Como o Yaga Explora Aplicações Web

Do reconhecimento inteligente ao encadeamento multi-estágio de exploits

Aplicações web representam a superfície de ataque mais explorada no cenário atual de cibersegurança: 68% dos incidentes confirmados no Verizon DBIR 2025 envolvem uma aplicação web como vetor primário. Este artigo detalha como a Yaga conduz avaliações de segurança completas e autônomas contra aplicações web, desde o reconhecimento inicial e o fingerprinting de tecnologias até a construção de exploits e o encadeamento multi-estágio de vulnerabilidades. Descrevemos a arquitetura do Web Exploitation Pipeline, o mecanismo de interceptação e análise de requisições e respostas HTTP, o motor de detecção de tecnologias, o sistema de construção dinâmica de payloads e o Chain Engine, responsável por orquestrar ataques que combinam múltiplas vulnerabilidades em sequências de impacto máximo. Com base no benchmark HackerSec (150 casos web, cobrindo todo o OWASP Top 10), a Yaga alcança 98% de acurácia na detecção, 97,6% de resolução em cenários XSS e 93,3% de precisão em cadeias de exploração, superando todos os sistemas autônomos comparáveis por margem superior a 30 pontos percentuais.

1. Introdução

A web continua sendo o campo de batalha primário da segurança ofensiva. Aplicações web modernas combinam frontends reativos, APIs RESTful e GraphQL, microsserviços distribuídos, pipelines de autenticação complexos (OAuth2, SAML, JWT) e, cada vez mais, componentes integrados com Large Language Models (LLMs). Cada camada dessa pilha introduz classes de vulnerabilidades distintas, e a interação entre camadas cria oportunidades de encadeamento que ferramentas tradicionais de scanning não conseguem detectar.

Scanners automatizados como Burp Suite, OWASP ZAP e Nuclei operam predominantemente em modo de detecção pontual: cada requisição é analisada isoladamente, e cada vulnerabilidade é reportada como um achado independente. Essa abordagem falha em capturar cenários onde o impacto real emerge apenas da combinação de múltiplas vulnerabilidades: um IDOR que sozinho permite ler dados de outro usuário, mas que, combinado com um Stored XSS e uma falha de CSRF, permite o takeover completo de contas administrativas.

A Yaga foi projetada para operar dentro de um pentest web de forma completa e autônoma. Ela não se limita a disparar payloads pré-definidos contra endpoints conhecidos: mapeia a aplicação de forma inteligente, compreende a arquitetura e as tecnologias subjacentes, analisa o comportamento das requisições e respostas HTTP para inferir a lógica de negócio, constrói exploits sob medida para o contexto específico e, de forma crucial, encadeia múltiplas vulnerabilidades em sequências de ataque que maximizam o impacto demonstrável.

Este artigo apresenta, pela primeira vez em detalhe técnico, como cada fase do pipeline de exploração web da Yaga opera, desde o primeiro contato com uma URL-alvo até a geração do relatório final com provas de conceito encadeadas.

2. Metodologia: do início ao fim do pentest web

A Yaga segue o PTES (Penetration Testing Execution Standard) como framework operacional. Cada fase do pipeline mapeia a uma fase do PTES: Recon corresponde a Intelligence Gathering, Tech Profiler e Surface Mapper implementam Threat Modeling, o Motor de Detecção executa Vulnerability Analysis, Exploit Builder e Chain Engine correspondem a Exploitation e Post-Exploitation, e a geração de relatórios completa a fase Reporting.

O motor de testes implementa as 12 categorias do OWASP WSTG v4.2, totalizando mais de 90 test cases individuais: WSTG-INFO (11 tests), WSTG-CONF (12 tests), WSTG-IDNT/ATHN (21 tests), WSTG-ATHZ (4 tests), WSTG-SESS (9 tests), WSTG-INPV (19 tests), WSTG-ERRH/CRYP (8 tests), WSTG-BUSN (9 tests), WSTG-CLNT e WSTG-APIT. O WSTG fornece o "que testar"; o LLM fornece o "como testar".

A Yaga alinha seus testes ao OWASP ASVS v4.0.3, operando no nível L2 por padrão e cobrindo as 14 categorias de requisitos (V1 a V14). Cada finding é mapeado ao requisito ASVS violado: um JWT com algorithm confusion mapeia a V3.5.3, falha de rate limiting a V2.2.1, ausência de CSP a V14.4.3. Essa rastreabilidade viabiliza relatórios diretamente utilizáveis em processos de compliance.

Cada vulnerabilidade recebe identificador CWE (Common Weakness Enumeration), mapeamento para técnicas MITRE ATT&CK e score CVSS 4.0 contextualizado. A tríplice taxonomia (CWE para classificação, ATT&CK para contextualização tática, CVSS para priorização) permite integração com plataformas como DefectDojo e ThreadFix.

3. Arquitetura do Web Exploitation Pipeline

O pipeline de exploração web da Yaga opera em sete fases sequenciais, cada uma alimentando a próxima com dados estruturados. A inteligência é cumulativa: cada descoberta refina o modelo mental que o agente mantém da aplicação-alvo.

FIGURA 1: Pipeline de exploração web da Yaga, sete fases com Knowledge Graph central

3.1 Grafo de conhecimento central

No centro da arquitetura da Yaga está o Knowledge Graph: uma estrutura de dados em grafo que persiste durante toda a avaliação e conecta informações de todas as fases. É ele que permite ao agente sustentar, do primeiro request ao relatório final, o mesmo modelo mental que um especialista constrói sobre a aplicação enquanto a testa. Cada nó do grafo representa uma entidade descoberta (endpoint, parâmetro, cookie, header, tecnologia, vulnerabilidade), e as arestas representam relações (parâmetro_pertence_a_endpoint, endpoint_requer_autenticação, vulnerabilidade_depende_de_outra).

