AppLocker & AaronLocker

I recently had to put together a presentation on AppLocker and AaronLocker; this is a far more generalised version of that presentation

What is AppLocker and why use it?

AppLocker is an application whitelisting tool that is built into Windows; contrary to blacklisting where we state everything that should NOT run, with whitelisting, we state what SHOULD run, which is much easier to define, however by whitelisting we infer everything else is blacklisted.

AppLocker is available on Windows 7 and Server 2008 R2 and above, anything below these you will need to use Software Restriction Policies (SRP)

AppLocker forms an integral part of a Defence in Depth strategy, by preventing executable code, unauthorised applications and ultimately a step towards mitigating data leakage, licensing exposure and malware proliferation inside your network.

AppLocker policies can be configured centrally via Group Policy Management Console(GPMC) or locally via SECPOL; AppLocker events are recorded in the Windows Event Viewer “Application & Service Logs >> Microsoft >> Windows >> AppLocker”; you can use Windows Event Forwarding.

What can AppLocker Control?

• AppLocker has 3 intercept methods
  • New Process Creation
  • DLL Loaded (OCX & DLL)
  • Script Execution (VBScript, JScript, PowerShell, CMD & BAT)

• AppLocker supports 4 file types in Windows 7 & 5 in Windows 10
  • Executables (.com & .exe)
  • DLLs (.ocx & .dll)
  • Scripts (.vbs .js .ps1 .bat .cmd)
  • Windows Installers (.msi .msp .mst)
  • Packaged Applications (.appx) *Win10 only

Note: MSIX is not yet explicitly covered, however, due to the nature of MSIX publisher rules will cover them.

With scripting, the host process must call in to the “Application Identity” service; WScript. CScript, Powershell etc all do this, many others will not.

AppLocker Rule Types:

• AppLocker has 3 Rule Types
  • File Hash (SHA2 Authenticode for Exe & DLL; SHA2 flat file for everything else)
  • Path (Only as good as the ACLs applied)
  • Publisher (Derived from the digital signature)

• AppLocker offers Deny and Allow Actions with Exceptions
  • Deny will always take precedence, it is NOT recommended to deploy deny rules – Least privilege applies
  • Deploy Allow rules (which infer all else is denied) and use exceptions
  • AppLocker rules can be applied to groups or individual users and defined locally, these policies are additive, local and domain policies are evaluated.

AppLocker rules have “Enforce” and “Audit” modes; the latter should be your best friend for some time prior to moving to Enforce; in audit mode, nothing is blocked but event logs are created which will later be used by AaronLocker to generate rules.

AppLocker Limitations & Cautions:

• AppLocker requires processes to call to and be verified by the Application Identity service, not all software conforms.
• AppLocker cannot prevent all interpreted code being executed within a host process, e.g. Perl and even MS Office Macros.
  • Prime examples of interpreted code that AppLocker cannot prevent from executing.
  • Limit the process to executing only trusted signed code and macros.
• AppLocker only prevents a process from loading, what it does there after is not within AppLocker’s control.
• Do not use mapped drive letters for rules; Use fixed drives or UNC.
• Administrative users can bypass AppLocker rules.
• Don’t fear the DLL rules!

Using mapped drive letters is a very bad idea, these can be pointed anywhere thereby bypassing the rules!

Administrators are exempt from AppLocker rules, be careful who has this role

DLL Rules are nothing to fear, it may have once been true that a performance impact was seen, this is no longer the case, don’t fear the DLL rules.

AppLocker Initial Deployment Considerations:

• Active Directory Structure, mixed Windows versions & application suites will make GPO linking difficult if not impossible
• Application Identity Service is required and should be configured to “Automatic” start via GPO
• Clean builds are best, you don’t want to whitelist malware or PUA
• Do not deploy the default rule-set generated by AppLocker
  • These are path based and will allow execution from user writable areas such as windows temp.
• Use the Aaron locker scripts to export event log entries into AppLocker rules, saving you time!

AaronLocker, what is it?

