Comprovante bancário em JavaScript instala extensão que rouba sessões de banco no Chrome e no Edge — 98,75% das vítimas no Brasil

Introdução

Uma operação de malware bancário rastreada desde maio de 2025 pela Elastic Security Labs (laboratório de pesquisa e inteligência de ameaças da Elastic, empresa por trás do Elasticsearch) como REF9334 infectou ao menos 1.515 sistemas — 98,75% deles no Brasil — com uma extensão maliciosa que rouba sessões de banco no Google Chrome (navegador da Google) e no Microsoft Edge (navegador da Microsoft baseado no Chromium). O ponto de entrada é simples e enganoso: um arquivo JavaScript disfarçado de comprovante bancário, boleto ou extrato, que a própria vítima executa manualmente acreditando estar abrindo um documento.

O toolkit usado na operação se chama KREMLIN — nome escolhido pelo autor, identificado nos cabeçalhos dos scripts como Kr3mlin4rt1st —, embora nada nela seja russo: as mensagens de erro e os comentários de código estão em português, as iscas imitam bancos brasileiros e as transações Ethereum dos operadores se concentram no horário de trabalho de São Paulo. Em 15 meses e sete campanhas, a Elastic observou o toolkit evoluir de simples loaders até um instalador C++ capaz de forjar as próprias verificações de integridade do Chromium (projeto de navegador open source que serve de base para Chrome e Edge): o navegador passa a tratar a extensão como aprovada pelo usuário, que nunca a instalou.

A análise completa foi publicada em 13 de setembro e repercutida pelo Cyber Security News na segunda-feira (16). Dois avisos antes de seguir: não há CVE envolvido — isto é uma campanha de fraude, não uma vulnerabilidade de navegador — e a contagem de infectados reflete apenas o que a Elastic conseguiu observar.

O golpe: o comprovante que não é documento

A infecção começa com um arquivo JavaScript que imita documentos legítimos, enviado por e-mail ou mensageiro: nomes no padrão TemaEmPortugues_Banco_DATA.js, como ComprovanteSafra_03-08-2026.js, Extrato, PIX, Pagamento, TED, Transferencia, Recibo, Alvara e Regulamentacao. A Elastic mapeou iscas para 12 instituições brasileiras: Banco do Brasil, Caixa, Bradesco, Sicoob, C6 Bank, Inter, BTG Pactual, Safra, PagBank, PicPay, Santander e Mercado Pago. Ao executar o arquivo, o usuário vê um erro falso — o malware cria um script auxiliar no padrão popup_data_aleatorio.js que exibe uma janela de erro e se apaga em seguida — enquanto a cadeia de infecção roda em segundo plano. Os nomes dos arquivos e os erros em português confirmam o alvo: falantes de português, majoritariamente no Brasil.

A operação não é um caso isolado: o ecossistema de fraude bancária brasileira está ativo em várias frentes — o grupo BREEZE COMET usa malware assistido por IA contra bancos do país, e o Mantax Otax é um ransomware Android que grava a tela para capturar OTPs. A KREMLIN se destaca por atacar o navegador, a camada de confiança que o usuário não costuma suspeitar. Em campanhas anteriores, os mesmos operadores distribuíram RATs (trojan de acesso remoto, ferramenta que dá controle total da máquina ao atacante) como PULSAR e REMCOS — a mesma família de ferramentas do StreamRAT, analisado aqui no site.

Os estágios: do JavaScript ao navegador

A cadeia de ataque tem cinco etapas: a isca em JavaScript, o loader com verificações anti-sandbox, a persistência disfarçada de runtime da Microsoft, o instalador C++ com sideload de um binário legítimo da SentinelOne e, por fim, a extensão AVSync cravada no Chrome e no Edge. O diagrama abaixo resume o fluxo; cada etapa é detalhada em seguida.

O loader JavaScript e a fuga de sandbox

O primeiro estágio é um loader ofuscado de forma simples — nomes de função genéricos e strings buscadas por índice numa tabela de referência. Antes de qualquer coisa, ele tenta descobrir se está rodando num ambiente de análise: conta os arquivos no desktop do usuário e usa uma consulta WMI (Windows Management Instrumentation, interface de administração do Windows usada para consultar processos e configurações do sistema) para contar os processos em execução. Se houver menos de 5 arquivos ou menos de 50 processos, o malware assume que está numa sandbox e aborta.

