Lunex entlarvt: Ein neuer Informationsdieb, der über BYOVD verbreitet wird

Veröffentlicht am 24. September 2026

• Zusammenfassung
• Analysierte Proben
• Angriffskette
  • Phase 1: Die MSI-Datei, die sich selbst installiert
  • Phase 2: Loader / Dropper
    • Wo sind die Saiten?
    • Erweiterung von Berechtigungen
    • Den eigenen Entwurf des Kernels herunterladen
    • Die Hitliste der 20 Fahrer
  • Phase 3: Missbrauch von BYOVD
    • 12 IOCTLs, keine Zugriffskontrollen
  • Phase 4: LunexStealer, der zugleich ein C2-Agent
    • C2-Protokoll
    • Diebstahl von Anmeldedaten im Browser
    • Diebstahl von Kryptowährungs-Wallets
    • Die Hintertür, die auch nach dem Löschen bestehen bleibt
  • C2-Infrastruktur
    • Russischer Ursprung
    • 28 Panels in 13 Ländern
• Bedrohung Schauspieler
• Indikatoren für Kompromiss
  • Link zu GitHub
• Schlussfolgerung
• Referenzen

Zusammenfassung

Das Ontinue Cyber Defence Centre hat eine vierstufige Angriffskette identifiziert und rückentwickelt, die mit dem Lunex Eine „Malware-as-a-Service“-Plattform, die auf ukrainischsprachige Nutzer abzielt. Die analysierte Stealer-Binärdatei wurde am 12. September 2026 kompiliert, wobei die dazugehörige Infrastruktur kurz zuvor eingerichtet wurde, was auf eine aktive Weiterentwicklung hindeutet.

Die Angriffskette beginnt mit einer gefälschten CAPTCHA-Seite und gipfelt in der Installation eines C2-Agenten mit vollem Funktionsumfang. Der Stealer extrahiert Anmeldedaten und Informationen aus sieben Chromium-basierten Browsern, entwendet Kryptowährungs-Wallets und richtet über einen im Browser des Opfers installierten, PowerShell-basierten „Native Messaging Host“ einen dauerhaften Fernzugriff auf das Dateisystem ein.

Vor dem Einsatz des Datendiebs führt der Loader eine „Bring Your Own Vulnerable Driver“ (BYOVD)-Kette aus, die die Sicherheitsüberwachung auf Kernel-Ebene deaktiviert. Der Einsatz eines BYOVD ist zwar nicht ungewöhnlich, wird jedoch selten vor einer Payload der Endphase, wie beispielsweise einem Informationsdieb, verwendet. Dadurch kann die endgültige Payload ausgeführt werden, nachdem Callbacks von mehreren Endpunkt-Sicherheitsprodukten deaktiviert wurden.

Die Lunex-Befehls- und Kontrollplattform wurde erstmals im Rahmen einer OSINT-Recherche dokumentiert, die Luke Wilkinson von BlueTeamCoolTeam im Juni 2026 veröffentlichte. Er identifizierte sechs aktive Panels in fünf Ländern und dokumentierte die von außen sichtbaren Bedienungsmöglichkeiten der Plattform. Es gab bislang keine öffentliche technische Analyse der zugrunde liegenden Binärdateien oder der Einsatzwerkzeuge. Dieser Artikel liefert diese Analyse. Bei einer internetweiten Suche im Rahmen dieser Untersuchung wurden 28 Lunex-Bedienoberflächen in 13 Ländern identifiziert, und die Analyse des Quellcodes der Bedienoberflächen ergab russischsprachige UI-Strings sowie Funktionen eines Banking-Trojaners, die in früheren Berichten nicht behandelt wurden.

Wir gehen mit großer Sicherheit davon aus, dass diese Aktivität von einem finanziell motivierten, mit der GUS verbündeten Angreifer ausgeht, der über die Lunex-Plattform operiert. Nach unserem Kenntnisstand stellt dieser Artikel die erste öffentliche, eingehende Binäranalyse der mit Lunex verbundenen operativen Werkzeuge dar.

Analysierte Proben

Die Analyse umfasst vier Binärdateien, die eine vollständige Angriffskette bilden und zusammen mit einer ukrainischsprachigen Köderinfrastruktur auf uasputnik[.]com sichergestellt wurden. Als Übertragungsmechanismus wird eine gefälschte CAPTCHA-Seite genutzt, die das Opfer anweist, einen msiexec-Befehl auszuführen, wodurch die MSI-Datei von der URL des Angreifers im Hintergrund installiert wird.

Bühne	Datei	SHA-256	Größe
1	elita.msi (MSI-Installationsprogramm)	38E90AFFE37342EE36917CDC535FE9BF04589AFA8430EB8D1BA1016ADCFC1878	1,1 MB
2	psychedelic.exe / config.exe (LunexLoader)	bf14cd6c3328ebd08e940478b5d1da04e9e5aa576d045d41950bf4f1e2456dd8	2,3 MB
3	PDFWKRNL.sys (AMD BYOVD-Treiber, CVE-2023-20598)	6e8b49cf70bf854e8c59c7d27cefa89406caf8978461190dabb86dafcd8554e1	80 KB
4	psychedeliclove.exe (LunexStealer)	06f434695f93d7fd11eeff71358ff69fed79d310a66d993bbcc4ff979c117c90	275 KB

Die MSI-Datei ist ein 1,1 MB großes, nicht signiertes OLE-Compound-Dokument, das sich als “Vertification” von “Internal Software” ausgibt. Die absichtliche Falschschreibung entspricht dem ukrainischen Wort im Locktext. Die Eigenschaften unterdrücken den Installationsassistenten, verbergen den Eintrag unter „Programme hinzufügen/entfernen“ und konfigurieren eine benutzerdefinierte Aktion, um die Nutzlast automatisch zu starten. Das Paket benötigt keine Administratorrechte und wird in einem benutzerspezifischen Pfad unter „%LOCALAPPDATA%“ installiert.

