Malware bancário brasileiro usa DLL hijacking e sobreposições para fraudar sessões autenticadas

A cadeia analisada combina binário legítimo assinado pela VMware, módulo malicioso carregado por dependência, injeção em processos do Windows, monitoramento de URLs bancárias e telas falsas para capturar credenciais e códigos de autenticação.

Componente	Cadeia de malware bancário entregue como arquivo Java e executada por meio de vprintproxy.exe, vmwarebase.dll, prs.png e configuração criptografada em i.dk.
Vetor	Campanha de spam em português com anexo que redireciona a vítima para um arquivo JAR; a execução inicia código Java malicioso e instala os módulos no sistema.
Impacto	Monitoramento de sessões bancárias autenticadas, captura de credenciais e códigos de autenticação de dois fatores, controle visual do navegador e possibilidade de transações fraudulentas sem percepção clara do usuário.
Prioridade	Bloquear a cadeia de execução baseada em DLL hijacking, procurar carregamento anômalo de vmwarebase.dll por vprintproxy.exe, revisar endpoints com artefatos em C:\Users\public\Administrator e reforçar detecção de sobreposições bancárias falsas.
Artefatos	vprintproxy.exe, entregue sob o nome vm.png; vmwarebase.dll; prs.png; i.dk; car.dat; arquivos renomeados com número aleatório e extensão .db.
Técnicas	Empacotamento com Themida, DLL hijacking, injeção de DLL em explorer.exe e notepad.exe, monitoramento de URL em Chrome, Firefox e Internet Explorer, keylogging e uso de formulários Delphi como armazenamento interno de dados.

Resumo técnico

A campanha descreve um malware bancário originado no ecossistema brasileiro que evolui além de trojans simples de roubo de credenciais. A infecção começa com spam em português e anexo que leva a um arquivo JAR. Após a abertura, o código Java malicioso inicia a instalação de componentes no Windows. O conjunto observado foi projetado para atuar no momento de maior valor para o operador: quando a vítima já está autenticada no internet banking. Em vez de depender apenas de coleta passiva, a cadeia usa telas sobrepostas, controle da experiência visual e monitoramento de navegador para induzir o usuário a aguardar, fornecer dados adicionais ou inserir código de autenticação de dois fatores.

O ponto central da execução é o abuso de um binário legítimo assinado pela VMware, vprintproxy.exe, entregue com o nome vm.png. O código malicioso não fica diretamente nesse executável, mas em vmwarebase.dll, carregado como dependência pelo processo legítimo. Essa escolha reduz a visibilidade inicial, porque produtos de segurança podem ver um executável assinado iniciando uma biblioteca esperada pelo mecanismo de carregamento do Windows. A biblioteca, por sua vez, injeta o módulo principal prs.png em explorer.exe e em uma instância criada de notepad.exe, deslocando a atividade para processos comuns do sistema e dificultando a leitura superficial da árvore de processos.

A operação combina camadas de ocultação e interação com a vítima. O módulo principal usa objetos Delphi e formulários embutidos para guardar informações, bitmaps e lógica de execução. Esses formulários contêm componentes visuais e temporizadores usados para coordenar tarefas internas. A comunicação com infraestrutura de comando e controle depende de uma seção de configuração criptografada com AES-256 armazenada em i.dk. O malware também monitora URLs ativas em navegadores e compara o endereço acessado com uma lista de sites bancários suportados. Quando identifica uma sessão bancária relevante após autenticação, seleciona mensagens e imagens falsas associadas ao banco acessado.

Fluxo técnico

Depois que vprintproxy.exe é iniciado e vmwarebase.dll é carregada, o fluxo passa pelo ponto de entrada DllMain da DLL maliciosa. A finalidade dessa etapa é preparar a injeção do módulo prs.png. O caminho do módulo não é usado de forma estática: o malware consulta C:\Users\public\Administrator\car.dat, procura um identificador numérico aleatório e resolve o arquivo correspondente no diretório C:\Users\public\Administrator. O nome do arquivo é alterado para um inteiro aleatório entre 0 e 999999999, com extensão .db, o que atrapalha regras simples baseadas apenas em nome fixo. Quando o arquivo é localizado, o caminho é escrito em memória alocada dentro dos processos-alvo e usado como argumento para LoadLibrary. A chamada é disparada por CreateRemoteThread, levando o processo remoto a carregar a DLL maliciosa.

