Mostre, não apenas diga: o que Evo Continuous Offensive Security encontrou em um SaaS empresarial real

Os ataques autônomos de IA deixaram definitivamente de ser apenas demonstrações de pesquisa que impressionavam a todos e passaram a fazer parte dos procedimentos operacionais padrão. Para quem está prestando atenção, isso não é necessariamente novidade: em junho, a Five Eyes Alliance alertou que a IA pode contornar a cibersegurança em meses, não anos, e que o tempo para um invasor se infiltrar já pode ser medido em segundos. A própria Gartner fez uma previsão semelhante, estimando que a janela para explorar vulnerabilidades será reduzida pela metade já no próximo ano.

Descubra o que os invasores podem encontrar antes que eles descubram.

Isso torna ainda mais relevante e oportuna nossa notícia sobre a disponibilidade de Evo Continuous Offensive Security. Oferecemos segurança ofensiva autônoma que ataca continuamente suas aplicações e sistemas de IA, da mesma forma que uma equipe humana de red team de ponta faria, por meio de três recursos integrados: Pentest com IA, Red Teaming de agentes e Testes dinâmicos (DAST).

O COS foi desenvolvido para ser o pentester de IA mais preciso e confiável do mercado. Antes de chegar até você, cada descoberta é validada quanto à possibilidade real de exploração reproduzível por um “avaliador independente”, por assim dizer. Assim, seu relatório final inclui apenas o que um invasor realmente poderia explorar.

Mas, em vez de apenas contar o que ele pode fazer, queremos mostrar. Tudo o que vem a seguir é uma avaliação real de uma aplicação de cliente e duas vulnerabilidades reais que ela encontrou e comprovou.

Uma avaliação real de cliente em um SaaS empresarial multi-tenant

Um de nossos clientes usou o COS para avaliar uma aplicação SaaS empresarial multi-tenant, composta por uma aplicação de página única (SPA) no frontend, usada como cliente web, que consome centenas de endpoints de microsserviços que implementam a lógica de negócios.

Essa aplicação é particularmente interessante porque é difícil de avaliar de diferentes maneiras, tanto para pentesters humanos quanto para ferramentas determinísticas, como um scanner DAST:

Para as pessoas, é muito difícil garantir a cobertura completa da autorização e da lógica de negócios de centenas de microsserviços. Para as máquinas, o desafio não é o acesso. Scanners DAST modernos, como Snyk API & Web (o recurso de testes dinâmicos do Evo COS), autenticam-se em SPAs e enumeram sem muita dificuldade os endpoints por trás delas. O desafio está em quase tudo o que vem depois, porque falhas de autorização e de lógica de negócios não têm uma assinatura que possa ser identificada: decidir se uma determinada função deve poder chamar um endpoint específico ou se uma sequência de solicitações individualmente válidas resulta em algo que a aplicação nunca pretendeu exige saber para que serve a aplicação e o que cada agente deve poder fazer. Agora imagine isso em centenas de microsserviços: fica claro que se trata muito mais de um problema de raciocínio do que de cobertura. E essa é a parte que os testes dinâmicos ainda não automatizaram.

A solução agentiva do COS “explorou” a aplicação de forma metódica e guiada, aproveitando o poder dos LLMs:

• Verificações prévias: testou as credenciais fornecidas usando um navegador sem interface gráfica e confirmou que todos os recursos necessários da aplicação estavam acessíveis e que ela estava em condições de ser testada.

• Reconhecimento inicial: um subagente dedicado identificou a pilha de tecnologias da aplicação, os diferentes endpoints existentes e informações relevantes para a segurança, como o uso de um WAF, agentes de LLM acessíveis por interfaces de chat, o fluxo de autenticação e outros detalhes. É importante destacar que essa etapa também revelou informações sobre o modelo de negócios da aplicação. Nesse caso, o agente inferiu corretamente para que servia o produto, quem o usava e quais fluxos de trabalho tinham valor comercial real, usando apenas um ambiente de staging com pouca documentação e somente dados de teste pré-carregados. Essa inferência permitiu avaliar tudo o que veio depois em termos de impacto nos negócios, em vez de gravidade técnica.

• Testes e validação de vulnerabilidades: subagentes especializados foram iniciados para buscar classes específicas de vulnerabilidade com base nos resultados do reconhecimento. Subagentes adversariais validaram de forma cruzada cada descoberta para garantir que ela pudesse ser reproduzida independentemente e reduzir a probabilidade de falsos positivos.

• Encadeamento e validação de vulnerabilidades: vulnerabilidades individuais foram relacionadas logicamente para verificar se poderiam ser combinadas de forma a aumentar o impacto nos negócios. Subagentes adversariais também validaram de forma cruzada e reproduziram as cadeias de vulnerabilidades.

• Compilação do relatório: as descobertas foram reunidas em um documento que reproduzia o formato de um relatório elaborado por uma equipe humana, com resumo executivo e uma lista priorizada de ações para reduzir os riscos.

Essa avaliação foi feita com uma abordagem totalmente black box, ou seja, sem acesso ao código-fonte. Também podemos usar uma abordagem gray box, aproveitando o acesso ao código-fonte para melhorar a detecção e a eficiência, mas optamos por não fazer isso neste caso. De qualquer forma, estamos enfatizando o componente dinâmico dos testes: atacamos a aplicação de fora para dentro, como um invasor real faria.

Então, quais vantagens observamos com essa abordagem?

1. Conseguir identificar os objetivos de negócios das aplicações é uma grande vantagem, especialmente quando eles não são totalmente óbvios. Este era um ambiente de teste “desorganizado”, com poucos dados reais, o que tornou a tarefa difícil até para uma pessoa. Identificar os objetivos de negócios ajuda a frota de agentes a interpretar melhor o impacto de certas vulnerabilidades nos negócios.

2. Nossos agentes usam um navegador real e se adaptam a qualquer método de autenticação da aplicação, sem scripts específicos para cada alvo. Em uma avaliação, o login do cliente era protegido por autenticação de dois fatores baseada em tempo. Fornecemos a semente TOTP, e o agente gerou os códigos de uso único por conta própria como parte do processo para descobrir como fazer login, sem que tivéssemos configurado isso especificamente. Mais do que um recurso, isso demonstra confiabilidade: a autenticação é o ponto em que os testes automatizados mais costumam falhar silenciosamente. Uma avaliação que não passa da página de login não tem valor, por melhor que sejam os testes.

3. Com uma abordagem guiada, metódica e multiagente, aproveitamos os benefícios de agentes criativos que atuam como pessoas e, ao mesmo tempo, garantimos a cobertura dos testes, verificando sistematicamente cada microsserviço em busca de falhas de autorização, autenticação e lógica de negócios.

As vulnerabilidades encontradas

Nessa aplicação, encontramos 33 vulnerabilidades confirmadas, desde problemas de baixo impacto, como o uso de bibliotecas jQuery desatualizadas ou inseguras, até várias vulnerabilidades críticas. Entre elas, uma política de CORS insegura que permite que sites maliciosos arbitrários roubem tokens de autorização e ajam em nome de uma pessoa sem que ela precise interagir, além de falhas nos níveis de autorização que permitem que qualquer pessoa se promova a administradora do próprio tenant.

Para resumir, vamos destacar duas descobertas que, juntas, mostram os dois diferenciais dessa abordagem: encontrar o que outras ferramentas não conseguem encontrar por sua própria estrutura e comunicar o impacto real do que conseguem encontrar.

1. Comprometimento de todo um tenant por meio de atribuição em massa e falha na autorização em nível de função

Esse é exatamente o tipo de descoberta que um scanner DAST não consegue produzir por sua própria estrutura e que exigiria de um pentester humano profundo conhecimento da aplicação. Não há nenhum payload refletido para detectar nem erro óbvio a investigar: a falha está inteiramente na lógica de autorização da aplicação, em um endpoint administrativo legado que gerencia a configuração de um tenant inteiro.

Nosso agente identificou que um endpoint JSON legado, usado para salvar as configurações de contas de todo o tenant, fazia uma operação de upsert ilimitada de pares chave/valor, sem verificar no servidor as funções ou permissões, e não validava os parâmetros de signature e timestamp no estilo HMAC que, aparentemente, eram obrigatórios. Em seguida, o agente deduziu as consequências e as encadeou: a função com menos privilégios — a mesma atribuída a todos os funcionários comuns no login, que nem sequer podem abrir a interface administrativa — podia reescrever qualquer configuração crítica de segurança do tenant inteiro. Além disso, várias dessas configurações podiam levar ao comprometimento total.

Todo o processo, da descoberta à cadeia validada e reproduzida de forma independente, aconteceu em uma única execução sem supervisão humana. Uma equipe humana normalmente precisaria de dias conhecendo a aplicação para chegar à mesma conclusão.

Veja um trecho levemente editado do relatório do agente (todos os detalhes específicos do cliente e que identificam o produto foram generalizados):

Um endpoint administrativo legado de “salvar configurações da conta” faz uma operação de upsert ilimitada de pares chave/valor no armazenamento de configurações de todo o tenant, sem verificar no servidor as funções ou permissões e sem validar os parâmetros de consulta HMAC signature / timestamp associados. Qualquer usuário autenticado do tenant, inclusive quem tem a função com menos privilégios (que nem sequer pode acessar a interface administrativa), pode chamar o endpoint usando um token de acesso Bearer padrão e reescrever qualquer configuração crítica de segurança de todo o tenant.

[...]

Entre as chaves afetadas estão:

• Política de senhas: complexidade, tamanho mínimo, histórico e validade máxima.

• Política de bloqueio de autenticação: limite de tentativas malsucedidas e duração do bloqueio.

• Lista de bloqueio de tipos de arquivo executáveis para upload.

• Origens adicionais para a Content-Security-Policy.

• Domínio do remetente para e-mails enviados pelo tenant.

• Parâmetros de integração OAuth para uma integração empresarial de terceiros (ID do cliente, segredo do cliente, URL de login, recurso e indicador de ativação).

• Novas chaves arbitrárias definidas pelo invasor.

Causas-raiz:

1. Ausência de verificação de função/permissão no método de gravação. 2. Ausência de uma lista de permissões para as chaves que podem ser definidas; o endpoint aceita qualquer string como chave. 3. Falha ao validar os parâmetros de consulta signature / timestamp no estilo HMAC que, aparentemente, deveriam ser obrigatórios. O teste foi bem-sucedido mesmo com uma assinatura deliberadamente inválida.

O relatório prossegue detalhando as etapas necessárias para reproduzir essa vulnerabilidade e inclui uma seção sobre o impacto nos negócios, reproduzida aqui (também com informações generalizadas):

Impacto:

Como uma pessoa com o menor nível de privilégios tem controle total de leitura e gravação das configurações de segurança de todo o tenant, uma única conta do tenant comprometida ou maliciosa (ou qualquer pessoa de dentro da organização com acesso legítimo e poucos privilégios) pode:

1. Assumir o controle de todas as contas do tenant, enfraquecendo a política de senhas (por exemplo, definindo um tamanho mínimo de 1 caractere e removendo os requisitos de complexidade), desativando a política de bloqueio e, em seguida, tentando adivinhar senhas online no endpoint de login do tenant.

2. Distribuir malware pelo tenant, limpando a lista de bloqueio de arquivos executáveis e enviando executáveis nativos pelo recurso de upload de conteúdo, já acessível a usuários com poucos privilégios. Os arquivos enviados se propagam a todas as pessoas que acessam o conteúdo compartilhado do tenant.

3. Ativar ataques de cross-site scripting adicionando origens controladas pelo invasor à lista de permissões da Content-Security-Policy e ampliando script-src e connect-src para o tenant.

4. Transforme e-mails enviados em armas ao reescrever o domínio do remetente, fazendo com que as notificações do locatário pareçam vir de um domínio controlado pelo invasor (criando mensagens internas de phishing muito convincentes, assinadas e aprovadas pelo SPF/DKIM por meio da infraestrutura do locatário).

5. Sequestre a integração OAuth de terceiros reescrevendo a URL de login, o ID do cliente e os parâmetros de recurso. Isso redireciona a troca do código/token OAuth para a infraestrutura do invasor e permite coletar as credenciais OAuth que o locatário fornece ao que acredita ser seu provedor de identidade.

6. Mantenha o acesso entre sessões. As alterações permanecem mesmo após o token OIDC do invasor expirar, em cerca de 30 minutos, deixando o locatário com a configuração enfraquecida até que um administrador detecte manualmente e reverta cada chave.

7. Cause uma negação de serviço nas páginas administrativas gravando uma configuração malformada que trava a interface administrativa na próxima tentativa de análise.

O pré-requisito é um único token de acesso OIDC com o menor nível de privilégio — exatamente o token concedido no login a qualquer usuário real do locatário, incluindo todos os funcionários sem privilégios especiais. Não há outra barreira, escopo de administrador nem assinatura necessária.

Essa é a camada de raciocínio que os scanners tradicionais não conseguem alcançar: identificar uma gravação sem restrições, entender o impacto de cada configuração para o negócio e encadear algumas delas para comprometer todo o locatário.

2. Reflexão de origem no CORS: uma descoberta “trivial” que se torna incontestável