O grafo permite que o Chain Engine, na fase 6, responda a perguntas como: "existe um caminho de ataque partindo de um endpoint público que resulte em execução de código no servidor?", pergunta que só faz sentido para quem conduz o teste de ponta a ponta, com a visão acumulada de todas as fases.

3.2 Capacidades agênticas: conectando findings via grafo

A natureza agêntica é o que define a Yaga. Ela não é um modelo que responde perguntas, nem uma ferramenta que dispara verificações: é um agente de pentest autônomo que opera sobre o alvo, acumulando inteligência e conectando descobertas aparentemente independentes em cadeias de exploração avançadas.

Cada finding descoberto por qualquer fase do pipeline é imediatamente inserido no Knowledge Graph como um nó tipado. O agente então executa um ciclo contínuo de enriquecimento: para cada novo nó, ele avalia se existem arestas potenciais para nós já presentes no grafo, relações de dependência, pré-condição ou escalação que transformem achados isolados em caminhos de ataque completos.

Essa capacidade agêntica opera em três níveis:

1. Correlação automática: quando a Yaga descobre um IDOR em GET /api/users/:id e, separadamente, identifica um Stored XSS no campo de perfil, o grafo conecta ambos. O IDOR fornece acesso a dados de outros usuários, e o XSS inserido no perfil de um admin será executado quando qualquer usuário (incluindo administradores) visualizar aquele perfil. A cadeia IDOR+XSS emerge automaticamente do grafo, sem necessidade de regras pré-definidas.
2. Raciocínio de pré-condição: o agente raciocina sobre o que é necessário para explorar cada vulnerabilidade. Se um Blind SQLi requer autenticação, a Yaga busca no grafo por caminhos que forneçam credenciais: um endpoint de registro aberto, credenciais default, ou um JWT com secret fraco. Cada pré-condição não satisfeita se torna um sub-objetivo que direciona a exploração.
3. Escalação de impacto: achados de severidade média ou baixa que, conectados via grafo, produzem impacto crítico recebem reclassificação automática. Um Information Disclosure (baixo) que revela uma API key interna (médio), que permite acesso a um painel admin (alto), que expõe dados de todos os clientes (crítico): cada nó sozinho é tolerável, mas o caminho no grafo demonstra risco crítico real.

FIGURA 2: Findings individuais conectados por relações semânticas formam cadeias de exploração

3.2.1 Ciclo de enriquecimento contínuo do grafo

Para cada novo nó inserido no grafo, a Yaga dispara um ciclo de enriquecimento onde o LLM avalia arestas potenciais com nós existentes. As arestas são tipadas: depends_on (vuln B requer output de A), escalates_to (duas médias combinam em crítica), same_surface (mesmo componente afetado) e credential_flow (uma produz credenciais consumidas por outra). O enriquecimento é bidirecional: ao descobrir SSRF e depois um Redis interno sem autenticação, o grafo conecta retroativamente ambos, formando a cadeia SSRF-to-Redis, que não existiria se cada achado fosse avaliado isoladamente.

3.2.2 Propagação de contexto entre fases

Cada fase lê e escreve no Knowledge Graph, criando fluxo multidirecional. O perfil tecnológico da Fase 2 retroalimenta a Fase 1 (ao detectar Django, o crawler busca /__debug__/). Descobertas tardias disparam reexecução: se o SQLi revela endpoints internos, a Yaga reativa o crawler. A Fase 6 opera sobre o grafo acumulado de todas as fases: subdomínio de staging (Fase 1) + certificado expirado (Fase 2) + endpoint sem auth (Fase 3) podem compor uma cadeia crítica que nenhuma fase reconheceria individualmente.

3.2.3 Resolução de dependências e sub-objetivos

O Chain Engine implementa backward chaining aumentado com raciocínio LLM. Para alcançar um objetivo de impacto, decompõe em pré-requisitos: acesso admin requer credenciais, que podem vir de (a) SQLi na tabela de usuários, (b) JWT com secret fraco, ou (c) reset de senha vulnerável. Cada pré-requisito não satisfeito torna-se um sub-objetivo ativo. Se os caminhos diretos estão bloqueados (MFA no admin), a Yaga busca caminhos indiretos combinando os achados disponíveis no grafo.

3.2.4 Classificação dinâmica de severidade via grafo

A Yaga classifica severidade pelo contexto real do achado, não pela classe da vulnerabilidade: um Stored XSS em campo visualizado por admins, sem CSP, encadeável com CSRF, é crítico, enquanto um XSS refletido em página 404 é baixo. O Chain Engine recalcula a severidade quando novas arestas surgem: um Information Disclosure (baixo) que revela uma API key (CWE-798) desbloqueando acesso admin é reclassificado como alto. Isso alinha com o OWASP Risk Rating: Technical Impact × Business Impact.

4. Fase 1: reconhecimento e crawling inteligente

O reconhecimento web começa antes mesmo do primeiro request HTTP. A Yaga opera em três etapas de coleta progressiva.

4.1 Reconhecimento passivo

Antes de tocar o alvo, a Yaga coleta informações de fontes passivas:

• DNS Enumeration: resolução de subdomínios via wordlists curadas, Certificate Transparency logs (crt.sh) e enumeração via DNS bruteforce seletivo. Cada subdomínio descoberto é classificado por probabilidade de hospedar aplicação web (análise de registros A/AAAA/CNAME).
• OSINT Gathering: consulta a Shodan, Censys e SecurityTrails para identificar serviços expostos, banners, certificados TLS e portas alternativas.
• Historical Analysis: consulta ao Wayback Machine e Common Crawl para identificar endpoints antigos que podem ter sido removidos da aplicação atual mas permanecem acessíveis (path leakage).
• Google Dorking automatizado: queries estruturadas para encontrar arquivos de configuração expostos, páginas de debug, diretórios de backup e painéis administrativos indexados.

4.2 Crawling ativo e profundo

Após o reconhecimento passivo, a Yaga inicia o crawling da aplicação web usando uma abordagem que combina crawling tradicional com compreensão semântica.

