Metodologia · PTES 7 fases · ~12 min

Metodologia de Pentest: as 7 Fases do PTES Aplicadas com Olhar Clínico

Existe um abismo entre scan + report e pentest executado conforme PTES (Penetration Testing Execution Standard). O primeiro custa metade e entrega 5%. O segundo é o que auditor SOC 2 / ISO 27001 aceita. Esta página detalha as 7 fases, o que muitos fornecedores pulam, e como executamos cada uma.

Operamos PTES em 100% dos engajamentos, com complemento de OWASP Testing Guide v4.2 (web), MITRE ATT&CK (pós-exploração), NIST SP 800-115 e OSSTMM. Cada fase tem entregáveis intermediários e revisão peer-to-peer entre os 5 sêniors do time antes de seguir para a próxima.

Time fixo, sem rotatividade

5 sêniors. O mesmo time que pentestou Caixa Econômica vai pentestar você. Sem júnior aprendendo no seu ambiente, sem analista trocado a cada projeto.

90% manual, 10% automatizado

Scanner é o nosso ponto de partida, não o nosso entregável. Lógica de negócio, IDOR, BOLA, race condition, encadeamento de falhas — ferramenta nenhuma faz.

Relatório de 80–150 páginas

Cada finding com PoC reproduzível, business impact, CVSS justificado e rota de correção. Aceito por auditor SOC 2, ISO 27001, PCI-DSS.

1. Pre-engagement Interactions

A primeira fase define se o pentest vai ser sério ou teatro. Aqui acontece:

O que muitos fornecedores pulam: Threat Modeling abreviado para 30 minutos de call. Carta de Autorização genérica. Sem definição de critérios — então qualquer entregável "fecha" o contrato.

2. Intelligence Gathering

OSINT estruturado para construir o mapa de superfície:

O gap commodity: "rodamos um Subfinder e está bom". Sem correlação, sem priorização por valor, sem hipótese de adversário.

3. Threat Modeling

Tradução do que foi descoberto em quais atacantes, quais TTPs (MITRE ATT&CK), quais ativos críticos. Para cada cliente:

Exemplo concreto: no Threat Modeling de uma fintech identificamos que o fluxo de OAuth confiava em redirect_uri sem allowlist — vulnerabilidade que scanner não enxerga porque depende de mapear intent do negócio. O finding final saiu por essa rota; sem Threat Modeling, ficaria invisível.

4. Vulnerability Analysis

Aqui sim entra ferramenta — como insumo:

5. Exploitation

O coração do pentest e o que distingue manual de scan:

Scanner enxerga string match. Humano enxerga intenção. Veja casos reais →

6. Post-Exploitation

Simulação realista do que adversário faz após entrar:

O que MSSPs com operação de larga escala enfrentam: rotatividade de analista trunca essa fase. Quem roda Post-Exploitation precisa entender o ambiente em profundidade — analista júnior alocado em projeto novo não tem essa familiaridade.

7. Reporting

O entregável material do trabalho:

Comparativo: commodity × intrus

Critério
Modelo commodity
intrus.io
Execução manual
< 20%
≥ 90%
Time alocado
Rotativo, frequentemente júnior
5 sêniors fixos
Relatório típico
15–30 páginas
80–150 páginas
PoC reproduzível
Eventual
Sempre
Mapping PTES/OWASP/MITRE
Ausente
Por finding
Retest incluso
Cobrado à parte
Incluso 1x
Aceito por auditor SOC 2/ISO
Frequentemente reprovado
Aceito

Por que o mercado pula fases

Existem fornecedores que vendem o output de scanner como pentest finalizado. Não é caráter — é modelo de negócio: vender 40 horas de scan a R$ 8.000 dá margem operacional maior do que vender 4 semanas de pentest manual a R$ 30.000. Para o cliente que não exige PTES no Termo de Referência, comoditizar funciona. Para o cliente que precisa de evidência aceita por auditor, não.

Quem executa cada fase

Em MSSPs grandes com operação de larga escala, rotatividade estrutural de mercado (estimada em 25-40% ao ano em cyber, conforme relatórios ISC2 Cybersecurity Workforce Study) significa que cada engajamento novo do mesmo cliente é executado por uma pessoa diferente. O conhecimento contextual sobre infraestrutura, padrões de vulnerabilidade e histórico de findings se perde.

Na intrus.io são 5 profissionais sêniors fixos. Mesmo time, todos os engajamentos. Veja como esse modelo entrega →

Como o relatório materializa o trabalho

Relatório de 20 páginas com lista de CVEs e screenshots de scanner não é evidência — é resumo. Auditor de SOC 2 / ISO 27001 / PCI rejeita esse tipo de entregável. Nosso relatório médio tem 80 a 150 páginas porque cada finding é tratado como caso técnico independente: descrição → impacto → PoC passo-a-passo → CVSS justificado → recomendação técnica → rota de correção priorizada.

FAQ

PTES é obrigatório?

Não é norma com força regulatória, mas é a metodologia de referência reconhecida por auditores SOC 2 e ISO 27001. Auditor pede ou PTES, ou OWASP Testing Guide v4.2, ou NIST SP 800-115. Operamos os três.

Quanto tempo cada fase leva?

Pre-engagement 3-5 dias. Intelligence Gathering + Threat Modeling juntos: 5-10 dias. Vulnerability Analysis + Exploitation: 10-20 dias. Post-Exploitation: 3-7 dias. Reporting: 5-10 dias. Pentest típico web app: 4-6 semanas total.

Posso pular Intelligence Gathering?

Pode, mas então você tem vulnerability scan rotulado de pentest. Sem reconhecimento e modelagem de ameaça, o teste cobre só o documentado — atacante real explora justamente o que não está documentado.

Threat Modeling é o mesmo de SAST?

Não. SAST é análise estática de código. Threat Modeling em PTES é análise de superfície e adversário: quais ativos, qual ator de ameaça, qual TTP MITRE ATT&CK. Complementam-se, não se substituem.

Vocês usam scanner em qual fase?

Vulnerability Analysis. Burp Pro, Nessus, Nuclei, Subfinder e ferramentas próprias rodam como insumo de descoberta. Cada finding do scanner é validado manualmente — 60-80% dos hits altos/críticos são falso-positivo até prova manual.

Como sei que o fornecedor seguiu PTES de fato?

Peça o relatório de Threat Modeling como entregável. Peça também os resultados de Post-Exploitation (lateral movement, persistência simulada). Quem entrega só lista de CVEs com screenshot pulou as fases.

Agendar diagnóstico técnico Ler casos reais →