Application Allowlisting: Windows Defender Application Control und AppLocker

Application Allowlisting (früher “Whitelisting”) dreht das Sicherheitsparadigma um: Statt bekannte schlechte Software zu blockieren (Denylist = Antivirus), wird nur bekannte gute Software erlaubt. Alle anderen Programme werden geblockt - einschließlich jeder Malware die noch nicht signiert oder bekannt ist. Microsoft bietet zwei Enterprise-Technologien: AppLocker und das leistungsfähigere WDAC.

Konzept und Vergleich

Allowlisting vs. Denylist (Antivirus):

Antivirus (Denylist-Ansatz):
  → "Alles erlaubt, außer bekannte Böse"
  → Funktioniert nur bei bekannten Signaturen
  → Zero-Days: nicht erkannt → ausgeführt!
  → Fileless Malware (PowerShell): kein File = kein Scan

Allowlisting:
  → "Alles verboten, außer explizit Erlaubtes"
  → Unbekannte Malware: GEBLOCKT (egal ob signiert oder nicht)
  → LOLBin-Missbrauch: wenn nicht in Policy → geblockt
  → Effektiv gegen: alle Malware-Typen

Kombinierter Ansatz (Best Practice):
  → Allowlisting + EDR + SIEM
  → Allowlisting verhindert Ausführung
  → EDR erkennt Umgehungsversuche
  → SIEM: Block-Events → Alert

AppLocker vs. WDAC:

  Feature                  AppLocker        WDAC
  ─────────────────────────────────────────────────
  Windows Edition          Pro/Enterprise   Enterprise
  Kernel-Level             Nein             Ja (HSP)
  Bypass-Resistenz         Niedrig          Hoch
  Virtualization-Based     Nein             Ja (optional)
  PowerShell              Teilweise        Ja (AMSI)
  LoLBins-Blocking         Schwierig        Einfacher
  Management               GPO, Intune      GPO, Intune, CI
  Kompatibilität           Windows 7+       Windows 10 1903+
  Empfehlung               Legacy-Umgeb.    Neue Deployments

WDAC (Windows Defender Application Control)

WDAC Policy erstellen:

Policy-Typen:
  Base Policy:    Hauptrichtlinie (eine pro Gerät, bis zu 32 in HVCI)
  Supplemental:   Ergänzungsrichtlinie (für Applikationen)
  Signed:         Kryptografisch signiert (manipulationssicher!)

Einstieg: Default-Policy als Basis:
  # Windows-PowerShell (Admin):
  # Alle Microsoft-signierten Dateien erlauben:
  New-CIPolicy -Level Publisher `
    -FilePath C:\Policies\BasePolicy.xml `
    -UserPEs `
    -MultiplePolicyFormat
  # -Level Publisher: alle Dateien mit gültigem Microsoft-Zertifikat
  # -MultiplePolicyFormat: WDAC Multi-Policy Support (Windows 10 1903+)

Audit Mode (Empfehlung: immer zuerst!):
  # Policy im Audit-Modus deployen → kein Blocking, nur Logging:
  # In XML: Change <Option>0 Enabled:UMCI</Option> → nicht vorhanden = Audit
  ConvertFrom-CIPolicy -XmlFilePath C:\Policies\BasePolicy.xml `
    -BinaryFilePath C:\Policies\BasePolicy.bin

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

  # Audit-Events prüfen (Event ID 3076 = Audit Block):
  Get-WinEvent -LogName "Microsoft-Windows-CodeIntegrity/Operational" |
    Where Id -eq 3076 |
    Select -First 20 |
    Format-List TimeCreated, Message

Regel-Ebenen (Level):
  Hash:       Exakter Hash (SHA256) der Datei → sicherste Option
  FileName:   Dateiname → leicht zu fälschen (nicht empfohlen allein)
  FilePath:   Speicherort → manipulierbar
  Publisher:  Herstellerzertifikat → praktisch, etwas weniger sicher als Hash
  PCA:        Produktfamilien-CA (alle Microsoft-Produkte)
  SignedVersion: Publisher + Mindestversion → verhindert Downgrade-Angriffe

Fallback-Ebene (Fallback Level):
  # Publisher + Hash als Fallback:
  New-CIPolicy -Level Publisher -Fallback Hash ...
  # Wenn kein Zertifikat: Hash verwenden

Praktische Policy-Konfiguration

WDAC Wizard (GUI-Tool von Microsoft):

  Download: https://webapp-wdac-wizard.azurewebsites.net/
  → Export als XML → konvertieren → deployen

Eigene Regeln hinzufügen (Managed Installer):
  # Managed Installer: Jamf, Intune, SCCM darf Software installieren
  # Alle via SCCM/Intune installierten Apps automatisch erlaubt!

  # SCCM als Managed Installer konfigurieren:
  $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-Regel (eigene Anwendung):
  # Regel aus laufender Anwendung generieren:
  $Rules = Get-SystemDriver -ScanPath "C:\Program Files\MyApp" `
    -UserPEs -NoScript
  New-CIPolicy -MultiplePolicyFormat `
    -FilePath C:\Policies\MyApp-Supplemental.xml `
    -Rules $Rules

  # Als Supplemental-Policy:
  Set-CIPolicyIdInfo -FilePath C:\Policies\MyApp-Supplemental.xml `
    -SupplementsBasePolicyID "BasePolicy-GUID"

PowerShell-Scripting steuern:
  # WDAC + PowerShell Constrained Language Mode:
  # Wenn WDAC User-Mode-Code-Integrity aktiv:
  → PowerShell läuft automatisch in CLM!
  → COM-Objekte, .NET-Reflection blockiert
  → Meisten PowerShell-basierten Angriffe scheitern!

  # PowerShell 7 (pwsh.exe) separat regeln:
  # WDAC gilt für pwsh.exe genauso wie für powershell.exe

