SRPs block malware, but what if things stop working?
As I wrote in my last post on lateral movement, using AppLocker or Software Restriction Policies (SRPs) to avoid the execution of unknown or malicious software is good practice. While SRPs are older, they are also more widely available, especially when it comes to consumer-grade Windows versions.
Setting up SRPs is easy enough and there are good tutorials on how to do it. You will want to work with certain Path rules and Hash rules to allow known good software, while avoiding broad whitelisting of whole top-level directories (such as C:\ or *UserDir*\AppData\Roaming).
However, even if you found a good balance between usability and safety, there will still be times when a certain app will not run anymore or something will not be working. Fortunately, it is not hard to find out what was blocked by SRPs. Windows Event Viewer logs blocked application events as ID 865. So, you can just open Event Viewer…
… and watch out for event ID 865 to find the problematic program:
With this information you can now go ahead and set up a rule for whitelisting, for example by using the path of the executable or its hash.
I admit, working with SRPs in the strictest “Disallowed” mode can sometimes still be a pain, but having ransomware on your computer also is not fun. And knowing this little trick to find out why things stop working is often helping me to get the system running smoothly again.