Das FishMonger-Arsenal wurde erweitert: SprySOCKS für Windows

ESET Forscher haben zwei bislang nicht dokumentierte Windows-Varianten von der Backdoor SprySOCKS entdeckt. Diese war bisher ausschließlich unter Linux bekannt. Berichten zufolge nutzt sie die Hacker-Gruppe FishMonger. Von ihr wird angenommen, dass sie von einem chinesischen Auftragnehmer namens I‑SOON betrieben wird. Während wir die Malware-Proben ursprünglich auf VirusTotal entdeckt haben, zeigen ESET-Telemetriedaten tatsächliche Aktivitäten zwischen 2023 und 2024 mit mehreren Opfern in Honduras, Taiwan, Thailand und Pakistan. Vor allem wurden Regierungsorganisationen ins Visier genommen.

Die entdeckten Windows-Varianten sind intern als WIN_DRV und WIN_PLUS gekennzeichnet. Beide verfügen über eine fest codierte C&C-Konfiguration und unterstützen die Kommunikation über TCP-, UDP- und WebSocket-Protokolle. Die Kernfunktionalität der Backdoor umfasst für beide die Unterstützung von über 30 C&C-Befehlen, die verschiedene Funktionen abdecken. Dazu zählen unter anderem das Sammeln von Systeminformationen, die Auflistung von Prozessen sowie Funktionen zur Dienst- und Dateiverwaltung wie das Auflisten, Erstellen, Löschen und Übertragen von Dateien.

Zusätzlich zu den Kernfunktionen der Backdoor nutzt die WIN_DRV-Version Kernel-Treiber, um die Netzwerkverbindungen, Prozesse, Dateien und Registrierungsschlüssel der Malware zu verbergen. Das ermöglicht die Umleitung des TCP-Datenverkehrs, sodass die Malware-Betreiber Befehle über einen zufälligen TCP-Port auf dem Gerät des Opfers an die Backdoor senden können, ohne den tatsächlichen Listening-Port der Backdoor im Netzwerkverkehr preiszugeben.

Basierend auf ESET-Telemetriedaten gibt es vereinzelte Hinweise darauf, dass einige SprySOCKS-Angriffsszenarien eine UEFI-Bootkit-Komponente beinhalten könnten, die möglicherweise CVE-2023-24932 ausnutzt.

Die in diesem Bericht vorgestellte Analyse lässt uns diese neuen Windows-Varianten mit hoher Sicherheit FishMonger zuordnen.

Kernpunkte dieses Blogbeitrags:

• Wir haben zwei bisher undokumentierte Windows-Varianten der SprySOCKS -Backdoor von FishMonger entdeckt.
• Die ESET-Telemetrie zeigt Aktivitäten zwischen 2023 und 2024, die sich in erster Linie gegen Regierungsorganisationen in Honduras, Taiwan, Thailand und Pakistan richten.
• Beide Windows-Varianten unterstützen die Kommunikation über TCP-, UDP- und WebSocket-Protokolle und implementieren über 30 Befehle.
• Die WIN_DRV-Variante erstellt eine heimliche passive TCP-Backdoor, die sich auf einen Kernel-Treiber stützt, um den Datenverkehr an den versteckten TCP-Port der Backdoor umzuleiten, sobald speziell gestaltete Daten in einem empfangenen TCP-Paket erkannt werden.

FishMonger-Profil

FishMonger – vermutlich betrieben von einem chinesischen Auftragnehmer namens I‑SOON (siehe unseren APT-Aktivitätsbericht für das 4. Quartal 2023 bis 1. Quartal 2024) – ist eine Cyberspionagegruppe, die zur Winnti-Gruppe gehört. Höchstwahrscheinlich operiert sie von China aus, genauer gesagt aus der Stadt Chengdu. Sie ist auch unter den Namen Earth Lusca, TAG-22, Aquatic Panda oder Red Dev 10 bekannt. Wir haben Anfang 2020 eine Analyse zu FishMonger veröffentlicht, als die Gruppe während der im Juni 2019 begonnenen Bürgerproteste vor allem Universitäten in Hongkong ins Visier nahm. Die Gruppe ist laut Trend Micro auch dafür bekannt, Watering-Hole-Angriffe durchzuführen. Zu den Tools von FishMonger gehören ShadowPad, Spyder, Cobalt Strike, FunnySwitch, SprySOCKS und die BIOPASS RAT.

Technische Analyse

In diesem Abschnitt stellen wir eine technische Analyse dieser neuen Windows-Varianten der SprySOCKS-Backdoor von FishMonger vor.

Das Archiv, das uns zu dieser Entdeckung führte, wurde im April 2024 unter dem Namen klelam00007.zip auf VirusTotal hochgeladen; sein Inhalt ist in Abbildung 1 dargestellt.

Dieses Archiv enthält verschiedene Dateien, darunter legitime Dateien, die zum Hosten von DLL-Side-Loading verwendet werden; Darunter befinden sich auch drei verdächtig aussehende, verschlüsselte Dateien mit der Erweiterung .dat. Unsere anschließende Analyse ergab, dass diese verschlüsselten Dateien eine neue, bisher undokumentierte Windows-Variante der SprySOCKS-Backdoor von FishMonger enthalten. Die wird von ihren Entwicklern als WIN_DRV bezeichnet. Weitere Untersuchungen ergaben eine zusätzliche Backdoor-Version mit der Bezeichnung WIN_PLUS in der ESET Telemetry.

