Exploit-Schutz: System- und anwendungsspezifische Maßnahmen

Der Exploit-Schutz ist der Teil von Windows, der es erschwert, Speicherfehler in Codeausführung zu verwandeln. Er ist der integrierte Nachfolger von EMET (Enhanced Mitigation Experience Toolkit) und in Windows 10 1709 und neuer, Windows 11 sowie Windows Server 2019 und neuer enthalten. Während ASR-Regeln verdächtiges Verhalten blockieren (Word startet PowerShell), blockiert der Exploit-Schutz die Techniken, mit denen ein Exploit dorthin gelangt: Daten ausführen, über eine Return-Oriented-Kette springen, eine unsignierte DLL in einen gehärteten Prozess laden.

Die ASR-Säule streift ihn nur am Rande. Dieser Leitfaden deckt die gesamte Aufgabe ab: was die Standards bereits leisten, welche anwendungsspezifischen Maßnahmen sich lohnen, wie man sie im Überwachungsmodus testet und wie man eine einzige Konfiguration an die gesamte Flotte verteilt. Für das Gesamtbild des Bereichs siehe Reduzierung der Angriffsfläche.

Wie die Einstellungen aufgebaut sind

Der Exploit-Schutz hat zwei Ebenen:

• Systemeinstellungen gelten für jeden Prozess, sofern keine Anwendungseinstellung sie überschreibt.
• Programmeinstellungen gelten für eine benannte ausführbare Datei (optional mit vollständigem Pfad) und können Maßnahmen einschalten, die systemweit zu störend wären.

Jede Maßnahme kann ein, aus oder Standard verwenden sein, und mehrere unterstützen einen Überwachungszustand, der protokolliert, was blockiert worden wäre. Dieselben Einstellungen sind unter Windows Security > App & browser control > Exploit protection settings sichtbar, auf verwalteten Geräten sollten Sie sie aber über eine per Richtlinie verteilte XML-Datei steuern, nicht per Mausklick.

Die erste Aufgabe besteht schlicht darin, sicherzustellen, dass nichts davon abgeschaltet wurde. Alte Imaging-Skripte, Gaming-Tweaks und „Performance“-Anleitungen deaktivieren manchmal DEP oder CFG.

Schritt 1: Den aktuellen Zustand erfassen

Sehen Sie sich auf einem Referenzcomputer die wirksame System- und App-Konfiguration an:

# Systemweite Schutzmaßnahmen
Get-ProcessMitigation -System

# Eine einzelne Anwendung
Get-ProcessMitigation -Name winword.exe

# Alle Apps mit programmspezifischen Einstellungen
Get-ProcessMitigation | Where-Object { $_.ProcessName } |
  Select-Object ProcessName -Unique

Windows bringt bereits einige anwendungsspezifische Einstellungen mit, und eine frische Installation ist die beste Ausgangsbasis. Exportieren Sie sie, um später vergleichen zu können:

Get-ProcessMitigation -RegistryConfigFilePath C:\Temp\ep-baseline.xml

Haben Sie noch eine EMET-Richtlinie von vor Jahren, konvertieren Sie sie und behandeln Sie sie als Ideenliste, nicht als anzuwendende Konfiguration:

ConvertTo-ProcessMitigationPolicy -EMETFilePath C:\Temp\emet.xml -OutputFilePath C:\Temp\ep-from-emet.xml

Schritt 2: Anwendungsspezifische Maßnahmen auswählen

Bei den anwendungsspezifischen Maßnahmen zeigt der Exploit-Schutz seinen Wert, hier bricht er aber auch Dinge. Zielen Sie auf Anwendungen, die nicht vertrauenswürdige Eingaben verarbeiten und nicht schon stark in einer Sandbox laufen: Dokumentbetrachter, ältere Fachanwendungs-Clients, die Dateien aus E-Mails öffnen, Mediaplayer, Archivwerkzeuge und alte, aus dem Internet erreichbare Serverkomponenten, die Sie noch nicht ersetzen können.

