kaandemir993/vidar-stealer-chrome-injection-malicious-js-targeting-google-reddit-sessions-analysisReverse Engineering von Vidar Stealer: Von obfuskierten Speicher-Strings über Chrome-Prozessinjektion und bösartige JS-Ausführung bis hin zu aktiver Session-Hijacking bei Google & Reddit.
Die in Binary Ninja geladene Vidar-Stealer-Probe zeigt stark obfuskierten Code innerhalb der Funktion main.vxormo. Die Analyse ergibt, dass sich die Malware auf String-Verschlüsselung, benutzerdefinierte XOR-Routinen und Laufzeit-Speicherzusammenbau stützt, um ihr wahres Verhalten zu verbergen. Die \x00-lastigen Byte-Arrays (x00\x00\x00...) in der Pseudo-C-Ansicht deuten darauf hin, dass rohe Payload-Fragmente direkt im Speicher konstruiert werden.
Obfuskierte Funktionen: Zufällig generierte Namen wie main.vxormo, main.oqvmwusz und main.dzgsnuhm werden verwendet, um die Funktionalität zu verschleiern. Obfuskierte Strings: whatnthotsfalse... und cornbindtrue... sind verschlüsselte Strings, die zur Laufzeit aufgelöst werden. Benutzerdefinierte XOR-Routine: Der Funktionsname vxormo selbst deutet darauf hin, dass eine benutzerdefinierte XOR-Entschlüsselungsschleife aktiv ist. In-Memory-Payload-Konstruktion: Arrays mit den Bytes \x00, \x89, \x99, \x48 werden mittels _builtin_memcpy in den Speicher geschrieben. Der Zeiger uint8_t)rax zeigt, dass rohe Shellcode-/Payload-Fragmente zusammengesetzt werden.
Umgehung der statischen Analyse: Die Verwendung zufällig benannter Funktionen und verschlüsselter Strings bedeutet, dass signaturbasierte AV-Lösungen die Payload nicht identifizieren können. In-Memory-Ausführung (fileless): Die \x00-Payload wird niemals auf die Festplatte geschrieben; sie wird direkt im Speicher (RWX) alloziert und ausgeführt, wodurch Dateiscanner umgangen werden. Benutzerdefinierte XOR-Verschlüsselung: Eine benutzerdefinierte XOR-Routine verhindert einfache String-Extraktion oder YARA-Regel-Treffer. Datenverbergung: Die massiven, unlesbaren Arrays (\x00\x00\x00\x01...) sind wahrscheinlich verschlüsselte Konfigurationsblöcke (C2-URLs, Grabber-Module), die nur bei Bedarf entschlüsselt werden.
Eine zweite Ansicht der Vidar-Stealer-Probe in Binary Ninja zeigt eine Funktion (main.obttcklrlfwpzvugbzqtn), die der Systemaufklärung und anti-forensischen Bereinigung dient. Die Funktion verarbeitet verschlüsselte Strings und löst API-Namen auf, um Spuren ihrer Ausführung zu verwischen, wobei sie gezielt DNS-Caches, Ereignisprotokolle und temporäre Internetdateien anvisiert, bevor sie die endgültige Payload ablegt.
Obfuskierte API-Auflösung: Der String ...DiednsQuery_WGGetIfEntryCancelIoExCreatePipe... ist eine verschlüsselte Verkettung von WinAPI-Aufrufen Identifizierte Bereinigungs-APIs: DnsQuery_W / DnsFlushResolverCache – leert den DNS-Cache, um Spuren der C2-Domain-Auflösung zu verbergen. GetIfEntry – zählt Netzwerkschnittstellen auf (Prüfung auf Sandbox-/virtuelle Adapter). WinExec – führt dynamisch Systembereinigungsprogramme aus (z. B. cmd.exe /c del ...). Syscall-/Skriptausführung: Verweise auf dllws2_32.dll und /dev/stdin (Standard-Eingabeumleitung) deuten darauf hin, dass die Malware sich darauf vorbereitet, mit den Standard-Streams oder dem Netzwerk-Stack des Systems zu interagieren.
Anti-Forensik: Das Leeren des DNS-Caches (DnsFlushResolverCache) und das Aufrufen von Bereinigungsroutinen stellen sicher, dass Netzwerkprotokolle und lokale Artefakte zerstört werden, was die Incident Response erschwert. Sandbox-Umgehung: Das Abfragen von Netzwerkschnittstellen (GetIfEntry) ermöglicht es dem Stealer, virtualisierte Umgebungen (z. B. VMware, VirtualBox) zu erkennen und die Ausführung abzubrechen, wenn eine Sandbox erkannt wird Verschleierung des Ausführungsflusses: Die Verwendung von WinExec für die Bereinigung bedeutet, dass die Malware Lösch-APIs nicht statisch importieren muss; sie delegiert die Drecksarbeit an das Betriebssystem. Fileless-Interaktion: /dev/stdin-Umleitung und Pipe-Nutzung (CreatePipe) ermöglichen es dem Stealer, gestohlene Daten an einen injizierten Prozess oder eine Befehlsshell weiterzugeben, ohne die Festplatte zu berühren.
Die Speicheransicht von Process Hacker für den Prozess chrome.exe (PID 8944) bestätigt, dass der Vidar Stealer seine Nutzlast direkt in den Speicherbereich des Browsers injiziert hat. Der String-Scan legt mehrere Thread-Ausführungsblöcke offen, ein typisches Artefakt von Process Hollowing oder Remote-Thread-Injection. Durch die Injektion in Chrome agiert der Stealer unter einem vertrauenswürdigen Prozess mit hoher Integrität, um stillschweigend Cookies, gespeicherte Anmeldedaten und Session-Tokens zu erbeuten.
Injizierte Threads (Speicher-Strings): THREAD_BROWSER_WATCHDOG / THREAD_GPU_WATCHDOG – Watchdogs wurden gekapert, um die injizierten Threads am Leben zu halten. THREAD_CACHE_BLOCKFILE – deutet auf eine Manipulation des Chrome-Caches hin (wahrscheinlich zur Extraktion von Sitzungsdaten). THREAD_AUDIO_INPUTDEVICE / THREAD_GAMEPAD_POLLING – nicht essentielle Threads wurden zweckentfremdet, um bösartige Aktivitäten zu verschleiern. THREAD_WEBCRYPTO – höchst verdächtig; Chromes interne Krypto-API wird genutzt, um gespeicherte Passwörter und Cookies zu entschlüsseln. THREAD_PROXYRESOLVER / THREAD_DATABASE – werden genutzt, um Netzwerkverkehr abzufangen und auf die lokale Anmeldedaten-Datenbank zuzugreifen.
Diebstahl von Browser-Anmeldedaten: Das Hooking von THREAD_WEBCRYPTO und THREAD_DATABASE ermöglicht es Vidar, Chromes Verschlüsselung zu umgehen und gespeicherte Passwörter und Cookies zu stehlen. Living off the Land: Durch die Injektion in chrome.exe tarnt sich die Malware als legitimer Browser-Datenverkehr und umgeht so mühelos Firewalls und EDR-Netzwerkregeln. Process Hollowing: Das Vorhandensein von Standard-Chrome-Threads neben injizierten Threads bedeutet, dass die Malware wahrscheinlich einen legitimen Thread ausgehöhlt oder CreateRemoteThread verwendet hat. Session Hijacking: THREAD_CACHE_BLOCKFILE und die Cookie-Extraktion ermöglichen es dem Angreifer, aktive Sitzungen zu stehlen (Session Hijacking), ohne das Passwort des Benutzers zu benötigen. Evasion: Antivirus-Lösungen scannen selten innerhalb des Speicherbereichs eines signierten Browsers wie Chrome.
Ein tieferer Blick in den injizierten Speicherbereich von chrome.exe (PID 8944) offenbart eine Sammlung von Strings, die gezielt auf Google-Authentifizierungsabläufe, Reddit-Sitzungen und die JavaScript-Ausführung des Browsers abzielen. Das Vorhandensein dieser Strings bestätigt, dass der Vidar Stealer bösartiges JavaScript injiziert oder Browser-APIs hookt, um Anmeldedaten und Session-Tokens abzufangen.