Erster Zugriff

FishMonger ist dafür bekannt, die öffentlich zugänglichen Server seiner Opfer anzugreifen und dabei häufig serverbasierte Zero-Day-Schwachstellen auszunutzen, um sich einen ersten Zugriff zu verschaffen. Obwohl wir nicht genau bestätigen konnten, wie FishMonger in dieser Kampagne in die Systeme seiner Opfer gelangte, deuten das Vorhandensein eines Server-Betriebssystems auf einigen der Opfergeräte sowie die typische Vorgehensweise von FishMonger darauf hin, dass die Angreifer möglicherweise über falsch konfigurierte oder nicht gepatchte öffentlich zugängliche Anwendungen eingedrungen sind.

SprySOCKS für Windows

Im September 2023 veröffentlichte Trend Micro einen Bericht über eine neue FishMonger-Linux-Backdoor, die seine Analysten SprySOCKS nannten. Der Code der Backdoor basiert auf einem Open-Source-Windows-Remote-Access-Trojaner (RAT) namens Trochilus und weist mehrere Gemeinsamkeiten mit der RedLeaves-Backdoor auf; dennoch wurde er so stark erweitert und modifiziert, dass er als neue Backdoor angesehen werden kann. In diesem Bericht analysieren wir zwei bislang unveröffentlichte Windows-Varianten der Version 1.8 von SprySOCKS:

• Eine wurde von ihren Entwicklern WIN_DRV genannt und nutzt einen Kernel-Treiber für erweiterte Tarnung.
• Eine andere, ohne den Treiber, heißt WIN_PLUS.

Wie in Abbildung 2 dargestellt, sind der Versionstyp und die Versionsnummer der Backdoor fest in die Binärdatei eingebettet.

Die überwiegende Mehrheit der Artefakte und Funktionen, die in der Linux-Version der SprySOCKS-Backdoor aus dem Trend Micro-Bericht vorhanden sind, findet sich auch in den neu entdeckten Windows-SprySOCKS-Varianten. Dazu gehören:

• das gleiche C&C-Nachrichtenformat,
• sehr ähnliche C&C-Befehle (sowie einige zusätzliche),
• die gleichen Verschlüsselungsschlüssel und -algorithmen sowie
• die Verwendung derselben statisch verknüpften Netzwerkbibliothek (HP-Socket).

Bei beiden neuen SprySOCKS-Varianten ist die Kernfunktionalität der Backdoor, die die C&C-Kommunikation und die verfügbaren Befehle umfasst, sehr ähnlich. Die auffälligsten Unterschiede zeigen sich in der Art und Weise, wie die endgültige Backdoor geladen wird, in der verbesserten Tarnung sowie in den verwendeten Komponentennamen und Pfaden.

In den folgenden Unterabschnitten analysieren wir zunächst die Komponenten, die an der Ausführungs-Kette der einzelnen SprySOCKS-Varianten beteiligt sind, und beschreiben anschließend die Backdoor-Komponente, die bei beiden Varianten weitgehend identisch ist.

WIN_DRV-Komponenten

In einem auf VirusTotal hochgeladenen Archiv entdeckten wir die WIN_DRV-Version von SprySOCKS, die mit einer leeren C&C-Konfiguration ausgestattet ist. Daher kontaktiert diese Version keine Remote-Adressen aktiv; sie ist jedoch weiterhin in der Lage, einen TCP-Server auf einem zufälligen Port auf dem Gerät des Opfers zu starten und fungiert somit als passive Backdoor. Interessanterweise müssen die Angreifer die TCP-Portnummer dieses Servers nicht kennen, da, wie später erläutert wird, der von der WIN_DRV-Version verwendete RawWNPF-Treiber eine stillschweigende Umleitung – zur Backdoor selbst – des auf einem beliebigen offenen Port empfangenen TCP-Verkehrs ermöglicht (mehr dazu im Abschnittzum RawWNPF-Treiber ).

Wie in Abbildung 1 dargestellt, enthält das Archiv mit der WIN_DRV-Version von SprySOCKS mehrere Dateien:

• klelam00007.bat – ein Batch-Skript, das für die Persistenz der Backdoor zuständig ist. Wie in Abbildung 3 dargestellt, führt es folgende Schritte aus:

○ kopiert alle Dateien aus dem aktuellen Arbeitsverzeichnis in das Verzeichnis %SystemRoot%\Fonts (um ordnungsgemäß zu funktionieren, muss die Batch-Datei im selben Verzeichnis wie die übrigen Dateien aus dem Archiv bereitgestellt werden),

○ erstellt eine geplante Aufgabe namens „ApphostRagistreationVerifier“, die so konfiguriert ist, dass sie „ApphostRagistreationVerifier.exe“ (eine legitime, gültig signierte ausführbare Datei, die von den Angreifern umbenannt wurde, um die legitime, von Microsoft signierte „AppHostRegistrationVerifier.exe“ nachzuahmen) bei jedem Systemstart mit NT AUTHORITY\SYSTEM-Re chten bei jedem Systemstart auszuführen. Die Angreifer nutzen die bekannte DLL-Side-Loading-Technik und machen sich die Art und Weise zunutze, wie Windows DLLs lädt, um ihre eigene schädliche DLL (in diesem Fall tpsvcloc.dll) mithilfe einer legitimen, signierten Anwendung zu laden. Genauer gesagt nutzen die Angreifer in diesem Fall die Technik des Malware-Sideloadings über MFC-Satelliten-DLLs (beachten Sie den „loc“- String im Dateinamen tpsvcloc.dll ),

