Há ataques que nos obrigam a parar e a reconhecer que o terreno mudou debaixo dos nossos pés. Este é um deles. No dia 29 de maio de 2026, a equipa de investigação de ameaças da Sysdig observou algo que, na minha leitura de quem vive entre incidentes e análises forenses, marca uma transição que muitos de nós antecipávamos há tempo: um ataque de ponta a ponta conduzido não por um humano ao teclado, mas por um agente autónomo apoiado num modelo de linguagem. Não foi um humano a decidir o passo seguinte. Foi uma máquina.
Convém, antes de mais, desmontar um equívoco que tende a contaminar este tipo de notícias. A tentação é dizer que a IA "inventou" um ataque novo, que descobriu caminhos de exploração que nos escapam. Não foi nada disso, e é importante sermos rigorosos. As técnicas usadas são manual de escola: enumeração do socket do Docker exposto, criação de um contentor privilegiado para escapar para o host, leitura do ficheiro shadow e das chaves SSH, e o replay de um token de service account do Kubernetes para esvaziar o cofre de Secrets do cluster. Qualquer perito reconhece estas primitivas. O ponto de entrada foi, aliás, banalmente humano: um notebook marimo desatualizado e vulnerável (CVE-2026-39987), corrigível com um patch de uma linha.
Então onde está a verdadeira novidade? Está na autonomia, na velocidade e no comportamento. E é aqui que o meu lado forense fica genuinamente fascinado – e preocupado. O detalhe que, para mim, é a verdadeira assinatura da máquina não é nenhuma exploração espetacular: é o facto de o agente ter testado o seu próprio canal de entrega antes de o usar. Escreveu payloads-canário descartáveis – primeiro um simples "hello", depois um "hello" seguido de "world" em pedaços – só para confirmar que o mecanismo de escrever em base64, anexar e descodificar funcionava, antes de confiar nele o código real de fuga. Nenhum atacante humano, num shell interativo, perde tempo a fazer testes unitários ao seu próprio túnel. Isto é o comportamento de um harness autónomo, metódico e paciente à maneira de uma máquina.
O segundo sinal é ainda mais revelador para quem faz perícia. O agente agiu sobre diretivas escondidas no próprio fluxo de respostas – uma armadilha (canary) plantada num erro JSON e uma sequência de escape invisível no stream do terminal. Um humano nunca repararia nesses elementos; passaria os olhos por cima. Mas um agente que lê o stream completo como contexto autoritativo atua sobre eles. Foi precisamente isto que denunciou a natureza não-humana do operador. Como perito, isto muda a forma como olho para os artefactos: deixei de procurar apenas os erros e hesitações típicos de um humano e passei a procurar a regularidade mecânica, os marcadores de secção ===SHADOW===, ===SSH===) que servem para a próxima iteração do agente fatiar o output, e os retries sistemáticos que se adaptam ao resultado anterior.
A escolha do alvo – o plano de orquestração – é o que transforma isto de um incidente num alerta. Comprometer o Kubernetes não é escapar de um contentor isolado, é ter acesso à camada que governa toda a infraestrutura. Um único token de service account, montado num pod acessível e com um RBAC permissivo de mais, permitiu ao agente saltar de um RCE ao nível da aplicação para o cofre completo de Secrets do cluster: credenciais de base de dados, chaves AWS, uma chave de API da OpenAI, um webhook de Slack. Numa única jogada. Estas Secrets são o material-semente para o próximo salto – cloud, bases de dados, servidores. É um efeito de dominó que começa numa má configuração e acaba numa exposição total.
Aqui faço questão de ser claro num ponto onde discordo de alguma da narrativa mais alarmista, e onde a própria Sysdig é honesta: isto não torna as defesas tradicionais obsoletas – torna-as mais urgentes do que nunca. As deteções ao nível do host para estas técnicas já existem e funcionam. As fases de fuga de contentor e de replay de token são, aliás, onde o defensor tem mais sinal para detetar. O que mudou não foi a eficácia das defesas; foi a janela de tempo. Aquilo que antes era uma escalada lenta, ao ritmo de um humano a pensar entre comandos, é agora uma tomada de controlo do host e do cluster que corre à velocidade da máquina, com o agente a tentar primitivas de fuga em paralelo até uma resultar. A higiene de configuração, que sempre tratámos como aborrecida e adiável, passou a ser a linha da frente.
Na prática, e falando como quem teria de responder a um incidente destes, as prioridades são concretas e não abstratas. Atualizar o marimo para a versão 0.23.0 ou superior – é literalmente um patch de uma linha. Nunca, em circunstância alguma, montar o /var/run/docker.sock dentro de um contentor de aplicação: montar esse socket equivale a entregar root no host. Correr os contentores sem privilégios, com sistema de ficheiros só de leitura, capabilities removidas e um perfil seccomp restritivo. Limitar agressivamente os tokens de service account do Kubernetes – desativar o automount onde não é preciso, usar tokens de curta duração, e apertar o RBAC para que o token de uma única workload não consiga listar e ler Secrets de todo o namespace, quanto mais do cluster inteiro. E rodar tudo o que tenha estado exposto.
Deixo uma reflexão final, mais de fundo. Durante anos, o nosso modelo mental do atacante foi o de um humano – com fadiga, com hesitação, com um custo de oportunidade em cada passo. Esse modelo está a ruir. Quando o atacante é um agente que não dorme, não erra por distração, testa o seu próprio ferramental e adapta a estratégia a cada resposta em milissegundos, a assimetria entre ataque e defesa agrava-se. A boa notícia, e termino por aqui, é que o agente não é mágico: continua a depender das mesmas portas abertas que sempre nos descuidámos a fechar. A diferença é que já não temos o luxo do tempo para as fechar depois. Temos de as fechar antes.
Fonte original: [Sysdig] — investigação de Michael Clark, Sysdig Threat Research Team, 4 de junho de 2026.