Disección de la operación CastleBot Malware-as-a-Service

IBM X-Force ha estado investigando un nuevo marco de malware emergente llamado CastleBot. Se cree que el malware forma parte de una operación de malware como servicio (MaaS) y está diseñado específicamente para la implementación flexible de malware. Actualmente, los ciberdelincuentes utilizan CastleBot para distribuir todo tipo de programas, desde infostealers hasta puertas traseras como NetSupport y WarmCookie, que se han relacionado con ataques de ransomware.

Lo que hace que CastleBot sea especialmente preocupante es su forma de distribución: en la mayoría de los casos, a través de instaladores de software troyanizados descargados de sitios web falsos que atraen a usuarios desprevenidos para que ellos mismos lancen la infección. Esta técnica forma parte de una tendencia creciente que X-Force está observando. A menudo se activa a través del envenenamiento SEO, que hace que las páginas maliciosas se posicionen 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 las víctimas, gestionar las infecciones en curso e implementar el malware en objetivos de alto valor con precisión.

CastleBot sigue evolucionando y nuestra investigación muestra que es probable que solo 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, que puede utilizarse para entregar 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
• El marco CastleBot consta de tres componentes: un stager, un cargador y un núcleo, y parece estar en fase de 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 observó un aumento en el volumen de muestras y diferentes cargas útiles a partir de mayo, y desde entonces ha observado la implementación 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 el envenenamiento 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 del marco del malware CastleBot: un stager, un cargador y el núcleo/puerta trasera de CastleBot.

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

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

El malware utiliza el algoritmo de hashing DJB2 para resolver las APIs necesarias en tiempo de ejecución. Antes de cada llamada a la API, carga la DLL correspondiente y recorre la tabla de direcciones de exportación (EAT) en busca de la función de la API a través de hashes DJB2 pregenerados via VIA. Si la exportación se reenvía a otra DLL, el stager analiza el nombre de la DLL, la carga y resuelve la función mediante GetProcAddress.

Tras la ejecución, el stager descarga dos cargas útiles a través de HTTP con el agente de usuario "Googlebot". Las rutas de URL son similares entre samples y 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 (CastleBot Core) y un código auxiliar (CastleBot Loader).

A continuación, el organizador utiliza VirtualProtect para permitir la ejecución en el montón de 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, corrige las reubicaciones necesarias, resuelve las importaciones, establece las opciones de protección de memoria adecuadas y ejecuta las funciones de devolución de llamada TLS existentes.

Cabe destacar que el cargador también configura una nueva estructura de LDR_DATA_TABLE_ENTRY y los LDR_DDAG_NODE correspondientes (extendidos en Windows 8 y posteriores), que luego se añaden a las listas PEB_LDR_DATA doblemente enlazadas que contienen los módulos cargados de cada proceso. Para los agentes de EDR que monitorizan el PEB, esto haría que la carga útil inyectada pareciera más como si la hubiera cargado legítimamente el sistema operativo.

A menos que el archivo inyectado sea una 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 el backdoor x86 CastleBot (202f6b6631ade2c41e4762e5877ce0063a3beabce0c3f8564b6499a1164c1e04).

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

En primer lugar, la puerta trasera comienza descifrando su configuración. Casi todas las cadenas del binario, incluidas las que forman parte de la configuración, se almacenan como UTF-16 y se descifran en línea a través de 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, usando el nombre de la configuración, para asegurarse de que solo se ejecute una 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 ChaCha simétrico, excepto la solicitud GET inicial del malware. Tras el descifrado, el protocolo C2 utiliza una estructura de datos personalizada serializada, denominada internamente contenedor, que puede almacenar valores de distintos tipos.

En la raíz de la estructura de datos serializada siempre hay un campo de tipo ContainerFieldArray. Las estructuras siguientes definen con más detalle cómo se configuran los tipos array 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. A ese byte le sigue el nombre del campo, que 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 propios datos, que de nuevo comienzan con el primer byte que define el tipo.

