Análisis de la operación de malware como servicio de CastleBot

IBM X-Force ha estado investigando una infraestructura de malware emergente llamada CastleBot. Se cree que el malware forma parte de una operación de malware como servicio (MaaS) y está diseñado específicamente para un despliegue flexible de malware. Actualmente, los delincuentes cibernéticos utilizan CastleBot para entregar de todo, desde infostealers hasta puertas traseras como NetSupport y WarmCookie, que se han relacionado con ataques de ransomware.

Lo que hace que CastleBot sea particularmente preocupante es cómo se distribuye: la mayoría de las veces a través de instaladores de software troyanos descargados de sitios web falsos, que atraen a los usuarios desprevenidos para que lancen la infección ellos mismos. Esta técnica es parte de una tendencia creciente que está observando X-Force. A menudo se habilita a través del envenenamiento de SEO, lo que hace que las páginas maliciosas ocupen un lugar más alto en los motores de búsqueda que los distribuidores de software legítimos. Una vez dentro, CastleBot ejecuta un proceso de tres etapas: un organizador/descargador, un cargador y una puerta trasera central, que solicita un conjunto de tareas de su servidor de comando y control (C2). La información recopilada de la máquina infectada permite a los operadores filtrar fácilmente a las víctimas, gestionar las infecciones en curso y desplegar malware en objetivos de alto valor con precisión.

CastleBot aún está evolucionando, y nuestra investigación muestra que es probable que recién esté comenzando. En este informe, desglosamos cómo funciona, cómo se propaga y por qué es importante.

• CastleBot es un nuevo malware que probablemente funciona como malware como servicio y que puede utilizarse para distribuir una amplia gama de cargas maliciosas.
• Las cargas útiles de seguimiento van desde infostealers hasta puertas traseras vinculadas a ataques de ransomware, como NetSupport y WarmCookie
• X-Force observó que los instaladores de software troyano eran el vector de infección más común para distribuir CastleBot.
• La infraestructura de CastleBot abarca tres componentes: un stager, un cargador y un núcleo, y parece estar en desarrollo activo
• El malware parece permitir a los operadores filtrar fácilmente a las víctimas, actualizar las cargas útiles y gestionar múltiples campañas a lo largo de su ciclo de vida

CastleBot apareció por primera vez a principios de 2025. X-Force notó un aumento en el volumen de muestras y diferentes cargas útiles a partir de mayo, y desde entonces ha observado el despliegue de varias cargas útiles de puerta trasera e infostealer. El vector de infección más común de CastleBot es el software troyano, que forma parte de una tendencia que X-Force continúa observando desde 2024. Los paquetes de software e instaladores troyanos suelen distribuirse a través de sitios web falsos que utilizan técnicas de envenenamiento por SEO para atraer a las víctimas. CastleBot también se distribuía a través de repositorios de GitHub, haciéndose pasar por software legítimo, y mediante la popular técnica ClickFix.

X-Force identificó tres componentes como parte de la infraestructura de malware CastleBot: un escenario, un cargador y el núcleo/puerta trasera de CastleBot.

Tenga en cuenta que los informes públicos anteriores de Prodraft se refieren al mismo marco de malware que “CastleLoader”.

En la mayoría de los casos, el componente central de CastleBot se despliega a través de un shellcode stager, que forma parte de la misma familia de malware CastleBot. El stager es una carga útil de shellcode ligera que puede inyectar cualquier otro cargador de primera etapa. X-Force observó varios encriptadores utilizados con CastleBot, incluido Dave, un encriptador basado en AutoIt, y encriptadores simples compilados en C.

El malware utiliza el algoritmo hash DJB2 para resolver las API necesarias en tiempo de ejecución. Antes de cada llamada a la API, carga el DLL correspondiente y atraviesa la Export Address Table (EAT) en busca de la función de la API a través de hashes DJB2 pregenerados. Si la exportación se reenvía a otra DLL, el stager analiza el nombre del DLL, lo carga y resuelve la función mediante GetProcAddress.

Tras la ejecución, el stager descarga dos cargas útiles mediante HTTP con el agente de usuario “Googlebot”. Las rutas de URL son similares entre las muestras y se dirigen al mismo servidor C2 que el componente central de CastleBot.

Ejemplos de URL de descarga:

Ambas cargas útiles se descifran a través de una cadena XOR codificada, en este caso "GySDoSGySDoS" (codificado en UTF-16), revelando un PE (núcleo CastleBot) y un código auxiliar (CastleBot Loader).

