Ausgangslage: Ein gültig signierter Treiber kann trotzdem gefährlich sein

Windows verlangt für Kernel-Treiber eine vertrauenswürdige Signatur. Diese Kontrolle beantwortet jedoch vor allem, von wem ein Treiber stammt und ob er unverändert ist. Sie garantiert nicht, dass jede veröffentlichte Version sicher bleibt. Auch legitime, signierte Treiber können Schwachstellen oder Funktionen enthalten, mit denen sich die Windows-Sicherheitsgrenze umgehen lässt.

Das ist für Active Directory relevant, obwohl die Blocklist keine AD-Funktion ist. Ein kompromittierter Client, Member Server oder Administrationsrechner wird schnell zum Ausgangspunkt für Zugriffe auf Domänenidentitäten. Auf Domain Controllern schützt der Kernel wiederum RunAsPPL, EDR-Sensoren und Code Integrity; auf PAWs und geeigneten Tier-0-Membersystemen zusätzlich Credential Guard. Kann ein angreifbarer Treiber diese Schicht schwächen, verlieren mehrere darüberliegende Schutzmaßnahmen gleichzeitig an Wert.

Die Microsoft Vulnerable Driver Blocklist sperrt bekannte nicht von Microsoft stammende Treiber, wenn sie verwundbar oder bösartig sind oder die Windows-Sicherheitsarchitektur auf missbrauchbare Weise umgehen. Sie ist deshalb eine sinnvolle Baseline, aber keine vollständige Treiber-Allowlist und keine Aussage darüber, dass jeder nicht gelistete Treiber sicher ist.

Seit dem Windows-11-2022-Update ist die Blocklist auf Windows 11 standardmäßig aktiviert. Auf unterstützten Systemen wird sie außerdem über Memory Integrity, also HVCI, Smart App Control oder S Mode durchgesetzt; Windows Server 2016 braucht eine gesonderte Betrachtung. In gemischten Unternehmensumgebungen reicht die Annahme „bei Windows 11 ist das schon an“ nicht aus. Betriebssystemstand, Sicherheitsmodus, verwaltete App-Control-Richtlinien und tatsächlich geladene Policy müssen gemeinsam geprüft werden.

Zielbild: Kernel-Code erhält eine eigene, überprüfbare Zulassungsgrenze

Ein belastbarer Zielzustand besteht aus mehreren Kontrollen, die unterschiedliche Stellen des Treiberpfads abdecken:

  1. Unterstützte Windows-Versionen werden aktuell gehalten. Monatliche Windows-Updates transportieren auch Blocklist-Aktualisierungen; veraltete Builds erhalten keine belastbare aktuelle Baseline.
  2. Die Microsoft Vulnerable Driver Blocklist ist auf Clients, Member Servern, PAWs und Domain Controllern wirksam. Der Nachweis erfolgt über die aktive Code-Integrity-Konfiguration und zentrale Ereignisse, nicht nur über einen UI-Schalter.
  3. HVCI ist auf geeigneter Hardware das bevorzugte Durchsetzungsmodell. Wo Memory Integrity noch nicht kompatibel ist, wird die Blocklist über eine kontrolliert ausgerollte App-Control-for-Business-Policy erzwungen.
  4. Die aktuelle empfohlene Treiber-Blocklist wird bei höherem Schutzbedarf als eigenständige App-Control-Policy gepflegt. Sie wird zuerst im Audit-Modus und erst nach Bereinigung der Treffer im Enforcement-Modus verteilt.
  5. Die ASR-Regel gegen missbrauchte verwundbare signierte Treiber ergänzt die Blocklist. Sie verhindert, dass ein Prozess einen betroffenen Treiber auf Datenträger schreibt. Ein bereits vorhandener Treiber wird dadurch allein nicht am Laden gehindert.
  6. Treiber haben Owner und Lifecycle. Hardware-Agenten, Backup-Filter, Security-Produkte, RMM-Komponenten, VPN-, Storage- und Druckertreiber werden mit Version, Hersteller, Zweck und Updatepfad geführt.
  7. Ausnahmen ersetzen keine Aktualisierung. Ein blockierter legitimer Treiber wird aktualisiert, entfernt oder durch ein unterstütztes Produkt ersetzt. Eine Freigabe für eine verwundbare Version bleibt eng befristeter Notbetrieb.
  8. Recovery ist vor Enforcement getestet. Für Boot-Probleme stehen Out-of-Band-Zugriff, Wiederherstellungsumgebung, BitLocker-Recovery und die zuletzt funktionierende Policy bereit.

