Como rastreei R$28 milhões roubados de empresas

O que você vai aprender neste aulão

Nos últimos 12 meses eu vi, na minha frente, R$28 milhões saírem do caixa de empresas que investiam em segurança. Neste aulão eu explico como investigar uma fraude financeira digital a partir do rastro que sobra depois do golpe: uma empresa perdeu R$9 milhões, outra R$6 milhões, outra R$2 milhões, e em nenhuma delas o sistema foi "hackeado" no sentido clássico. Não teve falha de aplicação. Não teve .git derrubando o servidor. Teve credencial de acesso roubada. E credencial roubada muda toda a lógica de uma investigação de dinheiro desviado.

Eu atuei diretamente nessas investigações pós-invasão, então aqui não tem teoria de slide bonito. Vou mostrar as cinco ferramentas que eu uso para reconstruir o caminho do atacante e, principalmente, para entender onde a defesa falhou. O raciocínio é sempre o mesmo: enxergar a empresa como o criminoso enxergou, para conseguir tapar o buraco antes dele. Deixo isso claro logo no começo — o texto inteiro é orientado a reconhecer e se proteger, não a repetir o ataque. É o mindset de quem defende (ou de quem faz pentest autorizado na própria estrutura).

Uma investigação de dinheiro roubado raramente começa no extrato bancário. Ela começa no mapa da superfície digital da vítima. Foi o sistema principal que falhou? Quase nunca. Por isso eu quero te levar por cinco camadas de análise:

• O tamanho real da empresa exposta na internet, o que a gente chama de escopo
• Os erros de configuração que abrem uma porta lateral para dentro
• Os diretórios sensíveis que denunciam a arquitetura por trás do site
• Os servidores e as portas que respondem publicamente sem ninguém perceber
• A credencial vazada que some com o dinheiro sem disparar um único alarme

Esse mesmo caminho serve para dois lados. Serve para o investigador que chega depois do prejuízo e serve para o time de segurança que quer se antecipar. É por isso que casos como o rastreio de golpes financeiros aparecem tanto por aqui, como no Aulão #043 — Como Investigar Golpes do Pix e no Aulão #049 — Rastreamos um Golpista do Pix em 1h45. A diferença é a escala do dinheiro.

Por que investigar uma fraude financeira começa pelo escopo

Toda investigação de dinheiro roubado começa medindo o quanto a empresa está exposta. O site principal, aquele www que o time de TI construiu com carinho, costuma ser a parte mais segura de tudo. O problema mora ao lado.

Quando eu chego numa empresa saqueada, a primeira coisa que eu faço é sair do site principal e procurar o resto: a intranet, o painel de administração, a API, o blog esquecido, o ambiente de homologação, o "sistema-novo" e o "sistema-velho" que ninguém desligou. Cada uma dessas peças é uma aplicação diferente, com um dono diferente e um nível de cuidado diferente. E boa parte das invasões que eu investiguei não entrou pela porta da frente, entrou por um subdomínio que o próprio dono já tinha esquecido que existia.

Para mapear isso eu uso o SecurityTrails. Ele guarda o histórico de DNS de um domínio e devolve a lista de subdomínios de forma passiva, sem tocar no alvo. Num teste que eu fiz ao vivo, um único domínio de referência revelou 184 subdomínios: portais, bibliotecas, intranets, ambientes de desktop remoto. Cada linha daquela lista é uma possível porta de entrada. E SecurityTrails faz exatamente esse trabalho de aumentar o escopo antes de qualquer coisa mais agressiva.

Um detalhe que aparece toda vez nessa listagem é o versionamento. Aplicações batizadas de "novo", "velho", "teste" e "homologação" convivem no mesmo domínio, e é comum a versão de teste ter ficado no ar com uma falha que a produção já corrigiu. O criminoso não precisa da porta principal; ele entra pela cópia esquecida. Numa das empresas que eu investiguei, foi justamente um ambiente antigo, fora do inventário de segurança, que serviu de trampolim para o resto da rede.

Do lado da defesa, o exercício é o mesmo, só que com outro objetivo. Se o atacante consegue listar seus subdomínios em dois minutos, você precisa dessa lista primeiro. Precisa saber o que está no ar, desligar o que não deveria existir e monitorar o resto. Faço esse mapeamento de superfície em toda auditoria, e a técnica de descoberta de subdomínios já foi tema do Aulão #028 — Como Encontrar Subdomínios Escondidos, que vale a leitura para entender o método completo. Dá para reduzir o risco só enxergando o próprio tamanho? Boa parte dele, sim.

Repositórios Git expostos: a falha que a investigação encontra primeiro

