AppLocker - Another Layer in the Defense in Depth Against Malware

First published on TechNet on Jun 27, 2016
Hello, Paul Bergson here with a discussion on Security in particular utilizing Microsoft's AppLocker to help prevent the infection of Malware. Ransomware has been getting a lot of attention. There have been several high profile attacks in the press over the past few months and Understanding the Risk is important. If people don't understand the risk, changes won't be made. To protect your enterprise, there are many steps for a Defense in Depth strategy to be taken. One of the recommended steps is to run a Whitelisting tool. Microsoft provides a built-in tool named AppLocker. Initially AppLocker was only available on enterprise level desktop versions but, starting with Windows 10, it is now available for both Enterprise and Education versions. AppLocker has always been available for all versions of Windows Server, with the exception of Server Core. For a complete list of version availability, see here . AppLocker is an update from Software Restriction Policies feature (XP/2003) that was released with Windows 7/Server 2008 R2. AppLocker allows an administrator to define a set of rules to be applied against non-admins , which can be based on attributes from a file's digital signature including the Publisher, Product or Version. You can also create rules from a hash of the file or a path to a set of files. Along with the Whitelist rules, exceptions can be defined to prevent certain files from being executed from the initial larger rule set. Exceptions are an important part of the rules; a non-admin shouldn't need to modify system files or the registry. So when a rule is defined to allow "Everyone" to execute all files located in the %WinDir% folder an exception should be made to block applications used to managed the operating system (Registry Editor for example). The default NTFS permissions grant a user Read/Write permission to their workspace, as well as all "Authenticated Users" have Read/Write permissions to %WinDir%/Temp (see diagram below). Malware authors take advantage of this and other writable areas within the operating system to load and execute their malware. If NTFS permissions allow the storage and Anti-Virus doesn't block the malware from executing the software, then the user has been compromised. AppLocker's role in the Defense in Depth strategy is to prevent the execution of software from a non-admin's writable workspace. You will notice I don't use the term user, but instead refer to the standard desktop user as a "Non-Admin". One of the most important steps in the Defense in Depth strategy is to only provide your users with the permissions that are needed. AppLocker can be easily bypassed if a user is a member of the local administrators group. Therefore it is recommended to remove all desktop users from the local administrators group. AppLocker has default rules right out of the box, but these rules are just a starting point, not the end point. With the understanding that for AppLocker to be an effective tool, the administrator needs to know what folders the non-admins have both execute and write permissions on. This is the key point, since if a non-admin can't save to an executable location, then there won't be an opportunity for malware to be run on the system. Planning a roll out is probably the most important step in an AppLocker delivery. To enforce a single set of the rules across the enterprise is not a reasonable task. Departments within a company will each have their own set of applications that they need to run and rules for one department might not work for another. The installation of applications will create new files and folders that will need to be defined and managed, since the creation of these new folders might grant a user write capability that could be then become a dropping point for malware. A task the administrator will want to do, is create a script to read the folders on the non-admin's system to find where they have execution capabilities (Program Files and Windows for example). There are documents on the planning and management of AppLocker (below), but the non-admin's workspace will change over time, so to ensure that these changes are included in AppLocker's rule set it is important to understand what and where these writable folders exist.

• Microsoft's Torkington design guide
• National Security Agencies "Application Whitelisting Using Microsoft AppLocker"
  • Acceptance of a certificate required, so hyperlink was not included
• National Security Agencies " AppLocker-Guidance " on GitHub
• United Kingdom's CESG " End User Devices Security Guidance: Windows 10 "
• Australia's DoD " Implementing Application Whitelisting "
• New Zealand's NCSC " Application Whitelisting with Microsoft AppLocker "

This blog doesn't define how to configure the AppLocker rules themselves, several of the documents above do an outstanding job of this. Once AppLocker has been applied, it is important to monitor the effectiveness of the rules. The Windows Event Logs provide great information on this. In the initial roll out of AppLocker, it is first recommended to place the rule set in "Audit Only" mode. By using auditing, you can then evaluate the rules you have defined against what is actually occurring. The Event Id's used by AppLocker range from 8000-8027. For a complete list of what each event is see here . To read through a single Event log for missed applications is ok, but if the rules are going to be applied against 50 non-admin desktops, the review would be daunting. That is where another free tool from Microsoft comes into play, Windows Event Forwarding (WEF). WEF allows an administrator the ability to define an Event Log to be filtered by a defined set of criteria including a range of events with the results forwarded to a collector. An enterprise can use Group Policy to define to the clients where to find the WEF "Collector". The Collector will then define what log and the events it will aggregate for the clients. Since we already have a great a series of TechNet Wikis on this subject, I won't be going into it. Not only does this Wiki cover WEF configuration, it goes into details on uses for WEF to help in Malware detection. A quick look at how to configure a policy Whether you want to use a local or domain policy the process to edit it is the same. Open up the Computer Policy and drill down to – Computer Configuration \ Policies \ Windows Settings \ Security Settings \ Application Control Policies \ AppLocker.

From here there is the ability to enable rule sets by selecting the properties of the AppLocker icon. From the properties page the rules can be "Enforced" or "Audited".

When you are building a new rule set it is recommended that you start with "Audit only" and review the client Event Log to ensure that what you had expected to be allowed to be run... … or blocked was as expected. To define the rules from one of the four (Five with DLL) rules sets, you just right click on one and a context sensitive menu will pop-up.

From here you can either "Create a Default Rules" set, "Automatically Generate Rules" or "Create New Rule". I will briefly cover how to create default rules and creating a new rule. Each rule set has a default set of rules. For example: AppLocker defines executable rules as any files with the .exe and .com extensions that are associated with an application. Because all of the default rules for the executable rule collection are based on folder paths, all files under those paths will be allowed. The following table lists the default rules that are available for the executable rule collection.

For complete details on "Default Rules" for each of the rule sets, please see: https://technet.microsoft.com/en-us/library/ee460941(v=ws.11).aspx If you want to Create a new rule you can define it as "Allow" (Whitelist) or "Deny" (Blacklist). By Whitelisting only certain files to be executed you are implicitly denying all others, which is the recommended strategy. As with any rule within AppLocker you can define exceptions. Take for example I have a test lab that I want to allow "Everyone" to install "Security Compliance Manager" that will be pushed to "C:\SCM". The option "Create New Rule" was selected.

The option to use the "Publisher" will be the selected method. I want to ensure as the administrator only "Version 3.0.60.0" is permitted to be run (Installed in this instance). By using the slider the control of the application ca be adjusted from Version, File name, Product name, Publisher or Any publisher.

Finally, the name of the new rule is entered and it can then be created.

Once you have your rules defined, you will then want to link the group policy to a test group of clients, remember to start in "Audit Only" mode. Linking and managing group policy is beyond the scope of this blog. I hope I have helped educate you on some of the capabilities of AppLocker and, although it has been around for quite some time, I think it has been over-looked. With the uptick in Ransomware and other malware activity, administrators are giving it a second look since it can help you stop the proliferation of malware within your enterprise.