Passando no teste, o loader decodifica o próximo estágio com o certutil (utilitário nativo do Windows para manipular certificados, reaproveitado aqui para decodificar payloads Base64), baixa o Node.js (runtime que executa JavaScript fora do navegador) para rodar o código seguinte e envia um beacon de registro ao servidor C2 (servidor de comando e controle, usado para receber instruções e roubar dados), chamando o endpoint /api/log_loader com o ID da campanha. No exemplo analisado, o host é connection.upgradeonline.site.

Persistência disfarçada de runtime da Microsoft

O segundo estágio extrai um arquivo CAB (formato de arquivo compactado do Windows) embutido no script e instala uma tarefa agendada chamada MicrosoftNodeRuntimeUpdater, com descrição oficial em inglês sobre o "Node.js V8 Runtime" — na aparência, mais um componente legítimo da Microsoft. Um minuto após o logon do usuário, a tarefa executa conhost.exe --headless node.exe a partir do diretório que contém o script malicioso. O nome e a descrição são a assinatura da operação: se aparecerem numa máquina, é sinal de infecção.

O instalador C++ e o sideload da SentinelOne

O estágio final antes da extensão é um instalador de 2,10 MB escrito em C++ para x64. Para executar a carga maliciosa, ele abusa do sideload de DLL: usa um binário legítimo e assinado da SentinelOne (empresa de segurança especializada em proteção de endpoints), o SentinelMemoryScanner.exe, para carregar uma DLL não assinada disfarçada de SentinelAgentCore.dll — técnica documentada pela Symantec. O malware ainda contorna o lock de inicialização do Windows (a seção crítica LdrpLoaderLock) para criar sua thread principal antes de o DllMain terminar. O instalador repete as verificações anti-análise: lista de processos de ferramentas de análise, blacklist de nomes de usuário (Sandbox, testuser, virus), exigência de mais de 2 CPUs e mais de 3 GB de RAM, além da checagem do canário de rede. Quando detecta análise, encerra-se deliberadamente com uma violação de acesso.

A checagem do canário merece destaque, porque virou o ponto fraco da operação. O malware testa a conectividade consultando o domínio www.creamp1eonlyfans.net, que não deveria existir — se algo responder, é sinal de sandbox simulando rede, e o malware se encerra. A Elastic registrou o domínio e o apontou para seus próprios servidores: 1.515 sistemas infectados — 98,75% deles no Brasil — tentaram se reportar ao canário e passaram a abortar a execução. Os equipamentos seguem com o estágio final instalado, mas a infecção parou de avançar. Temporariamente.

C2 em contrato Ethereum: trocar de infraestrutura sem recompilar

Uma das inovações da operação é usar o Ethereum (blockchain que executa contratos inteligentes) como dead drop (mecanismo em que um local público e imutável guarda dados que as amostras consultam para descobrir a infraestrutura ativa). O malware consulta o contrato inteligente 0xCD7360A83E5cdbBbbbcEB0e78748babA6740d07b e lê três parâmetros: main-v2 (URL do módulo principal), sub-module (URL de um JPEG que esconde um kit de injeção RunPE, técnica que executa um executável dentro da memória de outro processo) e sentinel (URL de um JPEG com um CAB contendo o binário legítimo da SentinelOne usado no sideload). Como a configuração vive na blockchain, os operadores trocam servidores e domínios com uma simples transação — sem recompilar uma única amostra. Em 13 de agosto, por exemplo, o main-v2 foi atualizado para zaviro.online; dias antes, em 10 de agosto, o parâmetro da extensão passou a apontar para volmira.site.

Os rastros on-chain também entregam pistas sobre os operadores: os primeiros contratos maliciosos surgiram em maio de 2026 (apontando para cremeb.com e, depois, granderevolucao.store) antes da migração para o contrato atual, implantado em 16 de junho. Uma única carteira, 0x5C32A09873be70a92fd8bB5A9fED7967dE06BdE6, implantou os contratos e atualizou as configurações, movimentando cerca de 20,7 mil USDT recebidos e 19 mil USDT enviados entre junho de 2025 e agosto de 2026. A análise dos horários das transações, convertidos para UTC-3, mostra atividade concentrada no horário comercial — coerente com operadores baseados em São Paulo.

