Inhalte

• Einführung
• Hauptziele
  • Betroffene Branchen
  • Geografischer Fokus
• Infektionskette
• Erste Erkenntnisse
  • Ein Blick in das Lockvogeldokument
• Technische Analyse
  • Phase 1 – Erste Lieferung
    • Pfad A: LNK-basierte Ausführung
    • Pfad B: Auslieferung basierend auf ausführbaren Dateien
  • Phase 2 – Skriptbasierte Dropper-Kette
  • Stufe 3 – RUSTCLOAK (Rostbeschichter)
  • Phase 4 – AZUREVEIL (Adaptix C2 Agent)
• Infrastruktur und Zuordnung
• Fazit
• SEQRITE Schutz
• Kompromissindikatoren (IOCs)
• MITRE ATT&CK-Mapping
• Autoren

Einführung

Das Seqrite Das APT-Team verfolgt aktiv Bedrohungen weltweit. In unserer jüngsten Analyse identifizierten wir eine Spear-Phishing-Kampagne, die sich gegen Beamte und Bürger in Tschechien und Taiwan richtet. Wir beobachteten ein einzelnes Köderdokument sowie mehrere unterstützende Artefakte, die stark darauf hindeuten, dass die Kampagne gezielt auf diese Regionen abzielt, da die Dateien offiziellen Mitteilungen täuschend ähnlich sehen.

Der Angriff beginnt mit einem ZIP-Anhang. Nach dem Entpacken enthält das Archiv mehrere Dateien, die zwar legitim erscheinen, aber tatsächlich Teil einer strukturierten Infektionskette sind, die darauf ausgelegt ist, im Hintergrund Schadcode auszuführen.

Dieser Blog bietet eine detaillierte Beschreibung des gesamten Infektionsprozesses und erklärt, wie der Angreifer zwei verschiedene Übertragungswege nutzt, um die Schadsoftware auszuführen. Außerdem wird untersucht, wie vertrauenswürdige Dienste wie Microsoft Azure Blob Storage für die Befehls- und Kontrollkommunikation missbraucht werden und wie der Adaptix-Agent zur Datenexfiltration und Fernsteuerung eingesetzt wird.

Darüber hinaus analysieren wir die mehrschichtige Verschlüsselung zum Schutz der Nutzdaten und wie diese dem Angreifer hilft, einer Entdeckung zu entgehen. Der Blog präsentiert außerdem wichtige Indikatoren für eine Kompromittierung (IOCs), hebt wichtige Erkenntnisse unserer Analyse hervor und ordnet das beobachtete Verhalten den MITRE ATT&CK-Techniken zu, um die Zuordnung dieser Kampagne zu einem mit China verbundenen Bedrohungsakteur zu unterstützen.

Hauptziele

Betroffene Branchen

• Regierung & öffentlicher Sektor
• Forschung und Wissenschaft
• Technologie & Software
• Finanzdienstleistungen

Geografischer Fokus

• Tschechien
• Taiwan

Infektionskette

Erste Erkenntnisse

Im Rahmen unserer laufenden Bemühungen zur Bedrohungsüberwachung, SEQRITE Das Labs-Team hat ein verdächtiges ZIP-Archiv auf dem threat intelLicence-Plattform VirusTotal.

Auf Grundlage der verfügbaren Telemetriedaten wurde die Datei erstmals am 26. März 2026 aus Taiwan übermittelt. Diese erste Übermittlung liefert einen wichtigen Hinweis, da sie auf die Region hinweisen könnte, in der die Kampagne erstmals beobachtet wurde oder aktiv ins Visier genommen wurde.

Nach der Analyse des Inhalts des extrahierten ZIP-Archivs identifizierten wir mehrere verdächtige Dateien, darunter einen Ordner mit dem Namen frustrierten, eine Verknüpfungsdatei 計畫申請審查結果通知單.pdf.lnk, die als PDF-Dokument getarnt ist, und eine ausführbare Datei _計畫申請審查結果通知單.exe, die als legitime Datei getarnt ist. Der Dateiname wird übersetzt in „Benachrichtigung über das Ergebnis der Projektantragsprüfung“ Dies deutet darauf hin, dass versucht wird, den Anschein eines offiziellen Dokuments zu erwecken. Die Dateinamen sind in traditionellem Chinesisch verfasst, wie es in Taiwan üblich ist, was die Vermutung nahelegt, dass die Kampagne auf Nutzer in dieser Region abzielt.