Angriffskette

Phase 1: Die MSI-Datei, die sich selbst installiert

Das MSI-Paket “elita.msi” weist gezielte Designentscheidungen auf, die darauf abzielen, dass der Betroffene die Installation möglichst nicht bemerkt. Die Eigenschaft LIMITUI=1 unterdrückt den Standard-Assistenten des Windows Installers. Der Produktname “Vertification” ist eine plausibel wirkende Falschschreibung, keine zufällige Zeichenfolge, und entspricht dem ukrainischen Wort, das auf der Köder-Seite verwendet wird. Der Herstellername „Internal Software“ suggeriert ein Unternehmens-Tool, was den Verdacht in Unternehmensumgebungen mindert.

Das Paket wird unter %LOCALAPPDATA%\\Programme\\Interne Software\\Vertification\\ installiert, einem benutzerspezifischen Speicherort, für den keine Administratorrechte erforderlich sind und der keine UAC-Eingabeaufforderung zur Berechtigungserweiterung auslöst. Zwei Eigenschaften, ARPNOMODIFY=1 und ARPNOREPAIR=1, blenden die Schaltflächen „Ändern“ und „Reparieren“ im Eintrag „Programme hinzufügen/entfernen“ aus. Der Benutzer kann über die Standard-Windows-Oberflächen nicht mit der Installation interagieren.

Eine benutzerdefinierte Aktion vom Typ 226 an Sequenzposition 6700, unmittelbar nach “InstallFinalize” an Position 6600, startet die Nutzlast automatisch. Die Aktion wird nur bei der Erstinstallation ausgelöst, nicht jedoch bei einer Reparatur, Deinstallation oder administrativen Bereitstellung. Das in diesem Typ der benutzerdefinierten Aktion eingebettete Flag „Bei Fehler fortfahren“ bedeutet, dass die MSI-Datei eine erfolgreiche Installation meldet, selbst wenn die Ausführung der Nutzlast fehlschlägt.

Die MSI-Datei enthält außerdem eine Upgrade-Tabelle. Jede frühere Version mit demselben Upgrade-Code {2F40B8FA-6CB2-4328-B2A3-4B15A124F441} wird erkannt und deinstalliert, bevor die neue Version installiert wird. Dieser Mechanismus ermöglicht es dem Angreifer, die Payload auf zuvor kompromittierten Systemen zu aktualisieren, indem er einfach eine neue MSI-Datei mit einer erhöhten Versionsnummer verbreitet.

Die MSI-Datei enthält selbst keinen Schadcode. Keine „ServiceInstall“-Einträge. Keine Einträge in der Registrierung. Keine eingebetteten DLLs für benutzerdefinierte Aktionen. Die gesamte Persistenz und alle schädlichen Funktionen werden vollständig an die installierte Binärdatei delegiert.

Phase 2: Loader / Dropper

Loader (config.exe, ausgeliefert als psychedelic.exe) ist eine 2,3 MB große 64-Bit-Ausführungsdatei, die mit MinGW-w64 kompiliert wurde. In ihren Versionsangaben gibt sie vor, der ’Update Manager“ von Canonical Ltd. zu sein – ein Produkt, das unter Windows nicht existiert. Der Zeitstempel der Kompilierung wurde auf das Jahr 2054 gefälscht. Vor dem PE-Einstiegspunkt werden zwei TLS-Callbacks ausgeführt, was ein deutlicher Hinweis auf Malware ist. Außerdem ist jeder funktionsrelevante String in der Binärdatei verschlüsselt.

Wo sind die Saiten?

Das Ausführen von Zeichenketten auf dem Loader liefert fast nichts Brauchbares, sondern lediglich Namen von Importtabellen, die API-Referenzen des Dead-Code-Ankers und eine einzige Klartext-Zeichenkette: payload.exe. Alles andere, einschließlich API-Namen, Dateipfade, Registrierungsschlüssel, WMI-Abfragen, C2-URLs, Prozessnamen und Kernel-Symbolnamen, ist mit AES-256 im CTR-Modus verschlüsselt.

Zwei Decoder-Funktionen entschlüsseln Zeichenketten zur Laufzeit. Beide nutzen denselben 32-Byte-Schlüssel und denselben 16-Byte-IV, die im .rdata-Abschnitt eingebettet sind. Durch die Offline-Extraktion dieser Bytes konnten alle 126 verschlüsselten Zeichenketten wiederhergestellt werden, ohne die Malware auszuführen.

Eine Dead-Code-Funktion sorgt für eine zusätzliche Verschleierung der Importtabelle. Die Funktion wird nur ausgeführt, wenn GetTickCount() == 0x9E3779B9 gilt – die TEA- und XTEA-Verschlüsselungskonstante, die sich aus dem Goldenen Schnitt ableitet. Diese Bedingung ist bei normaler Ausführung mathematisch unmöglich. Der Funktionskörper ruft 55 importierte APIs mit NULL-Parametern auf, die ausschließlich dazu dienen, die Import-Adresstabelle mit Scheineinträgen aus SHELL32, WINHTTP, WS2_32, CRYPT32, GDI32 und zehn weiteren DLLs aufzublähen. Die statische Importanalyse ist von ihrer Konzeption her irreführend.

Abbildung 2: IAT-Anker für toten Code.

Erweiterung von Berechtigungen

Der Loader führt eine vierstufige Kette zur Rechteausweitung durch, die ihn von einem Prozess im Benutzermodus ohne Sonderrechte zu Zugriff auf Kernel-Ebene führt, ohne dass eine Abfrage der Benutzerkontensteuerung ausgelöst wird.

