Worok: Das große Ganze

ESET-Forscher fanden kürzlich gezielte Angriffe, bei denen undokumentierte Tools gegen verschiedene hochkarätige Unternehmen und lokale Regierungen hauptsächlich in Asien eingesetzt wurden. Diese Angriffe wurden von einer bisher unbekannten Spionagegruppe durchgeführt, die wir Worok nennen und die seit mindestens 2020 aktiv ist. Das Toolset von Worok umfasst einen C++-Loader CLRLoad, eine PowerShell-Backdoor PowHeartBeat und einen C#-Loader PNGLoad, der Steganographie verwendet, um versteckte Schadsoftware zu extrahieren Payloads aus PNG-Dateien.

Wer ist Workok?

Während der ProxyShell (CVE-2021-34523) Offenlegung von Schwachstellen Anfang 2021, haben wir beobachtet Aktivität von verschiedenen APT-Gruppen. Einer wies gemeinsame Merkmale auf TA428:

• Aktivitätszeiten
• Gezielte Branchen
• Verwendung von ShadowPad

Der Rest des Toolsets ist sehr unterschiedlich: Beispielsweise nahm TA428 an der teil Abable Desktop-Kompromiss im Jahr 2020. Wir sind der Ansicht, dass die Verbindungen nicht stark genug sind, um Worok als dieselbe Gruppe wie TA428 zu betrachten, aber die beiden Gruppen könnten Tools teilen und gemeinsame Interessen haben. Wir haben uns entschieden, einen Cluster zu erstellen und ihn Workok zu nennen. Der Name wurde nach einem Mutex in einem von der Gruppe verwendeten Loader gewählt. An diese Gruppe wurde dann die weitere Aktivität mit Varianten der gleichen Tools geknüpft. Laut Telemetrie von ESET ist Worok seit Ende 2020 aktiv und ist zum jetzigen Zeitpunkt weiterhin aktiv.

Bereits Ende 2020 zielte Worok auf Regierungen und Unternehmen in mehreren Ländern ab, insbesondere:

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

Von 2021-05 bis 2022-01 gab es eine erhebliche Unterbrechung der beobachteten Operationen, aber die Workok-Aktivität kehrte 2022-02 zurück und zielte auf:

• Ein Energieunternehmen in Zentralasien
• Eine Körperschaft des öffentlichen Sektors in Südostasien

Abbildung 1 zeigt eine visuelle Heatmap der Zielregionen und Branchen.

In Anbetracht der Profile der Opfer und der Tools, die wir gegen diese Opfer eingesetzt sehen, glauben wir, dass das Hauptziel von Worok darin besteht, Informationen zu stehlen.

Technische Analyse

Während die meisten Erstzugriffe unbekannt sind, haben wir in einigen Fällen bis 2021 und 2022 Exploits gesehen, die gegen die ProxyShell-Schwachstellen eingesetzt wurden. In solchen Fällen wurden in der Regel Webshells hochgeladen, nachdem diese Schwachstellen ausgenutzt wurden, um Persistenz im Netzwerk des Opfers zu gewährleisten. Dann verwendeten die Bediener verschiedene Implantate, um weitere Fähigkeiten zu erlangen.

Nachdem der Zugang erlangt worden war, setzten die Betreiber mehrere öffentlich zugängliche Tools zur Aufklärung ein, einschließlich Mimikatz, Regenwurm, ReGeorg und NBTscan, und stellten dann ihre benutzerdefinierten Implantate bereit: einen First-Stage-Loader, gefolgt von einem Second-Stage-.NET-Loader (PNGLoad). Leider konnten wir keine der endgültigen Nutzlasten abrufen. Im Jahr 2021 war der First-Stage-Loader eine CLR-Assembly (CLRLoad), während er 2022 in den meisten Fällen durch eine voll funktionsfähige PowerShell-Hintertür (PowHeartBeat) ersetzt wurde – beide Ausführungsketten sind in Abbildung 2 dargestellt. Diese drei Werkzeuge werden in den folgenden Unterabschnitten ausführlich beschrieben.

Abbildung 2. Bearbeitete Kompromissketten

CLRLoad: CLR-Assembly-Ladeprogramm

CLRLoad ist ein generisches Windows PE, das wir sowohl in 32- als auch in 64-Bit-Versionen gesehen haben. Es ist ein in C++ geschriebener Lader, der die nächste Stufe (PNGLoad) lädt, die a sein muss Common Language Runtime (CLR)-Assembly DLL-Datei. Dieser Code wird aus einer Datei geladen, die sich auf der Festplatte in einem legitimen Verzeichnis befindet, vermutlich um Opfer oder Notfallhelfer zu der Annahme zu verleiten, dass es sich um legitime Software handelt.

