Microsoft-Sperrliste für anfällige Treiber: BYOVD stoppen

Zum Laden eines Kerneltreibers braucht man Administratorrechte und eine gültige Signatur. Angreifer, die bereits Adminrechte haben, wollen in den Kernel, denn von dort aus können sie EDR-Prozesse beenden, LSASS den LSA-Schutz entziehen oder den Manipulationsschutz abschalten. Einen bösartigen Treiber können sie nicht signieren, also bringen sie einen legitim signierten mit einer bekannten Schwachstelle mit, laden ihn und nutzen ihn aus. Das ist Bring Your Own Vulnerable Driver (BYOVD), und so funktionieren die meisten „EDR-Killer“-Werkzeuge, die Ransomware-Affiliates einsetzen.

Die Microsoft-Sperrliste für anfällige Treiber ist eine App-Control-Richtlinie, die das Laden bekanntermaßen anfälliger und bösartiger Treiber verweigert. Microsoft pflegt sie gemeinsam mit Hardwareherstellern und liefert sie mit Windows aus. Dieser Leitfaden geht tiefer als die Erwähnung im Grundlagenleitfaden zu App Control: wie Sie bestätigen, dass sie aktiv ist, wie Sie sie aktuell halten und wie Sie mit den Lücken umgehen.

Was die Sperrliste ist und was nicht

Sie ist keine vollständige Treiber-Allowlist. Ein anfälliger Treiber, den Microsoft noch nicht aufgenommen hat, wird geladen. Deshalb ist die Sperrliste eine Basis, die mit Erkennung und auf besonders wertvollen Systemen mit einer vollständigen App-Control-Richtlinie kombiniert werden sollte.

Schritt 1: den aktuellen Zustand prüfen

Auf einem einzelnen Rechner zeigt die Windows-Sicherheit sie unter Gerätesicherheit > Details zur Kernisolierung > Microsoft-Sperrliste für anfällige Treiber. Ist Speicherintegrität, Smart App Control oder der S-Modus aktiv, ist der Schalter eingeschaltet und ausgegraut, weil diese Funktionen die Sperrliste immer erzwingen.

Hinter dem Schalter steckt ein Registrierungswert:

Get-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Control\CI\Config" -Name VulnerableDriverBlocklistEnable

1 bedeutet aktiviert. Prüfen Sie außerdem, ob die Speicherintegrität läuft, denn sie garantiert die Erzwingung:

