Nach SonicWall-VPN-Hack: Schutzmaßnahmen ergreifen

Sicherheitsforscher von Huntress haben Anfang Februar 2026 einen ausgeklügelten Cyberangriff dokumentiert, bei dem Angreifer kompromittierte SonicWall-Zugangsdaten ausnutzten und anschließend mithilfe eines widerrufenen Forensik-Treibers sämtliche Schutzmechanismen lahmlegen wollten. Der Vorfall zeigt eine etablierte Angriffstechnik, die seit Jahren Windows-Sicherheitslücken ausnutzt.

Einbruch über kompromittierte VPN-Credentials

Die Angreifer verschafften sich im Februar 2026 Zugang zum Zielnetzwerk über gestohlene SonicWall-SSLVPN-Anmeldedaten. Die Authentifizierungsprotokolle dokumentieren zunächst einen fehlgeschlagenen Portal-Login von der IP-Adresse 193.160.216.221, gefolgt von einer erfolgreichen VPN-Client-Verbindung über 69.10.60.250 wenige Augenblicke später. Dieses Muster deutet auf systematisches Credential-Testing hin.

Nach erfolgreicher Authentifizierung starteten die Angreifer umgehend mit der Netzwerk-Reconnaissance. SonicWall-IPS-Systeme registrierten ICMP-Ping-Sweeps, NetBIOS-Abfragen und intensive SMB-Aktivitäten mit über 370 SYN-Paketen pro Sekunde. Diese Aufklärungsphase diente der Kartierung erreichbarer Systeme im kompromittierten Netzwerk.

Grafik Quelle: Huntress

BYOVD-Technik mit EnCase-Forensik-Treiber

Das zentrale Angriffswerkzeug war eine 64-Bit-Windows-Executable, die als Firmware-Update-Tool getarnt war. Die Malware setzt auf die „Bring Your Own Vulnerable Driver“-Methode und missbraucht einen legitimen Treiber von Guidance Software (EnCase) für forensische Zwecke.

Wortlisten-basierte Verschlüsselung

Die Entwickler implementierten ein ungewöhnliches Verschlüsselungsverfahren: Statt konventioneller Kryptographie oder Kompression kommt eine Substitutionschiffre zum Einsatz, die jedes Byte in ein englisches Wort übersetzt. Ein eingebettetes Wörterbuch mit 256 Begriffen bildet die Grundlage – der Array-Index entspricht dem jeweiligen Byte-Wert.

Die verschlüsselte Treiber-Payload besteht aus 384.528 Byte leerzeichenseparierter englischer Begriffe. Beispielhaft decodiert die Sequenz „block both choice about“ zu den Hex-Werten „4D 5A 90 00“ – der charakteristischen MZ-Signatur eines Windows-PE-Headers.

Dieser Ansatz umgeht stringbasierte Erkennungsmechanismen, da die codierte Form keine verdächtigen API-Aufrufe oder Binärsignaturen enthält. Auch entropiebasierte Analysen schlagen fehl: Die Wortlisten-Verschlüsselung erreicht lediglich 4 Bit pro Byte, deutlich unter den 7-8 Bit/Byte, die üblicherweise auf gepackte oder verschlüsselte Malware hinweisen.

Systematische Ausschaltung von Sicherheitssoftware

Nach der Decodierung und Speicherung unter „C:\ProgramData\OEM\Firmware\OemHwUpd.sys“ setzt die Malware Anti-Forensik-Maßnahmen ein: Die Dateiattribute werden auf „versteckt“ und „System“ gesetzt, während Zeitstempel von ntdll.dll kopiert werden, um sich zwischen legitime Systemdateien einzufügen.

Die Binärdatei enthält 59 Zielprozessnamen von Sicherheitsanbietern, die beim Start mit dem FNV-1a-Hash-Algorithmus (Seed 0x811C9DC5) gehasht werden. Während der Ausführung listet das Tool laufende Prozesse via CreateToolhelp32Snapshot auf, konvertiert Namen in Kleinbuchstaben, berechnet deren Hash-Werte und vergleicht diese mit der vorbereiteten Liste. Dies ermöglicht schnelle Integer-Vergleiche statt zeitaufwändiger String-Operationen.