Zunächst überschreibt es die Einträge „ImagePathName“, „CommandLine“ und „InMemoryOrderModuleList“ im Prozessumgebungsblock (PEB) mit einem Pfad, der aus „GetWindowsDirectoryA“ abgeleitet wurde. Prozessanalyse-Tools erkennen eine legitime Windows-Binärdatei. Diese PEB-Tarnung ist nicht nur rein kosmetischer Natur. Sie ist eine Voraussetzung für den nächsten Schritt.

Zweitens ruft es „CoGetObject“ mit der COM-Elevation-Moniker-Zeichenkette „Elevation:Administrator!new:{3E5FC7F9-9A51-4367-9063-A120244FBEC7}“ auf. Die CLSID {3E5FC7F9-9A51-4367-9063-A120244FBEC7} entspricht dem COM-Objekt „CMSTPLUA“, einer Microsoft Connection Manager-Komponente, die in der Windows-Registrierung als „auto-elevate“ gekennzeichnet ist. COM-Objekte mit automatischer Berechtigungserweiterung können mit Administratorrechten ohne UAC-Aufforderung instanziiert werden, sofern der Aufrufer als vertrauenswürdige Windows-Binärdatei erscheint. Die PEB-Maskierung aus Schritt eins erfüllt diese Prüfung.

Drittens ruft er, sobald er mit Administratorrechten ausgeführt wird, die Funktionen „OpenProcessToken“, „LookupPrivilegeValueA“ (für „SeLoadDriverPrivilege“) und „AdjustTokenPrivileges“ auf, um die Berechtigung zum Laden von Kernel-Treibern zu aktivieren.

Viertens installiert und lädt es den BYOVD-Treiber über OpenSCManagerA, CreateServiceA und StartServiceA.

Der Loader führt außerdem eine WMI-basierte Erkennung von virtuellen Maschinen und Sandboxes durch, und zwar mithilfe von zwei ExecQuery-Aufrufen mit 16 verschlüsselten Eigenschaftsnamen. listet laufende Prozesse mit CreateToolhelp32Snapshot auf, um sie mit einer AES-verschlüsselten Sicherheits-Treiber-Blockliste mit 20 Einträgen abzugleichen, und löst etwa 30 API-Funktionen dynamisch durch Entschlüsselung von Zeichenfolgen zur Laufzeit auf. Keiner dieser API-Namen erscheint in der statischen Importtabelle.

Den eigenen Entwurf des Kernels herunterladen

Der Loader liest die Datei „C:\\Windows\\system32\\ntoskrnl.exe“, um die RSDS-PDB-GUID aus dem PE-Debug-Verzeichnis zu extrahieren. Diese GUID ist für den jeweiligen Windows-Kernel-Build auf dem Zielrechner eindeutig. Anschließend startet der Loader die Datei „curl.exe“ mit einem sorgfältig zusammengestellten Befehl:

Der User-Agent „Microsoft-Symbol-Server/10.1700.661.0“ ahmt legitimen Datenverkehr zur Windows-Symbolauflösung nach. Die URL zielt auf den offiziellen Symbol-Server von Microsoft ab. Für einen Netzwerkmonitor erscheint diese Verbindung als Routinevorgang. Die heruntergeladene PDB-Datei „ntkrnlmp.pdb“, die Kernel-Debugging-Symbole, enthält exakte Strukturoffsets und Typdefinitionen für die aktuell ausgeführte Windows-Version.

Der Loader ordnet die PDB-Datei im Speicher zu und analysiert sie mithilfe von acht APIs aus der dbghelp.dll: SymInitialize, SymLoadModuleEx, SymFromName, SymGetTypeInfo, SymGetTypeFromName, SymCleanup, SymUnloadModule64 und SymSetOptions. Er löst 15 Kernel-Symbole auf, darunter „PspCreateProcessNotifyRoutine“, „PspCreateThreadNotifyRoutine“, „PspLoadImageNotifyRoutine“, „ActiveProcessLinks“, „Token“, „Protection“, „SignatureLevel“ und „CallbackListHead“. Die resultierenden Offsets werden in sieben globalen Variablen gespeichert und dazu verwendet, Kernel-Callback-Tabellen, Benachrichtigungsketten und Felder der Prozessstruktur zu lokalisieren. Diese Technik ist versionsunabhängig: Sie funktioniert auf jedem Windows 10- oder Windows 11-Build, da die Offsets für den laufenden Kernel stets korrekt sind.

Die Hitliste der 20 Fahrer

Die Hitliste der 20 Fahrer

Der Loader enthält ein mit AES-256-GCM verschlüsseltes Overlay mit einer Größe von 2 MB (91% der gesamten Dateigröße). Das Authentifizierungs-Tag „bd8edd25bcf7717b“ ist fest einprogrammiert. Der Entschlüsselungsschlüssel leitet sich aus Konstanten im .rdata-Abschnitt ab. Nach der Entschlüsselung ergibt sich eine 80.536 Byte große Datei, bei der es sich um einen nativen x64-Kernel-Treiber handelt.

Vor der Bereitstellung des Treibers überprüft der Loader laufende Prozesse und Kernel-Module anhand einer Blockliste mit 20 Einträgen, wobei alle Einträge mit AES-256-CTR verschlüsselt sind. Jeder Treibername wurde durch Offline-Schlüsselextraktion ermittelt:

#	Fahrer	Anbieter
1	WdFilter.sys	Microsoft Defender
2	MsSecFlt.sys	Microsoft-Sicherheitsereignisse
3-8	klif.sys, klflt.sys, klam.sys, klark.sys, kneps.sys, klhk.sys	Kaspersky (6 Treiber)
9-11	dwprot.sys, drwebmon.sys, SpIDer.sys	Dr.Web (3 Treiber)
12-14	eamonm.sys, ekbdflt.sys, epfwwfp.sys	ESET (3 Treiber)
15	elastic-endpoint-driver.sys	Elastisch
16	SysmonDrv.sys	Sysinternals
17-18	CrowdStrike.sys, csagent.sys	CrowdStrike
19	SentinelMonitor.sys	SentinelOne
20	fltMgr.sys	Windows-Filtermanager

