Im Juni 2026 veröffentlichte das Threat Hunter Team von Symantec Carbon Black eine detaillierte Analyse darüber, wie sich „Hackledorb“, die Gruppe hinter ransomware „DragonForce“, ein bis zwei Monate lang in einem großen US-Dienstleistungsunternehmen eingenistet hatte. Bevor sie ransomware einsetzten und noch bevor sie auch nur einen einzigen Sicherheitsprozess beendeten, luden die Betreiber nacheinander vier Kernel-Mode-Treiber. Drei davon wiesen dokumentierte CVEs auf. Der vierte, ein Audio-Treiber von Huawei, den die Betreiber „Havoc Process Terminator“ nannten, wies zum Zeitpunkt der Installation keinerlei bekannte Sicherheitslücke auf.
Ein Hinweis zur Bezeichnung der Akteure: Symantec Carbon Black bezeichnet diesen Betreiber als „Hackledorb“; Trend Micro nennt dieselbe Gruppe „Water Tambanakua“. „DragonForce“ bezieht sich auf das übergeordnete ransomware ; mehrere Betreiber führen Angriffe unter diesem Namen durch. Die Herkunft ist weiterhin unbestätigt: Intel 471 stellt fest, dass der Hauptbetreiber in Cyberkriminalitätsforen auf Russisch postet; eine vermutete Verbindung zu Malaysia lässt sich auf eine separate Hacktivisten-Gruppe zurückführen, die Anfang 2024 jegliche Verbindung dementierte.
Was ein Microsoft-Treiberzertifikat tatsächlich überprüft
Jeder Treiber, der unter einem modernen Windows-System geladen wird, muss eine gültige Microsoft-Signatur aufweisen. Diese Anforderung gilt tatsächlich.
Was dabei überprüft wird: ob der Treiber von einem Anbieter stammt, der den Zertifizierungsprozess von Microsoft durchlaufen hat, und ob die Binärdatei nicht manipuliert wurde. Was dabei nicht überprüft wird: ob der Treiber Sicherheitslücken enthält. Das war nie der Zweck dieser Sicherheitsüberprüfung.
Eine Kernel-Signatur steht für Vertrauenswürdigkeit hinsichtlich der Herkunft: Sie gibt Auskunft darüber, wer den Code bereitgestellt hat. Sie ist jedoch keine Garantie dafür, dass der Treiber nicht ausgenutzt werden kann.
„Bring Your Own Vulnerable Driver“ (BYOVD) bezeichnet den Vorgang, der eintritt, wenn ein Angreifer diese Lücke ausnutzt. Er lädt einen legitimen, signierten Treiber mit einer bekannten Sicherheitslücke, nutzt diese Lücke, um die Sicherheitssoftware zu deaktivieren, und setzt dann den Angriff fort. Windows erkennt eine gültige Signatur und lädt den Treiber wie gewohnt. Im Ereignisprotokoll wird eine routinemäßige Installation vermerkt. Es sieht alles ganz normal aus.
Dieselbe Bibliothek, zwei Kampagnen
Diese Kampagne ist kein Einzelfall.
Im Juni 2026 veröffentlichte ESET eine Studie zu „GentleKiller“, einem BYOVD-Framework, das eine zweite ransomware als Standard-Tooling vor dem Angriff an ihre Partner verteilt. Es nutzt signierte Treiber verschiedener legitimer Anbieter, um Sicherheitsprogramme von 48 Anbietern zu deaktivieren, darunter Defender, CrowdStrike, SentinelOne und Sophos. ESET bestätigte 478 Opfer in mehr als 70 Ländern.
Bei beiden Kampagnen kam ein Audio-Treiber von Huawei zum Einsatz. Bei der Kampagne im Dezember 2025 wies dieser Treiber zum Zeitpunkt der Bereitstellung durch die Betreiber keine dokumentierten Sicherheitslücken auf. Huntress veröffentlichte seine Analyse drei Monate später, nach dem Angriff.
Die Treiberbibliothek umfasst ein Spielestudio, einen Anbieter von Sicherheitsprodukten, einen Hersteller von Audio-Hardware und ein Unternehmen für Betrugsbekämpfung. Dabei handelt es sich um seriöse Unternehmen, die signierten Code ausgeliefert haben und an den nachfolgenden Ereignissen in keiner Weise beteiligt waren. Die Signatur-Pipeline hat jeden Treiber bei der Veröffentlichung validiert und diese Validierung auch nach der Entdeckung der Sicherheitslücken fortgesetzt.
Die Sperrliste kann nichts blockieren, was noch nicht gefunden wurde.
Microsoft führt eine Blacklist mit anfälligen Treibern. Solange sie konsequent durchgesetzt und auf dem neuesten Stand gehalten wird, funktioniert sie.
Das Problem ist der Zeitpunkt. Ein Treiber wird erst dann hinzugefügt, wenn er bei einem Angriff auftaucht, wenn eine CVE gemeldet wurde und wenn die Kampagne ausreichend Aufmerksamkeit erregt hat. Bei dem Angriff im Dezember 2025 gab es drei Treiber mit dokumentierten CVEs, die noch nicht auf die Sperrliste gesetzt worden waren. Der Huawei-Treiber hatte überhaupt keine CVE.
Das ist kein Versagen des Prozesses. Es handelt sich um eine strukturelle Einschränkung. Die Sperrliste reagiert erst nachträglich. Angreifer nutzen die Lücke zwischen dem Zeitpunkt, zu dem eine Sicherheitslücke ausgenutzt werden kann, und dem Zeitpunkt, zu dem die Abwehr nachzieht.
Das einzige Erkennungsfenster
Es gibt einen Moment, in dem ein Verteidiger einen BYOVD-Angriff abfangen kann, bevor die Sicherheitstools deaktiviert werden.
Wenn ein Treiber als Windows-Dienst geladen wird, protokolliert Windows die Ereignis-ID 7045. Dieses Ereignis wird ausgelöst, während die Sicherheitstools noch laufen, noch bevor die Beendigungssequenz beginnt. Die Überwachung dieser Protokolle auf Treiberinstallationen, die von Ihrer normalen Baseline abweichen, verschafft Ihnen ein Zeitfenster, um Maßnahmen zu ergreifen.
Sobald die Löschsequenz ausgeführt wird, schließt sich dieses Fenster.
Es gibt auch eine strukturelle Abhilfe: Durch die Aktivierung der Speicherintegrität (auch als HVCI bezeichnet) wird eine strengere Treiberrichtlinie durchgesetzt, die diese Technik bereits im Keim erstickt. In den meisten Unternehmensumgebungen ist diese Funktion jedoch nicht aktiviert. Sie erfordert Hardwareunterstützung und Kompatibilitätstests, die viele Unternehmen noch nicht durchgeführt haben. Die Abhilfe ist vorhanden. Die Umsetzung hinkt jedoch hinterher.
Was das Zertifikat nicht abdeckt
Anhand der Codesignatur lässt sich feststellen, wer den Treiber bereitgestellt hat. Sie gibt jedoch keinen Aufschluss darüber, ob jemand anderes ihn Jahre später ausnutzen kann.
Die beiden Kampagnen stützen sich auf eine Sammlung, die die Bereiche Gaming, Cybersicherheit, Hardware und Unternehmenssoftware umfasst. Es handelt sich um legitime Anbieter mit gültigen Signaturen, die jedem Angreifer zur Verfügung stehen, der die richtige Schwachstelle findet.
BYOVD beeinträchtigt das Signatursystem des Windows-Kernels nicht. Es nutzt es vielmehr.
Das Hinzufügen zur Sperrliste nach der Ausnutzung ist ein reaktiver Ansatz. Die Speicherintegrität (HVCI) ist die strukturelle Lösung. Bis diese Lösung in größerem Umfang eingesetzt wird, besteht die praktische Erkennung darin, nach der Ereignis-ID 7045 zu suchen, um anomale Treiberladungen zu erkennen.
Die Erkennung funktioniert einwandfrei. Sie ist nur unvollständig.
Vectra AI auf der Netzwerkebene und nicht auf endpoint, sodass die hier beschriebene Kill-Sequenz keine Auswirkungen darauf hat. Wenn Sie genauer erfahren möchten, wie sich die netzwerkbasierte Erkennung in alle drei Sicherheitslücken einfügt und mit endpoint Identitätskontrollen zusammenwirkt, finden Sie im E-Book „Mind Your Attack Gaps“ eine umfassende Darstellung der gesamten Architektur.