Implementing Application Whitelisting with AppLocker

When to Use

Use this skill when:

• Implementing application control to prevent unauthorized software execution on Windows endpoints
• Meeting compliance requirements (PCI DSS 6.4.3, NIST 800-53 CM-7, ACSC Essential Eight)
• Blocking common attack vectors: living-off-the-land binaries (LOLBins), script-based attacks, unauthorized admin tools
• Restricting software installation in kiosk, POS, or high-security environments

Do not use this skill for macOS/Linux application control (use OS-native tools like Gatekeeper or AppArmor) or for enterprise-grade WDAC (Windows Defender Application Control) deployments.

Prerequisites

• Windows 10/11 Enterprise or Education, or Windows Server 2016+
• Application Identity service (AppIDSvc) enabled on target endpoints
• Active Directory with Group Policy Management Console (GPMC)
• Complete application inventory of approved software
• Test OU with representative endpoints for policy validation

Workflow

Step 1: Inventory Approved Applications

Before creating AppLocker rules, catalog all legitimate software:

# Generate application inventory on reference endpoint
Get-AppLockerFileInformation -Directory "C:\Program Files" -Recurse `
  -FileType Exe | Export-Csv "C:\AppLocker\app_inventory_progfiles.csv" -NoTypeInformation

Get-AppLockerFileInformation -Directory "C:\Program Files (x86)" -Recurse `
  -FileType Exe | Export-Csv "C:\AppLocker\app_inventory_progfiles86.csv" -NoTypeInformation

# Include Windows system executables
Get-AppLockerFileInformation -Directory "C:\Windows" -Recurse `
  -FileType Exe | Export-Csv "C:\AppLocker\app_inventory_windows.csv" -NoTypeInformation

Step 2: Create AppLocker Policy with Default Rules

# In Group Policy Editor (gpedit.msc) or GPMC:
# Navigate to: Computer Configuration → Policies → Windows Settings
#   → Security Settings → Application Control Policies → AppLocker

# Enable default rules for each rule collection:
# - Executable Rules: Allow Everyone to run files in Program Files and Windows
# - Windows Installer Rules: Allow Everyone to run digitally signed MSIs
# - Script Rules: Allow Everyone to run scripts in Program Files and Windows
# - Packaged App Rules: Allow Everyone to run signed packaged apps

# PowerShell: Generate default rules
$defaultRules = Get-AppLockerPolicy -Local -Xml
Set-AppLockerPolicy -XmlPolicy $defaultRules -Merge

Step 3: Create Publisher-Based Rules (Preferred)

Publisher rules are the most maintainable since they survive application updates:

<!-- Example AppLocker policy XML for publisher rules -->
<RuleCollection Type="Exe" EnforcementMode="AuditOnly">
  <!-- Default: Allow Windows binaries -->
  <FilePublisherRule Id="a9e18c21-ff54-4677-b3ac-4b9a03261f6c"
    Name="Allow Microsoft signed" Description="Allow all Microsoft-signed executables"
    UserOrGroupSid="S-1-1-0" Action="Allow">
    <Conditions>
      <FilePublisherCondition PublisherName="O=MICROSOFT CORPORATION*"
        ProductName="*" BinaryName="*">
        <BinaryVersionRange LowSection="*" HighSection="*"/>
      </FilePublisherCondition>
    </Conditions>
  </FilePublisherRule>

  <!-- Allow specific third-party vendor -->
  <FilePublisherRule Id="b2e28c32-aa65-5788-c4bd-5c0b14372e7d"
    Name="Allow Adobe Acrobat" Description="Allow Adobe-signed Acrobat executables"
    UserOrGroupSid="S-1-1-0" Action="Allow">
    <Conditions>
      <FilePublisherCondition PublisherName="O=ADOBE INC.*"
        ProductName="ADOBE ACROBAT*" BinaryName="*">
        <BinaryVersionRange LowSection="*" HighSection="*"/>
      </FilePublisherCondition>
    </Conditions>
  </FilePublisherRule>
</RuleCollection>

Step 4: Block Known-Abused Binaries (LOLBins)

# Deny rules for commonly abused living-off-the-land binaries
# These are legitimate Windows tools frequently used by attackers

$denyPaths = @(
    "%SYSTEM32%\mshta.exe",
    "%SYSTEM32%\wscript.exe",
    "%SYSTEM32%\cscript.exe",
    "%SYSTEM32%\regsvr32.exe",
    "%SYSTEM32%\certutil.exe",
    "%SYSTEM32%\msbuild.exe",
    "%SYSTEM32%\installutil.exe",
    "%WINDIR%\Microsoft.NET\Framework\*\msbuild.exe",
    "%WINDIR%\Microsoft.NET\Framework64\*\msbuild.exe"
)

# Create deny rules in AppLocker policy for standard users
# Important: Deny rules take precedence over Allow rules
# Apply only to standard users (not admins who may need these tools)

Step 5: Configure Script Rules

Script Rules (critical for preventing script-based attacks):

Allow:
  - Scripts in C:\Program Files\* (publisher or path-based)
  - Scripts in C:\Windows\* (default Windows scripts)
  - Approved admin scripts from \\fileserver\scripts\*

Deny (for standard users):
  - PowerShell scripts from user-writable directories
  - VBScript from %TEMP%, %APPDATA%, %USERPROFILE%\Downloads
  - JavaScript (.js) from any user-writable location

DLL Rules (optional, high performance impact):
  - Enable only in high-security environments
  - Allow signed DLLs from Program Files and Windows directories
  - Performance impact: 5-10% CPU increase during DLL loading

Step 6: Deploy in Audit Mode First

# CRITICAL: Always deploy AppLocker in Audit mode before Enforce mode
# Audit mode logs what would be blocked without actually blocking

# Set enforcement mode to Audit Only in GPO:
# AppLocker → Executable Rules → Properties → Configured: Audit only
# AppLocker → Script Rules → Properties → Configured: Audit only
# AppLocker → Windows Installer Rules → Properties → Configured: Audit only

# Ensure Application Identity service is running
Set-Service -Name AppIDSvc -StartupType Automatic
Start-Service AppIDSvc

# Link GPO to test OU
New-GPLink -Name "AppLocker-Audit-Policy" `
  -Target "OU=AppLocker-Pilot,DC=corp,DC=example,DC=com"

