While AppLocker has been around since Windows 7 and Windows Server 2008 R2, I have rarely found the solution in enterprises. The main reason was always that the implementation is very time and resource consuming and that you must constantly maintain a whitelist. This is a bummer, because the security gain is enormous when a solution like AppLocker is used. If you deal with the AppLocker rules intensively and have developed a good concept at the beginning, you will realize that you do not have to adjust the rule regularly and that the operation is not as complex as you thought.

This blog article shows the important things to consider when implementing AppLocker, how to create a usable basic ruleset that requires minimal maintenance, and how to manage with Microsoft Intune.

1. Application whitelisting technology overview
2. AppLocker basic recommendations
3. AppLocker deployment considerations
4. AppLocker OS Requirements
5. AppLocker AppIDSvc Service Requirements
6. Configure AppLocker and start with Audit Only Mode
7. Configure Basic Ruleset
8. Exceptions
   1. Path Exeptions
   2. Publisher Exception
9. AaronLocker
10. AppLocker deployment with Microsoft Intune
11. Event monitoring
    1. AppLocker Event IDs
    2. _PSScriptPolicyTest*. PowerShell Scripts
    3. Azure Log Analytics / KQL
       1. Check for Audit Mode Events with KQL
       2. Check for Enforce Mode Events with KQL
    4. AppLocker Microsoft Intune Rules Storage Location
12. Configure Enforce Mode

Application whitelisting technology overview

Let’s first get an overview of all the products developed by Microsoft in recent years for application whitelisting:

1. Software Restriction Policies (SRP/SAFER)
   • Introduced with Windows XP and Windows Server 2003. Hardly widespread. It was further developed and replaced by AppLocker. There is no good reason to use this product anymore.
2. AppLocker
   • Introduced with Windows 7 and Windows Server 2008 R2. It is the most widely used application whitelisting technology.
3. Windows Defender Application Control (WDAC)
   • Introduced with Windows 10 and Windows Server 2016. Previously known as Device Guard. Rebranded to Windows Defender Application Protection (WDAC) with Windows 10 1903.
4. Smart App Control (SAC)
   • Introduced with Windows 11 22H2 and works with an AI model that predicts whether an app is safe based on 43 trillion security signals collected daily. For more information and my first impressions click here.

AppLocker basic recommendations

The following five recommendations should be considered when implementing AppLocker:

1. In order to achieve successful AppLocker management, no admin rights for end-users are allowed on the system.
2. Generally use whitelisting with exceptions and blacklisting only in exceptional cases.
3. To avoid the need to create or adjust new rules on a regular basis, mainly Publisher and Path Rules should be used.
4. For path rules, if there are end-user write permissions on the approved paths, make sure that exception rules are created there.
5. Hash rules should only be used if the binary does not change constantly and no path or publisher rules can be used.

AppLocker deployment considerations

The AppLocker deployment considerations to achieve the least operational overhead are built from the following 12 points. These are mainly compiled from the recommendations of Sami Laiho, who has already written a very detailed post about this.

1. We generally trust the %WINDIR% and %PROGRAMFILES% path. As long as end-users do not have write permissions inside these paths or have general admin permissions, this concept works.
2. For paths where write permissions exist for end-users like C:\Windows\Temp or custom folders in %PROGRAMFILES%, exception path rules are created.
3. We trust signed applications from Microsoft (Signed by O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US).
4. Since there are some AppLocker bypasses methods that are exploited via signed Microsoft applications (such as Msbuild.exe), exceptions are created for these special cases.
5. We trust all applications signed by our hardware manufacturer like e.g., Lenovo
   (Signed by O=LENOVO, L=MORRISVILLE, S=NORTH CAROLINA, C=US)
6. We trust our used and signed remote support application like e.g., TeamViewer (Signed by O=TEAMVIEWER GERMANY GMBH, L=GÖPPINGEN, S=BADEN-WÜRTTEMBERG, C=DE).
7. We trust packaged applications (Microsoft Store Apps) that are signed.
8. End users are only allowed to install Microsoft signed applications that do not require admin rights or are run from %systemdrive%\Windows\Installer.
9. Installations that do not require administrator rights because they are installed via the user context (%LocalAppData%) are blocked.
10. We block all malicious, untrusted or unsigned applications from the Internet.
11. All approved applications that are distributed via Microsoft Intune (Required/Available/Uninstall) should not be blocked.
12. BUILTIN\Administrators are allowed to run all files and are therefore excluded from all AppLocker rules.

AppLocker OS Requirements

Without Microsoft Intune, Enterprise/Education version of Windows 10/11 is required. With Microsoft Intune, all Windows 10/11 editions are supported.

You can use the AppLocker CSP to configure AppLocker policies on any edition of Windows 10 and Windows 11 supported by Mobile Device Management (MDM). You can only manage AppLocker with Group Policy on devices running Windows 10 and Windows 11 Enterprise, Windows 10 and Windows 11 Education, and Windows Server 2016.

https://learn.microsoft.com/en-us/windows/security/threat-protection/windows-defender-application-control/applocker/requirements-to-use-applocker#general-requirements

AppLocker AppIDSvc Service Requirements

Without Microsoft Intune, it was necessary to configure the AppIDSvc service. This is no longer necessary with a deployment via Microsoft Intune. Therefore, the service does not need to be started or set to “Automatic”. Once AppLocker is configured with Microsoft Intune, the service starts automatically, and the startup type “Manual” is sufficient for AppLocker to work properly.

Configure AppLocker and start with Audit Only Mode

Via the Local Security Policy Snap-In (secpol.msc) we can configure AppLocker and have the option to run AppLocker in either Audit Mode or Enforce Mode.