Eintrag 20, „fltMgr.sys“, ist der Windows Filter Manager selbst. Das Entfernen von Hooks aus diesem Treiber würde alle auf Minifiltern basierenden Sicherheitsprodukte gleichzeitig deaktivieren, unabhängig vom Hersteller. Die Zusammensetzung der Blockliste, in der 45% neben westlichen EDR-Lösungen auch auf russische und GUS-Antivirenprodukte abzielt, passt zu einem kommerziellen Tool, das für eine breite geografische Anwendbarkeit konzipiert ist. Die Zusammensetzung der Blockliste, in der 45% neben westlichen EDR-Lösungen auch auf Antivirenprodukte aus Russland und der GUS abzielt, passt zu einem kommerziellen Tool, das für eine breite geografische Anwendbarkeit konzipiert ist.

Phase 3: Missbrauch von BYOVD

Die mit AES-256-GCM verschlüsselte Nutzlast wurde als „Bring Your Own Vulnerable Driver“ (BYOVD) in der Datei „PDFWKRNL.sys“ von AMD entdeckt, dem Treiber für das USB-C-Power-Delivery-Firmware-Update-Dienstprogramm. Die Binärdatei ist über die Signaturkette AMD → Sectigo → USERTrust → Microsoft Code Verification Root mit Authenticode signiert. Sie wurde mit Microsoft Visual Studio 2022 kompiliert; der Zeitstempel der Kompilierung, Dezember 2022, stimmt mit dem Build überein. Anhand der Versionsinformationen lässt sich feststellen, dass es sich um ein legitimes AMD-Produkt handelt.

Die Datei wurde nach der Signierung verändert. Der aus dem PE-Image berechnete Authentihash stimmt nicht mit dem in der Signatur eingebetteten Digest überein. Trotz dieser Manipulation lädt Windows den Treiber, da die Zertifikatskette gültig ist und der Zeitstempel der Gegen-Signatur innerhalb der Gültigkeitsdauer des Zertifikats liegt.

12 IOCTLs, keine Zugriffskontrollen

Der Treiber registriert ein Gerät unter \\\\.\\PdFwKrnl und verarbeitet IRP_MJ_DEVICE_CONTROL mithilfe einer switch-Anweisung für 12 IOCTL-Steuercodes. Auf keinem Pfad werden Zugriffskontrollen durchgeführt. Jeder Prozess im Benutzermodus, der über ein Handle für das Gerät verfügt, hat uneingeschränkten Zugriff auf alle Operationen.

Abbildung 3: IRP_MJ_DEVICE_CONTROL-Handler von PDFWKRNL.sys

IOCTL	Betrieb	Zweck
0x80002028	Kernel-Speicherauslesung	Kopiert Einträge aus der Kernel-Callback-Tabelle in einen Puffer im Benutzermodus
0x80002014	Schreiben in den Kernel-Speicher	Kopiert Nullen in die Einträge der Callback-Tabelle, die zu Sicherheitsprodukten gehören

Beide IOCTLs werden über dieselbe SIMD-optimierte Speicherkopierfunktion geleitet. IOCTL 0x80002028 kopiert Daten aus dem Kernelbereich in einen Puffer im Benutzermodus. IOCTL 0x80002014 kopiert Daten aus dem Benutzermodus an eine Kerneladresse. Der Loader nutzt das Lese-IOCTL, um den Inhalt der Callback-Tabelle abzurufen, ermittelt über K32GetDeviceDriverBaseNameA, welches Kernelmodul zu jedem Eintrag gehört, gleicht den Modulnamen mit der Blockliste mit 20 Einträgen ab und setzt übereinstimmende Einträge über das Schreib-IOCTL auf Null.

Die Sicherheitslücke ist ein Konstruktionsfehler im IOCTL-Handler und kein Fehler, der die Ausführung von Code ermöglicht. CVE-2023-20598 beschreibt dieses Fehlen von Zugriffskontrollen. Der Treiber ist auf LOLDrivers katalogisiert. Öffentliche Proof-of-Concept-Exploits sind seit 2023 verfügbar. ESET identifizierte PDFWKRNL.sys in seiner EDR-Killer-Studie vom März 2026 als aktiv missbrauchte Datei. Was diese Lunex-Kampagne auszeichnet, ist die Integration von PDFWKRNL.sys in eine mehrstufige Verteilungskette mit PDB-gesteuertem Callback-Zeroing anstelle einer blinden Prozessbeendigung.

Phase 4: LunexStealer, der gleichzeitig als C2-Agent fungiert

Nachdem die Kernel-Callbacks auf Null gesetzt wurden, lädt Loader die endgültige Payload von http://107.175[.]82[.]242:9000/wilow/psychedeliclove.exe herunter. Diese Binärdatei, die wir als „LunexStealer“ bezeichnen, ist eine 281 KB große 64-Bit-Ausführungsdatei, die am 12. September 2026, zwei Tage vor dem Vorfall, mit MinGW-w64 kompiliert wurde. Sie enthält 11 PE-Abschnitte, 169 Importe in 11 DLLs sowie eine eingebettete 2.124-Byte-JSON-Konfiguration in einem benutzerdefinierten .embed-Abschnitt.

C2-Protokoll