Das Ziel ist nicht, jede Treiberabweichung sofort zu blockieren. Es ist ein Zustand, in dem bekanntermaßen riskanter Kernel-Code nicht unbemerkt laden kann und eine neue Blockregel nicht überraschend einen geschäftskritischen Server stilllegt.

Umsetzung: Treiberbestand bereinigen, dann in Ringen erzwingen

1) Geräteklassen und Durchsetzungspfad inventarisieren

Trenne mindestens Windows-11-Clients, ältere Clients, PAWs, Member Server, Domain Controller, virtuelle Hosts und Systeme mit Spezialhardware. Derselbe Treiber kann auf einem Standard-Laptop irrelevant, auf einem Storage-Server aber bootkritisch sein. Erfasse daher nicht nur Dateinamen, sondern Geräteklasse, Hersteller, Treiberversion, abhängige Software, Neustartfenster und technischen Owner.

Die folgende Abfrage verändert nichts. Führe sie aus einer erhöhten PowerShell-Sitzung aus. Sie liefert einen ersten lokalen Überblick über signierte Plug-and-Play-Treiber, HVCI und relevante Code-Integrity-Ereignisse:

Set-StrictMode -Version Latest

$deviceGuard = Get-CimInstance `
  -Namespace 'root\Microsoft\Windows\DeviceGuard' `
  -ClassName 'Win32_DeviceGuard' `
  -ErrorAction Stop

$blocklistPath = 'HKLM:\SYSTEM\CurrentControlSet\Control\CI\Config'
$blocklistValue = Get-ItemProperty `
  -LiteralPath $blocklistPath `
  -Name 'VulnerableDriverBlocklistEnable' `
  -ErrorAction SilentlyContinue

[pscustomobject]@{
  ComputerName              = [Environment]::MachineName
  VbsStatus                 = $deviceGuard.VirtualizationBasedSecurityStatus
  HvciConfigured            = $deviceGuard.SecurityServicesConfigured -contains 2
  HvciRunning               = $deviceGuard.SecurityServicesRunning -contains 2
  ExplicitBlocklistSetting  = if ($null -eq $blocklistValue) {
    'Not explicitly set'
  } else {
    [int]$blocklistValue.VulnerableDriverBlocklistEnable
  }
}

Get-CimInstance -ClassName 'Win32_PnPSignedDriver' |
  Where-Object { $_.DriverVersion } |
  Select-Object DeviceName, DriverProviderName, DriverVersion, InfName, DriverDate |
  Sort-Object DriverProviderName, DeviceName

Get-WinEvent -FilterHashtable @{
  LogName = 'Microsoft-Windows-CodeIntegrity/Operational'
  Id      = 3076, 3077, 3099
} -MaxEvents 100 -ErrorAction SilentlyContinue |
  Select-Object TimeCreated, Id, Message

Der Registry-Wert ist nur ein Indikator. Ein fehlender Wert beweist keine deaktivierte Blocklist, weil HVCI, Smart App Control, S Mode oder eine App-Control-Policy unabhängig davon durchsetzen können. Ebenso beweist ein Wert von 1 nicht, dass die erwartete App-Control-Policy aktuell und wirksam ist. Policy-Load-Ereignisse, Code-Integrity-Telemetrie und der effektive Gerätezustand gehören zusammen.

Die PnP-Liste ist ebenfalls kein Vulnerability Scanner. Sie hilft, Hersteller und Versionen zuzuordnen. Ob eine konkrete Binärdatei durch eine Microsoft-Regel betroffen ist, muss über Audit-Ereignisse, die bereitgestellte Policy und den Vendor-Status geklärt werden.

2) Veraltete Treiber vor dem Security-Change entfernen