Nach der Analyse des Inhalts des Datenordners fanden wir mehrere Dateien, die in verschiedenen Phasen der Infektionskette involviert sind, darunter verschlüsselte Payload-Container (1.dat und Com.dat), Skriptdateien (Profile.ps1 und empty.vbs), eine bösartige DLL, die zum Sideloading verwendet wird (UnityPlayer.dll), und eine Köder-PDF-Datei, die dazu dient, das Opfer abzulenken.

Nach der Analyse der ausführbaren Datei stellten wir fest, dass diese ein zusätzliches Köderdokument erzeugt, das einem offiziellen Dokument der Tschechischen Republik nachempfunden ist. Dieses Dokument wird später im Blog detailliert analysiert; sein Vorhandensein deutet zudem darauf hin, dass die Kampagne auch tschechische Beamte ins Visier nimmt.

Ein Blick in das Lockvogeldokument

Nach der Untersuchung des ZIP-Archivs entdeckten wir im Ordner „data/“ ein Köderdokument mit dem Namen „000b67d70f3876965bb09fd37164b7.pdf“. Bei der Analyse der Hauptdatei „_計畫申請審查結果通知單.exe“ fanden wir zudem ein weiteres Köderdokument, das in die Binärdatei selbst eingebettet war. Auf den ersten Blick ähneln sich die beiden Dokumente aufgrund ihrer Namen, ihr Inhalt ist jedoch unterschiedlich.

Dokument 1: Köder im Ordner data/ gefunden

Die Datei 000b67d70f3876965bb09fd37164b7.pdf wurde im Ordner „data/“ gefunden und ist mit einem Einzelbyte-XOR und dem Schlüssel 0xBE verschlüsselt. Die Entschlüsselung ergab, dass das Dokument in Chinesisch verfasst ist und Inhalte enthält, die mit einer Werbung für die WPS-PDF-Software in Verbindung stehen. Obwohl die Datei ein ähnliches Namensmuster wie das im ausführbaren Programm eingebettete Köderdokument aufweist, wird sie in keiner Phase der Infektionskette referenziert oder verwendet.

Dies lässt vermuten, dass das Dokument vom Angreifer unbeabsichtigt beigefügt wurde, möglicherweise als Überbleibsel einer anderen Kampagne, bei der ein solches Dokument als Köder gedient haben könnte.

Dokument 2: Embedded Decoy Inside _計畫申請審查結果通知單.exe

Die Köderdatei ist in die ausführbare Datei _計畫申請審查結果通知單.exe eingebettet und wird dem Opfer während der Ausführung angezeigt. Der Dokumentname lautet 000b67d70f3876965bb09fd37164b7ccrezervaci.pdf und kombiniert eine Hash-ähnliche Zeichenkette mit dem tschechischen Wort „rezervaci“. Das Dokument ist in tschechischer Sprache verfasst und scheint eine Terminbestätigung der tschechischen Sozialversicherungsverwaltung (ČSSZ) zu sein, die wahrscheinlich von der offiziellen Website cssz.cz stammt. Sie enthält unter anderem einen Termin für eine Person namens [Name der Person einfügen]. Zuzana Košková am 16. März 2026, sodass es wie ein echtes, von der Regierung ausgestelltes Dokument aussieht.

Der letzte Abschnitt des Dokuments enthält zusätzliche Anweisungen für den Empfänger und erklärt, was bei Ankunft im Büro zu tun ist. Er erläutert, wie man mithilfe des angegebenen Identifikationscodes eine Wartemarkennummer erhält und weist den Benutzer an, entsprechend dem üblichen Terminverfahren zu warten.

Das Dokument enthält außerdem einen Link zur offiziellen Website der tschechischen Sozialversicherungsverwaltung (ČSSZ), über den der Termin verwaltet oder storniert werden kann. Es scheint erstellt worden zu sein, indem die Originalwebsite als PDF gespeichert oder ausgedruckt wurde.