LunexStealer kommuniziert über HTTP mit dem Lunex-Panel unter der Adresse 193.178.159[.]128, wobei die Authentifizierung über einen API-Schlüssel erfolgt. Die Exfiltrations-API läuft auf Port 8080. Das Operator-Panel läuft auf Port 8000. Das Protokoll folgt einem strukturierten Ablauf: Initialisierung, Entschlüsselung der Konfiguration, Erfassung des Maschinen-Fingerabdrucks anhand von 17 gesammelten Feldern, Check-in mit Kill-Switch-Prüfung, Diebstahl von Anmeldedaten und Wallets mit strukturierter Exfiltration sowie fortlaufende Aufgabenabfrage mit zufälligen Heartbeat-Intervallen.

Endpunkt	Verfahren	Zweck
/api/v1/checkin	BEITRAG	Erstregistrierung mit System-Fingerabdruck; Kill-Switch bei Statuscode 2
/api/v1/agent/config	GET	Dynamische Konfigurationsaktualisierung mit 11 aktivierbaren Feldern
/api/v1/agent/ping	GET	Heartbeat-Beacon mit einem zufälligen Jitter von 20 bis 25 Sekunden
/api/v1/agent/tasks	GET	Aufgabenabfrage für Befehle zum Herunterladen und Ausführen
/api/v1/agent/tasks//ack	BEITRAG	Bestätigung des Auftragsabschlusses
/api/v1/ext/passwords	BEITRAG	Gestohlene Anmeldedaten im JSON-Format
/api/v1/ext/tokens	BEITRAG	Session-Cookies und Authentifizierungstoken im JSON-Format
/api/v1/ext/wallets	BEITRAG	Wallet-Daten als mehrteilige Formular-Daten mit ZIP-Komprimierung

Alle Anfragen enthalten einen X-API-Key-Header mit dem Wert „c9daf8dbafc5e1f63e4af742a14a8a6669365e106ab0247ab366621bbc1f6967“ sowie einen Mozilla/5.0 User-Agent. Zu den API-CORS-Headern gehört außerdem „X-Clipper-HWID“, was darauf hindeutet, dass das Lunex-Panel neben dem st auch Malware unterstützt, die die Zwischenablage kapert.

Diebstahl von Anmeldedaten im Browser

LunexStealer zielt auf sieben Chromium-basierte Browser ab: Google Chrome, Microsoft Edge, Brave, Yandex Browser, Opera, Opera GX und Vivaldi. Der Datendiebstahl verläuft bei allen Zielen nach einem einheitlichen Muster. Der Browserprozess wird mit dem Befehl „taskkill /F /IM /T“ beendet, um die Sperren für die SQLite-Datenbankdateien aufzuheben. Die Datenbanken „Login Data“, „Login Data For Account“, „Web Data“ und „Cookies“ werden zur weiteren Verarbeitung in eine temporäre Datei namens „wd_tmp.db“ kopiert.

Die Binärdatei bindet die SQLite-Bibliothek nicht ein. Sie implementiert einen benutzerdefinierten B-Tree-Seiten-Parser, um Browser-Datenbanken direkt auszulesen. Dadurch wird eine Abhängigkeit beseitigt, auf die eine signaturbasierte Erkennung abzielen könnte, und der Import-Umfang der Binärdatei wird reduziert.

Die Extraktion des Verschlüsselungsschlüssels unterstützt drei Chrome-Versionen. Version 10 verwendet AES-GCM mit einem DPAPI-geschützten Hauptschlüssel, der aus dem Feld „encrypted_key“ in der JSON-Datei „Local State“ des Browsers abgerufen und über „CryptUnprotectData“ entschlüsselt wird. Version 11, Chromes im Juli 2024 eingeführte „App-Bound Encryption“, erfordert eine COM-basierte Prozessinjektion: Der Stealer generiert zur Laufzeit x64-Shellcode, erstellt einen angehaltenen Chrome-Unterprozess und injiziert Shellcode, der „CoInitializeEx“, „CoCreateInstance“ und „CoSetProxyBlanket“ aufruft, um mit dem IElevator-COM-Dienst von Chrome zu interagieren und den „app_bound_encrypted_key“ abzurufen. Version 20 verwendet die authentifizierte Verschlüsselung mit ChaCha20-Poly1305, dem neuesten Verschlüsselungsformat von Chrome. Die meisten öffentlich dokumentierten Stealer-Familien enden bei Version 11. Kreditkartendaten aus der Web-Datenbank sowie Einträge aus der automatischen Formularausfüllung werden ebenfalls erfasst.

Diebstahl von Kryptowährungs-Wallets

Der Stealer listet fünf Desktop-Kryptowährungs-Wallets auf – Bitcoin Core, Litecoin, Exodus, Atomic Wallet und Electrum – sowie vier Browser-Erweiterungs-Wallets: MetaMask, MetaMask Legacy, OKX Wallet und SafePal Wallet. Der Zugriff auf die Daten der Erweiterungen erfolgt über die Pfade „IndexedDB\\chrome-extension__0.indexeddb.leveldb“ und „Local Extension Settings“. Alle Wallet-Daten werden mithilfe eines benutzerdefinierten ZIP-Generators mit rohen PK-Headern und ohne Abhängigkeit von Komprimierungsbibliotheken in die Datei „wallet.zip“ komprimiert und anschließend über einen Multipart-Form-Data-POST an /api/v1/ext/wallets exfiltriert.

Die Hintertür, die auch nach dem Löschen bestehen bleibt

Der Persistenzmechanismus des Stealers ist die aus operativer Sicht wichtigste Komponente. Er richtet drei unabhängige Persistenzkanäle ein.

Bei der Benutzeranmeldung wird über die Funktionen `RegCreateKeyExW` und `RegSetValueExW` ein Registrierungsschlüssel vom Typ „Run“ mit dem Wertformat „UserStarts “ geschrieben. Über die COM-Schnittstelle des Taskplaners wird eine versteckte geplante Aufgabe mit dem Namen „psychedelicloveUtils“ erstellt, die so konfiguriert ist, dass sie bei der Benutzeranmeldung ausgeführt wird.

