Um scan diz "talvez haja SQLi aqui". Um pentester prova que há, mostra o que dá para roubar, e diz como corrigir. Essa é a diferença que você está aprendendo.

PARTE B — O ciclo de 7 etapas (o coração do módulo)

Decore este ciclo. Todo teste, de qualquer alvo, segue esta espinha (baseada em PTES/NIST SP 800-115):

1. ESCOPO  →  2. RECON  →  3. MAPEAMENTO  →  4. IDENTIFICAÇÃO  →
5. VALIDAÇÃO/EXPLORAÇÃO  →  6. IMPACTO  →  7. RELATÓRIO

Etapa 1 — Escopo & regras de engajamento

• O que: definir alvos in-scope e out-of-scope, janela, limites, contato de emergência. Assinar o ROE.
• Entregável: o AUTORIZACAO_ROE.md preenchido.
• 🔑 Regra: nada fora do escopo — nem "só para ver".

Etapa 2 — Reconhecimento (conhecer o alvo)

• Passivo (sem tocar no alvo): OSINT — crt.sh (subdomínios), Wayback, Google dorks, GitHub (segredos), DNS.
• Ativo (tocando de leve): ler headers, robots.txt, sitemap.
• Ferramentas: dig, crt.sh, httpx, gitleaks. Projeto: Ex. 1, 16, 21.

Etapa 3 — Mapeamento (desenhar a superfície)

• O que: enumerar tudo — portas, serviços, rotas, parâmetros, formulários, endpoints de API, tecnologias.
• Ferramentas: nmap (portas/serviços), gobuster/ffuf (diretórios), Burp (spider/mapa), nuclei (fingerprint).
• Entregável: o mapa da superfície de ataque. Projeto: Ex. 2, 6.

Etapa 4 — Identificação de vulnerabilidades

• O que: para cada ponto da superfície, levantar possíveis falhas — cruzando com as 11 classes do Módulo 4.
• Automático + manual: nuclei/scanners dão pistas; o olho humano acha lógica de negócio e authz (que ferramenta não pega).
• Ferramentas: nuclei, Burp Scanner, mais o raciocínio (o mapa de confiança do Módulo 4).

Etapa 5 — Validação / Exploração (provar, de forma controlada)

• O que: confirmar que a falha é real com uma prova mínima (PoC). Não "aproveitar" além do necessário.
• 🔑 Ético: prova mínima, dados pentest_, nada destrutivo em produção. O objetivo é demonstrar, não causar dano.
• Ferramentas: Burp (Repeater), curl, scripts Python (Módulo 3). Projeto: os passos "VULNERÁVEL" dos exercícios.

Etapa 6 — Pós-exploração & avaliação de impacto

• O que: responder "e daí?" — o que essa falha permite? Ler dados de outros? Virar admin? Mover-se lateralmente? Custar dinheiro?
• É aqui que você atribui severidade (Parte D) — o impacto de negócio, não só a existência técnica.

Etapa 7 — Relatório (o produto de verdade) ⭐

• O que: comunicar tudo de forma que o dono entenda e corrija. É o entregável pelo qual um pentest é pago.
• Detalhado na Parte D.

PARTE C — As ferramentas (o que cada uma faz)

Não decore comandos — entenda o papel. A ferramenta é o martelo; o raciocínio é o carpinteiro.

Regra de ouro: a ferramenta gera pistas; você valida e interpreta. Um nuclei que aponta 20 "achados" pode ter 18 falsos positivos — quem separa é você.

Comandos-âncora (em alvo SEU/autorizado):

nmap -sV -F SEU_HOST                    # serviços/versões nas portas comuns
./httpx -u https://SEU_ALVO -tech-detect -status-code -title
./nuclei -u https://SEU_ALVO -severity medium,high,critical -rl 10

PARTE D — O relatório (o entregável profissional) ⭐

O que separa um pentester de um "rodador de ferramenta" é isto. Um bom laudo tem duas audiências:

• Sumário executivo (1 página, para o dono/gestor não-técnico): quantos achados, quão grave, o risco de negócio, e o que fazer primeiro. Sem jargão.
• Achados técnicos (para quem vai corrigir): cada um no formato abaixo.

Estrutura de um achado

Título:        <ex.: Leitura pública de PII de leads via anon key>
Severidade:    Crítica / Alta / Média / Baixa   (+ nota CVSS, ver abaixo)
Componente:    <endpoint/tabela/serviço afetado>
Descrição:     <o que é a falha, em 2–3 frases>
Evidência (PoC): <o comando exato + a saída que prova — reproduzível>
Impacto:       <o que um atacante consegue: dados? dinheiro? acesso?>
Correção:      <como consertar, passo a passo>
Referências:   <OWASP/CWE/CVE relacionados>

Severidade: CVSS e o P0–P3 do seu projeto