• ApphostRagistreationVerifier.exe – eine legitime, signierte ausführbare Datei des ThinPrint-Dienstes zur Erstellung von AutoConnect-Druckern (SHA-1: FFC3AA7909D4E72C360D65A1F45260DFFE5C99B7), die die Bibliothek tpsvc.dll lädt,
• tpsvc.dll – eine legitime, signierte Bibliothek, die die Bibliothek tpsvcloc.dll lädt,
• tpsvcloc.dll – der Loader für die SprySOCKS-Backdoor,
• X1B5206BDC1743DD.dat – ein verschlüsselter Container, der die SprySOCKS-Backdoor und Kopien der beiden folgenden Dateien enthält,
• KX1B5206BDC1743DD.dat – DriverLoader, ein verschlüsselter Kernel-Treiber, der für das Laden eines weiteren Kernel-Treibers aus KW1B5206BDC1743FP.dat zuständig ist, und
• KW1B5206BDC1743FP.dat – RawWNPF, ein verschlüsselter Kernel-Treiber, der für das Verbergen der Backdoor-Dateien und der Netzwerkaktivitäten zuständig ist.

Abbildung 4 zeigt die Ausführungsfolge der SprySOCKS-WIN_DRV-Variante.

Die folgenden drei Unterabschnitte enthalten technische Analysen der oben genannten Komponenten: SprySOCKS-Loader, DriverLoader-Treiber und RawWNPF-Treiber.

SprySOCKS-Loader

Der Loader beginnt mit ersten Überprüfungen auf das Vorhandensein einer virtuellen Umgebung und einiger Sicherheitsprodukte. Er sucht im Prozess des Loaders nach bestimmten Bibliotheken (nämlich: snxhk.dll, SxWrapper.dll, SxIn.dll, SXIn64.dll und SbieDll.dll) und beendet sich, wenn er eine davon findet.

Im nächsten Schritt überprüft er, ob die Persistenz durch das Skript klelam00007.bat aus Abbildung 3 erfolgreich eingerichtet wurde. Dazu prüft es, ob das aktuelle Loader-Image aus dem Verzeichnis %SystemRoot%\Fonts\ geladen wurde, und versucht, auf die Dateien %SystemRoot%\Fonts\X1B5206BDC1743DD.dat, %SystemRoot%\Fonts\tpsvc.dll sowie %SystemRoot%\Fonts\tpsvcloc.dll zuzugreifen. Stellt es fest, dass sich eine dieser Dateien nicht an der vorgesehenen Stelle befindet, richtet es die Persistenz selbstständig ein, indem es:

• X1B5206BDC1743DD.dat, tpsvc.dll, tpsvcloc.dll und ApphostRagistreationVerifier.exe aus dem aktuellen Arbeitsverzeichnis in das Verzeichnis %SystemRoot%\Fonts\ kopiert,
• die Anwendung %SystemRoot%\Fonts\ApphostRagistreationVerifier.exe als Debugger für vds.exe (ein Virtual Disk Service, der beim Systemstart automatisch ausgeführt werden kann) registriert, indem der Pfad der Anwendung in den Registrierungswert HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\vds.exe\debugger ein, und
• die Datei „affair-build.bat“ in das Verzeichnis %SystemRoot%\Fonts\ kopiert und anschließend über cmd.exe ausgeführt. Dieses Skript, das in Abbildung 5 dargestellt ist, löscht die Spuren dieses Vorgangs, indem es Dateien aus dem Bereitstellungsverzeichnis entfernt und die Malware erneut (jetzt von %SystemRoot%\Fonts\) ausführt, indem der vds-Dienst neu gestartet wird.

Sobald die Persistenz eingerichtet ist, fährt der Loader mit dem Laden von Payloads aus einem verschlüsselten Container fort, der sich unter %SystemRoot%\Fonts\X1B5206BDC1743DD.dat befindet. Der Entschlüsselungsalgorithmus und der Schlüssel: 128-Bit-AES im ECB-Modus mit dem fest codierten Schlüssel uXQLESMXGaRMs6BL.

Dies erzeugt Shellcode, der vom Open-Source-Tool DllToShellCode generiert wurde. Vor der Ausführung des Shellcodes extrahiert er die restlichen verschlüsselten Payloads aus dem Container in separate Dateien:

• %SystemRoot%\Fonts\KX1B5206BDC1743DD.dat
• %SystemRoot%\Fonts\KW1B5206BDC1743FP.dat

Anschließend startet der Loader mithilfe von CreateProcessAsUserW und einem von spoolsv.exe bezogenen Token einen neuen svchost.exe-Prozess und injiziert den Shellcode der Backdoor unter Verwendung der Prozess-Doppelgänger -Technik in diesen Prozess. Während des Injektionsvorgangs wird der Shellcode in eine temporäre Datei mit dem Präfix TH im Dateinamen im Verzeichnis %TEMP% abgelegt.