secpol.msc (run as Administrator) – Application Control Policies – AppLocker – Properties

In the “Enforcement” tab we first activate the “Audit only” mode for all scopes.

To use the DLL rules they have to be activated in the “Advanced” tab first.

If you enable the AppLocker audit-only mode, you can retrieve important information from event logs that will be helpful in creating AppLocker rules.

Configure Basic Ruleset

Based on the concept described above, the following basic rule set is formed:

This basic ruleset can now either be adopted and customized to your needs or you can create your own policy rules from the beginning. I provide the basic ruleset directly as XML download. Exceptions for default rules are also already included. You just need to make sure that you replace Lenovo with your hardware manufacturer and TeamViewer with your remote help tool.

Download AppLocker Basic Ruleset

The XML file can be imported as follows:
secpol.msc (run as Administrator) – Application Control Policies – AppLocker – Import Policy

Exceptions

As already mentioned in the basic recommendations, it is important to check that end users do not have write permissions for permitted paths or that appropriate exceptions are defined. The easiest way to check this is to use AccessChk. Oddvar Moe (api0cradle) has published on GitHub all the important default paths to check using AccessChk.

To prevent an AppLocker bypass via ADS (Alternate Data Streams) from working, make sure that each path exeption is also specified in the format :*

Example:
If %WINDIR%\tracing\* is excluded, %WINDIR%\tracing:* must also be excluded.

Another important thing to know is that Microsoft has released many windows binaries within the .NET framework that have the ability to compile and execute code (such as Installutil.exe or Msbuild.exe). With these binaries, there are numerous verified AppLocker bypass methods if Microsoft is allowed as a trusted publisher in the AppLocker rules, which is the case in most configurations. Therefore, it is important to define exceptions for verified AppLocker bypasses for Default AppLocker rules as well. Oddvar Moe (api0cradle) has also published a list for verified AppLocker bypasses on GitHub.

Other known AppLocker bypasses include CIPHER.EXE, MICROSOFT.WORKFLOW.COMPILER.EXE, RUNAS.EXE and WMIC.EXE. These should also be excluded if possible. Also for BGInfo you will find bypass posts repeatedly. If not needed, BGInfo should also be excluded or only the latest version should be allowed.

Path Exeptions

The following path exeptions should be observed for the following scopes:

• All scripts located in the Windows folder (%WINDIR%*)
• All DLLs located in the Windows folder (%WINDIR%*)

Publisher Exception

The following publisher exeptions should be observed for signed Microsoft publisher rules:

• Signed by O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US

AaronLocker

Another very good way to get started with AppLocker and fill any policy gaps is to use AaronLocker developed by Aaron Margosis. AaronLocker is a PowerShell script collection available on GitHub. For an easy start, it is recommended to watch the two demo videos linked on the GitHub AaronLocker start page, which give a good first insight and also help to get started quickly.

AppLocker deployment with Microsoft Intune

Once we have completed our first AppLocker policy rules configuration, we can export them as XML to be able to distribute the configuration via Microsoft Intune.

secpol.msc (run as Administrator) – Application Control Policies – AppLocker – Export

After successfully exporting the configuration, we can now perform a cleanup of the local configuration, as we are now configuring the deployment via Microsoft Intune.

secpol.msc (run as Administrator) – Application Control Policies – AppLocker – Clear Policy

Now we switch to Microsoft Intune and create a Custom (OMA-URI) AppLocker Policy.

https://intune.microsoft.com – Devices – Configuration profiles – Create profile
Platform: Windows 10 and later
Profile type: Templates – Custom

A new row is created for each AppLocker rules category:

Event monitoring

AppLocker Event IDs

AppLocker events can be found in the Applications and Services logs (eventvwr.msc):
Applications and Services Logs – Microsoft – Windows – AppLocker

Here is an overview of the most important event IDs:

For Audit Mode look for the following event IDs: 8003, 8006, 8021
For Enforce Mode look for the following event IDs: 8004, 8007, 8022

_PSScriptPolicyTest*. PowerShell Scripts

PSSCRIPTPOLICYTEST files are random generated by Microsoft Powershell to test if AppLocker is running in enforcement mode. These events can be safely ignored.

Azure Log Analytics / KQL

To easily and clearly evaluate AppLocker events, it is helpful to configure Azure Log Analytics. For this I can recommend the post from Call4Cloud (Rudy Ooms).

Check for Audit Mode Events with KQL

Event | 
where EventLog contains "Microsoft-Windows-AppLocker" and EventID == "8003" or EventID == "8006" or EventID == "8021"
| project Computer,EventLog,EventID,RenderedDescription,UserName

Check for Enforce Mode Events with KQL

Event | 
where EventLog contains "Microsoft-Windows-AppLocker" and EventID == "8004" or EventID == "8007" or EventID == "8022" 
| project Computer,EventLog,EventID,RenderedDescription,UserName

AppLocker Microsoft Intune Rules Storage Location

Once AppLocker Rules are applied via Microsoft Intune, they can be found in the following path: C:\Windows\System32\AppLocker\MDM

Configure Enforce Mode

After extensive tests and event evaluations have taken place, the Enforce mode can be activated on a first test client. To do this, we can either import our completed XML ruleset again and then switch from “Audit Only” to “Enforce rules” in the AppLocker properties. Then perform a cleanup, export the XML and adjust all policy categories again in Microsoft Intune. Or we can simply customize the Microsoft Intune Policies directly and adjust the following syntax:

Audit Only Mode: EnforcementMode=”AuditOnly”
Enforce Mode: EnforcementMode=”Enabled”>