Infostealer: o vírus que rouba a senha antes do ransomware

Existe uma sequência que se repete tanto em relatórios de resposta a incidentes que virou padrão. Uma empresa é atingida por ransomware. A investigação descobre que o invasor entrou usando uma credencial válida — não explorou vulnerabilidade, não quebrou senha, apenas fez login. E, semanas antes, um funcionário havia instalado alguma coisa no computador de casa.

Esse alguma coisa costuma ser um infostealer: um malware discreto, de objetivo estreito, que rouba credenciais e vai embora sem quebrar nada.

Ele é o passo que quase ninguém discute, porque não produz manchete. O ransomware é o desfecho barulhento. O infostealer é a causa silenciosa, e é onde a defesa custa muito menos.

A tese em uma frase: quase todo ataque de credencial válida começa semanas antes, num computador que ninguém considerava crítico — e a janela entre o roubo e o uso é o momento mais barato de interromper a cadeia inteira.

O que ele leva

Um infostealer roda por poucos minutos e mira coisas específicas:

• Senhas salvas no navegador. O gerenciador embutido do Chrome, Edge e Firefox — que a maioria das pessoas usa sem pensar.
• Cookies de sessão. O item mais valioso e o menos compreendido. Ver abaixo.
• Tokens de autenticação de aplicações e serviços de nuvem.
• Carteiras de criptomoeda e chaves privadas.
• Arquivos de configuração de cliente VPN, cliente SSH e ferramentas de acesso remoto.
• Capturas de tela e lista de programas instalados, que ajudam o comprador a avaliar o valor do acesso.

Tudo isso é empacotado num stealer log e vendido. E aqui está o detalhe econômico que organiza o resto: quem infecta raramente é quem invade. Existe um mercado intermediário — os corretores de acesso inicial — que compra logs, testa credenciais, identifica quais pertencem a empresas interessantes e revende o acesso qualificado a operadores de ransomware.

Essa divisão de trabalho explica a janela de tempo. Entre a infecção e o ataque passam semanas — e é nessa janela que a defesa é barata.

Os números que ligam infostealer a ransomware

O DBIR 2026 da Verizon e os relatórios de exposição de identidade dão a dimensão:

• Metade das vítimas de ransomware teve um vazamento por infostealer nos 95 dias anteriores ao ataque.
• 54% dos dispositivos presentes em logs de corretores de acesso inicial tinham ao menos um infostealer instalado.
• Uma média de 2.362 credenciais corporativas por mês aparece em bases de stealer logs, por domínio organizacional.
• 5,3 bilhões de pares de credenciais circulavam em fontes criminosas no último ano.
• 4 em cada 10 usuários corporativos reutilizaram uma senha que já estava exposta.

O abuso de credencial segue como a técnica mais presente ao longo das cadeias de ataque, com 39% — mesmo depois de a exploração de vulnerabilidade ter assumido o primeiro lugar como vetor inicial, com 31% e alta de 55% no ano.

A leitura prática: vulnerabilidade abre a porta com mais frequência, mas credencial é o que o invasor usa para circular depois que entrou. São dois problemas distintos e ambos precisam de resposta.

O cookie de sessão: por que trocar a senha não basta

Este é o parágrafo que mais muda a prática de quem responde a incidentes.

Quando você faz login num serviço e aprova o MFA, o servidor emite um cookie de sessão — um comprovante de que aquela autenticação já aconteceu e já foi validada. É o que evita que você digite senha a cada clique.

Se o infostealer copia esse cookie, o criminoso o injeta no navegador dele e entra como você, sem senha e sem MFA. Do ponto de vista do servidor, a sessão é legítima: ela foi criada corretamente.

Consequências diretas:

• Trocar a senha não invalida a sessão na maioria dos serviços, a menos que você peça explicitamente. Você trocou a fechadura com o invasor dentro.
• MFA não ajuda aqui. Ele foi aprovado antes do roubo, e o cookie carrega essa aprovação.
• Passkeys reduzem o valor da credencial, como discuti no post sobre SIM swap e OTP por SMS, mas não impedem o sequestro de uma sessão já emitida.