Als letzten Schritt entschlüsselt und führt der Loader „DriverLoader“ aus, einen Kernel-Treiber, der in der zuvor abgelegten Datei „KX1B5206BDC1743DD.dat“ versteckt ist. DriverLoader wird zunächst entschlüsselt, anschließend wird der entschlüsselte Inhalt unter C:\Windows\System32\drivers\fsdiskbit.sys gespeichert. Um ihn auszuführen, installiert der Loader diesen Treiber als Minifilter-Treiber, indem er manuell einen neuen Dienst-Registrierungsschlüssel namens „msidiskserver“ mit einem ImagePath -Wert erstellt, der auf den abgelegten Treiber verweist (wie in Abbildung 6 dargestellt), und ruft die Windows-API-Funktion „NtLoadDriver“ mit dem Registrierungsschlüssel als Parameter auf, um ihn zu laden. Wenn keine Fehler festgestellt werden, löscht der Loader sowohl den Registrierungsschlüssel „msidiskserver“ als auch die Datei „fsdiskbit.sys “. Danach ist der Loader fertig und wird beendet.

DriverLoader-Treiber

Bevor wir uns der Funktionalität von DriverLoader zuwenden, noch ein wichtiger Hinweis: Mit der Veröffentlichung von Windows Vista führte Microsoft die Treibersignaturüberprüfung (DSE) ein, eine Funktion, die sicherstellt, dass nur gültig signierte Kernel-Modus-Komponenten im Windows-Kernel ausgeführt werden dürfen. Das bedeutet, dass Angreifer den fsdiskbit.sys -Treiber (DriverLoader) mit einem vertrauenswürdigen Zertifikat signieren müssen, um ihn ausführen zu können.

Um den Treiber zumindest auf einigen veralteten oder falsch konfigurierten Systemen zum Laufen zu bringen, verwendeten die Angreifer ein durchgesickertes Zertifikat, das auf GitHub im PastDSE-Projekt-Repository verfügbar war, und signierten den fsdiskbit.sys-Treiber damit. Informationen zum verwendeten Zertifikat finden sich in Abbildung 7.

Nun zur Funktionalität. Der Zweck dieser Komponente ist recht einfach: einen weiteren Treiber zu laden, diesmal jedoch nur im Speicher. Zunächst liest und entschlüsselt sie den Inhalt der Datei C:\Windows\Fonts\KW1B5206BDC1743FP.dat, die zuvor vom Loader erstellt wurde. Dabei werden derselbe Algorithmus und derselbe Schlüssel wie vom Loader verwendet: 128-Bit-AES im ECB-Modus mit dem Schlüssel uXQLESMXGaRMs6BL. Die entschlüsselten Daten enthalten eine native PE-Binärdatei (beschrieben im Abschnittzum RawWNPF-Treiber ), die anschließend manuell zugeordnet und deren Einstiegspunkt ausgeführt wird.

Der PDB-Pfad ist in der DriverLoader-Binärdatei eingebettet:

C:\Users\xdd\Desktop\今天\2023-4-11\2023‑04‑10__注册表驱动加载功能__集成到内测3中-未完成\DriverMemoryLoadDriver\x64\Release\DriverMemoryLoadDriver.pdb

Die Teile in vereinfachtem Chinesisch lassen sich maschinell wie folgt übersetzen:

• 今天: Heute
• 注册表驱动加载功能__集成到内测3中-未完成: Funktion zum Laden von Treibern aus der Registrierung__ist in die interne Beta 3 integriert – unvollständig

Wie aus dem Symbolpfad ersichtlich ist, scheint diese Komponente mindestens seit April 2023 in der Entwicklung zu sein, was mit dem Kompilierungszeitstempel von DriverLoader übereinstimmt. Ebenso deuten die Zeichenfolgen im Pfad darauf hin, dass sich das Projekt, zu dem dieser Treiber gehört, zum Zeitpunkt der Kompilierung des Treibers wahrscheinlich noch in der Entwicklung befand.

RawWNPF-Treiber

Der RawWNPF-Treiber ist die Komponente, die die WIN_DRV -Version der SprySOCKS-Backdoor im Vergleich zur WIN_PLUS-Variante wesentlich unauffälliger macht. Er ermöglicht es, die böswilligen Aktivitäten der Backdoor auf dem kompromittierten System zu verbergen, und kann durch Aufruf der benutzerdefinierten I/O-Steuercodes (IOCTLs) des Treibers konfiguriert werden. Der Treiber erstellt einen Gerätetreiber namens \Device\RawWNPF; eine Liste der verfügbaren IOCTLs mit kurzen Beschreibungen ist in Tabelle 1 aufgeführt.

Tabelle 1. Liste der vom RawWNPF-Treiber unterstützten IOCTLs

Ausblenden bestimmter Prozesse

Der RawWNPF-Treiber kann so konfiguriert werden, dass er Prozesse anhand ihrer Prozess-IDs ausblendet, und eine Liste der ausgeblendeten Prozesse kann durch Aufruf der IOCTLs 0x220358, 0x22035C, 0x220354 und 0x220350 verwaltet werden. Um einen Prozess auszublenden, fängt der Treiber die Ausführung des Systemaufrufs NtQuerySystemInformation ab und ändert dessen Ausgabe, wenn Informationen über laufende Prozesse abgerufen werden (d. h., wenn SystemProcessInformation an den Parameter SystemInformationClass übergeben wird). Wenn einer der von dieser API-Funktion abgerufenen Prozesse mit einem Prozess aus der Liste der versteckten Prozesse des Treibers übereinstimmt, entfernt der Treiber diesen Prozess aus der Ausgabe der Funktion. Die Art und Weise, wie der Kernel-Treiber den Systemaufruf NtQuerySystemInformation abfängt, scheint stark auf dem Quellcode des InfinityHookPro-Projekts zu basieren.

