Die SLEEPWALKER Backdoor ist eine neu beschriebene Windows-Malware, die zunächst kaum auffällt: Inaktiv bleibt sie so lange, bis sie ein ganz bestimmtes Netzwerkpaket erreicht. Erst dann startet sie Befehle – und zwar nicht als lesbarer Text, sondern in einer selbst entworfenen Bytecode-Logik. Damit setzt der Code auf ein sehr gezieltes Aktivierungsprinzip, das in Sicherheitsumgebungen schnell übersehen werden kann.
Ein unabhängiger Malware-Forscher dokumentierte eine bislang nicht bekannte Backdoor, deren Verhalten auf eine geplante Operation hindeutet. Gleichzeitig ist die Attribution unklar: In den vorliegenden Angaben lässt sich kein konkreter Angreifer, kein Opferkreis, keine Branche und auch kein Land zuverlässig bestimmen.
Wie die SLEEPWALKER Backdoor startet: der speziell konstruierte Trigger
Der entscheidende Punkt ist der Aktivierungsmechanismus. Die SLEEPWALKER Backdoor liegt als DLL vor und verharrt im Normalfall ohne erkennbare Wirkung. Erst wenn ein speziell konstruiertes Paket den Rechner erreicht, reagiert die Malware. In der entschlüsselten Konfiguration steckt anschließend eine einzelne Anweisung, die die Backdoor dauerhaft an allen relevanten Netzwerkinterfaces auf den Trigger überwachen lässt.
Der Listener erfasst den Verkehr, der über die überwachten Schnittstellen läuft. Dabei geht es nicht nur um Pakete, die direkt für den betroffenen Host bestimmt sind: Auch Traffic, der an andere Maschinen adressiert ist, kann sichtbar werden. Dadurch kann selbst eine Trigger-Nachricht, die eigentlich für einen anderen Teilnehmer gedacht ist, in bestimmten Netzwerkpfaden für einen Beobachter sichtbar werden – etwa in Umgebungen mit Gateway, VPN oder Segment-Bridging.
„Sleepwalking“ durch Inaktivität im Speicher
Der Name und die Arbeitsweise passen zusammen: Die SLEEPWALKER Backdoor wird nicht sofort aktiv, sondern bleibt untätig, bis der Trigger eintrifft. Zusätzlich enthält die Datei nach den veröffentlichten Details keine eingebetteten Domains, IP-Adressen oder URLs. Auch stellt sie von sich aus keine ausgehende Verbindung her.
Für die Praxis bedeutet das: Monitoring-Lösungen, die vor allem nach Kommunikation zu bekannten „Bad“-Infrastrukturen suchen, können ein kompromittiertes System fälschlicherweise unauffällig einstufen. Das erhöht die Bedeutung von Trigger- und Host-basierten Erkennungen.
Angriffsform: Side-Loading in den ESET Management Agent
Die Malware liegt als unsignierte 64-Bit-DLL mit einer Größe von 59.904 Bytes vor. Sie ist so ausgelegt, dass sie per Side-Loading in den Windows-Prozess ERAAgent.exe eingebunden wird – dem ausführbaren Bestandteil für den ESET Management Agent.
Besonders auffällig ist dabei die Tarnung: Die DLL imitiert dpapi.dll, exportiert dieselben sieben Funktionen wie die echte Systembibliothek und trägt eine Version-Resource, die aus dem ESET Management Agent übernommen wurde. Auf diese Weise wirkt die Komponente wie ein vertrauter Bestandteil, obwohl sie bösartig ist.
Wichtig ist: In den beschriebenen Informationen wird klar, dass es sich nicht um eine Lücke im ESET-Produkt handelt, die „gepatcht“ werden müsste. Stattdessen nutzt die Side-Loading-Strategie die Windows-DLL-Suchreihenfolge. Das verschiebt den Fokus von Software-Bugs hin zu Suchpfad-Verhalten und Deployment-Prozessen.
Woran man die SLEEPWALKER Backdoor erkennt
Der Forscher veröffentlichte Host-Indikatoren, die vor allem gegen eine bekannte „Good“-Baseline bewertet werden sollten. Dazu zählen unerwartete DLL-Dateien im Umfeld von ERAAgent.exe, sowie Registry-Änderungen.
- Eine unerwartete dpapi.dll neben ERAAgent.exe
- Eine unerwartete dpapisvc.dll im selben Verzeichnis
- SHA-256: d347170752a28e2b8c4b8b9f3cab2e3a6541ba11682c94498d26eb9002779d60
- MD5: 2318327b29bb1c0e2d2b5f0211fc7fac
- Registry-Wert EveryoneIncludesAnonymous auf 1 gesetzt
- Ein unerwarteter Eintrag in NullSessionPipes
Zusätzlich werden Erkennungsregeln bereitgestellt: Eine YARA-Regel sowie ein read-only PowerShell-Scanner, der diese Indikatoren im eigenen Bestand abfragt. Der Forscher äußerte, dass die Erkennungsabdeckung für die Datei zum Zeitpunkt der Veröffentlichung niedrig gewesen sei, nannte jedoch keine konkrete Grundlage für diese Einschätzung.
Bytecode statt Klartext: Kommandos erst nach Entschlüsselung
Die SLEEPWALKER Backdoor überträgt Befehle nicht als gut lesbare Textanweisungen. Stattdessen kommen sie als Bytecode. Der Schlüssel zur Entschlüsselung ist nach den beschriebenen Details die Voraussetzung, um den Bytecode als Opcode-Format zu interpretieren.
Damit wird das Reverse Engineering zusätzlich erschwert: Die „Bedeutung“ der Opcodes existiert in der analysierten Datei selbst. Eine zweite Hürde entsteht, weil bestimmte Teile der Erkennung auf statische Schlüssel oder kompilierte Protokollcodestücke verweisen. Bei einem Neubau mit veränderten Compiler-Einstellungen könnte so eine Regel an Wirksamkeit verlieren.
Netzwerk-Transportvielfalt und Besonderheiten in Virtualisierung
Die Malware nutzt eine eigene 23-Instruktions-Sprache. Die darin enthaltenen Schritte decken unter anderem Scheduling, das Verschieben von Daten in mehreren Varianten und eine gestufte Dateilieferung ab. Bevor Code ausgeführt wird, wird die Integrität über einen SHA-256-Hash gegen eine erwartete Signatur geprüft. Außerdem sind Schritte enthalten, die Code direkt im Speicher ausführen.
Für den Transport der Trigger und Kommandos setzt die Backdoor auf mehrere Wege: TCP, UDP, ICMP, SMB benannte Pipes (inklusive „credentialed lateral movement“) sowie einen Modus für rohes Promiscuous-Capture. Zusätzlich wird auch VMCI (Virtual Machine Communication Interface) aus der Virtualisierung verwendet.
Gerade bei VMCI gibt es eine praktische Konsequenz: VMCI-Traffic läuft durch die Virtualisierungsschicht und nicht über einen klassischen Netzwerkadapter. Dadurch kann ein Paketmitschnitt „zwischen zwei Maschinen“ ins Leere laufen, weil der relevante Strom nicht dort sichtbar wird, wo man sonst Capture erwartet. Ähnliche Muster wurden in früheren Intrusionen in Bezug auf die Persistenz zwischen kompromittierten ESXi Hosts und deren Gästen beschrieben.
Trigger-Logik: Hostnamen prüfen, nicht Signaturen
Die Backdoor prüft nur den Host-Prozessnamen. Sie kontrolliert nicht die Signatur oder den Pfad. Um die DLL in das benötigte Verzeichnis zu schreiben, werden lokale Administratorrechte verlangt – die Operatorseite muss diese Berechtigung also bereits besitzen.
Entscheidend ist: Die Malware versucht nicht selbst, diese Rechte zu erlangen. Stattdessen verlässt sie sich auf den Sicherheitskontext des Prozesses, in den sie eingebunden wird. Damit wird die SLEEPWALKER Backdoor in den beschriebenen Informationen als Post-Compromise-Implant eingeordnet: Sie ist eher ein nachgelagertes Werkzeug als ein Einstiegspunkt.
Persistenz und Aufräumverhalten: Side-Loading als einzige Wiederkehr
Die Persistenzmechanik ist eng mit dem Side-Loading gekoppelt. Sobald der Dienst des Management Agents startet, wird die DLL erneut nachgeladen – also wieder eingebunden. Da das Side-Loading auf der Windows-DLL-Suchreihenfolge basiert, wird in der Darstellung kein spezifischer Produktfehler bei ESET als Ursache beschrieben.
Für die Interaktion über benannte Pipes wird die Registry angepasst: Damit unauthentifizierte Aufrufer den benannten Pipe-Zugang erreichen können, setzt die Malware EveryoneIncludesAnonymous auf 1 und ergänzt den Pipe-Namen in NullSessionPipes. Beim Cleanup protokolliert die Backdoor allerdings nur, ob ihre eigene Registry-Schreiboperation erfolgreich war – nicht, ob der Wert bereits vorher existierte. Dadurch kann ein Entfernen im Einzelfall einen legitimen Eintrag löschen, der nicht durch die Infektion verursacht wurde.
Unklar bleibt der Ursprung: Zustellung ohne Nachweis eines Einsatzes
Die Einschätzung des Forschers stützt sich auf eine einzelne Binärdatei, ohne zusätzliche Kontextinformationen. Entsprechend konnte er keine bekannte Tätergruppe zuordnen, keine Opfer identifizieren und nicht belegen, ob die Malware überhaupt in realen Umgebungen eingesetzt wurde.
Auch die Frage, wie ein Operator zuerst an die Maschine gelangte und die DLL in das passende Verzeichnis schrieb, bleibt offen. Der beschriebene Ansatz deutet zwar auf eine gezielte Operation mit Ressourcen hin, doch ohne mehr Telemetrie bleibt das Bild unvollständig.
Was jetzt wichtig ist: Incident Response und systematisches Scannen
Wenn eine Umgebung Hinweise auf die SLEEPWALKER Backdoor liefert, lautet die vorgeschlagene Konsequenz im Grunde: als bestätigten Fund behandeln, Incident Response durchführen und die betroffenen Systeme neu aufbauen. Da es laut Beschreibung keinen „einzelnen Patch“ gibt, steht die Wiederherstellung und die Bereinigung von Side-Loading-Szenarien im Vordergrund.
Praktisch hilfreich ist außerdem ein Abgleich gegen den eigenen Ausgangszustand: Viele der erwähnten Registry- und Dateiindikatoren verlieren ihre Aussagekraft, wenn man nicht weiß, wie ein „normales“ System aussieht. Genau dafür sind das Scannen gegen Indikatoren und eine Vergleichsbasis entscheidend.
Fazit
Die SLEEPWALKER Backdoor zeigt, wie Angreifer Inaktivität und Netzwerk-Trigger kombinieren können, um sich der klassischen Suche nach verdächtigen Verbindungen zu entziehen. Ihre Aktivierung hängt von einem speziell präparierten Paket ab, während sie ansonsten ohne eingebettete C2-URLs auskommt und keine ausgehende Verbindung initiiert. Zusätzlich erschwert Bytecode statt Klartext die Analyse.
Wer Windows-Systeme mit Management-Agenten betreibt, sollte daher besonders auf unerwartete DLL-Dateien im Umfeld von ERAAgent.exe sowie auf die genannten Registry- und Pipe-Indikatoren achten. Mit systematischem Scannen, sauberer Baseline-Erkennung und konsequenter Incident Response lässt sich das Risiko deutlich reduzieren.
Quelle: https://thehackernews.com/2026/08/newly-sleepwalker-backdoor-waits-for.html
