O pentest autônomo com IA amplia a possibilidade de automatizar investigações que exigem contexto: permissões, relações entre usuários, regras de negócio e sequências de ações. A mudança é relevante porque muitas falhas só revelam seu impacto quando o teste entende como uma aplicação funciona e como suas partes se conectam.
Esses problemas já podiam ser descobertos por especialistas. A nova oportunidade é executar parte dessa investigação de maneira autônoma e recorrente, reduzindo a dependência de uma análise manual para cada hipótese. A cobertura efetiva continua ligada aos acessos, ao escopo e às evidências da operação.
O que significa cobertura em um pentest?
Cobertura envolve mais do que contar endereços visitados. Uma aplicação pode ter sido acessada, mas um perfil privilegiado, uma integração crítica ou uma sequência de negócio ainda não ter sido exercitada. É preciso saber quais contextos o teste conseguiu alcançar.
Na prática, há diferentes perguntas: quais ativos entraram na avaliação? Quais perfis foram usados? Quais funções e estados da aplicação foram explorados? Que hipóteses de ataque foram validadas? Quando isso ocorreu, em relação à versão atual?
O manifesto do Ares apresenta a visão da Vultus para essa evolução: tratar aplicações como sistemas com usuários, permissões, APIs, integrações e regras, conectando a exposição ao impacto. Isso orienta uma investigação que procura caminhos de ataque.
Da verificação programada à hipótese adaptativa
Análises estáticas, análises dinâmicas e verificações automatizadas seguem contribuindo para identificar condições conhecidas. Uma investigação por agentes acrescenta a possibilidade de interpretar uma resposta, formular outra hipótese e adaptar a sequência de teste.
Por exemplo, uma mensagem de erro pode revelar uma relação entre duas funções. Um perfil pode enxergar uma operação, mas ter uma restrição diferente ao concluí-la. O valor da interpretação aparece quando esses sinais orientam uma nova pergunta e o ambiente fornece evidência para respondê-la.
Para sustentar um achado, o teste precisa separar o que foi observado do que foi inferido. A hipótese pode vir do agente; a demonstração de acesso ou comportamento indevido precisa vir do alvo autorizado.
Permissões: a mesma função pode ter resultados diferentes
Considere um portal fictício com clientes e operadores internos. Um usuário pode ter acesso legítimo à função de consultar documentos e ainda assim não ter autorização para todos os documentos que ela retorna.
Testar esse cenário exige perfis distintos e conhecimento de quem deveria acessar cada objeto. A categoria API1:2023 da OWASP, Broken Object Level Authorization, trata dessa separação entre acesso à função e autorização sobre o objeto.
Uma arquitetura autônoma pode investigar essas diferenças com contas de teste apropriadas. Sem esses acessos, a avaliação daquele contexto fica limitada. Registrar essa dependência torna a cobertura mais clara para quem decide.
Fluxos de negócio: uma função legítima também pode ser abusada
Imagine, em outro exemplo fictício, um serviço de agendamento que permite reservar horários sem um limite adequado por usuário. A função pode operar conforme o esperado em cada requisição e, mesmo assim, permitir que uma sequência de ações prejudique a disponibilidade comercial.
A categoria API6:2023 da OWASP discute acesso irrestrito a fluxos sensíveis de negócio. A relevância depende de como a função é utilizada e do impacto para aquela organização.
Esse tipo de hipótese pede contexto de negócio e uma forma controlada de demonstrar o problema, usando limites e dados de teste acordados. O especialista ajuda a definir qual comportamento seria abusivo e qual evidência é suficiente para orientar a correção.
Kill chains: o impacto pode estar na combinação
Uma exposição inicial pode revelar informações que permitem uma segunda ação. A segunda ação pode alcançar um acesso adicional. Ao conectar essas etapas, o teste demonstra um caminho de ataque e ajuda a localizar os controles que deveriam interrompê-lo.
Na investigação autônoma, agentes podem usar os resultados de uma etapa para orientar hipóteses seguintes. É importante manter a rastreabilidade dessa sequência: condição inicial, ações realizadas, evidências obtidas e impacto observado dentro do escopo.
A série ARES KILLCHAINS BREAKDOWN mostra investigações realizadas pelo Ares. Para conhecer o conceito que organiza esses caminhos, veja também o que é cyber kill chain.
Como tornar a cobertura verificável
- Ativos e funções: identificar o que foi avaliado e o que ficou pendente.
- Perfis e estados: registrar acessos utilizados e condições relevantes do fluxo.
- Hipóteses e evidências: distinguir comportamento validado, suspeita e limitação de teste.
- Caminhos e impacto: conectar as etapas e a consequência demonstrada.
- Versão e reteste: indicar quando ocorreu a avaliação e o que foi confirmado após a correção.
Não há um percentual único que descreva a cobertura de qualquer aplicação. O conjunto de funções, perfis e integrações muda de um ambiente para outro. Por isso, o resultado deve ser explicado em termos do que a investigação alcançou e do que ainda depende de contexto ou acesso.
A combinação de autonomia e experiência ofensiva
O Ares combina arquitetura adversarial multiagêntica, harness proprietário e a experiência do Red Team da Vultus para investigar esses caminhos. Agentes contribuem para execução e recorrência; especialistas direcionam objetivos, limites e a leitura do impacto.
Essa combinação aproxima a descoberta da rotina de mudança das aplicações. Entenda como organizar testes contínuos e conheça o pentest autônomo com IA da Vultus.