Los ajustes recibidos por la muestra analizada anteriormente se analizan 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 mediante "cmd.exe /c <parent_process>" a través de ShellExecuteW con el verbo "runas" para iniciarlo como administrador.

anti_vm: CastleBot usará la instrucción cpuid con la hoja de 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 incrustado en la configuración. Si el archivo ya existe, el malware saldrá.

show_fake_error: el malware muestra un cuadro de mensaje "System Error" con el mensaje "The program can't start because VCRUNTIME140.dll is missing from your computer. Try reinstalling the program to fix this problem."

En el siguiente paso, CastleBot recopila información sobre el host infectado para registrarla 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 mediante IsWow64Process
• Nombre de dominio DNS local, utilizando LsaQueryInformationPolicy para recuperar la estructura PolicyDnsDomainInformation. El valor predeterminado es "WORKGROUP".
• Número de serie del volumen recuperado mediante GetVolumeInformationW. CastleBot lo utiliza para calcular un identificador único de víctima mediante un generador lineal congruente (LCG) con un multiplicador de 0x41C64E6D y un sumando de 0x3039.
• Versión de Windows mediante 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 agente de usuario 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 "tasks" es un tipo de matriz personalizado, como se ha detallado 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 un array con múltiples tareas que deben realizarse una tras otra. Cada tarea contiene un ID y varios campos que detallan cómo se debe 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 debe gestionar CastleBot.

Los demás 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 poder funcionar en Windows 11 24H2 y posteriores, los desarrolladores del malware optaron por enganchar la función NtManageHotPatch de NTDLL en la memoria para eludir la comprobación de memoria recién añadida. Vea la publicación de Hasherezade para más detalles., que también proporciona la implementación POC exacta utilizada 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 Task Scheduler. 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 del contenedor "tasks" se gestiona de forma iterativa según los campos especificados. Una vez que una tarea se ha completado sin errores, el malware informa de la ejecución exitosa mediante una solicitud HTTP GET a:

X-Force observó una variante básica de CastleBot actualizada, que admitía nuevos métodos de lanzamiento y una opción llamada "wow64_bypass", que se utiliza para lanzar específicamente los 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 muchas menos llamadas a la API WriteProcessMemory y proporciona una funcionalidad de carga más completa desde el stub de CastleBot Loader.

El objetivo principal de CastleBot es permitir la implementación de cargas útiles secundarias en las máquinas víctimas. X-Force descubrió varias cargas útiles diferentes distribuidas por CastleBot, a menudo con varias cargas útiles en una sola campaña. Las cargas útiles varían en sofisticación, desde los robos de información de origen hasta puertas traseras más capaces como NetSupport o WarmCookie, que han estado vinculadas a ataques de ransomware.

El marco CastleBot MaaS parece permitir a los operadores filtrar máquinas infectadas y actualizar fácilmente cargas útiles para gestionar múltiples campañas activas con gran flexibilidad, según el análisis de Prodaft y capturas de pantalla del panel C2. Con la fluidez de las cargas útiles y la capacidad del operador de 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 ningún indicio de una publicidad generalizada del MaaS en la dark web, lo que pueda indicar que el servicio actualmente solo se vende a un grupo privado de filiales.

Sin identificar el malware como su propio marco, 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 de PowerShell malicioso, que a su vez descarga CastleBot para implementar NetSupport. IoC de la campaña:

La Unidad 42 de PaloAlto notificó una actividad similar con sitios web que imitan DocuSign y Okta, usando ClickFix para implementar CastleBot a través del inicial de los componentes de la etapa y el cargador. 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). Es probable que forme parte de un ecosistema de ciberdelincuencia más amplio que permite los ataques de ransomware y fue una de las familias de malware atacadas con éxito por las fuerzas de seguridad internacionales durante la operación Endgame en 2024. Anteriormente, el actor de amenazas Hive0137 distribuyó WarmCookie a través de campañas de correo electrónico malicioso, aunque no se ha observado ninguna actividad significativa en 2025, según la visibilidad de X-Force. WarmCookie está vinculado públicamente a las operaciones de 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. After decryption, Dave Loader injects the CastleBot backdoor (202f6b6631ade2c41e4762e5877ce0063a3beabce0c3f8564b6499a1164c1e04), which receives the task to download and execute a WarmCookie payload (5bca7f1942e07e8c12ecd9c802ecdb96570dfaaa1f44a6753ebb9ffda0604cb4) from

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 con AutoIt es un sencillo cargador de código shell que ejecuta el stager CastleBot incrustado, el cual, a su vez, descarga el mismo binario de puerta trasera CastleBot (202f6b6631ade2c41e4762e5877ce0063a3beabce0c3f8564b6499a1164c1e04).