Luego, el organizador utiliza VirtualProtect para permitir la ejecución en la pila para la región de memoria que almacena la segunda carga útil de shellcode descifrada. Este último, actuando como cargador, se ejecuta directamente en memoria y recibe un puntero al PE descifrado como argumento.

CastleBot Loader es un cargador de PE con todas las funciones, que comienza asignando cada sección del PE proporcionado a una nueva región de memoria asignada mediante NtAllocateVirtualMemory. A continuación, realiza los arreglos necesarios, resuelve las importaciones, establece las opciones de protección de memoria adecuadas y ejecuta las funciones de devolución de llamada TLS existentes.

En particular, el cargador también configura una nueva estructura LDR_DATA_TABLE_ENTRY y el LDR_DDAG_NODE correspondiente (extendido en Windows 8 y versiones posteriores), que luego se agregan a las listas PEB_LDR_DATA doblemente vinculadas que contienen los módulos cargados para cada proceso. Para los agentes de EDR que monitorean el PEB, esto haría que la carga útil inyectada pareciera más como si estuviera legítimamente cargada por el sistema operativo.

A menos que el archivo inyectado sea un DLL, el campo ImageBaseAddress del PEB también se establece en la dirección base de la carga útil inyectada.

Por último, para ejecutar la carga útil, CastleBot Loader ejecuta el punto de entrada o asigna una nueva consola para aplicaciones de consola.

En la muestra analizada anteriormente, la carga útil inyectada es la puerta trasera CastleBot x86 (202f6b6631ade2c41e4762e5877ce0063a3beabce0c3f8564b6499a1164c1e04).

El núcleo de CastleBot emplea el mismo mecanismo de resolución de API que los componentes del stager y cargador, excepto el algoritmo hash, que es el hash AP, desarrollado por Arash Partow.

Primero, la puerta trasera comienza descifrando su configuración. Casi todas las cadenas en todo el binario, incluidas las que forman parte de la configuración, se almacenan como UTF-16 y se descifran en línea mediante una clave XOR única de 4 bytes para cada cadena. Durante el descifrado, se crea la siguiente estructura de configuración:

El malware intenta crear un mutex, utilizando el nombre de la configuración, para garantizar que solo se ejecute una única instancia. En el siguiente paso, envía una solicitud HTTP GET a la URL codificada para recuperar su configuración, utilizando el ID de campaña en la ruta de la URL:

En respuesta, CastleBot recibe un bloque de datos cifrados.

Toda la comunicación C2 se cifra a través del algoritmo simétrico ChaCha, excepto la solicitud GET inicial del malware. Después del descifrado, el protocolo C2 utiliza una estructura de datos personalizada serializada, internamente denominada contenedor, que puede almacenar valores de diferentes tipos.

En la raíz de la estructura de datos serializada siempre hay un campo de tipo ContainerFieldArray. Las estructuras a continuación definen cómo se configuran los tipos de matriz y bool:

Al analizar el contenedor descifrado que define la configuración solicitada por la puerta trasera, los datos comienzan con el byte 0x0D, que indica el tipo ContainerFieldArray. Ese byte va seguido del nombre del campo, que a su vez es la longitud de 2 bytes seguida del nombre codificado en UTF-16. Después del nombre, un campo de matriz define una longitud de 4 bytes de los datos, seguido de los datos en sí, que nuevamente comienzan con el primer byte que define el tipo.

La configuración recibida por la muestra analizada anteriormente se analiza de la siguiente manera.

Datos serializados:

Objeto deserializado:

Para cada configuración habilitada, CastleBot realiza las siguientes acciones:

run_as_admin: el malware ejecutará su proceso principal a través de "cmd.exe /c <parent_process>" mediante ShellExecuteW con el verbo "runas" para lanzarlo como administrador.

anti_vm: CastleBot utilizará la instrucción cpuid con la hoja 0x40000000 para intentar detectar entornos de hipervisor. Si se descubre VMware o Parallels, el malware desaparecerá.

prevent_restart: CastleBot creará un nuevo archivo oculto en %PROGRAMDATA% con el nombre que coincida con el nombre del mutex integrado en la configuración. Si el archivo ya existe, el malware se cerrará.

show_fake_error: el malware muestra un cuadro de mensaje "Error de Sistema" con el mensaje "El programa no puede iniciarse porque falta VCRUNTIME140.dll en el equipo. Intente reinstalar el programa para arreglar este problema".

En el siguiente paso, CastleBot recopila información sobre el host infectado para registrarse en el servidor C2 y solicitar tareas.