# Monitor audit logs for 2-4 weeks
# Event Log: Applications and Services Logs → Microsoft → Windows → AppLocker
# Event IDs:
#   8003 = EXE/DLL would be blocked
#   8006 = Script/MSI would be blocked
#   8023 = Packaged app would be blocked

Step 7: Analyze Audit Logs and Refine Rules

# Export AppLocker audit events
Get-WinEvent -LogName "Microsoft-Windows-AppLocker/EXE and DLL" `
  -FilterXPath "*[System[EventID=8003]]" |
  Select-Object TimeCreated,
    @{N='User';E={$_.Properties[0].Value}},
    @{N='FilePath';E={$_.Properties[1].Value}},
    @{N='FileHash';E={$_.Properties[4].Value}} |
  Export-Csv "C:\AppLocker\audit_blocked_exes.csv" -NoTypeInformation

# Review blocked applications
# For each blocked legitimate application:
#   1. Create a publisher rule (if signed) or path rule (if unsigned)
#   2. Add to AppLocker policy
#   3. Re-audit for 1 additional week

Step 8: Switch to Enforce Mode

# After audit period with no legitimate applications blocked:
# Change enforcement mode from Audit to Enforce

# Update GPO:
# AppLocker → Executable Rules → Properties → Configured: Enforce rules
# AppLocker → Script Rules → Properties → Configured: Enforce rules

# Phased enforcement:
# Week 1: Enforce EXE rules only
# Week 2: Enforce Script rules
# Week 3: Enforce MSI rules
# Week 4: (Optional) Enforce DLL rules

# Maintain monitoring: Event IDs 8004 (blocked EXE), 8007 (blocked script)

Key Concepts

Tools & Systems

• AppLocker (built-in): Windows application control feature in Enterprise/Education editions
• WDAC (Windows Defender Application Control): More advanced successor to AppLocker for modern Windows
• Microsoft LAPS: Manages local admin passwords to prevent bypassing AppLocker via admin rights
• WDAC Wizard: GUI tool for creating Windows Defender Application Control policies
• AaronLocker: Open-source AppLocker rule generator by Microsoft employee (GitHub)

Common Pitfalls

• Skipping Audit mode: Deploying AppLocker in Enforce mode without audit period will block critical applications and cause outages.
• Relying solely on path rules: Users with write access to allowed paths (C:\Windows\Temp) can bypass path-based rules. Prefer publisher rules.
• Not blocking user-writable directories: The most common gap is allowing execution from %TEMP%, Downloads, or %APPDATA%.
• Forgetting Application Identity service: AppLocker requires the AppIDSvc service running. If it stops, all rules stop enforcing.
• Admin bypass: Local administrators can bypass AppLocker by default. For full enforcement, combine with WDAC which enforces for all users including admins.
• DLL rule performance: Enabling DLL rules creates significant performance overhead. Only enable in high-security environments where the tradeoff is justified.