Neue Backdoor: Kein „Game Over“ für Winnti-Gruppe

Im Februar 2020 entdeckten wir eine neue, modulare Backdoor und gaben dieser den Namen „PipeMon“. Als persistenter Druckprozessor, wurde diese von der Winnti-Gruppe gegen verschiedene Video Gaming Unternehmen aus Südkorea und Taiwan eingesetzt. Die von den Unternehmen entwickelten MMO Games finden sich auf bekannten Gaming Plattformen wieder und haben tausende simultan miteinander spielende Gamer.

In mindestens einem Fall konnten die Malware-Operatoren das Build-System kompromittieren, was in einen Supply-Chain-Angriff hätte münden können. Dabei schleusen Angreifer ihre schädliche Malware direkt in die Executables eines Spiels ein. In einem anderen Fall wurden die Gaming Server attackiert. Hier hätten die Angreifer beispielsweise die in-Game-Währung zum eigenen finanziellen Vorteil manipulieren können.

Die seit mindestens 2012 aktive Winnti-Gruppe ist für eine Reihe ausgefeilter Supply-Chain-Angriffe gegen die Software-Industrie verantwortlich. Ihre Attacken führten dazu, dass CCleaner, ASUS LiveUpdate und einige Videospiele als kompromittierte Versionen verbreitet wurden. Zuletzt entdeckten ESET-Forscher, Winnti-Angriffe auf verschiedene Hong Konger Universitäten mit Hilfe von ShadowPad und anderer Malware.

Warum Winnti dahinter steckt

Mehrere Indizien sprechen dafür, dass sich die Winnti-Gruppe hinter dieser PipeMon-Kampagne verbirgt. Einige der C&C-Server tauchten bereits in vergangenen Kampagnen auf. Außerdem fand man schon im Jahr 2019 die Winnti-Malware auf den Servern einiger Unternehmen, die nun auch mit PipeMon kompromittiert wurden.

Neben der Winnti-Malware entdeckte man zudem eine maßgeschneiderten AceHash Binary auf den Systemen anderer Winnti-Opfer. Hierbei handelte es sich um eine Software für das heimliche Sammeln von Anmeldedaten. Diese wurde mit einem wohlbekannten gestohlenen Zertifikat signiert.

Das Zertifikat, welches auch PipeMon-Installer, -Module und andere Tools signierte, steht in Verbindung mit einem Videospiele-Unternehmen, das im Jahr 2018 mithilfe einer Supply-Chain-Attacke durch Winnti kompromittiert wurde.

Die PipeMon-Module wurden interessanterweise unter dem %SYSTEM32%\spool\prtprocs\x64\-Pfad installiert; was in der Vergangenheit dazu diente, die Second Stage des infizierten CCleaners abzusetzen.

Schlussendlich ist die Winnti-Gruppe dafür bekannt, die Software der Build-Umgebung von Entwicklern anzugreifen, um die legitimen Anwendungen der Software-Hersteller zu kompromittieren.

Von Winnti anvisierte Unternehmen

Die in der neuen Kampagne anvisierten Unternehmen gehören Videospiele-Entwickler, die auf MMO-Games spezialisiert sind, mit Sitz in Südkorea und Taiwan. In mindestens einem Fall glückte es, den Angreifern, den Build-Orchestrierungs-Server des Unternehmens lahmzulegen und die Kontrolle über das automatische Build-Systems zu erlangen. Den Eindringlingen war es möglich, schädlichen Code in ausführbare Videospiele-Dateien zu implementieren.

ESET kontaktierte die betroffenen Unternehmen und übermittelte alle relevanten Informationen, um der Kompromittierung zu entgegnen.

Technische Analyse

Unter den kompromittierten Unternehmen fanden wir zwei PipeMon-Varianten. Nur für die häufiger verwendete Backdoor waren wir imstande, die First Stage zu identifizieren. Diese ist maßgeblich für die Installation und Persistenz von PipeMon verantwortlich.