A defesa que realmente morde é encurtar a vida das sessões e vinculá-las a características do dispositivo, de modo que um cookie usado de outra máquina seja recusado. É configuração no provedor de identidade, não compra de ferramenta.

De onde vem a infecção

Quase sempre de download voluntário, o que muda completamente a estratégia de defesa. Os vetores mais comuns:

• Instalador de software pirata e ativador de licença.
• Mod e trapaça de jogo.
• Extensão de navegador falsa, incluindo clones de ferramentas populares.
• "Ferramenta de IA gratuita" divulgada em anúncio patrocinado — vetor que cresceu muito.
• Anexo em campanha de phishing comum.

Repare no padrão: o usuário executa por vontade própria, frequentemente desativando o antivírus porque o instalador "dá falso positivo". A instrução vem junto com o download.

E o vetor que mais dói na prática corporativa: o computador pessoal. O funcionário instala algo em casa, no mesmo navegador em que está logado no e-mail corporativo, no CRM e no painel da nuvem. A empresa não tem controle nenhum sobre aquela máquina — e as credenciais dela valem tanto quanto as do notebook corporativo.

O que fazer

Em ordem de retorno.

1. Impedir execução, não detectar depois. Controle de aplicação — só roda o que está autorizado — resolve a categoria inteira, porque o vetor é execução voluntária de binário desconhecido. É mais eficaz do que qualquer antivírus, e mais chato de administrar. Vale para as máquinas que acessam sistema crítico.

2. Encurtar sessão e vincular a dispositivo. Configuração no provedor de identidade. Sessão de 30 dias é conveniência que custa caro; sessão que morre em horas e recusa uso de outro dispositivo transforma o cookie roubado em lixo.

3. Monitorar stealer logs por domínio. Se ninguém na sua empresa consulta se há credenciais corporativas circulando, a resposta estatisticamente provável é que há. É uma consulta barata e o retorno é imediato: você descobre a infecção na janela entre o roubo e o uso.

4. Separar pessoal de corporativo. Perfil de navegador distinto, no mínimo. Idealmente, acesso corporativo apenas de dispositivo gerenciado — que é o pilar de dispositivo do Zero Trust.

5. Parar de usar o gerenciador do navegador para senha corporativa. É o alvo principal e o mais fácil de saquear. Um gerenciador dedicado, com cofre criptografado e desbloqueio próprio, eleva bastante o custo do roubo.

E se já aconteceu

A ordem correta importa:

1. Isole a máquina da rede.
2. Revogue todas as sessões ativas em cada serviço — antes de trocar senha, não depois.
3. Troque as senhas, a partir de outro dispositivo confiável.
4. Reemita tokens e chaves de API, VPN e SSH que estavam naquela máquina.
5. Verifique acessos recentes nos serviços críticos — login de local incomum, regra de encaminhamento de e-mail criada, aplicativo novo autorizado.
6. Reinstale o sistema. Infostealer costuma vir acompanhado, e limpeza parcial não dá garantia.

O passo 2 é o que quase todo mundo pula, e é o que decide se o incidente acabou. Se a sua empresa tem plano de resposta a incidentes, esse roteiro deveria estar nele.

O ponto que fica

O infostealer é o exemplo mais claro de que segurança é uma cadeia, e de que atacar o elo mais barato rende mais do que reforçar o mais caro.

Uma empresa pode investir bem em XDR, backup e monitoramento — e ser invadida porque alguém baixou um ativador de licença no computador de casa, num navegador que tinha a sessão do painel da nuvem aberta.

Se você for fazer uma coisa só depois deste texto, faça a consulta de stealer logs para o seu domínio. É rápido, é barato, e o resultado costuma ser suficientemente desconfortável para destravar o resto.