Modus operandi

Infostealer: por que a fraude aparece meses depois, e por que o 2FA não salvou

O malware rouba o cookie de sessão, que já carrega a verificação do segundo fator. E quem rouba não é quem usa, o que explica o intervalo até o prejuízo.

Por Julio Cesar Madeira Soares, Perito em Investigação Digital e Segurança da Informação.
Publicação prevista para 23 de março de 2027

O caso incomoda porque a vítima fez tudo certo. Senha longa e diferente em cada serviço, segundo fator ligado, aplicativo autenticador em vez de SMS. E perdeu dinheiro assim mesmo.

Pior: quando foi procurar a causa, descobriu que o computador tinha sido infectado meses antes, e que na época nada tinha acontecido. Nenhuma tela travada, nenhum pedido de resgate, nenhum arquivo perdido.

Esses dois fatos, o segundo fator que não impediu nada e o intervalo de meses, têm a mesma explicação, e ela não é óbvia.

O que um infostealer faz, e o que ele deliberadamente não faz

Infostealer é malware de coleta. Instalado no computador, ele vasculha o que o navegador guardou: senhas salvas, dados de preenchimento automático, cookies e tokens de sessão, às vezes arquivos e carteiras de criptomoeda. Empacota tudo e envia para fora.

Depois disso, ele costuma sumir.

Sobre como ele entra, o CERT.br é específico: entre os principais vetores de infecção desse tipo de malware estão gerador de chave de ativação e programa não original, o que o meio chama de keygen e de cracked. Não é o único caminho, anexo de e-mail e link patrocinado aparecem no mesmo documento como rota de entrada de malware em geral. Mas é o caminho que costuma estar na máquina que ninguém auditou.

Repare no contraste com ransomware, que é o malware que todo mundo conhece. Ransomware quer ser notado, porque só recebe se a vítima souber que foi atacada. Infostealer quer exatamente o oposto: quanto mais tempo ninguém perceber, mais fresco fica o material que ele colheu.

É por isso que a infecção não tem sintoma. Não é falha de percepção da vítima, é projeto.

O contraste é real, mas não é rivalidade. Os dois estão na mesma cadeia. No documento em que o CERT.br descreve como um ataque de ransomware acontece, o infostealer aparece já na primeira fase, a de acesso inicial, como mecanismo amplamente empregado para capturar credencial de acesso, incluindo token de sessão. O que um colhe em silêncio é o que abre a porta para o outro fazer barulho.

Por que o segundo fator não salvou

Aqui está o ponto que quase ninguém explica direito, e ele muda o que se deve fazer depois de uma infecção.

A autenticação multifator protege o momento do login. Você entra com senha, confirma no aplicativo, e o serviço então emite um token de sessão, guardado como cookie no navegador. Esse token representa uma sessão já autenticada, e a verificação do segundo fator já está dentro dele.

Quem rouba o cookie não precisa da sua senha nem do seu segundo fator. Ele importa o cookie no navegador dele e entra como se fosse você, no mesmo estado de autenticação em que você estava. A porta não é arrombada: ela já estava aberta, e a chave foi copiada depois de girada.

Duas consequências práticas que decorrem disso:

Trocar a senha não resolve sozinho. Se a sessão antiga continua válida, o token roubado continua funcionando. É preciso encerrar as sessões ativas, que em muitos serviços é opção separada, escondida em configurações de segurança.

Cookie roubado é mais valioso que senha roubada. Senha ainda esbarra no segundo fator. Cookie, não.

Vale registrar que esse não é o único jeito de contornar o segundo fator, e o outro é bem diferente. No SIM swap o criminoso não rouba a sessão, ele toma a linha de telefone e passa a receber o código. Um ataca o que veio depois do login, o outro ataca o canal por onde o código chega.

Por que a fraude aparece meses depois

Este é o outro fato estranho, e a explicação é econômica, não técnica.

Quem rouba a credencial não é quem usa.

O material colhido pelo infostealer vira o que o meio chama de log, e esse log é mercadoria. Ele é vendido em fórum e em mercado clandestino, às vezes em pacote diário ou semanal, e circula por intermediários antes de chegar em quem vai operar a fraude. Existe inclusive papel especializado nisso, o corretor de acesso inicial, que compra credencial em volume e revende o acesso já qualificado.

O CERT.br descreve esse arranjo pelo lado de quem compra. Quando o acesso vem de um corretor, diz o documento, ele pode ter ocorrido em momento anterior ao ataque em si, e as informações são vendidas a diferentes afiliados. São duas afirmações numa frase só, e a segunda quase nunca é repetida: o mesmo acesso pode ser vendido mais de uma vez.

Vale dizer de onde isso vem, porque muda o peso. O CERT.br está explicando ataque de ransomware, não fraude bancária. Só que o corretor não vende ataque, vende acesso, e quem compra é que decide o que fazer com ele. A camada do meio é a mesma.

E aí cai uma suposição confortável. Uma infecção não produz uma fraude, produz um acesso que pode ser usado por mais de uma pessoa, em momentos diferentes, sem que uma saiba da outra. Perícia que encontra um uso não pode concluir, sozinha, que era o único. Cada troca de mãos leva tempo, e é isso que empurra o prejuízo para meses depois.

