Teste de invasão não é rodar um scanner e entregar o PDF que ele cospe. Isso é varredura de vulnerabilidade, custa pouco, vale pouco e o cliente percebe.
Pentest é um exercício de método: você simula um adversário real, com objetivo declarado, dentro de limites acordados, e o produto final não é a lista de falhas. É a explicação de como elas se encadeiam em um caminho até o dado que importa.
Fase 0: escopo, a fase que evita processo
Nenhuma linha de comando antes do papel assinado. O documento precisa responder, sem ambiguidade:
- Alvos: domínios, faixas de IP e aplicações, listados de forma explícita. “Toda a infraestrutura” não é escopo, é armadilha.
- Fora de escopo: o que não pode ser tocado, tipicamente produção crítica, sistemas de terceiros e qualquer coisa hospedada por outro fornecedor.
- Janela: datas e horários permitidos.
- Técnicas proibidas: negação de serviço e engenharia social costumam ficar de fora, salvo contratação específica.
- Contato de emergência: alguém acessível durante toda a janela, para o caso de o teste derrubar algo.
- Tratamento de dado sensível: o que fazer se você acessar dado pessoal real. A resposta correta quase sempre é parar, registrar e não extrair.
Testar ativo de terceiro sem autorização do titular é crime, mesmo com autorização do seu cliente. Se a aplicação está em nuvem de terceiro, confirme as regras do provedor.
Fase 1: reconhecimento
Levantamento passivo primeiro, ativo depois. O objetivo é entender a aplicação antes de tocá-la: tecnologia, autenticação, papéis de usuário, fluxos de negócio.
O método de fontes abertas é o mesmo que descrevi em OSINT na Investigação de Cibercrimes, aplicado agora com autorização e foco no alvo contratado.
curl -sSI https://alvo.com.br | grep -Ei 'server|x-powered|set-cookie|content-security'
curl -sS https://alvo.com.br/robots.txt
curl -sS https://alvo.com.br/.well-known/security.txtAusência de cabeçalhos de segurança já é achado. E o robots.txt costuma listar exatamente os diretórios que alguém preferia esconder.
Fase 2: mapeamento
Aqui você constrói o mapa da aplicação: cada rota, cada parâmetro, cada papel. Navegue como usuário comum, com o proxy interceptando tudo, e depois repita como usuário privilegiado.
O material desta fase é o que diferencia teste bom de teste raso. Um scanner enxerga formulários; ele não enxerga regra de negócio. Que um usuário do plano básico não deveria conseguir emitir relatório do plano avançado é o tipo de falha que só aparece para quem entendeu o produto.
Fase 3: exploração controlada
Priorize por impacto no negócio, não por severidade genérica do catálogo. As classes que mais rendem em aplicação brasileira, na minha experiência:
| Classe | O que testar | Impacto típico |
|---|---|---|
| Controle de acesso quebrado | Trocar identificador na URL e no corpo da requisição, repetir ação com sessão de outro papel | Acesso a dado de outro cliente |
| Falha de autenticação | Recuperação de senha, expiração de sessão, ausência de segundo fator | Tomada de conta |
| Injeção | Parâmetros que chegam a consulta, comando ou template | Leitura ou escrita na base |
| Exposição de dado | Respostas de API com mais campos do que a tela mostra | Vazamento silencioso |
| Configuração incorreta | Diretório listável, painel exposto, credencial padrão | Porta de entrada direta |
A regra de ouro na exploração é prova sem dano. Demonstre que o acesso é possível e pare. Não baixe a base, não altere dado de produção, não persista acesso. Se precisar demonstrar profundidade, combine antes e registre a autorização específica.
Fase 4: pós-exploração, com limite
Se o escopo permite, mostre até onde o caminho leva: de onde você entrou até o que conseguiria alcançar. É essa narrativa que convence a diretoria a liberar orçamento, muito mais do que a contagem de falhas.
Documente cada passo com requisição, resposta e horário. Sem isso, a equipe do cliente não consegue reproduzir, e achado não reproduzível vira discussão.
Fase 5: o relatório
É o único entregável que sobrevive ao projeto. Estruture em duas camadas.
Sumário executivo, uma página, sem jargão: qual o risco para o negócio, o que pode acontecer na prática, quais são as três prioridades. Quem lê isso decide orçamento e não sabe o que é injeção.
Detalhamento técnico, um bloco por achado, contendo: descrição, evidência com requisição e resposta, passos exatos de reprodução, impacto, correção recomendada e referência. Quem lê isso vai corrigir e precisa reproduzir.
Duas coisas que valorizam muito e quase ninguém entrega: o que foi testado e não apresentou falha, porque isso também é informação, e uma proposta de reteste com prazo.
O erro que mais vejo em relatório
Copiar a descrição genérica da ferramenta e entregar. O cliente lê “possível injeção de SQL no parâmetro id”, tenta reproduzir, não consegue, e o relatório inteiro perde credibilidade junto.
Achado sem evidência reproduzível não é achado. É suspeita. E cobrar por suspeita é o caminho mais curto para não ser chamado de novo.