APT Gruppe Worok: Das große Ganze

ESET-Forscher entdeckten kürzlich gezielte Angriffe mit undokumentierten Tools auf verschiedene hochrangige Unternehmen und lokale Regierungen, hauptsächlich in Asien. Diese Angriffe wurden von einer bisher unbekannten Spionagegruppe durchgeführt, die wir Worok genannt haben und die mindestens seit 2020 aktiv ist. Das Toolset von Worok umfasst einen C++-Loader CLRLoad, eine PowerShell-Backdoor PowHeartBeat und einen C#-Loader PNGLoad, der Steganografie verwendet, um versteckte bösartige Payloads aus PNG-Dateien zu extrahieren.

Wer ist Worok?

Während der Veröffentlichung der ProxyShell-Schwachstelle (CVE-2021-34523) Anfang 2021 beobachteten wir Aktivitäten von verschiedenen APT-Gruppen. Eine davon wies gemeinsame Merkmale mit TA428 auf:

• Aktivitätszeiten
• Angegriffene Bereiche
• Verwendung von ShadowPad

Das restliche Toolset ist dagegen sehr unterschiedlich: TA428 hat sich beispielsweise an der Able Desktop Attacke im Jahr 2020 beteiligt. Wir sind der Meinung, dass die Verbindungen nicht stark genug sind, um Worok als dieselbe Gruppe wie TA428 zu betrachten, aber die beiden Gruppen könnten gemeinsame Werkzeuge und Interessen haben. Wir beschlossen, die Informationen in einem Cluster zusammenzufassen und nannten ihn Worok. Der Name wurde nach einem Mutex in einem von der Gruppe verwendeten Loader gewählt. Weitere Aktivitäten mit Varianten der gleichen Tools wurden dann mit dieser Gruppe verknüpft. Laut unserer Telemetrie ist Worok seit Ende 2020 aktiv und ist es auch jetzt noch.

Ende 2020 hatte Worok insbesondere Regierungen und Unternehmen in mehreren Ländern im Visier:

• Ein Telekommunikationsunternehmen in Ostasien
• Eine Bank in Zentralasien
• Ein Unternehmen der maritimen Industrie in Südostasien
• Eine staatliche Einrichtung im Nahen Osten
• Ein privates Unternehmen im südlichen Afrika

Von Mai 2021 bis Januar 2022 gab es eine Unterbrechung der beobachteten Vorgänge, aber im Februar 2022 kehrte die Worok-Aktivität zurück, und zwar zielgerichtet bei:

• Einem Energieunternehmen in Zentralasien
• Einer Einrichtung des öffentlichen Sektors in Südostasien

Abbildung 1 zeigt die Zielregionen und -bereiche.

Abbildung 1. Karte der Zielregionen und -bereiche

In Anbetracht der Profile der Zielpersonen und der Tools, die gegen diese Opfer eingesetzt wurden, gehen wir davon aus, dass das Hauptziel von Worok darin besteht, Informationen zu stehlen.

Technische Analyse

Während die Mehrheit der anfänglichen Angriffpunkte unbekannt ist, haben wir in einigen Fällen in 2021 und 2022 Exploits gesehen, die gegen die sogenannten ProxyShell-Schwachstellen eingesetzt wurden. In diesen Fällen wurden in der Regel Webshells hochgeladen, nachdem die Schwachstellen ausgenutzt worden waren, um die Persistenz im Netzwerk des Opfers zu gewährleisten. Dann verwendeten die Betreiber verschiedene Implantate, um weitere Fähigkeiten zu erlangen.

