Vidar-Malware: Angriff auf Azure-Anmeldedaten und Entschlüsselungsanalyse von Chrome v20

Zusammenfassung

Dieser Bericht dokumentiert einen technischen Tiefgang von Vidar Stealer 2.0 durch systematische statische Analyse. Die Untersuchung offenbart den gesamten Arbeitsablauf der Malware, von HTTP-Exfiltrationsprotokollen bis hin zu Mechanismen zum Diebstahl von Anmeldeinformationen. Was diese Version auszeichnet, ist eine komplette architektonische Überarbeitung: Die Entwickler haben die Plattform von Grund auf neu aufgebaut, eine durchgängige Verflachung des Kontrollflusses über alle Funktionen hinweg implementiert und spezielle Azure-Funktionen für den Angriff auf Anmeldeinformationen eingeführt, darunter den Diebstahl von MSAL-Token-Caches und die Extraktion der Azure-CLI-Konfiguration. Mit dieser Neugestaltung ist Vidar in der Lage, aus den Betriebsunterbrechungen durch konkurrierende Infostealer Kapital zu schlagen, insbesondere aus den jüngsten Herausforderungen von Lumma Stealer.

Wichtige technische Erkenntnisse

• Durchgängige Abflachung des Kontrollflusses bei allen 274 Funktionen durch Verschleierung von Zustandsautomaten ohne statische Importe
• Dokumentierte genaue HTTP POST-Exfiltrationsstruktur und rekonstruierte Konfigurationsspeicheranordnung (+0x000 bis +0x5c8)
• Chrome v20 AES-GCM-Passwort-Entschlüsselung korrekt implementiert bei Funktion 0x140014d6c mit Windows BCrypt APIs
• Spezielles Targeting von Azure-Anmeldeinformationen: MSAL-Token-Cache-Diebstahl und Extraktion der Azure-CLI-Konfiguration mit expliziter “Azure Reader”-Klassifizierung
• Rekursive Sammel-Engine mit 10-stufigem Verzeichnis-Traversal, intelligenter Dateifilterung und korrekter Windows-API-Fehlerbehandlung
• Multi-Browser-Anmeldedatenklau (Chrome, Edge, Firefox, Opera, Vivaldi) mit DPAPI-Integration und 50+ Kryptowährungs-Wallets im Visier

---

Hintergrund

Vidar Stealer erschien erstmals 2018 als Chromium-basierte Plattform zum Diebstahl von Anmeldeinformationen. Frühere Versionen basierten auf C++ und hatten einen relativ einfachen Kontrollfluss.

Die Version 2.0, die erstmals im Oktober 2025 zu sehen war, stellt eine grundlegende Änderung der Architektur dar:

• Die statische Analyse fand keine C++-Artefakte, sondern nur reine C-Aufrufkonventionen.
• Durchgängige Abflachung des Kontrollflusses für alle 274 Funktionen
• Erweiterte Funktionen für die Ausrichtung von Cloud-Zugangsdaten
• Keine statischen Importe (vollständige dynamische API-Auflösung)

Diese Neugestaltung deutet auf eine ausgereifte Entwicklungsarbeit hin, die sich auf Anti-Analyse und einen erweiterten Zielbereich konzentriert. Der Zeitpunkt fällt mit operativen Unterbrechungen zusammen, die konkurrierende infostealers, was auf eine Neupositionierung des Marktes hindeuten könnte.

Informationen zum Beispiel

Dateityp:        PE32+ (x64 ausführbare Datei)
Architektur: x86-64 (little endian)
Bild Basis:       0x140000000
Einstiegspunkt: 0x140001000
Compiler:         C (komplette Neufassung von C++)
Dateigröße: ~342 KB (.text section)
Funktionen insgesamt:  274
Statische Importe:   0 (dynamische API-Auflösung)
Datei-Hash (SHA256): bcf8a6911bf4033cf4d55caf22d7da9d97275bbb3b0f8fefd1129e86bd4b49f8

---

Kontrollflussverflachung