Einige CLRLoad-Beispiele beginnen mit der Dekodierung des vollständigen Pfads der Datei, deren Inhalt sie als nächste Stufe laden. Diese Dateipfade sind mit einem Single-Byte-XOR codiert, mit einem anderen Schlüssel in jedem Sample. Dekodiert oder Klartext, diese Dateipfade sind absolut, wobei die folgenden die sind, auf die wir gestoßen sind:

• C:ProgrammeVMwareVMware ToolsVMware VGAuthxsec_1_5.dll
• C:ProgrammdateienUltraViewermsvbvm80.dll
• C:ProgrammeInternet ExplorerJsprofile.dll
• C:ProgrammeWinRarRarExtMgt.dll
• C:Programmdateien (x86)Foxit SoftwareFoxit Readerlucenelib.dll

Als nächstes wird ein Mutex erstellt, und wir haben in jedem Sample einen anderen Namen gesehen. Der Loader sucht nach diesem Mutex; Wenn es gefunden wird, wird es beendet, da der Lader bereits ausgeführt wird. In einem der Beispiele ist der mutex Wo0r0KGWhYGO angetroffen, was der Gruppe den Namen Worok gab.

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

PowHeartBeat: PowerShell-Hintertür

PowHeartBeat ist eine voll funktionsfähige Hintertür, die in PowerShell geschrieben ist und mit verschiedenen Techniken wie Komprimierung, Kodierung und Verschlüsselung verschleiert wird. Basierend auf ESET-Telemetrie glauben wir, dass PowHeartBeat CLRLoad in neueren Worok-Kampagnen als Tool zum Starten von PNGLoad ersetzt hat.

Die erste Schicht des Backdoor-Codes besteht aus mehreren Blöcken von base64-codiertem PowerShell-Code. Sobald die Nutzlast rekonstruiert ist, wird sie über ausgeführt IEX. Nach der Dekodierung wird eine weitere Schicht verschleierten Codes ausgeführt, die wir in Abbildung 3 sehen können.

Abbildung 3. Ausschnitt der decodierten Hauptfunktion der zweiten Schicht von PowHeartBeat

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

Die Hauptschicht des Backdoor-Codes ist ebenfalls in PowerShell geschrieben und verwendet HTTP oder ICMP, um mit dem C&C-Server zu kommunizieren. Es funktioniert wie in Abbildung 4 dargestellt.

Abbildung 4. Funktionsweise von PowHeartBeat

Konfiguration

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

Tabelle 1. Bedeutungen der Konfigurationsfelder

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

Abbildung 5. Konfigurationsbeispiel

Datenverschlüsselung

PowHeartBeat verschlüsselt Protokolle und zusätzliche Konfigurationsdateiinhalte.

Der Inhalt der Protokolldatei wird durch Multi-Byte-XOR mit einem im Beispiel im Klartext angegebenen Schlüssel verschlüsselt. Interessant, Kunden ID wird als Salt für den Index in das Schlüsselarray verwendet. Der Schlüssel ist ein 256-Byte-Array, das in jedem Beispiel, auf das wir gestoßen sind, identisch war. Zusätzlicher Inhalt der Konfigurationsdatei wird durch Multi-Byte-XOR mit dem Wert von verschlüsselt Geheimer Schlüssel als seinen Schlüssel.

C&C-Kommunikation

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

HTTP

In einer Endlosschleife sendet die Hintertür eine GET-Anforderung an den C&C-Server und fordert einen zu erteilenden Befehl auf. Die verschlüsselte Antwort wird von der Hintertür entschlüsselt, die den Befehl verarbeitet, und schreibt die Befehlsausgabe in eine Datei, deren Inhalt dann per POST-Anfrage an den C&C-Server gesendet wird.

Das Format der GET-Anfragen ist wie folgt:

Beachten Sie, dass die Anforderung mithilfe der gleichnamigen Konfigurationsfelder erstellt wird.

In der Antwort des C&C-Servers ist das dritte Byte des Inhalts die Befehlskennung, die den von der Hintertür zu verarbeitenden Befehl angibt. Wir nennen es Befehls-ID. Der restliche Inhalt der Antwort wird als Argument an den verarbeiteten Befehl übergeben. Dieser Inhalt wird mit dem in Abbildung 6 gezeigten Algorithmus verschlüsselt. Aufgaben-ID der Wert des nach ihm benannten Cookies ist CookieTaskId's-Wert aus der Konfiguration.