Nachdem sie sich Zugang verschafft hatten, setzten die Angreifer mehrere öffentlich verfügbare Tools zur Erkundung und Aufklärung ein, darunter Mimikatz, EarthWorm, ReGeorg und NBTscan, und verteilten anschließend dann ihre eigenen Tools: einen First Stage Loader, gefolgt von einem .NET-Loader (PNGLoad). Leider ist es uns nicht gelungen, die endgültigen Payloads aufzuspüren. Im Jahr 2021 war der First Stage Loader eine CLR-Assembly (CLRLoad), während er im Jahr 2022 in den meisten Fällen durch eine voll funktionsfähige PowerShell-Backdoor (PowHeartBeat) ersetzt wurde - beide Angriffsverläufe sind in Abbildung 2 dargestellt. Diese drei Tools werden in den folgenden Unterabschnitten im Detail beschrieben.

Abbildung 2. Worok-Angriffsverlauf

CLRLoad: CLR Assembly Loader

CLRLoad ist ein generisches Windows PE, das wir sowohl in 32- als auch in 64-Bit-Versionen gesehen haben. Es handelt sich um einen in C++ geschriebenen Loader, der die nächste Stufe (PNGLoad) lädt, bei der es sich um eine Common Language Runtime (CLR) Assembly-DLL handeln muss. Dieser Code wird aus einer Datei geladen, die sich auf der Festplatte in einem legitimen Verzeichnis befindet, vermutlich um die Opfer oder Forensiker zu täuschen, damit sie glauben, es handele sich um legitime Software.

Einige CLRLoad-Beispiele beginnen mit der Dekodierung des vollständigen Pfads der Datei, deren Inhalt sie im nächsten Schritt laden werden. Diese Dateipfade werden mit einem Single-Byte-XOR verschlüsselt, wobei in jedem Sample ein anderer Schlüssel verwendet wird. Dekodiert oder im Klartext sind diese Dateipfade absolut, wobei wir die folgenden gefunden haben:

• C:\Program Files\VMware\VMware Tools\VMware VGAuth\xsec_1_5.dll
• C:\Program Files\UltraViewer\msvbvm80.dll
• C:\Program Files\Internet Explorer\Jsprofile.dll
• C:\Program Files\WinRar\RarExtMgt.dll
• C:\Program Files (x86)\Foxit Software\Foxit Reader\lucenelib.dll

Als Nächstes wird ein Mutex erstellt, der in jedem Sample einen anderen Namen hat. Der Loader sucht nach diesem Mutex; wenn er ihn findet, wird er beendet, da der Loader bereits läuft. In einem der Samples wurde der Mutex Wo0r0KGWhYGO gefunden, was der Gruppe den Namen Worok gab.

CLRLoad lädt dann eine CLR-Assembly aus dem möglicherweise dekodierten Dateipfad. Als nicht verwalteter Code erreicht CLRLoad dies über CorBindToRuntimeEx-Windows-API-Aufrufe in 32-Bit-Varianten oder CLRCreateInstance-Aufrufe in 64-Bit-Varianten.

PowHeartBeat: PowerShell Backdoor

PowHeartBeat ist eine in PowerShell geschriebene, vollumfängliche Backdoor, die mit verschiedenen Techniken wie Komprimierung, Kodierung und Verschlüsselung verschleiert wird. Basierend auf den ESET-Telemetriedaten gehen wir davon aus, dass PowHeartBeat in neueren Worok-Kampagnen CLRLoad als das Tool zum Starten von PNGLoad ersetzt hat.

Die erste Schicht des Backdoor-Codes besteht aus mehreren Stücken base64-kodierten PowerShell-Codes. Sobald die Payload rekonstruiert ist, wird sie über IEX ausgeführt. Nach der Dekodierung wird eine weitere Schicht mit verschleiertem Code ausgeführt, wie in Abbildung 3 zu sehen.

Abbildung 3. Auszug aus der entschlüsselten Hauptfunktion der zweiten Schicht von PowHeartBeat

