ViteVenom: a nova ameaça em npm que oculta um RAT na importação e usa blockchains como C2

Pesquisadores de segurança identificaram uma nova onda de pacotes maliciosos no ecossistema npm que apontam para desenvolvedores que usam a ferramenta de construção frontend Vite. A campanha, denominada por alguns analistas como ViteVenom, faz parte de uma operação maior ligada ao que é conhecido como ChainVeil e mostra uma evolução tática importante: o abuso direto do ecossistema de pacotes para introduzir um carregador (loader) que obtém e lança um troiano de acesso remoto (RAT) a partir de uma infraestrutura de comando e controle (C2) baseada em múltiplos blockchains.

A importância técnica do ataque reside no método de entrega. Em vez de exfiltrar o payload desde domínios ou servidores tradicionais que podem ser fechados, o código malicioso consulta transações públicas em cadeias como Tron e Binance Smart Chain, descodificar dados incorporados em campos de transação, e assim recupera ponteiros para o próximo estádio do malware. Esta abordagem torna as blockchains públicas numa espécie de camada de armazenamento distribuído e imune à tomada direta pelas autoridades, e dificulta as medidas habituais de interrupção da infraestrutura atacante.

Os pacotes detectados foram publicados no final de junho e início de julho de 2026 e foram projetados para parecer parte do ecossistema Vite por nomes com alcance (scoped) que emulam o namespace oficial. Entre os pacotes identificados aparecem menções a pacotes com prefixos semelhantes a @vitejs e variantes que incluem cadeias como vite-tree, vite-ui e vite-ts, publicados sob diferentes mantenedores e com números de downloads que vão de dezenas a mais de mil. O uso de nomes com alcance para fingar pertence ao projeto oficial é uma mudança tático que aumenta a probabilidade de um desenvolvedor o montante sem suspeita.

Outro traço alarmante é que o código malicioso não se dispara durante a instalação, mas sim para o Importar a dependência em tempo de execução. Isto reduz a eficácia de muitas soluções de segurança que analisam hooks de instalação ou assinaturas de arquivos em repositórios de pacotes, porque o comportamento prejudicial emerge apenas quando o código faz parte do bundle ou é executado na aplicação do desenvolvedor.

As implicações para projetos e organizações são claras: a cadeia de fornecimento de software não é já um vetor teórico, mas um campo operacional onde os atacantes exploram técnicas sofisticadas para persistir e evitar a interrupção. A dependência de infra-estruturas públicas como blockchains para armazenar ponteiros e cargas dificulta tanto a detecção como o bloqueio tradicional, e obriga a repensar controles preventivos e de resposta a incidentes em ambientes de desenvolvimento e CI/CD.

Se você suspeitar que seu projeto pode estar afetado, as ações imediatas e práticas recomendadas incluem remover qualquer pacote comprometido, auditar de forma exaustiva as dependências e os arquivos de configuração do ambiente shell (por exemplo, .bashrc, .zshrc e .profile) em busca de modificações não autorizadas, e rotar credenciais que possam ter sido filtradas. A médio prazo, é conveniente fortalecer políticas de governança de dependências: usar arquivos de bloqueio (lockfiles) verificáveis, exigir revisões de dependências para merges em repositórios, aplicar restrições egress em ambientes de CI para limitar conexões salientes não autorizadas e manter inventários SBOM atualizados para saber quais componentes estão em uso. A combinação de controlos preventivos na fase de desenvolvimento e detecção de comportamento em tempo de execução é fundamental.

Ferramentas de análise de composição de software (SCA) e digitalização de pacotes podem ajudar a detectar sinais de risco, mas as políticas humanas devem ser complementadas: verificar a proveniência dos mantenedores, exigir autenticação multifator para contas de publicação e observar padrões invulgares de importação nos repositórios. Também é prudente incorporar regras de bloqueio para chamadas salientes para nódos e APIs associadas às blockchains utilizadas pelos atacantes e monitorar tráfego DNS e HTTP em busca de comunicações a servidores de C2 conhecidos.

Para aqueles que desenvolvem com Vite, é recomendável rever a documentação oficial e as práticas de segurança do ecossistema, e limitar a adoção de pacotes que não contem com história e manutenção verificáveis. Você pode começar por consultar o site oficial do Vite em https://vitejs.dev/ e repassar boas práticas de segurança na cadeia de fornecimento em projetos como OWASP Software Supply Chain: https://owasp.org/www-project-software-supply-chain-security/. Para quem gere dependências a nível empresarial, serviços de terceiros que oferecem digitalização e monitoramento contínuo de pacotes, como Snyk ou as ferramentas de segurança dos registros de pacotes podem fazer parte de uma estratégia mais ampla de mitigação.

Finalmente, esta campanha reforça uma lição que já é habitual em segurança: não existe uma solução única. Detecção, prevenção e resposta devem ser integradas com governação do desenvolvimento e controlos de rede Para mitigar o risco que as cadeias de fornecimento modernas representam. Aqueles que mantêm projetos públicos e os consumidores de pacotes devem assumir que qualquer nova dependência requer verificação e que a visibilidade contínua sobre o comportamento das aplicações em produção é indispensável para conter incidentes deste tipo.