Die Teams von Symantec und dem Carbon Black Threat Hunter Team haben eine aktive Instanz des Rootkits Daxin auf einem kompromittierten Host der taiwanischen Tochtergesellschaft eines multinationalen Hightech-Herstellers entdeckt. Auf demselben Host wurde die bislang unbekannte Backdoor Stupig identifiziert, die einen nicht trivialen Persistenzmechanismus über den Austausch der Windows-DLL für das Tastaturlayout nutzt. Beide Samples tragen Kompilierungszeitstempel aus dem Beginn des Jahres 2013, während Telemetriedaten von der infizierten Maschine erst ab dem 12. Mai 2026 eingingen – was die Frage nach einer möglicherweise über Jahre hinweg unbemerkten Präsenz des Angreifers im Netzwerk aufwirft. Organisationen, die veraltete Versionen von Software und JDK in Produktionsumgebungen einsetzen, sollten einen Audit auf ähnliche Indikatoren einer Kompromittierung durchführen.
Technische Besonderheiten von Daxin
Daxin (srt64.sys) ist ein Windows-Treiber auf Kernel-Ebene, der von Symantec im März 2022 erstmals öffentlich dokumentiert wurde. Nach Angaben der Forscher lassen sich Hinweise auf seinen Einsatz in zielgerichteten Angriffen auf Regierungsbehörden und Betreiber kritischer Infrastrukturen seit 2013 zurückverfolgen.
Eine zentrale architektonische Besonderheit von Daxin ist der Verzicht auf direkte ausgehende Verbindungen zur Steuerinfrastruktur. Stattdessen fängt das Rootkit eingehenden TCP-Traffic ab, analysiert ihn auf bestimmte Muster und bettet die verschlüsselte Kommunikation mit dem Operator in bereits bestehende legitime Verbindungen ein. Dieser Ansatz macht die Erkennung durch Network-Monitoring-Lösungen äußerst schwierig.
Zusätzlich unterstützt Daxin nach Angaben von Broadcom eine mehrstufige Kommunikation über Ketten infizierter Hosts, was es den Operatoren ermöglicht, Systeme in isolierten Netzsegmenten zu erreichen, die physisch vom Internet getrennt sind.
Backdoor Stupig: Befehlsausführung vom Windows-Anmeldebildschirm aus
Stupig ist eine DLL-Backdoor, die unter den Namen a.dll und kbdus1.dll entdeckt wurde. Der Dateiname kbdus1.dll imitiert die legitime Microsoft-Bibliothek kbdus.dll, die für das Tastaturlayout US English zuständig ist.
Der Persistenzmechanismus von Stupig basiert auf der Registrierung als Provider für ein Tastaturlayout. Beim Systemstart lädt der Treiber win32k.sys die schädliche DLL in den Prozess winlogon.exe. Die Bibliothek gibt einen gültigen KBDTABLES-Zeiger zurück, sodass das Tastaturlayout weiterhin ordnungsgemäß funktioniert und das Modul bei der Prozessinspektion legitim wirkt.
Nach dem Start innerhalb von winlogon.exe überwacht Stupig das Eingabefeld für den Benutzernamen auf dem Windows-Anmeldebildschirm. Sobald ein Name eingegeben wird, der mit dem Präfix „stupig“ beginnt, wird die danach folgende Zeichenkette als Befehl interpretiert und mit SYSTEM-Privilegien ausgeführt. Wird nach dem Präfix kein Befehl angegeben, startet die Backdoor eine Kommandozeile mit SYSTEM-Rechten direkt auf dem Anmeldebildschirm – noch vor der Authentifizierung des Benutzers und ohne Erzeugung eines Audit-Ereignisses für die Anmeldung.
Wie Symantec und Carbon Black anmerken: „Indem sich Stupig im Windows-Anmeldeprozess verbirgt und sich als Provider für das Tastaturlayout registriert, ermöglicht es den Operatoren, Befehle mit SYSTEM-Privilegien auszuführen und Anmeldedaten bereits vor der Benutzeranmeldung zu stehlen – ein Zugriffsweg, von dem die meisten Verteidiger nichts wissen und den sie nicht überwachen“.
Zusammenhang zwischen Daxin und Stupig
Nach Angaben der Forscher wurden auf Codeebene keine direkten Überschneidungen zwischen Daxin und Stupig festgestellt. Ihre gemeinsame Verteilung auf demselben Host, die sich ergänzenden Funktionalitäten, ähnliche Entwicklungspraktiken und identische Kompilierungszeitstempel aus dem Jahr 2013 lassen jedoch vermuten, dass beide Tools von derselben Gruppe entwickelt worden sein könnten. Zuvor wurde Daxin von Forschern als Tool eingestuft, das mit einem chinesischsprachigen Akteur in Verbindung steht, die aktuelle Attribution bleibt jedoch unbestätigt.
Es ist zu berücksichtigen, dass die Aussage über eine 13-jährige unbemerkte Präsenz eine analytische Einschätzung ist, die auf Kompilierungszeitstempeln und der beobachteten Tarnung der Bedrohung basiert, nicht jedoch ein bestätigter chronologischer Fakt. Kompilierungszeitstempel können von Angreifern bewusst manipuliert werden.
Vermuteter Initialzugriffsvektor
Die genaue Art und der Zeitpunkt der Kompromittierung des Hosts sind weiterhin unbekannt. Die Forscher vermuten, dass ein veraltetes Single Sign-On (SSO)-Portal von Digiwin, das die nicht mehr unterstützten Java Development Kit (JDK)-Versionen 1.5 und 1.6 aus den Jahren 2009–2011 einsetzte, als Angriffsvektor gedient haben könnte. Diese Hypothese wird jedoch nicht durch konkret ausgenutzte Schwachstellen belegt.
Parallele Aktivität: KI-Modelle in offensiven Operationen
In einer separaten Untersuchung berichtete das Unternehmen Hunt.io über die Beobachtung eines mutmaßlich chinesischsprachigen Akteurs, der die Modelle Anthropic Claude Code und DeepSeek zur Automatisierung von Intrusionen in Regierungs- und Finanzsysteme Afghanistans, Thailands, Taiwans und der USA nutzt. Diese Schlussfolgerung basiert auf der Entdeckung eines offenen Verzeichnisses unter der Adresse 112.213.124[.]132, dessen HTTP-Header mit bekannter TencShell-Steuerinfrastruktur übereinstimmen.
Nach Angaben von Hunt.io fungierte Claude Code als Ausführungs-Engine für die agentenbasierte Steuerung von Tools, die Ausführung von bash-Kommandos und die Parallelisierung von Aufgaben, während DeepSeek-v4-pro als Reasoning-Modell zur Generierung der Angriffslogik, von Skripten und für die Entscheidungsfindung eingesetzt wurde.
Einschätzung der Auswirkungen
Der Fund von Daxin im Jahr 2026 zeigt, dass die Cyberspionageoperation nicht vollständig beendet, sondern in einen Modus verdeckter Aufrechterhaltung der Präsenz übergegangen ist. Am stärksten gefährdet sind:
- Produktionsbetriebe in Taiwan und Südostasien, insbesondere Tochtergesellschaften multinationaler Konzerne
- Organisationen, die veraltete JDK-Versionen und SSO-Portale ohne Security-Updates einsetzen
- Netzwerke mit isolierten Segmenten, in denen die mehrstufige Kommunikation von Daxin den Zugriff auf kritische Systeme ermöglichen kann
Praktische Empfehlungen
- Audit der Tastaturlayout-Provider: Überprüfen Sie die Windows-Registry auf nicht standardmäßige DLLs, die als Provider für Tastaturlayouts registriert sind. Vergleichen Sie die in winlogon.exe geladenen Module mit einer Referenzliste legitimer Microsoft-Bibliotheken.
- Suche nach Indikatoren: Prüfen Sie das Vorhandensein der Dateien srt64.sys, kbdus1.dll und a.dll im System. Achten Sie auf DLLs mit Namen, die kbdus.dll ähneln, sich aber vom Original unterscheiden.
- Überwachung des Netzwerkverkehrs: Implementieren Sie eine tiefe Analyse des TCP-Traffics, um anomale Muster innerhalb legitimer Verbindungen zu erkennen – ein Standardmonitoring ausgehender Verbindungen wird Daxin nicht aufdecken.
- Aktualisierung veralteter Software: Nehmen Sie JDK 1.5 und 1.6 sowie alle SSO-Portale, die keine Sicherheitsupdates mehr erhalten, umgehend aus dem Betrieb.
- Audit der Ereignisse am Anmeldebildschirm: Richten Sie ein Monitoring für Anmeldeversuche mit ungewöhnlichen Benutzernamen ein, insbesondere solchen, die die Zeichenfolge „stupig“ enthalten.
- Prüfung isolierter Segmente: Berücksichtigen Sie angesichts der Fähigkeit von Daxin zur mehrstufigen Kommunikation auch Hosts in als vom Internet isoliert geltenden Segmenten in Ihrem Audit.
Der Fall Daxin und Stupig zeigt, dass Werkzeuge, die vor mehr als einem Jahrzehnt kompiliert wurden, bei sorgfältig umgesetzter Tarnung weiterhin effektiv sein können. Vorrangige Maßnahme für Security-Teams ist ein gezielter Audit der Provider für Windows-Tastaturlayouts und der in winlogon.exe geladenen Module sowie die Sicherstellung, dass keine veralteten JDK-Komponenten und SSO-Portale in der Produktionsumgebung verbleiben.
