Malware VENON mira bancos brasileiros com sobreposições falsas para roubo de credenciais

Malware VENON mira bancos brasileiros com sobreposições falsas para roubo de credenciais

A ameaça escrita em Rust infecta Windows por carregamento lateral de DLL, aplica evasões antes da execução maliciosa e monitora janelas e domínios bancários para acionar telas falsas contra 33 instituições e plataformas financeiras.

ComponenteMalware bancário VENON, escrito em Rust, voltado a sistemas Windows e a usuários de instituições financeiras brasileiras.
VetorDistribuição por arquivos ZIP com cargas acionadas por script e por pacotes falsamente apresentados como correções ou drivers, com execução por carregamento lateral de DLL; o uso de ClickFix aparece como vetor esporádico.
ImpactoMonitoramento de janelas e domínios bancários para exibir sobreposições falsas e capturar credenciais quando a vítima acessa aplicativos ou sites financeiros visados.
PrioridadeBloquear a cadeia de entrega, caçar carregamento lateral de DLL em diretórios de usuário, revisar tarefas agendadas suspeitas e monitorar conexões WebSocket iniciadas por processos incomuns.
ArtefatosAmostras anteriores expuseram caminhos de desenvolvimento contendo o usuário Windows byst4; a DLL inclui blocos VBScript usados para alterar atalhos LNK relacionados ao aplicativo bancário Itaú.
MitigaçãoReforçar controles contra execução de DLL fora de caminhos confiáveis, restringir scripts em contexto de usuário, auditar atalhos alterados e validar persistência por tarefas agendadas.
Resumo técnico

O VENON é um malware bancário direcionado ao Brasil que se destaca por ter sido implementado em Rust, em contraste com famílias latino-americanas historicamente associadas a Delphi. A mudança de linguagem não é apenas estética: ela altera o perfil de análise, empacotamento, engenharia reversa e detecção estática, além de sugerir que o operador tentou reproduzir capacidades já conhecidas em trojans bancários regionais com uma base técnica diferente. A amostra foi observada em sistemas Windows e combina lógica de sobreposição bancária, monitoramento de janela ativa e alteração de atalhos, três recursos coerentes com operações de fraude financeira que dependem de interação direta da vítima com aplicativos ou páginas bancárias.

A finalidade técnica confirmada é o roubo de credenciais por telas falsas acionadas de forma condicional. Em vez de executar a etapa de fraude de maneira indiscriminada, o malware monitora títulos de janelas e domínios abertos no navegador, esperando que a vítima acesse uma instituição ou plataforma incluída na lista de alvos. Quando esse gatilho ocorre, a ameaça apresenta sobreposições que imitam fluxos legítimos e tentam capturar dados de autenticação. O conjunto de alvos informado inclui 33 instituições financeiras e plataformas de ativos digitais, o que posiciona a campanha como operação ampla contra usuários bancários brasileiros, não como comprometimento isolado de uma única organização.

A cadeia também mostra preocupação explícita com evasão e controle operacional. Antes de iniciar ações maliciosas, a DLL executa nove técnicas defensivas contra análise, incluindo verificações anti-sandbox, chamadas indiretas ao sistema, desvio de ETW e desvio de AMSI. Depois disso, busca configuração em um endereço de armazenamento em nuvem, cria uma tarefa agendada e estabelece comunicação WebSocket com a infraestrutura de comando e controle. Esse encadeamento indica que a defesa deve tratar o caso como infecção de endpoint com persistência e coordenação remota, não apenas como página falsa aberta pelo usuário.

Fluxo técnico

A infecção começa com engenharia social e entrega de um pacote compactado. Um dos vetores citados usa ClickFix, técnica em que a vítima é induzida a executar uma ação apresentada como correção de problema local. Nesse cenário, o pacote contém cargas que acabam sendo acionadas por um script, mas a defesa deve concentrar a análise no efeito observado: execução de componentes em diretórios de usuário, chamada de binário legítimo ou aparentemente legítimo e carregamento lateral de uma DLL maliciosa. O carregamento lateral permite que o malware se beneficie da confiança associada a um executável esperado, reduzindo a visibilidade de uma execução direta da DLL.

O vetor descrito como mais prevalente no Brasil usa vídeos no YouTube voltados a jogadores. Os vídeos se apresentam como tutoriais para resolver falhas gráficas ou erros de inicialização em jogos populares, incluindo Perfect World. Nas descrições, a vítima é direcionada a baixar um pacote apresentado como versão correta de driver NVIDIA. O arquivo baixado, porém, contém um executável com aparência de notificação de driver junto da DLL maliciosa. Quando a cadeia é acionada, a DLL é carregada lateralmente e passa para a fase de preparação, na qual realiza as verificações de evasão antes de buscar configuração e estabelecer controle remoto.

