Application Allowlisting: Windows Defender Application Control and AppLocker

Application allowlisting (formerly "whitelisting") flips the security paradigm on its head: Instead of blocking known malicious software (denylist = antivirus), only known legitimate software is allowed. All other programs are blocked—including any malware that has not yet been signed or identified. Microsoft offers two enterprise technologies: AppLocker and the more powerful WDAC.

Concept and Comparison

Allowlisting vs. Denylist (Antivirus):

Antivirus (Denylist approach):
  → "Everything allowed, except known threats"
  → Works only with known signatures
  → Zero-days: not detected → executed!
  → Fileless malware (PowerShell): no file = no scan

Allowlisting:
  → "Everything prohibited, except what is explicitly allowed"
  → Unknown malware: BLOCKED (regardless of whether signed or not)
  → LOLBin abuse: if not in policy → blocked
  → Effective against: all types of malware

Combined approach (best practice):
  → Allowlisting + EDR + SIEM
  → Allowlisting prevents execution
  → EDR detects bypass attempts
  → SIEM: Block events → Alert

AppLocker vs. WDAC:

  Feature                  AppLocker        WDAC
  ─────────────────────────────────────────────────
  Windows Edition          Pro/Enterprise   Enterprise
  Kernel-Level             No             Yes (HSP)
  Bypass Resistance         Low          High
  Virtualization-Based     No             Yes (optional)
  PowerShell              Partial        Yes (AMSI)
  LoLBins Blocking         Difficult        Easier
  Management               GPO, Intune      GPO, Intune, CI
  Compatibility           Windows 7+       Windows 10 1903+
  Recommendation               Legacy Environments    New Deployments

WDAC (Windows Defender Application Control)

Create WDAC Policy:

Policy Types:
  Base Policy:    Main policy (one per device, up to 32 in HVCI)
  Supplemental:   Supplemental policy (for applications)
  Signed:         Cryptographically signed (tamper-proof!)

