O arsenal que eu abro toda semana para investigar (e blindar) aplicações web

O que você vai aprender neste aulão

As ferramentas hacker que eu uso todos os dias não são um top 4 de ranking nem a lista definitiva da internet. São, literalmente, as quatro que mais abri no terminal e no browser na última semana enquanto investigava alvos reais. Neste aulão eu mostrei FFuf, ChatGPT, SecurityTrails e DevTools em ação, e o mais interessante é o que cada uma revela sobre uma aplicação web. Aqui eu explico como elas funcionam, por que eu uso cada uma no dia a dia da investigação digital e do teste de segurança autorizado, e como você fecha as portas que elas deixam expostas.

Antes de qualquer coisa: este conteúdo é para você reconhecer e se defender. Fuzzing, análise de subdomínios e leitura de requisições são técnicas de pentest autorizado, bug bounty e investigação de fraude. Você aplica no seu próprio sistema, na sua empresa ou num escopo que te deram permissão para testar. Não é manual de ataque contra terceiros.

O que você leva deste aulão:

• Como o fuzzing acha diretórios, parâmetros e falhas de lógica que ninguém devia ver
• Como usar a IA para ler respostas de servidor e entender comportamentos estranhos
• Como o histórico de DNS entrega máquinas e ambientes que o dono achava escondidos
• Como o console do browser revela dados que o código-fonte da página esconde

FFuf: fuzzing para achar (e fechar) portas abertas na sua aplicação

O FFuf é a ferramenta que eu mais uso hoje, todo dia, sem exagero. Ela faz fuzzing, e fuzzing é o processo de mandar entradas em série contra um sistema para ver qual delas gera um comportamento fora do padrão. A analogia que eu dei na aula: é como jogar milhões de chaves diferentes numa fechadura para ver qual abre, ou qual faz a fechadura reagir de um jeito estranho.

Repare que fuzzing é diferente de força bruta. No brute force eu quero adivinhar usuário e senha para ganhar acesso. No fuzzing eu quero descobrir o que existe e o que quebra: um diretório admin que respondeu diferente, um arquivo .git exposto, um parâmetro que aceita um valor inesperado. É a diferença entre arrombar a porta e descobrir que existe um código de reset que ninguém protegeu.

Na demonstração eu rodei o FFuf com uma wordlist e o alvo apontando para onde entra a palavra FUZZ. A ferramenta substitui esse marcador por cada linha da lista e dispara requisições de forma acelerada. Em segundos ela achou um arquivo class e um development.log que estavam ali, esquecidos. E foi só o começo, porque eu quase nunca paro no fuzzing de diretório hoje.

O que mudou no meu dia a dia:

• Fuzzing de parâmetro: eu testo o valor dentro de uma busca ou de uma API e observo o status HTTP de cada resposta
• Fuzzing recursivo: quando ele acha um diretório como admin, ele entra e continua a busca lá dentro sozinho
• Filtro de ruído: com -fc 200 eu escondo tudo que respondeu 200 e sobra só o que fugiu do padrão (302, 500, 403)
• Fuzzing em endpoints de IA: dá para sondar um assistente atrás de vazamento de prompt, sempre em ambiente próprio e autorizado

Foi assim que eu achei o comportamento mais interessante da noite. Num parâmetro de busca de um e-commerce, o texto hacker respondia 200, mas o número 01 devolvia 500 e o valor 2257 respondia 302 e redirecionava. Isso é o cheiro clássico de um identificador interno vazando: um id sequencial que o sistema resolve de formas diferentes conforme o valor. É o tipo de falha de lógica de negócio (IDOR) que só aparece quando você olha a resposta, não a tela. Se você quiser se aprofundar em como um único parâmetro conta a história inteira de um site, eu destrinchei isso no Aulão #063 — como investigar uma URL.