Der dritte Kanal ist der beständigste. Der Stealer schreibt einen Registrierungsschlüssel unter „HKCU\\Software\\Google\\Chrome\\NativeMessagingHosts\\com.lunex.explorer“ sowie einen identischen Schlüssel für Microsoft Edge. Dadurch wird ein „Chrome Native Messaging Host“ registriert, ein Mechanismus, der dafür vorgesehen ist, dass legitime Browser-Erweiterungen mit nativen Anwendungen kommunizieren können. Der Host wird durch ein 13.200 Byte großes PowerShell-Skript unterstützt, das in den .rdata-Abschnitt eingebettet ist und das Chrome Native Messaging-Protokoll über Standard-Ein- und -Ausgabe implementiert.

Das Skript bietet sechs Dateisystemaktionen:

Aktion	Fähigkeit
list_drives	Alle Laufwerksbuchstaben von C bis Z auflisten
list_dir	Verzeichnisinhalt mit Dateigrößen auflisten
read_file	Beliebige Dateien in Blöcken von 512 KB lesen, bis zu 524 MB
schreiben	Beliebige Daten in einen beliebigen Dateipfad schreiben
Herunterladen	Dateien aus dem System herunterladen
laufen	Beliebige Programme ausführen

Der NMH läuft im Prozesskontext von Chrome. Er überdauert das Löschen der Stealer-Binärdatei, Systemneustarts und Browser-Neustarts. Ein Incident-Responder, der die ausführbare Stealer-Datei identifiziert und entfernt, aber die Registrierungen des Native Messaging Host nicht überprüft, gewährt dem Angreifer weiterhin vollen Zugriff auf das Dateisystem über den Browser. Ein Mutex namens „Local\\psychedeliclove-guard“ verhindert mehrere Stealer-Instanzen.

Der Stealer schleust zudem eine bösartige Chrome-Erweiterung ein, indem er die sicheren Einstellungen von Chrome manipuliert. Ein HMAC-Bypass extrahiert einen Startwert, berechnet den MAC-Baum rekursiv neu, entfernt Integritäts-Hash-Einträge und aktiviert den Entwicklermodus. Das in der JSON-Konfiguration eingebettete Erweiterungsmanifest legt Berechtigungen für Cookies, Verlauf, Lesezeichen, Tabs, Speicher, Proxy, Skripting, „declarativeNetRequest“ sowie alle HTTP- und HTTPS-URLs fest. Diese Kombination verschafft der Erweiterung vollständige Einblicke in die Browseraktivitäten und die Kontrolle darüber.

Die Binärdatei nutzt mehrere Techniken, die über die typische Komplexität von Stealern hinausgehen. Die hashbasierte API-Auflösung nach dem FNV-1a-Verfahren, ähnlich wie beim Beacon von Cobalt Strike, vermeidet API-Namenszeichenfolgen im Klartext im Speicher. Die Binärdatei extrahiert rohe Systemaufrufnummern direkt aus der ntdll.dll, um direkte Systemaufrufe durchzuführen und so EDR-Hooks im Benutzermodus zu umgehen. Durchgängig maßgeschneiderte Implementierungen – darunter ein handgeschriebener JSON-Parser mit Linked-List-Dictionaries, ein SQLite-B-Tree-Seitenleser, ein ZIP-Builder mit rohen PK-Headern sowie eine COM-basierte Extraktion von „Shell.Application“ – eliminieren Abhängigkeiten von externen Bibliotheken, auf die eine signaturbasierte Erkennung abzielen könnte. Eine vollständige Ghidra-Dekompilierung über 275 Funktionen hinweg ergab 992 KB Pseudocode.

C2-Infrastruktur

Die Kampagne wurde über drei Hosts bei verschiedenen Anbietern in unterschiedlichen Ländern betrieben. Der Payload-Server unter der Adresse 107.175.82[.]242 (OneProvider, Seattle) stellte LunexStealer auf Port 9000 bereit und wurde über EasyPanel, ein selbst gehostetes Dashboard zur Serververwaltung, verwaltet. Der Exfiltrationsserver unter der Adresse 193.178.159[.]128 (UFO Technologies, Roubaix, Frankreich) hostete vier Dienste: das Lunex-Bedienfeld auf Port 8000, die REST-API auf Port 8080, eine öffentlich zugängliche phpMyAdmin-Instanz 5.2.3 auf Port 8081, bei der der MySQL-Root-Benutzer im Anmeldeformular sichtbar war, sowie SSH. Die Auslieferungsdomain uasputnik[.]com wurde zu einem Shared-Hosting-Server in Warschau, Polen, aufgelöst, der sich am selben Standort befand wie eine Domain, deren Name das russische Wort “Vostok” enthielt.”

Beide C2-Hosts wiesen denselben SSH-HASSH-Fingerabdruck auf, was bestätigt, dass ein einziger Betreiber beide Server mit denselben Bereitstellungstools verwaltete. An keinem C2-Port war TLS konfiguriert. Die phpMyAdmin-Instanz ermöglichte einen direkten, nicht authentifizierten Datenbankzugriff. Die Sicherheit der Infrastruktur des Betreibers war mangelhaft und stand in starkem Kontrast zur technischen Raffinesse des Loaders. Diese Diskrepanz – fortschrittliche Malware-Technik gepaart mit amateurhaftem Infrastrukturmanagement – deutet entweder darauf hin, dass Entwicklung und Betrieb von unterschiedlichen Personen durchgeführt wurden, dass die Infrastruktur als Einweglösung konzipiert war oder beides.

Abbildung 5: Die Anmeldeseite des Lunex C2-Bedienfelds läuft auf Port 8000

Russischer Ursprung

