redteam-report-template

Quando usar

Use esta habilidade para relatórios entregues ao cliente:

• Engajamentos de red-team externos com um SOW assinado
• Relatórios de pentest enviados para uma equipe de CISO / TI-Sec (não para um triador)
• Descobertas que serão revisadas por partes interessadas técnicas e não técnicas
• Relatórios que precisam de saída DOCX/PDF (não apenas markdown / interface da plataforma)

NÃO use para:

• Submissões de plataforma de bug-bounty (use report-writing / bugcrowd-reporting em vez disso)
• Memorandos rápidos de prova de conceito
• Relatórios de equipe interna

O formato de 6 seções por descoberta

Esta é a estrutura canônica que cada descoberta segue:

## Finding F##: <descriptive title>

**Severity:** Critical / High / Medium / Low / Informational
**Status:** Confirmed / Patched mid-engagement / Suspected (1 signal)
**CVSS 3.1:** <score> (<vector>)
**Affected Asset:** <URL / IP / app name>

### 1. Subject
<One-line statement of the issue. Plain English, no jargon.>

### 2. Observations
<Bulleted list of what was observed during testing. Concrete facts only — no interpretation yet.>
- <Observation 1>
- <Observation 2>
- ...

### 3. Description
<Technical explanation of the vulnerability. 2-4 paragraphs. Reader should understand WHY the observations indicate a vulnerability, what the underlying flaw is.>

### 4. Impact
<What an attacker could achieve. Concrete attacker outcomes, NOT generic CIA triad statements. Tie to the client's business — money, data, reputation, regulatory exposure.>

### 5. Recommendation
<Specific, actionable remediation. Vendor patch, configuration change, code-level fix. Avoid "implement security best practices" — say what specifically.>

### 6. Proof of Concept (PoC)
<Steps to reproduce, numbered. Include the exact HTTP requests, payloads, tools used.>

**Step 1:** <action>
```http
<requisição HTTP completa ou curl one-liner>

Step 2: <action>

<trecho da resposta>

Screenshot: ![F##_descriptive_name] (screenshots/F##_descriptive_name.png)

---

## Disciplinas de severidade e status

### Tabela de severidade (voltada para o cliente — diferente de apenas CVSS)

| Severidade | Definição de negócio | Faixa aproximada de CVSS |
|---|---|---|
| Crítica | Perda direta de receita/dados sem pré-requisitos | 9.0-10.0 |
| Alta | Tomada de controle total da conta/sistema com pré-requisitos limitados | 7.0-8.9 |
| Média | Exposição significativa de dados ou comprometimento parcial | 4.0-6.9 |
| Baixa | Divulgação de informações com caminho de exploração limitado | 0.1-3.9 |
| Informativa | Descoberta de higiene, sem exploração imediata | N/A |

### Campo de status (específico de red-team)

Este é o campo que distingue entregas de red-team de relatórios de bug-bounty. Use um dos seguintes:

- **Confirmado** — reproduzido várias vezes, com PoC completo
- **Confirmado; corrigido no meio do engajamento** — era reproduzível, o cliente corrigiu durante a janela de teste (ainda envie a descoberta — veja `mid-engagement-ir-detection`)
- **Confirmado; parcialmente reproduzível** — funciona, mas precisa de condições específicas
- **Suspeito (1 sinal)** — indicador único, não confirmado (raro — geralmente descartado)
- **Fora de banda** — descoberta de reconhecimento passivo, não testada ativamente

---

## Erros a evitar (de engajamento autorizado)

### 1. Não retifique descobertas que pararam de reproduzir
Se uma descoberta foi confirmada e depois parou de funcionar, isso é quase sempre um CORRETIVO DO CLIENTE, não uma descoberta falsa. A resposta correta é "Confirmado; corrigido no meio do engajamento" com timestamps mostrando quando parou de funcionar. Veja `mid-engagement-ir-detection`.

### 2. Não seja vago na seção de Impacto
Ruim: "Um atacante poderia potencialmente ser capaz de acessar dados do usuário, o que pode levar a..."
Bom: "Um atacante lê os dados do perfil de qualquer usuário. Demonstrado no usuário de teste `victim@target.com` às 14:22 IST."

### 3. Não generalize o impacto com CIA (Confidencialidade, Integridade, Disponibilidade)
Ruim: "Perda de confidencialidade e integridade dos dados do cliente"
Bom: "Acesso de leitura a 247.000 registros de clientes, incluindo cartões PAN, endereços, números de GST. A Seção 33 da LGPD da Índia exige a divulgação de violação em 72 horas ao DPB."

### 4. Não liste toda descoberta de reconhecimento como uma descoberta
Notas de reconhecimento (subdomínios encontrados, portas abertas, tecnologias identificadas) pertencem a um apêndice separado de **Reconhecimento / Superfície de Ataque**, não à lista de descobertas. Uma descoberta deve ter um resultado alcançável por um atacante.

### 5. Não enterre o PoC
Cada descoberta DEVE ter passos reproduzíveis. A seção PoC é o que prova a descoberta para um leitor cético. Se você não consegue escrever o PoC claramente, a descoberta provavelmente não está pronta para ser enviada.

---

## Estrutura do documento

1. Resumo Executivo (1 página, não técnico)

…