Eine kontinuierliche Kill-Schleife mit einsekundigen Intervallen stellt sicher, dass neu gestartete Sicherheitsprozesse sofort wieder terminiert werden. Zu den 59 angegriffenen Prozessen zählen Produkte aller großen EDR- und Antivirus-Hersteller – mit einer Ausnahme: Der Huntress-Agent befand sich nicht auf der Terminierungsliste.

Grafik Quelle: Huntress

Persistenz durch Dienst-Registrierung

Die Malware registriert sich als Windows-Kernel-Dienst beim Service Control Manager. Die gewählten Bezeichnungen imitieren legitime OEM-Software:

Servicename: OemHwUpd
Anzeigename: OEM-Hardware-HAL-Dienst
Beschreibung: Verwaltet die Kompatibilität der Hardware-Abstraktionsschicht
Diensttyp: Kernel-Treiber
Starttyp: Bei Bedarf

Diese Konfiguration ermöglicht das Laden in den Kernel und gewährleistet Persistenz über Systemneustarts hinweg.

Schwachstelle in der Treibersignatur-Prüfung

Seit Windows Vista x64 fordert Microsoft digitale Signaturen von vertrauenswürdigen Zertifizierungsstellen für alle Kernelmodus-Treiber. Die Driver Signature Enforcement (DSE) verhindert das Laden unsignierter oder manipulierter Treiber durch kryptografische Validierung der Signaturkette zu einem Microsoft-vertrauenswürdigen Stammzertifikat.

Eine kritische Limitation besteht jedoch: Der Kernel prüft keine Zertifikatssperrlisten (CRLs). Windows validiert zwar die mathematische Gültigkeit der Signatur und deren Herkunft, kann aber nicht feststellen, ob das Zertifikat mittlerweile widerrufen wurde. Diese Einschränkung resultiert aus praktischen Erwägungen – Treiber werden früh im Bootprozess geladen, bevor Netzwerkdienste verfügbar sind, und CRL-Checks würden die Startperformance erheblich beeinträchtigen.

Der missbrauchte EnCase-Treiber illustriert diese Lücke: Das Signaturzertifikat lief im Januar 2010 ab und wurde nachfolgend widerrufen, dennoch akzeptiert Windows die Signatur aufgrund erfolgreicher kryptografischer Validierung.

Microsofts Blocklisten-Strategie

Anstelle von CRL-Prüfungen führte Microsoft die Vulnerable Driver Blocklist ein – eine hashbasierte Deny-Liste zur Verhinderung des Ladens bekannter problematischer Treiber. Seit Windows 11 22H2 ist diese standardmäßig aktiv, wenn Hypervisor-Protected Code Integrity (HVCI) oder Memory Integrity aktiviert sind. Updates erfolgen üblicherweise ein- bis zweimal jährlich mit größeren Windows-Releases.

Dieser Ansatz bietet Präzision durch Blockierung einzelner Treiber-Hashes statt ganzer Zertifikate, funktioniert jedoch reaktiv: Ein Treiber muss erst als anfällig identifiziert, gemeldet und zur Blocklist hinzugefügt werden.

Warum der EnCase-Treiber trotzdem lädt

Das Zertifikat des verwendeten „EnPortv.sys“ ist über 15 Jahre abgelaufen und widerrufen, Windows akzeptiert es dennoch aufgrund dreier Faktoren:

Ausnahmeregel vom 29. Juli 2015: Ab Windows 10 Version 1607 müssen neue Kernel-Treiber über das Hardware Dev Center signiert sein. Zur Gewährleistung der Abwärtskompatibilität dürfen jedoch Treiber mit Zertifikaten vor diesem Datum, die mit unterstützten gegenseitig signierten Zertifizierungsstellen verknüpft sind, weiterhin geladen werden. Das EnCase-Zertifikat stammt vom 15. Dezember 2006.

Gültiger Zeitstempel: Der Treiber trägt einen Zeitstempel der Thawte Timestamping CA (VeriSign-Dienst). Bei zeitgestempeltem Code validiert Windows die Signatur gegen den Erstellungszeitpunkt, nicht das aktuelle Datum. Da die Signatur erfolgte, während das Zertifikat gültig war (vor 31. Januar 2010), bleibt sie unbegrenzt gültig.