4.2.1 Spider com compreensão de JavaScript

Diferente de crawlers tradicionais que apenas seguem links <a href>, a Yaga executa JavaScript no contexto da aplicação para descobrir:

• Rotas definidas em frameworks SPA (React Router, Vue Router, Angular Routes)
• Endpoints de API chamados via fetch() ou XMLHttpRequest
• Formulários dinâmicos renderizados por JavaScript
• WebSocket endpoints e Event Source connections
• Parâmetros construídos programaticamente

Listagem 1: extração de rotas a partir de bundles de frontend

4.2.2 Descoberta de endpoints baseada em contexto

A Yaga não se limita ao que o crawler encontra. Com base nas tecnologias detectadas (Fase 2), ela gera endpoints candidatos usando raciocínio do LLM:

• Se detecta Laravel: testa /telescope, /horizon, /_debugbar, /api/documentation
• Se detecta Django: testa /admin/, /__debug__/, /api/schema/
• Se detecta Spring Boot: testa /actuator/, /actuator/env, /actuator/heapdump
• Se detecta Node.js/Express: testa /.env, /package.json, /graphql, /playground

Essa geração contextual é um dos pontos onde o backbone LLM se diferencia: em vez de uma wordlist estática, a Yaga raciocina sobre quais endpoints são prováveis dado o stack tecnológico observado.

4.2.3 Cobertura e clustering

A cobertura estimada é calculada via captura-recaptura (estimador de Chapman):

Ê_total = (k₁ + 1)(k₂ + 1) m + 1 − 1

onde k₁ e k₂ são os endpoints de dois passes e m a interseção. Os endpoints são agrupados via DBSCAN com similaridade de cosseno:

sim(v_a, v_b) = v_a · v_b ‖v_a‖ · ‖v_b‖

sobre o feature vector v_e = [s_status, s_size, s_time, s_type, s_auth]. Similaridade acima de 0.92 agrupa endpoints, reduzindo testes redundantes.

4.3 Mapeamento de superfície de autenticação

A Yaga dedica atenção especial ao fluxo de autenticação, pois ele define a barreira entre a superfície pública e a superfície autenticada:

• Identifica formulários de login e registro
• Mapeia fluxos OAuth2/OIDC (authorization_endpoint, token_endpoint, redirect URIs)
• Analisa cookies de sessão (flags HttpOnly, Secure, SameSite, tempo de expiração)
• Detecta JWTs em headers Authorization ou cookies, e analisa claims e algoritmo de assinatura
• Identifica endpoints de reset de senha, MFA enrollment e account recovery

Listagem 2: mapa de superfície de autenticação (exemplo)

5. Fase 2: Technology Profiler, entendendo o stack

A identificação precisa das tecnologias da aplicação-alvo é crítica porque determina quais classes de vulnerabilidade são prováveis, quais payloads serão eficazes e quais técnicas de evasão serão necessárias. A Yaga implementa um sistema de fingerprinting multi-camada.

5.1 Fingerprinting de servidor e framework

Cada resposta HTTP carrega sinais que revelam o stack: o header Server (servidor web e versão), X-Powered-By (framework backend), o padrão de X-Request-Id, o formato do Set-Cookie, além de Content-Security-Policy, X-Frame-Options e Strict-Transport-Security, que indicam o nível de hardening. A Yaga extrai e cataloga cada header de cada resposta, construindo um perfil probabilístico.

TABELA I: Matriz de confiança de tecnologias (exemplo)

5.1.1 Camada de aplicação (comportamento)

Além dos headers estáticos, a Yaga analisa o comportamento da aplicação para inferir tecnologias. O formato de erro é um sinal forte: stack traces de Django, Laravel, Spring Boot, Express e ASP.NET têm padrões distintos. Uma resposta 500 com Traceback (most recent call last) confirma Python; um trace iniciando em at Object.<anonymous> (/app/server.js) confirma Node.js.

5.2 Detecção de WAF e mecanismos de proteção

Identificar Web Application Firewalls e mecanismos de proteção é essencial para calibrar payloads. Cada WAF deixa indicadores próprios: Cloudflare (header cf-ray, cookie __cfduid, página 403), AWS WAF (x-amzn-requestid), Akamai (AkamaiGHost), ModSecurity (padrão no corpo da resposta, paranoia level), Imperva (cookie incap_ses, visid_incap) e F5 BIG-IP ASM (prefixo de cookie TS, headers X-WA-).

A Yaga realiza detecção ativa de WAF enviando payloads canônicos conhecidos por acionar regras genéricas e analisando o padrão de bloqueio (código de status, corpo da resposta, headers adicionados). Isso permite que a Fase 5 (Exploit Builder) ajuste automaticamente os payloads para contornar as regras específicas detectadas.

6. Fase 3: análise de requisições e respostas HTTP

A análise de tráfego HTTP é uma das etapas em que a autonomia da Yaga fica mais evidente. Ela intercepta cada par de requisição e resposta e interpreta por conta própria o significado semântico da interação, usando o LLM para inferir a lógica de negócio por trás de cada campo, sem depender de um operador humano lendo o tráfego.

6.1 Interceptação e parsing estruturado

Para cada par request/response, a Yaga extrai e estrutura os dados, anotando pontos de interesse. No exemplo de um request de criação de pedido, ela marca parâmetros controlados pelo usuário e referências a outros recursos:

Listagem 3: análise anotada de um request

Do lado da resposta, a Yaga identifica exposição excessiva de dados e padrões sequenciais que viabilizam enumeração:

Listagem 4: análise anotada de uma response

6.2 Compreensão semântica da lógica de negócio

O LLM backbone permite que a Yaga vá além da análise sintática e compreenda a lógica de negócio implícita em cada fluxo:

• Fluxo de compra: a Yaga identifica que product_id + quantity + coupon_code formam uma transação financeira, e testa manipulação de preço (quantidade negativa, cupom aplicado múltiplas vezes, race condition no checkout).
• Fluxo de permissão: ao detectar roles (admin, customer, editor), a Yaga testa automaticamente acesso horizontal (trocar ID de recurso) e vertical (trocar role ou acessar endpoints administrativos com token de usuário comum).
• Fluxo de upload: ao encontrar endpoint de upload, a Yaga testa as variantes de bypass: extensão dupla, null byte, content-type mismatch, polyglot files e path traversal no nome do arquivo.

6.3 Análise de estado e fluxo de sessão

A Yaga rastreia o estado da sessão ao longo de múltiplas requisições, construindo um modelo de máquina de estados da aplicação e destacando as transições que representam caminhos de ataque (bypass de autenticação, escalação de privilégio, manipulação de preço no checkout).

6.4 Diferenciação de respostas para detecção cega

Para vulnerabilidades onde não há output visível (Blind SQL Injection, Blind SSRF, Blind XSS), a Yaga implementa técnicas avançadas de diferenciação de respostas:

• Time-based: mede o tempo de resposta com precisão de milissegundos, injeta um atraso controlado e compara com a baseline.
• Boolean-based: compara tamanho do body, estrutura JSON e código de status entre requisições verdadeiras e falsas.
• Error-based: analisa diferenças sutis em mensagens de erro que indicam processamento diferencial da entrada.
• Out-of-band: configura listeners externos (DNS callback, HTTP callback) para confirmar interações que não se refletem na resposta direta.

6.4.1 Detecção estatística e entropia

A detecção time-based usa o teste t de Welch para separar o sinal do ruído de rede:

t = T_probe − T_base √s²_probe/n_probe + s²_base/n_base

com threshold adaptativo τ_detect = μ_base + 3σ_base. A entropia de tokens é medida via Shannon, H(X) = −∑_i=1ⁿ p(x_i) log₂ p(x_i) (tokens seguros: H ≥ 5.0 bits/char), complementada com teste qui-quadrado para uniformidade. A diferenciação boolean-based usa a diferença normalizada:

Δ_bool = |len(R_true) − len(R_false)| max(len(R_true), len(R_false))

onde Δ acima de 0.1 com 5 repetições confirma a injeção. A listagem a seguir mostra o log interno de confirmação de um Blind SQLi por combinação de boolean e time-based:

Listagem 5: log interno de confirmação de Blind SQLi

7. Fase 4: motor de detecção de vulnerabilidades

Com o mapa da aplicação, o perfil tecnológico e o modelo de fluxo de negócio construídos, a Yaga entra na fase de detecção ativa. O motor opera de forma sistemática sobre todo o OWASP Top 10 Web, mas com priorização inteligente baseada no contexto já acumulado.

7.1 Priorização contextual de testes

Em vez de executar todos os testes em todos os endpoints, a Yaga prioriza com base na probabilidade de sucesso. O score de priorização de cada teste t para o endpoint e é:

P_{priority(t,e)} = P(vuln | tech_e) × w_impact(t) × (1 − P_waf(t))

onde P(vuln | tech_e) é a probabilidade condicional de vulnerabilidade dado o stack tecnológico, w_impact é o peso do impacto potencial (RCE = 1.0, data leak = 0.8, info disclosure = 0.3) e P_waf é a probabilidade de bloqueio pelo WAF detectado. A probabilidade condicional é derivada de dados históricos de benchmarks: um SQLi em PHP+MySQL tem P = 0.72, contra 0.15 para SQLi em Node.js+PostgreSQL com prepared statements.

TABELA II: Priorização de testes por contexto detectado

7.2 Cobertura completa do OWASP Top 10 Web

Cada teste executado é rastreado contra três referências simultâneas: test case ID do WSTG v4.2, requisito ASVS 4.0.3 aplicável e identificador CWE. Esse triple-mapping garante rastreabilidade entre standards e viabiliza relatórios de compliance.

7.2.1 A01, Broken Access Control

IDOR (troca de IDs de recursos entre sessões de privilégios diferentes), forced browsing, method tampering, CORS misconfiguration e directory traversal. A Yaga mantém sessões simultâneas por role (admin, editor, viewer, anonymous) e executa cada request com cada sessão, comparando respostas para detectar falhas horizontais e verticais. WSTG-ATHZ-01 a ATHZ-04. CWE-639, CWE-284, CWE-862, CWE-863. ASVS V4.1 a V4.3.

7.2.2 A02, Cryptographic Failures

Configuração TLS (protocolos fracos, cipher suites vulneráveis), dados sensíveis em trânsito sem HTTPS, mixed content, e detecção de hashing fraco (MD5/SHA1) via análise de respostas de reset. WSTG-CRYP-01 a CRYP-04. CWE-326, CWE-327, CWE-319, CWE-614. ASVS V6.1 a V6.4, V9.1.

7.2.3 A03, Injection

Cobertura de todas as classes de injeção, com payloads contextualizados ao DBMS e runtime detectados pelo Tech Profiler. A Yaga também detecta injeções de segunda ordem. WSTG-INPV-05 a INPV-18. CWE-89, CWE-79, CWE-78, CWE-94, CWE-90, CWE-643. ASVS V5.2 a V5.5.

TABELA III: Matriz de testes de injeção (payloads base e variantes de evasão)

Os payloads são adaptados ao runtime detectado: MySQL usa a função de atraso própria, PostgreSQL a sua, MSSQL o comando de delay correspondente.

7.2.4 A04, Insecure Design

Falhas de lógica de negócio (pular etapas do checkout, race conditions, manipulação de quantidade e preço), ausência de rate limiting (brute force em login, enumeração via timing) e anti-automação insuficiente. A Yaga analisa fluxos multi-etapa e executa race conditions para detectar TOCTOU. WSTG-BUSL-01 a BUSL-09. CWE-840, CWE-841, CWE-362. ASVS V11.1.

7.2.5 A05, Security Misconfiguration