• Nombre de usuario a través de GetUserNameW
• Nombre NetBIOS a través de GetComputerNameW
• Arquitectura del sistema a través de IsWow64Process
• Nombre de dominio DNS local, a través de LsaQueryInformationPolicy para recuperar la estructura PolicyDnsDomainInformation. El valor predeterminado es "WORKGROUP".
• Número de serie del volumen recuperado a través de GetVolumeInformationW.CastleBot lo utiliza para calcular una ID de víctima única mediante un generador lineal congruente (LCG) con un multiplicador de 0x41C64E6D y un sumando de 0x3039.
• Versión de Windows a través de RtlGetVersion y GetSystemMetrics(89)

La información se compila en el siguiente objeto, seguida de la serialización y el cifrado ChaCha:

Los valores codificados son la clave de acceso (idéntica al Usuario-Agente de la configuración), el identificador de campaña y la versión de compilación de CastleBot, que es "1.0" para la muestra analizada.

La puerta trasera envía los datos cifrados en una solicitud HTTP POST a

 La respuesta es un contenedor cifrado más grande que contiene las tareas preconfiguradas de CastleBot.

El contenedor recibido del servidor C2 por la muestra de CastleBot analizada se descifra y deserializa en un objeto con los siguientes campos:

El campo "tareas" es un tipo personalizado de matriz como se detalla anteriormente, que contiene al menos una matriz sin nombre (nombre de longitud cero), cada una de las cuales representa una tarea. CastleBot también puede recibir una matriz con múltiples tareas que se llevarán a cabo una tras otra. Cada tarea contiene un ID y varios campos que detallan cómo se ejecutará la tarea, que se copian en una estructura de tareas durante la deserialización.

El campo más importante de cada tarea es "launch_method", que determina el tipo de carga útil que manejará CastleBot.

Los otros campos pueden utilizarse para establecer opciones específicas para la ejecución de la tarea:

CastleBot admite la inyección de procesos simples para cargas útiles de PE. Comienza creando un nuevo proceso suspendido, basado en la ruta de instalación y los campos de argumentos. Para trabajar en Windows 11 24H2 y versiones posteriores, los desarrolladores de malware optaron por conectar la función NtManageHotPatch de NTDLL en la memoria para eludir la comprobación de memoria recién agregada. Vea la publicación de Hasherezade para saber más detalles, que también proporciona la implementación POC exacta empleada por CastleBot:

El resto de la inyección del proceso sigue técnicas comunes asignando memoria en el proceso destino, escribiendo las secciones en el búfer y modificando el contexto del hilo antes de reanudar la ejecución.

Si el campo del método de inicio se establece en "1", CastleBot establece la persistencia creando una tarea programada. Para registrar la tarea, el malware utiliza la interfaz COM de ITaskService para conectarse al servicio del Programador de tareas. Crea una nueva tarea y una acción de ejecución para la carga útil de destino, que se activa cada vez que el usuario actual inicia sesión (TASK_TRIGGER_LOGON).

Cada tarea en el contenedor "tasks" se maneja iterativamente de acuerdo con sus campos especificados. Una vez que una tarea se ha completado sin errores, el malware informa de la ejecución exitosa a través de una solicitud HTTP GET a:

X-Force observó una variante central actualizada de CastleBot, que admite nuevos métodos de lanzamiento y una opción llamada "wow64_bypass", utilizada para lanzar específicamente binarios del sistema de 32 bits en la carpeta SysWOW64.

La implementación adicional de inyección de procesos (método de lanzamiento 6) escribe tanto el componente CastleBot Loader (consulte la sección de análisis anterior) como la carga útil de PE en el proceso de destino. A continuación, utiliza QueueUserAPC y ResumeThread para transferir la ejecución al cargador, que carga correctamente la carga útil PE en la memoria y la ejecuta.

Esta técnica utiliza un número significativamente menor de llamadas a la API WriteProcessMemory y proporciona una funcionalidad de carga más completa desde el stub CastleBot Loader.

El objetivo principal de CastleBot es permitir el despliegue de cargas útiles secundarias en las máquinas víctimas. X-Force descubrió varias cargas útiles diferentes distribuidas por CastleBot, a menudo con múltiples cargas útiles en una sola campaña. Las cargas útiles varían en sofisticación, desde infostealers de productos básicos hasta puertas traseras más capaces, como NetSupport o WarmCookie, que se han relacionado con ataques de ransomware.

El marco CastleBot MaaS parece permitir a los operadores filtrar máquinas infectadas y actualizar fácilmente las cargas útiles para gestionar múltiples campañas activas con gran flexibilidad, según el análisis y las capturas de pantalla de Prodaft del panel C2. Con la fluidez de las cargas útiles y la capacidad del operador para agregar múltiples tareas y cargas útiles a una sola campaña, las cadenas de infección de CastleBot son más complejas en comparación con las etapas de malware tradicionalmente estáticas.