Após a execução inicial, a DLL recupera uma configuração a partir de um recurso hospedado em Google Cloud Storage, instala uma tarefa agendada e abre uma conexão WebSocket para o servidor de comando e controle. A configuração externa permite alterar parâmetros da operação sem trocar necessariamente o binário distribuído. A tarefa agendada fornece persistência no host, enquanto o canal WebSocket facilita interação remota para comandos, atualização de estado e ativação de funcionalidades. O texto recebido também informa que a operação possui uma etapa de desinstalação capaz de desfazer modificações em atalhos, o que sugere controle remoto suficiente para restaurar parte do ambiente e reduzir rastros visíveis.

Dois blocos VBScript extraídos da DLL implementam um mecanismo de sequestro de atalhos voltado exclusivamente ao aplicativo bancário Itaú. A técnica substitui atalhos legítimos por versões adulteradas que redirecionam a vítima para uma página controlada pelo operador. Esse ponto é importante para resposta a incidente porque desloca parte da evidência para artefatos do perfil do usuário, área de trabalho, menu Iniciar e demais locais onde atalhos LNK possam existir. Mesmo que o binário principal seja removido, atalhos manipulados podem continuar servindo como ponto de redirecionamento se não forem revisados.

Superfície afetada

A superfície primária é composta por estáções Windows usadas por clientes de bancos, corretoras, plataformas financeiras e serviços de ativos digitais no Brasil. A ameaça depende de execução local, interação do usuário com um pacote malicioso e posterior acesso a aplicativos ou sites financeiros monitorados. O impacto confirmado não é exploração de uma vulnerabilidade em banco específico, mas comprometimento do endpoint do usuário para manipular a sessão e capturar credenciais por interfaces falsas. Essa distinção importa para a priorização: o foco defensivo deve recair sobre endpoint, navegação, execução de scripts, atalhos, persistência e treinamento contra iscas de software falso.

O uso de Rust também amplia a superfície analítica para equipes que dependem de assinaturas criadas para famílias Delphi da região. O comportamento, porém, continua familiar: janelas ativas, domínios bancários, sobreposições, persistência e comunicação remota. Amostras anteriores expuseram caminhos completos do ambiente de desenvolvimento do autor com o nome de usuário Windows byst4, informação útil para agrupamento de artefatos, mas insuficiente para atribuição pública a um grupo conhecido. O material analisado não confirma ligação do VENON a campanha ou ator previamente documentado.

A notícia também descreve atividade paralela no ecossistema brasileiro envolvendo o worm SORVEPOTEL, distribuído por sessões autenticadas do WhatsApp na versão web ou desktop. Esse fluxo usa conversas já autenticadas para entregar iscas a novas vítimas e pode culminar na implantação de malware bancário como Maverick, Casbaneiro ou Astaroth. Esse trecho não prova que SORVEPOTEL seja parte direta da cadeia do VENON, mas reforça que operadores no Brasil exploram canais sociais de alta confiança e ambientes de usuário com permissões amplas para reduzir atrito na instalação.

  • Sistemas Windows em que usuários executam pacotes baixados de descrições de vídeos, supostas correções ou arquivos ZIP recebidos por engenharia social.
  • Perfis de usuário com atalhos bancários, tarefas agendadas criadas fora do padrão corporativo e diretórios graváveis contendo executáveis e DLLs correlacionados.
  • Sessões de navegação ou aplicativos financeiros monitorados por título de janela e domínio ativo, com acionamento das sobreposições somente quando um alvo é identificado.
  • Ambientes com política permissiva para scripts, execução em diretórios temporários ou de usuário e ausência de controle efetivo contra carregamento lateral de DLL.
Hunting e telemetria

A investigação deve começar pela cadeia de execução. Procure processos iniciados a partir de pacotes compactados, diretórios de download, pastas temporárias ou caminhos graváveis por usuário que carreguem DLLs não esperadas. O padrão de carregamento lateral costuma aparecer como executável aparentemente legítimo acompanhado de DLL no mesmo diretório, especialmente quando o par de arquivos foi criado no mesmo intervalo de tempo. Eventos de criação de processo, carregamento de imagem, criação de arquivo e reputação de assinatura digital ajudam a diferenciar instalação legítima de abuso.

Na camada de persistência, a criação de tarefas agendadas após a execução da DLL é um ponto de observação prioritário. A tarefa pode usar nomes pouco descritivos, caminhos em perfil de usuário ou referências a executáveis recém-baixados. A defesa deve correlacionar a criação da tarefa com conexões externas subsequentes e com modificações em atalhos LNK. Como há mecanismo voltado ao aplicativo Itaú, a revisão de atalhos que apontem para URLs inesperadas, wrappers de script ou caminhos intermediários deve fazer parte da triagem em hosts suspeitos.