Antes da injeção, a DLL enumera processos e encerra instâncias de conhost.exe, aparentemente para remover janelas remanescentes de fases anteriores da infecção. O primeiro estágio injetado apresenta recursos de keylogger e monitoramento de URLs. Para identificar a navegação bancária, o código enumera janelas do sistema por meio de funções de interface gráfica do Windows e usa métodos distintos para extrair a barra de endereço em Chrome, Firefox e Internet Explorer. Esse detalhe é relevante para defesa porque a atividade não depende apenas de tráfego de rede: há interação direta com janelas, controles de navegador e estado visual da sessão do usuário.

A lógica de fraude depende de sobreposições. O malware contém bitmaps que imitam mensagens de bancos e falsas instalações de componentes de segurança. Quando o endereço ativo corresponde a um banco suportado, como HSBC, Santander, Citibank ou bancos brasileiros citados no contexto, o malware escolhe a imagem adequada e a exibe para a vítima. As mensagens simulam falhas de sincronização ou instalação de módulo de segurança e orientam o usuário a aguardar ou tentar novamente. Enquanto isso, o operador pode manipular a sessão aberta no navegador e conduzir ação fraudulenta. A cadeia também pode solicitar credenciais bancárias ou token de autenticação de dois fatores, explorando um hábito comum em transações bancárias brasileiras.

O módulo empacotado com Themida adiciona resistência à análise e mecanismos de proteção em tempo de execução. Uma rotina chama UnhookWindowsHookEx repetidamente com valores de argumento de 1 a 5000, sugerindo tentativa de remover hooks previamente instalados por ferramentas de análise, segurança ou monitoramento. Em certas condições, o malware também tenta restaurar os primeiros bytes de funções quando identifica URL ativa vazia, comportamento compatível com remoção de alterações em memória ou breakpoints. Há ainda uma verificação no Registro em HKCU\Software\Trilian\[A-Z]{2}, na qual as duas letras finais são derivadas da URL ativa. O valor de data obtido é comparado com a data do sistema, influenciando a decisão de exibir ou não determinada sobreposição.

Superfície afetada

A superfície principal é o endpoint Windows usado para internet banking, especialmente quando a vítima opera bancos suportados pela lista embutida no malware. A cadeia não exige comprometimento direto do banco: ela atua sobre a estáção do cliente, observa o navegador, espera a autenticação e manipula a interface local. Essa arquitetura reduz a necessidade de quebrar controles do lado servidor, porque o operador explora uma sessão legítima já estabelecida pelo usuário. O risco aumenta quando o ambiente permite execução de anexos recebidos por e-mail, Java local, carregamento de bibliotecas em diretórios controlados pelo usuário e ausência de controles comportamentais sobre injeção entre processos.

Os artefatos citados também mostram uma superfície de detecção em disco e memória. O uso de C:\Users\public\Administrator como local de apoio, car.dat como índice de resolução e arquivos .db com nomes numéricos são elementos que podem ser correlacionados. O binário assinado vprintproxy.exe não deve ser tratado como benigno apenas por assinatura quando aparece fora do contexto esperado da VMware ou quando carrega vmwarebase.dll de caminho não padrão. Em memória, a presença do módulo principal injetado em explorer.exe e notepad.exe deve ser avaliada junto com chamadas de carregamento remoto e interação incomum com janelas de navegador.

• Usuários de Windows que acessam internet banking por Chrome, Firefox ou Internet Explorer em estáções onde a cadeia foi instalada.
• Sessões autenticadas em bancos presentes na lista interna do malware, incluindo bancos brasileiros e instituições como HSBC, Santander e Citibank mencionadas no contexto.
• Processos explorer.exe e notepad.exe usados como destino de injeção do módulo prs.png.
• Diretório C:\Users\public\Administrator contendo car.dat e arquivos com nomes numéricos e extensão .db.
• Carregamento de vmwarebase.dll associado a vprintproxy.exe entregue com nome diferente do esperado.

Hunting e telemetria

A busca defensiva deve combinar telemetria de e-mail, endpoint, processo, arquivo, Registro, interface gráfica e rede. Na camada de entrada, procure mensagens em português com anexos ou redirecionamentos para arquivo JAR, especialmente quando a abertura do anexo resulta em execução de código Java e criação posterior de arquivos no perfil público. Em EDR, a cadeia deve aparecer como execução de um arquivo nomeado vm.png ou de vprintproxy.exe fora de diretórios legítimos, seguida pelo carregamento de vmwarebase.dll e injeção em processos comuns. A sequência LoadLibrary em processo remoto acionada por CreateRemoteThread é um sinal importante quando ligada aos artefatos descritos.