Credenciais default em painéis admin, features desnecessárias habilitadas (debug mode, stack traces, directory listing), headers de segurança ausentes (HSTS, CSP, X-Content-Type-Options, X-Frame-Options), CORS permissivo e cloud storage público (S3/Azure/GCS). WSTG-CONF-01 a CONF-11. CWE-16, CWE-942, CWE-693. ASVS V14.1 a V14.5.

7.2.6 A06, Vulnerable and Outdated Components

A Yaga cruza versões detectadas (via fingerprinting) com bancos de CVE (NVD, GitHub Security Advisories, Snyk) e verifica se o exploit path é acessível na configuração real do alvo, reduzindo falsos positivos de componentes vulneráveis mas inalcançáveis. WSTG-INFO-02, INFO-08, INFO-09. CWE-937, CWE-1104. ASVS V14.2.

7.2.7 A07, Identification and Authentication Failures

Ataques a JWT (algoritmo none, confusão RS256/HS256, brute force de secrets fracos, manipulação de claims, JWK injection via jku/x5u), session fixation, credential stuffing com ausência de rate limiting e políticas de senha fracas. WSTG-ATHN-01 a ATHN-10. CWE-287, CWE-384, CWE-307, CWE-640. ASVS V2.1 a V2.10.

7.2.8 A08, Software and Data Integrity Failures

Ataques de desserialização (Java, PHP, Python, .NET), CI/CD tampering e ausência de Subresource Integrity em scripts de CDN externo. A Yaga detecta automaticamente o formato de serialização por magic bytes e seleciona gadget chains apropriadas. WSTG-INPV-14, INPV-16. CWE-502, CWE-829, CWE-494. ASVS V5.5, V10.1 a V10.3.

7.2.9 A09, Security Logging and Monitoring Failures

A Yaga verifica se suas próprias atividades de teste geram alertas: executa ataques ruidosos e depois checa se foram detectados e logados. A ausência de detecção de um pentest ativo indica falha de resposta a incidentes. WSTG-ERRH-01, ERRH-02. CWE-778, CWE-223. ASVS V7.1 a V7.4.

7.2.10 A10, Server-Side Request Forgery (SSRF)

SSRF clássico (manipulação de URLs para acessar serviços internos), Blind SSRF (confirmado via DNS/HTTP callback), SSRF via redirect e acesso a metadata de cloud. A Yaga identifica parâmetros que aceitam URLs (url, webhook, callback, avatar, import) e testa acesso a endpoints internos, ao endpoint de metadata de cloud e a portas internas, com bypass via encoding alternativo de IP, DNS rebinding e encadeamento com open redirects. WSTG-INPV-19. CWE-918, CWE-611. ASVS V12.6.

8. Fase 5: Exploit Builder, construção dinâmica de exploits

Identificar uma vulnerabilidade é apenas metade do trabalho em um pentest: o que comprova risco é a exploração. Quando o motor de detecção confirma um achado, a Yaga constrói um exploit funcional que demonstra o impacto real, sempre dentro do escopo autorizado do engajamento.

8.1 Arquitetura do Exploit Builder

O Exploit Builder opera em três estágios. No Estágio 1 (análise de contexto), ele recebe do Knowledge Graph o tipo de vulnerabilidade confirmada, o endpoint e parâmetro afetados, as tecnologias do stack (para calibrar o payload), o WAF e as proteções ativas (para calibrar a evasão), o nível de privilégio atual e o objetivo de impacto desejado (definido pelo Chain Engine ou por default).

No Estágio 2 (geração de payload), o LLM gera payloads sob medida, não a partir de uma lista estática. Cada payload é construído considerando o contexto de injeção, as regras do WAF e a política de CSP observadas:

Listagem 6: raciocínio de geração de payload (exemplo XSS)

No Estágio 3 (validação e refinamento), cada exploit gerado é testado antes de entrar no relatório: é executado contra o alvo, a Yaga confirma que o efeito esperado ocorreu, e, se falhou, analisa o motivo (WAF block, CSP violation, encoding issue) e gera uma variante. Por fim, o payload é reduzido ao mínimo necessário para reprodução confiável.

8.1.1 Espaço de busca e otimização

O espaço de brute force é |S| = |Σ|^ℓ, com tempo t = |S| / (r × k). Um brute force de secret de JWT é considerado viável se a entropia da chave H_key = log₂(|S_secret|) < 40 bits. O fuzzing usa um power schedule no estilo AFL, E(s) = α × (1 / f(p(s)))^β, onde seeds em paths raros recebem mais mutações. A evasão de WAF é tratada como inferência bayesiana, com a posterior atualizada a cada iteração:

P(evasão | payload) = P(payload | evasão) × P(evasão) P(payload)

8.2 Construção de exploits por classe de vulnerabilidade

Ao confirmar um SQLi, o Exploit Builder escala automaticamente: identifica o DBMS, enumera o schema (tabelas, colunas, tipos), comprova por leitura o acesso aos dados sensíveis e, quando o privilégio permite, evidencia o caminho até o impacto máximo. A figura abaixo resume o pipeline de escalação.

FIGURA 3: Escalação de SQL Injection, da detecção à demonstração de impacto

A listagem a seguir ilustra uma prova de conceito gerada pela Yaga para extração boolean-based cega, contra um alvo de laboratório e com fins de demonstração de impacto no relatório:

Listagem 7: prova de conceito ilustrativa, Blind Boolean SQLi

8.2.1 Do alert ao impacto real (XSS)

A Yaga não se contenta com um alert(1). O Exploit Builder demonstra o impacto real do XSS conforme o contexto: roubo de sessão (replay do cookie como admin), phishing in-context (login falso dentro da própria aplicação), encadeamento com CSRF para executar ações como a vítima, e, no caso de Stored XSS, propagação (o payload se auto-replica quando outros usuários visualizam o conteúdo).

FIGURA 4: Escalação de impacto de XSS

8.2.2 Do request ao comprometimento de cloud (SSRF)

