Security: Application Whitelisting with Microsoft Intune and AppLocker

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.
ProductDisadvantagesPolicy ManagementRequirements/Support
Software Restriction Policies (SRP/SAFER)
  • Cannot block Store apps (.appx)
  • Rules cannot be created separately by file types
  • Rules cannot be imported or exported
  • No Audit mode
  • Group Policy (GPO)
  • Local Security Policy snap-in (secpol.msc)
  • AppLocker
  • Requires Enterprise/Education version of Windows 10/11 (unless you have Microsoft Intune)
  • Requires the AppIDSvc Service
  • Microsoft Intune (custom policy deployment via OMA-URI only)
  • Microsoft Configuration Manager (custom policy deployment via software distribution only)
  • PowerShell
  • Group Policy (GPO)
  • Local Security Policy snap-in (secpol.msc)
  • Windows 10, or Windows 11, or Windows Server 2016 and above.

    Policies deployed through GP are only supported on Enterprise/Education and Server editions.

    Policies deployed through MDM are supported on all editions.
    Windows Defender Application Control (WDAC)
  • Per-User and Per-User group rules are not supported
  • Microsoft Intune (limited built-in policies or custom policy deployment via OMA-URI)
  • Microsoft Configuration Manager (limited built-in policies or custom policy deployment via software distribution)
  • Group policy (GPO)
  • PowerShell
  • Windows 10, or Windows 11, or Windows Server 2016 and above.
    Smart App Control (SAC)
  • No application exclusion rules can be defined.
  • The set of rules is determined by Microsoft
  • App & browser control panel of the Windows Security appA newly installed Windows 11 22H2 is required to use Smart App Control (SAC). For existing installations, you won’t be able to turn SAC on unless you re-install or reset Windows 11.
    Application whitelisting technology overview

    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.

    AppIDSvc Service State when AppLocker is deployed with Microsoft Intune.

    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

    Configure AppLocker


    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.

    AppLocker Properties – Audit Only Mode

    Configure Basic Ruleset

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

    UserNameConditionPublisher/PathScope
    BUILTIN\AdministratorsAll filesPath*
  • Executable
  • DLL
  • Windows Installer
  • Script
  • EveryoneAll files located in the Program Files folderPath%PROGRAMFILES%*
  • Executable
  • DLL
  • Script
  • EveryoneAll files located in the Windows folderPath%WINDIR%*
  • DLL
  • Script
  • EveryoneSigned by MicrosoftPublisherO=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US
  • Executable
  • DLL
  • Windows Installer
  • EveryoneSigned by LenovoPublisherO=LENOVO, L=MORRISVILLE, S=NORTH CAROLINA, C=US
  • Executable
  • DLL
  • EveryoneSigned by TeamViewerPublisherO=TEAMVIEWER GERMANY GMBH, L=GÖPPINGEN, S=BADEN-WÜRTTEMBERG, C=DE
  • Executable
  • EveryoneAll signed packaged appsPublisherPublisher *
    Package name: *
  • Package app Rules
  • EveryoneAll Windows Installer files in %systemdrive%\Windows\InstallerPath%WINDIR%\Installer*
  • Windows Installer
  • Overview Basic Ruleset

    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

    Import AppLocker 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.

    Example: Permission check with 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.

    Path exeptions to prevent bypass via ADS (Alternate Data Streams)

    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.

    Publisher Exeption for Installutil.exe

    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%*)
    Path
    %SYSTEM32%\Com\dmp:*
    %SYSTEM32%\Com\dmp\*
    %SYSTEM32%\drivers\DriverData:*
    %SYSTEM32%\drivers\DriverData\*
    %SYSTEM32%\Microsoft\Crypto\RSA\MachineKeys:*
    %SYSTEM32%\Microsoft\Crypto\RSA\MachineKeys\*
    SYSTEM32%\spool\drivers\color:*
    %SYSTEM32%\spool\drivers\color\*
    %SYSTEM32%\Spool\PRINTERS:*
    %SYSTEM32%\Spool\PRINTERS\*
    %SYSTEM32%\Spool\SERVERS:*
    %SYSTEM32%\Spool\SERVERS\*
    %SYSTEM32%\Tasks:*
    %SYSTEM32%\Tasks\*
    %WINDIR%\Registration\CRMLog:*
    %WINDIR%\Registration\CRMLog\*
    %WINDIR%\SysWOW64\Com\dmp:*
    %WINDIR%\SysWOW64\Com\dmp\*
    %WINDIR%\SysWOW64\Tasks:*
    %WINDIR%\SysWOW64\Tasks\*
    %WINDIR%\Tasks:*
    %WINDIR%\Tasks\*
    %WINDIR%\Temp:*
    %WINDIR%\Temp\*
    %WINDIR%\tracing:*
    %WINDIR%\tracing\*
    Windows Path Exceptions

    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
    PublisherPath
    “O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US” ProductName=”BGINFO” BinaryName=”*”>
    <BinaryVersionRange LowSection=”*” HighSection=“4.31.0.0” />
    C:\Users\%username%\AppData\Local\Microsoft\WindowsApps\Bginfo.exe
    “O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US” ProductName=”MICROSOFT® WINDOWS® OPERATING SYSTEM” BinaryName=”CIPHER.EXEC:\Windows\System32\cipher.exe
    “O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US” ProductName=”MICROSOFT® .NET FRAMEWORK” BinaryName=”INSTALLUTIL.EXEC:\Windows\Microsoft.NET\Framework\v4.0.30319\InstallUtil.exe

    C:\Windows\Microsoft.NET\Framework64\v4.0.30319\InstallUtil.exe
    “O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US” ProductName=”MICROSOFT® .NET FRAMEWORK” BinaryName=”MICROSOFT.WORKFLOW.COMPILER.EXEC:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Workflow.Compiler.exe

    C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Microsoft.Workflow.Compiler.exe
    “O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US” ProductName=”MICROSOFT® .NET FRAMEWORK” BinaryName=”MSBUILD.EXEC:\Windows\Microsoft.NET\Framework\v4.0.30319\Msbuild.exe

    C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Msbuild.exe
    “O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US” ProductName=”INTERNET EXPLORER” BinaryName=”MSHTA.EXEC:\Windows\System32\mshta.exe

    C:\Windows\SysWOW64\mshta.exe
    “O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US” ProductName=”MICROSOFT® WINDOWS® OPERATING SYSTEM” BinaryName=”PRESENTATIONHOST.EXEC:\Windows\System32\PresentationHost.exe

    C:\Windows\SysWOW64\PresentationHost.exe
    “O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US” ProductName=”MICROSOFT® .NET FRAMEWORK” BinaryName=”REGASM.EXEC:\Windows\Microsoft.NET\Framework\v4.0.30319\regasm.exe

    C:\Windows\Microsoft.NET\Framework64\v4.0.30319\regasm.exe
    “O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US” ProductName=”MICROSOFT® .NET FRAMEWORK” BinaryName=”REGSVCS.EXEC:\Windows\Microsoft.NET\Framework\v4.0.30319\regsvcs.exe

    C:\Windows\Microsoft.NET\Framework64\v4.0.30319\regsvcs.exe
    “O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US” ProductName=”MICROSOFT® WINDOWS® OPERATING SYSTEM” BinaryName=”RUNAS.EXEC:\Windows\System32\runas.exe
    “O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US” ProductName=”MICROSOFT® WINDOWS® OPERATING SYSTEM” BinaryName=”WMIC.EXE”C:\Windows\System32\wbem\WMIC.exe
    Publisher exeptions for verified AppLocker bypasses for Default AppLocker rules

    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

    Export AppLocker Policy

    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

    Cleanup AppLocker 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:

    Custom (OMA-URI) AppLocker Rules
    NameOMA-URIData typeValue
    Executable Rules./Vendor/MSFT/AppLocker/ApplicationLaunchRestrictions/apprulset0001/EXE/PolicyStringCopy RuleCollection “Exe” Part from exported XML.

    <RuleCollection Type=”Exe” … </RuleCollection>
    Windows Installer Rules./Vendor/MSFT/AppLocker/ApplicationLaunchRestrictions/apprulset0001/MSI/PolicyStringCopy RuleCollection “Msi” Part from exported XML.

    <RuleCollection Type=”Msi” … </RuleCollection>
    Script Rules./Vendor/MSFT/AppLocker/ApplicationLaunchRestrictions/apprulset0001/Script/PolicyStringCopy RuleCollection “Script” Part from exported XML.

    <RuleCollection Type=”Script” … </RuleCollection>
    Packaged app Rules./Vendor/MSFT/AppLocker/ApplicationLaunchRestrictions/apprulset0001/StoreApps/PolicyStringCopy RuleCollection “Appx” Part from exported XML.

    <RuleCollection Type=”Appx” … </RuleCollection>
    DLL Rules./Vendor/MSFT/AppLocker/ApplicationLaunchRestrictions/apprulset0001/DLL/PolicyStringCopy RuleCollection “Dll” Part from exported XML.

    <RuleCollection Type=”Dll” … </RuleCollection>

    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:

    IDScopeDESCRIPTION
    8003EXE and DLLSpecifies that the .exe or .dll file would be blocked (Audit Mode).
    8004EXE and DLLThe .exe or .dll file was prevented from running (Enforce Mode).
    8006MSI and ScriptSpecifies that the script or .msi file would be blocked (Audit Mode).
    8007MSI and ScriptThe script or .msi file was prevented from running (Enforce Mode).
    8021Package appSpecifies that a package app would be blocked (Audit Mode).
    8022Package appPackage app was prevented from running (Enforce Mode).
    AppLocker 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.

    _PSScriptPolicyTest*. PowerShell Scripts

    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

    AppLocker Microsoft Intune Rules Storage Location

    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”>

    AppLocker in Action: Enforce Mode

    Leave a Reply

    Fill in your details below or click an icon to log in:

    WordPress.com Logo

    You are commenting using your WordPress.com account. Log Out /  Change )

    Twitter picture

    You are commenting using your Twitter account. Log Out /  Change )

    Facebook photo

    You are commenting using your Facebook account. Log Out /  Change )

    Connecting to %s