Getting Started: Use the default policy as a basis:
  # Windows PowerShell (Admin):
  # Allow all Microsoft-signed files:
  New-CIPolicy -Level Publisher `
    -FilePath C:\Policies\BasePolicy.xml `
    -UserPEs `
    -MultiplePolicyFormat
  # -Level Publisher: all files with a valid Microsoft certificate
  # -MultiplePolicyFormat: WDAC Multi-Policy Support (Windows 10 1903+)

Audit Mode (Recommendation: always start here!):
  # Deploy policy in audit mode → no blocking, logging only:
  # In XML: Change <Option>0 Enabled:UMCI</Option> → not present = Audit
  ConvertFrom-CIPolicy -XmlFilePath C:\Policies\BasePolicy.xml `
    -BinaryFilePath C:\Policies\BasePolicy.bin

  # Deploy policy:
  CopyItem C:\Policies\BasePolicy.bin `
    -Destination C:\Windows\System32\CodeIntegrity\SIPolicyP.p7b -Force
  citool.exe --update-policy C:\Policies\BasePolicy.bin

  # Check audit events (Event ID 3076 = Audit Block):
  Get-WinEvent -LogName &quot;Microsoft-Windows-CodeIntegrity/Operational&quot; |
    Where Id -eq 3076 |
    Select -First 20 |
    Format-List TimeCreated, Message

Policy Levels:
  Hash:       Exact hash (SHA256) of the file → safest option
  FileName:   File name → easy to forge (not recommended on its own)
  FilePath:   Location → manipulable
  Publisher:  Publisher certificate → practical, slightly less secure than hash
  PCA:        Product Family CA (all Microsoft products)
  SignedVersion: Publisher + minimum version → prevents downgrade attacks

Fallback Level:
  # Publisher + Hash as fallback:
  New-CIPolicy -Level Publisher -Fallback Hash ...
  # If no certificate: Use hash

Practical Policy Configuration

WDAC Wizard (GUI tool from Microsoft):

  Download: https://webapp-wdac-wizard.azurewebsites.net/
  → Export as XML → convert → deploy

Add custom rules (Managed Installer):
  # Managed Installer: Jamf, Intune, SCCM are allowed to install software
  # All apps installed via SCCM/Intune are automatically allowed!

  # Configure SCCM as a Managed Installer:
  $policyFile = "C:\Policies\BasePolicy.xml"
  $sccmRule = New-CIPolicyRule -DriverFilePath `
    "C:\Windows\CCM\CcmExec.exe" `
    -Level Publisher
  Merge-CIPolicy -PolicyPaths $policyFile `
    -OutputFilePath $policyFile `
    -Rules $sccmRule

Specific App Rule (custom application):
  # Generate rule from running application:
  $Rules = Get-SystemDriver -ScanPath "C:\Program Files\MyApp" `
    -UserPEs -NoScript
  New-CIPolicy -MultiplePolicyFormat `
    -FilePath C:\Policies\MyApp-Supplemental.xml `
    -Rules $Rules

  # As a supplemental policy:
  Set-CIPolicyIdInfo -FilePath C:\Policies\MyApp-Supplemental.xml `
    -SupplementsBasePolicyID "BasePolicy-GUID"

Control PowerShell scripting:
  # WDAC + PowerShell Constrained Language Mode:
  # When WDAC User-Mode Code Integrity is enabled:
  → PowerShell runs automatically in CLM!
  → COM objects and .NET reflection are blocked
  → Most PowerShell-based attacks fail!

  # Configure PowerShell 7 (pwsh.exe) separately:
  # WDAC applies to pwsh.exe just as it does to powershell.exe

AppLocker (Legacy, for older environments)

AppLocker GPO configuration:

Rule types:
  Executable (.exe, .com):  Main applications
  Windows Installer (.msi, .msp, .mst): Installers
  Scripts (.ps1, .bat, .cmd, .vbs, .js): Scripts
  DLL (.dll, .ocx): Libraries (Performance impact!)
  Packaged Apps (AppX): Windows Store Apps

Default Rules:
  # Computer Config → Windows Settings → Security Settings
  # → Application Control Policies → AppLocker

  # Automatically generated default rules:
  # Allow: All in %PROGRAMFILES% (Publisher or Hash)
  # Allow: All in %WINDIR% (Publisher or Hash)
  # Allow: BUILTIN\Administrators: everything
  # Deny: All others (implicitly)

Publisher rule (recommended):
  # Allow: all Adobe products starting with version 23.0:
  # Rule: Publisher = "O=ADOBE SYSTEMS INCORPORATED"
  #       Min version = 23.0.0.0

Hash rule (for unsigned software):
  # SHA256 hash of the file → exact version required
  # When updating: new rule required!
  Get-AppLockerFileInformation -Path "C:\Program Files\MyApp\app.exe" |
    New-AppLockerPolicy -RuleType Hash -User Everyone -Xml

Path rule (Caution!):
  # Allows: everything in C:\MyApps\
  # Risk: An attacker writes their own EXE to this path!
  # Only if write access to the path is controlled!

AppLocker in Enforcement Mode:
  # GPO → AppLocker Properties → Enforcement:
  # Configured = Enforce Rules
  # (Default: Audit Only)

  # Quick check to see if AppLocker is active:
  Get-AppLockerPolicy -Effective | Format-List
  Get-Service AppIDSvc | Select Status  # Running = active

LOLBin Blocking

Block Living-Off-the-Land binaries via WDAC:

Frequently abused LOLBins:
  mshta.exe       → HTML Application Host (WDAC: block!)
  wscript.exe     → Windows Script Host
  cscript.exe     → Windows Script Host (CLI)
  regsvr32.exe    → DLL registration (Squiblydoo)
  msbuild.exe     → Compile .NET code from XML
  installutil.exe → .NET Installer
  rundll32.exe    → DLL execution (use with caution!)

WDAC Policy: Block LOLBins:
  # Deny rules for specific LOLBins:
  $DenyRules = @()

  # Block mshta.exe:
  $DenyRules += New-CIPolicyRule -DriverFilePath `
    "C:\Windows\System32\mshta.exe" `
    -Deny -Level Hash

  # Caution with rundll32.exe and regsvr32.exe:
  # → Used by Windows itself!
  # → Better: use WDAC audit to identify what must be allowed

  New-CIPolicy -FilePath C:\Policies\LOLBin-Deny.xml `
    -Rules $DenyRules `
    -MultiplePolicyFormat

Microsoft Recommended Block Rules:
  → WDAC Wizard contains recommended block rules
  → URL: docs.microsoft.com/windows/security/threat-protection/windows-defender-application-control/microsoft-recommended-block-rules
  → Includes: mshta, wscript, regsvr32 (script mode), installutil, etc.
  → Use as a starting point, then customize

Script Enforcement (WDAC):
  # All PowerShell scripts must be signed:
  # Policy option: Enabled:Require WHQL → Scripts must be allowed by WDAC
  # PowerShell 5: AMSI integration → WDAC check during script execution

Migration and Rollout

Phased rollout (important! Ensure productivity):

Phase 1 - Inventory (4 weeks):
  → Deploy WDAC in audit mode
  → Collect Event ID 3076: what is running in the organization?
  → Tools: WDAC Policy Wizard → Audit Report
  → Identify: standard software, custom apps, special cases

  # Audit events in SIEM (all 3076 events):
  Get-WinEvent -ComputerName (Get-ADComputer -Filter *).Name `
    -LogName "Microsoft-Windows-CodeIntegrity/Operational" `
    -FilterHashtable @{Id=3076} |
    Select TimeCreated, Message |
    Export-Csv audit-results.csv

Phase 2 - Policy Creation (2 weeks):
  → Base Policy: Standard Software (Publisher Rules)
  → Supplemental Policies: Department-specific software
  → Managed Installer: Intune/SCCM as trusted installer

Phase 3 - Pilot Group (4 weeks):
  → 20-30 IT employees as pilot
  → Enforcement mode (no audit!)
  → Helpdesk hotline for exceptions
  → Policy adjustments based on feedback

Phase 4 - Department-by-department rollout (8–12 weeks):
  → Stable departments first (Accounting, HR)
  → Critical workstations (developers): separate, extended policy
  → Exception process: fast (max. 24 hours for new software)

Exception process:
  1. Employee reports: "Software X is being blocked"
  2. IT checks: legitimate? Security check?
  3. Supplemental policy → Deployment via Intune
  4. SLA: 24 hours for standard software, 4 hours for critical systems

KPIs after rollout:
  □ Block events per day (should decrease after initial phase)
  □ Reported issues (should be under 5/week)
  □ Malware incidents (expectation: 0 after full rollout)
  □ Exceptions per month (indicates policy quality)