Abbildung 6. Verschlüsselungsalgorithmus für angeforderte Inhaltsdaten

Die Antwort des C&C-Servers enthält außerdem ein weiteres Cookie, dessen Name von der Hintertür angegeben wird CookieTerminalId Konfigurationsvariable. Der Wert dieses Cookies wird in der POST-Anforderung von der Hintertür wiederholt und darf nicht leer sein. Nach Ausführung des Backdoor-Befehls sendet PowHeartBeat das Ergebnis als POST-Request an den C&C-Server. Das Ergebnis wird als Datei mit dem Namen gesendet .png.

ICMP

Ab Version 2.4 von PowHeartBeat wurde HTTP durch ICMP ersetzt, wobei Pakete mit einem Timeout von sechs Sekunden versendet wurden unfragmentiert. Die Kommunikation über ICMP ist höchstwahrscheinlich eine Möglichkeit, der Erkennung zu entgehen.

Es gibt keine größeren Änderungen in den Versionen 2.4 und höher, aber wir haben einige Änderungen im Code bemerkt:

• PowHeartBeat sendet bei jeder Schleife, die den String enthält, ein Heartbeat-Paket abcdefghijklmnopqrstuvwxyz, bevor Sie einen Befehl anfordern. Dies informiert den C&C-Server darüber, dass die Hintertür bereit ist, Befehle zu empfangen.
• Anfragen zum Abrufen von Befehlen, die von der Hintertür ausgeführt werden, enthalten die Zeichenfolge abcdefghijklmnop.

Heartbeat-Pakete haben das in Abbildung 7 beschriebene Format.

Abbildung 7. Layout des Heartbeat-Pakets

Die Differenz zwischen Kunden ID und Client-Flag ist, dass Kunden ID unterscheidet sich in jeder Probe, während Client-Flag ist in jeder Probe, die ICMP verwendet, gleich. Herzschlag-Flagge zeigt an, dass die Backdoor einen Heartbeat sendet. Die Antwort vom C&C-Server hat das in Abbildung 8 beschriebene Format.

Abbildung 8. Antwortlayout des C&C-Servers

Flagge Hier wird angezeigt, ob ein Befehl an die Hintertür ausgegeben werden muss. Anforderungen zum Abrufen von Befehlen haben das in Abbildung 9 beschriebene Format.

Abbildung 9. Layout für Anfragen zum Abrufen von Befehlen

Beachten Sie, dass der ICMP-Modus der Hintertür den Empfang einer unbegrenzten Menge an Daten, aufgeteilt in Chunks, und die Variablen ermöglicht Datenlänge, aktuelle Position und Gesamtlänge werden verwendet, um die übertragenen Daten nachzuverfolgen. Antworten auf diese Anforderungen haben das in Abbildung 10 beschriebene Format.

Abbildung 10. Layout von Antworten auf Anfragen zum Abrufen von Befehlen

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

Nach sieben aufeinanderfolgenden ICMP-Antworten mit leerem oder inkonsistent formatiertem Inhalt gelten Übertragungen zwischen Backdoor und C&C-Server als abgeschlossen.

In Bezug auf die Anforderungen zum Senden des Ergebnisses des ausgegebenen Befehls an den C&C-Server wird der Servermodus in den Postmodus geändert und die letzte Zeichenfolge (abcdefghijklmnop) wird für die Ergebnisdaten geändert.

Backdoor-Befehle

PowHeartBeat hat verschiedene Fähigkeiten, einschließlich Befehls-/Prozessausführung und Dateimanipulation. Tabelle 2 listet alle Befehle auf, die von den verschiedenen analysierten Beispielen unterstützt werden.

Tabelle 2. PowHeartBeat-Befehlsbeschreibungen

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

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

PNGLoad: Steganografischer Lader