Im nächsten Abschnitt werden wir uns mit den technischen Aspekten dieser Kampagne befassen.

Technische Analyse

Beim Durchsehen des ZIP-Inhalts fiel uns etwas Interessantes auf: Es gab tatsächlich zwei Arten Die Infektionskette würde letztendlich die schädliche DLL-Datei, die die Nutzlast enthält, seitlich laden, je nachdem, mit welcher Datei das Opfer zuerst interagiert hat.

In Pfad ADie Infektion beginnt, sobald das Opfer auf die schädliche LNK-Datei 計畫申請審查結果通知單.pdf.lnk klickt. Dadurch wird im Hintergrund ein VBScript (empty.vbs) ausgeführt, welches wiederum ein PowerShell-Skript (Profile.ps1) startet. Dieses PowerShell-Skript ist für die Entschlüsselung zuständig. 1.dat, indem der entschlüsselte Inhalt als RuntimeBroker_update.exe geschrieben und ausgeführt wird.

In Pfad BDas Opfer führt direkt _計畫申請審查結果通知單.exe aus. Diese ausführbare Datei fungiert als eigenständiger, auf Rust basierender Dropper, der alle benötigten Komponenten selbst extrahiert und anschließend dieselbe RuntimeBroker_update.exe startet.

Obwohl die ersten Schritte unterschiedlich sind, führen beide Wege zum selben Ergebnis. RuntimeBroker_update.exe lädt eine schädliche UnityPlayer.dll mittels DLL-Sideloading, was zur Ausführung eines Rust-basierten Loaders führt, den wir „runtimeBroker_update“ nennen. RostmantelDieser Loader entschlüsselt und führt dann die endgültige Nutzlast aus. AZUREVEIL, ein Adaptix C2-Agent.

Phase 1 – Erste Lieferung

Pfad A: LNK-basierte Ausführung

Die erste Übermittlungsmethode beginnt mit einer bösartigen Windows-Verknüpfungsdatei namens 計畫申請審查結果通知單.pdf.lnk, was übersetzt „Project Application Review Result Notice.pdf“ bedeutet. Die Verwendung einer doppelten Erweiterung (.pdf.lnk) ist beabsichtigt, damit die Datei wie ein normales PDF-Dokument aussieht.

Die LNK-Datei ist so konfiguriert, dass sie wscript.exe aus dem Windows-Systemverzeichnis ausführt und dabei .\data\empty.vbs als Argument übergibt. Anstatt eine PDF-Datei zu öffnen, führt die Verknüpfung diese VBScript-Datei im Hintergrund aus. Gleichzeitig verwendet sie das Microsoft Edge-Symbol, um wie ein normales Dokument auszusehen.

Pfad B: Auslieferung basierend auf ausführbaren Dateien

Die zweite Zustellungsmethode verwendet eine in Rust kompilierte ausführbare Datei namens _計畫申請審查結果通知單.exe. Diese Datei fungiert als vollständiger Dropper, da alle erforderlichen Komponenten in ihr eingebettet sind und sie daher nicht auf externe Dateien aus dem ZIP-Archiv angewiesen ist.

Bei der dynamischen Analyse stellten wir fest, dass die Binärdatei selbstständig mehrere Aktionen ausführt. Zunächst erstellt sie unter %LOCALAPPDATA%\WebViewFixUtility ein Verzeichnis zum Speichern ihrer Dateien. Anschließend legt sie mehrere Komponenten ab, darunter BrowserViewUtility.exe (eine legitime ausführbare Datei zum Sideloading), eine schädliche UnityPlayer.dll (RUSTCLOAK), eine verschlüsselte Konfigurationsdatei, ein Köderdokument (000b67d70f3876965bb09fd37164b7ccrezervaci.pdf) und RuntimeBroker_update.exe.

Phase 2 – Skriptbasierte Dropper-Kette

Weg B regelt alles intern, daher konzentrieren wir uns ab jetzt nur noch auf Pfad ADie skriptbasierte Kette durchläuft drei weitere Komponenten: empty.vbs, Profile.ps1 und 1.dat. Jede dieser Komponenten spielt eine Rolle bei der Vorbereitung und Ausführung der endgültigen Binärdatei RuntimeBroker_update.exe, die später zum DLL-Sideloading verwendet wird.