Vertrauenswürdige Zertifikatskette: Die Signaturkette führt über VeriSign Class 3 Code Signing 2004 CA zum Microsoft Code Verification Root, dem Windows für Kernelmodus-Codesignierung vertraut.

IOCTL-Schnittstelle für Prozessbeendigung

Nach dem Laden exponiert der Treiber eine IOCTL-Schnittstelle, über die Usermode-Prozesse beliebige Prozesse direkt aus dem Kernelmodus terminieren können. Dies umgeht sämtliche Usermode-Schutzmaßnahmen inklusive Protected Process Light (PPL), das normalerweise kritische Systemprozesse und EDR-Agenten schützt.

Der EnCase-Treiber (EnPortv.sys) bietet 18 IOCTL-Funktionen für forensische Zwecke: Prozessbeendigung (KillProc), DKOM-Prozessversteckung (HideProc/UnhideProc), Kernelmodus-Dateilöschung (DeleteFile), physischen Speicherzugriff (OpenPhysicalMemory/ReadPhysicalMemory), Prozessspeicherauslesung (PidMemory) und VAD-Enumeration (GetVadList).

In diesem Vorfall nutzten die Angreifer ausschließlich IOCTL 0x223078 (KillProc). Die Usermode-Komponente öffnet einen Handle zum Gerätetreiber (\.\OemHwUpd) und übermittelt Ziel-PIDs via DeviceIoControl. Der Kernelmodus-Treiber ruft ZwOpenProcess mit PROCESS_TERMINATE-Zugriff auf, gefolgt von ZwTerminateProcess. Bei Kernelmodus-Aufrufen von Zw*-Funktionen setzt der Wrapper PreviousMode auf KernelMode, was signalisiert, dass Parameter aus vertrauenswürdiger Quelle stammen – Windows überspringt daraufhin Sicherheitsüberprüfungen, die bei Usermode-Aufrufen greifen würden.

Empfehlungen zur Absicherung

Huntress konnte den Angriff vor der Ransomware-Deployment-Phase stoppen. Die Sicherheitsforscher empfehlen folgende Maßnahmen:

Multi-Faktor-Authentifizierung: Implementierung von MFA für alle Fernzugriffsdienste. Die initiale Kompromittierung erfolgte über ein SonicWall-SSLVPN-Konto ohne Zwei-Faktor-Authentifizierung.

VPN-Log-Überwachung: Regelmäßige Analyse der Authentifizierungsprotokolle auf anomale Anmeldemuster, insbesondere fehlgeschlagene Versuche vor erfolgreicher Authentifizierung.

HVCI/Memory Integrity aktivieren: Stellt die Durchsetzung der Microsoft Vulnerable Driver Blocklist sicher.

Dienst-Monitoring: Überwachung und Alarmierung bei Erstellung von Diensten mit OEM-/Hardware-Namen außerhalb regulärer Softwarebereitstellung.

WDAC-Blockierungsregeln: Deployment der von Microsoft empfohlenen Treiberblockierungsregeln via Windows Defender Application Control.

ASR-Regel aktivieren: Die Attack Surface Reduction-Regel „Missbrauch von ausgenutzten anfälligen signierten Treibern blockieren“ verhindert, dass Anwendungen bekannte anfällige Treiber auf Festplatten schreiben.

Die dokumentierte Angriffskette mit kompromittierten VPN-Zugangsdaten und EDR-Killer-Einsatz entspricht etablierten Mustern bei Ransomware-Vorläuferaktivitäten und unterstreicht die zunehmende Professionalisierung der BYOVD-Technik in modernen Cyberkampagnen.

„Die in diesem Beitrag bereitgestellten Informationen wurden sorgfältig recherchiert, erheben jedoch keinen Anspruch auf Vollständigkeit oder absolute Richtigkeit. Sie dienen ausschließlich der allgemeinen Orientierung und ersetzen keine professionelle Beratung. Die Redaktion übernimmt keine Haftung für eventuelle Fehler, Auslassungen oder Folgen, die aus der Nutzung der Informationen entstehen.“

Auch interessant: