Metodologia de pentest: as fases de um teste de invasão

Um teste de invasão profissional não é apenas "tentar invadir até conseguir". É um processo estruturado, com fases bem definidas, objetivos claros e — fundamental — autorização explícita. Neste artigo você vai conhecer a metodologia de um pentest segundo padrões consagrados como o PTES, entendendo o que acontece em cada etapa, do primeiro contato com o cliente até a entrega do relatório que dá valor ao trabalho.

O que é um pentest (e o que não é)

Pentest, ou teste de invasão, é a simulação autorizada de um ataque real com o objetivo de encontrar e demonstrar vulnerabilidades antes que um adversário mal-intencionado as explore. A palavra-chave é autorizado. A única diferença técnica entre um pentester e um criminoso pode ser um documento assinado — o escopo e a autorização. Sem eles, a mesma atividade é crime.

O pentest também não se confunde com uma varredura automatizada de vulnerabilidades. Um scanner aponta possíveis falhas; o pentester as explora, confirma que são reais, mede o impacto e mostra o caminho que um atacante percorreria. Essa diferença entre "pode existir" e "eu explorei e cheguei aqui" é o que dá peso ao relatório final.

Pentest, red team e auditoria: não são a mesma coisa

Confundir esses termos atrapalha a contratação e a expectativa. Um pentest busca encontrar o máximo de vulnerabilidades exploráveis em um escopo definido, dentro de uma janela de tempo. Um exercício de red team é mais furtivo e orientado a objetivos: simula um adversário específico tentando alcançar uma "joia da coroa" sem ser detectado, testando também a capacidade de resposta do time de defesa (o blue team). Já uma auditoria de conformidade verifica se controles existem segundo uma norma, sem necessariamente explorá-los. Os três se complementam, mas respondem a perguntas diferentes.

Por que seguir uma metodologia

Improvisar leva a resultados inconsistentes: você testa o que lembra, esquece áreas inteiras e não consegue comparar dois testes. Uma metodologia traz cobertura (você não pula etapas), repetibilidade (outro profissional chega a resultados semelhantes) e comunicação (cliente e equipe falam a mesma língua).

Dois padrões guiam este artigo. O PTES Team (2014), com o Penetration Testing Execution Standard, define as fases de ponta a ponta de um engajamento. E o MITRE (2020), com o framework ATT&CK, cataloga as táticas e técnicas reais que adversários usam, servindo como um dicionário das ações que o pentester simula. Antes de tudo isso, porém, vale entender o raciocínio: modelar ameaças e pensar como um atacante no threat modeling é o exercício mental que orienta para onde olhar primeiro.

Vale notar que existem outros guias complementares conforme o alvo: o OWASP Testing Guide para aplicações web, o OSSTMM para uma visão mais ampla de segurança operacional, e o NIST SP 800-115 como referência institucional. PTES e ATT&CK dão a espinha dorsal; os demais aprofundam domínios específicos.

Fase 1: Pré-engajamento

Tudo começa fora do teclado. A fase de pré-engajamento define as regras do jogo:

• Escopo: quais sistemas, domínios e faixas de IP estão dentro e fora do teste.
• Tipo de teste: black box (sem informação prévia), white box (acesso total à documentação e código) ou gray box (algo no meio).
• Janela de tempo e janelas de ataque: quando o teste pode ocorrer sem derrubar a operação.
• Autorização formal: o documento que torna tudo legal.
• Tratamento de dados sensíveis: o que fazer se o pentester encontrar dados reais de clientes.

Pular essa fase é o erro de iniciante mais perigoso. É aqui que se evita derrubar um sistema crítico por engano ou testar um ativo que nem pertence ao cliente.

Os documentos que protegem você

Três documentos costumam formalizar o engajamento e merecem atenção:

• Regras de Engajamento (RoE): definem o que é permitido, o que é proibido (engenharia social? DoS? exploração destrutiva?), horários e limites de impacto.
• Carta de autorização ("get out of jail letter"): o documento assinado por alguém com poder para autorizar, que comprova a legalidade da atividade caso você seja questionado.
• Acordo de confidencialidade (NDA): protege as informações sensíveis que você inevitavelmente verá.