Sobald das Opfer auf die LNK-Datei klickt, empty.vbs wird ausgeführt und die skriptbasierte Kette beginnt. Dieser Ablauf läuft unauffällig im Hintergrund ab und übergibt die Steuerung von einer Komponente zur nächsten, ohne dem Benutzer etwas Verdächtiges anzuzeigen.

Nach der Analyse des VB-Skripts stellten wir fest, dass es sich um ein sehr kleines VB-Skript handelt, das lediglich den Zweck hat, Profile.ps1 mithilfe von PowerShell zu starten. Es führt PowerShell mit umgangener Ausführungsrichtlinie und in einem versteckten Fenster aus, sodass für den Benutzer nichts sichtbar ist. Das Skript selbst enthält keine eigentliche Logik und dient lediglich als Brücke zum nächsten Schritt.

Die Hauptlogik der Infektionskette wird von Profile.ps1 gesteuert. Dieses Skript liest Folgendes: 1.dat von der Datum / Der Ordner wird mithilfe einer einfachen XOR-Operation mit dem fest codierten Schlüssel P@ssw0rd_am_2026 entschlüsselt. Nach der Entschlüsselung lautet die Datei: RuntimeBroker_update.exe, das dann auf die Festplatte geschrieben wird.

Das Skript verschiebt außerdem die Dateien UnityPlayer.dll und Com.dat in das %TEMP%-Verzeichnis, sodass alle benötigten Komponenten zusammen abgelegt werden. Sobald alles vorbereitet ist, führt es im Hintergrund RuntimeBroker_update.exe aus und öffnet ein Attrappen-Dokument, um den Benutzer abzulenken.

Die Datei 1.dat ist keine reguläre ausführbare Datei. Es handelt sich um einen XOR-verschlüsselten Container, der die Datei RuntimeBroker_update.exe enthält. Die Verschlüsselung ist einfach und verwendet einen kurzen Schlüssel, vermutlich um eine einfache Erkennung zu verhindern. Nach der Entschlüsselung durch Profile.ps1 wird die eigentliche ausführbare Datei RuntimeBroker_update.exe abgelegt und ausgeführt.

Wie bereits beschrieben, nutzt die Kampagne zwei verschiedene Einstiegspunkte, je nachdem, wie das Opfer mit dem Archiv interagiert. Beide Wege führen letztendlich zur gleichen Payload, RuntimeBroker_update.exe, jedoch auf unterschiedliche Weise. Weg A folgt einer mehrstufigen, skriptbasierten Kette, die startet, sobald das Opfer auf die LNK-Datei klickt, während Weg B in sich abgeschlossen ist und lediglich die Ausführung der ausführbaren Datei erfordert.

Stufe 3 – RUSTCLOAK (Rostbeschichter)

Beide Pfade laufen hier zusammen, und RuntimeBroker_update.exe wird nun ausgeführt. Windows sucht zunächst im selben Ordner nach der UnityPlayer.dll. Der Angreifer nutzt dies aus, indem er eine manipulierte UnityPlayer.dll im selben Ordner platziert. Dadurch lädt Windows die DLL des Angreifers anstelle der legitimen Version.

Diese DLL, die wir RUSTCLOAK nennen, ist ein Rust-basierter Loader, der für die Fortsetzung der Ausführungskette und die Vorbereitung der endgültigen Nutzlast verantwortlich ist.

Entwicklerartefakte

Eine der wichtigsten Erkenntnisse aus unserer Analyse von Rostmantel Es handelte sich um einen Fehler im Bereich der betrieblichen Sicherheit, der vom Angreifer begangen wurde. Der Rust-Build-Pfad C:\Users\dell2\.cargo\registry\src\ index.crates.io-1949cf8c6b5b557f\ src\decrypt_SM4.rs wurde als Klartext in der Binärdatei belassen, wodurch Details aus dem System des Entwicklers offengelegt wurden:

Dadurch werden der Windows-Benutzername des Entwicklers als dell2 und die verwendeten Bibliotheksversionen wie libsm-0.5.1 für die SM4-Verschlüsselung und base64-0.21.7 für Base64-Operationen offengelegt.