• A series of Powershell scripts created by Aaron Margosis – MS Cyber Team
• AaronLocker comes with a hefty 80 page document
• Download it from Github – https://github.com/Microsoft/AaronLocker/
• Uses event data and SysInternals AccessChk to audit a system, the output is a pair of AppLocker policies
• The process is iterative, expect to run the scripts several times and make a few adjustments along the way!
• AaronLocker requires
  • SysInternals AccessChk tool (there is a script included to download this tool)
  • PowerShell 5.0+ (Obtain Windows Management Framework 5.1 for Win7)

Building Rules with AaronLocker:

It is crucial that any machine on which you build AppLocker rules is used for a reasonable period of time. AppLocker relies on the event logs to create rules, these logs will only be populated by activity, a particular caution would be your company finance department, if their software uses a DLL or OCX for payroll runs on a monthly basis, you wouldn’t be popular if you missed it and the payroll run didn’t happen!

Setup AaronLocker:

• Unblock the archive downloaded from GitHub (File Properties)
• Unzip to C:\ or C:\Users\Public\Documents, maintain the structure
• Place AccessChk & AccessChk64 in the same directory as the scripts
• Use an elevated PowerShell console to execute the scripts

Your directory structure should look something like this:

AaronLocker First Run:

• Execute “.\Create_Policies.ps1”

• 2 Policies created in “Output”
• Each time Create_Policies.ps1 is executed another set is created
• Writable directories written to 3 XML files in “ScanResults”

Use the “Audit” policy to start gathering events, but, first, run the remaining steps to identify known admin accounts and unsafe directories.

Using the same script and output, review the “ScanResults” for known admin accounts. AaronLocker will attempt to identify admin account but there’s no substitute for local knowledge, if you notice any, add them to the “CustomizationInputs\KnownAdmins.ps1” script; it’s worth considering whether the accounts should be there and if they should, can they be replaced with AD Groups instead?

The 3 XML files are the main item of interest here:

Here are the contents of the XML files, we are looking for admin accounts in the “Grantee” node.

Finding unsafe directories:

The Scan-Directories script uses AccessChk to run through ACLs looking for areas that regular users can write,

• By default all “Unsafe” directories will be blocked by the AaronLocker rule set: unsafe is defined as not read-only to non-admins
• Unsafe Directories are usually:
  • Directories on the root of C:\
  • The users profile
  • Some sub-directories of Program Data
  • Some sub-directories of Program Files

• Do NOT use File Path rules for these locationsUse the -Excel switch to get a filter friendly spreadsheet, or pipe to out-file

The scan-directories scripts has many more options, include specifying directories to search, user profiles to search and more! check the comments.

Add unsafe directories to “CustomizationInputs\UnsafePathsToBuildRulesFor.PS1”; AaronLocker output will tell you if a directory is unsafe!

Below is the “CustomizationInputs\UnsafePathsToBuildRulesFor.PS1” script, to add an entry just copy from the @ to } and change “label” & “paths”

• AaronLocker will build appropriate Publisher or File Hash rules for these locations
• Add any safe (read-only to non-admins) directories to “CustomizationInputs\GetSafePathsToAllow.ps1”
• Re-run the create policies script using “.\create_policies.ps1 –rescan”

Additional AaronLocker Scripts:

• TrustedSigners.ps1
  • Includes rules to allow Chrome – uncomment if needed
  • Use this script if you use WEF and don’t have AaronLocker on the same machine as the event data was gathered
• GetExeFilesToBlackList.ps1
  • Blacklists files known to bypass whitelisting
  • Includes Runas, cipher.exe, WMIC and multiple .Net apps
    • Comment them out if you need them but do so with extreme caution!
• After changing any customisation script, re-run create_policies.ps1 with the “-rescan” switch

By this point you should have a fairly well built AppLocker policy for Enforce and Audit mode; use the Audit policy to gather further data on a machine, again, do this for a good period of time to ensure you cover all activity, then re-run the create-policies script and apply audit again, when you are happy, move to enforce.

AppLocker is not a set and forget solution, the setup process is iterative, you should spend plenty of time in audit mode before you move to enforce.

In addition, the National Cyber Security Centre (NCSC) provides guidance on AppLocker policies, again, these are just a building block, using these in Enforce would almost certainly break things.