PNGLoad ist die Nutzlast der zweiten Stufe, die von Worok auf kompromittierten Systemen bereitgestellt und laut ESET-Telemetrie entweder von CLRLoad oder PowHeartBeat geladen wird. Obwohl wir keinen Code in PowHeartBeat sehen, der PNGLoad direkt lädt, hat die Hintertür die Möglichkeit, zusätzliche Payloads vom C&C-Server herunterzuladen und auszuführen, was wahrscheinlich dazu führt, dass die Angreifer PNGLoad auf Systemen eingesetzt haben, die mit PowHeartBeat kompromittiert wurden. PNGLoad ist ein Ladeprogramm, das Bytes aus PNG-Dateien verwendet, um eine auszuführende Nutzlast zu erstellen. Es ist eine ausführbare 64-Bit-.NET-Datei – verschleiert mit .NET Reactor – die sich als legitime Software ausgibt. Abbildung 11 zeigt beispielsweise die CLR-Header eines Beispiels, das sich als WinRAR-DLL tarnt.

Abbildung 11. Beispiel einer gefälschten WinRAR-DLL

Nach der Entschleierung ist nur noch eine Klasse vorhanden. In dieser Klasse gibt es eine Hauptpfad Attribut, das den Verzeichnispfad enthält, den die Backdoor einschließlich ihrer Unterverzeichnisse nach Dateien mit a durchsucht . Png Erweiterung, wie in Abbildung 12 gezeigt.

Abbildung 12. . Png Dateiauflistung

. . Png Datei, die durch diese Suche gefunden wurde Hauptpfad wird dann auf steganographisch eingebettete Inhalte geprüft. Zuerst wird das niedrigstwertige Bit der Werte R (Rot), G (Grün), B (Blau) und A (Alpha) jedes Pixels abgerufen und in einem Puffer zusammengestellt. Sollten die ersten acht Bytes dieses Puffers mit der in Abbildung 13 gezeigten magischen Zahl übereinstimmen und der nächste Acht-Byte-Wert, control, nicht null sein, besteht die Datei die steganografische Inhaltsprüfung von PNGLoad. Bei solchen Dateien wird die Verarbeitung mit dem Rest des Puffers fortgesetzt, der mit einem Mehrbyte-XOR entschlüsselt wird, wobei der in PNGLoad gespeicherte Schlüssel verwendet wird SecretKeyBytes -Attribut, und dann 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 erstellt . Png Dateien

Interessanterweise werden von PNGLoad ausgeführte Operationen in einer Datei protokolliert, deren Pfad in der Variablen gespeichert ist Protokolldateipfad. Operationen werden nur protokolliert, wenn eine Datei vorhanden ist, deren Pfad durch die interne Variable angegeben wird IfLogFilePath.

Eine Probe konnten wir nicht beschaffen . Png Datei, die zusammen mit PNGLoad verwendet wird, aber die Funktionsweise von PNGLoad legt nahe, dass es mit gültigen PNG-Dateien funktionieren sollte. Um die schädliche Nutzlast zu verbergen, verwendet Worok Bitmap-Objekte in C#, die nur Pixelinformationen aus Dateien entnehmen, nicht die Dateimetadaten. Das bedeutet, dass Worok seine bösartigen Payloads in gültigen, harmlos aussehenden PNG-Bildern verstecken und sich so vor aller Augen verstecken kann.

Zusammenfassung

Worok ist eine Cyberspionage-Gruppe, die ihre eigenen Tools entwickelt und vorhandene Tools nutzt, um ihre Ziele zu kompromittieren. Wir glauben, dass die Betreiber Informationen von ihren Opfern stehlen wollen, weil sie sich auf hochkarätige Unternehmen in Asien und Afrika konzentrieren und auf verschiedene Sektoren abzielen, sowohl private als auch öffentliche, aber mit besonderem Schwerpunkt auf Regierungsbehörden. Aktivitätszeiten und Toolset weisen auf mögliche Verbindungen zu TA428 hin, aber wir treffen diese Einschätzung mit geringem Vertrauen. Ihr benutzerdefiniertes Toolset umfasst zwei Loader – einen in C++ und einen in C# .NET – und eine PowerShell-Hintertür. Obwohl unsere Sichtbarkeit begrenzt ist, hoffen wir, dass die Aufklärung dieser Gruppe andere Forscher dazu ermutigt, Informationen über diese Gruppe auszutauschen.

IOCs

Mappen

Dateipfade

Einige der Hauptpfad, Protokolldateipfad und IfLogFilePath Werte, die wir in PNGLoad-Beispielen gefunden haben:

Netzwerk

Mutexe

In CLRLoad-Beispielen sind die Mutex-Namen, auf die wir gestoßen sind:

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

Eine umfassende Liste von Indicators of Compromise (IoCs) und Beispielen finden Sie in unser GitHub-Repository.

MITRE ATT&CK-Techniken

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