Kontrollflussverflachung ist eine Verschleierungstechnik wird in Software (insbesondere Malware) verwendet, um die Codeanalyse und das Reverse Engineering erheblich zu erschweren, und ist daher weit verbreitet, um Situationen wie diese bei der Analyse von Malware zu erschweren.

Das Besondere an Vidar 2.0 ist die allgegenwärtige Verflachung des Kontrollflusses, die alle Standardfunktionen in Zustandsautomaten mit scheinbar zufälligen magischen Zahlen verwandelt. Dieses Verschleierungsmuster findet sich durchgängig in allen 274 Funktionen des Binärprogramms.

Einstiegspunkt-Analyse

Der Einstieg in das Programm scheint einfach zu sein:

FUN_140001018 offenbart jedoch sofort das Verschleierungsmuster mit einer Zustandsmaschinenlogik, die sich über Tausende von Zeilen erstreckt.

Zustandsmaschinen-Muster

Die Malware verwendet numerische Zustandskennungen, um den Ausführungsablauf zu steuern:

Dokumentierte staatliche Werte

Durch umfangreiche Analysen wurden die folgenden Zustandsmuster ermittelt:

Zustand Wert	Funktion Kontext	Beobachtetes Verhalten
0xef25c2e	Initialisierungsroutinen	Eingangszustand für die Konfiguration
-0x1ccdc046	Verzeichnisoperationen	Auslöser für CreateDirectoryA-Aufrufe
-0x5b685f24	Validierungsprüfungen	Bedingter Verzweigungszustand
0x3faa991b	HTTP-Operationen	Kommunikationswege im Netzwerk
0x5a1064e5	Bereinigungsroutinen	Vorbereitung auf die Selbstlöschung

Auswirkungen auf das Reverse Engineering

Diese Verschleierung schafft mehrere Herausforderungen:

1. Funktion Länge Explosion
2. Verlorene semantische Struktur
3. Beschränkungen des Decompilers
4. Zeitliche Investition

---

C2 & Exfiltration

Struktur der HTTP-Exfiltration

Die Malware verwendet einen zweistufigen HTTP-Exfiltrationsprozess:

1. Formular Konstruktion - (FUN_14000906e) - Erzeugt die multipart/form-data Struktur
2. HTTP-Kommunikation - (FUN_1400064cc) - Behandelt die eigentliche Netzwerkübertragung

Stufe 1: Konstruktion des Formulars

Die Malware verwendet HTTP-POST-Anfragen mit multipart/form-data-Kodierung. Die Analyse der Funktion FUN_14000906e (HTTP Request Wrapper) offenbart die genaue Datenstruktur:

Exfiltrationsfelder:

1. Token - Eindeutige Bot-Kennung (gespeichert im Konfigurations-Offset +0x300)
2. build_id - Kennung der Kampagne oder des Kunden
3. Modus - Aktuelle Betriebsphase

Die Begrenzungszeichenfolge wird mit 20 zufälligen Zeichen pro Anfrage generiert.

---

Stufe 2: HTTP-Kommunikation

Implementierung von HTTP-Anfragen

Funktion FUN_1400064cc Behandelt die eigentliche HTTP-Kommunikation (wie wird gesendet)

Herstellung der Verbindung:

Konfiguration anfordern:

Timeout-Einstellungen:

Kopfzeile Konfiguration:

Validierung der Antwort:

Die Antwortdaten werden in 1-KB-Blöcken (0x400 Bytes) mit ‘InternetReadFile()‘ mit dynamischer Heap-Zuweisung auf der Grundlage der Inhaltslänge.

1. InternetCrackUrlA - Parsen der Ziel-URL
2. InternetConnectA - Verbindung zum C2-Server
3. HttpOpenRequestA - HTTP-Sitzung öffnen
4. InternetSetOptionA (x3) - Zeitüberschreitungen einstellen (120s)
5. HttpAddRequestHeadersA - Hinzufügen von benutzerdefinierten Kopfzeilen
6. HttpSendRequestA - Senden gestohlener Daten
7. HttpQueryInfoA - Überprüfung des Statuscodes (200-399?)
8. InternetReadFile - C2-Antwort lesen
9. InternetCloseHandle (x2) - Bereinigung

1

2

3