Na camada de comportamento, monitore processos que enumeram janelas do sistema, inspecionam barras de endereço de navegadores e executam captura de teclado no mesmo período em que o usuário acessa bancos. A presença de janelas muito pequenas ou quase invisíveis criadas por um processo suspeito pode indicar o uso de formulários Delphi como contêiner de dados e temporizadores. Também vale procurar chamadas incomuns e repetitivas a UnhookWindowsHookEx, pois a rotina descrita tenta remover hooks em ampla faixa de identificadores. No Registro, a árvore HKCU\Software\Trilian\ com subchaves de duas letras derivadas de URL é um indicador comportamental que deve ser validado no contexto do endpoint, já que o valor de data influencia a lógica de exibição das falsas mensagens.

A telemetria de rede deve priorizar saídas originadas dos processos injetados e tentativas de contato com infraestrutura de comando e controle após leitura ou descriptografia de i.dk. O contexto não fornece domínios, IPs ou portas, portanto não é adequado inventar indicadores. A abordagem mais robusta é correlacionar beaconing, destino recém-observado, processo incomum e presença dos arquivos locais. Para bancos e equipes antifraude, a anomalia mais relevante é o descompasso entre uma sessão autenticada legítima e interações feitas enquanto o cliente vê uma tela de suposto erro, instalação de componente de segurança ou solicitação adicional de token.

• Execução de anexo que resulta em download ou abertura de JAR e posterior criação de artefatos em diretórios públicos do Windows.
• vprintproxy.exe carregando vmwarebase.dll de caminho suspeito ou sendo iniciado a partir de arquivo originalmente nomeado vm.png.
• Injeção em explorer.exe ou notepad.exe com uso de LoadLibrary e CreateRemoteThread.
• Presença de i.dk, car.dat e arquivos .db com nomes numéricos em C:\Users\public\Administrator.
• Acesso ou criação de chaves em HKCU\Software\Trilian\ com sufixos de duas letras.
• Processos enumerando janelas de navegadores e lendo URLs ativas durante sessões bancárias.
• Chamadas repetitivas a UnhookWindowsHookEx em processo associado à cadeia.

Mitigação

A contenção deve começar pelo endpoint, porque a fraude se apoia na estáção da vítima e na sessão legítima do navegador. Ao identificar um host com os artefatos descritos, isole a máquina da rede, preserve memória e disco para análise, encerre sessões bancárias abertas e invalide credenciais usadas durante a janela de exposição. Como a cadeia tenta capturar códigos de autenticação, a resposta não deve se limitar à troca de senha: é necessário revisar métodos de segundo fator, histórico de transações, dispositivos confiáveis e eventos de login associados ao período em que o malware esteve ativo.

No hardening, bloqueie execução de anexos de e-mail que iniciem JAR em estáções sem necessidade operacional, aplique controle de aplicação para impedir binários assinados fora de caminho esperado e restrinja carregamento de DLL a partir de diretórios graváveis pelo usuário. Regras comportamentais devem alertar quando um executável legítimo carrega biblioteca de local incomum, quando há criação de thread remota em processos de usuário comuns e quando um processo interage de forma automatizada com janelas de navegador. A assinatura digital do executável não pode ser o único critério de confiança: o ponto de abuso é justamente combinar binário legítimo com biblioteca maliciosa em um caminho controlado pela cadeia.

Para instituições financeiras e equipes antifraude, a mitigação deve incluir correlação entre telemetria do cliente, postura do dispositivo e comportamento transacional. Sessões nas quais o usuário permanece inativo visualmente enquanto ocorrem ações críticas merecem validação adicional. Mensagens de erro ou componentes de segurança exibidos no lado cliente devem ser desenhados de modo a reduzir oportunidade de imitação, mas a principal defesa continua sendo detecção de anomalia transacional e confirmação fora do canal comprometido. Em ambientes corporativos, a revisão de logs históricos deve procurar os artefatos locais e eventos de rede correspondentes antes de liberar a estáção para uso novamente.

• Isolar endpoints com vprintproxy.exe, vmwarebase.dll, prs.png, i.dk, car.dat ou arquivos .db suspeitos nos caminhos citados.
• Revogar credenciais bancárias usadas durante a infecção e revisar fatores de autenticação associados à conta afetada.
• Bloquear execução de JAR iniciado por anexos de e-mail quando não houver justificativa de negócio.
• Criar detecção para DLL hijacking envolvendo binário legítimo assinado executado fora de diretório esperado.
• Alertar para injeção em explorer.exe e notepad.exe combinada com monitoramento de navegador ou captura de teclado.
• Remover persistência e artefatos somente após coleta forense suficiente para entender a linha do tempo da infecção.
• Validar transações realizadas durante a janela de comprometimento antes de recolocar a estáção em produção.