Operation XENOFISCAL: SideCopy setzt persistentes XenoRAT ein, das auf das afghanische Finanzministerium abzielt.

Autoren: Dixit Panchal & Vaibhav Krushna Billade

Table of Contents:

• Einführung:
• Hauptziele:
• Infektionskette:
• Erste Erkenntnisse zur Kampagne:
• Analyse des Lockvogels:
• Technische Analyse:
  • Phase 1: Analyse der LNK-Datei.
  • Phase 2: Analyse der HTA/JavaScript-Nutzdaten
  • Phase 3: Analyse der Stage-1-Loader-DLL
  • Phase 4: Analyse der Stage-2-Loader-DLL und des Shellcodes
  • Phase 5: Analyse von XenoRAT.
• Infrastrukturelle Artefakte & Zuordnung von Bedrohungsakteuren.
• Fazit: Operation XENOFISCAL?
• Seqrite Reichweite:
• IOCs:
• MITRE ATT&CK:

Einführung:

Seqrite Labs überwacht aktiv Spear-Phishing-Kampagnen weltweit und verfolgt seit Langem den SideCopy-APT-Cluster – eine mit Pakistan verbundene Bedrohungsgruppe, die unter dem Dach von Transparent Tribe/APT36 agiert. Im Zuge dieser Überwachung identifizierten wir eine gezielte Kampagne gegen das afghanische Finanzministerium, deren Taktiken, Techniken und Verfahren (TTPs) mit mittlerer bis hoher Wahrscheinlichkeit mit denen von SideCopy übereinstimmen.

Die Kampagne beginnt mit einer Spear-Phishing-Attacke – der Zustellung eines ZIP-Archivs, das eine bösartige LNK-Datei mit einem sorgfältig gewählten Dateinamen in Paschtu enthält:

د_هغو_کارکوونکو_لېست_چې_د_فکري_او_رواني_جګړې_سیمینار_ته_ورپېژندل_شوي_وو12.pdf.lnk („Liste der Mitarbeiter, denen vorgestellt wurde das Seminar „Intellektuelle und psychologische Kriegsführung“)

Die Wahl von Paschtu ist bewusst getroffen. Es ist die vorherrschende Sprache in den afghanischen Regierungsinstitutionen und die Hauptsprache der anvisierten Zielgruppe – Provinzfinanzbeamte, die in allen 34 afghanischen Mustoufiats tätig sind. Indem der Akteur den Köder mit einem Seminar über psychologische und intellektuelle Kriegsführung verband, demonstrierte er präzise Kenntnisse des operativen und administrativen Kontextes seiner Ziele.

Im Folgenden wird eine vollständige technische Analyse der Kampagne vorgestellt – von der LNK-Ausführungskette über das XenoRAT-Implantat-Beaconing bis hin zur kugelsicheren europäischen Infrastruktur – sowie Infrastruktur-Pivots, die Analyse von Köderdokumenten und die Zuordnung der Zuordnung anhand der bekannten SideCopy-TTP-Basislinie.

Hauptziele:

• Finanzministerium des Islamischen Emirats Afghanistan.
• Provinzielle Steuer- und Finanzdirektionen (Mustoufiats).
• Paschtusprachige Regierungsbeamte.
• Mitarbeiter der Provinzregierungen, nicht des Zentralministeriums

Infektionskette:

Erste Erkenntnisse zur Kampagne:

Im Rahmen unserer Analyse stellten wir fest, dass der Angreifer den Angriff über ein ZIP-Archiv einleitete, das mittels Spear-Phishing verbreitet wurde und eine bösartige LNK-Datei in Paschtu enthielt – eine bewusste Entscheidung, die eine tiefe Vertrautheit mit der Zielumgebung widerspiegelt.

Nach der Ausführung nutzt der LNK im Hintergrund mshta.exe, um eine HTA-Payload von einer kompromittierten afghanischen Bildungsdomäne abzurufen. Diese entschlüsselt verschleiertes JavaScript im Arbeitsspeicher, etabliert eine Registry-basierte Persistenz, die als Microsoft Edge-Eintrag getarnt ist, und setzt schließlich XenoRAT 1.8.7 ein. Dabei werden ausgehende Signale an eine ausfallsichere europäische Hosting-Infrastruktur gesendet, die vollständig von der Auslieferungsschicht getrennt ist, um langfristige Ausfallsicherheit zu gewährleisten.

Analyse des Lockvogels:

Bei dem während der Hinrichtung fallengelassenen Dokument handelt es sich um ein Provinzmitarbeiterverzeichnis des afghanischen Finanzministeriums, das alle 34 Provinzen umfasst und in dem Finanzdirektoren, Leiter der Steuerbehörden, Finanzbeamte und Sekretäre zusammen mit ihren direkten Mobiltelefonnummern aufgeführt sind – vollständig in Dari und Paschtu verfasst.

Der Detaillierungsgrad der Organisation deutet auf vorherige Informationsbeschaffung durch den Angreifer hin. Seine Rolle bei dem Angriff ist simpel: Während das Opfer ein scheinbar routinemäßiges internes Regierungsdokument liest, hat die Schadsoftware ihre Installation im Hintergrund bereits unbemerkt abgeschlossen.

Technische Analyse:

Phase 1: Analyse der LNK-Datei.

Die LNK-Datei dient als erster Infektionsvektor und Auslöser der Angriffskette. Obwohl sie mit einem PDF-Symbol und einem irreführenden Dateinamen als legitimes Dokument getarnt ist, zeigt die Überprüfung ihrer Verknüpfungseigenschaften, dass sie das Windows-Dienstprogramm mshta.exe aus C:\Windows\System32 startet. Der in der Verknüpfung eingebettete Befehl verweist auf eine entfernte, bösartige PHP-Ressource, die über HTTPS gehostet wird. (hxxp[:]//abimj.edu.af>/index.php), Dies ermöglicht es dem Angreifer, extern gehostete Skriptinhalte direkt im Speicher auszuführen, ohne eine ausführbare Datei auf der Festplatte abzulegen. Dies geschieht durch Missbrauch von mshta.exe – einer legitimen Microsoft-Binärdatei, die üblicherweise mit der Ausführung von HTML-Anwendungen (HTA) in Verbindung gebracht wird.

Der Angreifer nutzt eine Living-off-the-Land-Binary-Technik (LOLBIN), um herkömmliche Erkennungsmechanismen zu umgehen und das Misstrauen der Nutzer zu unterlaufen. Die übermäßige Verwendung von Kommas zur Verschleierung der URL-Struktur deutet zudem auf den Versuch hin, statische Analysen und signaturbasierte Erkennung zu behindern.

Phase 2: Analyse der HTA/JavaScript-Nutzdaten

Die über mshta.exe abgerufene PHP-Payload enthält stark verschleierten JavaScript-Code, der im Kontext der HTA-Engine Schadcode ausführt. Eine erste Analyse zeigt das Vorhandensein kodierter String-Arrays wie _$_f1bf=[“\x55\x33\x6…”], eine gängige Verschleierungsmethode, um Funktionsnamen, URLs, Befehle oder sekundäre Payloads vor Analysten und Sicherheitstools zu verbergen. Das Skript definiert außerdem irreführende Fenstertexte wie „Windows-Dateifehler“, um legitimes Systemverhalten zu imitieren und das Opfer während der Ausführung abzulenken. Diese Phase dient als primäre Ausführungs- und Übermittlungsebene der Kampagne. Hier wird der verschleierte JavaScript-Code wahrscheinlich dynamisch dekodiert, um Folgeaktionen wie das Abrufen der Payload, die Befehlsausführung, die Einrichtung einer dauerhaften Verbindung oder die Datenexfiltration durchzuführen.

Analyse eines verschleierten JScript

Die Analyse ergab, dass es sich bei der .js-Datei um einen stark verschleierten, JScript-basierten Malware-Loader handelt, der unter Windows Script Host (WSH) oder älteren Internet Explorer-Umgebungen mit aktivierter ActiveX-Unterstützung ausgeführt werden soll. Das Skript verwendet mehrere schädliche Techniken, darunter ActiveX-basierte Ausführung, benutzerdefinierte Base64-Payload-Dekodierung und .NET-Code. Binärformatierer Deserialisierung und Ausführung der Nutzdaten im Arbeitsspeicher.

Die erste Phase der Malware beginnt mit einem großen, verschleierten JavaScript-Array, typischerweise definiert als Variable wie beispielsweise _$_f1bf. Dieses Array enthält zahlreiche hexadezimal kodierte Stringfragmente, die eine eingebettete Payload darstellen. Diese Fragmente werden später verkettet und an eine benutzerdefinierte Dekodierungsfunktion übergeben. Anstatt auf native Base64-Dekodierungs-APIs zurückzugreifen, implementiert das Skript eine eigene Base64-Dekodierungsroutine, um die Payload zu verschleiern und die Analyse zu erschweren.

Die benutzerdefinierte Funktion rekonstruiert dynamisch den Standard-Base64-Zeichensatz (A–Z, a–z, 0–9, +, /) mithilfe von `String.fromCharCode` und verarbeitet anschließend die kodierten Daten in Blöcken, wobei der ursprüngliche Byte-Stream durch eine Reihe bitweiser Operationen wiederhergestellt wird. Durch die manuelle Durchführung des Dekodierungsprozesses umgeht die Malware verdächtige Indikatoren wie `atob()` oder gängige Dekodierungsbibliotheken, was die statische Erkennung und signaturbasierte Analyse erheblich erschwert.

Rekonstruktion der Nutzlast mithilfe von .NET COM-Objekten

In der zweiten Phase wandelt die Malware die dekodierte Nutzlast mithilfe mehrerer, über ActiveXObject instanziierter .NET-Klassen in ein ausführbares Objekt im Arbeitsspeicher um. Das Skript erstellt System.Text.ASCIIEncoding um die dekodierte Zeichenkette in ein Byte-Array umzuwandeln, verwendet man dann System.Security.Cryptography.FromBase64Transform Um eine zusätzliche Base64-Transformation der Nutzdaten durchzuführen, wird der resultierende Byte-Stream in ein System.IO.MemoryStream-Objekt geschrieben. Dadurch wird die serialisierte Nutzlast vollständig im Arbeitsspeicher rekonstruiert, ohne auf die Festplatte zuzugreifen. Dieses gestaffelte Verfahren wird häufig bei dateiloser Malware eingesetzt, da Angreifer so schädliche .NET-Objekte für die Ausführung vorbereiten können, während gleichzeitig forensische Spuren minimiert und die Wahrscheinlichkeit der Erkennung durch herkömmliche dateibasierte Sicherheitsprodukte verringert wird.

Nach dem Dekodieren der eingebetteten Nutzdaten tritt das Skript in seine Ausführungsphase ein, indem es ein WScript.Shell ActiveX Objekt, das den Zugriff auf Registrierungsoperationen, Umgebungsvariablen und andere Systemfunktionen ermöglicht. Das Skript prüft dann, ob .NET Framework-Version v4.0.30319 wird durch Abfrage des Registrierungspfads installiert HKLM\SOFTWARE\Microsoft\.NETFramework\v4.0.30319Falls die neuere Laufzeitumgebung nicht verfügbar ist, wird auf .NET v2.0.50727 zurückgegriffen. Die Malware setzt anschließend die COMPLUS_Version Umgebungsvariable, um den Prozess zum Laden einer bestimmten CLR-Laufzeitversion zu zwingen und so die Kompatibilität mit der eingebetteten .NET DLL-Nutzlast sicherzustellen.

Während der Ausführung missbraucht die Malware vertrauenswürdige .NET-Deserialisierungskomponenten, darunter WPF-XAML-Gadgets wie ObjectDataProvider und ResourceDictionary sowie Windows Forms-Serialisierungsobjekte wie AxHost und PropertyBagBinary. Diese Komponenten tragen zur Aufrechterhaltung der Deserialisierungskette bei und lösen die Ausführung während der Objektrekonstruktion aus.

Schließlich wird das im MemoryStream-Objekt gespeicherte bösartige serialisierte Objekt verarbeitet durch .NET BinaryFormatter.Deserialize_2()Dadurch wird die unauffällige Ausführung von DLLs im Arbeitsspeicher ermöglicht, während gleichzeitig forensische Artefakte minimiert und herkömmliche dateibasierte Erkennungsmechanismen umgangen werden.

Phase 3: Analyse der Stage-1 Loader-DLL (Initial Loader)

Dies ist eine .NET Loader DLL, die für die Ausführung der Payload der nächsten Stufe, die Persistenz und das In-Memory-Staging der nächsten Komponenten der Angriffskette verantwortlich ist.

Zu Beginn der Datei öffnen() Funktion, die für das Herunterladen und Öffnen eines simulierten PDF-Dokuments von der URL zuständig ist hxxp[:]//abimj.edu.af/institute/cloudiyaf/document.pdf. Die Funktion extrahiert zunächst den Dateinamen aus der URL und speichert die heruntergeladene Datei mithilfe von `WebClient.DownloadFile()` im temporären Windows-Verzeichnis. Vor dem Download aktiviert die Malware explizit die TLS-1.2-Kommunikation über `ServicePointManager.SecurityProtocol`, um die Kompatibilität mit sicheren HTTPS/TLS-Verbindungen zu gewährleisten. Nach dem Herunterladen des Dokuments pausiert die Malware die Ausführung für fünf Sekunden und öffnet anschließend die heruntergeladene PDF-Datei über eine versteckte Befehlsausführungsroutine.

Die Funktion `RunProcessWithHiddenCmd()` dient zum Ausführen von Dateien oder Befehlen über `cmd.exe`. Sie erstellt ein Befehlszeilenargument mit dem Parameter `/c`, der `cmd.exe` anweist, die angegebene Datei auszuführen und sich anschließend zu beenden. Die Funktion initialisiert eine neue Prozessinstanz, weist `cmd.exe` als auszuführende Datei zu und übergibt die generierte Argumentzeichenfolge an den Prozess. Nach dem Start führt der Befehlsinterpreter die angegebene Datei oder den Befehl aus und beendet sich nach Abschluss automatisch.

Nach dem Öffnen des Köderdokuments erstellt die Malware unter C:\Users\Public\ ein Verzeichnis namens USOShared-1de48789-1285, um die nächste HTA-Payload (zuidrt.hta) zu speichern. Anschließend ruft sie die RegWorkExePathFromPublic() Funktion, die Base64-kodierte Registrierungsbefehle enthält, die zur Laufzeit mithilfe der BSDSD94() Base64-Dekodierungsroutine. Nach der Dekodierung erstellt der Befehl einen neuen Eintrag unter dem HKCU\Software\Microsoft\Windows\CurrentVersion\Run Registrierungsschlüssel mit dem Wertnamen Edgre. Der Registrierungseintrag wird ausgeführt:

cmd /C start C:\Users\Public\USOShared-1de48789-1285\zuidrt.hta

Um die Tarnung und Persistenz weiter zu gewährleisten, schreibt die Malware den dekodierten Befehl in eine Batch-Datei namens noway.bat im temporären Verzeichnis des Benutzers und führt diese über einen versteckten Prozess aus. Die Ausführung ist so konfiguriert, dass alle sichtbaren Fenster unterdrückt werden und dem Benutzer keine Eingabeaufforderung angezeigt wird. Dadurch wird sichergestellt, dass die HTA-Payload beim Anmelden des Benutzers automatisch gestartet wird und somit dauerhaft im System verbleibt.

Die Funktion CopyExeToUsersPublic() ist für das Abrufen und Rekonstruieren der HTA-Payload der nächsten Stufe (zuidrt.hta) im Verzeichnis C:\Users\Public\USOShared-1de48789-1285\ zuständig. Sie prüft zunächst, ob das Zielverzeichnis existiert, und erstellt es gegebenenfalls mit Directory.CreateDirectory(). Anschließend lädt sie die kodierte Payload von dort herunter.

hxxp[:]//abimj.edu.af/institute/cloudiya/

Die heruntergeladene Payload zuidrt.hta wird komprimiert und Base64-kodiert gespeichert, um einer Erkennung zu entgehen. Die Malware dekomprimiert und dekodiert die Daten später, um die endgültige HTA-Payload wiederherzustellen. Diese wird anschließend über RunProcessWithHiddenCmd() ausgeführt, welches intern Folgendes ausführt: cmd.exe /c start C:\Users\Public\USOShared-1de48789-1285\zuidrt.hta, wobei die Windows-Dateizuordnung genutzt wird, um weitere Aktionen aufzurufen mshta.exe für die HTA-Ausführung.

Ausführung der HTA-Nutzlast (zuidrt.hta)

Die Datei zuidrt.hta weist eine ähnliche Struktur wie die ursprüngliche HTA-Payload auf, enthält jedoch modifizierte eingebettete Komponenten und eine aktualisierte Ausführungslogik. Sie setzt die Angriffskette fort, indem sie Verschleierungs- und Dekodierungsroutinen wiederverwendet, um ihre Funktionalität zu verbergen und einer Analyse zu entgehen. Das Skript initialisiert ActiveX-basierte Ausführungspfade neu, um die Ausführung innerhalb der HTA-Umgebung aufrechtzuerhalten, und rekonstruiert die eingebettete serialisierte Payload im Speicher.

Ähnlich wie in der ersten HTA-Phase nutzt die Payload .NET-Deserialisierungskomponenten und Gadget-Chains, um die Ausführung der eingebetteten Stage-2-Loader-DLL im Arbeitsspeicher auszulösen. Diese Phase fungiert als sekundäre Ausführungsebene innerhalb der Infektionskette, gewährleistet die Persistenz des Angriffsablaufs und ermöglicht den Übergang zur DLL der nächsten Phase, die für die endgültige Auslieferung und Ausführung der Payload verantwortlich ist.

Phase 4: Analyse der Stage-2-Loader-DLL und des Shellcodes

Nach der Entschlüsselung zur Laufzeit wird der Ausführungsablauf an eine bösartige DLL weitergeleitet.

Die DLL ist ein .NET-basierter Shellcode-Loader, der für das Abrufen, Dekodieren, Dekomprimieren und Ausführen der nächsten Payload-Stufe vollständig im Arbeitsspeicher zuständig ist. Die Malware nutzt mehrere Ebenen der Vorbereitung und Laufzeitausführung, um herkömmliche Sicherheitsmechanismen zu umgehen und die Anzahl der auf der Festplatte gespeicherten Artefakte zu reduzieren.

Die DLL fungiert als Zwischenlader zwischen der JavaScript-basierten HTA-Phase und der endgültigen Xeno-RAT-Payload.

Umgebungseinrichtung und Nutzlastabruf

Bei der Ausführung initialisiert die DLL eine Staging-Umgebung, die dazu dient, die Nutzlast der nächsten Stufe zu speichern und zu verarbeiten und dabei möglichst wenig Verdacht zu erregen. Die Malware dekodiert zunächst eine Base64-kodierte Zeichenkette (ZmlyZWZ4LTFkZTg3ZWVjOC0xMjQx) unter Verwendung der benutzerdefinierten BSDSD94() Diese Routine führt zum Verzeichnisnamen firefx-1de87eec8-1241. Anschließend wird ein Arbeitsverzeichnis unter dem öffentlich zugänglichen Windows-Pfad erstellt:

• C:\Users\Public\firefx-1de87eec8-1241

Die Verwendung von C:\Users\Public\ ermöglicht es der Malware, schreibrechtliche Beschränkungen aufgrund von Benutzerrechten zu umgehen und sich gleichzeitig als legitimer Dateisystemzugriff zu tarnen. Die Namenskonvention des Verzeichnisses ähnelt anwendungsgenerierten Cache- oder Profilordnern, wodurch der Verdacht der Benutzer gemildert und gängige IOC-basierte Erkennungsmethoden umgangen werden. Die Malware definiert außerdem temporäre Payload-Dateinamen wie beispielsweise ayui.vmxx und ayhui.vmxx, die absichtlich durch nicht standardmäßige Erweiterungen verschleiert werden, um eine sofortige Identifizierung als ausführbarer Inhalt zu vermeiden.

Nach Einrichtung des Staging-Verzeichnisses initiiert die DLL die Kommunikation mit der vom Angreifer kontrollierten Infrastruktur, um die Payload für die nächste Phase abzurufen. Die Malware enthält mehrere fest codierte URLs, darunter:

• hxxps[:]//abimj[.]edu[.]af/institute/10/
• hxxps[:]//abimj[.]edu[.]af/institute/7/

und wählt den Download-Endpunkt dynamisch anhand der Betriebssystemversion des Opfers aus. Systeme, die als Windows 7 (Version 6.1) identifiziert werden, werden zu einem alternativen Speicherort für die Nutzdaten umgeleitet, was auf eine kompatibilitätsbewusste Nutzdatenübermittlung hinweist.

Verwendung von .NET WebClient.DownloadFile() Mithilfe dieser Methode und der explizit aktivierten TLS/TLS1.1/TLS1.2-Protokolle lädt die Malware die verschlüsselte Nutzlast herunter und speichert sie lokal als ayui.vmxxDer heruntergeladene Inhalt ist nicht direkt ausführbar; stattdessen dient er als kodierter und komprimierter Zwischenspeicher, der einer weiteren Base64-Dekodierung und GZIP-Dekomprimierung unterzogen wird, bevor die Shellcode-Ausführung im Speicher initiiert wird.

Payload-Dekodierung und Shellcode-Rekonstruktion

Nach erfolgreichem Herunterladen der zweiten Payload-Stufe speichert die DLL die abgerufenen Daten im Staging-Verzeichnis als getarnte Datei namens ayui.vmxx. Anstatt eine portable ausführbare Datei (PE) direkt auf der Festplatte zu speichern, verwendet die Malware mehrschichtige Kodierungs- und Komprimierungsmechanismen, um den eigentlichen Payload-Inhalt zu verbergen und statische Erkennungs-Engines zu umgehen. Die Datei enthält Base64-kodierte und GZIP-komprimierte Daten, die bei oberflächlicher Prüfung nicht ausführbar erscheinen. Diese Technik reduziert die Sichtbarkeit der Signaturen für Antivirenprodukte erheblich und erschwert die manuelle Analyse, da Analysten das Payload-Format nicht sofort erkennen können. Anschließend liest die Malware die gesamte Datei in den Arbeitsspeicher ein. File.ReadAllBytes() und beginnt während der Laufzeitausführung dynamisch mit der Rekonstruktion der eingebetteten Nutzdaten.

Der Rekonstruktionsprozess wird über die kundenspezifische Abwicklung abgewickelt. decompressdata() Die Funktion führt mehrere Dekodierungs- und Dekomprimierungsvorgänge vollständig im Speicher aus. Die Routine dekodiert zunächst den Base64-Blob, extrahiert den Header mit der dekomprimierten Größe und verwendet anschließend die .NET GZipStream Eine Klasse dient dazu, den ursprünglichen Nutzdatenpuffer wiederherzustellen. Sobald die Dekomprimierung abgeschlossen ist, werden die resultierenden Daten erneut weitergeleitet. Convert.FromBase64String() um die Rohbytes des Shellcodes wiederherzustellen. Die vollständig rekonstruierte Nutzlast wird dann lokal geschrieben als ayhui.vmxxDiese Datei dient als Zwischenspeicher für den Shellcode vor der Ausführung. Durch die Kombination von gestaffelter Dekodierung, Komprimierung und dem Wiederaufbau der Nutzlast zur Laufzeit vermeidet die Malware, den endgültigen Shellcode im Klartext auf der Festplatte zu speichern. Dadurch werden herkömmliche Dateiscan- und inhaltsbasierte Erkennungsmechanismen umgangen, während die Nutzlast für die reflexive Ausführung im Arbeitsspeicher vorbereitet wird.

Shellcode-Ausführung:

Nach der Rekonstruktion der Payload geht die DLL in die finale Ausführungsphase über, indem sie als Shellcode-Loader im Arbeitsspeicher fungiert. Anstatt eine herkömmliche ausführbare Datei von der Festplatte zu starten, reserviert die Malware mithilfe der Windows-API direkt ausführbaren Speicher innerhalb des aktuellen Prozesses. VirtualAlloc(). Die Zuordnungsanforderung verwendet das MEM_COMMIT-Flag zusammen mit PAGE_EXECUTE_READWRITE (RWX) Speicherberechtigungen werden so gesetzt, dass ein Speicherbereich entsteht, der beliebigen Code speichern und ausführen kann. Dieses RWX-Zuweisungsmuster ist ein bekanntes Indiz für die Ausführung von Shellcode und das Laden reflektierender Malware. Nach der Speicherzuweisung kopiert die Malware den rekonstruierten Shellcode-Puffer mithilfe von Marshal.Copy()Dadurch wird die Nutzlast vollständig im Prozessspeicher bereitgestellt, ohne auf den Windows PE-Loader angewiesen zu sein.

Sobald der Shellcode in den ausführbaren Speicher eingebunden ist, überträgt die Malware die Ausführung über den eingeschleusten Puffer. CreateThread() Die API verwendet die Basisadresse des zugewiesenen Speichers als Thread-Einstiegspunkt. Diese Technik ermöglicht die direkte Ausführung des Shellcodes aus dem Speicher, umgeht die herkömmliche, festplattenbasierte Ausführungsüberwachung und reduziert forensische Artefakte erheblich. Die DLL ruft dann Folgendes auf: WaitForSingleObject() Mit einem unbegrenzten Timeout-Wert wird die Thread-Synchronisierung aufrechterhalten und eine unterbrechungsfreie Shellcode-Ausführung gewährleistet. Diese Ausführungsmethode entspricht modernen Techniken dateiloser Malware, bei denen die Payloads entschlüsselt und dynamisch im Speicher ausgeführt werden, um signaturbasierte Antivirenprogramme, Anwendungskontrollmechanismen und statische Scantechnologien zu umgehen. Der Shellcode dient anschließend als Loader für die finale Xeno-RAT-Payload und ermöglicht so Persistenz, Command-and-Control-Kommunikation und Fernzugriff für Angreifer auf das kompromittierte System.

Der Shellcode fungiert als In-Memory-Loader, der für die Vorbereitung und den Start der endgültigen Xeno-RAT-Payload zuständig ist.

Während der Ausführung führt es üblicherweise Umgebungsvalidierungen, dynamische API-Auflösung und Änderungen der Speicherberechtigungen mithilfe von APIs wie beispielsweise VirtualProtect() und GetProcAddress()Bei Donut-Loadern umgeht der Shellcode Sicherheitsmechanismen, indem er Funktionen wie beispielsweise … patcht. AmsiScanBuffer() AMSI-Scanning deaktivieren und die Sichtbarkeit dynamisch geladener Inhalte reduzieren.

Da es sich bei der endgültigen Nutzlast um eine verwaltete .NET-Assembly handelt, initialisiert der Shellcode die .NET Common Language Runtime (CLR) durch Laden von Komponenten wie clr.dll und mscoree.dll. Die eingebettete Nutzlast wird anschließend entschlüsselt und mithilfe von Reflektionstechniken direkt aus dem Speicher geladen. Assembly.Load(byte[])Dadurch wird eine Installation auf Festplatte vollständig vermieden. Nach dem Laden wird die Xeno-RAT-Payload im Arbeitsspeicher ausgeführt und ermöglicht so die Befehls- und Kontrollkommunikation, die Persistenz und den Fernzugriff des Angreifers auf das kompromittierte System.

Phase 5: Analyse von XenoRAT.

Die letzte in der Infektionskette identifizierte Nutzlast ist Xeno RAT, ein Open-Source-Remote-Access-Trojaner (RAT), der öffentlich auf GitHub verfügbar ist und häufig von Bedrohungsakteuren für dauerhaften Fernzugriff, Überwachung und Post-Exploitation-Aktivitäten eingesetzt wird.

Bei der Ausführung initialisiert es einen sicheren Befehls- und Kontrollkanal (C2) unter Verwendung eines fest codierte IP-Adresse (185.235.137.106) und Portkonfiguration, die eine direkte Verbindung zur vom Angreifer kontrollierten Infrastruktur ermöglicht. Um die Ausführung in einer einzigen Instanz zu gewährleisten und Mehrfachstarts zu verhindern, verwendet die Malware außerdem mutex („clouda“)Dadurch wird sichergestellt, dass jeweils nur eine Client-Instanz auf dem infizierten System ausgeführt wird. Im Anschluss an diese Initialisierungsschritte greifen Persistenz- und kontinuierliche Wiederverbindungslogiken, um den langfristigen Zugriff auf den kompromittierten Host aufrechtzuerhalten.

Nun werden wir uns einige interessante Funktionen ansehen und ihre Funktionsweise analysieren.

ConnectAndSetupAsync Diese Funktion ist für den Aufbau und die Initialisierung einer TCP-basierten Command-and-Control-Verbindung (C2) zwischen Client und Remote-Server zuständig. Sie erstellt eine neue Node-Instanz mithilfe eines SocketHandlers, der mit dem angegebenen Socket und Verschlüsselungsschlüssel konfiguriert ist, und ermöglicht so die verschlüsselte Kommunikation über die Verbindung. Nach der Initialisierung führt die Funktion einen asynchronen Authentifizierungs-Handshake mit AuthenticateAsync durch, um die Verbindung anhand der angegebenen Typ- und ID-Werte zu validieren. Schlägt die Authentifizierung fehl oder tritt während des Aufbaus eine Ausnahme auf, gibt die Funktion null zurück, was darauf hinweist, dass der C2-Kommunikationskanal nicht erfolgreich hergestellt werden konnte. Andernfalls gibt sie ein vollständig initialisiertes und authentifiziertes Node-Objekt zurück, das für den sicheren Datenaustausch bereit ist.

DllNodeHandler Die Funktion verwaltet das dynamische Laden und Ausführen externer DLL-Module, die über eine Remote-Node-Verbindung empfangen werden. Sie empfängt zunächst den DLL-Namen vom verbundenen Client und prüft, ob die Assembly bereits im Speicher geladen ist. Falls die DLL fehlt, fordert sie die Binärdaten vom Remote-Server an und lädt diese dynamisch. Assembly.LoadDie DLL wird zur Wiederverwendung im Assemblies-Dictionary gespeichert; andernfalls wird dem Client mitgeteilt, dass die DLL bereits existiert. Nach dem Laden erstellt die Funktion mithilfe von Reflektion eine Instanz der angegebenen Klasse aus der Assembly und ruft deren öffentliche Run-Methode asynchron auf, wobei die aktive Node-Verbindung als Argument übergeben wird.

SendAsync Die Methode sendet Daten asynchron über den Socket-Handler und überprüft, ob die Übertragung erfolgreich war. Schlägt der Sendevorgang fehl, wird die Verbindung zum Knoten getrennt. Ebenso verhält es sich mit der Methode. ReceiveAsync Die Methode ruft verschlüsselte und formatierte Daten vom zugrunde liegenden Socket-Handler ab und gibt den verarbeiteten Byte-Stream an den Aufrufer zurück. Schlägt die Operation fehl oder gibt sie null zurück, wird die Verbindung automatisch getrennt, um einen gültigen Verbindungsstatus zu gewährleisten. Zusammen ermöglichen diese Methoden eine zuverlässige TCP-basierte C2-Kommunikation mit integriertem Verbindungsmanagement und automatischer Bereinigung bei Übertragungsfehlern.

Darüber hinaus werden die Nutzdaten vor der Übertragung mit den nativen RTL-Komprimierungs-APIs von Windows (RtlCompressBuffer) komprimiert und beim Empfang mit RtlDecompressBuffer auf Basis des Headers in Originalgröße dekomprimiert. Dies verbessert die Übertragungseffizienz bei gleichzeitiger Wahrung der Datenintegrität. Die Datensicherheit wird durch AES-Verschlüsselung gewährleistet, wobei die Rohdaten mit einem gemeinsamen Schlüssel und einem festen Initialisierungsvektor (IV) über CryptoStream verschlüsselt werden, um eine sichere Kommunikation während der Übertragung sicherzustellen.

Zusätzliche Methoden innerhalb der Klasse verwalten andere Netzwerkoperationen, darunter das Trennen von Socket-Verbindungen (Disconnect), das Herstellen sekundärer Unterverbindungen (ConnectSubSockAsync), das Überprüfen des aktiven Verbindungsstatus (Connected) und das Verwalten von Beziehungen zwischen untergeordneten Knoten (AddSubNode).

AddToStartupAdmin Die Funktion erstellt eine geplante Windows-Aufgabe mit dem Namen "XenoUpdateManager" Das Skript führt die angegebene ausführbare Datei automatisch aus, sobald sich ein Benutzer mit Administratorrechten am System anmeldet. Es erstellt eine XML-Aufgabendefinition, speichert diese in einer temporären Datei und registriert die Aufgabe mithilfe von schtasks.exe in der Windows-Aufgabenplanung. Nach der Ausführung prüft es die Ausgabe, um festzustellen, ob die Aufgabe erfolgreich erstellt wurde, und gibt das Ergebnis zurück.

 

AddToStartupNonAdmin Die Funktion fügt die ausführbare Datei dem Windows-Startverzeichnis des aktuellen Benutzers hinzu, indem sie in den entsprechenden Eintrag geschrieben wird. HKCU\Software\Microsoft\Windows\CurrentVersion\Run Der Vorgang wird über einen Registrierungsschlüssel abgewickelt, sodass er beim Anmelden ohne Administratorrechte automatisch ausgeführt wird und zurückgibt, ob die Operation erfolgreich war.

GetAntivirus Die Funktion ruft mithilfe der Windows-Verwaltungsinstrumentation (WMI) Antivireninformationen vom System ab, indem sie die Klasse „AntivirusProduct“ unter „root\SecurityCenter2“ abfragt. Sie sammelt die von dieser Abfrage zurückgegebenen „displayName“-Werte, die die installierten Antivirenprodukte repräsentieren, die zur Systemidentifizierung verwendet werden.

Systemstart entfernen Diese Funktion entfernt eine Anwendung aus dem Windows-Autostart, indem sie alle entsprechenden Einträge sowohl aus der Aufgabenplanung (mittels schtasks.exe) als auch aus dem Registrierungsschlüssel HKCU\Software\Microsoft\Windows\CurrentVersion\Run löscht. Zuerst prüft sie, ob Administratorrechte zum Entfernen geplanter Aufgaben vorliegen, scannt dann alle Aufgaben, die auf den angegebenen Ausführungspfad verweisen, und löscht diese. Abschließend entfernt sie den entsprechenden Registrierungseintrag für den aktuellen Benutzer.

Deinstallieren Die Funktion entfernt die Persistenzmechanismen der Anwendung und beendet das Programm anschließend selbst. Zuvor ruft sie RemoveStartup auf, um alle mit der aktuellen ausführbaren Datei verknüpften Starteinträge (geplante Aufgaben oder Registrierungseinträge) zu löschen.

Es startet einen versteckten cmd.exe-Prozess mit einem Base64-dekodierten Befehl (/C choice /CY /N /DY /T 3 & Del), der einige Sekunden wartet und anschließend die laufende ausführbare Datei von der Festplatte löscht. Abschließend beendet die Funktion den aktuellen Prozess zwangsweise, sodass die Anwendung nach der Bereinigung sofort beendet wird.

Xeno-RAT-FÄHIGKEITEN

Xeno RAT liefert wichtige Einblicke in sein Betriebsverhalten und seine Fähigkeiten nach der erfolgreichen Ausnutzung von Sicherheitslücken. Basierend auf dem analysierten Code, den beobachteten Aktivitäten und den im Open-Source-Projekt auf GitHub verfügbaren Funktionen weist die Malware eine Vielzahl von Merkmalen auf, die typischerweise mit fortgeschrittenen Remote-Access-Trojanern (RATs) in Verbindung gebracht werden.

• Überwacht die Aktivitäten des Opfers und sammelt Informationen zur Aufklärung des Wirts.
• Stellt eine verschlüsselte TCP-basierte Befehls- und Kontrollkommunikation (C2) her.
• Unterstützt SOCKS5-Proxy-basiertes Netzwerk-Tunneling.
• Lädt externe Assemblies dynamisch in den Speicher mittels Assembly.Load.
• Führt beliebige, vom Angreifer ausgegebene Befehle aus der Ferne aus.
• Bietet Funktionen zur Dateiverwaltung, einschließlich Hochladen, Herunterladen und Löschen.
• Führt Tastaturaufzeichnungen, Bildschirmaufnahmen, Zwischenablageüberwachung und Webcam-/Mikrofonüberwachung durch.
• Sendet regelmäßig Status- und Heartbeat-Updates an den C2-Server.
• Nutzt verschlüsselten und komprimierten Netzwerkverkehr, um die Analyse zu erschweren.
• Gewährleistet die Persistenz mithilfe von geplanten Aufgaben und Registry-Ausführungsschlüsseln.
• Kann sich selbst zu den Windows-Startverzeichnissen hinzufügen oder daraus entfernen.
• Arbeitet verdeckt, um langfristigen unbefugten Zugriff zu gewährleisten.
• Beinhaltet eine Selbstdeinstallations- und Selbstlöschfunktion zur Bereinigung nach der Ausführung.

Infrastrukturelle Artefakte & Zuordnung von Bedrohungsakteuren:

Basierend auf unserer Analyse und der Tracking-Historie dieser Kette und der TPPs mit all diesen Beweisen haben wir diese Kampagne dem Cluster SideCopy mit einem mittleren bis hohen Konfidenzniveau zugeordnet, wie bereits erwähnt. Bei der Infrastrukturanalyse wurde die Zustellungsdomäne abimj[.]edu[.]af zu zwei IP-Adressen aufgelöst – 103.132.98.224 und 103.132.98.226 – die sich beide innerhalb des Blocks 103.132.98.0/23 befinden, der AS58469, dem afghanischen Ministerium für Kommunikation und Informationstechnologie, zugeordnet ist.

Passives DNS-Pivoting über diesen IP-Block hinweg enthüllte über 200 legitime afghanische Regierungs- und Bildungsdomains, die auf derselben Infrastruktur gehostet werden. Dies bestätigt, dass der Bedrohungsakteur seine Auslieferungsschicht absichtlich innerhalb der souveränen Internetinfrastruktur Afghanistans eingerichtet hat – ein kalkulierter Schritt, um bösartigen Datenverkehr mit legitimer Regierungskommunikation zu vermischen und eine Erkennung auf Netzwerkebene zu umgehen.

Eine weitere Untersuchung des RAT-C2-Servers 185.235.137.106 ergab, dass es sich um einen Windows-Host handelte, der HTTP, HTTPS und einen nicht standardmäßigen RDP-Port nutzte – was mit einem vom Betreiber verwalteten dedizierten C2-Server übereinstimmt.

Der Server wird bei AS59711 (HZ Hosting Ltd) gehostet, einem in Bulgarien registrierten Anbieter mit physischer Präsenz in Frankfurt, der bereits zuvor in SideCopy-Infrastrukturberichten dokumentiert wurde. Seqrite.

Zum Zeitpunkt der Analyse wurden drei Domain-Cluster auf diese IP-Adresse aufgelöst, darunter vom Akteur registrierte Wegwerf-Domains in den Top-Level-Domains .xyz, .live und .online sowie eine vollständig konfigurierte Mail-Infrastruktur-Domain – was darauf hindeutet, dass derselbe Server gleichzeitig sowohl RAT-Kommunikation als auch Phishing-Zustellungsoperationen bediente.

Die Angriffskette – LNK führt mshta.exe aus, um über einen index.php-Endpunkt eine entfernte HTA abzurufen – ist eine charakteristische SideCopy-TTP, die seit 2019 konsistent dokumentiert ist und weiterhin zu den zuverlässigsten Identifikatoren der Gruppe zählt. Die Verwendung von XenoRAT untermauert diese Zuordnung zusätzlich. Seqrite Labs bestätigte im Dezember 2024, dass SideCopy angepasste XenoRAT-Varianten offiziell in sein aktualisiertes Toolset aufgenommen hat, analog zur vorherigen Verwendung von Open-Source-RATs wie AsyncRAT. Die Registry-basierte Persistenz über einen Run-Schlüssel mit einem Prozessnamen, der den Namen einer legitimen Windows-Anwendung kopiert, entspricht dem dokumentierten Verhalten von SideCopy nach der Ausnutzung einer Sicherheitslücke.

Auf Infrastrukturebene wurde die Auslieferungsdomain über AFGNIC registriert und im selben IP-Block wie die legitime Infrastruktur der afghanischen Regierung eingerichtet – eine bewusste Verschleierungsmethode, die dem dokumentierten Vorgehen von SideCopy entspricht. Der RAT-C2-Server auf HZ Hosting (AS59711) bestätigt dies zusätzlich, da derselbe Anbieter bereits in früheren, von SideCopy überwachten Infrastrukturclustern aufgetaucht ist. SeqriteBesonders auffällig ist die Namenskonsistenz zwischen dem Auslieferungspfad (cloudiyaf) und dem fest codierten Startnamen des RAT (clouda), die darauf hindeutet, dass ein einziger Betreiber beide Infrastrukturebenen verwaltet – wodurch die Auslieferungs- und die Post-Exploitations-Ebene mit demselben Akteur verknüpft werden.

Fazit: Warum die Operation XENOFISCAL?

Der Name leitet sich direkt von den beiden prägenden Merkmalen dieser Kampagne ab: XenoRAT, dem Open-Source-Fernzugriffstool, das als finale Payload eingesetzt wurde, und Fiscal, das die präzise Zielsetzung des Provinznetzwerks des afghanischen Finanzministeriums widerspiegelt. Zusammen bilden sie einen einzigen Codenamen, der sowohl die Waffe als auch das Opfer in einem Wort beschreibt. Die bewusste Entscheidung des Angreifers, einen Köder mit Finanzbezug gegen ein Finanzministerium einzusetzen, kombiniert mit einem Fernzugriffstool, das unbemerkt und langfristig überwachen kann, machte diese Kombination unausweichlich. XENOFISCAL ist nicht nur ein Name – es ist eine Zusammenfassung der gesamten Operation in acht Buchstaben.

Seqrite Reichweite:

• Link.Downloader.50744.GC
• Script.Netloader.50745.GC
• Trojan.LoaderCiR
• Trojan.YakbeexMSIL.ZZ4
• cld.script.trojan.1779477414

IOCs:

Dateiname	SHA256
PLZ	194B912C242604D6F9A79369F22338C58A13CE0CC2ED280CE505075808BC2F14
LNK	3B4194BDFE40D94031A94B30397FFD8A4B09D0A4057668E897B8BDCD1703DD01
Köder-PDF	DF9173A28C0B0B878C10A53D35CD7CE6F6ED66D207B6B7C4FF723721F1C027AB
ugayt.hta	A63E90EE57A1F213A8FE76EF1A6CFF5AE9ED7EBCEDA258431533825E648C0C67
noway.bat	5833917BD137804F5A021D2CB37ADFE5C4B7B67DBB06D59C3B9C5CF393835E45
zuidrt.hta	99127C8C67D90E2776BEEB85281F9C68399BF4567B07A6B638D68B760212E88D
WayBroad.dll	8F2D979EF33B2900351C94C7335275A9342C75189E1A901998E90A539E944A1A
Aotestpass.dll	0019212F25EB04BBB33BB194879C095265DB7855D6003BDD777CF0CBB90EB772
XenoRat	9AE3D785486022AF82EA92E51B26E3F55C1BBA88A7BE2AD9790F4240E8499D14

 

MITRE ATT&CK:

Taktik	Technikname	Technik-ID
Erster Zugriff	Spearphishing-Anhang	T1566.001
Ausführung	Trusted Developer Utilities Proxy Execution: mshta	T1218.005
	Befehls- und Skriptinterpreter: Windows-Befehlsshell	T1059.003
	Befehls- und Skriptinterpreter: JavaScript	T1059.007
	Gemeinsam genutzte Module	T1129
	Native API	T1106
Beharrlichkeit	Registrierungsschlüssel ausführen / Startordner	T1547.001
	Geplante Aufgabe	T1053.005
Privilegien Eskalation	Geplante Aufgabe
Verteidigungsflucht	Verschleierte Dateien oder Informationen	T1053.005
	Enthüllen/Dekodieren von Dateien oder Informationen	T1027
	Dateilose Speicherung / Ausführung	T1140
	Reflektierendes Laden von Code	T1027.011
	Living off the Land Binaries and Scripts (LOLBAS)	T1620
	Versteckte Dateien und Verzeichnisse	T1218
	Prozessinjektion / In-Memory-Ausführung	T1564.001
	AMSI-Umgehung	T1055
	Entfernung des Indikators auf dem Host: Dateilöschung	T1562.001
Bewertung	Registrierung abfragen	T1070.004
	Systeminformationserkennung	T1012
	Softwareerkennung	T1082
	Erkennung von Sicherheitssoftware	T1518
Kollektion	Keylogging	T1518.001
	Screen Capture	T1056.001
	Daten aus der Zwischenablage	T1113
	Audio-Capture	T1115
	Video Capture	T1123
Command and Control	Application Layer Protocol: Webprotokolle	T1125
	Non-Application-Layer-Protokoll	T1071.001
	Verschlüsselter Kanal	T1095
	Proxy: Externer Proxy	T1573
	Dynamische Auflösung	T1090.002
Ressourcenentwicklung	Infrastruktur erwerben: Domänen	T1568
	Infrastruktur kompromittieren	T1583.001