GPO software restrictions

There is a feature in group policy called software restriction policies which allows you to try to block users from running certain specified applications (black listing), or provide a list of applications which are allowed while blocking all others by default(white listing). There are several types of rules you can create:

Hash Rule: Crypto hash of the binary file
Certificate: A software publisher certificate that was used to digitally sign the file
Path: The file path or registry path to the file
Zone: What internet zone is used.

These types of rules can help to guard against predictable malware or certain versions of applications. The problem is that they are frequently very easy to get around.

Hash Rule (avoiding blacklist)
Lets assume our block rule covers txdns.

C:\Users\nl\Downloads>md5sum txdns.exe
f59a3d8e94f0f61130874fd794c38aa7 *txdns.exe

Using a hash rule to block something like this requires some considerations. First, every version and every patch level will have a unique hash. For applications that are frequently updating, you will never be able to keep up with them. If you have a file that has limited versions and no further development, it is still trivial to bypass this. Most files will have some text strings inside the executable. If we open txdns.exe with a hex editor, and immediately we see a string "This program cannot be run in DOS mode". We can change the T in This to lower case without effecting the program.

C:\Users\nl\Downloads>md5sum txdns.exe
42e19fdaeda1a12f21af5512396f37b9 *txdns.exe

Here we can see our hash is radically different than the original. A GPO administrator can't get around this with their blacklists. So what would blacklisting a hash be useful for? There may be a rare case where you encounter a specific and non mutating virus/malware that is in your organization. If you can throw up a hash rule and have systems update group policy, you can help to reduce the spread by this type of policy.

Certificate rules

It would be a bit rare to blacklist something that is signed. Many exe files won't be signed. If they are, and you have a specific one to block, you can look in the file properties to see the signature, and extract the certificate. Load this into a rule to block the software. This may work for something like Stuxnet that is reported to be signed by several stolen certs. Certificate rules would be primarily used in white listing mode, but again many exe's are not signed, or they may be signed with many certs. If you go looking through Microsoft software and downloads you will find either no signing or multiple certs used. Trying to keep up with external vendors' signed applications would take a lot of effort. If you were white listing a limited number of apps for a smaller set of machines, then this may be a useful method for one rule of your whole GPO.

Path rules

Getting path rules to work well in a blacklisting scenario would require a well locked down system to start with. Targeting a specific file using a standard install path would be pointless as the application could be moved or installed to a non standard location. If a user did not have access to create files and folders outside of their own home directory, you could blacklist everything in their profile to prevent execution of all code and scripts. Path rules allow for wildcards. So if you specify c:\documents and settings\*, no executable files can be run in this folder or any subfolders. This also includes attempts to access these files/folders using 8.3 format directory names. In the main policy settings, you can specify the extensions of files to protect against. You can try renaming the extension of a file such as file.exe to file.1 and trying to run it from cmd.exe. This will attempt to execute the file, but the system still sees it as the appropriate file type and blocks it. So, in general, if you need your systems to be extremely locked down, path rules can be a powerful addition.


The software restriction policy mechanism is being replaced by applocker, which is available in windows 7. It is possible to use both in policies, but only the newer OS's can process the applocker rules. I have yet to look at applocker, and I hope it is a step in the right direction for security and manageability.