Die zweite Schicht der Backdoor entschlüsselt zunächst die nächste Schicht ihres Codes mit base64, der dann mit Triple DES (CBC-Modus) entschlüsselt wird. Nach der Entschlüsselung wird dieser Code mit dem gzip-Algorithmus dekomprimiert, wodurch die dritte Schicht des PowerShell-Codes entsteht, die die eigentliche Backdoor darstellt. Sie ist in zwei Hauptteile unterteilt: die Konfiguration und die Verarbeitung von Backdoor-Befehlen.

Die Hauptschicht des Backdoor-Codes ist ebenfalls in PowerShell geschrieben und verwendet HTTP oder ICMP zur Kommunikation mit dem C&C-Server. Sie funktioniert wie in Abbildung 4 dargestellt.

Abbildung 4. Die Funktionsweise von PowHeartBeat

Konfiguration

Die Konfiguration enthält mehrere Felder, darunter die Versionsnummer, die optionale Proxy-Konfiguration und die C&C-Adresse. Tabelle 1 beschreibt die Bedeutung der Konfigurationsfelder in den verschiedenen Versionen, die wir beobachtet haben.

Table 1. Bedeutung der Konfigurationsfelder

Abbildung 5 zeigt ein Beispiel für eine Konfiguration, die aus einem PowHeartBeat-Beispiel extrahiert wurde (SHA-1: 757ABA12D04FD1167528FDD107A441D11CD8C427).

$Script:nouse = 100;
if(Test-Path $MyInvocation.MyCommand.Path){Remove-item $MyInvocation.MyCommand.Path -Force;}
$Script:ClientId = "83";
$Script:Version = "2.1.3.0003";
$Script:ExecTimes = 10;
$Script:UserAgent = "Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/69.0.3487.100 Safari/537.36";
$Script:Referer = "www.adobe.com";
$Script:AcceptEncoding = "text/html,app1ication/xhtml+xml,app1ication/xml;q=0.9,*/*;q=0.8";
$Script:CookieClientId = "s_ecid";
$Script:CookieTaskId = "aam_uuid";
$Script:CookieTerminalId = "AAMC_adobe_0";
$Script:UrlHttps = "http://";
$Script:UrlDomain=  " 118.193.78[.]22:443";
$Script:UrlSendHeartBeat = "/latest/AdobeMessagingClient.js";
$Script:UrlSendResult = "/content/dam/offers-homepage/homepage.jpg";
$Script:GetUrl = $Script:UrlHttps + $Script:UrlDomain + $Script:UrlSendHeartBeat;
$Script:PutUrl = $Script:UrlHttps + $Script:UrlDomain + $Script:UrlSendResult;
$Script:currentPath = Split-Path -Parent $MyInvocation.MyCommand.Definition;
$Script:ProxyEnableFlag = $false;
$Script:Proxymsg;
$Script:Interval = 10 ;
$Script:BasicConfigPath = "C:\ProgramData\unins.dat";
$Script:UpTime = 0;
$Script:DownTime = 24;
$Script:Domains;
$Script:DomainIndex;
$Script:SecretKey = "###ConfigKey###";

#$Script:IfLog = $true;
$Script:IfLogFilePath = "C:\ProgramData\tpncp.dat";
$Script:logpath = "C:\ProgramData\unins000.dat";
$Script:ProxyFile = "C:\ProgramData\hwrenalm.dat";

$Script:IfConfig = $false;

Abbildung 5. Beispiel für eine Konfiguration

Datenverschlüsselung

PowHeartBeat verschlüsselt Logs und den Inhalt zusätzlicher Konfigurationsdateien.

Der Inhalt der Logs wird durch Multiple-Byte-XOR mit einem im Sample im Klartext angegebenen Schlüssel verschlüsselt. Interessanterweise wird clientId als Salt für den Index im Schlüssel-Array verwendet. Der Schlüssel ist ein 256-Byte-Array, das in jedem Sample identisch war. Zusätzlicher Inhalt der Konfigurationsdatei wird durch Multiple-Byte-XOR mit dem Wert von SecretKey als Schlüssel verschlüsselt.

C&C Kommunikation

