O que capturar em cada finding
Para cada vulnerabilidade encontrada, documente:
Screenshot da exploração — mostrando o payload, a requisição e a resposta
Comando exato executado — copiado do terminal
Output completo — não só a linha relevante
URL ou endpoint afetado
Timestamp — data e hora em UTC
Impacto demonstrado — o que foi acessado ou comprometido
Estrutura de pastas por engajamento
Mantenha uma estrutura consistente para cada pentest. Facilita encontrar evidências semanas depois e montar o relatório final.
├── recon/ (nmap, subfinder, screenshots)
├── exploitation/ (payloads, outputs)
├── post-exploitation/
├── screenshots/ (numerados por finding)
└── report/ (rascunhos e final)
Logging automático do terminal
Grave automaticamente tudo que acontece no terminal. O comando script salva sessão completa. tmux pode ser configurado para logging por pane. Nenhum comando se perde.
script -a /root/engagement/terminal.log
# Ou via tmux: Ctrl+B → : → pipe-pane -o 'cat >> ~/log.txt'
Por que timestamps importam
Questões legais podem surgir sobre quando uma ação foi executada. Sempre use UTC para evitar confusão de fuso horário. Configure seu terminal para exibir timestamp em cada comando ou use date -u antes de ações críticas.
Executive Summary
Uma página, linguagem de negócios, sem jargão técnico. Responde: o que foi testado, o que foi encontrado em termos de risco, qual o impacto para o negócio, e qual a recomendação prioritária. Um CEO que não sabe o que é SQL injection deve entender completamente esta seção.
Escopo e Metodologia
Define exatamente o que foi testado (IPs, domínios, aplicações), o período do teste, as ferramentas utilizadas, e a metodologia seguida (PTES, OWASP). Importante para delimitar responsabilidade — o que não estava no escopo não foi testado.
Resumo dos Findings
Tabela com todos os findings, ordenados por severidade. Inclui: nome do finding, severidade (Critical/High/Medium/Low/Informational), sistema afetado, e status (Open). Permite visão rápida de toda a superfície de risco.
Findings Detalhados
Uma subseção para cada vulnerabilidade, com: descrição do problema, passos de reprodução, evidências (screenshots, outputs), impacto, severidade com CVSS score, e recomendação de remediação. É o coração técnico do relatório.
Recomendações Gerais
Além das correções específicas de cada finding, recomendações de postura de segurança: programa de patch management, treinamento de desenvolvedores, implementação de WAF, política de senhas, processo de vulnerability disclosure.
Apêndices
Outputs completos de ferramentas (Nmap, Nuclei), lista de IPs testados, metodologia detalhada, glossário de termos técnicos (útil para executives). Mantém o corpo do relatório limpo sem perder completude.
Para o Executive
"Um atacante externo conseguiu acessar o banco de dados de clientes contendo 50.000 registros, incluindo dados pessoais e financeiros, sem necessidade de credenciais. O impacto inclui risco regulatório (LGPD) e dano reputacional."
Para o Técnico
"O parâmetro id no endpoint GET /api/users/{id} não valida se o usuário autenticado tem permissão para acessar o recurso solicitado (IDOR — CWE-639). Payload: alterar id=1337 para qualquer valor retorna dados do usuário correspondente."
Remediação Clara
Toda remediação precisa ser acionável: não escreva "melhorar a segurança". Escreva "implementar verificação de autorização no endpoint /api/users/{id} para confirmar que o id solicitado pertence ao usuário autenticado antes de retornar os dados."
| Fator | Impacto no Score | Exemplo High vs Low |
|---|---|---|
| Attack Vector | Network = alto · Physical = baixo | SQLi via web (N) vs acesso físico ao server room (P) |
| Attack Complexity | Low = alto · High = baixo | Exploit público funcional (L) vs requer condição de race (H) |
| Privileges Required | None = alto · High = baixo | Sem autenticação (N) vs requer admin (H) |
| User Interaction | None = alto · Required = baixo | RCE direto (N) vs XSS exige clique da vítima (R) |
| Confidentiality Impact | High = dados sensíveis expostos | Dump de banco completo (H) vs versão de software (N) |
| Integrity Impact | High = dados podem ser alterados | SQLi com UPDATE (H) vs read-only (N) |
| Availability Impact | High = sistema pode ser derrubado | DoS via exploit (H) vs lentidão mínima (N) |
Título: Insecure Direct Object Reference (IDOR) na API de Perfil de Usuário
Severidade: High (CVSS 8.1 — AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N)
CWE: CWE-639 — Authorization Bypass Through User-Controlled Key
Endpoint: GET /api/v1/users/{id}/profile
Descrição: O endpoint de consulta de perfil de usuário não verifica se o ID solicitado pertence ao usuário autenticado. Qualquer usuário com uma conta válida pode acessar os dados pessoais de qualquer outro usuário simplesmente alterando o parâmetro id na URL.
Passos de Reprodução:
1. Autenticar com uma conta de usuário padrão e obter o token JWT
2. Realizar uma requisição GET para /api/v1/users/1337/profile
3. Alterar o valor de 1337 para 1338 no endpoint
4. Observar que os dados do usuário 1338 são retornados com HTTP 200
Evidências: [Screenshot da requisição no Burp Suite mostrando o parâmetro alterado e a resposta com dados do outro usuário — Figura 1.1]
Impacto: Um atacante autenticado pode enumerar e exfiltrar dados pessoais de todos os usuários da plataforma, incluindo nome completo, endereço de email, CPF e endereço físico. O sistema possui aproximadamente 45.000 usuários cadastrados. A exposição configura violação do Art. 46 da LGPD.
Remediação: Implementar verificação de autorização no backend para confirmar que o user_id extraído do token JWT corresponde ao id solicitado no path da requisição antes de retornar os dados. Considerar o uso de UUIDs em vez de IDs sequenciais para dificultar enumeração.
Referências: OWASP API Security Top 10 — API1:2023 Broken Object Level Authorization
CherryTree
Editor de notas hierárquico, muito usado em pentest. Permite organizar por cliente → fase → finding, com suporte a texto rico, código com syntax highlighting, e tabelas. Salva tudo em um único arquivo .ctb. Templates prontos disponíveis no GitHub (TCM Security, hwk3r).
Obsidian
Editor de notas baseado em Markdown com linking entre notas. Ideal para construir uma base de conhecimento pessoal de técnicas, ferramentas e referências ao longo do tempo. Plugins como Kanban e Calendar ajudam no gerenciamento de engajamentos.
Flameshot (Linux)
Ferramenta de screenshot com anotações integradas — setas, destaques, texto, blur para dados sensíveis. Essencial para capturar evidências com anotações durante o teste. Atalho: configurar para Print Screen no Kali.
Templates Prontos
Não crie do zero. TCM Security disponibiliza templates de relatório gratuitos no GitHub. O PNPT exige entrega de relatório real — praticar com o template oficial é preparação direta para o exame. PentesterLand agrega samples de relatórios públicos de bug bounty como referência.
Plextrac / Writehat
Plataformas de gerenciamento de relatórios de pentest. Permitem criar bibliotecas de findings reutilizáveis, gerar PDFs formatados automaticamente, e gerenciar múltiplos clientes. Plextrac tem versão gratuita. Writehat é open-source.
HackTricks & PentesterLand
Para referências técnicas durante a escrita: HackTricks tem descrições prontas de cada tipo de vulnerabilidade. PentesterLand tem links para writeups de bug bounty reais — excelente para ver como outros documentam findings similares aos seus.