olimposec.com
Radar / Notícias / OS-2026-879
panoramaNOTÍCIA2026-11-06 · 2 min de leitura
0

Honeypot planejado por LLM redireciona agentes atacantes autônomos para uma cópia isolada da aplicação

Resumo executivo

Pesquisadores desenvolveram um esquema de defesa em que um LLM planeja, a partir do código-fonte da aplicação, um honeypot estático, e um roteador desvia todo o tráfego subsequente de clientes já confirmados como atacantes — inclusive exploits funcionais — para uma réplica isolada («shadow»). Contra o framework ofensivo ARTEX, a defesa reduziu o comprometimento real de 20/40 para 0/40 em tarefas conhecidas e de 15/20 para 0/20 em tarefas novas do CVE-Bench.

A motivação do trabalho é uma assimetria temporal que já preocupa quem defende aplicações expostas à internet: agentes de IA conseguem encontrar e explorar vulnerabilidades web rápido o suficiente para que o ciclo tradicional de patching não alcance o ataque a tempo. Técnicas de decepção (honeypots, canários, dados falsos) existem há décadas, mas normalmente apenas atraem o atacante para longe do alvo real, que continua acessível — o que deixa margem para o atacante eventualmente encontrar e explorar o sistema de produção de qualquer forma.

A proposta aqui é diferente: em vez de apenas atrair, um LLM analisa o código-fonte da aplicação e planeja estaticamente um honeypot plausível adaptado àquela aplicação específica, e um roteador observa o comportamento de cada cliente. No momento em que um cliente é confirmado como atacante — por exemplo, por enviar um exploit que de fato funcionaria contra o sistema real — todas as requisições subsequentes desse cliente passam a ser silenciosamente redirecionadas para uma cópia isolada («shadow») da aplicação, onde o exploit pode «funcionar» sem nenhum impacto real. Os autores também testam uma variante aumentada, com um respondente LLM em tempo de execução e regras adicionais de roteamento.

Os números são expressivos: nas 40 tarefas críticas do CVE-Bench, o honeypot estático cortou o comprometimento real de 26/40 para 5/40 quando o atacante era o Claude Opus 4.8, e de 20/40 para 0/40 quando o atacante era o próprio framework ofensivo ARTEX; em 20 tarefas novas, fora do conjunto usado para desenhar a defesa, o ARTEX foi de 15/20 para 0/20. Em cerca de metade das execuções com a defesa ativa, o exploit do ARTEX efetivamente funcionou — só que contra a cópia isolada, não contra o sistema real —, o que os autores descrevem como «mover» um exploit funcional em vez de simplesmente bloqueá-lo. Curiosamente, o ARTEX também reportou um segredo falso plantado como genuíno em 30 das 120 tarefas do braço de decepção, inclusive classificando, em cinco casos, outro item como «decoy» no mesmo relatório.

O ponto relevante para quem avalia esse tipo de defesa na prática é a limitação que os próprios autores destacam: o risco residual está concentrado nas requisições que chegam ao sistema real antes de o cliente ser confirmado como atacante — ou seja, o primeiro exploit de um atacante novo ainda passa. Isso posiciona esse tipo de honeypot adaptativo como uma camada de contenção pós-detecção eficaz contra campanhas automatizadas e persistentes, mas não como substituto de correção de vulnerabilidades ou de defesas que bloqueiem a primeira tentativa de exploração.

Fonte ↗
0 comentários

Entre para comentar.

Nenhum comentário ainda — seja o primeiro.