PowHeartBeat verwendete bis Version 2.4 HTTP für die C&C-Kommunikation und wechselte dann zu ICMP. In beiden Fällen ist die Kommunikation nicht verschlüsselt.

HTTP

In einer Endlosschleife sendet die Backdoor eine GET-Anfrage an den C&C-Server und bittet um einen Befehl, der ausgeführt werden soll. Die verschlüsselte Antwort wird von der Backdoor entschlüsselt, die den Befehl verarbeitet und die Befehlsausgabe in eine Datei schreibt, deren Inhalt dann über eine POST-Anfrage an den C&C-Server gesendet wird.

Das Format der GET-Anfragen ist wie folgt:

GET <UrlSendHeartBeat> HTTP/1.1
User-Agent: <UserAgent>
Referer: <Referer>
Host: <Domain>
Cookie: <CookieClientId>=<ClientId>
Connection: close

Beachten Sie, dass die Anfrage unter Verwendung der gleichnamigen Konfigurationsfelder erstellt wird.

In der Antwort des C&C-Servers ist das dritte Byte des Inhalts die Befehlskennung, die den von der Backdoor zu verarbeitenden Befehl angibt. Wir nennen ihn command_id. Der restliche Inhalt der Antwort wird als Argument an den zu verarbeitenden Befehl übergeben. Dieser Inhalt wird mit dem in Abbildung 6 dargestellten Algorithmus verschlüsselt, wobei taskId der Wert des Cookies ist, der nach dem Wert von CookieTaskId aus der Konfiguration benannt ist.

o[int] $pos = $taskId % 256;
for ($i = 0; $i -lt $tmpBytes.Value.Length; $i++)
{
	$pos = $pos + $clientId;
	if ($pos -ge 256)
	{
		$pos = $pos % 256;
	}
	$tmpBytes.Value[$i] = [byte]($tmpBytes.Value[$i] -bxor $hexEnc[$pos]);
}

Abbildung 6. Abfrage des Algorithmus zur Verschlüsselung von Inhaltsdaten

Die Antwort des C&C-Servers enthält außerdem ein weiteres Cookie, dessen Name durch die Konfigurationsvariable CookieTerminalId der Backdoor festgelegt wird. Der Wert dieses Cookies wird in der POST-Anfrage von der Backdoor wiederholt und darf nicht leer sein. Nach dem Ausführen des Backdoor-Befehls sendet PowHeartBeat das Ergebnis als POST-Anfrage an den C&C-Server. Das Ergebnis wird in Form einer Datei mit dem Namen <command_id>.png gesendet.

ICMP

Ab Version 2.4 von PowHeartBeat wurde HTTP durch ICMP ersetzt, wobei die gesendeten Pakete ein Timeout von sechs Sekunden haben und nicht fragmentiert sind. Die Kommunikation über ICMP ist höchstwahrscheinlich ein Weg, um der Entdeckung zu entgehen.

In den Versionen 2.4 und später gibt es keine größeren Änderungen, aber wir haben einige Änderungen im Code festgestellt:

• PowHeartBeat sendet bei jeder Schleife ein Heartbeat-Paket, das die Zeichenfolge abcdefghijklmnopqrstuvwxyz enthält, bevor es einen Befehl anfordert. Dies teilt dem C&C-Server mit, dass die Backdoor bereit ist, Befehle zu empfangen.
• Anfragen zu Abrufbefehlen, die von der Backdoor ausgeführt werden, enthalten die Zeichenfolge abcdefghijklmnop.

Heartbeat-Pakete haben das in Abbildung 7 beschriebene Format.

Abbildung 7. Aufbau von Heartbeat-Paketen

Der Unterschied zwischen client ID und client flag besteht darin, dass client ID in jedem Sample unterschiedlich ist, während client flag in jedem Sample, das ICMP verwendet, gleich ist.  heartbeat flag zeigt an, dass die Backdoor einen Heartbeat sendet. Die Antwort des C&C-Servers hat das in Abbildung 8 beschriebene Format.

