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

Antivirus (Denylist-Ansatz): Alles ist erlaubt, außer bekannte Schadprogramme. Das Verfahren funktioniert nur bei bekannten Signaturen - Zero-Days werden nicht erkannt und ausgeführt. Fileless Malware wie PowerShell-basierte Angriffe erzeugen keine Datei und werden daher nicht gescannt.

Allowlisting: Alles ist verboten, außer explizit Erlaubtem. Unbekannte Malware wird geblockt, egal ob signiert oder nicht. LOLBin-Missbrauch scheitert, wenn das Binary nicht in der Policy enthalten ist. Das Verfahren ist effektiv gegen alle Malware-Typen.

Der kombinierte Ansatz als Best Practice kombiniert Allowlisting mit EDR und SIEM: Allowlisting verhindert die Ausführung, EDR erkennt Umgehungsversuche, SIEM erzeugt Alerts bei Block-Events.

Vergleich AppLocker vs. WDAC:

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

WDAC (Windows Defender Application Control)

WDAC kennt drei Policy-Typen: Base Policy als Hauptrichtlinie (eine pro Gerät, bis zu 32 in HVCI), Supplemental Policy als Ergänzungsrichtlinie für Applikationen und Signed Policy als kryptografisch signierte, manipulationssichere Variante.

# Alle Microsoft-signierten Dateien erlauben (Einstieg):
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+)

# Policy im Audit-Modus deployen (immer zuerst!):
ConvertFrom-CIPolicy -XmlFilePath C:\Policies\BasePolicy.xml `
  -BinaryFilePath C:\Policies\BasePolicy.bin
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 prüft den exakten SHA256-Hash der Datei und ist die sicherste Option. FileName und FilePath sind leicht zu fälschen oder zu manipulieren. Publisher verwendet das Herstellerzertifikat und ist praktisch. SignedVersion kombiniert Publisher mit einer Mindestversion und verhindert Downgrade-Angriffe. Als Fallback-Strategie empfiehlt sich die Kombination Publisher + Hash.

Praktische Policy-Konfiguration

Der WDAC Wizard (GUI-Tool von Microsoft) unter webapp-wdac-wizard.azurewebsites.net ermöglicht den Export als XML zur anschließenden Konvertierung und Deployment. Für den Managed-Installer-Ansatz können SCCM und Intune als vertrauenswürdige Installer konfiguriert werden, sodass alle via SCCM oder Intune installierten Apps automatisch erlaubt sind.

Für eigene Anwendungen werden Supplemental-Policies erstellt: Die Policy-ID der Base-Policy wird als SupplementsBasePolicyID angegeben, sodass die Ergänzungsrichtlinie nur in Kombination mit der Basis gilt.

Wenn WDAC User-Mode-Code-Integrity aktiv ist, läuft PowerShell automatisch im Constrained Language Mode (CLM). COM-Objekte und .NET-Reflection sind dann blockiert, wodurch die meisten PowerShell-basierten Angriffe scheitern. Das gilt für PowerShell 5 wie auch für PowerShell 7 (pwsh.exe).

AppLocker (Legacy, für ältere Umgebungen)

AppLocker unterscheidet fünf Regeltypen: Executable (.exe, .com) für Hauptanwendungen, Windows Installer (.msi, .msp, .mst) für Installer, Scripts (.ps1, .bat, .cmd, .vbs, .js), DLL (.dll, .ocx) mit Performance-Auswirkungen und Packaged Apps (AppX) für Windows Store Apps.

# Hash-Regel für unsignierte Software:
Get-AppLockerFileInformation -Path "C:\Program Files\MyApp\app.exe" |
  New-AppLockerPolicy -RuleType Hash -User Everyone -Xml
# Bei jedem Update muss eine neue Regel erstellt werden!

# Enforcement-Status prüfen:
Get-AppLockerPolicy -Effective | Format-List
Get-Service AppIDSvc | Select Status  # Running = aktiv

Publisher-Regeln sind die empfohlene Methode: Sie erlauben alle Adobe-Produkte ab einer bestimmten Mindestversion anhand des Herstellerzertifikats. Path-Regeln sind zu vermeiden, wenn der Angreifer Schreibzugriff auf den entsprechenden Pfad haben könnte.

LOLBin-Blocking

Living-Off-the-Land Binaries (LOLBins) sind legitime Windows-Tools, die von Angreifern missbraucht werden. Häufig missbraucht werden mshta.exe (HTML-Application-Host), wscript.exe und cscript.exe (Windows Script Host), regsvr32.exe (DLL-Registrierung, Squiblydoo), msbuild.exe (.NET-Code aus XML kompilieren), installutil.exe (.NET-Installer) und rundll32.exe (DLL-Ausführung, Vorsicht: wird von Windows selbst genutzt).

Microsoft empfiehlt im WDAC Wizard eine vordefinierte Block-Rules-Liste, die mshta, wscript, regsvr32 (Script-Modus) und installutil enthält. Diese dient als Startpunkt und sollte angepasst werden.

Migration und Rollout

Ein schrittweiser Rollout ist entscheidend um die Produktivität zu sichern.

Phase 1 - Inventarisierung (4 Wochen): WDAC im Audit-Mode deployen und Event-ID-3076-Events sammeln, um zu erfassen was im Unternehmen läuft. Standardsoftware, Custom-Apps und Sonderfälle identifizieren.

Phase 2 - Policy-Erstellung (2 Wochen): Base-Policy für Standardsoftware mit Publisher-Regeln erstellen. Supplemental-Policies für abteilungsspezifische Software anlegen. Intune oder SCCM als Managed Installer konfigurieren.

Phase 3 - Pilot-Gruppe (4 Wochen): 20-30 IT-Mitarbeiter im Enforcement-Mode (kein Audit). Helpdesk-Hotline für Ausnahmen bereitstellen und Policy basierend auf Feedback anpassen.

Phase 4 - Rollout abteilungsweise (8-12 Wochen): Stabile Abteilungen wie Buchhaltung und HR zuerst. Entwickler erhalten eine separate, erweiterte Policy. SLA für neue Software: maximal 24 Stunden für Standardsoftware, 4 Stunden für kritische Systeme.

KPIs nach Rollout:

• Block-Events pro Tag (sollte nach der Anlaufphase sinken)
• Gemeldete Probleme (Ziel: unter 5 pro Woche)
• Malware-Incidents (Erwartung: 0 bei vollständigem Rollout)
• Ausnahmen pro Monat (zeigt die Policy-Qualität)