O que acontece quando você realmente entra no sistema
A maioria das pessoas acha que testes de invasão é rodar um scanner e receber um PDF colorido no final. Na prática, é isso que a ferramenta faz. O trabalho real é entender por que a ferramenta errou, o que ela não consegue ver, e o que acontece quando o alvo decide que o scan não é autorizado. Testes de invasão: uma introdução prática ao hacking não começa com Metasploit. Começa com um contrato assinado, um escopo bem definido, e a compreensão de que um único commando errado pode derrubar um serviço de produção.
Por que scanners sozinhos não resolvem nada
Eu já passei horas analisando relatórios gerados por Nessus e OpenVAS em ambientes corporativos. Os relatórios mostravam vulnerabilidades críticas em servidores que estavam desligados, em portas que não existiam mais, e em serviços que haviam sido migrados há meses. A ferramenta marcou tudo como HIGH. O time de segurança gastou três dias verificando falsos positivos. O problema fundamental é que scanners automatizados operam por assinatura. Eles sabem o que procurar porque já viram antes. Se uma aplicação tem uma falha de lógica que exige compreensão contextual — como um token de sessão que pode ser reutilizado entre contas diferentes — o scanner simplesmente passa direto. Nada de alarme vermelho. A vulnerabilidade existe e ninguém vai reportá-la.
Em um caso específico, deparei-me com um sistema de gerenciamento de pacientes onde o parâmetro de ID na URL era sequencial e não autenticado. Um scanner de XSS não encontraria isso. Um scanner de injeção SQL poderia alertar sobre o parâmetro, mas não relacionaria o fato de que qualquer ID acessível significa que os dados de qualquer paciente podem ser lidos sem credenciais. Eu rodei um script manual em Python que iterava IDs de 1 a 500 em vinte minutos. O relatório final teve apenas uma entrada, mas mudou a arquitetura de segurança daquele cliente.
Métodos que funcionam na prática
O fluxo real de um teste de invasão varia muito dependendo do alvo. Mas existe uma sequência básica que eu sigo praticamente em cada engagement: Reconhecimento passivo primeiro. Antes de tocar no alvo, você coleta informações públicas: registros DNS, subdomínios expostos, código fonte em repositórios GitHub abandonados, perfis de funcionários no LinkedIn que revelam nomes de sistemas internos, e configurações de e-mail que indicam provedores usados. Isso leva de algumas horas a dois dias, dependendo da maturidade do alvo.
Definição de escopo escrita. Anotar exatamente quais IPs, domínios e aplicações estão autorizados. Definir o que é proibido: testes de negação de serviço, engenharia social contra funcionários, acesso a bancos de dados de produção sem backup. Sem isso, você pode causar dano real e perder a licença para trabalhar no setor. Reconhecimento ativo com cautela. Escaneamento de portas, identificação de serviços, versionamento. Aqui eu uso Nmap com flags de detecção de OS e serviços, mas sempre com timing templates moderados (-T3) para evitar que o WAF ou o IDS do alvo bloqueie minha máquina antes mesmo de eu começar a explorar.
Exploração controlada. Tentar aproveitar vulnerabilidades encontradas, mas sem exagero. Se eu acesso um shell em um servidor de desenvolvimento, não vou instalar keyloggers ou exfiltrar dados aleatórios. Vou documentar o caminho, provar o acesso, e parar. A maioria dos testes de invasão que eu vi causarem problemas foi porque o testador continuou se movendo lateralmente além do que estava no escopo. Relatório que realmente informa. O documento final precisa conter: a vulnerabilidade encontrada, como ela foi explorada, qual o impacto real, e como corrigir. Não adianta dizer "HTML injection detectada" sem mostrar que ela permite roubar sessões de administradores. A diferença entre um relatório útil e um que vai para a gaveta é a clareza do risco de negócio.
A parte que ninguém conta nos cursos
Um dos maiores erros de iniciantes é acreditar que Domínio 1 (reconhecimento) e Domínio 2 (exploração) são as fases mais importantes. Na realidade, Domínio 4 — pós-exploração e manutenção de acesso — é onde a maioria dos testes falha, e é também onde você aprende o quanto uma organização está exposta. Pós-exploração não significa instalar backdoors. Significa responder perguntas como: se eu estou dentro da rede interna, consigo chegar ao domínio controller? Consigo acessar o banco de dados com credenciais que achamos num arquivo de configuração? Quantas máquinas na rede têm senhas idênticas?
Eu lembro de um teste em que encontrei uma credencial de API num repositório GitHub privado que o cliente havia deixado exposto por engano. A API dava acesso a um sistema de monitoring que, por sua vez, tinha um endpoint de execução remota mal protegido. Em quinze minutos de enumeração manual a partir daquela credencial, eu tinha acesso administrativo a vinte e três servidores. Nenhum scanner teria conectado esse ponto. O scanner viu "credencial exposta" e "endpoint com risco" como dois itens isolados. A cadeia de correlação foi construída manualmente.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Ferramentas que eu uso de verdade
Kali Linux é o padrão do setor por um motivo: vem com quase tudo que você precisa pré-instalado. Mas o sistema operacional em si não faz o teste. São as ferramentas dentro dele. Nmap — essencial para mapeamento de rede. A flag -sC roda scripts padrão de descoberta. -sV identifica versões de serviços. -O tenta detectar o sistema operacional. Combine tudo e você tem uma imagem clara do que está rodando antes de qualquer tentativa de exploração.
Burp Suite Community — para testes em aplicações web. A versão community é limitada em throughput, mas suficiente para a maioria dos testes. O Intercept proxy, o Repeater para manipulação manual de requests, e o Scanner básico cobrem cerca de sessenta por cento das falhas em apps web. John the Ripper e Hashcat — para quebra de senhas. Hashcat é mais rápido por usar GPU. John é mais fácil de usar em cenários onde você não tem placa de vídeo disponível. Ambos funcionam bem com dicionários personalizados baseados em vazamentos anteriores, como o conjunto Have I Been Pwned.
SQLMap — automação de detecção e exploração de SQL injection. Útil, mas perigoso. Eu nunca rodo SQLMap sem antes confirmar manualmente que a input é de fato vetor de injeção. Rodar automaticamente em produção já me vi causar timeouts em consultas legítimas do banco. CrackMapExec e Impacket — para enumeração e exploração em ambientes Windows/Active Directory. O CME faz enumeração de domínio de forma rápida. O Impacket fornece scripts para explorar falhas como SMB relay, Kerberoasting, e pass-the-hash. São as ferramentas mais negligenciadas por testadores que vêm de background apenas web.
Erros comuns que custam caro
O erro número um é escanear fora do escopo. Um IP que não estava na lista de autorização pode pertencer a um cliente diferente ou a uma infraestrutura de terceiros. Isso já gerou processos na minha área. O erro número dois é tratar every vulnerability reportada pelo scanner como real. Cross-site scripting encontrado pelo scanner pode ser um falso positivo causado por encoding duplo. Injeção SQL pode ser mitificada pela configuração do WAF. Sempre valide manualmente antes de marcar como confirmado no relatório.
O erro número três é não ter um plano de rollback. Se você explora uma vulnerabilidade que modifica dados — mesmo que seja para provar o ponto — precisa ter certeza de que pode reverter. Em um teste recente, um colega explorou uma falha de atualização batch em um sistema de estoque e alterou quantidades em trinta e dois itens. Ele não havia perguntado se podia fazer isso. O cliente considerou o incidente como dano operacional e cortou o contrato na hora.
Sobre certificados e credenciamento
OTPW e CEH são os mais citados, mas nenhum deles ensina o pensamento crítico que um teste de invasão realmente exige. O OSCP é mais prático e avalia habilidade real, mas ainda sim é um ambiente controlado. O mundo real não tem replay de tentativas. A experiência prática supera qualquer certificação. Participar de plataformas como Hack The Box ou TryHackMe ajuda, mas o próximo passo é configurar seu próprio lab com máquinas vulneráveis reais, como as do VulnHub, e documentar cada passo como se fosse um relatório profissional.
Quando testes de invasão não são a resposta
Existem cenários onde testes de invasão tradicionais falham completamente. Aplicações serverless com architectures efêmeras não têm superfície fixa para escanear. Microserviços comunicando-se via service mesh criam tráfego criptografado que é difícil de interceptar sem acesso aos certificates de service identity. Sistemas com autenticação multifator forte e segmentação de rede rigorosa podem resistir a técnicas convencionais de forma eficaz. Nesses casos, o approche mais eficiente é combinar testes manuais com análise estática de código (SAST) e dinâmica (DAST), além de revisões de configuração de infraestrutura como código. Ferramentas como Semgrep, Snyk, ou Checkov complementam o trabalho de campo e cobrem lacunas que o teste manual não alcança.
O importante é entender que testes de invasão: uma introdução prática ao hacking não é sobre dominar ferramentas. É sobre desenvolver a paciência de investigar, o ceticismo de questionar cada resultado automatizado, e a disciplina de parar quando o risco ultrapassa o escopo acordado.