4

5

6

7

8

9

1. InternetCrackUrlA - Parsen der Ziel-URL

2. InternetConnectA - Verbindung zum C2-Server

3. HttpOpenRequestA - HTTP-Sitzung öffnen

4. InternetSetOptionA (x3) - Zeitüberschreitungen einstellen (120s)

5. HttpAddRequestHeadersA - Hinzufügen von benutzerdefinierten Kopfzeilen

6. HttpSendRequestA - Gestohlene Daten senden

7. HttpQueryInfoA - Überprüfung des Statuscodes (200-399?)

8. InternetReadFile - C2-Antwort lesen

9. InternetCloseHandle (x2) - Bereinigung

---

Konfiguration Struktur Rekonstruktion

Die Konfigurationsstruktur-Offsets wurden durch die Analyse von FUN_14000921e identifiziert, die Konfigurationsdaten für die Exfiltration bereitstellt:

Versetzt	Zweck	Größe	Nachweis Funktion	Verwendung
+0x000	Datenpuffer	0x200	FUN_14000921e	Kopie des Bereitstellungspuffers
+0x200	Server-URL	0x100	FUN_14000921e	Ziel der HTTP-Verbindung
+0x300	Bot Token	0x100	FUN_14000921e	Eindeutiger Bezeichner
+0x448	Unbekannt	0x80	FUN_14000921e	Zweck unklar
+0x4c8	Arbeitsweg 1	0x40	FUN_14000921e	Primäres Verzeichnis

Hinweis: Zielverzeichnisse für den Diebstahl von Anmeldeinformationen (Azure, Browserpfade usw.) sind dynamisch auf dem Stapel aufgebaut über Umgebungsvariablen (LOCALAPPDATA, USERPROFILE), die nicht in der Konfigurationsstruktur gespeichert sind.

Von ‘FUN_14000921e’ - diese Funktion bereitet Konfigurationsdaten für die Exfiltration vor

Beweise für die Strukturierung

Die folgenden Codemuster treten in verschiedenen Funktionen immer wieder auf:

Token-Zugang für HTTP-Exfiltration:

Verwendung der Serveradresse:

Verzeichnisstruktur erstellt

---

Konfiguration Datenfluss

---

Implementierung des Ausweisdiebstahls

Browser Credential Targeting

Vidar 2.0 zielt auf die Zugangsdaten aller gängigen Browser ab, und zwar sowohl mit traditionellen als auch mit fortschrittlichen Techniken.

Gezielte Browser:

• Google Chrome
• Microsoft Edge
• Mozilla Firefox
• Oper / Oper GX
• Vivaldi
• Wasserfuchs
• Palemoon

DPAPI-Integration

Windows-Datenschutz-API wird genutzt, um gespeicherte Zugangsdaten zu entschlüsseln, wenn Malware unter dem Benutzerkontext des Opfers ausgeführt wird:

Chrome v20 Verschlüsselung: AES-GCM Implementierung

Diese Funktion implementiert die Entschlüsselung von Chrome v20-Kennwörtern unter Verwendung der Windows BCrypt-API für die AES-256-GCM-Entschlüsselung. Der stark verschleierte Kontrollfluss verwendet berechnete Sprünge, um die statische Analyse zu umgehen.

Wichtige Parameter:

• param_1: Zeiger auf entschlüsselten v20-Schlüssel (32-Byte-AES-Schlüssel aus Local State)
• param_2: Zeiger auf verschlüsselten Passwort-Blob aus der Chrome-Datenbank
• param_3: Gesamtgröße des verschlüsselten Blob
• param_4: Ausgabepuffer für entschlüsseltes Passwort
• param_5: Größe des Ausgabepuffers

Chrome v20 Strukturextraktion:

• Überspringt 3-Byte-Präfix “v20”: local_d0 = param_2 + 3
• Berechnet die Größe des Chiffretextes: cbInput = param_3 - 0x1f (31 Bytes = 3 Präfix + 12 Nonce + 16 Tag)
• Lokalisiert das Authentifizierungskennzeichen: local_d8 = param_2 + param_3 - 0x10 (letzte 16 Bytes)