Um detalhe crítico: confirme que quem assina tem autoridade para autorizar o teste e que o cliente realmente possui os ativos no escopo. Testar um servidor hospedado em nuvem de terceiros, por exemplo, pode exigir autorização adicional do provedor.

Fase 2: Reconhecimento

Com o escopo definido, começa a coleta de informações sobre o alvo. O reconhecimento se divide em passivo (sem tocar diretamente no alvo — buscas públicas, registros DNS, vazamentos, redes sociais) e ativo (interagindo com o alvo, como varredura de portas e enumeração de serviços).

Esta é, para muitos, a fase mais determinante: quanto melhor o mapa do terreno, mais certeiros os ataques seguintes. Quem domina o reconhecimento (recon) como a fase mais importante do pentest costuma encontrar caminhos que passariam despercebidos — um subdomínio esquecido, uma versão de software desatualizada, um e-mail que revela o padrão de nomes de usuário da empresa.

No vocabulário do MITRE (2020), boa parte dessa fase corresponde às táticas de Reconnaissance e Resource Development: entender o alvo e preparar a infraestrutura do ataque.

Reconhecimento passivo versus ativo na prática

A distinção importa porque muda o risco de detecção. No passivo, você consulta fontes que não tocam o alvo: registros WHOIS e DNS, certificados TLS públicos, mecanismos de busca, repositórios de código vazados e perfis em redes sociais. É silencioso e quase sempre legal mesmo fora de um engajamento, por usar dados públicos.

# exemplos de reconhecimento passivo (consultas a dados públicos)
whois exemplo.com
dig exemplo.com any
# certificados públicos revelam subdomínios em portais de transparência de CT

No ativo, você interage diretamente — varredura de portas, banner grabbing, enumeração de serviços — e isso gera tráfego que pode ser registrado e detectado. Por isso o reconhecimento ativo só acontece dentro da janela e do escopo autorizados.

# exemplo de reconhecimento ativo: varredura de serviços
nmap -sV -p- alvo-autorizado.exemplo.com

Fase 3: Modelagem de ameaças e análise de vulnerabilidades

Com as informações em mãos, o pentester organiza o que descobriu e prioriza alvos. Quais serviços são mais promissores? Onde estão as joias da coroa (os dados que realmente importam)? Quais vulnerabilidades conhecidas afetam as versões identificadas?

Aqui o trabalho mistura ferramentas automatizadas e análise humana. Scanners de vulnerabilidade aceleram a triagem, mas é o julgamento do profissional que separa o falso positivo da brecha explorável e que enxerga combinações não óbvias — duas falhas pequenas que, encadeadas, dão acesso total.

Encadeamento: o todo maior que as partes

O conceito de encadeamento de vulnerabilidades (exploit chaining) é o que distingue um pentest maduro. Uma falha de severidade "média" sozinha pode parecer pouco; combinada com outra, vira crítica. Por exemplo: um upload sem validação de tipo (médio) + um diretório de uploads servido com execução (médio) podem resultar em execução remota de código (crítico). Bons pentesters pensam em caminhos de ataque, não em achados isolados. É esse raciocínio de cadeia que justifica a fase de análise antes de partir para a exploração às cegas.

Fase 4: Exploração

É a fase mais cinematográfica, mas, idealmente, a mais curta e cirúrgica. Explorar significa transformar uma vulnerabilidade em acesso concreto: executar código, obter credenciais, contornar a autenticação. O profissionalismo aqui está na contenção — explorar apenas o necessário para provar o impacto, sem causar dano colateral nem derrubar serviços.

Algumas classes de falha são tão recorrentes que merecem estudo dedicado. Entender, por exemplo, como funciona a exploração de SQL Injection na prática, de forma ética, é parte essencial do repertório de qualquer pentester web, porque injeção continua entre as falhas mais comuns e mais impactantes.

A exploração é raramente feita só na unha. Ferramentas de interceptação são indispensáveis no contexto web; dominar o Burp Suite, o canivete suíço do pentester web, permite capturar, modificar e repetir requisições — exatamente o que se precisa para manipular parâmetros e testar fronteiras de confiança.