As configurações incorretas de compartilhamento de recursos entre origens (CORS) estão entre as vulnerabilidades web mais comuns. Praticamente qualquer scanner e qualquer profissional de testes competente sinalizará um endpoint que reflete a Origin da solicitação em Access-Control-Allow-Origin e, ao mesmo tempo, retorna Access-Control-Allow-Credentials: true. Detectar o problema não é a parte difícil.

A parte difícil é um dos problemas mais persistentes e menos discutidos do setor: uma vulnerabilidade é relatada, mas ninguém envolvido depois consegue traduzir o que ela realmente significa para o negócio. Isso acontece porque os níveis de gravidade comunicam bem a urgência, mas geralmente não deixam claras as consequências reais.

Uma descoberta chega como o nome de uma categoria e uma pontuação CVSS, e a equipe que a recebe precisa decidir sua importância com base em informações que nunca explicam o possível impacto. Então, recorre à análise mais simples e se guia apenas pelo número.

Tudo que é classificado como médio fica atrás do que é classificado como alto. O resultado não é apenas um atraso, mas uma alocação realmente equivocada de esforços: riscos reais permanecem intocados na lista de pendências enquanto as equipes corrigem descobertas mais fáceis de entender. A avaliação de riscos só é tão boa quanto a análise de impacto que a alimenta e, na maioria das ferramentas, cabe ao leitor interpretar essa análise.

Esta descoberta é um bom exemplo. Em um relatório típico de scanner, ela aparece como uma única linha de gravidade média sobre um cabeçalho permissivo. Na prática, isso significava que qualquer site visitado por um usuário conectado poderia ler sua sessão sem que ele percebesse e roubar os tokens usados para agir em seu nome, sem interação nem phishing.

A configuração incorreta estava no provedor de identidade, aplicava-se a todos os endpoints do aplicativo e fazia com que os tokens de acesso fossem retornados no corpo das respostas entre origens. Portanto, o problema vai muito além da simples higiene de cabeçalhos: ele permite assumir completamente a conta de qualquer usuário que acesse a página “errada”. E, ainda assim, a vulnerabilidade estava na categoria “média”.

O que mais impressionou nosso cliente e parceiro de design não foi apenas o fato de o agente ter encontrado o problema, mas também o que fez em seguida. Além de descrever o problema e seu impacto para o negócio, ele criou em poucos minutos uma prova de conceito totalmente funcional, que reproduziu o ataque completo em uma instalação padrão do navegador Chrome: basta abrir a página e ver seu próprio token de acesso ser exfiltrado para uma origem controlada pelo invasor.

Um desenvolvedor da equipe do cliente pôde ver, em vez de apenas ouvir dizer, que a descoberta permitia o comprometimento real de uma conta — sem proxy, experiência em segurança ou ferramentas especializadas. No fim das contas, essa será a diferença entre uma descoberta que é triada e outra que é corrigida.

Também é possível investigar descobertas diretamente na plataforma Evo: basta pedir que uma delas se explique em linguagem simples ou sugira uma correção. Assim, a demonstração e a solução ficam no mesmo lugar.

Essa é a diferença que importa para nós: não detectar CORS, o que é trivial, mas eliminar a distância entre uma descoberta que exige pouco esforço e uma demonstração incontestável de seu impacto no mundo real.

Duas descobertas, dois pontos fortes diferentes

Isso mostra o que diferencia o COS: a capacidade de investigar mais a fundo e comunicar o impacto de forma adequada.

Em termos de profundidade, trata-se de identificar uma falha de autorização que um scanner não consegue encontrar e que levaria dias para uma pessoa descobrir. Já em termos de comunicação, o objetivo é pegar uma descoberta que qualquer ferramenta consegue detectar e tornar incontestável seu impacto no mundo real.

Para um modelo competente, encontrar vulnerabilidades é a parte fácil. A parte difícil é comunicá-las bem, sem ruído e de um jeito que permita ao público certo agir. É nisso que concentramos grande parte do nosso trabalho de engenharia.

Veja em ação

Tudo o que mostramos acima veio de uma única execução sem supervisão em um aplicativo real. Em vez de acreditar apenas no que dizemos, é melhor conferir por conta própria.

Para entender como Pentesting com IA, Red Teaming de agentes e testes dinâmicos funcionam como um único sistema — e por que a cobertura contínua supera um pentest feito uma ou duas vezes por ano — comece pelo nosso anúncio de lançamento e inscreva-se no nosso próximo webinar, “Cobertura no nível de pentest na velocidade da IA”, em 2 de setembro.