Anti-Analyse: Sandbox-Erkennung

Bevor Sie eine böswillige Handlung begehen, Rostmantel Es prüft, ob das System in einer Sandbox- oder Analyseumgebung ausgeführt wird. Dazu wird der Computername des Systems abgerufen und mit einer fest codierten Liste von über 100 bekannten Sandbox- und Analystenrechnernamen verglichen.

Wird eine Übereinstimmung gefunden, beendet sich der Loader sofort, ohne die Nutzdaten auszuführen. Die Liste enthält häufig verwendete Namen wie beispielsweise DESKTOP-NAKFFMT, JULIA-PC und ARCHIBALD-PCDiese Überprüfung wird häufig in automatisierten Analyseumgebungen durchgeführt. Sie hilft der Malware, während der Analyse nicht erkannt zu werden.

Dreischichtige Entschlüsselungskette

Sobald Rostmantel Wenn es geladen wird, liest es die verschlüsselte Nutzlast (Com.dat) von der Festplatte und verarbeitet sie durch mehrere Entschlüsselungsebenen, bevor sie ausgeführt werden kann.

Schicht 1: Benutzerdefinierte RC4-Entschlüsselung – Die erste Stufe verwendet einen modifizierten RC4-Algorithmus. Der für diesen Schritt verwendete Schlüssel lautet: F8 83 40 17 1D 66 AA C2 B0 25 A8 6C A0 DD C4 5A

Schicht 2: Base64-Dekodierung – Nach dem RC4-Schritt ist die Ausgabe noch nicht direkt verwendbar. Sie ist im Base64-Format kodiert, daher dekodiert der Loader sie, um die eigentlichen Binärdaten für den nächsten Schritt zu erhalten.

Schicht 3: SM4-CBC-Entschlüsselung – Im letzten Schritt werden die Daten mit SM4 im CBC-Modus entschlüsselt. Der verwendete Schlüssel und Initialisierungsvektor sind:

Legende: CD CE 4F DB 3E 6A F2 44 AC 62 8C F4 96 1F 6B FB
IV: FA 70 B1 81 A0 BA 5D 46 7A 5D 40 DD 99 B6 9B 42

In-Memory-Ausführung über Windows-Fibers

Sobald der Entschlüsselungsprozess abgeschlossen ist, Rostmantel Es reserviert Speicher mithilfe von VirtualAlloc und kopiert den entschlüsselten Shellcode hinein. Anschließend ändert es die Speicherberechtigungen mithilfe von VirtualProtect auf ausführbar, bevor die Payload ausgeführt wird.

Anstatt einen neuen Thread zu erstellen, was häufig von Sicherheitstools überwacht wird, verwendet es Windows-Fibers zur Ausführung. Der Loader ruft CreateFiberEx und anschließend SwitchToFiber auf, um die Kontrolle an den Shellcode zu übergeben.

Beim Debuggen des Loaders stellten wir fest, dass dieser einen großen Speicherbereich belegt und die entschlüsselte Nutzlast dorthin kopiert. Bei genauerer Untersuchung des Speicherbereichs identifizierten wir einen gültigen PE-Header (MZ), was bestätigte, dass der Shellcode tatsächlich eine vollständige ausführbare Datei enthält. Die Größe dieser Nutzlast im Speicher betrug etwa 103 KB.

Wir extrahierten diese PE-Datei im Arbeitsspeicher während des Debuggens, die sich als die endgültige Nutzlast herausstellte. AZUREVEIL. Dies zeigt, dass Rostmantel Es wird nicht einfach nur roher Shellcode direkt ausgeführt, sondern stattdessen wird eine vollständige ausführbare Datei entschlüsselt und in den Speicher geladen und anschließend die Ausführung an diese übertragen.

Phase 4 – AZUREVEIL (Adaptix C2 Agent)

AZUREVEIL ist die letzte Nutzlast und der technisch interessanteste Teil dieser Kampagne.

Nach der Analyse der Datei mit DIE stellten wir fest, dass AZUREVEIL ist ein voll funktionsfähiger Adaptix C2-Agent, der als 64-Bit-DLL mit MinGW C++ kompiliert wurde.