Ao confirmar um SSRF em um parâmetro de URL, a Yaga demonstra a cadeia de impacto em etapas: confirma o acesso a serviços de loopback, faz um port scan interno de portas comuns, tenta alcançar o endpoint de metadata de cloud (169.254.169.254) para verificar, por leitura, se há exposição de credenciais temporárias de IAM. Confirmada a exposição, a Yaga registra o suficiente para o cliente reproduzir e corrigir, sem utilizar as credenciais além do necessário para evidenciar o acesso. Todo o fluxo ocorre dentro do escopo autorizado e serve para dimensionar o impacto de negócio (comprometimento potencial da conta de cloud) no relatório.

9. Fase 6: Chain Engine, encadeamento de exploits web

O Chain Engine é o diferencial arquitetural mais significativo da Yaga. Enquanto as Fases 4 e 5 operam sobre vulnerabilidades individuais, o Chain Engine raciocina sobre combinações de vulnerabilidades para construir cadeias de ataque com impacto máximo.

9.1 Modelo de grafos de ataque

O Chain Engine modela vulnerabilidades como nós em um grafo direcionado, onde cada nó possui pré-condições (o que é necessário antes de explorar) e pós-condições (o que é obtido após explorar). As arestas conectam pós-condições de uma vulnerabilidade às pré-condições de outra, e o objetivo é encontrar caminhos do estado inicial (acesso anônimo) até estados de impacto máximo (account takeover, data breach e similares).

FIGURA 5: Grafo de ataque resolvido, cadeia de 5 vulnerabilidades até Admin Takeover

9.2 Algoritmo de resolução de cadeias

O Chain Engine combina três mecanismos: busca em grafo (BFS/DFS) para enumerar caminhos possíveis entre o estado inicial e os estados-objetivo; raciocínio LLM para avaliar a viabilidade prática de cada caminho e gerar passos intermediários que a busca formal não capturaria; e validação empírica, executando cada cadeia candidata contra o alvo real para confirmar que as transições funcionam na prática.

9.2.1 Grafos e shortest path

O grafo G = (V, E, w) usa peso de dificuldade w(u, v) = (1 − P_exploit) × (1 + P_detect) × c_priv. O caminho de ataque mais provável é o shortest path via Dijkstra, d(v) = min_u∈pred(v) [d(u) + w(u, v)]. Os nós pivô são identificados por betweenness centrality:

C_B(v) = ∑_s≠v≠t σ_st(v) σ_st

corrigir um pivô quebra múltiplas cadeias de uma vez. Os alvos são priorizados por PageRank, PR(v) = (1 − d)/N + d ∑_u∈in(v) PR(u)/|out(u)|, com d = 0.85. O impacto combinado é multiplicativo, I_chain = 1 − ∏_v∈path (1 − I(v)): três achados médios (I = 0.5) produzem I_chain = 0.875 (alto).

9.3 Padrões comuns de encadeamento web

A Yaga reconhece e prioriza padrões de encadeamento empiricamente validados. Os cinco mais recorrentes, apresentados como cadeias de impacto (do insumo inicial ao impacto final), são:

• Padrão 1, Information Disclosure → Authentication Bypass: um endpoint de debug exposto ou mensagens de erro verbosas revelam secrets (API keys, credenciais de banco, JWT secrets), que levam a acesso administrativo via chave vazada.
• Padrão 2, XSS → CSRF → Privilege Escalation: um Stored XSS no perfil é executado quando um admin visualiza o conteúdo, roda no contexto privilegiado e dispara uma requisição que cria uma nova conta admin, resultando em acesso persistente.
• Padrão 3, SSRF → Serviço Interno → Comprometimento de Cloud: um SSRF alcança o endpoint de metadata de cloud, obtém credenciais temporárias de IAM e permite pivô para storage e serviços internos, com potencial de data breach cross-tenant.
• Padrão 4, SQL Injection → privilégio de escrita → caminho para RCE: a Yaga confirma o SQLi e verifica, por leitura, se a conta de banco possui privilégio de escrita em disco. Com o privilégio confirmado, o caminho até execução remota de código está aberto e o achado é classificado como crítico. A comprovação para o relatório é a leitura do privilégio e do caminho gravável, não a gravação de um artefato no servidor.
• Padrão 5, Insecure Deserialization → RCE: um cookie serializado é identificado por magic bytes, a classpath é inferida a partir de erros, e a cadeia de gadgets correspondente é identificada. A confirmação é feita por sinal out-of-band (callback DNS ou HTTP), que comprova a execução sem persistir qualquer artefato no alvo. Aplicável a Java, PHP, Python e .NET.

9.4 Métricas de performance do Chain Engine (web)

Dentro dos 150 casos web do benchmark HackerSec, 45 envolvem encadeamento de vulnerabilidades:

TABELA IV: Resultados de encadeamento web (N = 45 casos com cadeia)

Burp Suite Pro em modo de scan automatizado, sem operador humano. A comparação com o Burp Suite se refere ao modo automatizado: com um pentester humano operando a ferramenta, os resultados seriam diferentes. O valor da automação não é substituir o pentester, mas amplificar sua capacidade e cobrir superfícies que a análise manual não alcançaria no tempo disponível.

10. Evasão de proteções e geração de relatório

Aplicações web modernas raramente estão desprotegidas. WAFs, CSPs, rate limiters e input validators são defesas comuns que neutralizam a maioria dos payloads de ferramentas automatizadas genéricas. A Yaga implementa técnicas de evasão adaptativas e, ao final, consolida tudo em um relatório de pentest profissional.

10.1 Bypass de WAF adaptativo

Quando um payload é bloqueado pelo WAF, a Yaga não abandona o teste: inicia um ciclo de refinamento. Ela analisa o padrão de bloqueio, gera uma variante aplicando técnicas como URL/Unicode encoding, case alternation, inserção de comentários e payload splitting, e testa novamente, iterando até confirmar o bypass ou esgotar as variantes.