Initialisierung des BCrypt-Algorithmus-Providers

• BCryptOpenAlgorithmProvider: Öffnet den Microsoft Primitive Provider für AES
• &local_110: Empfängt den Algorithmus-Handle (BCRYPT_ALG_HANDLE)
• L ”AES”: Gibt den AES-Algorithmus an
• Gibt zurück: NTSTATUS-Code (negativ bei Fehlschlag)

AES-GCM-Verkettungsmodus einstellen

• BCryptSetProperty: Ändert die Eigenschaften von Algorithmus-Objekten
• local_110: Algorithmus-Handle vom vorherigen Schritt
• L ”ChainingMode”: Kennung der Eigenschaft
• L ”ChainingModeGCM”: Legt den Galois/Counter-Modus fest (authentifizierte Verschlüsselung)
• 0x20: Größe des Eigenschaftswerts in Bytes (32 Bytes für eine breite Zeichenfolge)

Warum GCM? Chrome verwendet AES-GCM, weil es diese Funktion bietet:

• Vertraulichkeit (Verschlüsselung)
• Authentizität (verhindert Manipulationen)
• Integritätsprüfung über Authentifizierungs-Tag

Symmetrische Schlüsselerzeugung

• BCryptGenerateSymmetricKey: Erzeugt ein Schlüsselobjekt aus Rohschlüsselmaterial
• param_1: Zeigt auf eine Struktur, die den entschlüsselten v20-AES-Schlüssel enthält (32 Byte)
• *(ULONG *)(param_1 + 0x20): Schlüssellänge an Offset 0x20 gespeichert (sollte 32/0x20 sein)
• &local_100: Empfängt das Schlüsselhandle (BCRYPT_KEY_HANDLE)

Schlüsselquelle: Dieser 32-Byte-AES-Schlüssel wurde zuvor aus dem lokalen Schlüssel von Chrome extrahiert.

Speicherzuweisung für die Ausgabe

BCRYPT_AUTHENTICATED_CIPHER_MODE_INFO Struktur Setup: Dadurch wird die für die authentifizierte Entschlüsselung erforderliche Struktur geschaffen:

OffsetValuePurposelocal_b00x100000058Strukturversion/Größe magiclocal_a8local_d0Nonce/IV-Zeiger (12 Byte bei Offset 3)local_a00xcNonce-Länge (12 Byte)lStack_88local_d8Zeiger auf Authentifizierungskennzeichen (letzte 16 Byte)local_800x10Länge des Authentifizierungskennzeichens (16 Byte)

Speicherzuweisung:

• Zuweisung von ‘cbinput’-Bytes (Chiffriertextlänge ohne Präfix, Nonce, Tag)
• Verwendet den Windows-Heap (GetProcessHeap/HeapAlloc)
• Fehlschlag löst Bereinigungsroutine aus

Browser-Erkennung

Die Funktion FUN_140019ad0 implementiert die Fensterklassenerkennung, um laufende Browser zu identifizieren:

Zielerfassungsmatrix:

Browser	Fenster-Klasse	Prozess Name
Google Chrome	Chrome_WidgetWin_1	chrome.exe
Mozilla Firefox	MozillaWindowClass	firefox.exe
Microsoft Edge	ApplicationFrameWindow	msedge.exe
Oper	OperaWindowClass	opera.exe

Kryptowährungs-Geldbörsen

Basierend auf öffentlichen Berichten und String-Analysen zielt Vidar 2.0 auf mehr als 50 Kryptowährungs-Wallet-Anwendungen ab, darunter:

• Atomic Brieftasche
• Exodus
• Elektrum / ElektrumLTC
• Bitcoin-Kern
• Ethereum
• Monero
• Dogecoin
• Und viele browserbasierte Erweiterungen für Geldbörsen

Zusätzliche gezielte Daten

2FA-Anwendungen:

• Authy-Schreibtisch
• Google-Authentifikator
• EOS-Authentifikator
• GAuth-Authentifikator

E-Mail-Clients:

• Microsoft Outlook
• Mozilla Thunderbird

FTP/Dateiübertragung:

• FileZilla
• WinSCP
• CCleaner

Cloud-Dienste:

• AWS (.aws-Dateien), Azure (.azure-Dateien), Office 365-Tokens

---

Azure Identity Service Token-Diebstahl

An dieser Stelle wird es interessant. Ich habe eine spezielle Funktion an Adresse 0x14003fa19 gefunden, die speziell nach Microsoft Authentication Library (MSAL) Token-Caches sucht. Ich habe auch entdeckt, dass der gleiche Ablauf für andere Cloud-Anbieter gilt, bei denen die gleiche Logik für den Diebstahl von Cloud-Anmeldeinformationen gilt.

Hier ist, was es tut:

Zielort:

%LOCALAPPDATA%\.IdentityService\msal.cache

Die Malware prüft zunächst, ob die Umgebungsvariable LOCALAPPDATA vorhanden ist, und konstruiert dann einen Pfad zum Verzeichnis .IdentityService auf dem Stapel unter Verwendung von String-Operationen. Dieses Verzeichnis enthält die MSAL-Cache-Datei - eine wahre Fundgrube an Authentifizierungs-Tokens, die verwendet werden können, um sich bei Microsoft-Diensten als legitime Benutzer auszugeben.

Die Funktion überprüft die Existenz des Verzeichnisses mit ‘GetFileAttributesA’ auf den konstruierten Pfad (gespeichert im Stapelpuffer local_148). Bei Erfolg übergibt er sowohl die Konfigurationsstruktur (param_1) und den konstruierten Pfad an die Sammelmaschine FUN_14003ec16 zur Verarbeitung.

Die Funktion überprüft die Existenz des Verzeichnisses mit GetFileAttributesA, bevor sie versucht, es zu lesen. Wenn sie erfolgreich ist, übergibt sie die Daten an eine zentrale Dateisammelmaschine, auf die wir gleich noch eingehen werden.

Warum das wichtig ist: Diese Token können einen sofortigen, authentifizierten Zugriff auf Azure-Ressourcen ermöglichen, ohne dass Passwörter geknackt oder MFA umgangen werden müssen. Sie sind im Grunde vorauthentifizierte Sitzungen, die nur darauf warten, gekapert zu werden.

Azure CLI-Konfiguration Diebstahl

Die zweite Azure-Zielfunktion befindet sich an der Adresse 0x14003eaf4 und hat es auf einen anderen Preis abgesehen - das Azure CLI-Konfigurationsverzeichnis.

Zielort:

%USERPROFILE%\.azure

Diese Funktion folgt demselben Muster wie der Diebstahl von MSAL-Token:

1. Fragt die Umgebungsvariable USERPROFILE ab
2. Konstruiert den vollständigen Pfad %USERPROFILE%\\.azure auf dem Stapel (im Puffer local_148)
3. Überprüft die Existenz des Verzeichnisses mit GetFileAttributesA auf dem Stapelpuffer
4. Pässe sowohl die Konfigurationsstruktur als auch der konstruierte Pfad zur Sammlung
   Motor FUN_14003ec16 für rekursive Aufzählung und Exfiltration

Dies ist besonders gefährlich, da DevOps-Teams und Cloud-Administratoren in Azure-Umgebungen oft über erhöhte Rechte verfügen. Durch Diebstahl ihrer Azure-CLI-Anmeldedaten können Angreifer administrativen Zugriff auf die Cloud-Infrastruktur erlangen und so möglicherweise ganze Azure-Mandate gefährden.

Die Funktion folgt einem ähnlichen Muster - sie sucht nach der Umgebungsvariablen USERPROFILE, konstruiert den Pfad, überprüft die Existenz und exfiltriert den Inhalt.

Die Sammlungsmaschine

Beide Azure-Targeting-Funktionen, die ich beschrieben habe, werden an Adresse 0x14003ec16 in eine Core Collection Engine eingespeist. Hier findet die eigentliche Schwerstarbeit statt, und sie ist beeindruckend gründlich.

Wichtiger Hinweis: Die Sammelmaschine (`FUN_14003ec16`) erhält zwei separate Parameter