A telemetria de rede deve observar conexões para recursos de configuração em armazenamento em nuvem e sessões WebSocket saindo de processos que não deveriam manter canal interativo com a internet. Não há necessidade de publicar ou depender de um indicador único: a combinação de processo incomum, diretório de origem suspeito, busca de configuração remota e canal persistente é mais robusta para detecção. Para navegadores, EDRs e ferramentas de DLP, sinais úteis incluem sobreposição de janelas no momento de acesso bancário, criação de interfaces inesperadas e leitura recorrente de título de janela ou domínio ativo por processo desconhecido.

No caso do ecossistema relacionado a SORVEPOTEL, a telemetria deve cobrir automação local, drivers de navegador sem supervisão e mensagens enviadas por sessões já autenticadas. O ponto defensivo é identificar abuso de uma sessão legítima para propagar iscas, sem assumir que toda mensagem suspeita resulte no mesmo payload final. Quando houver indício de implantação de malware bancário como Astaroth, Maverick ou Casbaneiro, a resposta deve seguir o fluxo específico da família observada.

  • Execução de DLL por binário localizado no mesmo diretório de um pacote recém-extraído ou baixado de origem não corporativa.
  • Criação de tarefas agendadas próxima da primeira execução do pacote e apontando para caminhos em perfil de usuário.
  • Modificação de atalhos LNK de aplicativos bancários, especialmente redirecionamentos para páginas externas ou intermediários de script.
  • Conexões WebSocket originadas por processos sem perfil esperado de comunicação contínua.
  • Busca de configuração em serviço de armazenamento em nuvem seguida de persistência local e comunicação com infraestrutura de controle.
Mitigação

A contenção deve remover o host da rede quando houver evidência de execução do VENON, porque a ameaça estabelece comunicação remota e pode receber comandos. Em seguida, preserve artefatos voláteis e colete a linha do tempo de processos, DLLs carregadas, tarefas agendadas, arquivos criados no diretório de usuário e alterações em atalhos. A resposta não deve se limitar à exclusão do executável visível: o mecanismo de sequestro de atalhos e a persistência por tarefa agendada podem manter o risco após uma limpeza superficial.

A mitigação preventiva passa por endurecimento de execução. Bloqueie ou restrinja scripts em contexto de usuário quando não houver necessidade operacional, aplique controle de aplicativos para impedir execução de binários e DLLs em diretórios de download e temporários, e reforce regras contra carregamento lateral por pares de executável e biblioteca desconhecidos. Em ambientes corporativos, políticas de reputação, assinatura e origem do arquivo devem impedir que pacotes obtidos por descrições de vídeo ou páginas não gerenciadas sejam executados em estáções usadas para operações financeiras.

Para usuários afetados ou suspeitos, a rotação de credenciais bancárias e de serviços financeiros deve ocorrer a partir de um dispositivo limpo, depois da contenção do endpoint. A equipe também deve revisar logs de acesso às contas visadas quando disponíveis, procurando autenticações anômalas, tentativas de transação e mudanças de cadastro. Como o impacto confirmado é captura de credenciais por sobreposição falsa, a validação precisa considerar que senhas, fatores digitados e dados inseridos em telas fraudulentas podem ter sido expostos ao operador.

A comunicação de segurança deve abordar os dois vetores citados sem reproduzir instruções operacionais. Usuários devem ser orientados a não instalar correções, drivers ou supostos ajustes de jogos a partir de descrições de vídeos, arquivos ZIP ou páginas de procedência incerta. Equipes de suporte devem oferecer canais oficiais para atualização de drivers e resolução de falhas de software, reduzindo o apelo das iscas. Em paralelo, monitore o abuso de WhatsApp em estáções corporativas quando o aplicativo for permitido, principalmente envio de mensagens em massa por sessões já autenticadas e uso de automação de navegador fora de fluxos aprovados.

  • Isolar hosts suspeitos, coletar artefatos e remover tarefas agendadas, DLLs, executáveis e atalhos adulterados de forma coordenada.
  • Aplicar controle de aplicativos para bloquear execução e carregamento de DLL em diretórios graváveis por usuário.
  • Auditar atalhos bancários e restaurar apenas versões verificadas por caminhos legítimos.
  • Rotacionar credenciais financeiras afetadas usando dispositivo confiável e revisar eventos de autenticação nas contas relacionadas.
  • Criar detecções comportamentais para carregamento lateral, criação de persistência, busca de configuração em nuvem e conexões WebSocket incomuns.

Postar um comentário

0 Comentários