FIGURA 6: Ciclo adaptativo de bypass de WAF

10.2 Bypass de CSP

Content Security Policy é uma defesa crítica contra XSS. A Yaga analisa a CSP da aplicação e identifica vetores de bypass: fontes de CDN que permitem carregar pacotes arbitrários, endpoints que aceitam callback e podem ser abusados por JSONP/script gadgets, e políticas com 'self' sem 'strict-dynamic' nem nonce/hash, que deixam a proteção mais fraca do que seria possível. O resultado é uma lista de vetores priorizados por probabilidade de sucesso dado o restante da política observada.

10.2.1 Detecção de rate limiting

O rate limiting é detectado via regressão linear sobre os tempos de resposta (t_i = α + βi, com β > 0 indicando throttling) e via CUSUM, S_i = max(0, S_i−1 + (x_i − μ₀ − k)). Um changepoint em S_i > h calibra a velocidade máxima segura, r_max = changepoint / Δt.

10.3 Bypass de rate limiting

Para endpoints protegidos por rate limiting, a Yaga testa rotação de IP (via headers X-Forwarded-For, X-Real-IP), parameter pollution para contornar contagem baseada em chave de cache, distribuição temporal dos requests abaixo do threshold, e variação de endpoint (o mesmo recurso acessível via paths diferentes, como /api/v1/login contra /api/v2/login).

10.4 Fase 7: geração de provas de conceito e relatório

Cada vulnerabilidade confirmada gera um pacote de PoC completo: um script de reprodução autocontido, o par request/response raw exato, screenshots automatizados (para XSS e vulnerabilidades visuais, via headless browser), o diagrama de cadeia (para vulnerabilidades encadeadas) e a classificação (OWASP category, CWE ID, score CVSS calculado). Antes de chegar ao cliente, cada achado passa pela validação de um especialista da HackerSec, que confirma a exploração e a classificação atribuída.

10.4.1 CVSS 4.0 contextual

A Yaga calcula o CVSS 4.0 preenchendo os grupos de métricas com evidência real coletada durante o pentest, em vez de deixá-los como "Not Defined" (o padrão de scanner genérico, que equivale ao pior caso e infla a severidade). O grupo Threat (Exploit Maturity) é derivado do resultado real de exploração obtido pelo agente; o grupo Environmental (Confidentiality, Integrity e Availability Requirements, mais as Modified Base Metrics) é derivado da classificação de dados do ativo e dos controles efetivamente observados em runtime: um componente atrás de WAF eleva a Attack Complexity, e dados regulados (LGPD/GDPR) forçam o Confidentiality Requirement para High. Essa contextualização é a mesma base metodológica descrita no artigo sobre a metodologia de criticidade contextual da Yaga, aqui aplicada ao eixo web.

10.4.2 Estrutura do relatório

O relatório final segue o formato de pentest profissional, em seis blocos: (1) Executive Summary (escopo, resumo de achados por severidade, risco geral e recomendação); (2) Metodologia (ferramentas, cobertura de testes, limitações); (3) Achados detalhados por severidade, cada um com título e classificação (OWASP/CWE/CVSS), descrição técnica, endpoint e parâmetro afetados, prova de conceito, impacto demonstrado, cadeia de exploração quando aplicável e recomendação de remediação; (4) Cadeias de exploração (diagrama de cada cadeia, impacto combinado contra individual, priorização de remediação baseada em cadeia); (5) Análise de superfície de ataque (mapa de endpoints, perfil tecnológico, postura geral); e (6) Apêndices (requests/responses relevantes, scripts de PoC completos, configurações de ferramentas).

11. Estudos de caso e resultados de benchmark

Os estudos a seguir ilustram o pipeline completo da Yaga contra cenários realistas do benchmark HackerSec. Em seguida, apresentamos os resultados quantitativos sobre os 150 casos web e a comparação com ferramentas tradicionais. Vale a ressalva metodológica que vale para todo o YagaBench: uma vulnerabilidade só entra na contagem quando foi efetivamente explorada e confirmada por um especialista da HackerSec.

11.1 E-commerce: do XSS ao account takeover em massa

Alvo: plataforma de e-commerce (PHP + Laravel + MySQL + Vue.js). No reconhecimento, a Yaga descobre 47 endpoints de API, o painel admin em /nova e um endpoint de debug (/telescope) acessível sem autenticação. O profiling identifica Laravel 9.x, PHP 8.1, MySQL 8.0, Vue 3.x e Sanctum. A análise HTTP revela tokens com SameSite=Lax (não Strict) e CSRF token presente mas não validado em rotas de API.

Vulnerabilidades: Stored XSS no campo "nome do produto" (input admin, exibido para todos), CSRF ausente em POST /api/user/email/update, debug endpoint exposto e IDOR em GET /api/orders/{id}. Cadeia: a Yaga obtém a chave da aplicação pelo debug endpoint, o Stored XSS é visualizado por usuários e admins, executa a troca de email da vítima via CSRF, solicita reset de senha e, com acesso à conta, escala para admin via IDOR no endpoint de roles. Impacto: account takeover em massa, qualquer visitante que visualizar o produto comprometido tem a conta sequestrada. Nenhuma vulnerabilidade individual seria Crítica; a cadeia de 5 resulta em impacto Crítico.

11.2 API financeira: de Blind SQLi a data breach

Alvo: API REST financeira (Node.js + Express + PostgreSQL + JWT). O reconhecimento encontra 23 endpoints documentados via Swagger exposto; o profiling identifica Express 4.18, PostgreSQL 15 e Sequelize ORM (com raw queries em 2 endpoints). Vulnerabilidades: Blind SQLi (boolean-based) em GET /api/transactions?search=, chave pública JWT acessível, user enumeration via timing e excessive data exposure em /api/users/:id. Cadeia: o SQLi dá acesso de leitura ao schema, à tabela de usuários (hashes bcrypt, saldos) e à tabela de chaves de API de serviço com permissões elevadas; essas chaves alcançam endpoints admin capazes de exportar a base de clientes. A Yaga registra apenas as amostras necessárias para comprovar o acesso. Impacto: dados financeiros de todos os clientes expostos a partir de um parâmetro de busca. Tempo total de exploração: 23 minutos (com GPT 6 como backend).