Abbildung 8. Antwort-Layout des C&C-Servers

flag zeigt an, ob ein Befehl an die Backdoor zu senden ist. Anfragen für Befehle haben das in Abbildung 9 beschriebene Format.

Abbildung 9. Layout für die Abfrage von Befehlen

Beachten Sie, dass der ICMP-Modus der Backdoor den Empfang einer unbegrenzten Menge von Daten, aufgeteilt in Pakete, ermöglicht und die Variablen data length, current position und total length verwendet werden, um die übertragenen Daten zu verfolgen. Die Antworten auf diese Anfragen haben das in Abbildung 10 beschriebene Format.

Abbildung 10. Layout der Antworten auf Anfragen für Abrufbefehle

Wie bei HTTP-Antworten ist die Befehlskennung das dritte Byte von data.

Nach sieben aufeinanderfolgenden ICMP-Antworten mit leerem oder inkonsistent formatiertem Inhalt wird die Übertragung zwischen Backdoor und C&C-Server als abgeschlossen betrachtet.

Bei den Anfragen zum Senden des Ergebnisses des erteilten Befehls an den C&C-Server wird der Servermodus in den Postmodus geändert, und die endgültige Zeichenfolge (abcdefghijklmnop) wird in die Ergebnisdaten geändert.

Backdoor Befehle

PowHeartBeat verfügt über verschiedene Fähigkeiten, darunter die Ausführung von Befehlen/Prozessen und die Bearbeitung von Dateien. In Tabelle 2 sind alle Befehle aufgeführt, die von den verschiedenen analysierten Samples unterstützt werden.

Tabelle 2. Beschreibungen der PowHeartBeat-Befehle

Bei Fehlern auf der Backdoor-Seite verwendet die Backdoor eine spezielle Befehlskennung 0x00 in der POST-Anfrage an den C&C-Server und zeigt damit an, dass ein Fehler aufgetreten ist.

Beachten Sie, dass die Daten vor dem Zurücksenden an den C&C-Server gzip-komprimiert werden.

PNGLoad: Steganographischer Loader

PNGLoad ist die Second Stage Payload, die von Worok auf kompromittierten Systemen verteilt und laut ESET-Telemetrie entweder von CLRLoad oder PowHeartBeat geladen wird. Wir sehen zwar keinen Code in PowHeartBeat, der PNGLoad direkt lädt, aber die Backdoor ist in der Lage, zusätzliche Payloads vom C&C-Server herunterzuladen und auszuführen. So haben die Angreifer PNGLoad wahrscheinlich auf Systemen eingesetzt, die mit PowHeartBeat kompromittiert wurden. . PNGLoad ist ein Loader, der Bytes aus PNG-Dateien verwendet, um eine Payload zur Ausführung zu erstellen. Es handelt sich um eine ausführbare 64-Bit-.NET-Datei, die mit .NET Reactor verschleiert wurde und sich als legitime Software tarnt. Abbildung 11 zeigt zum Beispiel die CLR-Header eines Samples, das sich als WinRAR-DLL ausgibt.

Abbildung 11. Beispiel für eine gefälschte WinRAR-DLL

Nach der Entschleierung ist nur noch eine Klasse vorhanden. In dieser Klasse gibt es ein MainPath-Attribut, das den Verzeichnispfad enthält, in dem die Backdoor nach Dateien mit der Erweiterung .png sucht, einschließlich ihrer Unterverzeichnisse (siehe Abbildung 12).

Abbildung 12. .png-Dateiliste