Las ejecuciones de entorno aislado de la muestra principal de CastleBot indican que el mismo afiliado puede haber soltado 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 generan varios infostealers. El malware admite múltiples tareas de descarga para cualquier campaña, lo que dará como resultado la implementación 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 integrado (b45cce4ede6ffb7b6f28f75a0cbb60e65592840d98dcb63155b9fa0324a88be2) desde su recurso y lo ejecuta. El endpoint de configuración del servidor C2 se encuentra en

que se descubrió que transmitía un total de tres tareas distintas en un solo mensaje C2, cada una de las cuales implementaba 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/aplicación/light1_v5_signed.html
  • Carga útil: 12de997634859d1f93273e552dec855bfae440dcf11159ada19ca0ae13d53dff (Remcos)
  • Ruta de instalación: %ProgramData%\AmazonApp\AmazonWebServiceUpdate.exe
  • Método de lanzamiento: 1

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

X-Force descubrió además campañas que implementan 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 with ejecutable sideloading msvcp140.dll (8bf93cef46fda2bdb9d2a426fbcd35ffedea9ed9bd97bf78cc51282bd1fb2095)
• CastleBot C2 server: http[:]//107.158.128[.]45/service/settings/81a16c72f9c9f4ea94d68b609c78f72d4a8725e7b8f6949b12d8871b6c6843e3
• Payload hosted at http[:]//107.158.128[.]45/service/download/Exchanger32.zip (4834bc71fc5d3729ad5280e44a13e9627e3a82fd4db1bb992fa8ae52602825c6)

MonsterV2:

• libssl-1_1.dll (53dddae886017fbbb43ef236996b9a4d9fb670833dfa0c3eac982815dc8d2a5) DLL-sideloaded, inyecta reflexivamente CastleBot stager
• CastleBot C2 server: http[:]//107.158.128[.]45/service/settings/8306a6b35d4be6de72be58860791e3644468fd67f675e4045a246dd27fa5692c
• Payload hosted at http[:]//107.158.128[.]45/service/download/CCver_Setup.exe (ab725f5ab19eec691b66c37c715abd0e9ab44556708094a911b84987d700aa62)

CastleBot es la última prueba de un cambio en los vectores iniciales de infección en el panorama de amenazas del cibercrimen. Las puertas traseras y los marcos 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. En pocos meses desde que observaron un aumento en la actividad de CastleBot, los desarrolladores ya han añadido varias funciones nuevas y probablemente intentarán adaptar soluciones de EDR y seguridad de red. La actividad actual sugiere que varios afiliados están utilizando CastleBot para implementar tanto infostealers como backdoors, lo que podría provocar 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.

• Asegúrese de que el software EDR y los controles de seguridad asociados estén actualizados
• Entrenar a los usuarios para que ejerzan extrema precaución al descargar software y se abstengan de instalar software no autorizado o no verificado
• Implemente la autenticación multifactor 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 by Filigran, brindando inteligencia de amenazas procesable sobre esta actividad de amenazas y más. Acceda a conocimientos sobre los actores de amenazas, el malware y los riesgos del sector. Instale el X-Force OpenCTI Connector para mejorar la detección y la respuesta, y refuerce su ciberseguridad con la experiencia de IBM X-Force. ¡Obtenga una prueba de 30 días de X-Force Premier Threat Intelligence hoy mismo!