Beginne mit Software, die häufig eigene Kernel-Komponenten mitbringt: Hardware-Monitoring, Tuning- und RGB-Tools, ältere VPN-Clients, Storage- und Backup-Agenten, Drucksoftware, Endpoint-Security, DLP, Verschlüsselung, RMMs und virtuelle Hardware-Tools. Prüfe auch deinstallierte Anwendungen, deren Treiberpakete im Driver Store verblieben sind.

Für jeden Treffer gibt es vier saubere Ergebnisse:

  • eine vom Hersteller korrigierte, unterstützte Version wird verteilt,
  • die abhängige Software wird aktualisiert oder neu konfiguriert,
  • ungenutzte Software und ihr Treiberpaket werden kontrolliert entfernt,
  • das System wird ersetzt oder in einem klar befristeten Ausnahmezustand isoliert.

Eine Blocklist ist kein Patch-Mechanismus. Sie verhindert das Laden einer gelisteten Version, repariert aber weder das Produkt noch seine Abhängigkeiten. Deaktiviere die Blocklist deshalb nicht dauerhaft, nur damit ein altes Verwaltungswerkzeug wieder funktioniert. Das verschiebt das Risiko vom sichtbaren Kompatibilitätsproblem zurück in den Kernel.

3) Windows-Servicing und HVCI als Basis herstellen

Stelle zuerst sicher, dass Pilotgeräte aktuelle kumulative Windows-Updates erhalten und nach dem Servicing tatsächlich neu gestartet werden. Microsoft pflegt die Blocklist regelmäßig und verteilt Aktualisierungen im normalen Windows-Servicing. Geräte, die monatelang keinen aktuellen Build oder keinen Neustart sehen, dürfen in der Compliance-Auswertung nicht als geschützt gelten.

Aktiviere HVCI beziehungsweise Memory Integrity auf unterstützter Hardware in eigenen Rollout-Ringen. Die Prüfung muss Boot-Treiber, Hypervisor, EDR, VPN, Storage, Backup, Druck und Spezialperipherie abdecken. PAWs und neu beschaffte Standardclients sind meist gute frühe Zielgruppen. Domain Controller und geschäftskritische Server folgen mit einer repräsentativen Testgruppe und einem getesteten Recovery-Pfad.

HVCI und die Vulnerable Driver Blocklist sind nicht identisch. HVCI schützt Code Integrity in einer virtualisierungsbasierten Umgebung und erzwingt auf unterstützten Systemen zugleich die Blocklist. Eine App-Control-Policy kann die Treiberregeln auch dort bereitstellen, wo HVCI noch nicht ausgerollt ist. Dokumentiere pro Geräteklasse, welcher Mechanismus tatsächlich führend ist.

4) Die aktuelle Blocklist als App-Control-Policy pilotieren

Für Systeme, die immer die aktuell bereitgestellte empfohlene Liste benötigen, oder für Geräte ohne geeigneten HVCI-Pfad, kann die Microsoft-Policy als separate App-Control-for-Business-Policy ausgerollt werden. Beziehe Policy und Refresh-Werkzeug ausschließlich aus dem kontrollierten Microsoft-Downloadpfad. Prüfe Herkunft, Signatur und Hash, versieh das Paket intern mit einer Version und behandle es wie ein Security-Artefakt.

Starte mit der von Microsoft bereitgestellten Audit-Variante. Event 3099 dient als Nachweis, dass eine App-Control-Policy geladen wurde; die Policy-ID und der Policy-Name müssen zum vorgesehenen Paket passen. Event 3076 zeigt Code, der unter Enforcement nicht zugelassen wäre. Erst wenn diese Treffer einem Gerät, Treiber, Produkt und Owner zugeordnet sind, folgt die erzwungene Policy. Event 3077 kennzeichnet einen tatsächlichen Block unter Enforcement.

Die bereitgestellte Treiber-Policy enthält Allow-All-Regeln, damit sie als eigenständige Deny-Policy funktioniert. Auf Windows-Versionen mit Multiple-Policy-Unterstützung ist eine separat parallel bereitgestellte Deny-Policy meist übersichtlicher als ein Merge. Wird sie mit einer bestehenden expliziten Allowlist zusammengeführt, müssen die Allow-All-Regeln vorher entfernt werden. Andernfalls kann das zusammengeführte Regelwerk seine beabsichtigte Zulassungswirkung verlieren.