X-Force no tiene ninguna evidencia de un anuncio generalizado de MaaS en la dark web, lo que podría indicar que el servicio actualmente solo se vende a un grupo privado de afiliados.

Sin identificar el malware como su propia infraestructura, otros investigadores informaron públicamente sobre varios fragmentos de las campañas que condujeron a NetSupport en junio y julio de 2025.

DomainTools observó páginas falsas de DocuSign que emplean la técnica ClickFix para ejecutar un script malicioso de PowerShell, que a su vez descarga CastleBot para desplegar NetSupport. IoC de la campaña:

Unit42 de Palo Alto informó actividad similar con sitios web que imitan a DocuSign y Okta, empleando ClickFix para implementar CastleBot a través de los componentes iniciales de preparación y carga. Contiene un análisis parcial de un "NetSupport RAT Loader", que X-Force identifica como el marco CastleBot. IoC de la campaña:

Una de las cargas útiles más interesantes de CastleBot es la puerta trasera WarmCookie (también conocida como Quickbind, BadSpace). Probablemente forme parte de un ecosistema de delito cibernético más amplio que permite los ataques de ransomware y fue una de las familias de malware contra las que actuaron con éxito las fuerzas del orden internacionales durante la Operación Endgame en 2024. Anteriormente, el actor de amenazas Hive0137 distribuyó WarmCookie mediante campañas de correo electrónico maliciosas, aunque no se observó actividad significativa en 2025, según la visibilidad de X-Force. WarmCookie está públicamente vinculado a las operaciones TA866/Asylum Ambuscade.

La campaña que X-Force observó comenzó en junio con un archivo ZIP armado que imitaba un instalador para un software legítimo SSMS-20.2-enu.zip (4766f5cc6501fc40c7151a0ce1c9d2cc49fca9b0b9cab2a206dd2426947e9afe). Entre los componentes legítimos, contiene un ejecutable malicioso SSMS_Windows.x64.exe (05ecf871c7382b0c74e5bac267bb5d12446f52368bb1bfe5d2a4200d0f43c1d8) identificado como una variante de Dave Loader, que descifra una carga útil almacenada dentro de sus recursos. Tras el descifrado, Dave Loader inyecta la puerta trasera de CastleBot (202f6b6631ade2c41e4762e5877ce0063a3beabce0c3f8564b6499a1164c1e04), que recibe la tarea de descargar y ejecutar una carga útil WarmCookie (5bca7f1942e07e8c12ecd9c802ecdb96570dfaaa1f44a6753ebb9ffda0604cb4) de

El servidor C2 de WarmCookie se encuentra en:

Una segunda muestra encontrada más tarde en junio utilizó un ejecutable similar, imitando un instalador para el software Zscaler Zscaler-windows-4.4.0.379-installer-x64.exe (bf21161c808ae74bf08e8d7f83334ba926ffa0bab96ccac42dde418270387890). El binario compilado por AutoIt es un simple cargador de shellcode, que ejecuta el stager CastleBot incrustrado, que a su vez descarga el mismo binario de puerta trasera de CastleBot (202f6b6631ade2c41e4762e5877ce0063a3beabce0c3f8564b6499a1164c1e04).

Las ejecuciones de sandbox de la muestra principal de CastleBot indican que el mismo afiliado puede haber dejado caer una carga útil de StealC con un servidor C2 en “http://107.158.128[.]105/c91252f9ab114f26.php” durante la campaña; sin embargo, X-Force no pudo recuperar una muestra. 

Ambas campañas utilizan el ID de campaña de CastleBot "81a16c72f9c9f4ea94d68b609c78f72d4a8725e7b8f6949b12d8871b6c6843e3".

Además, X-Force está rastreando múltiples campañas de CastleBot que ofrecen varios infostealers. El malware admite múltiples tareas de descarga para cualquier campaña, lo que dará como resultado el despliegue de múltiples cargas útiles en el mismo cliente. El ejecutable AMD_Chipset_DriverOnly_DCH_AMD_Z_V1.2.0.105_20238.exe (e6aab1b6a150ee3cbc721ac2575c57309f307f69cd1b478d494c25cde0baaf85) carga la carga útil del núcleo CastleBot incrustrado (b45cce4ede6ffb7b6f28f75a0cbb60e65592840d98dcb63155b9fa0324a88be2) desde su recurso y lo ejecuta. El endpoint de configuración del servidor C2 se encuentra en