Eine Analyse des Lunex-Panel-Frontends (eine von nginx bereitgestellte React-Single-Page-Anwendung) ergab ein 453 KB großes JavaScript-Bundle, das die gesamte Bedienoberfläche enthält. Das Internationalisierungs-Framework des Panels (i18next) lädt Russisch als Standard-Locale. Es sind über 150 russischsprachige UI-Strings eingebettet, darunter Meldungen im Leerzustand (“Ботов пока нет – подключи установщик с API-ключом” / Noch keine Bots – Verbinde den Installer mit einem API-Schlüssel), Fehlermeldungen (“Неверный логин или пароль” / Ungültiger Benutzername oder Passwort) sowie Funktionsbezeichnungen (“Команд в очереди” / Befehle in der Warteschlange). Die Sprachauswahl listet “Русский” (Russisch) als primäre Option auf. Ein Platzhalterbeispiel in der Spoofing-Konfiguration des Browsers verwendet “ya.ru”, die Startseite von Yandex Russland, als Zieldomäne. Das Panel wurde von und für russischsprachige Betreiber entwickelt.

Wir haben außerdem festgestellt, dass eine der IP-Adressen, auf denen Lunex gehostet wird, über ein Bedienfeld verfügt, das vermutlich speziell für den Entwickler bzw. Betreiber bestimmt ist, und die Versionsnummer auf dem Bildschirm deutet darauf hin, dass sich das System noch in der Entwicklung befindet.

28 Panels in 13 Ländern

Bei einer internetweiten Suche wurden 28 einzigartige Lunex-Panels in 13 Ländern identifiziert – eine deutliche Zunahme gegenüber den sechs Panels, die BlueTeamCoolTeam im Juni 2026 dokumentiert hatte. Russland beherbergt die meisten Panels (6), gefolgt von den Vereinigten Staaten (4), dem Vereinigten Königreich (3) sowie den Niederlanden, Frankreich, Deutschland, der Türkei und Bangladesch (jeweils 2). UFO Technologies in Krasnogorsk (Region Moskau) beherbergt vier Panels und bildet damit den am stärksten konzentrierten Cluster. Eines dieser Panels (193.178.158.61) befindet sich im selben /24-Netzwerk wie der in dieser Analyse untersuchte Exfiltrationsserver, was auf eine gemeinsame Infrastruktur des Betreibers hindeutet. ZORNTECH, das die Auslieferungsdomain uasputnik[.]com betreibt, hostet zudem ein Panel unter einer separaten IP-Adresse.

Ein Panel in der Türkei (103.101.85[.]123) wurde identifiziert, das auf fünf Phishing-Domains verweist: account-sams-club[.]com, teamwork-recover-password[.]com, namshi-uae[.]com, whatsappbusineses[.]com und ibraq-perfumes[.]com. Dies bestätigt, dass Lunex neben dem Diebstahl von Anmeldedaten auch für Markenimitationen und Phishing genutzt wird, was mit den im Quellcode des Servers identifizierten Funktionen für Web-Injects und Browser-Spoofing übereinstimmt.

Der Zeitplan für die Infrastruktur spiegelt ein hohes Tempo wider. Der Netzwerkblock wurde im Juli 2026 zugewiesen. Das Lunex-Panel wurde am 11. September bereitgestellt. LunexStealer wurde am 12. September kompiliert. Bei der Analyse am 15.09.2026 wurde bestätigt, dass beide C2-Server in Betrieb waren.

Angreifer

Wir gehen mit großer Sicherheit davon aus, dass die Lunex-Plattform von einem russischsprachigen Entwickler oder einem russischsprachigen Entwicklerteam entwickelt und an mehrere unabhängige kriminelle Akteure verkauft wurde. Das Frontend des Panels enthält über 150 russischsprachige UI-Strings, die über ein Internationalisierungs-Framework als Standard-Locale geladen werden und nicht als Übersetzungsebene über dem Englischen. Die Sprachauswahl listet “Русский” als primäre Option auf. Ein Platzhalter in der Konfiguration zur Browser-Fälschung verwendet “ya.ru” (die Startseite von Yandex Russland) als Standard-Zieldomäne – ein Verweis, der nur für einen russischsprachigen Entwickler naheliegend ist. Die höchste Konzentration an Panels (6 von 28) wird bei UFO Technologies in Krasnogorsk, einer Satellitenstadt von Moskau, gehostet, was darauf hindeutet, dass der Entwickler von der Region Moskau aus operiert oder dort Infrastruktur bereitstellt. Die Malware-Technik, einschließlich maßgeschneiderter AES-256-Implementierungen, PDB-gesteuerter Kernel-Symbolauflösung und einer in der öffentlichen Literatur nicht dokumentierten „Dead-Code“-IAT-Anker-Technik, lässt eher auf einen erfahrenen Entwickler als auf einen MaaS-Kunden schließen.

Die 28 in 13 Ländern identifizierten Panels, der Endpunkt für die Selbstregistrierung sowie das Vorhandensein mehrerer Stealer-Codebasen (Rust, C, .NET), die mit derselben Panel-Architektur verbunden sind, deuten darauf hin, dass die Plattform mehrere unabhängige Betreiber bedient. Der in dieser Analyse identifizierte Betreiber, der durch das Konfigurations-Tag “Psychedelic” gekennzeichnet ist, zielte über einen gefälschten CAPTCHA-Köder auf uasputnik[.]com auf ukrainischsprachige Nutzer ab. Die Auslieferungsdomain befindet sich zusammen mit einer Domain, die das russische Wort “Vostok” (Osten) enthält, auf einem Shared-Hosting-Server in Warschau. Die MinGW-w64-Toolchain und die Blockliste für Sicherheitstreiber (45%, die auf Kaspersky und Dr.Web abzielt) deuten auf einen kriminellen Betreiber aus der GUS-Region hin. Ein separater Betreiber scheint das in der Türkei ansässige Panel hinter fünf Phishing-Domains zu betreiben, die auf Marken aus dem Westen und dem Nahen Osten abzielen (Sam’s Club, Teamwork, Namshi, WhatsApp) – eine völlig andere Zielausrichtung als bei der ukrainischen Phishing-Masche. Die beobachtete mangelhafte OPSEC der Infrastruktur – kein TLS, offen zugängliches phpMyAdmin mit Root-Zugriff, Wildcard-CORS – steht im Kontrast zur technischen Qualität der Entwickler und deutet auf eine Trennung zwischen den Entwicklern, die die Plattform erstellen, und den Betreibern, die die Kampagnen durchführen, hin.