Bereits laufende Treiber werden durch das Aktivieren einer neuen Policy nicht aus dem Kernel entladen. Ein Neustart ist nötig, damit eine nun gesperrte Komponente beim nächsten Ladeversuch blockiert wird. Plane diesen Neustart als Teil des Changes und prüfe danach Boot, Hardwarefunktion und Code-Integrity-Events.

Windows Server 2016 gehört in einen eigenen Ring. Die aktuelle Policy muss auf einem neueren unterstützten Windows-System konvertiert beziehungsweise als dafür bereitgestellte Variante übernommen werden. Improvisierte Änderungen direkt an EFI- oder CodeIntegrity-Dateien sind kein verlässlicher Enterprise-Rollout.

5) Die ASR-Regel als vorgelagerte Kontrolle ergänzen

Die Defender-ASR-Regel „Block abuse of exploited vulnerable signed drivers“ reduziert einen anderen Teil des Pfads: Sie hindert Anwendungen daran, bekannte verwundbare signierte Treiber auf Datenträger zu schreiben. Führe sie zunächst im Audit-Modus ein, werte die Treffer zentral aus und wechsle danach geräteklassenweise auf Block.

Die Regel ersetzt die Blocklist nicht. Liegt der Treiber bereits auf dem System, kann die ASR-Regel allein sein Laden nicht verhindern. Umgekehrt deckt die Blocklist nicht automatisch jeden neuen oder kundenspezifischen Treiber ab, den eine ASR- oder App-Control-Regel erfassen könnte. Beide Kontrollen sollten als getrennte Compliance-Signale geführt werden.

6) Pilot, Enforcement und Monitoring fest miteinander verbinden

Ein sinnvoller Ringaufbau beginnt mit Security- und IT-Testgeräten, geht über repräsentative Hardwaremodelle und Applikationsserver und erreicht erst danach PAWs, Domain Controller und die breite Fläche. Der Pilot braucht mehr als einen erfolgreichen Neustart. Teste mindestens:

  • Kaltstart und Neustart mit aktiviertem Secure Boot,
  • BitLocker- und Recovery-Ablauf,
  • EDR-, Backup-, VPN- und Storage-Funktion,
  • Firmware- und Treiberupdates über den vorgesehenen Managementpfad,
  • Druck, Dockingstations und Spezialperipherie,
  • virtuelle Hardware, Snapshot- und Restore-Prozesse,
  • Code-Integrity-Events nach Policy-Update und Neustart,
  • Rollback auf die zuletzt funktionierende Policy.

Sammle 3076, 3077 und 3099 zentral. Ein einzelner Audit-Treffer ist noch kein Incident, aber er braucht eine Entscheidung. Ein Enforcement-Block auf einem Domain Controller, einer PAW oder einem Security-Produkt hat hohe Priorität. Halte mindestens Policy-ID, Policy-Version, Gerät, Treiberpfad, Hash, Signer, Produkt, Owner und Entscheidung fest.

Ergänze die technische Telemetrie um Servicing-Daten. Eine aktive Policy mit monatelang veraltetem Windows-Stand ist keine aktuelle Blocklist. Ebenso darf ein Gerät, das nach dem Enforcement-Change nicht neu gestartet wurde, nicht vorschnell als vollständig geprüft gelten.

7) Recovery ohne dauerhafte Sicherheitslücke vorbereiten

Treiberfehler können sich als fehlende Hardwarefunktion, Startschleife oder in seltenen Fällen als Bluescreen zeigen. Der Recovery-Plan muss deshalb außerhalb der normalen Benutzersitzung funktionieren. Teste Out-of-Band-Zugriff für Server, Windows Recovery Environment, Safe Mode soweit im Betriebsmodell unterstützt, BitLocker-Recovery und die Wiederherstellung der zuletzt freigegebenen Policy.

Definiere vorab, wer eine Ausnahme genehmigen darf. Eine temporäre Rücknahme braucht betroffene Geräte, Treiberversion, Herstellerfall, kompensierende Kontrollen, Ablaufdatum und Rückkehrplan. Die pauschale Abschaltung von HVCI oder Blocklist auf einer ganzen OU ist kein Rollback, sondern eine neue Sicherheitslage.

