En un servidor Exchange comprometido, la actividad más interesante no siempre es el mensaje que llega a la bandeja de entrada de un usuario.
En alguna oficina de gobierno nacional, un funcionario envía un correo electrónico a un colega de una alianza militar transnacional. El mensaje sale a través de un servidor Microsoft Exchange, exactamente como debería hacerlo, y nada parece sospechoso. Sin embargo, antes de que el correo electrónico salga del edificio, un fragmento de código lo examina discretamente, determina si es de interés y aparta una copia para enviarla a terceros no autorizados, mientras el mensaje original sigue su curso.
El 28 de noviembre de 2025, encontramos el conjunto de herramientas que instala ese código en un servidor Exchange de una organización gubernamental de Kazajistán. Lo que inicialmente parecía un grupo de componentes sospechosos independientes pronto reveló un conjunto de herramientas que no había sido documentado hasta entonces: una colección de malware modular desarrollado en .NET y diseñado para ejecutarse en servidores Microsoft Exchange, recibir comandos, ejecutarlos en memoria, mapear la organización comprometida y recopilar determinados mensajes de correo electrónico. Tras ajustar nuestras detecciones, encontramos el mismo conjunto de herramientas en una organización gubernamental de Rumania —comprometida el 23 de diciembre de 2025—, donde estaba configurado para identificar los correos electrónicos enviados a la Organización del Tratado del Atlántico Norte (OTAN) o recibidos de ella, así como los enviados a la Unión Europea (UE) o recibidos de esta.
Como las herramientas dependen en gran medida de la serialización (una técnica para empaquetar datos y código para su transporte), les hemos asignado nombres que comienzan con el prefijo «Cereal». Lo que distingue a este conjunto de herramientas es la combinación de técnicas novedosas que requieren un conocimiento profundo del funcionamiento interno de Exchange y métodos inusuales de ejecución de .NET.
Uno de los aspectos más interesantes de este conjunto de herramientas es lo que no encontramos: infraestructura externa de comando y control (C&C). En cambio —y para agravar aún más la situación—, el servidor Exchange comprometido de la víctima es reutilizado para funcionar como infraestructura de C&C.
Con un alto grado de confianza, atribuimos Cereal al grupo APT prorruso Turla, basándonos en el uso simultáneo de otro componente vinculado públicamente con Turla y en las similitudes conceptuales con malware anterior del grupo. El análisis técnico completo está disponible en nuestro white paper.
Puntos clave de este artículo:
- Inicialmente observamos un conjunto de herramientas no documentado en una organización gubernamental de Kazajistán. Después de ajustar las detecciones de nuestros productos para estas herramientas, un mes más tarde descubrimos una organización gubernamental comprometida en Rumania.
- Descubrimos un conjunto de herramientas sofisticado, modular y estrechamente interconectado, diseñado para ejecutarse en servidores Exchange de entidades comprometidas con fines de ciberespionaje a largo plazo.
- No observamos infraestructura de red externa. Uno de los componentes maliciosos, un backdoor pasivo que se ejecuta en servidores Exchange, proporciona acceso a la red interna.
- Los operadores envían comandos en forma de ejecutables independientes con una estructura propia y similar. Esto sugiere la existencia de un framework que automatiza la compilación y la entrega de comandos.
- Un módulo automatizado de recopilación de correos electrónicos, inyectado en procesos legítimos de Microsoft Exchange, accede a la canalización de transporte de correo electrónico y la manipula. Esto requiere un conocimiento profundo del funcionamiento interno de Microsoft Exchange y constituye una técnica novedosa.
- El uso de diversos trucos de .NET, como puntos de entrada no administrados (unmanaged entry points) y el abuso de la caché de imágenes nativas de .NET (native image cache), hace que este conjunto de herramientas sea bastante sofisticado en comparación con la mayoría de los casos recientes de ataques APT que hemos investigado.
Víctimas y contexto geopolítico
Turla, también conocido como Snake, está activo desde al menos 2004 y, según las evaluaciones ampliamente aceptadas, forma parte del Servicio Federal de Seguridad de Rusia (FSB). Sus objetivos habituales son gobiernos, misiones diplomáticas y organizaciones de defensa, principalmente en Europa, Asia Central y Medio Oriente. Hemos documentado gran parte de su arsenal en WeLiveSecurity. En 2025, también informamos sobre una inusual cooperación entre Turla y Gamaredon en nuestro artículo Gamaredon X Turla collab y en nuestro white paper Gamaredon en 2025: uso de túneles, workers, dead drops y nuevas alianzas.
El conjunto de herramientas Cereal demuestra la capacidad de Turla para llevar adelante una intrusión lenta, cuidadosa y prolongada, centrada en servidores Microsoft Exchange.
Identificamos dos organizaciones gubernamentales nacionales comprometidas por Cereal, en regiones geográficas que coinciden estrechamente con los objetivos conocidos de Turla. Según la telemetría de ESET, alrededor del 70 % de los países que Turla ha tenido como objetivo desde 2022 son antiguas repúblicas soviéticas o países europeos que alguna vez estuvieron estrechamente alineados con la Unión Soviética. La distribución geográfica de los dos compromisos confirmados se muestra en la Figura 1.
El caso de Rumania es destacable porque uno de los componentes, CerealBox, estaba configurado para recopilar mensajes relacionados con direcciones institucionales de la OTAN y la UE. Este enfoque coincide con las prioridades históricas de los servicios de inteligencia rusos. También podría estar relacionado con las tensiones regionales: desde principios de 2025, Rumania ha informado de varios incidentes en los que drones rusos se estrellaron cerca de su territorio o dentro de él, lo que provocó fuertes reacciones de las autoridades rumanas y llamados a establecer una misión de la OTAN en la región del mar Negro.
El compromiso de la organización kazaja también se produjo en un contexto político relevante. Desde enero de 2026, según se ha informado, Kazajistán comenzó a deportar a algunos exiliados rusos y críticos del régimen que anteriormente habían encontrado allí una relativa seguridad tras la invasión a gran escala de Ucrania por parte de Rusia. El compromiso de un organismo gubernamental kazajo encaja con un escenario en el que los operadores buscan obtener información sobre disidentes rusos conocidos por las autoridades kazajas, pero que todavía no figuran en ninguna lista de deportación.
Hay un detalle más que vale la pena señalar. La actividad en Kazajistán se intensificó el 15 de enero de 2026, el día posterior al Año Nuevo Viejo, una festividad informal que todavía se celebra en Rusia y algunos países vecinos. El malware no celebra las fiestas, pero sus operadores sí.
Siguiendo el rastro de las migas de Cereal
Los primeros componentes que encontramos no se parecían a un backdoor clásico. No había un implante monolítico evidente, una lista de comandos incorporada ni un patrón sencillo de comunicación periódica con un servidor. En cambio, la actividad se presentaba como una cadena de componentes especializados: payloads cifrados en el disco, ensamblados de .NET incrustados dentro de otros ensamblados de .NET, procesos legítimos de Windows que cargaban DLL sospechosas y servicios de Exchange que ejecutaban código que no debería estar allí.
La reconstrucción de esa cadena reveló un conjunto de herramientas modular basado en unos pocos principios de diseño recurrentes: mantener los payloads cifrados, ejecutar el código en memoria siempre que sea posible, reutilizar el servidor Exchange comprometido y enviar los comandos como ensamblados de .NET independientes. La Figura 2 muestra las relaciones entre todos los componentes observados del conjunto de herramientas.
Los componentes principales son:
- CerealLoader, que carga y ejecuta un ensamblado de .NET desde un archivo cifrado en el disco. Es el único componente del conjunto de herramientas que se escribe en el disco como un archivo .NET reconocible. Todo lo demás se entrega dentro de contenedores cifrados, se descomprime durante la ejecución y se ejecuta desde la memoria.
- CerealRunner, que contiene otros binarios cifrados que se cargan y ejecutan. Permite encapsular y distribuir comandos, así como otros componentes.
- CerealSprinter, similar a CerealRunner, pero utilizado únicamente para cargar y ejecutar otros componentes.
- CerealNeuron, un backdoor pasivo que no tiene comandos incorporados, pero que puede ejecutar ensamblados contenidos en binarios de CerealRunner recibidos mediante solicitudes de red. Le dimos ese nombre en referencia a Neuron, una familia de malware documentada y atribuida a Turla por el Centro Nacional de Ciberseguridad del Reino Unido en 2017, debido a que ambos tienen funcionalidades similares.
- CerealHermit, una variante de CerealNeuron que no tiene funcionalidades de red. Lee los comandos desde archivos cifrados en el disco.
- CerealIron, un inyector que permite a los operadores cargar y ejecutar ensamblados de .NET desde procesos que no utilizan .NET.
- CerealBox, que procesa, filtra y recopila mensajes de correo electrónico de interés mediante su inyección en el servicio de transporte de Microsoft Exchange.
- CerealMoth, un componente sencillo que recibe como argumentos un ensamblado y el nombre de un método, carga el ensamblado y ejecuta el método especificado.
Cuando el Exchange de la víctima se convierte en la infraestructura
El aspecto más destacable de esta campaña es lo que no encontramos: un servidor bajo el control de los atacantes.
La mayoría de los backdoors se comunican periódicamente con sus operadores. Ese comportamiento deja rastros —dominios, direcciones IP, proveedores de hosting y patrones temporales— que los equipos de defensa pueden identificar y bloquear. CerealNeuron, el principal backdoor del conjunto de herramientas Cereal, no hace nada de eso. En lugar de iniciar conexiones salientes, espera solicitudes entrantes.
CerealNeuron se ejecuta en el servidor Exchange comprometido y escucha pasivamente las solicitudes web entrantes en rutas que parecen corresponder al tráfico habitual de Exchange. Entre las rutas que observamos se encuentran:
- https://*:443/owa/sdds/
- HTTPS://*:443/AUTODISCOVER/PROXYSERVICE/
- HTTPS://*:443/MICROSOFT-SERVER-ACTIVESYNC/INTEGRATED/API/
Para los registros de un firewall o para un analista que revisa el tráfico, las solicitudes dirigidas a estas rutas se confunden con el tráfico legítimo de Outlook Web Access, Autodiscover y ActiveSync. Si una solicitud de un recurso en alguna de estas rutas está correctamente cifrada y supera varias comprobaciones de integridad, CerealNeuron la descifra, interpreta su contenido como un comando y lo ejecuta. Si una solicitud parece sospechosa, CerealNeuron redirige al cliente a una página de error de Exchange que parece legítima.
Las consecuencias son importantes:
- No hay una infraestructura de C&C específica que se pueda descubrir, bloquear o desmantelar. El propio servidor Exchange de la víctima, expuesto a Internet, se convierte en el punto de control al que pueden acceder los operadores.
- El rastreo basado en la red se ve considerablemente limitado. No pudimos identificar las direcciones IP de origen utilizadas por los operadores. Es posible que se hayan conectado directamente, a través de servicios de anonimización o desde otros equipos comprometidos.
- El tráfico malicioso coexiste con los servicios web legítimos de Exchange: precisamente el tipo de tráfico que los equipos de defensa tienen menos probabilidades de bloquear.
La figura 3 muestra el flujo de comunicación entre los operadores y CerealNeuron.
Figura 3. Flujo de comunicación entre los operadores y CerealNeuron para la ejecución de comandos
El uso de un servidor Exchange comprometido como centro operativo es una técnica poco frecuente, utilizada por apenas un puñado de grupos APT. Turla ya ha empleado variantes de este enfoque en el pasado. Con Cereal, al utilizar el servidor Exchange de la víctima, se elimina la necesidad de contar con infraestructura propia de los atacantes.
El conjunto de herramientas también ofrece un mecanismo alternativo. CerealHermit es una variante de CerealNeuron a la que se le quitaron las funcionalidades de red. En lugar de esperar solicitudes web, lee archivos de comandos cifrados desde el disco y escribe los resultados cifrados. En algunas intrusiones, ambos backdoors se implementaron en simultáneo, lo que les dio a los operadores dos formas independientes de alcanzar sus objetivos.
Comandos en forma de programas descartables
En lugar de utilizar un único backdoor de gran tamaño que contenga todos los comandos posibles, los operadores de Turla envían cada comando como un pequeño programa compilado en .NET.
El componente central de ejecución es CerealRunner. Este contiene otros programas .NET cifrados, junto con los argumentos necesarios para ejecutarlos. Cuando se ejecuta, descomprime sus payloads, los ejecuta en memoria y devuelve sus resultados a través de la misma cadena de procesamiento, para que CerealNeuron pueda cifrarlos y enviarlos de vuelta.
Detectamos numerosos binarios de CerealRunner en las dos intrusiones. Todos comparten la misma estructura, pero se diferencian en el pequeño fragmento de código que implementa cada tarea específica
Los comandos incluyen:
- Recuperar buzones de correo o mensajes específicos a través de Exchange Web Services.
- Consultar Active Directory para obtener información sobre equipos, usuarios, grupos y registros DNS.
- Ejecutar consultas WMI; por ejemplo, para enumerar procesos o conexiones TCP activas.
- Extraer LSA Secrets (credenciales que Windows almacena localmente).
- Enumerar instantáneas de volúmenes.
- Listar, leer y eliminar archivos, a menudo los volcados de correos electrónicos generados por CerealBox.
La gran cantidad de binarios prácticamente idénticos, cada uno compilado para una tarea específica, sugiere claramente que los operadores cuentan con un framework interno que automatiza la compilación y el empaquetado de comandos. Sumado a una base de código diseñada en torno a componentes modulares e intercambiables, esto da la impresión de una plataforma madura y bien desarrollada, más que de una colección desordenada de scripts.
Trucos de .NET que no son para niños
Lo que distingue a Cereal de la mayoría de los casos recientes de ataques APT es el grado de aprovechamiento de los mecanismos internos de .NET, el framework de software de Microsoft que sustenta gran parte de Windows y del propio Exchange.
Normalmente, los programas .NET se ejecutan a través de Common Language Runtime (CLR), que convierte las instrucciones de un programa en código máquina justo antes de ejecutarlas. Todo este proceso es visible para las herramientas de análisis estándar. Cereal opera reiteradamente fuera de estas vías habituales y observables.
Un programa .NET que ejecuta código nativo antes que cualquier código .NET
CerealLoader es el único componente de Cereal que se escribe en el disco sin cifrar. En un descompilador de .NET, el código del punto de entrada prácticamente no hace nada y nunca se activa un punto de interrupción establecido en el método malicioso.
En la práctica, CerealLoader ejecuta código de bajo nivel, nativo de máquina, antes incluso de que el entorno de ejecución de .NET comience a ejecutar sus instrucciones habituales. Abusa de una característica poco utilizada de la especificación de .NET, Vtable Fixups, para crear un puente oculto que conecta el código nativo con un método de .NET que aparentemente no es invocado por ninguna otra parte del programa. Un analista que inspeccione únicamente el código .NET verá un código que parece no hacer nada. Para ese momento, el payload real ya se habrá ejecutado.
Secuestro de componentes legítimos de Windows
Como CerealLoader puede iniciarse desde código nativo, los operadores pueden colocarlo en ubicaciones desde las que los procesos legítimos de Windows que no utilizan .NET lo cargarán. En una de las cadenas de ejecución, CerealLoader se ubicó como ncobjapi.dll dentro de C:\Windows\System32\wbem\\, donde el servicio Windows Management Instrumentation lo cargó automáticamente. En otra, se hizo pasar por wbemcomn.dll en la misma carpeta. La DLL maliciosa reenvía las llamadas a funciones legítimas, por lo que el proceso afectado continúa funcionando con normalidad.
Abuso de la caché de imágenes nativas de .NET
Para mejorar el rendimiento durante el inicio, .NET mantiene una caché de versiones precompiladas de bibliotecas comunes en una carpeta del sistema. Cuando un programa solicita una de estas bibliotecas, el entorno de ejecución consulta primero la caché y, si encuentra una coincidencia, carga la versión almacenada allí en lugar de compilar el código del ensamblado mediante JIT. Los operadores colocaron archivos maliciosos de CerealLoader en esta caché, utilizando nombres como Microsoft.Exchange.Search.Mdb.ni.dll. Cuando Exchange solicitó la biblioteca correspondiente, el entorno de ejecución cargó la versión maliciosa en su lugar. Como el archivo malicioso no contiene código de reemplazo funcional, .NET recurre silenciosamente a la biblioteca legítima para ejecutar las funciones correspondientes, pero no antes de que se haya ejecutado el código del punto de entrada nativo de los atacantes. En una de las muestras, el código malicioso solo se activa cuando el proceso padre es el servicio de búsqueda de Exchange.
Cada una de estas técnicas está documentada en secciones poco conocidas de la especificación de .NET. Lo inusual es verlas combinadas de manera tan deliberada en un mismo conjunto de herramientas y utilizadas específicamente para ocultarse dentro de Microsoft Exchange.
CerealBox: manipulación de Exchange desde adentro
El componente de Cereal que utiliza la técnica más novedosa es CerealBox, un módulo de recopilación de correos electrónicos desarrollado para Microsoft Exchange.
Turla ya había atacado servidores Exchange anteriormente, incluso mediante el abuso de los agentes de transporte, una funcionalidad legítima de Exchange que permite a los desarrolladores intervenir en el flujo de correo electrónico para realizar tareas como el filtrado de spam. Sin embargo, los agentes de transporte instalados dejan rastros visibles en la configuración de Exchange.
CerealBox utiliza un enfoque más sigiloso. En lugar de registrarse como un agente, se inyecta directamente en EdgeTransport.exe, el proceso de Exchange que gestiona el flujo de correo electrónico. Sin embargo, llegar hasta ese punto no es sencillo: CerealBox se distribuye a través de una compleja cadena de componentes Cereal anidados, ilustrada en la Figura 4.
Una vez dentro, CerealBox accede a las estructuras internas de Exchange, localiza los agentes de transporte existentes y envuelve sus controladores con código malicioso. Estos envoltorios ejecutan primero la lógica propia de CerealBox y luego devuelven el control al código original. El correo electrónico sigue circulando con normalidad. No aparece ningún agente nuevo en la configuración de Exchange. En pocas palabras: CerealBox no agrega un agente nuevo, sino que secuestra los agentes existentes que están cargados en memoria.
Al tener visibilidad sobre el flujo de correo, CerealBox selecciona los mensajes de interés. Un mensaje cumple los criterios si tiene un archivo adjunto .doc, .docx o .pdf y coincide con al menos una de varias listas predefinidas: direcciones de remitentes, direcciones de destinatarios, fragmentos de texto en el asunto o nombres de archivos adjuntos. Al mismo tiempo, evita los mensajes que coinciden con las listas de exclusión. Los mensajes de interés se comprimen, cifran y almacenan temporalmente en archivos en el disco. Posteriormente, los operadores utilizan comandos habituales de CerealNeuron para exfiltrar y eliminar estos archivos.
La inyección en el servicio de transporte de Exchange y la manipulación del flujo de correo desde su interior constituyen una técnica novedosa, que no había sido documentada anteriormente en ninguna familia de malware. Requiere un conocimiento profundo de la estructura interna de la canalización de correo de Exchange, un nivel de conocimiento que demanda una inversión considerable de tiempo y esfuerzo para adquirirlo.
Conclusión
El conjunto de herramientas Cereal es un instrumento cuidadosamente diseñado para llevar adelante operaciones de ciberespionaje sigilosas y a largo plazo. Deja pocos rastros en el disco, evita el uso de infraestructura externa que podría ser descubierta y bloqueada, y se oculta dentro de procesos legítimos de Exchange. El uso de puntos de entrada no administrados, VTable Fixups, el abuso de la caché de imágenes nativas y la inyección en memoria en la canalización de transporte de Exchange reflejan un nivel de inversión en técnicas avanzadas de .NET poco habitual, incluso entre actores APT sofisticados.
El conjunto de herramientas Cereal demuestra que, para Turla, los servidores Exchange no son solo servidores de correo: también son puntos de recopilación persistentes, centros de ejecución internos y un entorno adecuado para ocultar técnicas avanzadas de .NET.
Para cualquier consulta sobre nuestra investigación publicada en WeLiveSecurity, ponte en contacto con nosotros en threatintel@eset.com.ESET Research ofrece informes privados de inteligencia sobre APT y fuentes de datos. Para cualquier consulta sobre este servicio, visita la página de ESET Threat Intelligence.
IoC
Puede consultarse una lista completa de indicadores de compromiso (IoC) en nuestro repositorio de GitHub y en el informe técnico sobre Turla.