Die in LunexStealer vorhandene Umgehung der Integritätsprüfung der Chrome Secure Preferences ließ zunächst einen möglichen Zusammenhang mit dem SUPERSTOMP-Tool von APT31 vermuten, das von Volexity am 9. September 2026 dokumentiert wurde. Wir haben diese Einschätzung anschließend heruntergestuft. Im September 2026 wurden mindestens vier unabhängige Implementierungen desselben Umgehungsmechanismus in voneinander unabhängigen Operationen identifiziert, was darauf hindeutet, dass sich die Technik weit verbreitet hat. Der Umgehungsmechanismus ist somit kein verlässlicher Indikator mehr für staatlich geförderte Aktivitäten.

BlueTeamCoolTeam dokumentierte die Lunex-Plattform im Juni 2026 mittels OSINT-Panel-Mapping und identifizierte dabei sechs Panels in fünf Ländern. Bei einer internetweiten Überprüfung im Rahmen dieser Untersuchung wurden 28 einzigartige Panels in 13 Ländern identifiziert, was ein deutliches Wachstum der operativen Reichweite der Plattform belegt. Im Rahmen ihrer Untersuchung dokumentierten sie einen auf Rust basierenden Stealer. Der in dieser Analyse untersuchte Stealer wurde mit MinGW-w64 in C kompiliert. Mehrere Codebasen, die mit derselben Panel-Architektur verbunden sind, untermauern die Einschätzung, dass es sich bei Lunex um eine Plattform handelt, die an Betreiber verkauft wird, und nicht um eine einzelne Malware-Familie.

Indikatoren für Kompromisse

Indikatoren hier: https://github.com/ontinue-research/threat-intel-iocs/blob/main/Public/LunexMalware/2026-09-22-LUNE…

Schlussfolgerung

Diese Analyse stellt die erste öffentlich zugängliche, eingehende Binäranalyse der operativen Tools der Lunex-Plattform dar und deckt eine Plattform auf, deren Fähigkeiten deutlich über das bisher Bekannte hinausgehen. Was in früheren OSINT-Untersuchungen als Verwaltungs-Panel für Stealer dokumentiert wurde, entpuppt sich bei genauerer Betrachtung als voll ausgestattete Crimeware-Plattform mit Web-Inject-Verwaltung, Browser-Spoofing, Fernsteuerung des Browsers und dauerhaftem Zugriff auf das Dateisystem über Chrome Native Messaging Hosts. Das Panel wurde von russischsprachigen Entwicklern erstellt, wird über 28 identifizierte Panels in 13 Ländern betrieben und wird aktiv sowohl für den Diebstahl von Anmeldedaten als auch für Phishing-Angriffe durch Markenimitation genutzt.

Die BYOVD-Ausführungskette, die anstelle einer Prozessbeendigung ein PDB-gesteuertes Zurücksetzen von Kernel-Callbacks nutzt, stellt einen unauffälligeren Ansatz zur EDR-Neutralisierung dar, bei dem Sicherheitsprodukte zwar weiterlaufen, jedoch blind sind. Validierte Tests haben gezeigt, dass weder HVCI noch die aktuelle „Microsoft Vulnerable Driver Blocklist“ das Laden der in dieser Kette verwendeten spezifischen Variante von „PDFWKRNL.sys“ verhindern – eine Lücke, die trotz der Erfassung des Treiber-Hashes im LOLDrivers-Projekt seit März 2026 weiterhin besteht.

Für Sicherheitsverantwortliche ist die entscheidende Erkenntnis, dass sich die Erkennung auf die Phasen konzentrieren muss, bevor die EDR-Blindheit eintritt: PDB-Downloads aus Nicht-Entwicklungsprozessen, das Ablegen von Treibern in temporären Verzeichnissen und die Erstellung von Diensten für nicht signierte Treiber aus nicht standardmäßigen Pfaden. Nach dem Einsetzen der Blindheit ist der Registrierungsschlüssel „Native Messaging Host“ (NativeMessagingHosts\com.lunex.explorer) der zuverlässigste Indikator für eine Kompromittierung und muss neben der Stealer-Binärdatei, der geplanten Aufgabe und dem „Run“-Schlüssel in jeden Behebungsumfang einbezogen werden.

Referenzen

• BlueTeamCoolTeam, “Das Panel hinter der Aufgabe: OSINT zu einem aktiven Lunex-Stealer-Netzwerk”, 13. Juni 2026. https://blueteam.cool/posts/lunex-c2-osint/
• ESET, “EDR-Killer erklärt: Mehr als nur die Treiber”, 19. März 2026. https://welivesecurity.com/en/eset-research/edr-killers-explained-beyond-the-drivers
• Volexity, “Mind the Patch Gap: Mehrere chinesische Angreifer verketten 0-Day-Exploits in Chrome und Windows”, 9. September 2026. https://www.volexity.com/blog/2026/09/09/mind-the-patch-gap-multiple-chinese-threat-actors-chain-0-day-exploits-in-chrome-windows/
• Proofpoint, “Unpacking Cruciferra: Eine Analyse eines ausgeklügelten Crypter-Dienstes”, Juli 2026. https://www.proofpoint.com/us/blog/threat-insight/unpacking-cruciferra-analysis-sophisticated-crypter-service