Campanha ViteVenom Utiliza Pacotes npm Maliciosos com C2 em Blockchain para Distribuir RAT

Campanha ViteVenom Utiliza Pacotes npm Maliciosos com C2 em Blockchain para Distribuir RAT

Pesquisadores identificaram uma expansão da operação ChainVeil que foca no ecossistema Vite, utilizando uma infraestrutura de comando e controle baseada em blockchain para evadir bloqueios e entregar um Trojan de Acesso Remoto.

ComponentePacotes npm com escopo @vitejs/* (typosquatting) e infraestrutura de build Vite
VetorInstalação de dependências maliciosas seguida de execução de código no momento da importação (import time), utilizando transações de blockchain para recuperar o payload.
ImpactoImplantação de Remote Access Trojan (RAT) com capacidades de reverse shell, exfiltração de arquivos, coleta de credenciais e injeção de backdoor persistente.
PrioridadeRemoção imediata dos pacotes, auditoria de arquivos de configuração de shell (.bashrc,.zshrc,.profile) e rotação de todas as credenciais.
Resumo técnico

Uma campanha de atacada de cadeia de suprimentos de software, codinome ViteVenom, foi descoberta visando desenvolvedores que utilizam a ferramenta de build frontend Vite. Atribuída ao ator de ameaças conhecido como SuccessKey, a atividade representa uma expansão da operação ChainVeil, alterando o foco de bibliotecas genéricas para componentes específicos do ecossistema Vite. A principal mudança tática observada é o uso de nomes de pacotes com escopo (scoped packages) que imitam o namespace oficial @vitejs/*, conferindo uma aparência de legitimidade para enganar desenvolvedores.

A campanha se distingue pelo uso de uma infraestrutura de comando e controle (C2) de quatro camadas baseada em blockchain, abrangendo as redes Tron, Aptos e Binance Smart Chain (BSC). Essa arquitetura permite que os atacantes armazenem ponteiros de payload em dados de transações públicas em vez de dominios tradicionais, o que torna o desligamento ou a destruição da infraestrutura C2 extremamente difícil para as autoridades e provedores de segurança. Evidências da atividade maliciosa, incluindo a ativação de carteiras de criptomoedas ligadas à ViteVenom, remontam a 27 de fevereiro de 2026.

Fluxo técnico

Diferentemente de muitas campanhas de supply chain que ativam o código malicioso durante a instalação (install time), os pacotes da família ViteVenom são projetados para executar apenas no momento da importação (import time). Essa técnica deliberada visa contornar mecanismos de segurança de endpoint que monitoram ganchos de instalação de pacotes, atrasando a detecção até que o código seja efetivamente utilizado em tempo de execução pelo desenvolvedor.

O código malicioso atua como um loader inicial que consulta a infraestrutura blockchain para obter o estágio seguinte da infecção. O fluxo começa com uma consulta à blockchain Tron para recuperar a transação mais recente da carteira do atacante. Os dados dessa transação são decodificados para extrair um hash de transação da Binance Smart Chain (BSC). Subsequentemente, a transação na BSC é consultada para extrair o payload criptografado do campo de entrada. Caso o método de recuperação via Tron falhe, o malware emprega a rede Aptos como mecanismo de redundância. Além disso, existe um fallback que busca o Trojan de Acesso Remoto (RAT) diretamente de um servidor C2 via HTTP, ignorando completamente a camada de blockchain para garantir a entrega do malware final.

Superficie afetada

O ataque afeta desenvolvedores e ambientes de integração contínua que instalaram pacotes npm maliciosos entre 29 de junho e 3 de julho de 2026. O foco específico em pacotes com escopo que imitam o @vitejs/* indica que alvos que buscam utilitários oficiais ou complementares para o Vite foram os principais visados. A persistência do malware é garantida através da modificação de arquivos de configuração de shell padrão em sistemas Unix-like.

A análise da campanha revela que o ator SuccessKey utiliza uma abordagem de compartimentação para limitar a exposição, variando nomes de pacotes, contas de mantenedor, carteiras de nível 1 e caminhos de arquivo entre diferentes trilhas de distribuição. No entanto, o compartilhamento de infraestrutura de nível 2 (mesmos endereços de carteira Tron e contas Aptos) conecta operacionalmente o ViteVenom à campanha anterior ChainVeil.

  • Desenvolvedores utilizando o framework JavaScript Vite e o registro npm.
  • Pacotes com nomes semelhantes ao namespace oficial @vitejs/*.
  • Arquivos de configuração de shell de usuário:.bashrc,.zshrc e.profile.
Hunting e telemetria

Equipes de segurança devem procurar por anomalias no tráfego de rede que indiquem interações com APIs de nós de blockchain públicas (Tron, Aptos, BSC) originadas de estáções de desenvolvimento ou servidores de build, especialmente se seguidas por comunicações HTTP suspeitas. A atividade de processo relacionada a comandos de shell não autorizados ou modificações em arquivos de configuração de usuário deve ser tratada como um indicador de comprometimento.

A detecção pode ser aprimorada monitorando-se tentativas de conexão de saída para domínios desconhecidos ou endereços IP que funcionem como servidores C2 de fallback, dado que o mecanismo primário de C2 não depende de DNS tradicional. Verificações de integridade de arquivos nos diretórios home dos usuários para detectar alterações em scripts de inicialização de shell são cruciais.

  • Tráfego de rede para endpoints de API de blockchain (Tron/Aptos/BSC) a partir de ambientes de desenvolvimento.
  • Modificações não autorizadas nos arquivos.bashrc,.zshrc ou.profile.
  • Conexões HTTP de saída para servidores desconhecidos após a importação de novas dependências.
Mitigação

A resposta imediata requer a remoção dos pacotes maliciosos identificados de todos os ambientes afetados, incluindo caches locais e dependências transitórias. É imperativo realizar uma auditoria completa nas dependências dos projetos para garantir que nenhum outro artefato suspeito tenha sido introduzido. Como o malware possui capacidades de coleta de credenciais e acesso remoto, a rotação de todas as chaves de API, tokens e senhas que possam ter sido acessadas ou interceptadas durante o período de comprometimento é obrigatória.

A limpeza da persistência deve envolver a edição manual dos arquivos de configuração de shell para remover quaisquer linhas de código injetadas pelo atacante. Organizações deve revisar seus processos de triagem de pacotes e implementar verificações de segurança estática em dependências antes da instalação, com foco na detecção de typosquatting e behavioramento anômalo em scripts de inicialização.

  • Remoção imediata dos pacotes npm maliciosos e limpeza de cache.
  • Restauração de arquivos.bashrc,.zshrc e.profile para um estado seguro conhecido.
  • Rotação forçada de credenciais, tokens de acesso e chaves SSH acessados pelos desenvolvedores comprometidos.

Postar um comentário

0 Comentários