El C2 del atacante ya no es un panel HTTP. Es un message broker pub/sub con autenticación, ACLs y colas durables. En Tech86 acompañamos la evolución de las tácticas de comando y control, y el caso NATS-as-C2 publicado por Sysdig representa un cambio de paradigma que la mayoría de los equipos de seguridad todavía no percibió.
El ataque que reescribió el playbook de C2
En marzo de 2026, CISA agregó la CVE-2026-33017 al catálogo Known Exploited Vulnerabilities. La vulnerabilidad: ejecución remota de código sin autenticación en Langflow, plataforma de orquestación de IA. Lo que pasó después muestra la velocidad y la sofisticación del ataque moderno.
En 30 minutos, el atacante explotó la vulnerabilidad, extrajo credenciales AWS de la memoria del proceso y validó el acceso vía sts:GetCallerIdentity. Reconocimiento completo: Bedrock, S3, EC2, Lambda, IAM. Intentó escape de container vía DirtyPipe y DirtyCreds. Y entonces instaló lo que nadie esperaba: un servidor NATS como infraestructura de comando y control.
El servidor fue configurado en 45.192.109.25:14222, con autenticación y ACLs por subject. El atacante no improvisó. Montó infraestructura de producción para controlar máquinas comprometidas.
Por qué NATS es el C2 perfecto
El C2 tradicional usa paneles HTTP, webhooks, Discord, Telegram. Son canales que los equipos de seguridad monitorean desde hace años. NATS es diferente.
NATS ofrece pub/sub con autenticación nativa, ACLs por subject, colas durables y fan-out. Son las mismas propiedades que los ingenieros eligen para microservicios de producción. Cuando el atacante usa esas propiedades para C2, el tráfico es indistinguible del legítimo.
Si su infraestructura usa NATS, el tráfico NATS outbound está permitido por defecto. Un worker malicioso conectado al broker del atacante pasa desapercibido porque el protocolo, el puerto y el patrón de comunicación son idénticos a los de sus microservicios. Su SIEM no alerta. Su firewall no bloquea. Su IDS no detecta.
El worker KeyHunter: un scanner, dos fuentes de ingresos
El atacante no se limitó a un canal de comando. Implementó un worker llamado KeyHunter con cuatro capacidades mapeadas como NATS subjects:
task.scan_cde, escanea entornos cloud de desarrollo en busca de credenciales expuestastask.scan_web, escanea CodePen, JSFiddle, StackBlitz, CodeSandbox buscando API keys filtradastask.validate_aws, valida credenciales AWS en tiempo real antes de reportartask.validate_ai, valida claves de OpenAI, Anthropic, HuggingFace en tiempo real
Un worker. Dos fuentes de ingresos: credenciales cloud y claves de IA. Del mismo scan. Validadas antes de reportar al operador. Eso es eficiencia operativa de nivel empresarial, aplicada al robo de credenciales.
La arquitectura de subjects permite que el operador publique tareas en un subject y reciba resultados en otro, con fan-out hacia múltiples workers. Escala horizontal sin esfuerzo. El C2 no es un panel centralizado, es un sistema distribuido.
Persistencia y escala sobre stealth
El atacante configuró persistencia vía systemd con Restart=always y FD limits de 65.535. Workers escritos en Python y Go, compilados para múltiples arquitecturas. Hospedados en VPS baratas en DigitalOcean.
La estrategia es clara: escala sobre stealth. Ya no hace falta esconder un panel HTTP o un canal de Discord. Basta usar infraestructura que parece legítima. El costo es bajo, la resiliencia es alta, y la detección es difícil porque nadie está buscando tráfico NATS malicioso.
Este enfoque de persistencia es particularmente peligroso porque sobrevive a reinicios y no deja artefactos obvios en los logs de seguridad tradicionales. Un servicio systemd con nombre genérico no levanta sospechas. Un proceso Go que consume pocos recursos no llama la atención.
La ventana de exposición de las plataformas de IA
Langflow, n8n y las plataformas de orquestación de IA necesitan acceso outbound para endpoints de LLM. Esa necesidad crea una ventana de exposición amplia. El acceso outbound permisivo es exactamente el canal que el worker necesita para alcanzar el broker C2.
En Tech86 vemos repetidamente equipos configurando acceso outbound amplio para workloads de IA porque "tiene que funcionar". Funciona: para el atacante también. La ausencia de restricción de egress es lo que convierte una vulnerabilidad de RCE en un compromiso persistente con canal C2 invisible.
El error no es usar Langflow o n8n. El error es permitir que esos workloads accedan a cualquier destino outbound sin restricción. La CVE-2026-33017 fue corregida. La próxima vulnerabilidad en una plataforma de IA no lo será. Pero con egress allowlist, el atacante no logra alcanzar el broker C2 incluso con RCE.
La defensa que funciona: egress allowlist
La defensa contra NATS-as-C2 no es detectar el protocolo, es restringir el destino. La egress allowlist es la medida más eficaz: restrinja el tráfico outbound de workloads de IA y automatización a endpoints específicos. El tráfico NATS outbound hacia IPs no autorizados debe ser bloqueado y alertado.
En Tech86 implementamos monitoreo de tráfico outbound y egress allowlisting para workloads de IA porque el próximo C2 puede estar escondido en la misma infraestructura que usan sus microservicios. Nuestro Blindaje Perímetro WAF incluye inspección de tráfico egress y reglas de allowlist que impiden que un worker comprometido alcance brokers no autorizados.
El atacante evolucionó. Su defensa necesita evolucionar junto. Cuando el C2 se disfraza de infraestructura legítima, la única defensa es garantizar que el tráfico ilegítimo nunca salga de su red.