O que é teste de invasão na prática
teste de invasão é basicamente tentar entrar no sistema de alguém antes que alguém ruim faça o mesmo. A diferença entre um teste sério e uma scan automática é que no primeiro você pensa como o defensor pensa, e no segundo você só roda o tool e espera que algo apareça no relatório. Eu já vi gente chamar Nmap rodando em rede client de pentest. Não é. O escanner te diz o que existe, mas não te diz o que importa. A parte chata é entender isso sem gastar três semanas num único alvo.
Como eu monto um teste real
A primeira coisa que eu faço não é tocar no alvo. Eu leio o escopo. Qual IP? Qual sub-rede? Tem API externa? Tem ambiente de homologação espelhando produção? Isso define se o teste vai levar dois dias ou duas semanas. Se o escopo estiver mal definido, o cliente vai achar que você não fez nada porque o relatório não cobre o que ele queria ver. Depois vem a coleta de informação passiva. Subdomínios, Whois, Shodan, GitHub com tokens jogados em repositórios públicos. Eu passo uns 40 minutos a 2 horas só nisso antes de tocar no alvo. Parece pouco, mas já tive caso onde uma chave AWS exposta num commit de 2019 foi o caminho mais rápido pra entrar no ambiente. O cara tava preocupado com firewall de perimetral e a brecha era credencial num repositório legado.
Na fase ativa eu misturo ferramentas com análise manual. Burp Suite pro web, Nmap pros serviços, alguns scripts Python pra automaçãozinha. Mas o segredo é anotar tudo. Cada requisição que dá 403, cada header que muda, cada erro de aplicação. O que parece lixo num primeiro momento é quando você volta 48 horas depois e percebe que aquele endpoint com timeout era o vetor que você precisava. Um exemplo bem específico que eu lembro: estava testando uma API REST com autenticação JWT. O token vinha com payload normal, mas num dos endpoints de upload eu notei que o server respondia com tempo de resposta diferente dependendo do conteúdo. Demorei duas manhãs procurando por SSRF e não achava nada. Aí lembrei de testar a validação do header Content-Type com valores estranhos. O server não falava inglês pra mim, então comecei a brincar com edge cases de parsing. Descobri que o parser aceitava multipart com campos duplicados e isso me deu controle sobre o boundary. O resto foi subir uma reverse shell via DNS exfiltration porque a saída HTTP tava restrita. O relatório levou seis páginas pra explicar isso, mas o exploit real eram três requisições curl malucas.
Pegadinhas que ninguém conta
A maioria dos iniciantes foca em encontrar vulnerabilidades e esquece que o negócio todo é sobre proveito de risco de negócio. Achou SQL injection? Ótimo. Agora responde: isso leva a dados sensíveis? Quanto custa pras regras da empresa se isso vazar? Qual o impacto real num cenário de produção? Outro erro comum é depender de tools automatizadas pra tudo. Nessus, OpenVAS, ZAP no modo automático. Eles acham o baixo-hanging fruit e param aí. Vulnerabilidades lógicas, fluxos de autenticação quebrados, privilege escalation em APIs internas - isso tool nenhuma acha pra você. Você precisa entender o fluxo da aplicação, não só scannerar portas.
Também tem a questão do ruído. Teste de invasão em produção sem autorização explícita é crime, ponto. Mesmo com scope firmado, alguns testes geram tanto tráfego que derrubam serviços. Eu já vi scanner agressivo de directory brute-force fazer o banco de dados entrar em connection pool exhaustion numa loja online. Aí o cliente cobra e você fica na mão porque técnicamente estava dentro do escopo. A solução é sempre testar velocidade progressiva e ter um botão de pausa pronto.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Ferramentas que eu realmente uso
OWASP ZAP pra web app, mas só no modo manual. O automático gera falso positivo que perde tempo do analista. Burp Suite Professional é essencial, especialmente a versão com intruder pra fuzzing controlado. Nmap com scripts Lua próprios que eu mantenho num repositório interno - nada de copiar e colar script kiddie. Para_ENUMeração de subdomínios eu uso o amass combinado com sublist3r, mas sempre cross-checkando com Wayback Machines e Archive.org. Cansou de cliente reclamar que "o subdomínio não existia" quando ele tinha sido desativado em 2021 e o DNS ainda respondia por cache.
Para exploração, Metasploit é útil pra validar, mas eu prefiro escrever payloads customizados. O frameowrk é pesado e deixa rastro. Em ambiente de teste isso não importa muito, mas em engagement real com regras de sigilo mais apertadas, payload customizado é melhor. Report generation. Aqui é onde a maioria falha. Vulhub ou DVWA pra treino é uma coisa, escrever um relatório técnico que um CISO entenda é outra. O relatório precisa ter CVSS score, prova de conceito reproduzível, recomendação de mitigação específica e timeline de exposição. Sem isso, o teste vira só mais um PDF que ninguém lê.
Quando o teste NÃO funciona
Teste de invasão tradicional tem limitações reais. App móvil nativo com código ofuscado? Difícil extrair inteligência sem reverse engineering pesado, e aí o custo sobe exponencialmente. Infraestrutura cloud com WAF bem configurado e detecção de anomalia? O teste demora mais porque você não pode ser agressivo. Ambientes air-gapped? Basicamente impossível sem acesso físico prévio. Outra limitação importante: teste pontual só captura o estado naquele momento. Se a equipe de dev lança uma feature nova três dias depois do pentest, a vulnerabilidade que ela traz não aparece no relatório. Por isso o ideal é ciclo contínuo, não evento único. E mesmo com ciclo contínuo, teste manual ainda é insubstituível pra lógica de negócio. Tool automatizada nunca vai entender que um campo de quantidade negativa num checkout permite estocar produto infinito sem pagamento.
Se você quer aprender na prática, comece com portswigger web security academy. É grátis, orientado por labs progressivos e cobre desde o básico até técnicas avançadas de lógica de aplicação. Evite bootcamps que prometem certificação em 5 dias - essas coisas ensinam a rodar tool, não a pensar como invasor. O mercado brasileiro ainda confunde teste de invasão com auditoria de conformidade. São coisas diferentes. Auditoria verifica se controles existem. Pentest tenta burlá-los. Ambos são úteis, mas exigir que um pentest substitua um programa de segurança completo é ingenuidade. O melhor cenário é combinar os dois com red teaming periódico e treinamento contínuo da equipe de desenvolvimento.
Se o objetivo é só passar em checklist de regulamentação, ferramentas automáticas resolvem. Se o objetivo é realmente entender como alguém entraria no seu sistema, o trabalho manual e a análise de contexto são obrigatórios. Não tem atalho.