Disciplina durante a exploração

Três regras de ouro evitam transformar um teste em incidente:

• Documente cada passo em tempo real. Comando executado, horário, resultado. Isso vira evidência no relatório e prova de que você se manteve no escopo.
• Prefira provas de conceito não destrutivas. Para demonstrar acesso ao banco, ler uma linha de uma tabela de teste prova o ponto sem exfiltrar dados reais.
• Comunique o crítico imediatamente. Se você encontrar algo gravíssimo (acesso a dados de clientes, sistema já comprometido por terceiros), pare e avise o cliente — não espere o relatório final.

Fase 5: Pós-exploração

Conseguir o primeiro acesso é só o começo. A pós-exploração responde à pergunta: "e agora, até onde dá para ir?". Ela envolve táticas que o MITRE (2020) cataloga em detalhe:

• Persistência: manter o acesso mesmo após reinícios.
• Escalada de privilégios: de usuário comum a administrador.
• Movimento lateral: saltar de uma máquina comprometida para outras na rede.
• Coleta e exfiltração (simulada): demonstrar que dados sensíveis poderiam ser extraídos.

O objetivo não é causar estrago, mas medir o impacto real. Um acesso inicial limitado tem uma gravidade; provar que dele se chega ao banco de dados de clientes tem outra, muito maior. É a pós-exploração que traduz uma vulnerabilidade técnica em risco de negócio.

Limpeza: não deixe rastros perigosos

Uma parte frequentemente esquecida é a limpeza pós-engajamento. Tudo que você instalou — webshells, contas de usuário, ferramentas, chaves de acesso, mecanismos de persistência — precisa ser removido e listado para o cliente. Um artefato esquecido vira uma porta dos fundos real que um atacante de verdade pode usar depois. Mantenha um inventário do que foi criado para garantir que nada fique para trás.

Fase 6: Relatório

O relatório é o produto final e, paradoxalmente, a parte mais negligenciada por iniciantes. Um teste brilhante com um relatório ruim não gera valor: o cliente não consegue corrigir o que não entende. Um bom relatório tem duas camadas:

• Sumário executivo: linguagem de negócio, para liderança. Qual o risco geral, qual o impacto potencial, quais as prioridades.
• Detalhamento técnico: para a equipe que vai corrigir. Cada achado com descrição, evidência (provas de conceito), avaliação de severidade e recomendações de remediação claras.

O PTES Team (2014) coloca o relatório como fase formal justamente porque é onde o esforço técnico vira ação corretiva. Sem ele, o pentest é um exercício intelectual sem retorno.

Como classificar a severidade

Achados precisam de uma medida de gravidade consistente para o cliente priorizar. O padrão mais comum é o CVSS (Common Vulnerability Scoring System), que combina fatores como facilidade de exploração e impacto em uma nota de 0 a 10. Mas a nota técnica não basta: o pentester deve ajustá-la ao contexto de negócio. Uma falha "média" em CVSS num sistema que processa pagamentos pode ser, na prática, a prioridade número um. Um bom relatório explica o porquê de cada prioridade, não só o número.

Cada achado bem documentado costuma conter: título claro, severidade, ativos afetados, descrição técnica, passos de reprodução, evidência (capturas e logs), impacto de negócio e recomendação de remediação acionável.

O reteste: fechando o ciclo

O trabalho não termina na entrega. Depois que o cliente corrige, um reteste confirma que as correções funcionaram e não introduziram novas falhas. Esse fechamento de ciclo é o que transforma o pentest de um retrato pontual em uma melhoria real e verificada da postura de segurança.

Como as fases se conectam: um exemplo end-to-end

Para ver a metodologia em movimento, imagine um engajamento web de gray box em uma loja online.

No pré-engajamento, define-se o escopo (loja.exemplo.com e sua API, excluído o gateway de pagamento de terceiros), tipo gray box (com uma conta de teste), janela noturna e autorização assinada. No reconhecimento, mapeiam-se subdomínios e descobre-se um admin-staging.exemplo.com esquecido fora do escopo principal — anotado, mas não testado sem nova autorização. Na análise, prioriza-se a API, onde a versão de um componente identificado tem CVE conhecida, e nota-se que o upload de avatar não valida tipo.