11.3 SaaS multi-tenant: de SSRF a comprometimento de cloud

Alvo: aplicação SaaS (Python + Django + Redis + AWS), deploy em ECS Fargate. Vulnerabilidades: SSRF na funcionalidade de "importar dados via URL" (POST /api/import), Redis interno sem autenticação e IAM role com permissões excessivas. Cadeia: o SSRF alcança o metadata da cloud, obtém as credenciais temporárias da IAM role do container, enumera buckets de storage e encontra um com dados de todos os tenants, evidenciando acesso de leitura cross-tenant; adicionalmente, via o mesmo SSRF, alcança o Redis interno. Impacto: comprometimento de dados de todos os tenants. A SSRF isolada seria Alta; com acesso a credenciais de cloud e serviço interno, o impacto é Crítico.

11.4 Acurácia por categoria OWASP Top 10

TABELA V: Detecção web da Yaga por categoria OWASP (N = 150)

11.5 Performance detalhada em XSS

XSS é historicamente um dos vetores mais complexos para automação. A Yaga alcança 97,6% de resolução, superando o Burp Suite Pro por 49,4 pontos percentuais, com os maiores gaps em mXSS (100% contra 25%) e Blind XSS (90% contra 30%).

TABELA VI: Detecção de XSS por subtipo

11.6 Performance por LLM backend

TABELA VII: Acurácia web por LLM backend (N = 150)

Opus 5 lidera em detection rate e chain accuracy em cenários web (predominantemente black-box). GPT 6 é cerca de 7% mais rápido, mantendo acurácia comparável.

11.7 Comparação com ferramentas tradicionais

TABELA VIII: Yaga contra ferramentas tradicionais (150 cenários web)

A comparação evidencia dois paradigmas distintos: detecção pontual via signatures contra exploração contextual via raciocínio. Nuclei e Nikto completam rápido, mas detectam apenas vulnerabilidades com templates pré-existentes. O Burp Suite Pro é significativamente mais capaz, mas ainda depende de regras estáticas e não realiza encadeamento autônomo.

12. Limitações, trabalho futuro e conclusão

12.1 Limitações atuais

• Lógica de negócio complexa: vulnerabilidades que exigem compreensão profunda de um domínio específico (por exemplo, manipulação de regras contábeis) permanecem desafiadoras. A taxa de detecção de business logic flaws cai para 85% em cenários altamente especializados.
• Aplicações com JavaScript pesado: SPAs com fluxos multi-etapa que requerem interação precisa de UI (drag-and-drop, canvas, WebGL) podem não ser completamente exploradas pelo crawler.
• Rate limiting agressivo: alvos com limites extremamente restritivos (menos de 10 req/min) forçam o pipeline a operar em velocidade reduzida, aumentando o tempo total de avaliação.
• Zero-day em frameworks modernos: a Yaga detecta CVEs conhecidos com mais de 98% de acurácia, mas a descoberta de zero-days em frameworks bem mantidos permanece rara em modo black-box.
• Custo computacional: cada avaliação web completa com backend frontier consome entre US$ 15 e US$ 40 em tokens de LLM, dependendo da complexidade da aplicação.

12.2 Direções futuras

• Fine-tuning por vertical: modelos ajustados para domínios específicos (fintech, healthcare, e-commerce) para melhorar a detecção de lógica de negócio.
• Visual understanding: integração com modelos multimodais para analisar a UI renderizada, não apenas o DOM e o HTTP.
• Interfaces de direção em tempo real: aprofundar a colaboração entre o especialista da HackerSec e a Yaga durante a operação, tornando ainda mais fluida a direção humana que já guia a estratégia ofensiva do agente, combinando a intuição do especialista com a velocidade de execução da Yaga.
• Modo de monitoramento contínuo: operação como parte do pipeline CI/CD, avaliando cada deploy automaticamente.

12.3 Conclusão

O pipeline de sete fases descreve um pentest web completo, conduzido de ponta a ponta pelo próprio agente: a Yaga raciocina sobre a aplicação, compreende sua arquitetura, constrói exploits sob medida e encadeia vulnerabilidades em sequências de impacto máximo. Os números sustentam a tese: 98% de acurácia em 150 cenários web, 97,6% em XSS e 93,3% em encadeamento. A arquitetura implementa PTES, WSTG, ASVS e CWE de ponta a ponta, viabilizando conformidade com PCI DSS 11.3, SOC 2 e ISO 27001 A.12.6.

A inovação central é o Knowledge Graph e o Chain Engine operando em conjunto. A Yaga não entrega uma lista plana de achados desconectados: ela transforma cada achado em um grafo de ataque demonstrável: não "existe XSS e falta CSRF token", mas "um atacante anônimo injeta JavaScript no perfil, executa como admin e forja uma requisição que cria conta admin, cinco passos do anonimato ao controle total". Os resultados do YagaBench v2.8 confirmam que a orquestração importa mais que o modelo: modelos isolados alcançam de 27% a 58%, e a Yaga eleva para 97% a 98,8%, uma multiplicação de 2x a 3,6x.

A Yaga representa a convergência do raciocínio LLM com uma metodologia ofensiva estruturada. À medida que os modelos evoluem, a arquitetura garante que as melhorias se traduzam em resultados superiores. O futuro não é substituir o pentester, mas amplificar: a Yaga executa em minutos o que levaria dias, enquanto os especialistas da HackerSec direcionam a estratégia, acompanham a operação, validam cada achado antes da entrega e refinam continuamente a capacidade ofensiva do agente, liberando o especialista para a lógica de negócio complexa e o threat modeling estratégico.

Referências