E aqui entra a parte defensiva, que é o ponto. Se o FFuf acha seu .git, seu .env ou seu development.log, o problema não é a ferramenta, é a exposição. A wordlist que eu usei está cheia de padrões de vazamento que programador esquece no servidor (a mesma ideia por trás dos Aulão #008 — buscas perigosas com Google dorks). Para se defender: bloqueie o acesso a arquivos de configuração e log, aplique rate limiting para que ninguém dispare milhares de requisições no seu servidor, e trate identificadores sequenciais como o que eles são, um risco de IDOR que precisa de checagem de autorização. Vale a pena testar seu próprio sistema com FFuf antes que outra pessoa faça isso? Vale, e muito.

Uma coisa que eu repito sempre: a velocidade é o que torna o fuzzing tão perigoso quanto útil. Fazer esse teste na mão, uma requisição de cada vez, levaria dias inteiros. E FFuf faz isso em segundos, disparando milhares de possibilidades enquanto você toma um café e olha o resultado chegando na tela. Mas velocidade sem critério vira só barulho, um monte de linha que não diz nada. Por isso eu filtro por status, leio o que fugiu do padrão e só então decido o próximo passo. É essa leitura fina, e não a ferramenta em si, que separa quem investiga de quem só sai rodando comando no escuro.

ChatGPT como copiloto de análise de segurança

A segunda ferramenta que anda o tempo todo comigo é o ChatGPT. Não para escrever exploit mágico (não é isso), mas para ler comportamento e acelerar raciocínio. Quando o fuzzing cospe centenas de linhas de resposta, ler tudo na mão é inviável. Então eu jogo o contexto para a IA e pergunto o que pode explicar aquilo.

Na aula eu fiz exatamente isso duas vezes. Primeiro, eu não lembrava o comando para filtrar respostas no FFuf, perguntei, e ele me lembrou do -fc para ignorar um status. Depois, eu descrevi o padrão estranho: uma URL que retorna 200 na maioria dos termos, mas 302 num número específico e 500 no valor 01. Passei isso para a IA como quem pede a um colega de bug bounty para pensar junto, e ela sugeriu a hipótese do identificador interno sequencial e como confirmar de forma responsável.

O caso que mais me marcou foi de decodificação. Eu tinha dois identificadores de um ativo meu num sistema (um tipo 001 e outro tipo 01010) e não sabia a regra de geração. Mandei os dois para a IA, ela identificou que aquilo era um encode, me explicou o tipo de codificação por trás e eu consegui entender a sequência. Repare: eram ativos meus, no meu escopo. Esse é o uso legítimo, e é o que eu recomendo.

A IA erra, inventa e às vezes te empurra num caminho que não existe. Por isso ela é copiloto, não piloto. Eu uso para gerar hipótese, lembrar sintaxe e resumir resposta, e sempre confirmo na mão. Mas o ganho de velocidade é grande quando você já sabe o que está procurando. Se você quer ver a IA aplicada a caso de investigação do início ao fim, eu mostrei o fluxo completo no Aulão #006 — ChatGPT para investigação digital.

E do lado da defesa, fica o alerta: se a sua aplicação expõe mensagens de erro detalhadas, stack traces e status inconsistentes, você está entregando de graça o material que a IA vai usar para montar a hipótese de ataque. Padronize respostas de erro, esconda detalhes internos do servidor e nunca confie em identificador só porque ele parece aleatório na tela.

Vou ser honesto sobre o limite disso, porque acho importante. E ChatGPT não substitui o seu conhecimento de base, ele multiplica o que você já tem na cabeça. Se você não sabe o que é um status HTTP nem o que é um parâmetro de URL, a resposta da IA vira ruído e te leva para o buraco errado. Mas quando você domina o fundamento, a IA vira um colega que pensa junto às três da manhã, sem reclamar e sem cansar. Foi esse equilíbrio, usar a IA como acelerador e nunca como verdade absoluta, que me fez adotar a ferramenta de vez no meu fluxo de investigação.

SecurityTrails: subdomínios e histórico de DNS que ninguém devia ver

A terceira ferramenta é a mais fácil de usar de todas, e talvez a mais perigosa pelo tanto que entrega. É o SecurityTrails, e o melhor é que eu nem preciso abrir o terminal: rodo tudo no browser. Ela é excelente para achar subdomínios, ver alterações de DNS e, principalmente, o histórico de para onde um domínio já apontou. Tem plano gratuito com um limite que dá para trabalhar bem, e é só criar a conta.

Na demonstração eu criei uma conta ao vivo e consultei domínios reais. Num deles, o SecurityTrails me mostrou o IP da Microsoft para onde o domínio apontava seis anos atrás, e uma lista de subdomínios que abre um mundo: dev, backoffice (rodando um sistema SAP), prod, api, api3 e um ambiente de parceiro com tela de login. Cada um desses subdomínios vira um novo alvo de análise. O ambiente dev costuma ser mais frouxo que o de produção, e o backoffice quase nunca deveria estar acessível pela internet aberta.

É por isso que essa ferramenta conversa direto com o FFuf. Eu saio da aplicação principal, descubro uma API num subdomínio esquecido, e é ali que o fuzzing de parâmetro começa a render de verdade. O mapa de subdomínios é o mapa de superfície de ataque, e quanto maior a superfície, maior o risco. Eu me aprofundei nas técnicas de descoberta de subdomínios, incluindo alternativas gratuitas, no Aulão #028 — como encontrar subdomínios escondidos, e em como transformar cada serviço exposto em alvo de mapeamento no Aulão #036 — técnicas para investigar sites.

E SecurityTrails não trabalha sozinho na hora de se defender. Se você é dono do domínio, faça a busca você mesmo, com regularidade: veja quais subdomínios estão públicos, derrube os ambientes de teste que vazaram para a internet e confira o histórico de DNS atrás de apontamentos antigos que ainda respondem. Ferramentas como o Shodan complementam esse trabalho mostrando o que cada IP expõe, algo que eu demonstrei no Aulão #020 — como usar o Shodan. A regra é simples: o que você não sabe que está exposto é exatamente o que vão achar primeiro.

DevTools: o console do browser como lupa de investigação

A quarta ferramenta não precisa de instalação nenhuma. É o DevTools, o console de desenvolvedor que já vem no seu browser. Botão direito, inspecionar, aba Network, marca preservar o log e dá um F5. A partir daí você vê todas as requisições que a página faz por baixo dos panos. E é aqui que mora informação que o código-fonte simplesmente não mostra.

Cada vez mais as aplicações separam a interface dos dados. O front-end carrega e consome um fetch numa rota, a autenticação vai para um serviço como o Supabase, a hospedagem está na Vercel, e cada uma dessas conexões aparece no Network. Quando eu encontro um endpoint de requisição ali, eu trago de volta para o meu cenário de análise: é mais um caminho para fuzzing, mais superfície para investigar. Muitas vezes um endpoint que não estava no SecurityTrails nem na força bruta aparece limpinho no console do browser.

O uso que mais me diferencia em investigação, porém, é contra fraude. Quando você chega no checkout de um curso ou de uma loja, boa parte das empresas esconde da tela quem está por trás do produto. Só que, ao inspecionar as requisições no DevTools, muitas vezes aparecem dados de cadastro do responsável, do vendedor, da tecnologia de pagamento (Hotmart, gateways, marketplaces) que não estavam no código-fonte visível. Isso é ouro para quem investiga golpe, porque revela quem está processando aquela venda. Eu detalhei esse tipo de rastreio de loja e checkout no Aulão #034 — como investigar lojas virtuais.

Tem uma sutileza importante aqui. Ver o código-fonte da página (aquele "ver código-fonte" do botão direito) te mostra só o HTML entregue. O DevTools te mostra o que a API trouxe depois, em tempo real. São coisas diferentes, e a segunda entrega muito mais. Se você gosta desse tipo de recurso que vive dentro do browser, eu reuni um arsenal de extensões e ferramentas de console no Aulão #042 — ferramentas de investigação no browser.

Do ponto de vista de quem defende: entenda que tudo que seu front-end consome é visível. Não mande dado sensível para o browser achando que ninguém vai ler a resposta da API. Se um cadastro não deveria aparecer para o cliente, ele não pode trafegar na requisição, ponto. O DevTools é gratuito e universal, então parta do princípio de que qualquer pessoa está lendo o que sua aplicação responde.

Tem gente que ainda acha que precisa de ferramenta cara e complicada para começar. E DevTools desmonta esse mito na hora, porque ele é gratuito, já vem instalado no browser e mostra a aplicação por dentro sem pedir licença a ninguém. Mas o valor de verdade não está no botão, e sim no hábito de sempre abrir a aba Network antes de tirar qualquer conclusão sobre um site suspeito. Quando eu investigo uma fraude, essa é a primeira aba que eu abro, todas as vezes, porque é ali que a máscara do golpista costuma cair.

As 4 ferramentas hacker que eu uso todos os dias

Juntando tudo, essas são as quatro que fizeram parte da minha semana de investigação e teste de segurança. Cada link abaixo eu validei, e cada ferramenta cobre uma etapa diferente do processo, do mapeamento à leitura fina da resposta.

Ferramenta	O que ela faz no meu fluxo	Link oficial
FFuf	Fuzzing acelerado de diretórios, arquivos e parâmetros para achar o que fugiu do padrão	FFuf no GitHub
ChatGPT	Copiloto para ler respostas de servidor, lembrar sintaxe e levantar hipóteses de falha	ChatGPT (Wikipédia)
SecurityTrails	Subdomínios, alterações e histórico de DNS direto no browser, com plano gratuito	SecurityTrails Docs
Chrome DevTools	Leitura das requisições reais da aplicação, endpoints e dados escondidos do código-fonte	Chrome DevTools

Repare no encadeamento. O SecurityTrails me dá os subdomínios, o DevTools me dá os endpoints que cada um consome, o FFuf testa esses endpoints em busca de comportamento estranho, e o ChatGPT me ajuda a entender o que aquele comportamento significa. Não é sobre dominar cada ferramenta a fundo (eu não sei programar todas elas), é sobre saber que existem e combiná-las com curiosidade.

Como se proteger do que essas ferramentas revelam

Se este aulão te deixou preocupado, ótimo, era essa a intenção. Toda técnica que eu mostrei tem um espelho defensivo, e é ele que importa para a maioria das pessoas que me acompanha. Você não precisa virar pentester para usar esse conhecimento a seu favor.

A defesa prática, no seu próprio ambiente:

• Bloqueie arquivos e diretórios sensíveis (.git, .env, logs, backups) para que o fuzzing não ache nada útil
• Aplique rate limiting e monitore picos de requisição, que é a assinatura de quem está rodando fuzzing contra você
• Trate todo identificador sequencial com checagem de autorização, para fechar a porta do IDOR
• Padronize mensagens de erro e esconda status internos, tirando o mapa da mão de quem investiga
• Audite seus subdomínios no SecurityTrails e derrube ambientes de teste expostos
• Parta do princípio de que o DevTools lê tudo: dado sensível não trafega para o browser

Eu sempre falei que o mesmo conhecimento que acha a falha é o que corrige a falha. Ao longo destes anos eu encontrei brechas e também fechei brechas, resolvi caso e protegi cliente, exatamente porque entendo o dois lados. Isso é invasão? Quando é no seu escopo e com permissão, não, é teste de segurança. E é assim que eu recomendo que você trate cada uma dessas quatro ferramentas.

Perguntas Frequentes

O que é fuzzing e para que serve o FFuf?

Fuzzing é o processo de enviar entradas em série contra um sistema para descobrir o que existe e o que quebra, observando respostas fora do padrão. O FFuf automatiza isso com velocidade, testando diretórios, arquivos e parâmetros a partir de uma wordlist, e é uma das principais ferramentas de pentest autorizado e bug bounty.

Usar essas ferramentas hacker é ilegal?

As ferramentas em si são neutras e de uso profissional em segurança. O que define legalidade é o alvo e a permissão: testar seu próprio sistema, o da sua empresa ou um escopo autorizado é legítimo. Rodar contra terceiros sem autorização é crime, e não é isso que eu ensino.

Preciso saber programar para usar o SecurityTrails e o DevTools?

Não. O SecurityTrails roda inteiro no browser, com conta gratuita, e entrega subdomínios e histórico de DNS em poucos cliques. O DevTools já vem instalado no browser e basta abrir a aba Network para ler as requisições, então qualquer pessoa consegue começar hoje.

Como o ChatGPT ajuda numa análise de segurança sem virar muleta?

Ele funciona como copiloto para lembrar sintaxe de comando, resumir centenas de respostas e levantar hipóteses sobre um comportamento estranho. A IA erra e inventa, então toda sugestão precisa de confirmação manual, mas o ganho de velocidade é grande quando você já sabe o que procura.

Como eu defendo minha aplicação contra fuzzing?

Comece bloqueando o acesso a arquivos de configuração e log, aplique rate limiting para conter rajadas de requisição e trate identificadores sequenciais com checagem de autorização. Padronizar mensagens de erro também ajuda, porque tira do atacante o mapa de comportamentos que ele usaria.

O que o DevTools mostra que o código-fonte da página não mostra?

O código-fonte exibe só o HTML entregue no primeiro carregamento. O DevTools, na aba Network, mostra as requisições que a aplicação faz depois, incluindo o que a API devolve em tempo real. É por isso que dados de cadastro escondidos em checkouts de fraude aparecem no console e não no código-fonte.

Referências e Recursos

• FFuf — repositório oficial no GitHub
• SecurityTrails — documentação oficial
• Chrome DevTools — documentação para desenvolvedores
• OWASP — introdução a Fuzzing
• SecLists — coleção de wordlists para fuzzing
• FFuf no Kali Linux — página da ferramenta
• MDN — Fetch API, como o front-end consome endpoints