O C2 do atacante não é mais um painel HTTP. É um message broker pub/sub com autenticação, ACLs e filas duráveis. Na Tech86, acompanhamos a evolução das táticas de comando e controle, e o caso NATS-as-C2 publicado pela Sysdig representa uma mudança de paradigma que a maioria das equipes de segurança ainda não percebeu.
O ataque que reescreveu o playbook de C2
Em março de 2026, a CISA adicionou a CVE-2026-33017 ao Known Exploited Vulnerabilities catalog. A vulnerabilidade: execução remota de código sem autenticação no Langflow, plataforma de orquestração de IA. O que aconteceu depois mostra a velocidade e a sofisticação do ataque moderno.
Em 30 minutos, o atacante explorou a vulnerabilidade, extraiu credenciais AWS da memória do processo e validou acesso via sts:GetCallerIdentity. Reconhecimento completo: Bedrock, S3, EC2, Lambda, IAM. Tentou escape de container via DirtyPipe e DirtyCreds. E então instalou o que ninguém esperava: um servidor NATS como infraestrutura de comando e controle.
O servidor foi configurado em 45.192.109.25:14222 — com autenticação e ACLs por subject. O atacante não improvisou. Montou infraestrutura de produção para controlar máquinas comprometidas.
Por que NATS é o C2 perfeito
C2 tradicional usa painéis HTTP, webhooks, Discord, Telegram. São canais que equipes de segurança monitoram há anos. NATS é diferente.
NATS oferece pub/sub com autenticação nativa, ACLs por subject, filas duráveis e fan-out. São as mesmas propriedades que engenheiros escolhem para microserviços de produção. Quando o atacante usa essas propriedades para C2, o tráfego é indistinguível do legítimo.
Se sua infraestrutura usa NATS, tráfego NATS outbound é permitido por padrão. Um worker malicioso conectado ao broker do atacante passa despercebido porque o protocolo, a porta e o padrão de comunicação são idênticos aos dos seus microserviços. Seu SIEM não alerta. Seu firewall não bloqueia. Seu IDS não detecta.
O worker KeyHunter: um scanner, duas fontes de receita
O atacante não se limitou a um canal de comando. Implementou um worker chamado KeyHunter com quatro capacidades mapeadas como NATS subjects:
task.scan_cde— escaneia ambientes cloud de desenvolvimento atrás de credenciais expostastask.scan_web— escaneia CodePen, JSFiddle, StackBlitz, CodeSandbox procurando API keys vazadastask.validate_aws— valida credenciais AWS em tempo real antes de reportartask.validate_ai— valida chaves OpenAI, Anthropic, HuggingFace em tempo real
Um worker. Duas fontes de receita: credenciais cloud e chaves de IA. Do mesmo scan. Validadas antes de reportar ao operador. Isso é eficiência operacional de nível empresarial — aplicada para roubo de credenciais.
A arquitetura de subjects permite que o operador publique tarefas em um subject e receba resultados em outro, com fan-out para múltiplos workers. Escala horizontal sem esforço. O C2 não é um painel centralizado — é um sistema distribuído.
Persistência e escala sobre stealth
O atacante configurou persistência via systemd com Restart=always e FD limits de 65.535. Workers escritos em Python e Go, compilados para múltiplas arquiteturas. Hospedados em VPS baratas na DigitalOcean.
A estratégia é clara: escala sobre stealth. Não é mais preciso esconder um painel HTTP ou um canal Discord. Basta usar infraestrutura que parece legítima. O custo é baixo, a resiliência é alta, e a detecção é difícil porque ninguém está procurando por tráfego NATS malicioso.
Essa abordagem de persistência é particularmente perigosa porque sobrevive a reinicializações e não deixa artefatos óbvios nos logs de segurança tradicionais. Um serviço systemd com nome genérico não levanta suspeitas. Um processo Go consumindo poucos recursos não chama atenção.
A janela de exposição das plataformas de IA
Langflow, n8n e plataformas de orquestração de IA precisam de acesso outbound para endpoints de LLM. Essa necessidade cria uma janela de exposição ampla. O acesso outbound permissivo é exatamente o canal que o worker precisa para alcançar o broker C2.
Na Tech86, vemos repetidamente equipes configurando acesso outbound amplo para workloads de IA porque "precisa funcionar". Funciona — para o atacante também. A ausência de restrição de egress é o que transforma uma vulnerabilidade de RCE em um comprometimento persistente com canal C2 invisível.
O erro não é usar Langflow ou n8n. O erro é permitir que esses workloads acessem qualquer destino outbound sem restrição. A CVE-2026-33017 foi corrigida. A próxima vulnerabilidade em uma plataforma de IA não será. Mas com egress allowlist, o atacante não consegue alcançar o broker C2 mesmo com RCE.
A defesa que funciona: egress allowlist
A defesa contra NATS-as-C2 não é detectar o protocolo — é restringir o destino. Egress allowlist é a medida mais eficaz: restrinja o tráfego outbound de workloads de IA e automação para endpoints específicos. Tráfego NATS outbound para IPs não autorizados deve ser bloqueado e alertado.
Na Tech86, implementamos monitoramento de tráfego outbound e egress allowlisting para workloads de IA porque o próximo C2 pode estar escondido na mesma infraestrutura que seus microserviços usam. Nossa Blindagem Perímetro WAF inclui inspeção de tráfego egress e regras de allowlist que impedem que um worker comprometido alcance brokers não autorizados.
O atacante evoluiu. Sua defesa precisa evoluir junto. Quando o C2 se disfarça de infraestrutura legítima, a única defesa é garantir que tráfego ilegítimo nunca saia da sua rede.