Operation CAIRN: plataforma de ataque con LLM en uso real

Primero el resumen: un investigador de amenazas (alias @TheM3gatr0n) informa de haber encontrado una plataforma activa y hecha a medida, «Cairn», que permite a un gran modelo de lenguaje ejecutar intrusiones de principio a fin sin un humano en el circuito en cada sesión. La tratamos como una divulgación creíble de una sola fuente, aún no corroborada de forma independiente. Esto es lo que se informó, lo que es realmente nuevo y lo que deberían hacer los defensores. Actualización, noviembre de 2026: el grupo de inteligencia de amenazas de Google ha informado desde entonces de atacantes que usan marcos agénticos en intrusiones reales, incluida una herramienta que llama CAIRN (GTIG no dice si es la plataforma tratada aquí); consulta ARTEX y los marcos de ataque agénticos: lo que encontró GTIG.

Qué se encontró

Empezó, como suele pasar, con un análisis rutinario de indicadores de compromiso. La pista era poco vistosa: un servidor privado virtual en un proveedor de alojamiento APAC registrado en Hong Kong, marcado por una combinación de puertos inusual. Al mirarlo más de cerca tenía un certificado TLS autofirmado de dos días de antigüedad (decodifica un certificado), una API en Python detrás de autenticación HTTP Basic y (el detalle que abre la mayoría de estas historias) un directorio abierto. Ese directorio contenía más de 150 archivos de una campaña activa.

Dentro no había un script ni un kit de herramientas. Había una plataforma que el operador llama Cairn: un sistema completo de orquestación de ataques construido en torno a un LLM. El humano le da un objetivo y una meta. La IA hace el resto.

La arquitectura

El diseño descrito es sencillo y, de forma incómoda, sensato:

• Un despachador lee una base de datos SQLite de objetivos: había más de 85 objetivos distintos.
• Cada víctima tiene su propio contenedor Docker con Kali Linux, que aísla un ataque de otro.
• Un LLM recibe tres cosas: el objetivo, una meta (por ejemplo, «obtener una webshell o RCE») y un grafo de hechos con todo lo intentado en sesiones anteriores.
• El modelo elige el siguiente paso, lo ejecuta, observa el resultado y escribe el resultado de vuelta en el grafo.

No hay un humano en el circuito en cada sesión. El modelo que, según el informe, se usa es DeepSeek v4.1-flash, al que se accede mediante un servicio pirata de rotación de cuentas («ClinePass») que va alternando suscripciones robadas para eludir los límites de frecuencia por sesión: dos cuentas activas con unos 10.000 $ de saldo combinado restante. Dos dispositivos Raspberry Pi (pi-workbuddy y pi-cline-deepseek) servían como trabajadores locales.

Lo que de verdad lo hace diferente

Las herramientas de ataque automatizadas tienen décadas. Lo que distingue a Cairn es la memoria. Cada sesión termina con un resumen estructurado en chino (qué se intentó, qué se bloqueó, qué está ya confirmado) escrito de vuelta en el grafo de hechos para la siguiente ejecución. A lo largo de más de 90 sesiones contra un solo objetivo, el modelo lee su propio trabajo anterior y se niega a repetir callejones sin salida.

Ese es el cambio. No un exploit nuevo, sino un atacante que acumula conocimiento con el tiempo y nunca se aburre, se distrae ni se desanima. En 13 días registrados, la plataforma generó 229.828 eventos de ataque despachados por la IA y 17.768 intentos de explotación activa.

Las CVE en juego

Según el informe, convertidas en armas y concentradas en comercio electrónico y dispositivos perimetrales:

• CVE-2024-34102: «CosmicSting», XXE en Magento
• CVE-2022-24086: RCE por inyección de plantillas en Magento
• CVE-2026-75650: «StyleSmuggler», un 0-day de Magento en el momento de los ataques
• CVE-2026-53787: Amasty Order Attributes, subida de archivos sin autenticación
• CVE-2026-44277: FortiAuthenticator, previa a la autenticación
• CVE-2014-6271: ShellShock, y la que de verdad funcionó

El vector que merece estudio: ShellShock por SMTP

