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:
<RuleCollection Type="Exe" EnforcementMode="AuditOnly">
<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>
<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
| Term | Definition |
|---|
| Application Whitelisting | Security model that allows only pre-approved applications to execute, denying everything else by default |
| Publisher Rule | AppLocker rule based on digital signature; most resilient to application updates |
| Path Rule | AppLocker rule based on file system path; less secure as attackers can place files in allowed paths |
| Hash Rule | AppLocker rule based on file hash; most restrictive but breaks on every application update |
| LOLBin | Living Off the Land Binary; legitimate OS tool abused by attackers to avoid detection |
| Audit Mode | AppLocker logs policy violations without blocking; essential for rule refinement |
| Enforcement Mode | AppLocker actively blocks applications that violate policy rules |
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.