Erste Stufe

Die erste Stufe von PipeMon besteht aus einer kennwortgeschützten ausführbaren RARSFX-Datei, die in den .rsrc-Abschnitt des Startprogramms eingebettet ist. Der Launcher schreibt die RARSFX in setup0.exe in ein Verzeichnis mit einer zufällig generierten ASCII-Zeichenfolge aus acht Zeichen, die sich in dem von GetTempPath zurückgegebenen Verzeichnis befindet. Nach dem Schreiben auf die Festplatte wird die RARSFX mit CreateProcess ausgeführt, indem das Entschlüsselungspasswort in einem Argument wie folgt angegeben wird:

setup0.exe -p*|T/PMR{|T2^LWJ*

Das Passwort ist für jedes Malware-Sample unterschiedlich.

Der Inhalt von RARSFX wird dann nach %TMP%\RarSFX0 entpackt. Dieser enthält folgende Dateien:

• CrLnc.dat – Entschlüsselte Payload
• Duser.dll – Genutzt für UAC Bypass
• osksupport.dll - Genutzt für UAC Bypass
• PrintDialog.dll – Genutzt zur bösartigen Druckprozessor-Initialisierung
• PrintDialog.exe – Legitime Windows Executable genutzt, um PrintDialog.dll zu laden
• setup.dll – Installation DLL
• setup.exe – Main Executable

Im Fall einer Dateinamenkollision erhöht sich die Ziffer am Ende von RarSFX0. In Abhängigkeit vom Installationsprogramm sind nicht unbedingt alle Dateien im Archiv vorhanden.

Die setup.exe wird nach dem Entpacken ohne weitere Argumente ausgeführt. Der einzige Zweck dieser Datei ist das Laden der setup.dll mithilfe von LoadLibraryA. Danach prüft setup.dll ob ein Argument in -x:n-Form (n ist eine Ganzzahl) bereitgestellt wurde. Die Funktionsweise hängt dabei von n ab. Unterstützte Argumente und deren entsprechendes Verhalten sind in Tabelle 1 dargestellt.

setup.exe wird ohne Argumente von RARSFX ausgeführt. Die Executable überprüft, ob sie unter erhöhten Rechten läuft. Ist das nicht der Fall, unternimmt sie den Versuch, diese mithilfe von Access Token Manipulation bei Windows 7 Versionen unter Build 7601 zu erlangen. Ansonsten werden verschiedene UAC Bypass-Techniken ausprobiert, so dass die Installation des Payload-Loaders in eine dieser Techniken gelingt:

• C:\Windows\System32\spool\prtprocs\x64\DEment.dll
• C:\Windows\System32\spool\prtprocs\x64\EntAppsvc.dll
• C:\Windows\System32\spool\prtprocs\x64\Interactive.dll

(Je nach Variante). Wir gelangten an keine Malware-Samples, die auf Interactive.dll zurückgriffen.

Tabelle 1: die von setup.exe unterstützten Argumente und deren entsprechendes Verhalten

Der Loader ist innerhalb von setup.dll verschlüsselt gespeichert und wird vor der Speicherung an zuvor genannten Ort entschlüsselt.

Persistenz mit Windows-Druckprozessoren

Der Ort, an dem die bösartige DLL abgelegt wird, ist nicht zufällig gewählt. Es handelt sich um den Pfad, an dem sich die Windows-Druckprozessoren befinden. Hier registriert setup.dll auch den schädlichen Loader als alternativen Druckprozessor, mithilfe einer der folgenden Registry-Werte:

HKLM\SYSTEM\ControlSet001\Control\Print\Environments\Windows x64\Print Processors\PrintFiiterPipelineSvc\Driver = “DEment.dll”

Oder

HKLM\SYSTEM\CurrentControlSet\Control\Print\Environments\Windows x64\Print Processors\lltdsvc1\Driver = “EntAppsvc.dll”

(Je nach Variante). Man beachte den Typo in \PrintFiiterPipelineSvc\ (was aber keinen Einfluss auf die Druckprozessor-Installation hat, da jede Bezeichnung zulässig ist).

Nach erfolgreicher Registrierung des Druckprozessors startet PipeMon den Print Spooler Service (spoolsv.exe) neu. Infolgedessen wird der bösartige Druckprozess nun bei jedem Start des Spooler-Diensts geladen. Die Persistenz von PipeMon wir dadurch gewährleistet, dass spoolsv.exe bei jedem PC-Start ausgeführt wird.

Diese Technik ähnelt der Print Monitor Persistence Technique, die DePriMon nutzte, und die nach unserem Wissen bisher noch nicht genauer beleuchtet wurde.

Zusätzlich wird die verschlüsselte Payload CrLnc.dat, die aus RARSFX extrahiert wird, je nach Installationsprogramm in die Registry an folgender Stelle geschrieben:

• HKLM\SOFTWARE\Microsoft\Print\Components\DC20FD7E-4B1B-4B88-8172-61F0BED7D9E8
• HKLM\SOFTWARE\Microsoft\Print\Components\A66F35-4164-45FF-9CB4-69ACAA10E52D

Die verschlüsselte Registry-Payload wird dann von der zuvor registrierten Druckprozessors-DLL geladen, entschlüsselt und ausgeführt. Die gesamte PipeMon-Bereitstellung und -Persistenz ist in Abbildung 1 dargestellt.

Abbildung 1: PipeMon Staging und Persistenz

PipeMon

Wir gaben dieser neuen Malware, den Namen PipeMon, da mehrere Pipes für die Kommunikation zwischen den Modulen verwendet werden. Gemäß des PDB-Pfads lautet der Name des von seinen Entwicklern verwendeten Visual Studio-Projekts "Monitor".

Wie eingangs bereits erwähnt, wurden zwei verschiedene PipeMon-Varianten gefunden. Bei der ersten Variante konnten wir das Installationsprogramm nicht wiederherstellen; daher wissen wir nicht mit absoluter Sicherheit, welche Persistenz-Technik verwendet wurde. Bedenkt man aber, dass sich diese erste Variante von PipeMon ebenfalls im Verzeichnis des Druckprozessors befand, ist es wahrscheinlich, dass man denselben Persistenz-Mechanismus nutzte.

Originale Variante

PipeMon ist eine modulare Backdoor, bei der jedes Modul aus einer einzelnen DLL besteht, welche die Funktion IntelLoader exportieren. Diese wird mithilfe einer Reflective Loading Technique geladen. Jedes Modul weist unterschiedliche Funktionalitäten auf, die wir in Tabelle 2 darstellen.

Der für das Laden der Hauptmodule (ManagerMain und GuardClient) verantwortliche Loader ist Win32CmdDll.dll. Dieser befindet sich im Druckprozessor-Pfad. Die Module werden auf der Festplatte am gleichen Ort mit harmlos aussehenden Namen wie folgt verschlüsselt:

• banner.bmp
• certificate.cert
• License.hwp
• JSONDIU7c9djE
• D8JNCKS0DJE
• B0SDFUWEkNCj.logN

.hwp ist die Datei-Erweiterung von Hangul Word Processor von Hangul Office, das in Südkorea sehr beliebt ist.

Die Module sind RC4-verschlüsselt. Der Entschlüsselungsschlüssel Com!123Qasdz ist in jedem Modul fest einprogrammiert. Win32CmDll.dll entschlüsselt die Module ManagerMain und GuardClient und schleust diese in entsprechende Programme ein. Das ManagerMain-Modul ist für die Entschlüsselung und Injection des Kommunikationsmoduls verantwortlich, während das GuardClient-Modul dafür sorgt, dass das Kommunikationsmodul läuft, und es bei Bedarf neustartet. Eine Übersicht über die Funktionsweise von PipeMon ist in Abbildung 2 dargestellt.

Die Prozesskandidaten für die Injection von Kommunikationsmodulen müssen sich in der TCP-Verbindungstabelle entweder mit 0.0.0.0 (lokale Adresse) oder einer ESTABLISHED-Verbindung befinden und über ein LOCAL SERVICE-Token verfügen. Diese Bedingungen werden wahrscheinlich verwendet, um das Kommunikationsmodul in einem Prozess zu verstecken, der bereits über das Netzwerk kommuniziert, so dass der Traffic vom Kommunikationsmodul nicht auffällt und möglicherweise auch auf der Whitelist in der Firewall zu finden ist.

Wenn kein Prozess die vorherigen Anforderungen erfüllt, versucht das ManagerMain-Modul, das Kommunikationsmodul in explorer.exe einzuschleusen. Prozesse, die zu den Windows Store Apps gehören, und Prozesse mit den Namen egui.exe (ESET) und avpui.exe (Kaspersky) werden bei der Auswahl ignoriert.

Tabelle 2: PipeMon-Modulbeschreibungen und ihre jeweiligen PDB-Pfade

Zusätzliche Module können bei Bedarf mit Hilfe von dedizierten Befehlen (untenstehend) geladen werden, leider bekamen wir keines davon zu Gesicht. Die Namen dieser Module sind eine wohlbegründete Vermutung auf der Grundlage der benannten Pipes, die zur Kommunikation mit ihnen verwendet wurden:

• Screen
• Route
• CMD
• InCmd
• File

Inter-module Kommunikation

Die Kommunikation zwischen den Modulen erfolgt über Named Pipes, wobei zwei Named Pipes pro Kommunikationskanal zwischen jedem einzelnen Modul verwendet werden, eine zum Senden und eine zum Empfangen. Tabelle 3 listet die Kommunikationskanäle und ihre entsprechenden Pipes auf.

Tabelle 3: PipeMon-Kommunikationskanal und die jeweiligen Named Pipes

Die Zeichenfolge %CNC_DEFINED% wird vom C&C-Server empfangen, die Variablen %B64_TIMESTAMP% sind base64-kodierte Zeitstempel, wie sie in Tabelle 4 dargestellt sind.

Tabelle 4: Beispiele für Zeitstempel bei Named Pipes

Abbildung 2: PipeMon IPC-Schema (originale PipeMon-Variante)

C&C Kommunikation

Das Kommunikationsmodul ist für die Verwaltung der Kommunikation zwischen dem C&C-Server und den anderen Modulen via Named Pipes zuständig, ähnlich wie bei der PortReuse Backdoor, die in unserem Whitepaper über das Winnti-Arsenal dokumentiert ist.

Die C&C-Server-Adresse ist fest im ManagerMain-Modul einprogrammiert und mit dem festcodierten Com!123Qasdz-Key RC4-verschlüsselt. Es wird über eine Named Pipe an das Kommunikationsmodul gesendet.

Für jedes installierte Modul wird ein separater Kommunikationskanal erstellt. Das verwendete Kommunikationsprotokoll ist TLS over TCP. Die Kommunikation wird mithilfe der HP-Socket-Bibliothek abgewickelt. Alle Nachrichten werden mit dem hartkodierten Schlüssel RC4 verschlüsselt. Wenn die Größe der zu übertragenden Nachricht größer oder gleich 4 KB ist, wird sie zunächst mit zlib-Deflate komprimiert.

struct CCMSG
{
    BYTE is_compressed;
    CMD cmd;
};

struct CMD
{
    QWORD cmd_type;
    DWORD cmd_size;
    DWORD cmd_arg;
    BYTE data[cmd_size - 16];
};

struct beacon_msg
{
    BYTE isCompressed = 0;
    CMD cmd_hdr;
    WCHAR win_version[128];
    WCHAR adapters_addrs[128];
    WCHAR adapters_addrs[64];
    WCHAR local_addr[64];
    WCHAR malware_version[64];
    WCHAR computer_name[64];
}

Abbildung 3: C&C-Nachricht und Beacon-Formate

Um die Kommunikation mit dem C&C-Server einzuleiten, wird zunächst ein Beacon gesendet, das die folgenden Informationen enthält:

• OS-Version
• Physische Adresse von angeschlossenen Netzwerkadaptern, mit %B64_TIMESTAMP%
• Lokale IP-Adresse des Opfers
• Backdoor-Version / Campaign ID; wir beobachteten die folgenden Werte
  • "1.1.1.4beat"
  • "1.1.1.4Bata"
  • "1.1.1.5"
• PC-Name des Opfers

Die Informationen über den Computer des Opfers werden vom ManagerMain-Modul gesammelt und über die Named Pipe an das Kommunikationsmodul gesendet. Die Backdoor-Version ist im Kommunikationsmodul im Klartext fest einprogrammiert.

Das Format des Beacons ist in Abbildung 3 dargestellt, die unterstützten Befehle sind in Tabelle 5 aufgeführt.

Tabelle 5: Liste der unterstützten Befehle

Aktualisierte Variante

Wie bereits erwähnt, verwendeten die Angreifer auch eine aktualisierte Version von PipeMon, für die wir die oben beschriebene erste Stufe abrufen konnten. Zwar weist diese Variante eine Architektur auf, die der originalen sehr ähnlich ist, allerdings wurde ihr Code wahrscheinlich von Grund auf neu geschrieben.

Der für die Entschlüsselung der Module und Strings verwendete RC4-Code wurde durch ein einfaches XOR mit 0x75E8EEAF -Key substituiert, alle fest einprogrammierten Strings entfernten die Malware-Entwickler.

Die Named Pipes, die für die Kommunikation zwischen den Modulen verwendet werden, sind nun mit Zufallswerten statt mit expliziten Namen benannt und entsprechen dem Format \\\.\pipe\%rand%, wobei %rand% eine pseudozufällig generierte Zeichenkette von 31 Zeichen ist (nur Buchstaben in gemischter Groß- und Kleinschreibung).

Es wird nur der Main-Loader (d.h. die als Druckprozessor installierte bösartige .DLL) als Datei auf der Festplatte gespeichert; die Module werden vom Installationsprogramm (ausgehend von CrLnc.dat) in der Registry gespeichert und sind in Tabelle 6 beschrieben:

Tabelle 6: Aktualisierte Module

Das Einschleusen von Modulen wird nicht mehr mithilfe von der Reflective Loading Technique mit Exportfunktion durchgeführt. Stattdessen wird maßgeschneiderter Loader-Shellcode verwendet, den man zusammen mit dem zu ladenden Modul einschleust.

Das C&C-Nachrichtenformat wurde ebenfalls geändert, was Abbildung 4 darstellt:

struct CCMSG
{
    BYTE is_compressed;
    CMD cmd;
};

struct CMD
{
    QWORD cmd_type;
    DWORD cmd_size;
    DWORD cmd_arg;
    BYTE data[cmd_size - 16];
};

struct CCMSG
{
    DWORD signature = 0xFA149DEB;
    DWORD not_used;
    WORD buff_size;
    WORD msgcode;
    BYTE buff[buff_size];
};

Abbildung 4: Vorheriges (links) und aktualisiertes (rechts) C&C-Nachrichtenformat

Interessanterweise ist die Backdoor-Konfiguration verschlüsselt und in die Loader-DLL eingebettet. Die Konfiguration enthält:

• Name des Registry-Werts
• Campaign ID
• C&C IP-Adressen oder Domain Names
• Zeitstempel (im FILETIME-Format), der dem Datum entspricht, ab dem eine zweite C&C-Domain, die in der Konfiguration mit '#' gekennzeichnet ist, benutzt werden soll.

Ein Beispiel für einen in die Loader-DLL eingebetteten Konfigurations-Dump ist in Abbildung 5 dargestellt – Konfigurationen, die aus mehreren Loader-DLLs extrahiert wurden in Tabelle 7.

Abbildung 5: Beispiel einer entschlüsselten Konfiguration (einige Null-Bytes wegen Bildgröße entfernt)

Tabelle 7: Aus mehreren Loadern extrahierte Konfiguration

Gestohlenes Code-Signatur-Zertifikat

PipeMon-Module und Installer wurden alle mit dem gleichen validen Code-Signatur-Zertifikat signiert, das wahrscheinlich aus einem Raubzug früherer Winnti-Kampagnen stammte. Der Owner des Zertifikats widerrief es, als er über uns von dem Problem erfuhr.

Abbildung 6: Code-Signatur-Zertifikat zum Signieren der ersten Stufe und der Module von PipeMon

Auf einer Sample Sharing Plattform fanden wir weitere Tools, die mit dem Zertifikat signiert wurden. Dazu gehörten beispielsweise HTRan (ein Connection Bouncer), der WinEggDrop Port Scanner, Netcat und Mimikatz, was die Angreifer möglicherweise auch nutzten.

Auf einigen mit PipeMon kompromittierten Rechnern entdeckten wir außerdem ein maßgeschneidertes AceHash Build, das mit einem von Wemade IO gestohlenen Zertifikat signiert wurde. Darüber berichteten wir bereits in einem zurückliegenden Artikel über Winnti.

Fazit

Wieder einmal steht die Videospiele-Industrie in Asien im Fokus der Winnti-Gruppe. Eine neue modular aufgebaute Backdoor, die mit einem gestohlenen Zertifikat signiert wurde, zeigt einige Ähnlichkeiten zur älteren PortReuse Backdoor. Die Neuentwicklung der Angreifer verdeutlicht, dass die Winnti-Gruppe immer noch aktiv an neuen Tools baut und dabei auf mehrere Open-Source-Projekte zurückgreift; sie verlassen sich also nicht nur auf ihre Flaggschiffe, die ShadowPad- und Winnti-Malware.

ESET-Forscher werden die Winnti Group weiterhin verfolgen und zusätzliche Details bereitstellen, sobald das Team sie findet. Wer glaubt, kompromittiert worden zu sein oder wer weitere Fragen hat, wendet sich bitte an unser Team via  threatintel@eset.com. Die IoCs sind auf GitHub hochgeladen.

Indicators of Compromise

ESET detection names

Win64/PipeMon.A
Win64/PipeMon.B
Win64/PipeMon.C
Win64/PipeMon.D
Win64/PipeMon.E

Filenames

100.exe
103.exe
Slack.exe
setup.exe
%SYSTEM32%\spool\prtprocs\x64\DEment.dll
%SYSTEM32%\spool\prtprocs\x64\EntAppsvc.dll
%SYSTEM32%\spool\prtprocs\x64\Interactive.dll
%SYSTEM32%\spool\prtprocs\x64\banner.bmp
%SYSTEM32%\spool\prtprocs\x64\certificate.cert
%SYSTEM32%\spool\prtprocs\x64\banner.bmp
%SYSTEM32%\spool\prtprocs\x64\License.hwp
%SYSTEM32%\spool\prtprocs\x64\D8JNCKS0DJE
%SYSTEM32%\spool\prtprocs\x64\B0SDFUWEkNCj.log
%SYSTEM32%\spool\prtprocs\x64\K9ds0fhNCisdjf
%SYSTEM32%\spool\prtprocs\x64\JSONDIU7c9djE
%SYSTEM32%\spool\prtprocs\x64\NTFSSSE.log
AceHash64.exe
mz64x.exe

Named pipes

\\.\pipe\ScreenPipeRead%CNC_DEFINED%
\\.\pipe\ScreenPipeWrite%CNC_DEFINED%
\\.\pipe\RoutePipeWriite%B64_TIMESTAMP%
\\.\pipe\MainPipeWrite%B64_TIMESTAMP%
\\.\pipe\MainPipeRead%B64_TIMESTAMP%
\\.\pipe\MainHeatPipeRead%B64_TIMESTAMP%
\\.\pipe\InCmdPipeWrite%B64_TIMESTAMP%
\\.\pipe\InCmdPipeRead%B64_TIMESTAMP%
\\.\pipe\FilePipeRead%B64_TIMESTAMP%
\\.\pipe\FilePipeWrite%B64_TIMESTAMP%
\\.\pipe\ComHeatPipeRead%B64_TIMESTAMP%
\\.\pipe\CMDPipeRead
\\.\pipe\CMDPipeWrite

Registry

HKLM\SYSTEM\ControlSet001\Control\Print\Environments\Windows x64\Print Processors\PrintFiiterPipelineSvc\Driver = “DEment.dll”

HKLM\SYSTEM\CurrentControlSet\Control\Print\Environments\Windows x64\Print Processors\lltdsvc1\Driver = “EntAppsvc.dll”

HKLM\SOFTWARE\Microsoft\Print\Components\DC20FD7E-4B1B-4B88-8172-61F0BED7D9E8

HKLM\SOFTWARE\Microsoft\Print\Components\A66F35-4164-45FF-9CB4-69ACAA10E52D

Samples

First stage

4B90E2E2D1DEA7889DC15059E11E11353FA621A6
C7A9DCD4F9B2F26F50E8DD7F96352AEC7C4123FE
3508EB2857E279E0165DE5AD7BBF811422959158
729D526E75462AA8D33A1493B5A77CB28DD654BC
5663AF9295F171FDD41A6D819094A5196920AA4B

PipeMon

23789B2C9F831E385B22942DBC22F085D62B48C7
53C5AE2655808365F1030E1E06982A7A6141E47F
E422CC1D7B2958A59F44EE6D1B4E10B524893E9D
5BB96743FEB1C3375A6E2660B8397C68BEF4AAC2
78F4ACD69DC8F9477CAB9C732C91A92374ADCACD
B56D8F826FA8E073E6AD1B99B433EAF7501F129E
534CD47EB38FEE7093D24BAC66C2CF8DF24C7D03

PipeMon encrypted binaries

168101B9B3B512583B3CE6531CFCE6E5FB581409
C887B35EA883F8622F7C48EC9D0427AFE833BF46
44D0A2A43ECC8619DE8DB99C1465DB4E3C8FF995
E17972F1A3C667EEBB155A228278AA3B5F89F560
C03BE8BB8D03BE24A6C5CF2ED14EDFCEFA8E8429
2B0481C61F367A99987B7EC0ADE4B6995425151C

Additional tools

WinEggDrop

AF9C220D177B0B54A790C6CC135824E7C829B681

Mimikatz

4A240EDEF042AE3CE47E8E42C2395DB43190909D
FD4567BB77F40E62FD11BEBF32F4C9AC00A58D53

Netcat

751A9CBFFEC28B22105CDCAF073A371DE255F176

HTran

48230228B69D764F71A7BF8C08C85436B503109E

AceHash

D24BBB898A4A301870CAB85F836090B0FC968163

Code-signing certificate SHA-1 thumbprints

745EAC99E03232763F98FB6099F575DFC7BDFAA3
2830DE648BF0A521320036B96CE0D82BEF05994C

C&C domains

n8.ahnlabinc[.]com
owa.ahnlabinc[.]com
ssl2.ahnlabinc[.]com
www2.dyn.tracker[.]com
ssl2.dyn-tracker[.]com
client.gnisoft[.]com
nmn.nhndesk[.]com

C&C IP addresses

154.223.215[.]116
203.86.239[.]113

MITRE ATT&CK techniques