Bring Your Own Vulnerable Driver

Bring Your Own Vulnerable Driver (BYOVD) bezeichnet eine Angriffstechnik, bei der ein Angreifer einen legitimen, kryptografisch signierten Kernel-Treiber auf ein Zielsystem nachlädt — nur eben in einer alten Version mit bekannter Schwachstelle. Über diese Lücke verschafft sich der Angreifer Code-Ausführung im Windows-Kernel und damit jene Privilegien, die EDR-Sensoren, Treibersignatur-Prüfung (Driver Signature Enforcement) und Endpoint-Schutz strukturell einschränken sollten. Da die Treiber selbst ordnungsgemäß signiert sind, akzeptiert das Betriebssystem sie zunächst — die Sicherheitsverletzung entsteht erst durch die ausnutzbare Funktion innerhalb der Treiberlogik.

Wie BYOVD funktioniert

Der Ablauf folgt einem stabilen Muster. Nach dem Initial Access platziert der Angreifer den verwundbaren Treiber als Datei auf dem Endpunkt, registriert ihn als Kernel-Service (sc create oder direkter Registry-Eintrag unter HKLM\SYSTEM\CurrentControlSet\Services) und startet ihn. Anschließend wird die im Treiber enthaltene Schwachstelle gezielt getriggert — typischerweise eine ungesicherte IOCTL-Schnittstelle, die beliebige Kernel-Speicheroperationen erlaubt. Mit diesen Primitiven hebt der Angreifer EDR-Callbacks aus, manipuliert Prozessobjekte oder deaktiviert komplette Sicherheitsdienste auf Kernel-Ebene.

Entscheidend ist: Es handelt sich nicht um einen klassischen Exploit gegen das Betriebssystem, sondern um die Zweckentfremdung eines bewusst eingebrachten Drittanbieter-Treibers. Die Vertrauenskette bleibt formal intakt — das Microsoft-Code-Signing erkennt eine gültige Signatur und lädt den Treiber.

Warum signierte, verwundbare Treiber ein strukturelles Problem sind

Treibersignaturen wurden eingeführt, um unsignierte Schadtreiber abzuwehren. Sie machen aber keine Aussage über die Qualität oder Sicherheit des Codes. Ein Hersteller, dessen Treiber drei Jahre nach Veröffentlichung mit einem nicht beachteten IOCTL-Bug aus dem Markt verschwindet, hinterlässt eine signierte Binary, die über Jahre vertrauenswürdig bleibt. Da Zertifikatswiderrufe in der Praxis selten und langsam ausgerollt werden, bleibt der Treiber regelmäßig auch dann ladbar, wenn längst Patches existieren.

Bekannte Beispiele aus der Praxis verdeutlichen die Tragweite:

Sicherheitsforscher dokumentieren laufend neue Kandidaten — der von der Community (Projekt MagicSword) gepflegte Katalog loldrivers.io listet inzwischen mehrere hundert bekanntermaßen missbräuchlich nutzbare signierte Treiber.

BYOVB: Dieselbe Logik, nur eine Ebene tiefer

Die Idee, eine signierte, aber verwundbare Binary mitzubringen, ist nicht auf Kernel-Treiber beschränkt. Unter dem Begriff Bring Your Own Vulnerable Binary (BYOVB) wird das Muster auf andere signierte Komponenten übertragen — insbesondere auf Bootloader und UEFI-Anwendungen, die noch unterhalb des Betriebssystems agieren. Das prominenteste Beispiel ist das Bootkit BlackLotus: Statt einen neuen Bug zu finden, kopiert der Installer eine alte, weiterhin gültig signierte Version des Windows Boot Managers (bootmgfw.efi) auf die EFI System Partition und löst über die längst gepatchte Schwachstelle „Baton Drop" (CVE-2022-21894) eine Manipulation der Secure-Boot-Policy aus. Die Vertrauenskette akzeptiert die alte Binary, weil ihre Signatur nie widerrufen wurde — analog zum BYOVD-Muster, nur eine Schicht unterhalb des Kernels. Details zu Wirkungsweise und Revokation finden sich in unserer Analyse zu BlackLotus und CVE-2023-24932.

BYOVD im Ransomware-Werkzeugkasten

BYOVD ist nicht mehr exotisch, sondern fester Bestandteil moderner Ransomware-Operationen. Sicherheitsforscher dokumentierten zuletzt mehrere Dutzend „EDR-Killer", die Dutzende verwundbare Treiber gleichzeitig mitbringen, um beim Treffer auf eine fremde EDR-Lösung möglichst flächendeckend zu sein. Einige Loader betten den verwundbaren Treiber direkt in die Ransomware-Binary ein, sodass Deaktivierung der Sicherheitssoftware und Verschlüsselung in einem einzigen Lauf erfolgen.

