Senha de funcionário apareceu em log de infostealer: o que fazer antes que vire tomada de conta
Infostealers como RedLine, Lumma e Vidar coletam de máquinas infectadas muito mais do que senhas salvas: cookies de sessão, dados de preenchimento automático, carteiras de cripto e chaves SSH, tudo revendido em pacotes chamados de logs. O artigo (baseado em orientação da empresa Flare) explica que um cookie de sessão roubado pode permitir que o atacante reproduza o login já autenticado, pulando completamente a etapa de MFA, e propõe um fluxo de priorização e resposta para equipes de segurança.
O ponto central do artigo é uma distinção que muitas equipes de segurança ainda tratam como equivalente, mas não é: vazamento de senha versus vazamento de sessão autenticada. Quando só a senha vaza, o atacante ainda precisa passar pelo login e, na maioria dos casos, pelo segundo fator — e é nesse momento que alertas de acesso suspeito ou MFA bem implementado bloqueiam a fraude. Quando o infostealer também captura o cookie de sessão do navegador, o atacante pode importar esse cookie e assumir a sessão já autenticada, sem nunca disparar um prompt de MFA, porque, do ponto de vista do serviço, aquela sessão já passou pela verificação — a técnica é conhecida como "session hijacking" ou "pass-the-cookie".
No contexto de fraude financeira, essa técnica é exatamente o que sustenta boa parte do account takeover contra bancos digitais, corretoras e carteiras de cripto: o criminoso não precisa "adivinhar" nada, só usar uma sessão válida roubada de uma máquina comprometida — muitas vezes a do próprio usuário, infectado por um instalador pirata, crack de jogo ou anexo malicioso. Os logs de infostealer são vendidos em volume em mercados clandestinos (ex.: canais no Telegram, marketplaces como antigos Genesis Market), e compradores filtram por domínio de interesse — bancos, exchanges, e-commerce — para depois testar as sessões e credenciais em campanhas de fraude direcionada.
A recomendação prática do artigo, e que vale tanto para empresas quanto para o usuário final, é agir pela janela de tempo, não pela quantidade: a prioridade não é o volume de credenciais expostas, mas se havia sessão autenticada viva de um provedor de identidade corporativo ou de uma conta financeira — nesse caso a resposta precisa ser em minutos, revogando sessões ativas nos provedores de identidade e nos apps bancários (a maioria dos bancos permite "sair de todos os dispositivos"), forçando reset de senha e reautenticação com MFA renovado. Para o usuário comum, a lição prática é desconfiar da origem do computador usado para acessar contas financeiras (evitar login bancário em máquinas com software pirateado), manter antivírus atualizado, e, ao suspeitar de infecção, encerrar sessões ativas em todos os apps sensíveis, não só trocar a senha.