Hey everyone, I'm trying to figure out if it's possible to block an executable file just by its product name while ignoring the publisher. I'm facing this issue because the publisher is Microsoft, and I currently have a rule that blocks essential applications like settings and the snipping tool.
My main aim is to block psexec from PSTools without having to update my rules every time the application gets updated—meaning I'd like to avoid using hash blocks. This is my first time using AppLocker, so I apologize if I seem a bit clueless. If AppLocker can't do this, are there alternative methods I can use through Intune?
The product details are:
- Publisher: O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US
- Product Name: SYSINTERNALS PSEXEC
- File name: *
- File version: *
5 Answers
Remember, you need to be mindful of both the publisher and product name in your rules. If other applications are being blocked, it sounds like there's a conflicting rule that’s causing these issues. For instance, what does your event viewer show when the snipping tool is blocked?
I recommend considering WDAC instead, as AppLocker isn't well-supported and may not be in the long term. Your setup could block any executable from Microsoft. You'll need to specify the exact program name in the rule for it to effectively block the specific file. However, the file version can be set to a wildcard if you want to block all versions.
But wouldn't renaming the executable allow it to bypass that block? I’m really looking for a way to ensure that the exe can’t run regardless of its name or version, which is why I thought relying on the product name could be the key.
This is one of those situations where AppLocker seems straightforward until you dive deeper. Blocking solely by product name isn't really supported in its design. AppLocker's security relies on binary trust—either trust the signer or the file path. The product name is just embedded metadata, not part of its security chain. If you want more nuanced control, consider using WDAC with advanced CI policies. But definitely test in audit mode first to avoid causing headaches with admin tools.
Thanks for the tip! I’ll try that approach and see how it turns out!
You should be able to do this with a path rule, but keep in mind that path rules can be easily bypassed. An admin could rename the executable and run it without any issues.
Yeah, I’m hesitant about path rules for exactly those reasons! It just seems too easy to get around.
Are you aiming to control local admins or just regular users? What’s your specific reason for blocking psexec? Many functions of psexec can usually be done through other methods, which makes your approach a bit of an X/Y problem.
I'm mainly trying to prevent local users from creating new user accounts as SYSTEM. I know there are other ways to do this, but this is my main concern at the moment. Plus, dealing with admin users makes it trickier.
It indicates that the snipping tool at %SYSTEM32%PICKERHOST.EXE was allowed to run, even though I'm getting the blocked notification. I think the issue arises because it's a UWP app.