Depois de listar o escopo, o investigador procura erros de configuração. O mais grave e mais comum é o repositório Git deixado público por acidente, o famoso Git Exposed.

Funciona assim: o programador sobe a aplicação para o servidor e, sem querer, envia junto a pasta .git, que guarda todo o versionamento do código. Quando essa pasta fica acessível, dá para reconstruir o código-fonte inteiro, os commits, as mensagens entre os programadores e, o pior, as variáveis com senhas e chaves de API que nunca deveriam sair do ambiente interno. É por isso que essa falha paga tanto em programa de recompensa. No Aulão #030 — Bug Bounty na prática eu já tinha comentado essa lógica de reporte responsável, e na HackerOne você encontra relatórios reais de .git exposto sendo pago em grandes empresas.

Para reconhecer o problema nos meus próprios ativos, eu uso a extensão de browser DotGit. Ela roda em segundo plano e, sempre que um site que você acessa tem a pasta .git aberta, dispara um alerta. Num teste eu forcei a situação e a extensão apontou cinco sites com repositório exposto de uma vez, chegando a enumerar 37 arquivos em um deles. E DotGit é o tipo de ferramenta que todo time de TI deveria rodar contra os próprios domínios uma vez por semana.

Dentro de um repositório reconstruído aparece o que nunca deveria ser público: string de conexão com banco de dados, token de API, comentário interno entre programadores e, não raro, senha em texto puro. Para o investigador, é ouro; para a vítima, é o começo de um problema sério. Por isso eu trato .git aberto como incidente de segurança, e não como curiosidade técnica.

Aqui vale o meu enquadramento de sempre. Eu não ensino a saquear repositório de terceiro. Eu mostro como a falha aparece para que você a corrija no seu lado: um .gitignore correto, a pasta .git bloqueada no servidor e uma varredura periódica. A ferramenta que faz o download reverso do repositório (o git-dumper, do projeto GitTools) existe e é pública, mas o uso legítimo dela é auditar o que é seu ou o que você tem autorização por escrito para testar. Mas a real é que a maioria dos vazamentos de .git que eu encontro poderia ter sido evitada com uma linha de configuração. Encontrar essa falha na investigação é comum. Ela existir ainda é o que me assusta. Google dorks também revelam esse tipo de arquivo, tema que eu detalhei no Aulão #008 — Buscas Perigosas no Google.

Diretórios sensíveis e falhas de configuração no radar do investigador

Nem todo diretório perigoso está num repositório Git. Muita coisa fica solta no servidor: um .env, um .config, um backup, um painel de admin sem senha. O investigador precisa achar isso rápido, e o atacante também.

O segredo é entender que programadores erram em padrão. O nome de pasta que você acha criativo (admin, backup, config-old) já está catalogado. Existe um projeto no GitHub chamado SecLists que reúne listas de palavras com praticamente todos os nomes de diretório e arquivo que costumam expor falha. É a maior coleção pública desse tipo, organizada por tecnologia. Segurança por obscuridade não funciona: se você escondeu, está numa lista. E SecLists prova isso a cada linha.

Com uma dessas listas na mão, a ferramenta faz o trabalho braçal de testar cada caminho contra a aplicação. Eu uso o Gobuster, escrito em Go e bem rápido, mas quando quero algo já pronto no Kali Linux costumo abrir o dirb, que faz a mesma coisa em ritmo mais calmo. Num teste rápido o dirb já apontou o .git, um redirecionamento e caminhos de configuração de servidor, tudo em segundos. O ponto importante da investigação (e da defesa) é escolher a lista certa: se o alvo roda Apache, uso a lista de padrões do Apache; se roda ASP.NET, troco a lista. Conhecer a tecnologia antes de disparar evita ruído e evita derrubar serviço.

Do lado de quem defende, esse capítulo é um convite ao inventário. Rode a mesma varredura contra os seus próprios sistemas, veja o que responde e feche o que não deveria estar público. Um diretório de backup aberto é, muitas vezes, o atalho que liga o site à conta bancária da empresa. Vale a pena fazer essa faxina? Sempre.

Portas abertas e serviços: o mapa do servidor na investigação

Cada subdomínio roda em algum servidor, e cada servidor tem portas. A porta 80 responde o site, a 443 o site com SSL, a 22 o acesso remoto por SSH, a 21 um FTP. Cada porta aberta é um software rodando, e todo software pode estar desatualizado e vulnerável.

Por isso o investigador faz o mapeamento de portas, o port scanning. A ferramenta padrão para isso é o Nmap. Ele descobre quais portas estão abertas e, com o versionamento, revela qual software e qual versão respondem em cada uma. E Nmap é a mesma ferramenta que uso para checar se um exploit conhecido se aplica àquela versão específica daquele serviço. Uma versão antiga de FTP ou de painel de gestão exposta é o tipo de detalhe que explica como um atacante circulou dentro do ambiente antes de mexer no dinheiro.

Tem um detalhe técnico que eu gosto de mostrar. O comando padrão do Nmap conversa demais com o servidor. Quando eu só quero saber o status de uma porta, uso o SYN scan, o -sS. Ele pergunta "essa porta está aberta?", recebe a resposta e encerra sem completar a conexão. É mais leve e mais discreto. Penso nisso como uma porta com fechadura: primeiro você descobre que a porta existe, depois que ela tem uma fechadura (o serviço), depois a marca e o ano daquela fechadura (a versão), e só então procura se alguém já publicou a receita para abri-la. Descobrir dispositivos e serviços expostos na internet também é o assunto do Aulão #020 — Shodan na Prática, que complementa bem esse raciocínio de superfície de servidor.

Para a defesa, a lição é dura e simples. Cada porta aberta sem necessidade é uma porta que alguém vai bater. Feche o que não usa, atualize o que precisa ficar aberto e coloque acesso remoto atrás de VPN. Mas nenhuma dessas quatro primeiras camadas explica, sozinha, os R$28 milhões. A explicação está na quinta.

InfoStealers: a peça que explica o dinheiro roubado

Aqui está o ponto que fecha a investigação. Nas três empresas que somaram R$28 milhões, o acesso não veio de exploit, de .git ou de porta aberta. Veio de credencial roubada por InfoStealer. Foi falha técnica no sistema? Não foi. Foi uma senha que já estava à venda.

InfoStealer é um malware feito para uma coisa só: ler o que está guardado na máquina da vítima. E InfoStealer não tenta adivinhar senha nenhuma, ele simplesmente copia o que já está salvo no browser: usuário, senha, cookie de sessão, histórico, dados de preenchimento automático. Em minutos, tudo isso vira um pacote (um "log") que sai do computador sem alarde. Existe até um mercado de malware como serviço, com aluguel e revenda desses códigos, o que coloca a arma na mão de qualquer um.

E é aqui que a investigação vira defesa de verdade. Esses logs são vendidos em mercados na dark web por valores absurdos de baixos, entre US$2 e US$10 o pacote. Quando eu chego numa empresa invadida, a primeira consulta que eu faço é procurar se existe log de InfoStealer daquela empresa à venda. E é aí que o escopo das primeiras camadas se junta com esta: como eu já sei os subdomínios (o sistema., o admin., o painel financeiro), eu consigo filtrar, naquele mar de máquinas infectadas, exatamente as credenciais que dão acesso ao dinheiro. O criminoso que vende a US$10 está vendendo invasão em massa e nem sabe o que tem na mão. O investigador que conhece o alvo, sabe.

Os números externos assustam. Levantamentos recentes apontam o Brasil entre os países mais atingidos por ladrões de informação na região, e a Flashpoint registrou, no primeiro semestre de 2026, 7,4 milhões de dispositivos infectados no mundo, uma alta de 27% sobre o semestre anterior. Não é um problema de nicho. É o vetor de fraude financeira que mais cresce, e ele conversa direto com o que eu já mostrei sobre senhas expostas no Aulão #009 — Investigar Vazamentos de Senhas e sobre o clique que entrega tudo no Aulão #058 — Como se Proteger de Phishing e Engenharia Social.

Por dentro, um log de InfoStealer é uma pasta com o retrato completo da máquina infectada: informações do computador no momento da captura, lista de programas instalados, processos em execução, histórico do browser, perfil salvo e um arquivo de texto com todas as senhas guardadas. É um raio-x da vida digital da pessoa. E basta um funcionário com o dispositivo infectado, usando credencial corporativa, para a empresa inteira entrar naquele pacote de US$10. Foi assim, e não por genialidade técnica do atacante, que boa parte dos R$28 milhões escorreu.

Para se defender, o monitoramento é a chave. Serviços como o Have I Been Pwned deixam qualquer pessoa checar se um e-mail apareceu em vazamento conhecido, e é um primeiro passo gratuito. E Have I Been Pwned não substitui monitoramento corporativo dedicado de logs de InfoStealer, mas já mostra a lógica: a defesa hoje é achar a credencial vazada antes do criminoso usar. Mas o dinheiro não sai da conta quando a senha vaza; sai quando ninguém está olhando. É por isso que consultar vazamento virou rotina obrigatória nas minhas investigações.

Ferramentas que usei nesta investigação

Reuni as cinco ferramentas do aulão numa tabela. Todas são de uso legítimo em pentest autorizado, auditoria da própria empresa e resposta a incidente. O objetivo de cada linha é reconhecer o risco e corrigir, nunca atacar quem não te deu permissão.

Ferramenta	Para que serve na investigação	Uso defensivo	Onde encontrar
SecurityTrails	Mapear subdomínios e histórico de DNS (escopo)	Inventariar o que a empresa expõe e desligar o esquecido	Serviço web com conta gratuita
DotGit	Alertar sobre .git exposto enquanto você acessa sites	Varrer os próprios domínios atrás de repositório aberto	Extensão de browser open source
SecLists + Gobuster	Encontrar diretórios e arquivos sensíveis por lista de palavras	Auditar caminhos abertos nos próprios servidores	Listas no GitHub, Gobuster e dirb no Kali
Nmap	Descobrir portas abertas, serviços e versões	Fechar portas sem uso e atualizar serviços vulneráveis	Gratuito para Linux e Windows
Have I Been Pwned	Checar se credenciais apareceram em vazamento	Monitorar exposição de contas antes do incidente	Consulta gratuita por e-mail

Como se proteger de uma fraude financeira digital

O lado prático da investigação é a defesa. Se o dinheiro saiu por credencial roubada, a proteção não é só firewall, é higiene de acesso. Reuni o que eu recomendo para as empresas que atendo depois de um saque, na ordem de prioridade que aplico:

• Ative autenticação multifator em tudo que toca dinheiro: banco, painel financeiro, e-mail corporativo e VPN. Uma senha roubada sozinha deixa de ser suficiente.
• Mantenha antivírus e EDR atualizados e bloqueie software pirata e extensões de fora das lojas oficiais, que são o principal vetor de InfoStealer.
• Monitore vazamentos de credenciais da empresa de forma contínua, não só uma vez por ano.
• Reduza o escopo exposto: desligue subdomínios e ambientes de teste que ninguém usa mais.
• Corrija erros de configuração conhecidos, o .git, o .env, backups abertos e portas sem necessidade.
• Rode uma varredura de descoberta contra a própria estrutura antes que o atacante rode contra você.

Se você já foi vítima, registre o incidente e procure a Polícia Federal ou a autoridade competente. Preservar o rastro (logs, prints, datas) é o que sustenta uma investigação séria depois.

Perguntas Frequentes

Como investigar uma fraude financeira digital em uma empresa?

Comece mapeando a superfície exposta (escopo, subdomínios, portas) e só depois olhe o rastro financeiro. Na maioria dos casos que eu atendi, a origem foi uma credencial roubada por InfoStealer, então checar logs vazados da empresa costuma explicar o acesso mais rápido que qualquer análise de código.

O que é um InfoStealer e por que ele é tão perigoso?

É um malware feito para copiar senhas, cookies de sessão e dados salvos no browser da vítima. Ele é perigoso porque não precisa quebrar nenhum sistema: rouba credenciais legítimas e as vende barato em mercados na dark web, permitindo login direto no ambiente da empresa.

Rastrear o dinheiro roubado adianta? Dá para recuperar?

Rastrear adianta para identificar o vetor e conter o vazamento. Recuperar o valor depende de velocidade, de bloqueio bancário e de decisão judicial, então nem sempre é possível. Por isso o foco desse trabalho é cortar o acesso e evitar o próximo saque.

Essas ferramentas de investigação são legais de usar?

Sim, quando usadas na própria estrutura, em pentest com autorização por escrito ou em resposta a incidente. Usar contra terceiros sem permissão é crime, e este conteúdo é orientado a defesa e reconhecimento, não a ataque.

Como sei se as credenciais da minha empresa vazaram?

Consulte serviços de checagem de vazamento por e-mail e, para uso corporativo, contrate monitoramento contínuo de logs de InfoStealer. O sinal de alerta costuma ser acesso não autorizado ou tentativa de login estranha, que deve ser investigada na hora.

Fechar subdomínios e portas antigas ajuda mesmo contra fraude?

Ajuda, e muito. Cada ambiente esquecido é uma porta lateral com menos vigilância. Reduzir o escopo exposto diminui o número de lugares por onde uma credencial vazada pode ser usada e simplifica o monitoramento do que sobra.

Referências e Recursos

• SecurityTrails (documentação oficial)
• DotGit no GitHub
• GitTools / git-dumper no GitHub
• SecLists no GitHub
• Gobuster no GitHub
• Nmap: técnicas de port scanning
• HackerOne (programas de bug bounty)
• Have I Been Pwned
• OWASP: Credential Stuffing
• Polícia Federal