I hope you are enjoying your day. Perhaps you found yourself in a pickle with malware and need to finally implement a software restriction policy on your Windows Domain. Considering the items in question, I am presuming and hoping you have a Group Policy on your side to help manage these machines and users. Software Restriction Policies (SRP) are here to help you out.
Great! Since you are looking to add a restrictive group policy, I would suggest making a test OU (Object Unit – I will only define acronyms once) and creating GPO (Group Policy Object). With your Test OU and user account, I would suggest a VM (Virtual Machine) with that user account having minimal level domain access (Group: Domain Users). Making our new policy, you want to focus on the following tree of your new policy.
Computer Configuration | Windows Settings | Security Settings | Software Restrictions
Brief pause here. Respect to SwiftOnSecurity for bringing this conversation up recently on Twitter. My guide is based from Branko Vucinec’s SRP Guide. There is also a guide I will link below, that is for when you realize your policy also prevented Admins from installing programs. There is a fix for that too. 
Let’s talk about Environmental Variable Paths (EVP). These are commonly used by installers and scripters for installing, both legitimate and exploit code & applications. Ones I am focusing in are:
>@echo %appData%
C:Users{username.fullpath}AppDataRoaming
>@echo %localAppData%
C:Users{username.fullpath}AppDataLocal
>@echo %temp%
C:Users{username.8char~}AppDataLocalTemp
>@echo %tmp%
C:Users{username8char~}AppDataLocalTemp
Echo shows us we have the right file paths and how they output per the active user account. As noted, we are looking to restrict some access to items in these folders executing. Along with that, we have some extensions to focus on restricting. The linked guide covers, while I also add:
- Archives (7z, zip, rar)
- EXE
- JAR
- MSI
- VBS
- COM
- BAT
- PS1
Wild list, with some oldies on there. Let’s just say, you can lots of automation with .bat files. Everything else listed has more capabilities than that, but if you can call something else from a batch, there are options from there. This is not meant as an exhaustive stop-all-exploit execution solution! Honestly nothing really is (and if someone says so, they are lying). This is about presenting extra layers to prevent exploits from ‘getting the keys to your castle’ in respect to infrastructure.
This is getting wordy on the backdrop narrative… Let’s get going here. Time to make the policy.
Making our new GPO, jump into the tree and Right-click on SRP then click New Software Restriction Policy.
Under Additional Rules, add our Disallowed exceptions. These being the EVP list of folders I noted above. An example being “%temp%*.exe”
We add these by making a New Path Rule.
I could lie to you here, but you have quite a few to add. Branko’s Guide covers the syntax while my extension list adds other possibilities. Make the call what is most probable on your network and what you may have seen in attack patterns. Besides, you are one of the people who has to test this, and ideally one of the 1st to do so… so you can eliminate the immediate conflicts with business operations, before anyone else can try to prevent the implementation from happening.
Good Job. Now that you finished your new GPO, add your test machine into the linked OU with that policy and have your test account login on said VM or test desktop. Try to do some standard fare user operations and software patching. Install Firefox, update Flash, whatever you or anyone else might do on a frequent basis. If you managed to remove flash from your network. Give yourself a high-five.
Ok now try to install some software as an Administrator. In this case, Firefox will fail because it extracts the installer to %localAppData%. Turns out your policy also applies to Local and Domain Administrators logged into that machine. Good thing we are testing before launching live, huh?
To resolve this, we are jumping back into that policy you just made. We need to add an Enforcement exception for Administrators. The Policy path for that is:
Computer Configuration | Windows Settings | Security Settings | Enforcement
On the Enforcement settings, you will see Apply software restriction policies to the following users: Go ahead and in this middle section, set the radio dot to All users except local administrators MS KB on Enforcement.
Hit OK, Close your policy, jump back onto your VM and run another ‘gpupdate’ command to get the latest policy on that machine.
Diagnostic Note: If you have questions if the policy is actually applying, run RSOP.msc and see the Resultant Set of Policy. These details will show you what options are set by all GPOs and what one is defining the settings.
Try running that installer again, but this time right-click it and do a Run as Administrator. It will prompt if you are not logged in with an admin-level account, else it will just run. Your installer should now properly execute. In addition and most of all, rouge applications matching your filter rule list, should not be able to run. The protections are only as good as your rules, so keep an eye out for what applicable stops you can build to protect your network from processes gone awry.