O efeito colateral disso é o que interessa aqui: a vítima não tem como ligar o efeito à causa. Infecção em março, fraude em agosto, e nesse meio tempo ela trocou de máquina, formatou, ou simplesmente esqueceu.

O que o intervalo faz com a prova, e é aqui que dói

Duas consequências sérias, e as duas são de prazo.

O registro do momento da infecção pode ter expirado. Como tratamos em golpe do boleto e troca de dados, o Marco Civil da Internet manda guardar registro de conexão por um ano e registro de acesso a aplicações por seis meses. Se a infecção foi há oito meses, o registro que mostraria a exfiltração provavelmente já não existe. Ninguém agiu de má-fé, o prazo simplesmente venceu.

O equipamento pode não contar mais a história. O infostealer costuma se remover depois de executar, e o usuário formatou, trocou de máquina ou rodou antivírus que limpou o rastro. Sobra, às vezes, artefato em registro do sistema, agendamento residual, entrada em log de execução. É trabalho de perícia, é incerto, e fica mais incerto a cada mês.

A regra prática decorre direto disso: suspeita de infecção é motivo para preservar imagem do disco antes de formatar, e não depois. Vale a mesma disciplina de cadeia de custódia, inclusive o hash na origem.

A discussão de responsabilidade fica desconfortável

Vale tratar de frente, porque é a pergunta que o cliente faz e é a que a instituição usa para se defender.

O argumento da instituição é forte à primeira vista: o dispositivo comprometido era do cliente, a credencial usada era legítima, a autenticação ocorreu corretamente. Logo, culpa exclusiva da vítima.

E ele fica mais forte ainda se a porta de entrada foi keygen ou programa pirata, que é o vetor apontado pelo CERT.br entre os principais. Não adianta fingir que isso não pesa, porque pesa, e pesa do lado da instituição. Melhor saber antes da audiência do que durante.

O contra-argumento não é negar isso, e sim deslocar a pergunta. Credencial legítima não é o mesmo que comportamento compatível.

Como tratamos em responsabilidade do banco, o critério que os tribunais vêm aplicando olha se a operação destoa do padrão do cliente, e não apenas se a autenticação passou. Sessão retomada de outro dispositivo, de outro endereço, em horário fora do hábito, seguida de transferência alta para beneficiário novo, é conjunto de sinais disponível para o sistema no momento da operação.

Ou seja, a infecção no computador do cliente explica como a credencial vazou. Ela não responde sozinha por que a operação seguinte não foi tratada como suspeita.

Os quesitos que separam isso estão em quesitos para perícia, especialmente os do eixo de identificação de dispositivo e os do eixo de conduta da instituição.

O enquadramento penal, e são dois crimes

Detalhe que costuma ser tratado como um só e não é.

A infecção é crime autônomo. O art. 154-A do Código Penal pune invadir dispositivo informático de uso alheio, conectado ou não à rede, com o fim de obter, adulterar ou destruir dados sem autorização do usuário, ou de instalar vulnerabilidades para obter vantagem ilícita, com reclusão de um a quatro anos e multa, na redação dada pela Lei 14.155/2021. O §3º eleva para reclusão de dois a cinco anos quando da invasão resulta a obtenção de conteúdo de comunicações eletrônicas privadas, segredos comerciais ou industriais, informações sigilosas assim definidas em lei, ou o controle remoto não autorizado do dispositivo. Há ainda aumento quando resulta prejuízo econômico.

A fraude posterior é outro crime, e normalmente de outro autor. Aplica-se o estelionato por fraude eletrônica, como tratado em clonagem de voz.

Isso importa na prática: são fatos distintos, momentos distintos e, quase sempre, pessoas distintas. Uma ocorrência que descreve só a fraude final deixa de fora a porta de entrada, e é a porta de entrada que explica como a credencial legítima foi parar em outra mão.

E o destino do dinheiro segue o caminho de sempre, que é a conta laranja e a dispersão.

O que fazer

Se você suspeita que foi infectado:

1. Não formate ainda. Se houver prejuízo financeiro envolvido, preservar imagem do disco vem antes de limpar a máquina.
2. Encerre as sessões ativas em todos os serviços relevantes, e só depois troque as senhas. Na ordem inversa, o token roubado continua valendo.
3. Troque a senha de outro dispositivo, que você tenha motivo para considerar limpo.
4. Revise o que estava salvo no navegador. Tudo que estava lá deve ser tratado como comprometido, e não só o banco.
5. Registre ocorrência descrevendo os dois fatos, a invasão do dispositivo e a fraude, e não apenas o segundo.

Se você opera a instituição:

1. Sessão retomada de dispositivo e endereço diferentes é sinal, ainda que a credencial esteja correta. Autenticação válida não encerra a análise, inicia.
2. Registre a vinculação entre sessão, dispositivo e endereço, e guarde. É o que vai ser pedido depois.
3. Trate credencial vazada em base pública como gatilho de reautenticação, não como informação de relatório.

A frase que resume: o infostealer não quebra a fechadura, ele fotografa a chave enquanto você abre a porta. E vende a foto para alguém que vai usar meses depois, quando você já esqueceu que abriu.