Uma nova abordagem força um agente de pentest impulsionado por LLM a provar uma violação em vez de apenas alegá-la, utilizando nonces de desafio-resposta que eliminam falsos positivos. A técnica, demonstrada no framework HALO, transforma o “parece que conseguimos um shell” em “nós realmente temos um shell”.

Por que violações com falsos positivos importam

Motores de exploração automatizados construídos sobre grandes modelos de linguagem podem gerar dezenas de compromissos de porta “bem-sucedidos” em uma única execução. Muitos serviços ecoam strings como “uid=0” em banners, e um alvo manipulado pode imitar essas saídas sem nunca executar o código do atacante. Quando o agente confia nesses ecos, cada decisão subsequente — seja para realizar um pivot, exfiltrar dados ou mover-se lateralmente — baseia-se em uma mentira. Equipes de segurança perdem horas perseguindo pontos de apoio fantasmas, e respondedores de incidentes podem priorizar incorretamente ameaças reais.

Transformando uma alegação em prova

A solução utiliza truques clássicos de autenticação. Antes de lançar um exploit, o sistema do atacante gera um token único, ou nonce, e o incorpora ao payload. O exploit deve retornar o token exato para que o controlador aceite o resultado como uma violação genuína. Um banner falso não consegue adivinhar o nonce; ele deve executar o código do atacante para incorporar o token na resposta. Se os dados retornados não contiverem o nonce correspondente, a tentativa é descartada como um falso positivo.

Essa mudança altera o modelo de verificação de “a saída parece correta” para “a saída prova a execução”. Isso remove o viés de otimismo que assola ferramentas de ataque autônomas.

Construindo uma escada de entrega confiável

Levar o payload ao alvo ainda requer uma cadeia de entrega sólida. O HALO classifica três caminhos comuns:

  • Reverse shells – o host comprometido inicia uma conexão de volta para um listener controlado pelo atacante. Útil quando o tráfego de entrada está bloqueado.
  • Bind shells – o atacante se conecta diretamente a um serviço de escuta no alvo. Funciona quando os filtros de saída são permissivos.
  • Blind callbacks – um sinal unidirecional (ex: requisição DNS) que confirma a execução em ambientes altamente restritos, onde nenhum canal direto pode ser aberto.

Cada etapa na escada deve preservar o nonce, caso contrário, a etapa de prova falhará adiante no processo.

Garantindo exploits autossuficientes

Outra fonte de falsa confiança é a dependência de bibliotecas externas que podem estar ausentes no alvo. O HALO agrupa todos os componentes necessários em um único arquivo antes do envio. O pacote é então testado em um sandbox que deliberadamente carece das dependências originais. Se o exploit ainda assim for executado, o artefato é verdadeiramente autossuficiente e pode ser confiável em um sistema com segurança rigorosa.

Limpando o rastro de desenvolvimento

Enquanto se preparava para o lançamento público, o autor descobriu endereços IP reais remanescentes no histórico do Git. Uma árvore de trabalho limpa não apaga esses registros; o Git retém cada commit. O autor reescreveu o repositório para um único commit limpo e substituiu os endereços vazados por intervalos apenas para documentação definidos pela RFC 5737 (por exemplo, 192.0.2.0/24). Isso evita a exposição acidental da infraestrutura de produção quando a ferramenta é compartilhada.

Regras práticas para ferramentas de segurança

  • Use intervalos de IP apenas para documentação em cada fixture de teste.
  • Remova segredos e arquivos de escopo do commit inicial.
  • Aplique nonces de desafio-resposta para verificar qualquer violação alegada.
  • Valide o arquivo exato que será enviado, não um script vagamente relacionado.

Prova vence o otimismo. Ao forçar um agente de pentest autônomo a apresentar um token verificável, o HALO mostra que uma violação só é uma violação quando o alvo pode provar que executou o código do atacante. O portão é construído primeiro; todo o resto vem depois.