• param_1: Die Konfigurationsstruktur (für Staging/Exfiltrations-Metadaten)
• param_2`**: Der Zielverzeichnispfad (dynamisch vom Aufrufer erstellt) Die Engine liest NICHT die Verzeichnispfade aus der Konfigurationsstruktur. Stattdessen werden die Zielpfade von Wrapper-Funktionen wie `FUN_14003fa19` und `FUN_14003eaf4` auf dem Stack aufgebaut und dann als Parameter an diese Sammelmaschine übergeben.

Schlüsselkompetenzen:

Rekursiver Verzeichnis-Traversal Die Funktion durchläuft rekursiv Verzeichnisse bis zu 10 Ebenen tief. Sie holt sich nicht nur die oberste Cache-Datei - sie zählt systematisch alles auf, was wertvoll sein könnte.

Intelligente Dateifilterung Die Malware stiehlt nicht blindlings alles. Sie sucht gezielt nach Dateien, die bestimmten Mustern entsprechen:

• msal.cache-Dateien
• Dateien in .azure-Unterverzeichnissen
• Spezifische Dateierweiterungen im Zusammenhang mit Berechtigungsnachweisen

Lesen und Bereitstellen von Dateien Sobald es die Zieldateien identifiziert hat, wird es:

1. Öffnet sie mit CreateFileA
2. Ermittelt die Dateigröße mit GetFileSize
3. Allokiert Speicher aus dem Prozess-Heap
4. Liest die gesamte Datei in den Speicher mit ReadFile
5. Übergabe der Daten an die Exfiltrationsfunktion

Kontrollfluss-Verschleierung Der Code verwendet ein Zustandsmaschinenmuster mit berechneten Sprüngen, was die statische Analyse erschwert. Die Steuerung der Ausführung erfolgt über ein komplexes Netz von bedingten Verzweigungen. Dies ist eindeutig darauf ausgelegt, Reverse-Engineering-Bemühungen zu verlangsamen.

Klassifizierung der Daten

Schließlich gibt es eine Klassifizierungsfunktion unter 0x1400042fd, die die gestohlenen Daten vor der Exfiltration kennzeichnet. Hier habe ich die explizite Kennzeichnung “Azure Reader” an Adresse 0x140057f43 gefunden.

Die Funktion kategorisiert gestohlene Daten in Typen:

• “Azure Reader” - Azure-Anmeldeinformationen und Token
• “Krypto-Leser” - Kryptowährungs-Wallet-Daten
• “FTP/SSH-Leser” - FTP- und SSH-Zugangsdaten
• “Screenshot” - Bildschirmabzüge
• “Soziale Apps” - Anmeldeinformationen für soziale Medien
• “Dateigrabber” - Allgemeiner Dateidiebstahl

Dieses Kennzeichnungssystem deutet auf eine gut organisierte C2-Infrastruktur hin, in der die gestohlenen Daten automatisch nach Typ sortiert und verarbeitet werden. Die Klassifizierung “Azure Reader” verrät uns, dass die Bedrohungsakteure Cloud-Anmeldedaten getrennt von anderen gestohlenen Daten bewerten und verfolgen.

Zeichenfolgen in Binär gefunden:

• 0x140057f43: “Azure Reader”
• 0x14005826c: “Azure\.azure”
• 0x1400582aa: “msal.cache” (4 Verweise)
• 0x140058319: “Azure\.IdentityService”

---

Zusammenfassung des Angriffsflusses

---

Profil des Bedrohungsakteurs

Raffiniertheit der Entwickler:

• Tiefes Verständnis der Windows-Interna
• Korrekte Implementierung der modernen Kryptographie (AES-GCM)
• Professionelles Fehlerhandling und Ressourcenmanagement
• Strategische Marktanalyse und Positionierung

Operative Sicherheit:

• Sieben Jahre ohne größere Unterbrechungen
• Entwickler behält konsistente Identität bei (“Loadbaks”)
• Aktive Präsenz in Untergrundforen
• Reagiert auf Kundenfeedback

YARA-Regel - Detektionstechnik

Github-Link

---

MITRE ATT&CK-Abbildung

Technik-ID	Technik Name	Untertechnik	Taktik	Umsetzung Beweise
T1071.001	Protokoll der Anwendungsschicht	Web-Protokolle	Befehl und Kontrolle	“HTTP POST-Anfragen mit multipart/form-data an C2-Server (FUN_1400064cc). InternetConnectA, HttpOpenRequestA, HttpSendRequestA API-Sequenz.”
T1027.002	Verdeckte Dateien oder Informationen	Software-Paketierung	Verteidigung Umgehung	“Durchgängige Kontrollflussverflachung über alle 274 Funktionen mit Zustandsmaschinenverschleierung. Keine statischen Importe mit dynamischer API-Auflösung”.”
T1497.001	Virtualisierung/Sandbox-Umgehung	System-Prüfungen	Verteidigung Umgehung	“Mehrere Umgebungsvariablenprüfungen und Validierungszustände. Fehlercodes (0x2eff, 0x2f0d, 0x2f8f) deuten auf Anti-Analyse-Prüfungen hin.”
T1082	Suche nach Systeminformationen		Entdeckung	“CreateToolhelp32Snapshot, Process32First/Next, Thread32First/Next für die Prozessaufzählung. Fensterklassenerkennung (FUN_140019ad0) zur Browseridentifikation.”
T1083	Suche nach Dateien und Verzeichnissen		Entdeckung	“Rekursive Verzeichnisdurchsuchung (10 Ebenen tief) mit FindFirstFileA/FindNextFileA. Zielt auf Browser-Profile, Wallet-Verzeichnisse, Azure-Konfigurationen, MSAL-Cache ab.”
T1005	Daten aus dem lokalen System		Sammlung	“Systematische Sammlung von Browser-Datenbanken, Kryptowährungs-Wallets, 2FA-Anwendungen, FTP-Clients (FileZilla, WinSCP), E-Mail-Clients (Outlook, Thunderbird).”
T1555.003	Anmeldeinformationen aus Passwortspeichern	Anmeldeinformationen von Webbrowsern	Zugang zu Anmeldeinformationen	“Chrome, Edge, Firefox, Opera, Vivaldi, Waterfox, Palemoon: Diebstahl von Anmeldedaten. Chrome v20 AES-GCM Entschlüsselung (FUN_140014d6c) und DPAPI Integration (CryptUnprotectData)”.”
T1555.005	Anmeldeinformationen aus Passwortspeichern	Passwort-Manager	Zugang zu Anmeldeinformationen	“Zielt auf 2FA-Anwendungen (Authy, Google Authenticator, EOS Authenticator, GAuth Authenticator) gespeicherte Anmeldeinformationen ab.”
T1555.006	Anmeldeinformationen aus Passwortspeichern	Wolken-Geheimnisse	Zugang zu Anmeldeinformationen	“Diebstahl des Azure Identity Service MSAL-Token-Caches (%LOCALAPPDATA%\.IdentityService\msal.cache) bei FUN_14003fa19. Diebstahl der Azure-CLI-Konfiguration (%USERPROFILE%\.azure) bei FUN_14003eaf4.”
T1552.001	Ungesicherte Berechtigungsnachweise	Berechtigungsnachweise in Dateien	Zugang zu Anmeldeinformationen	“Sammlung von FileZilla-XML-Konfigurationen, WinSCP-Registrierungs-/Konfigurationsdateien, Azure-CLI-Konfigurationsdateien, Anmeldeinformationen für Dienstleiter”.”
T1528	Anwendungszugriffstoken stehlen		Zugang zu Anmeldeinformationen	“MSAL-Cache-Token-Diebstahl, der Zugriffstoken, Aktualisierungs-Token und Kontometadaten für Azure-Ressourcen bereitstellt. Explizite ‘Azure Reader’-Klassifizierung bei 0x140057f43”.”
T1539	Web-Session-Cookie stehlen		Zugang zu Anmeldeinformationen	“Diebstahl von Browser-Cookies aus Cookies-Datenbankdateien. Gesammelt im speziellen Cookies\-Unterverzeichnis.”
T1113	Bildschirmaufzeichnung		Sammlung	“Screenshot-Fähigkeit mit Ausgabe in screenshot.jpg im Exfiltrationsverzeichnis”.”
T1140	Entschlüsseln/Dekodieren von Dateien oder Informationen		Verteidigung Umgehung	“BCrypt-API-Nutzung für die AES-256-GCM-Entschlüsselung von Chrome v20-Passwörtern. BCryptOpenAlgorithmProvider, BCryptSetProperty, BCryptGenerateSymmetricKey, BCryptDecrypt sequence.”
T1573.001	Verschlüsselter Kanal	Symmetrische Kryptographie	Befehl und Kontrolle	“HTTPS-Kommunikation zu C2 mit deaktivierter SSL-Zertifikatsüberprüfung (SECURITY_FLAG_IGNORE-Flags)”.”
T1041	Exfiltration über C2-Kanal		Exfiltration	“HTTP POST-Exfiltration über denselben C2-Kanal. Strukturierte multipart/form-data mit den Feldern token, build_id, mode”.”
T1119	Automatisierte Sammlung		Sammlung	“Automatisierte rekursive Sammlungsmaschine (FUN_14003ec16) mit intelligenter Dateifilterung, 10-stufigem Verzeichnis-Traversal und Datenklassifizierungssystem”.”
T1070.004	Entfernen des Indikators	Löschung von Dateien	Verteidigung Umgehung	“Die Fähigkeit zur Selbstlöschung wird durch den Cleanup-Status (0x5a1064e5) und zugehörige Routinen angezeigt.”
T1036.005	Maskerade	Legitimer Name oder Standort entsprechen	Verteidigung Umgehung	“Verwendet temporäre Verzeichnisse mit legitim erscheinenden Pfaden (work_path_1 bei +0x4c8, work_path_2 bei +0x508).”

---

Indikatoren für Kompromisse

Github-Link

---

Schlussfolgerung

Diese Analyse dokumentiert ausgefeilte Fähigkeiten zum Diebstahl von Anmeldedaten in einem Beispiel, das eine weitreichende Verflachung des Kontrollflusses, eine umfassende Ausrichtung auf den Browser und spezielle Funktionen zum Diebstahl von Anmeldedaten in der Cloud aufweist. Zu den technischen Merkmalen gehören:

• Vollständige Neuschreibung von C mit Zustandsmaschinenverschleierung für 274 Funktionen
• Korrekt implementierte Chrome v20 AES-GCM-Entschlüsselung
• Explizite Klassifizierung für Cloud-Anmeldeinformationen
• Professionelles HTTP-Exfiltrationsprotokoll

Attribution Confidence:

Obwohl dieses Beispiel öffentlich auf der Grundlage operativer Informationen dem Vidar Stealer 2.0 zugeschrieben wird, kann diese technische Analyse diese Zuschreibung nicht unabhängig bestätigen. Die beobachteten Fähigkeiten stimmen mit den Berichten über Vidar 2.0 überein, aber ähnliche technische Muster könnten theoretisch auch in anderen Malware-Familien oder abgeleiteten Werken auftreten. Dies zeigt, dass es sich um hochentwickelte Operationen handelt, die sowohl auf Einzelpersonen als auch auf etablierte Organisationen abzielen.

Diese Analyse konzentriert sich auf die Dokumentation beobachtbarer technischer Verhaltensweisen, anstatt endgültige Zuordnungen vorzunehmen. Die hier dokumentierten Techniken, insbesondere das Azure-Targeting und die Implementierung der Chrome v20-Entschlüsselung, stellen unabhängig von der Zuordnung zu einer bestimmten Malware-Familie echte Bedrohungen dar.

Fokus der Erkennung:

Die bereitgestellten YARA-Regeln zielen eher auf technische Implementierungsmuster als auf familienspezifische Artefakte ab, was sie robust gegenüber Rebranding oder derivativen Malware-Familien macht.

---

Referenzen:

• Microsoft Docs - CryptUnprotectData Funktion (DPAPI) Referenz
• Microsoft Docs - Referenz zur Windows-Datenschutz-API (DPAPI)
• Microsoft Docs - GetFileAttributesA Funktionsreferenz