que se encontró que transmitía un total de tres tareas separadas en un solo mensaje C2, cada una de las cuales desplegaba una carga útil diferente:

• ID de tarea: 0x16
• • URL de descarga: https[:]//google.herionhelpline[.]com/aplicación/AcerUSBUpdate.exe
  • Carga útil: 03122e46a3e48141553e7567c659642b1938b2d3641432f916375c163df819c1 (Rhadamanthys)
  • Ruta de instalación: Ninguna
  • Método de lanzamiento: 6

• ID de tarea: 0x17 
• • URL de descarga: https[:]//google.herionhelpline[.]com/app/light1_v5_signed.html
  • Carga útil: 12de997634859d1f93273e552dec855bfae440dcf11159ada19ca0ae13d53d53dff (Remcos)
  • Ruta de instalación: %ProgramData%\AmazonApp\AmazonWebServiceUpdate.exe
  • Método de lanzamiento: 1

• ID de tarea: 0x18
• • https[:]//google.herionhelpline[.]com/app/SlackUpdateWeb.html
  • Carga útil: c8f95f436c1f618a8ef5c490555c6a1380d018f44e1644837f19cb71f6584a8a (DeerStealer)
  • Ruta de instalación: %AppData%\SlackUpdate\SlackServiceUpdate.exe
  • Método de lanzamiento: 1

X-Force descubrió además campañas que desplegaron SecTopRAT (también conocido como ArechClient), HijackLoader (también conocido como Shadowladder) y MonsterV2 (también conocido como Aurotun Stealer) 

SecTopRAT y HijackLoader:

• GlobalProtect-win-6.3.zip con msvcp140.dll ejecutable de carga lateral (8bf93cef46fda2bdb9d2a426fbcd35ffedea9ed9bd97bf78cc51282bd1fb2095)
• Servidor CastleBot C2: http[:]//107.158.128[.]45/service/settings/81a16c72f9c9f4ea94d68b609c78f72d4a8725e7b8f6949b12d8871b6c6843e3
• Carga útil alojada en http[:]//107.158.128[.]45/service/download/Exchanger32.zip (4834bc71fc5d3729ad5280e44a13e9627e3a82fd4db1bb992fa8ae52602825c6)

MonsterV2:

• libssl-1_1.dll (53dddae886017fbfbb43ef236996b9a4d9fb670833dfa0c3eac982815dc8d2a5) DLL cargado lateralmente, inyecta de forma reflexiva el stager CastleBot.
• Servidor CastleBot C2: http[:]//107.158.128[.]45/service/settings/8306a6b35d4be6de72be58860791e3644468fd67f675e4045a246dd27fa5692c
• Carga útil alojada en http[:]//107.158.128[.]45/service/download/CCver_Setup.exe (ab725f5ab19eec691b66c37c715abd0e9ab44556708094a911b84987d700aa62)

CastleBot es la última evidencia de un cambio en los vectores de infección iniciales del escenario de delito cibernético. Las puertas traseras y las infraestructuras MaaS se distribuyen cada vez más a través de sitios web falsos como parte de software troyano o mediante la técnica ClickFix. A los pocos meses de observar un aumento en la actividad de CastleBot, los desarrolladores ya agregaron varias características nuevas y probablemente intentarán mantenerse al día con la adaptación de las soluciones de seguridad de red y EDR. La actividad actual sugiere que múltiples afiliados utilizan CastleBot para desplegar infostealers y puertas traseras, lo que puede conducir a incidentes de ransomware de alto impacto.

Se recomienda a los defensores que permanezcan atentos a las técnicas mencionadas en este informe y tomen las medidas adecuadas para mitigar el riesgo de una infección de CastleBot.

• Cerciorarse de que el software EDR y los controles de seguridad asociados estén actualizados
• Capacite a los usuarios para que tengan mucho cuidado al descargar software y se abstengan de instalar software no autorizado o no verificado
• Implemente la autenticación multifactorial y supervise las credenciales empresariales filtradas
• Configure alertas o considere bloquear las conexiones HTTP (no HTTPS) salientes y las URL que contienen direcciones IP en particular

IBM X-Force Premier Threat Intelligence ahora está integrado con OpenCTI de Filigran, lo que proporciona inteligencia de amenazas aplicable en la práctica sobre esta actividad maliciosa y mucho más. Acceda a insights sobre actores de amenazas, malware y riesgos de la industria. Instale el OpenCTI Connector de X-Force para mejorar la detección y la respuesta, reforzando su ciberseguridad con la experiencia de IBM X-Force. ¡Obtenga una prueba de 30 días de X-Force Premier Threat Intelligence hoy mismo!