• CVSS (Common Vulnerability Scoring System) é o padrão da indústria: uma nota de 0–10 baseada em fatores (facilidade de explorar, impacto). Crítico ≈ 9–10, Alto ≈ 7–8.9, Médio ≈ 4–6.9, Baixo < 4.
• No seu programa isso vira P0–P3 (o roadmap do INVENTARIO-SUPERFICIE.md). Use os dois: CVSS comunica com o mercado; P0–P3 organiza a correção.

Como priorizar (a pergunta de impacto)

Ordene os achados por: um atacante ganha dinheiro ou dados? → crítico. Ganha acesso (admin)? → alto. Só vaza informação? → médio. Só incomoda? → baixo. (É a árvore de decisão do seu tutorial.)

Template pronto: o DOCUMENTACAO_CIBERSEGURANCA.md §15 tem um modelo de Incident Report; a rubrica do Capstone (AVALIACOES_QUIZZES.md) é literalmente a nota de um relatório de pentest. Use-os.

PARTE E — Labs práticos 🧪

Tudo em alvos seus ou labs feitos para isso. O objetivo desta fase é o ciclo completo, não uma técnica isolada.

Lab 1 — O ciclo de ponta a ponta (guiado)

Faça a trilha TryHackMe Jr Penetration Tester (ou HTB Starting Point): ela te leva pelas 7 etapas num alvo pensado para aprender. Entregável: um mini-relatório de 1 máquina, no formato da Parte D.

Lab 2 — Recon + scan no seu próprio alvo (🟡) — Ex. 21

# baixe httpx e nuclei (ProjectDiscovery, releases) e rode contra o SEU site:
./httpx -u https://SEU_ALVO -tech-detect -status-code -ip -title
./nuclei -u https://SEU_ALVO -severity medium,high,critical -rl 10 -silent

Faça: para cada linha do nuclei, decida: é real ou falso positivo? Lição: validação (Etapa 5) — a ferramenta não decide por você.

Lab 3 — Mapear com Nmap (🟡 — só o seu host)

nmap -sV -F 127.0.0.1     # ou o IP do SEU servidor autorizado

Lição: cada porta/serviço é uma entrada na sua superfície (Etapa 3).

Lab 4 — Escrever o relatório (o mais importante)

Pegue 3 achados (dos seus exercícios ou de um lab) e escreva-os no formato da Parte D — com PoC reproduzível, impacto e correção — mais um sumário executivo de 1 página. Lição: este é o produto que um cliente paga.

Lab 5 — Máquina VulnHub (offline, opcional)

Baixe uma máquina iniciante do VulnHub, rode o ciclo completo offline e documente. Bom para praticar sem depender de internet.

PARTE F — Autoavaliação ✅

Responda de memória:

1. Qual a diferença entre um vulnerability scan e um pentest?
2. Cite as 7 etapas do ciclo, na ordem.
3. O que significa "validação com prova mínima" e por que é uma regra ética?
4. Na avaliação de impacto, qual pergunta separa um achado crítico de um médio?
5. Quais são as duas audiências de um relatório e o que cada uma precisa?
6. Black-box, gray-box e white-box — o que muda entre eles?
7. Por que "rodar o nuclei e colar a saída" não é um pentest?

1. O scan é automático e lista possíveis falhas sem validar; o pentest é um humano que valida, avalia impacto e prioriza, entregando um relatório (A.3).
2. Escopo → Recon → Mapeamento → Identificação → Validação/Exploração → Impacto → Relatório (Parte B).
3. Confirmar a falha com o mínimo necessário para prová-la, sem explorar além nem causar dano. É ético (e contratual) porque o objetivo é demonstrar o risco, não causá-lo (Etapa 5).
4. "Um atacante ganha dinheiro ou dados com isso?" → crítico; se só vaza informação → médio (Parte D).
5. Gestor não-técnico (sumário executivo: risco de negócio, o que fazer primeiro) e quem corrige (achado técnico com PoC e correção) (Parte D).
6. Quanto você sabe do alvo: black = nada; gray = algum acesso/credencial; white = código-fonte/arquitetura (A.2).
7. Porque falta validação (separar falso positivo), impacto (o que a falha permite) e comunicação (o relatório) — que é onde está o valor (A.3/C).</details>

Checklist prático:

[ ] Preenchi um ROE (escopo + regras) antes de testar
[ ] Fiz o ciclo completo em 1 lab (TryHackMe Jr Pentester ou HTB Starting Point)
[ ] Rodei httpx + nuclei no meu alvo e separei real de falso positivo
[ ] Mapeei serviços com nmap
[ ] Escrevi 3 achados no formato profissional (PoC + impacto + correção)
[ ] Escrevi 1 sumário executivo de 1 página
[ ] Atribuí severidade (CVSS + P0–P3) a cada achado

Conclusão: 5/7 do quiz + o relatório escrito (é o entregável que comprova a fase).