Ein signierter Treiber macht den Endpunktschutz blind
Ein Treiber mit gültiger Microsoft-Signatur schaltet auf dem Endpunkt die Schutzprozesse ab. Das Sicherheitswerkzeug läuft weiter, meldet aber nichts mehr. Genau dieses Muster hat das Threat-Hunter-Team von Symantec bei der Gruppe hinter der Ransomware GodDamn beobachtet. Der Fall zeigt weniger eine neue Schadsoftware als die Grenzen des Windows-Treibervertrauens.
Das Wichtigste in Kürze
- Signatur ist kein Schutz. Ein gültig signierter Kernel-Treiber namens PoisonX beendet die Prozesse der Endpoint-Abwehr und entfernt deren Hooks. Die Konsole bleibt still.
- Admin-Rechte genügen. Windows lädt den signierten Treiber automatisch in den Kernel. Kein weiterer Exploit, keine CVE nötig.
- Erkennung schlägt Vertrauen. Treiber-Load-Telemetrie, die Vulnerable-Driver-Blocklist und konsequente Rechte-Minimierung greifen dort, wo die Signaturprüfung versagt.
Verwandt: Was EDR und XDR wirklich unterscheidet · Wie ein Ransomware-Angriff abläuft
Was hinter dem signierten Treiber steckt
Was ist ein BYOVD-Angriff? Bring Your Own Vulnerable Driver beschreibt eine Technik, bei der ein Angreifer mit Administratorrechten einen gültig signierten, aber fehlerhaften oder bösartigen Treiber auf das System bringt. Windows prüft die Signatur, findet sie in Ordnung und lädt den Treiber in den Kernel. Ein zusätzlicher Exploit ist nicht nötig.
Im GodDamn-Fall trägt der Treiber den Namen PoisonX und eine echte Signatur des Microsoft Windows Hardware Compatibility Publisher. Symantec betont eine Besonderheit: Klassisches BYOVD missbraucht einen legitimen, aber verwundbaren Treiber. Bei PoisonX handelt es sich dagegen um einen von vornherein bösartigen Treiber, den seine Entwickler durch die Signaturprüfung gebracht haben. Einmal geladen, terminiert er die Prozesse der installierten Endpoint-Abwehr und entfernt die User-Mode-Hooks, über die Antivirus und EDR ein System beobachten. Der Agent bleibt formal aktiv. Seine Sicht auf das Geschehen ist weg.
GodDamn selbst ist keine Neuentwicklung. Broadcom ordnet die Familie einem Akteur namens Hyadina zu und wertet sie als Nachfolger von Beast, das wiederum aus der älteren Monster-Linie hervorging. PoisonX taucht dabei nicht nur bei dieser einen Gruppe auf. Der Treiber ist bereits in anderen Werkzeugkästen dokumentiert und damit ein verbreiteter Baustein, kein Einzelfall.
Die lange Vorphase vor der Verschlüsselung
Die Verschlüsselung steht am Ende einer Kette, nicht am Anfang. In der von Symantec beschriebenen Kampagne verschafften sich die Angreifer über das Fernwartungswerkzeug AnyDesk Zugang und legten es an einem unauffälligen Ort im Benutzerprofil ab. Danach folgte ein Bündel frei verfügbarer NirSoft-Werkzeuge, um Zugangsdaten einzusammeln.
Erst dann bewegten sich die Angreifer seitlich durch das Netz, deaktivierten den Defender über dessen eigene Verwaltungsbefehle und richteten Dienste für die Persistenz ein. Bis zum Ausrollen der Ransomware waren rund zehn Systeme erreicht. Diese Vorphase dauert Stunden bis Tage. Sie ist das eigentliche Erkennungsfenster.
Warum Signaturvertrauen an seine Grenzen kommt
Die verbreitete Annahme lautet: Was signiert ist, ist vertrauenswürdig. Der PoisonX-Fall widerlegt sie. Eine gültige Signatur belegt die Herkunft eines Codes. Über seine Absicht sagt sie nichts. Sobald ein Angreifer bereits Administratorrechte hat, wird die Signatur zur Eintrittskarte in den Kernel.
Microsoft begegnet dem mit einer Sperrliste bekannter Problemtreiber und mit hypervisor-geschützter Codeintegrität. Beide Mechanismen helfen, wirken aber reaktiv. Zwischen der Entdeckung eines missbrauchten Treibers und seiner Aufnahme in die Sperrliste liegt ein Fenster. Nicht jedes System hat die Kernisolierung aktiv. Kompatibilität mit Altsoftware verzögert die Einführung zusätzlich.
Was Detection-Engineering konkret setzt
Der Hebel liegt beim Verhalten, nicht bei der Signatur. Das Laden eines Kernel-Treibers ist ein seltenes, gut beobachtbares Ereignis. Sysmon protokolliert es mit Hash, Signaturstatus und Pfad. Ein Treiber, der aus einem Benutzerordner statt aus dem Systemverzeichnis geladen wird, ist ein starkes Signal.
Ebenso verräterisch ist die Erstellung eines Kernel-Dienstes aus ungewöhnlicher Quelle sowie das plötzliche Beenden von Sicherheitsprozessen. Wer diese drei Ereignisse korreliert, sieht den Angriff, bevor die Verschlüsselung beginnt.
Sofort prüfen
- ✓Kernisolierung und Speicherintegrität (HVCI) auf den Endpunkten aktivieren, wo Hardware und Treiber es zulassen.
- ✓Microsoft Vulnerable Driver Blocklist erzwingen und um eigene WDAC-Regeln gegen bekannte Missbrauchstreiber aus LOLDrivers ergänzen.
- ✓Treiber-Load-Events (Sysmon Event 6) auf ungewöhnliche Pfade sowie die Installation von Kernel-Diensten (System-Log 7045) alarmieren.
- ✓Manipulationsschutz des EDR aktivieren, damit sich der Agent nicht einfach abschalten lässt.
- ✓Lokale Administratorrechte im Alltag entziehen, LAPS und ein Tiering-Modell durchsetzen.
Rechte-Minimierung als Voraussetzung
Alle genannten Kontrollen teilen eine Bedingung. Ohne Administratorrechte lädt kein Angreifer einen Treiber in den Kernel. Genau deshalb steht die Rechte-Minimierung am Anfang jeder wirksamen Antwort, nicht am Ende.
Konkret heißt das: keine dauerhaften lokalen Administratorrechte, Just-in-Time-Zugriff für privilegierte Aufgaben, LAPS für die lokalen Konten sowie ein Tiering, das Domänen-Administratoren von den Endpunkten fernhält. Blocklist, HVCI und Telemetrie entfalten ihre Wirkung erst, wenn breit verteilte Adminrechte den Angreifern nicht schon die halbe Arbeit abnehmen.
Häufige Fragen
Jede Frage ist verschlossen. Ein Tippen entriegelt die Antwort.
Was ist ein BYOVD-Angriff?
Bring Your Own Vulnerable Driver bezeichnet das Einschleusen eines gültig signierten, aber fehlerhaften oder bösartigen Treibers durch einen Angreifer mit Administratorrechten. Windows vertraut der Signatur und lädt den Treiber in den Kernel, wo er mit höchsten Rechten läuft.
Reicht ein aktuelles EDR gegen diese Technik?
Nicht allein. Der signierte Treiber setzt genau an der Abwehr an und entzieht ihr die Sicht. Wirksam wird die Erkennung erst in Kombination mit Manipulationsschutz, Treiber-Telemetrie und entzogenen Administratorrechten.
Schützt die Microsoft Vulnerable Driver Blocklist zuverlässig?
Sie hilft, wirkt aber reaktiv. Zwischen der Entdeckung eines Treibers und seiner Aufnahme in die Liste bleibt ein Fenster. Eigene WDAC-Regeln gegen bekannte Missbrauchstreiber schließen diese Lücke ein Stück weit.
Woran erkennt man den Angriff im Log?
Aussagekräftig sind drei Ereignisse: das Laden eines Kernel-Treibers aus einem Benutzerordner, die Erstellung eines Kernel-Dienstes aus ungewöhnlicher Quelle und das plötzliche Beenden von Sicherheitsprozessen. Korreliert ergeben sie ein klares Bild.
Was ist der wichtigste erste Schritt?
Die Reduktion breit verteilter Administratorrechte. Ohne diese Rechte lässt sich kein Treiber in den Kernel laden. Alle weiteren Kontrollen bauen darauf auf.
Lesetipps der Redaktion
LesetippWas EDR und XDR wirklich unterscheidetLesetippWie ein Ransomware-Angriff abläuftLesetippWenn Angreifer schneller sind als der Patch
Mehr aus dem MBF Media Netzwerk
cloudmagazinZum ersten Mal kann man einer KI beim Denken zusehenMyBusinessFutureKI im Mittelstand vom Pilot zur SkalierungDigital ChiefsDie IT entscheidet, ob der Spin-off sich auszahlt
Bildquelle: KI-generiert (Juli 2026)
