A few years ago, we had a horrible conficker infection. The total infected count climbed to just under 1000 machines. We couldn’t wipe machines faster than the malware could spread. Eventually, we took the entire site offline and imaged every machine.

This caused a paradigm shift for our organization. Administration was finally convinced that something had to be done with security. We were given the go ahead to do whatever was necessary to prevent a future breakout. We removed all administrative rights for users, tightened file security and the Windows firewall, and increased the level of protection provided by UAC. The biggest change though was the implementation of AppLocker with whitelisting.
 

AppLocker with a Whitelist

With the release of Windows 7, Microsoft essentially replaced Software Restriction Policies with the introduction of AppLocker. If you have ever used Software Restriction Policies, you fully understand the inherit limitations. While it was easy to block or allow specific applications, creating global whitelists or global blacklists was nearly impossible. Further, these policies lack flexibility in who they applied to or how they were deployed. AppLocker, available in Windows 7/8 Enterprise, addressed these limitations and added some essential features.

What is so important about a Whitelist? With a traditional antivirus, malware is detected through definition files. Malicious software is caught when it is known or when it behaves a certain way. Blacklists are always limited because malware constantly changes. In terms of security, the real power of AppLocker rests in the ability to create a whitelist. A whitelist comprises of known trusted software. Anything not on the whitelist is not allowed to run. Suddenly, you no longer have to worry about updating definitions or the latest threat! If it wasn’t trusted before, it won’t run now.
 

How to Setup AppLocker in Whitelist Mode

Once again, we are going to turn to Group Policy. Create a new GPO named AppLocker Configuration. We will store our domain’s general AppLocker settings in this GPO. Be sure that this GPO is not linked to an OU at this time. Edit the GPO and navigate to Computer Configuration/Windows Settings/Security Settings/System Services. Select the Application Identity service and set it to Automatic. If you are not on a Server OS (2008 R2+) or an Enterprise Client OS, you won’t see this service.

Enabling the Application Identity (AppLocker) Service

After enabling the service, navigate down to the Application Control Policies node and expand AppLocker. The OS you edit the GPO from will determine what AppLocker can control. If possible, edit this GPO from a Windows 8/Server 2012 machine in order to get the most out of AppLocker. As a best practice, you should always use the latest GPMC (and RSAT tools) available.

With AppLocker, we can control five types of files: executables (.exe, .com); a variety of scripts (.bat, .cmd, .js, .ps1, .vbs); DLLs files (optional); Modern Apps (.appx) and MSIs (or MSPs). For right now, we are only concerned with executables and scripts as they comprise the bulk of threats.

Our first step is to configure how AppLocker will run. Select the main AppLocker node and then choose Configure Rule Enforcement. We are going to select the enforcement options for Executables and Scripts. Because this is a test environment, we are going to leave Enforce Rules as the default method. If this was a production environment and if you were unsure if any applications are used outside the default rule locations, you would want to change this to Audit Only or do a phased rollout.

Configuring AppLocker Enforcement Properties

Our next step is to configure our default (white list rules). Select the Executable Rules node – right click and choose Create Default Rules.

You should now have three new rules. Before continuing, select the Scripts Rules node and generate the default rules for that node as well. It is extremely important for clients to have the default rules applied to them. If not, Windows won’t even come up to a logon screen!*

Notice that the Condition column for each rule specifies “Path”. Let’s break down a rule. Take the default rule “All files located in the Program Files folder”. The rule literally states “Allow Everyone to Run Any Executable (.EXE/.COM) that has a location of C:\Program Files\* (and if needed, C:\Program Files (x86)\*). When your environment deploys software centrally, you can see how simple AppLocker is to maintain.
 

Creating a New AppLocker Exclusion Rule

Let’s say that you have a legacy software that installs to the root of a drive (C:\). With AppLocker enabled, it obviously will not be allowed to run. With just the default rules, the legacy application must exist in either C:\Windows\* or C:\Program Files\*. For applications that fall outside the scope of the default rules, we will need to create a specific application exclusion rule.

Creating a new rule is easy. As an example, we are going to create a new folder in root of C:\. We will then copy notepad.exe to this folder and use it as our legacy application. Once we have linked our GPO and restarted our test machine, we can log in as a standard user to test AppLocker. When you try to launch the legacy application, you should receive this error message:

This error is also logged in Event Viewer under Application and Services Log/Microsoft/Windows/AppLocker. Let’s now create an exception for the legacy app. Right click on Executable Rules and select Automatically Generate Rules. While you can manually create rules by selecting Create New Rule, rules create automatically will always adhere to Microsoft’s best practices.

Automatically Generate Rules button will launch a Rule wizard. In the wizard, change the browse location to the C:\LegacyApp folder and select Next. You can now choose the rule type. Rules can be one of three types: Certificate, Hash, or Path rule. When creating a rule, you should always try to create a digitally signed (certificate) rule first.

If the files are not signed, you will have to choose between a hash or path rule. You will generally choose a hash rule if the executable is rarely updated. Because a hash rule only applies to a very specific version of a file, updating a program will require you to also update the hash rule. A path rule is your final option. It should normally be a last resort and should never apply in a folder where a standard user can write to.

Knowing the rule types, we can select the default rule type in the Rule wizard. Notepad is a signed file so a certification rule will be created. If it wasn’t signed, a hash rule would have been created. We can then press Next and finally create our rule.

Your executable rule list should now list your new rule. After running a Group Policy Update on our test machine, our legacy application will now run. Rules are cumulative. You can add them to specific GPOs. Any applied to a client will simply stack to build an AppLocker exclusion list. You can use GPResult on the client to view applied rules.

AppLocker is an incredibly powerful security tool. By implicitly denying all untrusted applications, you can secure your organization against the unknown. Users are unable to download all of the junk that causes most of their problems (toolbars, coupon clippers, weather stuff, etc…). Though it does require a bit of IT overhead, never having a virus outbreak again is an awesome benefit!

If you use AppLocker, what tricks make it easier to manage? If you aren’t using AppLocker, what is stopping you from doing so?

*Fun fact – I once spent an entire morning troubleshooting this particular problem!