AppLocker (Legacy, für ältere Umgebungen)

AppLocker GPO-Konfiguration:

Regeltypen:
  Executable (.exe, .com):  Hauptanwendungen
  Windows Installer (.msi, .msp, .mst): Installer
  Scripts (.ps1, .bat, .cmd, .vbs, .js): Scripts
  DLL (.dll, .ocx): Bibliotheken (Performance-Impact!)
  Packaged Apps (AppX): Windows Store Apps

Standard-Regeln (Default):
  # Computer Config → Windows Settings → Security Settings
  # → Application Control Policies → AppLocker

  # Automatisch generierte Default-Regeln:
  # Allow: Alle in %PROGRAMFILES% (Publisher oder Hash)
  # Allow: Alle in %WINDIR% (Publisher oder Hash)
  # Allow: BUILTIN\Administrators: alles
  # Deny: Alle anderen (implizit)

Publisher-Regel (empfohlen):
  # Erlaubt: alle Adobe-Produkte ab Version 23.0:
  # Rule: Publisher = "O=ADOBE SYSTEMS INCORPORATED"
  #       Min version = 23.0.0.0

Hash-Regel (für unsignierte Software):
  # SHA256-Hash der Datei → exakte Version erforderlich
  # Bei Update: neue Regel nötig!
  Get-AppLockerFileInformation -Path "C:\Program Files\MyApp\app.exe" |
    New-AppLockerPolicy -RuleType Hash -User Everyone -Xml

Path-Regel (Vorsicht!):
  # Erlaubt: alles in C:\MyApps\
  # Risiko: Angreifer schreibt eigene EXE in diesen Pfad!
  # Nur wenn Schreibzugriff auf Pfad kontrolliert!

AppLocker im Enforcement-Modus:
  # GPO → AppLocker Properties → Enforcement:
  # Configured = Enforce Rules
  # (Standard: Audit Only)

  # Schnell-Check ob AppLocker aktiv:
  Get-AppLockerPolicy -Effective | Format-List
  Get-Service AppIDSvc | Select Status  # Running = aktiv

LOLBin-Blocking

Living-Off-the-Land Binaries via WDAC blockieren:

Häufig missbrauchte LOLBins:
  mshta.exe       → HTML-Application-Host (WDAC: blockieren!)
  wscript.exe     → Windows Script Host
  cscript.exe     → Windows Script Host (CLI)
  regsvr32.exe    → DLL-Registrierung (Squiblydoo)
  msbuild.exe     → .NET-Code aus XML kompilieren
  installutil.exe → .NET-Installer
  rundll32.exe    → DLL-Ausführung (vorsichtig!)

WDAC-Policy: LOLBins blockieren:
  # Deny-Rules für spezifische LOLBins:
  $DenyRules = @()

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

  # Vorsicht bei rundll32.exe und regsvr32.exe:
  # → werden von Windows selbst genutzt!
  # → Besser: über WDAC-Audit identifizieren was erlaubt sein muss

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

Microsoft Recommended Block Rules:
  → WDAC Wizard enthält empfohlene Block-Rules
  → Url: docs.microsoft.com/windows/security/threat-protection/windows-defender-application-control/microsoft-recommended-block-rules
  → Enthält: mshta, wscript, regsvr32 (script-Modus), installutil, etc.
  → Als Startpunkt nutzen, dann anpassen

Script-Enforcement (WDAC):
  # Alle PowerShell-Scripts müssen signiert sein:
  # Policy-Option: Enabled:Require WHQL → Scripts müssen von WDAC erlaubt sein
  # PowerShell 5: AMSI-Integration → WDAC-Prüfung bei Scriptausführung

Migration und Rollout

Schrittweiser Rollout (wichtig! Produktivität sichern):

Phase 1 - Inventarisierung (4 Wochen):
  → WDAC im Audit-Mode deployen
  → Event ID 3076 sammeln: was läuft im Unternehmen?
  → Tools: WDAC Policy Wizard → Audit-Report
  → Identifizieren: Standardsoftware, Custom-Apps, Sonderfälle

  # Audit-Events in SIEM (alle 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-Erstellung (2 Wochen):
  → Base-Policy: Standardsoftware (Publisher-Regeln)
  → Supplemental-Policies: Abteilungs-spezifische Software
  → Managed-Installer: Intune/SCCM als vertrauenswürdiger Installer

Phase 3 - Pilot-Gruppe (4 Wochen):
  → 20-30 IT-Mitarbeiter als Pilot
  → Enforcement-Mode (kein Audit!)
  → Helpdesk-Hotline für Ausnahmen
  → Policy-Anpassungen based on Feedback

Phase 4 - Rollout abteilungsweise (8-12 Wochen):
  → Stabile Abteilungen zuerst (Buchhaltung, HR)
  → Kritische Workstations (Entwickler): separate, erweiterte Policy
  → Ausnahme-Prozess: schnell (max. 24h für neue Software)

Ausnahme-Prozess:
  1. Mitarbeiter meldet: "Software X wird geblockt"
  2. IT prüft: legitim? Sicherheitsprüfung?
  3. Supplemental-Policy → Deployment via Intune
  4. SLA: 24h für Standardsoftware, 4h für kritische Systeme

KPIs nach Rollout:
  □ Block-Events pro Tag (sollte sinken nach Anlauf)
  □ Gemeldete Probleme (sollte unter 5/Woche)
  □ Malware-Incidents (Erwartung: 0 bei vollständigem Rollout)
  □ Ausnahmen pro Monat (zeigt Policy-Qualität)