A extensão que você nunca instalou

O instalador baixa a extensão e a instala fora da Web Store, direto nas pastas de perfil do Chrome e do Edge. O truque está em como ela é ativada: o malware manipula o arquivo Secure Preferences, que registra as configurações protegidas do navegador, habilita o modo desenvolvedor e registra a extensão — depois regenera as assinaturas criptográficas que o Chromium exige para aceitar essas mudanças. São dois mecanismos: os HMACs (códigos de autenticação de mensagem usados pelo navegador para verificar integridade das preferências) legados, calculados com uma seed extraída do resources.pak do navegador, e os hashes mais novos (campo encrypted_hash), que o Chromium versão 144 ou superior protege com a criptografia App-Bound (proteção que vincula a criptografia do navegador a um serviço do Windows). Para obter as chaves, o instalador espera o navegador fechar ou ficar dois minutos ocioso, encerra o processo à força se preciso e o reabre sob um debugger (ferramenta de depuração que permite inspecionar e controlar um processo) para extrair a chave App-Bound da memória — além da chave OSCrypt (sistema de criptografia de dados do Chromium) mais antiga, protegida por DPAPI (API nativa do Windows para criptografar dados vinculados ao usuário). O resultado: o navegador carrega a extensão como se o usuário a tivesse instalado e aprovado.

A extensão se apresenta como AVSync (ID ndpbidppejfanjbhfgjlohfanbfbklff, versão 1.0.0) e pede acesso a abas, cookies, armazenamento e à API webRequest. Com isso, executa comandos como GSH01 (captura de tela), GAT01 (listar abas), GCO01 (roubar cookies, sessionStorage e localStorage), GHI01 (histórico dos últimos 15 dias), GSO01 (código-fonte da página), INC01 (injetar HTML controlado pelo atacante) e UPD01 (atualizar as regras de alvo). Além disso, registra um keylogger (captura de teclado) em todos os campos de entrada das páginas visitadas, intercepta requisições — inclusive corpos de formulários POST — e pode redirecionar cliques para páginas falsas. Os dados saem compactados e codificados (lz-string + Base64) por um canal WebSocket (comunicação bidirecional usada para receber comandos em tempo real) e por requisições disfarçadas de arquivos CSS. Os bancos de dados do navegador — Login Data, Web Data, Network/Cookies e as pastas da extensão — são empacotados num ZIP junto com as chaves de criptografia (keys.json) e enviados, criptografados com RC4, para os endpoints volmira.site/api/savecreds e zaviro.online/api/v1/fingerprint.

O que um cookie de sessão roubado permite

O ouro da operação é o cookie de sessão. Quando você autentica no internet banking, o servidor entrega ao navegador um token que prova que a conta está autenticada — e ele vale pelo tempo da sessão, sem exigir senha nem código de verificação a cada operação. Com o cookie em mãos, o atacante reutiliza a sessão: entra na conta como se fosse você, consulta saldos, transfere valores e altera dados cadastrais, tudo sem precisar do seu OTP. Por isso, a recomendação de revogar sessões ativas após um incidente é tão importante quanto trocar a senha: ela invalida os tokens já emitidos, inclusive os que o invasor copiou. Somados aos cookies, os bancos de dados roubados — senhas salvas, histórico, capturas de tela e o que foi digitado — dão ao golpista material para repetir o ataque em outras contas e serviços.

Detecção e IoCs

Os indicadores abaixo foram publicados pela Elastic e consolidados pelo Cyber Security News. Os domínios aparecem com o ponto defangado (.) para evitar cliques acidentais.

Além dos IoCs, vale caçar a tarefa agendada MicrosoftNodeRuntimeUpdater, a extensão AVSync instalada fora da loja, alterações recentes no Secure Preferences e beacons para os domínios listados. O endpoint graph.checkeligibitily.workers.dev é um pivô valioso: o erro de digitação "checkeligibitily" também aparece no campo ENDPOINT_DINAMIC da configuração da extensão, permitindo correlacionar outras amostras da mesma família.

