O que acontece quando você realmente tenta invadir um sistema
Existem dois tipos de pessoas que fazem testes de invasão. A primeira acredita que é sobre rodar o Nmap e o Burp Suite até aparecer um aviso vermelho. A segunda sabe que a maior parte do trabalho é entender como aquele sistema foi construído antes de tentar qualquer coisa. Eu já vi consultores passes dias tentando exploração automatizada em uma aplicação que estava sendo servida por um CDN com WAF configurado de forma customizada. O resultado foram zero achados relevantes. Dois dias depois, alguém revisou a documentação de API e encontrou um endpoint de redefinição de senha que não constava no swagger público. Esse é o tipo de detalhe que separa um relatório útil de uma lista genérica de vulnerabilidades de baixo risco.
testes de invasão: uma introdução prática ao hacking
O cenário mais comum no dia a dia começa com um escopo entregue por e-mail: um domínio, algumas URLs, talvez um range de IPs. A primeira coisa que eu faço não é abrir ferramenta nenhuma. É mapear o que existe. Subdomínios, tecnologias visibles no cabeçalho HTTP, certificados SSL, endpoints de administração, links para outras páginas que o frontend referencia mas que não aparecem na navegação principal. O reconhecimento passivo já pode te dar entre 30% e 50% do panorama inicial, dependendo da maturidade da equipe de segurança do alvo. Ferramentas como sublist3r, Amass e o Wayback Machine são padrão. Eu uso uma combinação delas num script simples que salva tudo num arquivo de texto para consulta rápida depois.
Quando entro na fase ativa, o primeiro passo é escaneamento de portas. Não é sobre ver quantas portas estão abertas. É sobre identificar quais serviços estão rodando e quais versões. Um Apache 2.4.49 com CVE-2021-41773 exposto é completamente diferente de um nginx 1.21 rodando na mesma porta. O Scanamap do Nmap com a flag -sV e --script vuln resolve isso rápido. Leva cerca de quinze minutos num range de classe C, depende da configuração de firewall. O erro mais frequente de quem começa é tratar cada descoberta isoladamente. Você encontra um Redis sem autenticação exposto na internet, marca como crítico e vai embora. O problema é que nem sempre aquele Redis está acessível de dentro da rede interna onde o aplicativo consome dados. Às vezes ele é usado apenas para cache externo e não há vazamento direto. Você gasta tempo explorando um caminho que não leva a lugar nenhum.
A abordagem correta é pensar em cadeia de exploração. Uma página com XSS refletida pode não parecer grave sozinha. Se aquela mesma aplicação usa tokens CSRF mal implementados e o domínio principal permite subdomínios dinâmicos, o quadro muda completamente. Eu já encontrei essa combinação em três oportunidades diferentes. Em todas, o vetor inicial era fraco, mas a conexão entre os componentes criava uma rota que atingia dados sensíveis.
Ferramentas que realmente importam no campo
O Burp Suite Professional continua sendo a espinha dorsal de qualquer teste em aplicações web. A versão Community funciona, mas a ausência de scanner automático e de repeater ilimitado limita severamente o ritmo. Eu recomendo a comunidade apenas para aprendizado inicial. Para trabalho real, o Professional se paga na primeira semana de uso, considerando o tempo economizado. Para APIs, o Postman combinado com rotas salvas no Burp faz a maior parte do serviço. Testar endpoints de autenticação requer atenção especial aos campos que aceitam JSON malformado, arrays em campos que deveriam ser strings, e datas fora do formato esperado. Falhas de validação aqui são mais comuns do que muitos pensam.
O SQLmap ainda é útil, mas deve ser usado com cuidado. Em sistemas modernos com prepared statements, o escaneamento automático frequentemente retorna falsos positivos ou demora horas sem conclusão. O que funciona melhor é a análise manual dos parâmetros que passam diretamente para queries dinâmicas. Um desenvolvedor construindo SQL com f-string ou String.Format em Cé um alerta imediato. Para enumeração de Active Directory em testes internos, o Impacket e o CrackMapExec são insubstituíveis. O BloodHound ajuda a visualizar a cadeia de privilégios, mas exige que você tenha pelo menos uma credencial válida no início. Sem isso, o bloodhound não produz gráfico útil.
O problema que ninguém conta
A maioria dos relatórios de penetração que eu li tem um viés sistêmico: os testadores focam nos alvos mais fáceis e ignoram os que realmente importam. Um servidor web com umaCVE conhecida é fácil de demonstrar. Um fluxo de autorização quebrado em uma API REST com JWT mal assinado é muito mais difícil de encontrar e muito mais perigoso. Eu passei semanas em um engagement onde o site principal não entregava nada relevante. O problema estava num microsserviço interno que não estava na lista de escopo original, mas era referenciado nos recursos estáticos do frontend. Ele tinha um endpoint /api/v1/export que aceitava um parâmetro de path traversal em um campo chamado "filename". A saída era salva em S3 e o URL de acesso era retornado na resposta JSON. Isso permitia ler arquivos do sistema operacional do container onde o serviço rodava.
👉 Clique no botão abaixo para saber mais sobre o assunto!
A correção não foi difícil. O time de desenvolvimento havia configurado o bucket S3 como privado e esquecido de validar o nome do arquivo no serviço. Levou dois commits para resolver. O relatório levou quatro páginas descrevendo o impacto potencial.
Como estruturar um teste que funcione
O planejamento é onde a maioria das falhas acontecem. Um cronograma realista para um teste de aplicação web de porte médio, com escopo definido, leva entre cinco e dez dias de trabalho ativo. Menos que isso resulta em superfície coberta superficialmente. Mais que isso geralmente indica escopo mal definido ou dificuldades de acesso. Testes de infraestrutura interna exigem mais tempo porque a exploração é incremental. Você começa com uma única máquina comprometida e precisa mapear movimentos laterais, elevação de privilégio e persistência. Esse processo é imprevisível. Não adianta estimar com precisão.
Um ponto que muitos desprezam é a comunicação durante o teste. Se você encontrar algo crítico às três horas da manhã, enviar um e-mail e esperar retorno até o dia seguinte é irresponsável. Tenha um número de contato de emergência e use-o. Da mesma forma, se o alvo ficar indisponível por mais de duas horas durante o escaneamento ativo, suspenda as atividades e notifique. Ferramentas de varredura intensa podem derrubar serviços legítimos se configuradas sem critério.
O que funciona e o que não funciona
Listas de exploits do Exploit-DB são úteis como referência, mas raramente funcionam no estado bruto. A versão do software, as bibliotecas dependentes, as configurações de hardening — tudo isso altera a exploitabilidade. Um shellcode que funcionou em um lab dockerizado com kernel 5.4 pode não funcionar em um kernel 6.2 com SYSCTL de segurança reforçados. O uso de frameworks como Metasploit acelera a exploração quando o vetor é claro. Mas eles escondem detalhes importantes do que está acontecendo na camada de rede. Para relatórios técnicos sólidos, é necessário entender exatamente como o payload é construído e transmitido. Metasploit não ensina isso por si só.
Aqui vai algo contraintuitivo: ferramentas de segurança muitas vezes deixam rastros óbvios. O tráfego gerado pelo Nmap, pelo Sqlmap e pelo Burp tem assinaturas reconhecíveis. Em ambientes com IDS configured com regras de detecção, a atividade automatizada pode ser flagada e bloqueada rapidamente. Em alguns casos, eu prefiro fazer enumeração manualmente, com curl e requests, mesmo que isso leve mais tempo. O custo em horas extras compensa quando o alvo tem monitoramento ativo.
O fim do relatório
O documento final é mais importante que o teste em si. Um relatório bem escrito traduz vulnerabilidades técnicas em risco de negócio. Classificações como crítico, alto, médio e baixo devem ser justificadas com evidências concretas: captura de tela do exploit em ação, código do payload modificado se necessário, e uma linha clara de como a correção seria aplicada. Incluir passos de reprodução é obrigatório. Um desenvolvedor que recebe uma descrição genérica como "vulnerabilidade de XSS" não tem como agir. Escreva: acesse a página X, insira o payload Y no campo Z, a execução do script se dá quando o usuário clica em W. Esse nível de detalhe economiza dias de investigação interna.
Relatórios técnicos sem recomendações de remediação são inúteis. Cada achado precisa ter pelo menos uma sugestão de correção. Quando existem múltiplas abordagens, apresente a mais simples como prioritária. O time de segurança do cliente não tem orçamento para refatorar toda a base de código baseada no seu relatório.