Bei der Analyse auf VirusTotal wurde die Probe von mehreren Anbietern als bösartig eingestuft, wobei die Erkennung auf eingebettete Konfigurationen hinwies, die mit der Malware-Familie Adaptix in Verbindung stehen.

Wir haben Folgendes festgestellt: AZUREVEIL löst zur Laufzeit etwa 87 Windows-APIs mithilfe einer djb2-basierten Hash-Methode auf. Diese APIs werden aus Kernbibliotheken wie beispielsweise … geladen. wininet.dll, Ws2_32.dll, Advapi32.dll, Iphlpapi.dll und msvcrt.dll.

Azure Blob Storage C2-Kommunikation

Im Rahmen unserer Analyse stellten wir Folgendes fest: AZUREVEIL Für die Befehls- und Kontrollkommunikation nutzt die Malware Microsoft Azure Blob Storage. Besonders interessant ist der C2-Mechanismus, da es keinen herkömmlichen C2-Server gibt. Die Malware kommuniziert direkt mit Azure Blob Storage, demselben Dienst, der von Tausenden legitimer Unternehmen weltweit eingesetzt wird.

C2-Endpunkt: note1ggbbhggdwa1[.]blob[.]core[.]windows[.]net

Anstatt eines herkömmlichen Pull-basierten C2-Modells, AZUREVEIL Es wird ein Dead-Drop-Verfahren angewendet. Angreifer und infiziertes System kommunizieren niemals direkt miteinander. Stattdessen nutzen beide Seiten denselben Azure-Speichercontainer für den Datenaustausch.

Der Agent lädt regelmäßig ein kleines, verschlüsseltes Signal (etwa 124 Byte) hoch, um seine Aktivität zu signalisieren. Der Angreifer platziert anschließend Befehle im selben Container. AZUREVEIL Ruft diese Befehle ab, entschlüsselt sie, führt sie aus und lädt die Ergebnisse als verschlüsselte Datenblöcke wieder hoch.

Befehlsfunktionen von AZUREVEIL

Im Rahmen unserer statischen und dynamischen Analyse identifizierten wir 36 Befehle, die von … unterstützt werden. AZUREVEILDiese Fähigkeiten decken ein breites Spektrum an Aktivitäten nach der Ausnutzung ab. Sie ermöglichen es dem Angreifer, das infizierte System vollständig zu kontrollieren, Daten zu stehlen und sich lateral im Netzwerk zu bewegen.

Dateisystemvorgänge

• Verzeichnisinhalte und logische Laufwerke auflisten
• Dateien lesen, verschieben, umbenennen und löschen
• Dateien in Azure Blob Storage exfiltrieren
• Dateien vom C2-Server auf das Zielsystem übertragen
• Warteschlange für Dateidownloads

Prozess- und Gehäusesteuerung

• Shell-Befehle ausführen
• Liste der laufenden Prozesse und benannten Pipes
• Prozesse konfigurieren und beenden
• Prozesse stoppen oder Leitungen schließen

Netzwerk und Pivotierung

• Portweiterleitung und SOCKS-Proxy-Steuerung
• TCP- und UDP-Pivot-Verbindungen
• Benannte Rohrleitungskommunikation
• Netzwerkadapteraufzählung (MAC, IP, Typ)

C2-Verwaltung

• C2-Einstellungen zur Laufzeit neu konfigurieren
• Status der Dateiübertragung steuern
• Systemverfügbarkeit abrufen

Codeausführung im Arbeitsspeicher

• Beacon-Objektdateien (BOF) vollständig ausführen
  im Speicher, ohne auf die Festplatte zu schreiben

BOF-Ausführungs-Engine

Der Befehl 0x32 erregte unsere Aufmerksamkeit während der statischen Analyse. Zunächst sah er aus wie eine generische Injektionsroutine, doch nach der Analyse des Relokationscodes stellten wir fest, dass er mehr als das war.

Die Funktion las Daten an Offset +2 für die Abschnittsanzahl und Offset +12 für die Symbolanzahl – genau die Offsets, die im Standard-COFF-Dateiformat definiert sind. Um dies zu bestätigen, kompilierten wir eine echte AMD64-COFF-Objektdatei auf unserem Analyserechner und verglichen deren Struktur mit der des Parsers.