Como se proteger

Bancos não enviam JavaScript. Comprovantes, boletos, extratos e notificações de PIX chegam em PDF, imagem ou dentro do app do banco — nunca como arquivo .js. Treine usuários e equipes para desconfiar de qualquer anexo executável, mesmo que o nome pareça um documento oficial.

Bloqueie arquivos de script na entrada. Filtros de e-mail e de mensageria corporativa devem bloquear ou colocar em quarentena anexos .js, .jse, .vbs e .wsf, além de arquivos compactados com conteúdo executável. É a medida de maior custo-benefício contra esta cadeia.

Revise as extensões instaladas. Chrome e Edge exibem a lista completa em chrome://extensions (ou edge://extensions): remova qualquer extensão desconhecida, em especial as que pedem acesso a abas, cookies, storage e webRequest e as que não vieram da loja oficial. A AVSync não é um produto legítimo.

Revogue sessões e troque senhas. Em caso de suspeita, isole o dispositivo da rede, remova a extensão e a tarefa agendada, troque as senhas a partir de um sistema limpo e revogue todas as sessões ativas das contas bancárias — os apps de banco oferecem essa opção. Sessões revogadas inutilizam os cookies roubados.

Monitore o que foge do padrão. Tarefas agendadas recém-criadas (a MicrosoftNodeRuntimeUpdater é a assinatura desta operação), alterações nos perfis de navegador e conexões para domínios recém-registrados podem ser detectadas com um SIEM — plataformas open source como o Wazuh (plataforma de monitoramento e SIEM open source) cobrem bem esse caso. Para investigar a infraestrutura associada aos domínios, o Shodan (mecanismo de busca por dispositivos e serviços expostos na internet) ajuda a mapear o que os operadores deixaram público.

Use apps oficiais e favoritos. Acesse o banco pelo aplicativo ou digitando o endereço salvo nos favoritos, nunca por links recebidos em mensagens — um dos vetores mais comuns de fraude bancária no Brasil.

A verificação manual da persistência pode ser feita com o PowerShell:

# Tarefa agendada usada pelo KREMLIN para persistência
Get-ScheduledTask | Where-Object { $_.TaskName -eq "MicrosoftNodeRuntimeUpdater" }
 
# Extensões instaladas nos perfis do Chrome
Get-ChildItem "$env:LOCALAPPDATA\Google\Chrome\User Data\*\Extensions" -ErrorAction SilentlyContinue
 
# Última alteração no Secure Preferences (instalação forçada de extensão)
Get-ChildItem "$env:LOCALAPPDATA\Google\Chrome\User Data\*\Secure Preferences" -ErrorAction SilentlyContinue |
    Select-Object FullName, LastWriteTime

Conclusão

A operação KREMLIN combina o vetor mais simples da fraude brasileira — um documento falso que o usuário abre — com o alvo mais confiável: o navegador. Ao forjar as verificações de integridade do Chromium e esconder a configuração do C2 num contrato Ethereum, os operadores constroem uma cadeia difícil de bloquear com listas estáticas, porque a infraestrutura muda sem recompilar nada. A resposta da Elastic, registrando o domínio canário, deu um respiro: as máquinas infectadas passaram a abortar a execução ao detectar uma "sandbox" onde não havia. Mas é uma medida temporária — os sistemas continuam comprometidos com o estágio final, e os operadores podem remover ou alterar a checagem na próxima atualização. A análise é da Elastic, e a contagem de 1.515 infectados reflete o que a empresa observou até a publicação. A defesa eficaz não depende de bloquear um domínio, mas de tratar anexos executáveis como ameaça, revisar extensões e revogar sessões — hábitos que funcionam contra esta e contra a próxima campanha.

Perguntas frequentes

Fontes e leituras adicionais

• Elastic Security Labs — The extension you never installed: KREMLIN forges Chrome's own integrity checks to steal banking sessions — 13/09/2026
• Cyber Security News — KREMLIN Banking Malware Infects Over 1,500 Systems With Malicious Chrome Extension — 16/09/2026