Netzwerkaktivität verbergen

Der Treiber kann so konfiguriert werden, dass bestimmte aktive Verbindungen (mit einer bestimmten IP-Adresse, einem bestimmten Port oder einer Kombination aus beidem) verborgen werden, sodass sie nicht in der Ausgabe gängiger Netzwerkverwaltungstools wie netstat.exe aufgeführt werden. Dies wird durch eine bekannte Technik erreicht (z. B. [1], [2], [3], …), bei der Angreifer IoCompletionRoutine für IOCTL 0x12001B innerhalb der DeviceIoControl-Funktion des Windows-Kernel-Treibers nsiproxy.sys hooken. Der Code im 0x12001B -IOCTL-Handler von nsiproxy ist für das Abrufen der Liste aktiver Verbindungen zuständig, und das Hooken seiner IoCompletionRoutine ermöglicht es Angreifern, die abgerufene Liste zu durchlaufen, auf das Vorhandensein bestimmter Ports, Adressen oder beidem zu prüfen und die betreffende Verbindung in der Liste zu verbergen, falls eine Übereinstimmung gefunden wird. Abbildung 8 zeigt die Hook-Funktion, die für das Verbergen von Netzwerkverbindungen zuständig ist.

Zusätzlich zum Ausblenden aktiver Netzwerkverbindungen enthält der Treiber eine interessante Funktion, die es ihm ermöglicht, auf einem beliebigen offenen TCP-Port empfangene TCP-Pakete an den durch den IOCTL 0x220200 konfigurierten TCP-Port umzuleiten (es handelt sich dabei um den Port des TCP-Servers der SprySOCKS-Backdoor), jedoch nur dann, wenn die empfangenen TCP-Daten speziell manipulierte Daten enthalten. Um dies zu erreichen, registriert der Treiber seine eigenen Paketfilterobjekte mithilfe von Windows Filtering Platform (WFP)-API-Funktionen, analysiert manuell den Inhalt der übertragenen IPv4-Pakete (sowohl eingehender als auch ausgehender Datenverkehr wird überprüft) und leitet den Datenverkehr um, wenn die speziell gestalteten Daten in den Daten eines empfangenen TCP-Pakets erkannt werden. Der Zweck dieser Funktion scheint hauptsächlich darin zu bestehen, die bösartige Backdoor kontaktieren zu können, ohne eine C&C-Adresse in die Binärdatei einbetten zu müssen. Zudem wird, obwohl solcher umgeleitete Datenverkehr mit Tools wie Wireshark untersucht werden kann, der tatsächliche Port (derjenige, zu dem der Datenverkehr umgeleitet wird) nicht offengelegt; daher kann es schwierig sein, das tatsächliche Ziel dieses bösartigen Datenverkehrs zu ermitteln.

Die installierten Paketfilter sind zusammen mit ihren Identifikationsdaten in Tabelle 2 aufgeführt.

Tabelle 2. Vom RawWNPF-Treiber registrierte WFP-Filterobjekte

Verbergen der Dateien der Backdoor

Der Treiber verbirgt/schützt die Dateien der SprySOCKS-Backdoor, indem er sich als Minifilter-Treiber registriert und die folgenden Callbacks installiert:

• Pre-Operation-Callback, der bei jeder IRP_MJ_CREATE -E/A-Anforderung ausgelöst wird und dafür zuständig ist, bei jedem Versuch, eine Datei oder ein Verzeichnis aus der Liste der versteckten/geschützten Dateien des Treibers zu erstellen oder zu öffnen, STATUS_NO_SUCH_FILE zurückzugeben,
• Pre-Operation-Callback, der bei jeder IRP_MJ_DIRECTORY_CONTROL-E/A-Anforderung ausgelöst wird und dafür zuständig ist, Anforderungen herauszufiltern, die nicht mit der Verzeichnisauflistung zusammenhängen, sodass nur die Anforderungen, die sich auf die Verzeichnisauflistung beziehen, an den Post-Operation-Callback weitergeleitet werden, und
• Post-Operation-Callback, der bei IRP_MJ_DIRECTORY_CONTROL-E/A- Anfragen ausgelöst wird, die die Prüfungen des Pre-Operation-Callbacks bestanden haben. Dieser Callback ist dafür zuständig, Einträge versteckter/geschützter Dateien aus allen Versuchen zur Verzeichnisauflistung zu entfernen.

Die folgende fest codierte Liste von Dateinamen wird vom Treiber geschützt:

• \SystemRoot\Fonts\tpsvc.dll
• \SystemRoot\Fonts\tpsvcloc.dll
• \SystemRoot\Fonts\ApphostRagistreationVerifier.exe
• \SystemRoot\Fonts\X1B5206BDC1743DD.dat
• \SystemRoot\Fonts\KX1B5206BDC1743DD.dat
• \SystemRoot\Fonts\KW1B5206BDC1743FP.dat

Schutz der Persistenz