Beim Empfang einer BOF (Bounding File) reserviert AZUREVEIL zunächst Speicher und lädt die verschiedenen Abschnitte der Objektdatei hinein. Anschließend verarbeitet es die erforderlichen Relokationen und löst Funktionsreferenzen mithilfe seiner internen Hash-basierten Suche auf. Nach Abschluss aller Vorbereitungen führt der Loader den BOF-Einstiegspunkt direkt im Agentenprozess aus.

Jegliche während der Ausführung erzeugte Ausgabe wird mithilfe einer Named Pipe erfasst und anschließend über Azure Blob Storage an den Angreifer zurückgesendet. Dadurch kann der Angreifer zusätzliche Funktionen auf dem System ausführen und die Ergebnisse zurückerhalten, während er sich vollständig im Arbeitsspeicher befindet.

Infrastruktur und Zuordnung

Im Rahmen unserer Analyse stellten wir Folgendes fest: AZUREVEIL Die Kommunikation erfolgt ausschließlich über Microsoft Azure Blob Storage, wodurch die legitime Cloud-Infrastruktur für die Kommando- und Kontrollführung missbraucht wird. Anstelle eines herkömmlichen C2-Servers nutzt der Angreifer ein dediziertes Azure-Speicherkonto: note1ggbbhggdwa1[.]blob[.]core[.]windows[.]net

Weitere Analysen ergaben folgende Details zur Speicherkonfiguration:

Container: /note/ats/
Blob-Format: {agent_id}/{timestamp1}_{timestamp2}.bin
Agenten-ID: 345831bc
Port: 443 (HTTPS)

Die gesamte Kommunikation erfolgt über HTTPS auf Port 443, wodurch der Datenverkehr unauffällig in den normalen Azure-Verkehr integriert wird. Da blob.core.windows.net von vielen legitimen Anwendungen genutzt wird, hilft dieser Ansatz Angreifern, eine Erkennung auf Netzwerkebene zu vermeiden.

Wir haben außerdem ein fest codiertes Shared Access Signature (SAS)-Token in encrypted_blob identifiziert, das von der ausführbaren Datei _計畫申請審查結果通知單.exe abgelegt wird und zur Authentifizierung aller Operationen auf dem Speicherkonto verwendet wird:

sv=2024-11-04&ss=b&srt=sco&sp=rwdlaciytfx&st=2026-03-19T09:20:44Z&se=2027-03-19T17:35:44Z&spr=https&sig=ECJjJIIE9Ou75dwiHhliC4fWccdBpLX9u580AX9TGwY=

Das Token ist ein Jahr lang gültig, vom 19. März 2026 bis zum 19. März 2027. Diese lange Gültigkeitsdauer deutet darauf hin, dass der Angreifer beabsichtigte, über einen längeren Zeitraum dauerhaften Zugriff zu erlangen. Die mit dem Token verbundenen Berechtigungen ermöglichen die uneingeschränkte Interaktion mit dem Speichercontainer, einschließlich Lese-, Schreib-, Lösch- und Upload-Operationen.

Aufgrund der im Verlauf dieser Kampagne beobachteten Taktiken, Techniken und Verfahren (TTPs), Werkzeuge und Zielauswahl gehen wir mit mittlerer Wahrscheinlichkeit davon aus, dass sie mit einem in China ansässigen Bedrohungsakteur in Verbindung steht. Wir ordnen sie jedoch keiner bestimmten bekannten Gruppe zu, da die Kampagne Techniken umfasst, die bisher nicht im Zusammenhang mit öffentlich bekannten chinesischen APT-Aktivitäten dokumentiert wurden.

Fazit