Vorteile

  • Bekannte Kernel-Risiken werden vor dem Laden gestoppt: Eine gültige Signatur reicht nicht mehr als alleinige Vertrauensentscheidung.
  • Credential-Schutz wird belastbarer: RunAsPPL, Credential Guard und EDR arbeiten auf einer Kernel-Basis, die bekannte verwundbare Treiber nicht akzeptiert.
  • Domain Controller und PAWs erhalten eine zusätzliche Schutzschicht: Ein lokaler Administrationsfehler führt nicht automatisch zu frei nutzbarem Kernel-Code.
  • Hersteller- und Versionswildwuchs wird sichtbar: Audit-Treffer erzwingen eine Zuordnung von Treiber, Produkt und Owner.
  • Der Zustand ist messbar: Geladene Policy, Audit- und Block-Events, OS-Stand und Neustartstatus lassen sich zentral auswerten.
  • Die Kontrolle funktioniert vor einer Verhaltensanalyse: Ein gelisteter Treiber wird blockiert, auch wenn ein nachgelagerter Sensor noch kein verdächtiges Verhalten erkannt hat.
  • ASR und App Control lassen sich ergänzen: Schreiben, Laden und weitergehende Code-Zulassung können getrennt kontrolliert werden.

Nachteile und Grenzen

  • Kompatibilitätsprobleme sind real: Hardware, Backup, VPN, Storage, Druck oder Security-Produkte können ausfallen, wenn sie von einer gesperrten Version abhängen.
  • Boot-Probleme sind möglich: Kernel-Treiber wirken früh im Startprozess; ungetestetes Enforcement kann bis zum Bluescreen führen.
  • Die Liste ist nicht vollständig: Neue, unbekannte oder kundenspezifische Schwachstellen sind nicht automatisch enthalten.
  • Nicht jeder aktuelle Treiber ist automatisch sicher: „Nicht blockiert“ ist keine Freigabe oder Sicherheitsbewertung.
  • Audit-Modus schützt nicht: Er liefert Entscheidungsdaten, lässt den betroffenen Treiber aber weiterhin laden.
  • Ein Neustart bleibt erforderlich: Bereits geladene Treiber werden nicht nachträglich aus dem Kernel entfernt.
  • HVCI passt nicht sofort zu jeder Plattform: Alte Hardware, Firmware oder Spezialtreiber können einen separaten Migrationspfad benötigen.
  • Servicing bleibt Pflicht: Eine aktivierte, aber veraltete OS-Blocklist verliert mit der Zeit an Wert.
  • ASR ist nur ergänzend: Die Regel gegen das Schreiben eines Treibers blockiert keinen bereits vorhandenen Treiber beim Laden.
  • Eine Deny-List ersetzt keine Allowlist: Für besonders schützenswerte Systeme kann eine explizite App-Control-Zulassung weiterhin notwendig sein.
  • Lokale Administratorrechte bleiben ein Risiko: Die Blocklist reduziert missbrauchbare Treiberpfade, ersetzt aber keine Least-Privilege-Architektur.

Typische Stolperfallen

  • „Signiert“ mit „sicher“ gleichsetzen: Signaturen schaffen Herkunftsvertrauen, keine dauerhafte Schwachstellenfreiheit.
  • Nur den Windows-Security-Schalter prüfen: UI, Registry, HVCI und App-Control-Policy können unterschiedliche Ausschnitte des Zustands zeigen.
  • Die gesamte Domäne in einem Schritt erzwingen: Unterschiedliche Hardware- und Serverrollen brauchen eigene Pilotringe.
  • Treiber erst nach dem Block testen: Vendor-Updates und Deinstallation gehören vor Enforcement.
  • Audit-Treffer ungesehen freigeben: Eine breite Publisher-Ausnahme kann auch weitere verwundbare Versionen zulassen.
  • Allow-All-Regeln falsch mergen: Die eigenständige Deny-Policy darf eine vorhandene explizite Allowlist nicht unbeabsichtigt öffnen.
  • ASR und Blocklist verwechseln: Schreiben auf Datenträger und Laden in den Kernel sind zwei getrennte Kontrollpunkte.
  • Nach dem Policy-Change nicht neu starten: Der alte Treiber kann weiterlaufen, obwohl die neue Policy geladen ist.
  • Nur ein Hardwaremodell testen: Docking, Storage, Druck, VPN und Firmware unterscheiden sich oft innerhalb derselben Geräteklasse.
  • Windows-Updates auslassen: Die Blocklist ist Teil eines laufenden Servicing-Prozesses, kein einmaliges Projektartefakt.
  • Blocklist zur Treiberinventur erklären: Sie kennt ausgewählte riskante Treiber, nicht den vollständigen erlaubten Bestand.
  • HVCI bei Problemen dauerhaft abschalten: Ein befristeter Recovery-Schritt darf nicht zum unbemerkten Zielzustand werden.
  • Policies manuell aus EFI-Verzeichnissen löschen: Ad-hoc-Reparaturen können Code Integrity und Secure Boot in einen schwer nachvollziehbaren Zustand bringen.
  • Rollback nur als neue GPO planen: Ein nicht bootendes oder nicht verbundenes System erhält diese Änderung nicht rechtzeitig.
  • Keine Policy-Version protokollieren: Ohne ID, Version und Ring ist ein Blockereignis nicht reproduzierbar.