Der Treiber ruft CmRegisterCallbackEx auf, um eine RegistryCallback-Routine zu installieren, die dafür zuständig ist, den Registrierungsschlüssel zu verbergen, der für die Persistenz des SprySOCKS-Loaders verwendet wird: HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\vds.exe. Infolgedessen werden alle Versuche, den Schlüssel zu öffnen oder aufzulisten, vom Treiber herausgefiltert.

WIN_PLUS-Komponenten

In der SprySOCKS-WIN_PLUS-Version entdeckten wir den bösartigen verschlüsselten Container erstmals in unseren Telemetriedaten, wobei der erste Treffer auf Juli 2024 zurückging und auf dem Gerät eines Opfers in Pakistan gefunden wurde. Er enthielt die SprySOCKS-Backdoor und den SprySOCKS-Loader. Die C&C-Konfiguration war vorhanden und ist in Abbildung 9 dargestellt.

Der verschlüsselte Container befand sich auf dem kompromittierten System unter folgendem Pfad:

C:\Windows\System32\spool\drivers\color\config.dat

Nach der Entschlüsselung enthält der Container einen SprySOCKS-Loader und die SprySOCKS-Backdoor selbst. Eine weitere Analyse der SprySOCKS-Backdoor aus dem Container ergab, dass es in diesem Fall offenbar eine zusätzliche Komponente gab, die für das Laden des SprySOCKS-Loaders aus dem verschlüsselten Container zuständig war. Diese Komponente – in dieser Analyse als First-Stage-Loader bezeichnet – sollte als Druckprozessor unter dem folgenden Registrierungsschlüssel installiert werden:

HKLM\SYSTEM\ControlSet001\Control\Print\Environments\Windows x64\Print Processors\VSPMsg

Interessanterweise entdeckten wir bei der Durchsuchung unserer Telemetriedaten nach allem, was mit dieser VSPMsg-Zeichenkette zu tun hatte, eine Datei, die auf zwei verschiedenen Opfergeräten aus Honduras unter C:\Windows\System32\spool\prtprocs\x64\VSPMsg.dll bereitgestellt wurde. Diese Datei erwies sich als der Loader der ersten Stufe, der für die Ausführung des SprySOCKS-Loaders aus der oben genannten config.dat-Datei verantwortlich ist.

Ein Ausführungsdiagramm der SprySOCKS -Variante WIN_PLUS ist in Abbildung 10 dargestellt.

Loader der ersten Stufe

Dieser Loader prüft zunächst, ob er von spoolsv.exe ausgeführt wurde, und beendet sich andernfalls; dadurch wird sein Verhalten vor automatisierten Malware-Analyse-Sandboxes verborgen, da der Loader als Druckprozessor ausgeführt werden soll. Anschließend entschlüsselt er den SprySOCKS-Loader aus dem verschlüsselten Container C:\Windows\System32\spool\drivers\‌color\config.dat. Zunächst entschlüsselt er den Loader mit 128-Bit-AES-ECB unter Verwendung des fest codierten Schlüssels uXQLESMXGaRMs6BL und injiziert ihn dann mittels Prozess-Doppelgänger in den neu erstellten svchost.exe-Prozess. In der Zwischenzeit wird der SprySOCKS-Loader in einer temporären Datei mit dem Dateinamenpräfix TH im Verzeichnis %TEMP% abgelegt.

Das Beispiel exportiert zwei Funktionen:

• GetErrorMessageModule
• SetErrorMessageModule

Während die Funktion „SetErrorMessageModule“ nichts tut, dient die Funktion „GetErrorMessageModule“ dazu, die Persistenz für den Loader selbst festzulegen. Bei Ausführung registriert sie den Loader als Druckprozessor, indem sie den Registrierungsschlüssel HKLM\SYSTEM\ControlSet001\Control\Print\Environments\Windows x64\Print Processors\VSPMsg anlegt, den Registrierungswert „Driver“ auf „VSPMsg.dll“ setzt und die fest codierte Datei „C:\ProgramData\Microsoft Event\PFs\VSPMsg.dll“ in das Verzeichnis „C:\Windows\System32\spool\prtprocs\x64\“ kopiert. Im nächsten Schritt kopiert es den verschlüsselten Container aus C:\ProgramData\Microsoft Event\PFs\config.dat nach C:\Windows\System32\spool\drivers\color\config.dat und erstellt anschließend das Batch-Skript affair-build.bat, legt es im Verzeichnis C:\Windows\System32\spool\drivers\color\ ab und führt es aus. Wie in Abbildung 11 dargestellt, dient dieses Skript dazu, die Spuren des Loaders zu verwischen, indem die Dateien im ursprünglichen Bereitstellungsverzeichnis entfernt werden, und die Ausführung des neu installierten Druckprozessors durch einen Neustart des Druckspooler-Dienstes auszulösen.

SprySOCKS-Loader

Dieser Loader beginnt mit der Erstellung eines Mutex mit dem fest codierten Namen fqwhi2d1qaz2 und fährt dann fort, die SprySOCKS-Backdoor aus dem verschlüsselten Container unter C:\Windows\System32\spool\drivers\color\‌config.dat zu laden. Er entschlüsselt die Backdoor mit 128-Bit-AES-ECB unter Verwendung des fest codierten Schlüssels uXQLESMXGaRMs6BL und injiziert sie anschließend mittels Prozess-Doppelgänger-Technik in den neu erstellten svchost.exe-Prozess. Unterdessen wird der SprySOCKS-Loader in einer temporären Datei mit dem Dateinamenpräfix TH im Verzeichnis %TEMP% abgelegt.