Die Funktion eines BYOVD-Angriffs ist dabei selten Selbstzweck. Sobald der Kernel offen ist, folgen typischerweise Credential-Diebstahl aus LSASS, Manipulation von Kerberos-Tickets bzw. Cache-Inhalten und Rootkit-ähnliche Verschleierung, bis die eigentliche Payload — Verschlüsselung, Datenexfiltration, persistente Hintertür — gestartet wird. Eine ausführliche Einordnung in das Evasion-Arsenal aktueller Gruppen liefert unser Beitrag Ransomware-Evasion durch Virtualisierung.

Microsoft Vulnerable Driver Blocklist

Microsoft pflegt eine zentrale Sperrliste bekannter, missbräuchlich nutzbarer Treiber: die Microsoft Vulnerable Driver Blocklist. Sie wird über Windows-Update verteilt und durch eine WDAC-Code-Integrity-Policy durchgesetzt. Auf Windows 11 ist sie standardmäßig aktiv, sofern Hypervisor-Protected Code Integrity (HVCI) oder Smart App Control eingeschaltet sind. Auf Windows 10 und Windows Server muss sie in vielen Installationen explizit aktiviert werden — manuell über die mitgelieferte XML-Policy oder per Intune.

In der Praxis finden wir in Assessments regelmäßig, dass die Blocklist auf Windows-10-Bestandsgeräten und Domain Controllern nicht aktiv ist, obwohl die Hardware sie problemlos tragen würde. Damit bleibt eine zentrale Hürde gegen BYOVD ungenutzt.

Verteidigung: HVCI, WDAC und gehärtete Treiberregeln

Eine wirksame BYOVD-Abwehr setzt auf mehreren Ebenen an und nutzt die nativen Windows-Mechanismen konsequent:

• HVCI / Memory Integrity — Hypervisor-Protected Code Integrity validiert Treibercode innerhalb von VBS (VTL1) und verhindert das Laden von Treibern, die nicht mit aktuellen Microsoft-Compliance-Regeln vereinbar sind. Damit fallen viele klassische BYOVD-Treiber bereits beim Ladevorgang aus.
• WDAC mit Treiber-Allowlist — Eine WDAC-Policy, die Kernel-Mode-Treiber nur nach Publisher und Version zulässt, schließt das Restrisiko: Selbst wenn die Microsoft-Blocklist einen Treiber noch nicht kennt, scheitert das Laden an der Allowlist.
• Vulnerable Driver Blocklist aktivieren — Auf jedem Endpunkt und Server, idealerweise über Intune oder GPO ausgerollt und im Audit-Modus überwacht, bevor die Blockierung scharfgeschaltet wird.
• Least Privilege auf Endpunkten — Ohne lokale Admin-Rechte kann ein Angreifer keinen Kernel-Service registrieren. Das macht BYOVD nicht unmöglich, hebt aber die Hürde deutlich.
• EDR mit Kernel-Tamper-Protection — Sensoren, die das Entfernen ihrer eigenen Kernel-Callbacks erkennen und alarmieren, verkürzen die Reaktionszeit, falls die anderen Schichten umgangen werden.

Die Kombination aus HVCI und einer schlanken WDAC-Treiberrichtlinie ist dabei die belastbarste Antwort. Beide Funktionen sind auf moderner Hardware ohne Zusatzkosten verfügbar, werden aber selten konsequent ausgerollt.

Relevanz für KMUs

BYOVD ist kein APT-only-Werkzeug mehr, sondern Standardrepertoire von Ransomware-Affiliates, die mittelständische Unternehmen gezielt angreifen. Die gute Nachricht: Die wirksamsten Gegenmaßnahmen — Microsoft Vulnerable Driver Blocklist, HVCI und eine WDAC-Treiberrichtlinie — sind in vorhandenen Windows-Lizenzen enthalten und benötigen weder zusätzliche Produkte noch ein 24/7-SOC. Wer im Rahmen einer Systemhärtung die Blocklist aktiviert, HVCI flächendeckend erzwingt und das Laden unbekannter Kernel-Treiber per Policy unterbindet, entzieht der überwiegenden Mehrheit aktueller BYOVD-Angriffe die Grundlage — und schützt damit zugleich vor einer ganzen Klasse verwandter Techniken einschließlich BYOVB auf Bootloader-Ebene.