Microsofts eigene Browser und Office aktivieren viele davon bereits intern, und Chromium-basierte Browser verwalten ihre eigene Sandbox. Setzen Sie ACG oder CIG nicht zusätzlich auf Edge oder Chrome; konfigurieren Sie stattdessen den Browser (siehe Edge-Härtung). Microsoft warnt außerdem, dass EAF, IAF und die ROP-Maßnahmen mit EDR- und Anti-Cheat-Produkten kollidieren können, die dieselben Funktionen hooken; testen Sie daher auf Geräten mit Ihrem echten Sicherheits-Stack.

Schritt 3: Im Überwachungsmodus testen

Bauen Sie die anwendungsspezifischen Einstellungen auf einem Testcomputer auf und beginnen Sie im Überwachungsmodus, wo die Maßnahme ihn unterstützt:

# ACG und Kindprozesserstellung für einen älteren Viewer überwachen
Set-ProcessMitigation -Name "C:\Program Files\Contoso\Viewer\viewer.exe" `
  -Enable AuditDynamicCode, AuditChildProcess

# Risikoarme Maßnahmen direkt erzwingen
Set-ProcessMitigation -Name viewer.exe -Enable BlockRemoteImages, BlockLowLabel

Die Parameternamen entsprechen den Maßnahmenoptionen (zum Beispiel DisallowChildProcessCreation, AuditChildProcess, DynamicCode, AuditDynamicCode, MicrosoftSignedOnly, ForceRelocateImages). Die Überwachung für EAF, IAF und die ROP-Maßnahmen ist über die PowerShell-Cmdlets nicht verfügbar; setzen Sie sie in der Windows-Sicherheit-App und exportieren Sie das XML. Führen Sie Get-Help Set-ProcessMitigation -Full auf Ihrem Build aus, um die unterstützte Liste zu sehen, denn neuere Versionen fügen Optionen hinzu.

Der Exploit-Schutz schreibt in zwei Protokolle unter Applications and Services Logs > Microsoft > Windows > Security-Mitigations: KernelMode und UserMode. Jede überwachte Maßnahme hat ein Überwachungs- und ein Erzwingungsereignis; ACG protokolliert beispielsweise 1 (Überwachung) und 2 (blockiert), die Kindprozesserstellung 3 (Überwachung) und 4 (blockiert). Die vollständige Zuordnung für Ihren Build finden Sie in Microsofts Ereignisreferenz zum Exploit-Schutz.

Get-WinEvent -LogName "Microsoft-Windows-Security-Mitigations/UserMode",
                       "Microsoft-Windows-Security-Mitigations/KernelMode" -MaxEvents 200 |
  Select-Object TimeCreated, LogName, Id, Message

Nutzen Sie die Anwendung ein bis zwei Wochen normal: Öffnen Sie die ungewöhnlichen Dateien, drucken Sie, lassen Sie die Updateprüfung laufen, verwenden Sie die Plug-ins. Keine Überwachungsereignisse bedeuten, dass die Maßnahme erzwungen werden kann. Ereignisse bei einem echten Arbeitsablauf bedeuten, dass Sie diese Maßnahme entweder abgeschaltet lassen oder den Hersteller um eine Korrektur bitten.

Schritt 4: Das XML exportieren und verteilen

Sobald sich der Testcomputer korrekt verhält, exportieren Sie die vollständige Konfiguration. Die Datei enthält System- und App-Einstellungen gemeinsam:

Get-ProcessMitigation -RegistryConfigFilePath \\corp.example\NETLOGON\ExploitProtection\ep-settings.xml

Gruppenrichtlinie. Legen Sie das XML auf eine Freigabe, die Computer lesen können, und setzen Sie dann Computer Configuration > Policies > Administrative Templates > Windows Components > Windows Defender Exploit Guard > Exploit Protection > Use a common set of exploit protection settings mit dem UNC-Pfad auf Enabled. Neuere ADMX-Dateien zeigen den Ordner möglicherweise als Microsoft Defender Exploit Guard. Die Richtlinie speichert den Pfad unter HKLM\SOFTWARE\Policies\Microsoft\Windows Defender ExploitGuard\Exploit Protection, und das Gerät wendet die Datei bei der nächsten Aktualisierung an.

Intune. Verwenden Sie Endpoint security > Attack surface reduction > Create policy > Exploit Protection und fügen Sie das XML ein oder laden Sie es hoch. Der zugrunde liegende CSP ist ExploitGuard/ExploitProtectionSettings.

Sperren. Unterbinden Sie lokale Änderungen über die Windows-Sicherheit-App mit Computer Configuration > Policies > Administrative Templates > Windows Components > Windows Security > App and browser protection > Prevent users from modifying settings (in Intune die Einstellung Disallow Exploit Protection Override im selben Profil).

Behandeln Sie das XML wie Code: Halten Sie es in der Versionsverwaltung, ändern Sie es per Pull Request und rollen Sie es ringweise aus, wie Sie es mit ASR-Regeln oder einer Sicherheitsbaseline tun würden.

Was kaputtgeht

• Mandatory ASLR systemweit ist der klassische selbstverschuldete Ausfall: Alte Installationsprogramme und DLLs ohne Relokationsdaten stürzen beim Laden ab. Belassen Sie es pro App.
• CIG und ACG bei Apps mit Plug-ins oder JIT schlagen stillschweigend fehl oder stürzen bei der ersten Nutzung des Plug-ins ab.
• Do not allow child processes verhindert, dass die App für Hilfelinks einen Browser öffnet, ihren Updater startet oder einen PDF-Drucker aufruft.
• Disable extension points bricht ostasiatische Eingabemethoden und manche Barrierefreiheitswerkzeuge.
• EAF/IAF und ROP-Maßnahmen können mit EDR-Hooks kollidieren. Das Symptom ist ein Absturz in der DLL des Sicherheitsprodukts, nicht in der App.
• Hardware-enforced stack protection funktioniert nur auf CET-fähigen CPUs und blockiert im strikten Modus inkompatible DLLs, die in den Prozess geladen werden.

Wenn nach dem Rollout etwas bricht, zeigt Get-ProcessMitigation -Name app.exe auf dem betroffenen Gerät, was tatsächlich angewendet ist, und die Security-Mitigations-Protokolle zeigen, welche Maßnahme ausgelöst hat.

Überprüfen

Auf einer Stichprobe von Geräten nach der Richtlinienaktualisierung:

# Systemstandards intakt
Get-ProcessMitigation -System | Format-List DEP, ASLR, CFG, SEHOP, Heap

# Ihre anwendungsspezifischen Einstellungen angewendet
Get-ProcessMitigation -Name viewer.exe

# Richtlinienpfad vorhanden
Get-ItemProperty "HKLM:\SOFTWARE\Policies\Microsoft\Windows Defender ExploitGuard\Exploit Protection" -ErrorAction SilentlyContinue

Leiten Sie beide Security-Mitigations-Protokolle an Ihr SIEM weiter. Eine plötzliche Häufung von Erzwingungsereignissen auf einem Host ist entweder ein fehlerhaftes Update oder ein Ausnutzungsversuch, und beides verdient einen Blick.

Einordnung

Der Exploit-Schutz ist eine Ebene der Speichersicherheit. Auf Kernelseite schützen Speicherintegrität (HVCI) und VBS den Kernel vor derselben Angriffsklasse, und unter Windows 11 mit HVCI und einer CET-fähigen CPU können Sie außerdem den hardwaregestützten Stapelschutz im Kernelmodus unter Windows Security > Device security > Core isolation aktivieren. Darüber entscheidet die Anwendungssteuerung, was überhaupt ausgeführt werden darf. Zum Begriff selbst siehe den Glossareintrag Exploit-Schutz.

Checkliste

• Systemmaßnahmen (DEP, CFG, Bottom-up- und High-Entropy-ASLR, SEHOP, Heap-Integrität) flottenweit als aktiv bestätigt
• Exponierte ältere Apps identifiziert und anwendungsspezifische Maßnahmen gewählt
• Maßnahmen im Überwachungsmodus getestet, Security-Mitigations-Ereignisse ausgewertet
• XML exportiert, versioniert und per GPO oder Intune verteilt
• Lokales Überschreiben mit Prevent users from modifying settings blockiert
• Security-Mitigations-Protokolle weitergeleitet und mit Alarmierung versehen