SprySOCKS-Backdoor

Schließlich fahren wir mit der Analyse der SprySOCKS-Backdoor selbst fort. In beiden Varianten, WIN_DRV und WIN_PLUS, ist die Funktionalität der Backdoor nahezu identisch; Unterschiede bestehen lediglich in den verwendeten Dateipfaden und Registrierungsschlüsseln. Wie bereits erwähnt, verwendet die WIN_PLUS-Version den RawWNPF-Treiber nicht für erweiterte Tarnung.

Beide in diesem Bericht analysierten Varianten sind DLLs mit dem ursprünglichen Namen PrcsServer.dll, die eine Funktion namens Stop exportieren. Sie erstellen zu Beginn einen Mutex namens prcs-server-run und fahren unmittelbar danach mit der Initialisierung der Hauptfunktionalität der Backdoor fort, die die Initialisierung und den Start von C&C-Kommunikationskanälen (basierend auf der fest codierten Konfiguration) sowie die Einrichtung des Keyloggers umfasst. Zusätzlich zu diesen Aktionen initialisiert die WIN_DRV-Backdoor- Version den RawWNPF-Treiber, indem sie dessen 0x222000 -IOCTL-Handler aufruft, und verbirgt anschließend ihren eigenen Prozess durch Aufruf des 0x220350 -IOCTL des Treibers.

Das Keylogging wird nur aktiviert, wenn unter %appdata%\Microsoft\Vault\lgf.dat eine INI-Datei vorhanden ist, die einen Konfigurationsabschnitt mit einer Eigenschaft namens „key“ enthält, die auf 1 gesetzt ist. Sind diese Bedingungen erfüllt, erstellen beide Backdoors einen Mutex namens „Global\{DCAA7ED8-521B-4EAB-BE21-65254CF59239}“ und protokollieren regelmäßig Daten aus der Zwischenablage sowie den Titel des aktiven Fensters und Tastenanschläge in der Datei %appdata%\Microsoft\Vault\lg.dat. Die Daten in der Datei werden mit einer Single-Byte-XOR-Verschlüsselung unter Verwendung des Schlüssels 0x44 verschlüsselt.

C&C-Kommunikation

Die Backdoor unterstützt drei Protokolle für die Kommunikation mit dem C&C – TCP, UDP und WebSocket – und kann sowohl als Client als auch als Server fungieren. Die netzwerkbezogenen Funktionen basieren weitgehend auf dem HP-Socket-Netzwerk-Framework, und einige kryptografische Funktionen wurden unter Verwendung der Crypto++-Bibliothek implementiert.

Die C&C-Konfiguration ist in die Backdoor eingebettet und kann Folgendes enthalten:

• bis zu drei IP-Adressen und zugehörige Ports, wobei jede eine C&C-IP-Adresse und deren Port für einen der Kommunikationskanäle (TCP, UDP oder WebSocket) angibt, sowie
• bis zu drei Portnummern, die jeweils einen Port angeben, auf dem die Backdoor auf neue Verbindungen warten soll. Eine wird für einen TCP-Server, eine für einen UDP-Server und eine für einen WebSocket-Server verwendet.

Ein Beispiel für eine Konfiguration aus der WIN_PLUS-Version ist in Abbildung 9 dargestellt und enthält:

• Die C&C-Adresse und den Port für den TCP-Kommunikationskanal: 207.148.78[.]36:443.
• Die C&C-Adresse und den Port für den UDP-Kommunikationskanal: 207.148.78[.]36:53.
• Die C&C-Adresse und den Port für den WebSocket-Kommunikationskanal: 207.148.78[.]36:80.
• Der Listening-Port des TCP-Servers der Backdoor: 53781.

Bevor Verbindungen hergestellt oder ein Server gestartet wird, verbirgt die SprySOCKS WIN_DRV-Version alle Verbindungen von/zu den Adressen oder Ports aus der Konfiguration, indem sie die IOCTLs 0x220340 und 0x220200 des RawWNPF-Treibers aufruft. Infolgedessen werden diese Verbindungen nicht in der Ausgabe von Tools wie netstat.exe aufgeführt, obwohl sie aktiv sind. Darüber hinaus führen beide Backdoor-Versionen das Dienstprogramm netsh.exe zweimal aus:

netsh.exe netsh advfirewall firewall delete rule name="Core Networking - Packet Too Big(ICMPv6 - In)"

netsh advfirewall firewall add rule name="Core Networking - Packet Too Big(ICMPv6 - In)" dir=in action=allow protocol=tcp localport=53781

Der erste Befehl löscht eine bestimmte Firewall-Regel, und der zweite fügt eine neue Firewall-Regel mit demselben Namen wie die gerade gelöschte hinzu, wodurch der gesamte eingehende TCP-Datenverkehr zugelassen wird, der an den in der Konfiguration angegebenen TCP-Serverport der Backdoor gesendet wird.