Jede in MainPath gefundene .png-Datei wird dann auf steganografisch eingebettete Inhalte überprüft. Zunächst wird das niedrigstwertige Bit der R- (Rot-), G- (Grün-), B- (Blau-) und A- (Alpha-) Werte jedes Pixels abgerufen und in einem Puffer zusammengestellt. Wenn die ersten acht Bytes dieses Puffers mit der magischen Zahl aus Abbildung 13 übereinstimmen und der nächste Acht-Byte-Wert, control, nicht Null ist, besteht die Datei die steganografische Inhaltsprüfung von PNGLoad. Bei solchen Dateien wird die Verarbeitung mit dem Rest des Puffers fortgesetzt, der mit einem XOR aus mehreren Bytes entschlüsselt wird, wobei der im Attribut SecretKeyBytes von PNGLoad gespeicherte Schlüssel verwendet wird. Anschließend wird der entschlüsselte Puffer gzip-dekomprimiert. Als Ergebnis wird ein PowerShell-Skript erwartet, das sofort ausgeführt wird.

Abbildung 13. Format des Puffers, den PNGLoad bei der Verarbeitung von .png-Dateien erzeugt

Interessanterweise werden die von PNGLoad durchgeführten Operationen in einer Datei protokolliert, deren Pfad in der Variablen LogFilePath gespeichert ist. Die Operationen werden nur protokolliert, wenn eine Datei vorhanden ist, deren Pfad durch die interne Variable IfLogFilePath angegeben ist.

Es war uns nicht möglich, ein .png-Sample aufzuspüren, das zusammen mit PNGLoad verwendet wurde. Aber die Funktionsweise von PNGLoad legt nahe, dass es mit gültigen PNG-Dateien funktionieren sollte. Um die bösartige Payload zu verbergen, verwendet Worok Bitmap-Objekte in C#, die nur Pixelinformationen aus Dateien übernehmen, nicht aber die Metadaten der Datei. Das bedeutet, dass Worok seine bösartigen Payloads in gültigen, harmlos aussehenden PNG-Bildern verstecken kann und somit unauffällig ist.

Fazit

Worok ist eine Cyberspionage-Gruppe, die ihre eigenen Tools entwickelt und auch bestehende Tools nutzt, um ihre Ziele zu kompromittieren. Wir gehen davon aus, dass es den Betreibern darum geht, Informationen von ihren Opfern zu stehlen. Sie konzentrieren sich auf hochrangige Einrichtungen in Asien und Afrika und verschiedene private und öffentliche Sektoren, jedoch mit besonderem Schwerpunkt auf Regierungseinrichtungen. Die Aktivitätszeiten und das Toolset deuten auf mögliche Verbindungen zu TA428 hin, aber wir können diese Einschätzung nur mit geringer Sicherheit treffen. Das benutzerdefinierte Toolset umfasst zwei Loader - einen in C++ und einen in C# .NET - und eine PowerShell-Backdoor. Auch wenn unsere Einsicht begrenzt ist, hoffen wir, dass die Aufklärung über diese Gruppe andere Forscher dazu ermutigt, Informationen über diese Gruppe zu teilen.

IOCs

Dateien

Dateipfade

Einige der Werte MainPath, LogFilePath und IfLogFilePath, die wir in PNGLoad-Beispielen gefunden haben:

Netzwerk

Mutexe

In CLRLoad-Samples sind die Mutex-Namen, die wir gefunden haben, folgende:

aB82UduGX0EX
ad8TbUIZl5Ga
Mr2PJVxbIBD4
oERiQtKLgPgK
U37uxsCsA4Xm
Wo0r0KGWhYGO
xBUjQR2vxYTz
zYCLBWekRX3t
3c3401ad-e77d-4142-8db5-8eb5483d7e41
9xvzMsaWqxMy

MITRE ATT&CK Techniken

Diese Tabelle wurde mit Version 11 des MITRE ATT&CK Framework erstellt.

Haben Sie Fragen und Anregungen zu diesem, anderen oder zukünftigen Themen, die Sie gern betrachtet sehen wollen? Dann nutzen Sie gern die Kommentarfunktion unter diesem Artikel oder nutzen unser Kontaktformular!