Projekt-Checkliste

  • [ ] Windows-11-Clients, ältere Clients, PAWs, Member Server, DCs, Hosts und Spezialgeräte getrennt klassifiziert.
  • [ ] Aktuellen OS-Build, Patchstand und letzten erfolgreichen Neustart je Pilotgerät erfasst.
  • [ ] HVCI-Konfiguration und tatsächlichen Running State geprüft.
  • [ ] Effektive Blocklist- beziehungsweise App-Control-Durchsetzung pro Geräteklasse dokumentiert.
  • [ ] Signierte PnP-Treiber mit Hersteller, Version, INF und Gerät inventarisiert.
  • [ ] Boot-, Storage-, VPN-, Backup-, EDR-, RMM-, Druck- und Hardware-Treiber priorisiert.
  • [ ] Unnötige Altsoftware und verbliebene Treiberpakete kontrolliert entfernt.
  • [ ] Für verbleibende Treiber Produkt-Owner und Hersteller-Updatepfad festgelegt.
  • [ ] Windows-Servicing und monatliche Blocklist-Aktualisierung überwacht.
  • [ ] HVCI auf repräsentativer Hardware in einem eigenen Pilotring getestet.
  • [ ] Aktuelle Microsoft-Blocklist nur aus kontrollierter Quelle bezogen und intern versioniert.
  • [ ] App-Control-Policy-ID und Policy-Name vor Verteilung dokumentiert.
  • [ ] Event 3099 als Load-Nachweis geprüft.
  • [ ] Audit-Events 3076 zentral gesammelt und jedem Produkt-Owner zugeordnet.
  • [ ] Keine breite Allow-Regel für eine verwundbare Treiberversion erstellt.
  • [ ] Multiple-Policy- beziehungsweise Merge-Verhalten mit vorhandenen App-Control-Policies geprüft.
  • [ ] Windows Server 2016 in einem eigenen kompatiblen Policy-Pfad behandelt.
  • [ ] ASR-Regel zunächst im Audit-Modus und anschließend in Ringen auf Block gestellt.
  • [ ] ASR- und Blocklist-Compliance als getrennte Signale ausgewertet.
  • [ ] Enforcement auf alle relevanten Hardwaremodelle und Serverrollen ausgeweitet.
  • [ ] Neustart als fester Bestandteil des Enforcement-Changes eingeplant.
  • [ ] Event 3077 nach Enforcement zentral alarmiert und bearbeitet.
  • [ ] Firmware-, Treiber- und Windows-Update nach Enforcement getestet.
  • [ ] BitLocker-Recovery, WinRE und Out-of-Band-Zugriff praktisch geprüft.
  • [ ] Letzte funktionierende Policy und Wiederherstellungsverfahren dokumentiert.
  • [ ] Ausnahmen mit Gerät, Treiber, Owner, Begründung, Kompensation und Ablaufdatum geführt.
  • [ ] Abschaltungen von HVCI oder Blocklist als zeitkritische Abweichung überwacht.
  • [ ] Quartalsweise Policy-Prüfung und Review bei neuen Hardware- oder Softwareklassen terminiert.