Ist die C&C-Konfiguration leer (wie bei der WIN_DRV-Version, die wir auf VirusTotal entdeckt haben), startet die Backdoor einen TCP-Server, der auf einem zufälligen Port des kompromittierten Rechners lauscht, und verbirgt diesen Port zudem durch Aufruf des IOCTL 0x220200 des RawWNPF-Treibers. Dieser Aufruf verhindert nicht nur, dass der TCP-Server in der Ausgabe von Standard-Netzwerktools aufgeführt wird, sondern aktiviert auch die vom RawWNPF-Treiber bereitgestellte TCP-Umleitungsfunktion. Diese Funktion ermöglicht es Angreifern, Befehle an die Backdoor zu senden, ohne den tatsächlichen Port zu kennen, auf dem die Backdoor lauscht, indem sie einfach speziell gestaltete TCP-Daten an einen beliebigen offenen TCP-Port auf dem Rechner des Opfers senden.

Was den TCP-Kommunikationskanal betrifft, scheint das C&C-Protokoll dasselbe zu sein wie in der Linux-Version, die im Bericht von Trend Micro analysiert wurde. Jedes Mal, bevor die eigentlichen Daten der Backdoor gesendet werden, sendet sie einen 12-Byte-Header, der den 32-Bit-CRC des restlichen Headers, einen DWORD-Magic-Wert 0xACACBCBC und einen DWORD enthält, der die Größe der auf den Header folgenden Daten angibt.

Für die UDP- und WebSocket-Kanäle sind die Magic-Werte unterschiedlich, ebenso wie das Format und die Größe des Nachrichtenheaders. Für den UDP-Kanal lautet der Magic-Wert 0xACACBFBC und befindet sich an der Offset-Adresse 0x1C in einem 36-Byte-Header, gefolgt von einem DWORD, das die Größe der nachfolgenden Daten angibt. Im WebSocket-Kanal wird der Magic-Wert 0x1BDCCBAA als Masking-Key im WebSocket-Header verwendet. Abbildung 12 zeigt eine Erfassung des Netzwerkverkehrs mit den Magic-Werten für jeden der Kommunikationskanäle.

Auf den Header folgt wiederum ein 32-Bit-CRC, dann der WORD-Wert 0x0003 (der wahrscheinlich die Verschlüsselungsmethode angibt), gefolgt von 128-Bit-Daten, die im AES-ECB-Modus verschlüsselt (unter Verwendung des fest codierten Schlüssels QFTHEYjzX3RBOMgZ) und Base64-kodiert wurden.

Ein Beispiel für eine C&C-Nachricht vor und nach der Dekodierung und Entschlüsselung ist in Abbildung 13 dargestellt.

Der Wert __msgid in der entschlüsselten C&C-Nachricht dient zur Angabe eines Befehls, der durch eine Nachrichten-ID identifiziert wird und von der Backdoor ausgeführt werden soll. Die Liste der von der Backdoor unterstützten Nachrichten-IDs sowie deren Beschreibung finden Sie in Tabelle 3. Beachten Sie, dass wir nicht alle diese Befehle eingehend analysiert haben; daher sind einige Beschreibungen nur eine grobe Übersicht über den Teil des Codes/der Funktionalität, auf den sich die Nachrichten-ID bezieht.

Tabelle 3. SprySOCKS-C&C-Befehle; mit * gekennzeichnete Beschreibungen sind vorläufige Einschätzungen

Netzwerkinfrastruktur

In dieser Kampagne wurde nur eine C&C-Adresse entdeckt: 207.148.78[.]36, die in der Konfiguration (siehe Abbildung 9) der WIN_PLUS-Variante der SprySOCKS-Backdoor fest codiert ist.

Ports aus der Konfiguration, die von der Backdoor zur Kommunikation mit dem C&C verwendet werden sollten:

• TCP: 443
• UDP: 53
• WebSocket: 80

Wie im Bericht von Trend Micro erwähnt, wurde die IP-Adresse 207.148.75[.]122, die zum gleichen IP-Bereich 207.148.64.0/20 wie der oben genannte C&C gehört, wurde im Juni 2023 von den FishMonger-Betreibern als SprySOCKS-Verteilungsserver genutzt. Dieser IP-Bereich gehört dem Cloud-Hosting-Anbieter Vultr.

Fazit

Die Entdeckung einer Windows-Variante von SprySOCKS, das bisher als reine Linux-Backdoor bekannt war, stellt eine bedeutende Erweiterung der plattformübergreifenden Fähigkeiten von FishMonger dar. Unsere Analyse zeigt, dass die Windows-Portierung den Großteil der Kernarchitektur ihres Linux-Vorgängers beibehält – einschließlich des C&C-Protokolls, der verwendeten Verschlüsselung und der allgemeinen Befehlsverarbeitungslogik –, während sie bei Bedarf Windows-native Mechanismen einsetzt und die Tarnung der Backdoor durch den Einsatz von Kernel-Treibern verbessert. Angesichts der begrenzten Hinweise auf eine mögliche Beteiligung eines UEFI-Bootkits raten wir allen, die Aktivitäten der Gruppe genau im Auge zu behalten.

Bei Fragen zu unseren auf WeLiveSecurity veröffentlichten Forschungsergebnissen kontaktieren Sie uns bitte unter threatintel@eset.com.

ESET Research bietet private APT-Intelligence-Berichte und Datenfeeds an. Bei Fragen zu diesem Service besuchen Sie bitte die ESET Threat Intelligence -Seite.

IoCs

Dateien

Netzwerk

MITRE ATT&CK-Techniken

Diese Tabelle wurde unter Verwendung der Version 19 des MITRE ATT&CK-Frameworks erstellt.