La parte más instructiva del informe no es el 0-day más reciente: es un fallo de hace once años entregado a través de un intercambio de correo. El operador inyectó una carga de Bash en el campo RCPT TO de un servidor de correo. El objetivo ejecutaba qmail, que elimina el dominio del destinatario después de la @ antes de pasar la parte local al agente de entrega. En un entorno vulnerable a ShellShock, esa parte local llegó a Bash y se ejecutó durante una conversación SMTP por lo demás normal. La salida de los comandos volvía canalizada mediante curl, incrustada en códigos de respuesta 250 rutinarios, de modo que la exfiltración parecía acuses de recibo de correo normales.

Según el informe, los registros confirman que funcionó:

EXEC [redacted]:25   2026-09-29T18:11:49
id        -> 250 ok
hostname  -> 250 ok
uname -a  -> 250 ok

Cada respuesta, colada dentro de un acuse SMTP de aspecto normal. La lección es la misma que enseñó ShellShock en 2014: la entrada no fiable nunca debe llegar a una shell, y las pilas de correo heredadas siguen siendo un punto débil.

Un segundo punto de apoyo: GCP, Redis y una reverse shell cada cinco minutos

Según el informe, el operador también comprometió una plataforma SaaS multiinquilino en Google Cloud. Un pod de Redis comprometido tenía esto en su crontab, ejecutándose cada cinco minutos:

*/5 * * * * /bin/sh /data/pwn.sh

El script era una reverse shell con netcat que llamaba al servidor de comando y control del operador, y seguía ejecutándose en el momento del descubrimiento. Peor aún para los clientes de la víctima, las variables de entorno dentro del pod exponían nombres de servicios internos de unos 20 inquilinos clientes identificados por su nombre: tanto un problema de radio de impacto como de intrusión.

Esto es software mantenido, no un golpe rápido

Cairn incluye un demonio de gestión de memoria, cairn_guard.sh, que vigila el proceso del despachador, aplaza los reinicios hasta que ninguna sesión de ataque tiene una concesión activa y limita la frecuencia de reinicios para evitar bucles. Un comentario en el script explica por qué existe: el despachador llegó a ocupar 12 GB, llenó la swap y el OOM killer del kernel lo mató. Alguien se dio cuenta, lo depuró y lo arregló. Es un reflejo de mantenedor, y te dice que es una herramienta que su autor pretende seguir usando.

Lo que deberían sacar los defensores de esto

Toma las cifras concretas con cautela hasta que aparezca una segunda fuente. Pero las acciones baratas y de alto valor no dependen de que los detalles sean perfectos:

• Parchea rápido el comercio electrónico expuesto a internet. Magento / Adobe Commerce y sus extensiones están de lleno en el punto de mira; CosmicSting y compañía se están encadenando de forma agresiva.
• Retira el software de la época de ShellShock. Si un fallo de Bash de 2014 todavía puede funcionar en 2026, tienes sistemas heredados que deben desaparecer.
• Refuerza SMTP. Los campos de destinatario y de sobre nunca deberían poder llegar a una shell; parchea y aísla los agentes de entrega de correo, y alerta sobre patrones anómalos de tráfico con códigos 250.
• Vigila el tráfico de salida y los crontab de contenedores y pods. Las tareas programadas inesperadas que escriben reverse shells son una detección de alta señal; también lo es el tráfico saliente hacia C2 desconocidos.
• Acota el radio de impacto multiinquilino. Los nombres de inquilinos filtrados en variables de entorno de pods convierten una brecha en veinte. Segmenta, limita el alcance de los secretos y da por hecho el movimiento lateral.
• Ensaya contra un adversario adaptativo. Haz un ejercicio de mesa del caso en que el atacante aprende de cada intento fallido y vuelve más listo en la siguiente ronda, porque eso ya existe.

Practícalo, no te limites a leerlo

Un adversario que se adapta en cada ronda es exactamente el tipo de amenaza para la que una presentación no puede prepararte. En PlayCISO puedes trabajarlo de forma práctica, gratis, en el navegador:

• Cyber War Room: simulaciones de incidentes ramificadas en las que el siguiente movimiento del adversario depende del tuyo.
• Detection Lab: escribe y ajusta reglas de detección para IOC como tráfico SMTP 250 anómalo o escrituras inesperadas en crontab.
• IR Playbook Lab: codifica la contención de una intrusión rápida y guiada por la memoria.
• Cómo escribir una regla de detección y cómo clasificar una alerta del SOC: paso a paso, terminando en el laboratorio correspondiente.

Fuente: informe de campo de @TheM3gatr0n, tratado aquí como una divulgación de una sola fuente. Actualizaremos este artículo si los hallazgos se corroboran de forma independiente.