von John Dador
Aus unserem vorherigen Artikel über HijackLoader geht hervor, dass die beobachtete Nutzlast eine umbenannte Version von ACRStealer ist, die ursprünglich von Proofpoint in der ersten Hälfte des letzten Jahres gemeldet wurde. Diese aktualisierte Variante verwendet ähnliche Evasion-Techniken und eine vergleichbare C2-Initialisierungsstrategie, um noch unauffälliger zu agieren.
Da ACRStealer als Malware-as-a-Service (MaaS) bekannt ist, ist es plausibel, dass sie nun als eine von vielen Nutzlasten eingesetzt wird, die durch HijackLoader verteilt werden. Dies zeigt, dass ACRStealer nicht nur eine wiederverwendete Malware ist, sondern ein kontinuierlich weiterentwickeltes und umbenanntes Modul, das aktiv über komplexe Loader bereitgestellt wird. Die Integration mit HijackLoader unterstreicht die Vielseitigkeit und Modularität von ACRStealer, was wahrscheinlich weitere Angreifer dazu bewegen wird, sie als finale Nutzlast einzusetzen.
In diesem Teil werden wir die Evasion-Techniken, die C2-Kommunikation und insbesondere die Stealing-Fähigkeiten von ACRStealer hervorheben, wobei unser Fokus auf Letzteren neue Erkenntnisse liefert.
NTCalls and WoW64 SysCalls
Interessanterweise verwendet diese Version von ACRStealer eine dynamische API-Auflösung über NTDLL- und WoW64-Syscalls, wie ursprünglich von Proofpoint berichtet. Die meisten Malware-Familien greifen typischerweise auf höherstufige Win32-APIs zurück, um Evasion oder Ausführung direkt durchzuführen, die von Sicherheitsprodukten wie EDRs leicht erkannt und überwacht werden können. Durch die Verwendung von Low-Level-Syscalls kann diese ACRStealer-Variante User-Mode-Hooks umgehen und ihre Erkennbarkeit verringern.
Das Verhalten der neuen Variante beginnt damit, auf den Process Environment Block (PEB) zuzugreifen, um die ntdll.dll zu lokalisieren. Anschließend wird die Export Address Table (EAT) manuell geparst, um die Funktionsnamen aufzulösen. Dies geschieht über eine modifizierte Version von djb2, die ebenfalls in HijackLoader verwendet wird, jedoch mit einem anderen Seed. Nach der Auflösung speichert die Malware die entsprechende Adresse sowie die System Service Number (SSN) der Funktion und legt sie in einer globalen Variable ab. Abschließend nutzt sie zur Ausführung des Systemaufrufs das Wow64-Transition-Gate, wodurch die Win32-API-Schicht und User-Mode-Hooks umgangen werden.
AFD und NTSockets
Frühere Versionen von ACRStealer nutzten einen Dead Drop Resolver (DDR), um die C2-Kommunikation zu verschleiern. Diese Version verwendet jedoch NTSockets und den Ancillary Function Driver (AFD), um eine C2-Verbindung herzustellen, ohne Winsock oder andere höherstufige APIs zu verwenden.
Der Code beginnt damit, die Zeichenkette \Device\Afd\Endpoint\ manuell zu konstruieren, die den nativen Pfad zum AFD-Objekt darstellt. Anschließend erstellt er eine OBJECT_ATTRIBUTE-Struktur zusammen mit einer UNICODE_STRING-Struktur. Zusammen beschreiben diese Strukturen dem Windows Object Manager das Zielobjekt. Mit dieser Vorbereitung ruft der Code NtCreateFile auf, wodurch der AFD-Endpunkt aus dem User-Mode heraus aufgelöst und geöffnet werden kann. Dabei wird nicht die Win32-API-Schicht verwendet, wodurch erneut eine Erkennung umgangen wird.
Als Nächstes konstruiert die Funktion bewusst erzeugte Zeichenketten. Die erste resultierende Zeichenkette lautet AfdOpenPacketXX. Neben dieser erzeugten Zeichenkette werden auch protokollbezogene Werte (2, 1, 6) definiert, die AF_INET, SOCK_STREAM und IPPROTO_TCP entsprechen. Dies zeigt, dass ein TCP-IPv4-Socket vorbereitet wird, ohne ws2_32.socket zu importieren. Anschließend wird durch das Verketten von Zeichenketten dynamisch eine weitere Zeichenkette, NTCreateFile, erstellt. Diese Zeichenkette wird an den zuvor erwähnten benutzerdefinierten Funktions-Resolver übergeben, und mithilfe des Wow64-Transition-Gates wird der native Systemaufruf direkt ausgeführt.
Kommunikations-Schichten
Ein weiterer zentraler Aspekt dieser Version ist die Implementierung eines mehrschichtigen Kommunikationsdesigns: Zunächst wird eine RAW-TCP-Verbindung aufgebaut, anschließend wird über diese Verbindung mithilfe von SSPI eine SSL/TLS-Schicht etabliert.
Nachdem der AFD-Endpunkt-Handle vorbereitet wurde, wird die Ziel-IP-Adresse – in diesem Fall 157[.]180[.]40[.]106 – manuell geparst und zusammen mit dem Port 443 in Network Byte Order umgewandelt. Anschließend wird der entfernte C2-Endpunkt über native AFD-IOCTLs mithilfe von NtDeviceIoControlFile konfiguriert, was dem connect()-Aufruf in WinSock entspricht. Dies deutet darauf hin, dass die Kommunikation wie normaler HTTPS-Verkehr erscheinen soll, während tatsächlich AFD verwendet wird. Zu diesem Zeitpunkt wurde bereits eine einfache TCP-Verbindung hergestellt. Während der Analyse reagierte die IP-Adresse 157[.]180[.]40[.]106 jedoch nicht mehr und war möglicherweise bereits abgeschaltet, weshalb der Endpunkt sofort beendet wurde.
Wäre die IP-Adresse noch erreichbar gewesen, hätte die Probe einen TLS-Handshake über die bereits etablierte TCP-Verbindung gestartet. Dieser TLS-Handshake erfolgt mithilfe von SSPI über AcquireCredentialsHandleA, wobei der Microsoft Unified Security Protocol Provider verwendet wird. Anschließend folgt ein Aufruf von InitializeSecurityContextA mit einem fest kodierten pszTargetName von playtogga[.]com. Dieser Vorgang läuft in einer Schleife, in der ein Rückgabecode 0x90312 überprüft wird, der dem SSPI-Statuscode SEC_I_CONTINUE_NEEDED entspricht. Dies zeigt an, dass weitere Handshake-Tokens ausgetauscht werden müssen, bevor die TLS-Sitzung vollständig aufgebaut ist.
Post-Handshake Transmission: Plaintext vs TLS
Sobald der Handshake abgeschlossen ist, beendet der Code diesen Schritt und gibt die temporären Puffer frei. Anschließend wird die HTTP-Anfrage vorbereitet, bevor der Übertragungsmodus bestimmt wird. In dieser Funktion kann eine von acht HTTP-Methoden (GET, HEAD, POST, PUT, DELETE, CONNECT, OPTIONS, TRACE, PATCH) verwendet werden, wobei POST die Standardmethode ist. Der resultierende Header lautet exakt wie folgt: “POST / HTTP/1.1\r\nHost: playtogga[.]com\r\nConnection: close\r\nContent-Length: 48\r\nContent-Type: application/octet-stream\r\n\r\n”.
Nachdem der HTTP-Request-Header erstellt wurde, prüft der Code ein Konfigurationsflag, um zu bestimmen, ob die Daten im Klartext oder in TLS-gekapselter Form gesendet werden. Wenn das Flag auf 0 gesetzt ist, wird die konstruierte HTTP-Anfrage über die zuvor aufgebaute TCP-Verbindung mittels AFD gesendet. Dies ähnelt einer einmaligen HTTP-Anfrage, wie sie häufig für Beaconing verwendet wird. Andernfalls wird der HTTP-Request-Header zunächst mithilfe der EncryptMessage-API verschlüsselt, bevor er gesendet wird.
Abhängig vom Statuscode (200) wird anschließend entweder die vom Server empfangene Antwort mit AES-256 unter Verwendung eines fest kodierten 32-Byte-Schlüssels entschlüsselt oder ein Sleep-Befehl für zwei Sekunden ausgeführt, bevor eine Wiederherstellungsroutine gestartet wird, die versucht, eine erneute Verbindung aufzubauen.
Plündern und Ausruhen im Wechsel
Dieser Abschnitt zeigt die Bandbreite der Datendiebstahlfunktionen von ACRStealer. Neben den besonderen Methoden zum Diebstahl sensibler Browserinformationen bestätigt die Analyse auch, dass diese Variante gezielt Gamer ins Visier nimmt. Dies zeigt sich durch die Exfiltration von Steam-Kontodaten - ein Verhalten, das bei ACRStealer zuvor weder beobachtet noch eingehend untersucht wurde.
Die Stealing-Funktionen von ACRStealer basieren auf acht kurzen Konfigurationsschlüsseln, die jeweils mit einem Typwert (Integer, Array, Boolean, String) verknüpft sind. Diese Konfigurationsschlüssel werden als Argument übergeben und bestimmen, welche Aufgabe der Code ausführt. Die Funktion, die wir als GetArrayField (Abbildung 4) bezeichnet haben, gibt die unter einem bestimmten Konfigurationsschlüssel gespeicherten Array-Werte zurück. Diese werden später von den Task-Handling-Funktionen ab Adresse 0x4126D0 verwendet, um zu bestimmen, welche Dateien und Verzeichnisse als Ziel ausgewählt werden.
Der Anfang jeder Stealing-Funktion ist wie folgt aufgebaut (Abbildung 5). Zunächst wird geprüft, ob der Wert des Konfigurationsschlüssels tatsächlich ein Array ist (Typ 4). Anschließend wird über jedes Element dieses Arrays iteriert, um zu bestätigen, dass es sich jeweils um ein Objekt handelt (Typ 5), das dictionary-ähnliche Schlüssel wie (p, tp, n, f, r) enthält. Diese Dictionary-Schlüssel werden anschließend verwendet, um die Parameter der jeweiligen Aufgabe abzurufen, bei denen wir davon ausgehen, dass sie für Name (n), Zielpfad (tp), Argument (a), Dateien (f) und ein rekursives Flag (r) stehen.
Unter Nutzung von NT-Syscalls beginnt ACRStealer beim USERPROFILE-Verzeichnis und durchsucht dieses rekursiv nach sensiblen Dateien, wobei NtOpenFile und NtQueryDirectoryFile verwendet werden. Dabei wird in einer Schleife gearbeitet, bis keine weiteren Einträge mehr vorhanden sind. Außerdem senden die meisten Stealing-Funktionen die gestohlenen Daten unmittelbar an ihren C2-Server und führen anschließend einen Aufruf von NtDelayExecution aus, bevor zur nächsten Stealing-Funktion übergegangen wird.
Die folgenden Stealing-Funktionen werden wie folgt ausgeführt.
Zunächst wird der Master-Verschlüsselungsschlüssel des Browsers extrahiert, indem die Datei „Local State“ lokalisiert wird, um die Werte von encrypted_key zu erhalten. Dieser wird anschließend per Base64 dekodiert, der DPAPI-Präfix entfernt und die API CryptUnprotectData aufgerufen, die den rohen AES-Master-Schlüssel zurückgibt. Nachdem der Master-Schlüssel erhalten wurde, beginnt der Code damit, Benutzerverzeichnisse und Browserprofile zu enumerieren. Dies ist ein klassischer Missbrauch von DPAPI zur Entschlüsselung von Browserartefakten. Die gestohlenen Daten werden anschließend in eine TXT-Datei mit dem fest kodierten Namen „d5e48e78-2951-4117-b806-e4f8e626f28c.txt“ extrahiert, bevor sie an den C2-Server gesendet werden.
Die nächste Stealing-Funktion verwendet eine fortgeschrittenere Technik. Zunächst werden Browserprofile enumeriert und die rohen AES-Master-Schlüssel für jedes Profil extrahiert. Anschließend wird jedoch ein App-Bound-Encryption-Bypass eingesetzt, der über eine Shellcode-Prozessinjektion in den Zielbrowser durchgeführt wird. Dies zeigt deutlich, dass ACRStealer auch Chrome-Versionen unterhalb von v127 ins Visier nimmt, also Versionen, die vor der Einführung der App-Bound-Verschlüsselung veröffentlicht wurden. Ziel dieser Schutzmaßnahme war es, Stealer daran zu hindern, DPAPI zur Entschlüsselung sensibler Daten zu verwenden.
Der Shellcode spielt hierbei ebenfalls eine wichtige Rolle, da er keine Importtabelle besitzt und stattdessen nur dynamisch die Funktion CopyFileA aus kernel32.dll auflöst und aufruft. Außerdem fiel eine Zeichenkette „Elevator.exe“ auf, was stark darauf hindeutet, dass Elevator.exe oder elevation_service.exe kopiert wird, das für privilegierte Operationen in Chrome zuständig ist. Eine erfolgreiche Ausführung führt dazu, dass die App-Bound-Verschlüsselung umgangen und letztlich sensible Browserinformationen entschlüsselt werden können.
Die nächsten Stealing-Funktionen betreffen die Exfiltration von Login-Daten, Cookies und WebData. Außerdem führt die Malware ein vollständiges Fingerprinting des Opfers durch (Machine GUID, Architektur, Benutzername, Locale, Build-Zeit usw.). Auch diese Informationen werden zunächst in dieselbe fest kodierte TXT-Datei geschrieben, bevor sie an den C2-Server gesendet werden.
Die nächste Stealing-Funktion exfiltriert Steam-Anmeldedaten und Tokens. Die entsprechenden Informationen werden über den Registry-Eintrag des Installationspfads ermittelt, wobei Konto- und Login-Token-Daten aus den Konfigurationsdateien (loginuser.vdf, local.vdf) extrahiert werden. Auch diese Daten werden wieder in dieselbe fest kodierte TXT-Datei geschrieben, bevor sie an den C2-Server gesendet werden.
Die folgende Funktion zeigt die Fähigkeit des Stealers, mehrere sekundäre Payloads basierend auf der zugewiesenen Feldkonfiguration auszuführen. In dieser Funktion werden zusätzliche Payloads (exe, cmd, dll und ps1) in vier Fälle aufgeteilt. Dadurch wird festgelegt, welche Art der Ausführung der Code durchführen soll. Insgesamt sind drei Ausführungsmethoden vorhanden: zwei PowerShell-Befehle über CreateProcessA sowie eine Process-Hollowing-Technik, bei der rundll32.exe als Hostprozess verwendet wird.
Anstatt rundll32.exe über seine legitime DLL-Export-Schnittstelle aufzurufen (rundll32.exe <dll>, <export>), verwendet die Malware Process Hollowing. Zunächst wird rundll32.exe mithilfe des Flags CREATE_SUSPENDED in einem angehaltenen Zustand gestartet. Anschließend wird die bösartige Payload injiziert, der Instruction Pointer des primären Threads überschrieben und der Thread wieder fortgesetzt, wodurch effektiv der ursprüngliche Einstiegspunkt des Prozesses umgangen wird.
Die erste PowerShell-Befehlsfunktion ist dafür verantwortlich, ausschließlich .ps1- und .exe-Dateien auszuführen. Die .ps1-Datei wird mit den Argumenten „-NoProfile -ExecutionPolicy Bypass -File“ ausgeführt. Bei .exe-Dateien wird lediglich der Pfad der ausführbaren Datei als Befehlszeile vorbereitet. In beiden Fällen werden die .ps1- und .exe-Dateien über CreateProcessA ausgeführt.
Der zweite PowerShell-Befehl verwendet neben der Bypass-Ausführungsmethode auch DownloadString, das über Invoke-Expression (IEX) ausgeführt wird. Diese Funktion führt ausschließlich den Typ „4“ aus, der einer .ps1-Datei entspricht.
Diese Version von ACRStealer ist möglicherweise noch unvollständig. Wir sehen keine Funktion, die eine .cmd-Datei ausführt, und das Process Hollowing ist dem Typ „5“ zugeordnet, was nicht korrekt dem deklarierten Typ „3“ oder .dll-Dateien entspricht. Dies könnte auch auf einen Programmierfehler oder ein Versehen hindeuten, da sowohl cmd- als auch dll-Dateien deklariert, jedoch nie ausgeführt werden.
Die letzte Funktion umfasst das rekursive Durchlaufen von Dateien, wobei ausführbare Dateitypen (exe, dll, msi, sys) übersprungen werden, um vermutlich das Sammeln von Systemdateien zu vermeiden. Außerdem werden Screenshots erstellt, indem Bibliotheken (user32.dll und gdi32.dll) sowie APIs wie GetDC, CreateCompatibleBitmap und BitBlt dynamisch über GetProcAddress aufgelöst werden. Das aufgenommene Bild wird anschließend als „g/screen/screen.bmp“ gespeichert.
Jede gestohlene Information wird in ein im Speicher befindliches ZIP-Archiv eingefügt, dessen maximale Größe auf 40 MB (0x2800000) begrenzt ist. Sobald der Vorgang abgeschlossen ist, wird das Archiv über TCP-Port 443 an den C2-Server gesendet.
Patterns in Action
Die Aktivitäten von ACRStealer zeigen ein sehr interessantes operatives Muster. VirusTotal-Telemetriedaten weisen auf aktive Infektionen in Ländern wie den USA, der Mongolei und Deutschland hin. Alle identifizierten Samples kommunizieren mit derselben IP-Adresse (157[.]180[.]40[.]106), und fünf der sieben gesammelten Samples stellen zusätzlich Verbindungen zu playtogga[.]com her. Playtogga ist eine beliebte Fantasy-Fußballplattform mit Hauptsitz in Austin, Texas. Im Gegensatz dazu ist PiviGames die Domain, von der HijackLoader heruntergeladen wurde, der letztlich ACRStealer ablegt, und weist generell ein höheres Verkehrsaufkommen in spanischsprachigen Ländern auf. Diese Interaktion deutet darauf hin, dass ACRStealer einen breiten und vielfältigen digitalen Fußabdruck nutzt, möglicherweise um sich zu tarnen und im legitimen Datenverkehr unterzugehen.
In den ersten Tagen des Jahres 2026 ist die bösartige URL (hxxps://pivigames[.]blog/adbuho) weiterhin aktiv, jedoch scheint es einige Änderungen zu geben. Sie folgt noch immer demselben Skript und derselben Weiterleitungskette, führt nun jedoch zu einem neuen Cloud-Speicher- und Hosting-Dienst, in diesem Fall Mega. Die heruntergeladene ZIP-Datei enthält jetzt nur noch eine einzelne ausführbare Datei ohne Ressourcen-Dateien oder Ordner, im Gegensatz zur zuvor heruntergeladenen ZIP-Datei. Die Analyse zeigte, dass die ausführbare Datei, die ebenfalls den Namen „Setup.exe“ trägt, eine Variante von LummaStealer ist.
Dies deutet lediglich darauf hin, dass die Bedrohungsakteure, die die PiviGames-Infrastruktur kontrollieren, weiterhin kontinuierlich Systeme infizieren. Wie in diesem Fall könnten sie weiterhin aktiv ahnungslose Nutzer auf beliebten Gaming-Plattformen wie Steam, Discord, Twitch und sogar in sozialen Medien wie Reddit ansprechen, um Systeme zu kompromittieren und Daten zu stehlen.
IOCs
[1] FuII Verslon Setup 6419 σρєи Download.zip (sic!), archive with all files 418A1A6B08456C06F2F4CC9AD49EE7C63E642CCE1FA7984AD70FC214602B3B1
[2] ACRStealer, payload - 59202cb766c3034c308728c2e5770a0d074faa110ea981aa88f570eb402540d2 - Win32.Trojan-Stealer.ACRStealer.%M
[3] LummaStealer -f88c6e267363bf88be69e91899a35d6f054ca030e96b5d7f86915aa723fb268b - Win32.Trojan-Stealer.LummaStealer.%M
[4] 157[.]180[.]40[.]106 – ACRStealers’ C2 URL - Malware
[5] playtogga[.]com – ACRStealers’ C2 URL - Malware