Na exploração, confirma-se que o upload aceita um arquivo com extensão dupla e que o diretório o serve com execução — duas falhas médias que, encadeadas, dão execução remota de código (crítico). A descoberta crítica é comunicada de imediato ao cliente. Na pós-exploração, demonstra-se acesso de leitura a uma tabela de pedidos de teste (prova não destrutiva), medindo o impacto real: exposição de dados de clientes. Tudo que foi criado é então removido e inventariado.

No relatório, o achado de RCE encabeça as prioridades, com severidade ajustada ao contexto (loja que processa dados de clientes), passos de reprodução, evidências e remediação clara: validar tipo de arquivo, desabilitar execução no diretório de uploads e atualizar o componente vulnerável. Semanas depois, um reteste confirma que as correções funcionaram. Esse fio narrativo mostra por que nenhuma fase é dispensável: tirar qualquer uma quebra a cadeia que vai do contrato ao valor entregue.

Mentalidade e ética: o que de fato separa o profissional

Acima da técnica, o que define um pentester é a postura. Três princípios são inegociáveis:

• Autorização antes de qualquer ação. Nada fora do escopo, nunca, sem documento.
• Minimizar dano. Provar o impacto com o menor toque possível; produção é território sensível.
• Confidencialidade absoluta. Você verá os pontos mais frágeis de uma organização; protegê-los é dever profissional, durante e depois do engajamento.

É a soma desses princípios com o método que transforma uma habilidade potencialmente destrutiva em um serviço que fortalece a segurança de quem o contrata.

Treinando essas habilidades de forma segura

Você não aprende pentest invadindo sistemas alheios — isso é crime, e nem é didático. O ambiente ideal para praticar todas essas fases de forma legal e progressiva são os desafios práticos. Descobrir o que é um CTF e aprender hacking jogando é a porta de entrada recomendada: laboratórios e competições recriam cenários reais onde você exercita reconhecimento, exploração e pós-exploração sem risco legal e com objetivos claros.

Perguntas frequentes

Pentest é a mesma coisa que análise de vulnerabilidades? Não. A análise de vulnerabilidades (scan) aponta possíveis falhas; o pentest as explora para confirmar que são reais e medir o impacto. O scan é um insumo de uma das fases, não o pentest inteiro.

Quanto tempo dura um pentest? Depende do escopo, mas engajamentos típicos vão de uma a algumas semanas. Escopos maiores ou mais furtivos (red team) levam mais tempo.

Preciso saber programar para ser pentester? Ajuda muito. Entender como o software funciona por dentro permite enxergar falhas que ferramentas não pegam, escrever provas de conceito e automatizar tarefas. Não precisa ser especialista, mas fugir totalmente de código limita o teto da carreira.

Black box ou white box é melhor? Depende do objetivo. Black box simula um atacante externo sem informação; white box, com acesso a código e documentação, encontra mais falhas em menos tempo por não gastar esforço descobrindo o óbvio. Para cobertura máxima, white ou gray box costumam render mais.

Conclusão

Um pentest profissional é metodologia, não sorte. Do pré-engajamento que define as regras até o relatório que entrega valor, cada fase tem um propósito, e pular etapas compromete o resultado — quando não a legalidade. Padrões como o PTES e o ATT&CK dão estrutura e vocabulário para um trabalho rigoroso e comunicável. Se você está começando, internalize a sequência das fases, pratique em ambientes autorizados como CTFs e lembre-se de que o que separa um pentester de um atacante não é a técnica, mas a ética e a autorização. Domine o processo, e as ferramentas virão naturalmente.

Referências

• PTES Team (2014). Penetration Testing Execution Standard. PTES.
• MITRE (2020). MITRE ATT&CK Framework. MITRE Corporation.
• OWASP (2020). OWASP Web Security Testing Guide. OWASP Foundation.
• NIST (2008). SP 800-115: Technical Guide to Information Security Testing and Assessment. National Institute of Standards and Technology.