Operation Dragon Weave Es handelt sich um eine gezielte Spionagekampagne. Ein besonderes Merkmal dieser Kampagne ist die Nutzung von Microsoft Azure Blob Storage als verdeckten C2-Kanal. Anstatt mit einem herkömmlichen C2-Server zu kommunizieren, tarnt die Malware ihren Datenverkehr im regulären Cloud-Verkehr und ist dadurch deutlich schwerer zu entdecken. Die finale Payload, AZUREVEIL, ist ein vollwertiger Adaptix C2-Agent mit 36 ​​Befehlen zur Nachbearbeitung. Zusammen mit der Möglichkeit zur Ausführung von BOF-Befehlen im Arbeitsspeicher bietet er dem Angreifer viel Flexibilität, um zusätzlichen Code auszuführen und das System zu kontrollieren, ohne dabei nennenswerte Spuren auf der Festplatte zu hinterlassen.

Wir stellten außerdem fest, dass die Kampagne sowohl die Tschechische Republik als auch Taiwan ins Visier nimmt und regionsspezifische Köderdokumente verwendet. Dies deutet darauf hin, dass die Operation geplant und gezielt und nicht zufällig ist. Aufgrund des Einsatzes spezifischer Werkzeuge und Techniken gehen wir davon aus, dass diese Kampagne mit einem in China ansässigen Bedrohungsakteur in Verbindung steht.

SEQRITE Schutz

Lnk.Trojan.50646.GC

Trojan.Agent.S38943638

Script.Trojan.50655.SL

Script.Trojan.50650.SL

Kompromissindikatoren (IOCs)

SHA-256Dateiname

096372d19b4787e989f44e04c5ecc29885aa927c34ae8666628d6c0eb20bb447	計畫申請審查結果通知單.pdf.lnk
1c56228cbd1bdebb9e5ea55c2749150fee06c865ede4a3754e8bd6843e51d2d4	計畫申請審查結果通知單.exe
080ab9bc2893ba7bad354551604a667af40ed2ae2d042d2323c2bd9ad3122192	UnityPlayer.dll
5ed14c2b7f7433a1a72dd6b668413f935a217ba10b69d89b774a82990fa12fe1	BrowserViewUtility.exe
61f7d9cd2d8ce7df950639b23ce90085b300b0c6dd0d8d934bba8fdecb670f15	RuntimeBroker_update.exe
24aa4e780ccd66cef13da9ef98c32954105cf2a32ec643efab0ba1aa2d6352f4	Com.dat
02542a49b3bd6bd2795afb67840acb4557b17e017f7503dd03ebe3aeeb28720e	000b67d70f3876965bb09fd37164b7ccrezervaci.pdf
8ae7c82a3e4f742777e590b25a1c563d19bd9bcba2a387d004aae72c4b2828f9	000b67d70f3876965bb09fd37164b7.pdf
047687548605734348792e2a9d771b6cba42facd0d0d7d44d778290a25848574	1.dat
a4e9f9919d62589b57cfa08c9ccb89e386b09f683271373413cd8e8c8c7d1c5a	empty.vbs
823d5969db3f3b72ebbdce1b78752717ea849884a0fb40d86146416c38e128de	Profile.ps1
783661d0f7edb338d2d50be087764d82dbbc9ee7989ddc57db1801e4ec9045b0	azureveil.exe

Netzwerkanzeige

IndikatorBeschreibung

note1ggbbhggdwa1[.]blob[.]core[.]windows[.]net	Azure Blob Storage C2

MITRE ATT&CK-Mapping

Taktik	Technik-ID	Technikname
Erster Zugriff	T1566.001	Speerphishing-Anhang
Ausführung	T1204.002	Schadsoftware – Benutzerausführung
	T1059.001	Powershell
	T1059.005	Visual Basic
Verteidigungsausweichung	T1574.002	DLL-Seitenladen
	T1027	Verschleierte Dateien oder Informationen
	T1055	Prozessinjektion
	T1497.001	Virtualisierung/Sandbox-Umgehung
	T1620	Reflektierendes Laden von Code
Bewertung	T1083	Datei- und Verzeichniserkennung
	T1057	Prozesserkennung
	T1016	Systemnetzwerkkonfigurationserkennung
	T1082	Systeminformationsermittlung
Befehl und Kontrolle	T1102.001	Webdienst – Dead-Drop-Resolver
	T1573	Verschlüsselter Kanal
	T1090	Proxy
	T1105	Ingress-Tool-Übertragung
Exfiltration	T1041	Exfiltration über den C2-Kanal

Autoren

Priya Patel

Kartikkumar Jivani