(Get-CimInstance -Namespace root\Microsoft\Windows\DeviceGuard `
  -ClassName Win32_DeviceGuard).SecurityServicesRunning   # 2 = Speicherintegrität (HVCI)

Erfassen Sie flottenweit beide Werte mit Ihrem Managementwerkzeug, einer Erweiterung des Hardwareinventars von Configuration Manager oder einem Intune-Wartungsskript im reinen Erkennungsmodus. Konzentrieren Sie sich zuerst auf Windows Server: Per In-Place-Upgrade aktualisierte Server und VMs ohne virtualisierungsbasierte Sicherheit sind die üblichen Lücken.

Schritt 2: dort aktivieren, wo sie ausgeschaltet ist

Die einfachste Lösung ist, die Speicherintegrität (HVCI) einzuschalten. Sie bringt die Sperrliste mit und blockiert eine breitere Klasse von Kernelangriffen. Wo HVCI noch nicht möglich ist (inkompatible Treiber, ältere Hardware), setzen Sie die Sperrliste für sich allein:

Set-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Control\CI\Config" `
  -Name VulnerableDriverBlocklistEnable -Value 1 -Type DWord

Verteilen Sie diesen Wert mit einem Registrierungselement der Gruppenrichtlinieneinstellungen (Group Policy Preferences) oder einer Intune-Wartung und starten Sie neu: Die Treiberrichtlinie wird beim Start ausgewertet. Auf Builds, in denen der Schalter nicht existiert, verteilen Sie die Sperrliste stattdessen als App-Control-Richtlinie (nächster Schritt).

Schritt 3: zwischen Windows-Releases aktuell bleiben

Die mit Windows ausgelieferte Kopie hinkt der von Microsoft veröffentlichten Liste hinterher. Microsoft bietet die neueste Sperrliste zum Download an (verlinkt auf der Seite „Microsoft recommended driver block rules“ in der App-Control-Dokumentation), sowohl als XML als auch in Binärform, jeweils in einer Überwachungs- und einer Erzwingungsvariante.

Es gibt zwei Einsatzwege:

1. Eigenständig: Die von Microsoft dokumentierte Methode besteht darin, die Überwachungs- oder Erzwingungs-Binärdatei in SiPolicy.p7b umzubenennen, sie nach %windir%\System32\CodeIntegrity zu kopieren und das Aktualisierungstool für App-Control-Richtlinien auszuführen (oder neu zu starten). Testen Sie zuerst die Überwachungsversion in einem Pilotring. Dieser Dateiname ist der Platz für eine Einzelrichtlinie; er ersetzt also jede vorhandene Richtlinie im Einzelrichtlinienformat auf dem Gerät. Unterstützt das Gerät mehrere Richtlinien, empfiehlt Microsoft, die Sperrliste stattdessen neben Ihren vorhandenen Richtlinien bereitzustellen, etwa indem Sie das veröffentlichte XML (hier DriverBlockRules.xml) in eine .cip-Datei konvertieren und diese ab Windows 11 22H2 mit CiTool anwenden:

   PowerShell

   Copy-Item .\DriverBlockRules.xml .\DriverBlock.xml
   Set-CIPolicyIdInfo -FilePath .\DriverBlock.xml -ResetPolicyID   # Mehrfachrichtlinienformat, neue ID
   ConvertFrom-CIPolicy -XmlFilePath .\DriverBlock.xml -BinaryFilePath .\DriverBlock.cip
   CiTool.exe --update-policy .\DriverBlock.cip
   CiTool.exe --list-policies

   Bereits laufende Treiber werden erst nach einem Neustart blockiert.

2. In Ihre App-Control-Basisrichtlinie integriert: Wenn Sie App Control bereits erzwingen, führen Sie das veröffentlichte XML mit Ihrer Basis zusammen. Das veröffentlichte XML enthält Regeln, die alles zulassen, damit es eigenständig laufen kann; entfernen Sie diese Regeln vor dem Zusammenführen mit einer Allowlist-Richtlinie, sonst öffnen Sie Ihre Allowlist vollständig.

   PowerShell

   Merge-CIPolicy -PolicyPaths .\Base.xml, .\DriverBlockRules.xml -OutputFilePath .\Base-merged.xml

Für welchen Weg Sie sich auch entscheiden: Tragen Sie eine wiederkehrende Aufgabe in Ihren Änderungskalender ein und prüfen Sie jedes Quartal sowie nach größeren BYOVD-Enthüllungen die veröffentlichte Version.

Schritt 4: ASR-Regel und Erkennung ergänzen

Die Sperrliste verhindert, dass ein Treiber geladen wird. Zwei weitere Schichten helfen:

• ASR-Regel „Block abuse of exploited vulnerable signed drivers“ (GUID 56a863a9-875e-4185-98a7-b882c64b5ce5) verhindert, dass Anwendungen bekannte anfällige Treiber auf den Datenträger schreiben. Setzen Sie sie auf Blockieren; sie gehört zum Standardschutzsatz, der im Leitfaden zu ASR-Regeln beschrieben ist.
• Erkennung beim Laden von Treibern. Sysmon-Ereignis 6 (Treiber geladen) zeichnet Hash und Signatur jedes Treibers auf. Vergleichen Sie neue Hashes mit Ihrem Inventar bekannt guter Treiber und mit Community-Listen wie LOLDrivers. Ereignis 7045 im Systemprotokoll (ein Dienst wurde installiert) erfasst die Diensterstellung, die einem Treiberladevorgang meist vorausgeht.

Treiber aus echten BYOVD-Angriffen sind oft alte, legitim signierte Hilfsprogramme: Übertaktungstools, Firmware-Updater von Herstellern und Anti-Cheat-Komponenten. Dieselbe signierte Datei kann auf einem Gaming-PC harmlos und auf einem Dateiserver ein Alarmsignal sein.

Eine schnelle Möglichkeit, Treiberladevorgänge auf einem Host mit installiertem Sysmon zu prüfen:

Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-Sysmon/Operational'; Id=6} -MaxEvents 500 |
  ForEach-Object { $x = [xml]$_.ToXml(); [pscustomobject]@{
    Time      = $_.TimeCreated
    Driver    = ($x.Event.EventData.Data | Where-Object Name -eq 'ImageLoaded').'#text'
    Signature = ($x.Event.EventData.Data | Where-Object Name -eq 'Signature').'#text'
    Hashes    = ($x.Event.EventData.Data | Where-Object Name -eq 'Hashes').'#text' } } |
  Sort-Object Driver -Unique

Alles, was aus einem Benutzerprofil, aus C:\ProgramData, C:\Windows\Temp oder einem anderen beschreibbaren Ort geladen wird, ist unabhängig von seiner Signatur verdächtig.

Schritt 5: auf Servern weiter gehen

Die Sperrliste beantwortet die Frage „Ist dieser Treiber als schädlich bekannt?“. Auf Servern können Sie die stärkere Frage stellen: „Wird dieser Treiber hier erwartet?“. Serverhardware ändert sich selten, die Menge der Treiber ist also klein und stabil, was eine Treiber-Allowlist realistisch macht:

1. Erstellen Sie für jedes Hardwaremodell eine App-Control-Richtlinie aus einem Referenzserver, mit Kerneltreibern auf Herausgeberebene (New-CIPolicy -Level Publisher -Fallback Hash -ScanPath C:\Windows\System32\drivers).
2. Führen Sie die empfohlenen Treiber-Blockierregeln ohne deren Alles-zulassen-Regeln damit zusammen.
3. Betreiben Sie die Richtlinie einen vollständigen Patchzyklus lang im Überwachungsmodus, einschließlich Firmware- und Speichertreiberupdates, und erzwingen Sie sie dann.

Ist das vorerst zu viel, führen Sie zumindest ein Treiberinventar pro Servermodell und alarmieren Sie bei jedem Treiber, dessen Hash in Ihrer Umgebung noch nie gesehen wurde. Der Leitfaden zum Managed Installer zeigt, wie Sie eine solche Richtlinie wartbar halten, wenn sie über Treiber hinauswächst.

Was dabei kaputtgeht

Sehr wenig, weshalb diese Maßnahme flächendeckend gelten sollte. Die seltenen Fälle:

• Alte Hardware-Hilfsprogramme: Herstellertools, die eine anfällige Treiberversion mitbringen (Lüftersteuerung, RGB-Beleuchtung, BIOS-Flash-Tools). Die Lösung ist die aktualisierte Version des Herstellers, die normalerweise nicht auf der Liste steht.
• Veraltete Anti-Cheat- oder DRM-Komponenten auf privaten Geräten.
• Spezialisierte Industrie- oder Labortreiber, die nie aktualisiert wurden.

Wird ein Treiber blockiert, startet das Gerät weiterhin, aber die betroffene Komponente startet nicht. Prüfen Sie vor der Erzwingung auf Servern mit ungewöhnlicher Hardware, und widerstehen Sie der Versuchung, die Sperrliste für ein einzelnes Tool abzuschalten; ersetzen oder isolieren Sie das Tool.

Überprüfen

1. Richtlinie aktiv: CiTool.exe --list-policies listet die aktiven Richtlinien einschließlich der Treiber-Sperrrichtlinie mit ihrer Version auf; vergleichen Sie die Version mit der, die Sie bereitstellen wollten.
2. Aktivierung beim Start: Unter Applications and Services Logs > Microsoft > Windows > CodeIntegrity > Operational zeichnet Ereignis 3099 jede beim Start aktivierte Richtlinie mit Name und Version auf.
3. Blockierungen: Die Ereignisse 3077 (Erzwingung) und 3076 (Überwachung) im selben Protokoll zeigen einen Treiber, der blockiert wurde bzw. worden wäre. Ereignis 3089 folgt mit den Signaturdetails.
4. Sicher testen: Laden Sie zum Testen keine anfälligen Treiber auf Produktivsysteme herunter. Verwenden Sie eine isolierte Labor-VM oder verlassen Sie sich auf die obigen Richtlinien- und Ereignisprüfungen.

Leiten Sie CodeIntegrity-Ereignisse an Ihr SIEM weiter. Ein blockierter Treiber auf einem Server ist fast nie ein Zufall; behandeln Sie Ereignis 3077 für einen bekannten BYOVD-Treiber als Signal für einen aktiven Angriff und starten Sie die Incident Response.

Checkliste

• VulnerableDriverBlocklistEnable = 1 oder laufende Speicherintegrität auf jedem Client und Server
• Server und VMs ohne virtualisierungsbasierte Sicherheit ausdrücklich geprüft
• Neueste veröffentlichte Sperrliste bereitgestellt, zuerst im Überwachungsmodus in einem Pilotring getestet
• Alles-zulassen-Regeln vor dem Zusammenführen der Sperrliste mit einer App-Control-Allowlist entfernt
• ASR-Regel für anfällige signierte Treiber im Blockiermodus
• Sysmon-Ereignis 6 und Systemereignis 7045 erfasst und ausgewertet
• CodeIntegrity-Ereignis 3077 für Treiber als Alarm mit hohem Schweregrad eingerichtet
• Vierteljährliche Aufgabe zur Prüfung auf eine neuere Version der Sperrliste

Die Sperrliste ist eine kleine Änderung mit übergroßer Wirkung darauf, wie Angreifer Ihre Abwehr ausschalten. Sie wirkt am besten zusammen mit der Speicherintegrität und einer vollständigen Richtlinie aus dem Bereich Anwendungssteuerung, wobei der Managed Installer diese Richtlinie wartbar hält.