Campanha de npm instala RedC2 4.0 ao importar pacotes maliciosos

Autor: Publicada 6 min de lectura 2 leituras

As imagens deste artigo foram geradas com inteligência artificial. Como publicamos

Pesquisadores em cibersegurança encontraram uma campanha de pacotes maliciosos no ecossistema npm que, à primeira vista, proporcionam utilitários de calendário e cálculo, mas na verdade servem como veículo para instalar um implante Linux de controle remoto chamado RedC2 4.0 (com seu beacon Linux RedShell). O achado foi divulgado publicamente pela equipe de pesquisa de Trend Micro e confirma que a execução do malware ocorre simplesmente ao importar o pacote em uma cadeia de dependências, mesmo de forma transitiva.

Atos confirmados: Trend Micro relatou que uma dúzia de pacotes publicados no npm contém um binário empacotado (com nomes como math-core.bin, calc.bin ou calc-mapping.bin localizados em dist/ ou dist/internal/) que é marcado como executável e lançado em segundo plano quando o módulo é carregado. Os pacotes identificados incluem, entre outros, streak-metrics-math@1.0.0, kit-map-vim@1.0.0, streak-map-cache@1.0.0 e uma lista completa informada pela pesquisa. O ficheiro de entrada que atua como carregador troiano é dist/index.mjs: basta que qualquer módulo na cadeia de dependências importe esse pacote para que o implante seja executado, sem necessidade de hooks de instalação ou chamadas explícitas para funções exportadas.

Campanha de npm instala RedC2 4.0 ao importar pacotes maliciosos
Imagem gerada com IA.

Tecnicamente, o mecanismo descrito é simples e eficaz em ambientes JavaScript/Node: o módulo expõe funcionalidades legítimas (por exemplo, funções de datas ou métricas) mas em sua inicialização realiza operações sobre o binário incluído (cambia permissões (chmod), o lança com spawn como processo desassociado e termina sua própria execução. Assim, o pacote continua cumprindo a sua promessa funcional e passa despercebido em revisões superficiais, enquanto estabelece uma conexão saliente a um servidor de comando e controle (C2) para receber comandos.

Sobre a carga útil: o binário implantado é a variante Linux do framework RedC2 em sua versão 4.0, que incorpora o beacon RedShell. De acordo com a descrição técnica difundida, o implant oferece controle remoto interativo (/bin/sh), ex-filtração de dados (incluindo chaves SSH e credenciais de navegadores), execução em memória de ELF e shellcode, proxy SOCKS5 e funcionalidades de pivoting e tunneling entre hosts. RedC2 também inclui componentes para Windows e macOS com capacidades semelhantes; a versão para Windows adiciona evação de controle de contas (UAC bypass), técnicas para interferir com antivírus e movimento lateral mais avançado.

Um aspecto que preocupa especialmente os pesquisadores é a integração de uma camada assistida por modelos de linguagem: Red Agent, um componente LLM que transforma instruções em linguagem natural em sequências de comandos e comandos do beacon. Trend Micro e o pesquisador Aliakbar Zahravi apontaram que essa abstração reduz a pericia técnica necessária para operar o C2, facilitando intrusões complexas a operadores com menos experiência.

Quem afeta isto? Confirmado: qualquer projeto que dependa direta ou indiretamente dos pacotes listados e execute código em ambientes Linux - especialmente servidores, contêineres e pipelines de integração contínua que instalam dependências automaticamente - corre risco de executar a implant. O vetor é perigoso porque um simples "import" ou "require" em uma dependência transitiva ativa o binário. Portanto, não só usuários que instalem os pacotes maliciosos estão em risco; repositórios, imagens base e ambientes de produção que atualizem ou reconstruam dependências sem filtragem também podem ser comprometidos.

Consequências práticas: em sistemas comprometidos, os operadores podem obter shells interativos, roubar credenciais, implantar cargas adicionais, mover lateralmente e estabelecer persistência. A nível de cadeia de abastecimento, o vetor permite que o malware seja propague para projetos legítimos que incluam essas dependências em sua árvore. Além disso, a presença de um assistente AI integrado pode acelerar operações em escala e tornar mais difícil detectar padrões de atividade humana frente a automatizada.

O confirmado vs. o estimado: é confirmado que os pacotes executam um binário RedShell e que RedC2 4.0 foi promovido publicamente; também foi documentada a lista de pacotes afetados. É uma estimativa, embora plausível fundada, que essas publicações representem uma campanha intencional de distribuição de malware por pacotes npm. A atribuição a agentes ou ligações com ataques prévios criminosos é mantida como suspeita em relatórios relativos a outras campanhas da cadeia de abastecimento, mas não foram apresentados provas públicas conclusivas que permitam a sua atribuição definitiva.

Medidas concretas e imediatas que devem tomar desenvolvedores e administradores:

1) Identificar a exposição imediata. Em repositórios e servidores, procure a presença das livrarias concretas e dos nomes de binários reportados. Exemplos de pesquisas úteis: listar dependências com npm lsstreak-metrics-mathou digitalizar node_modules por padrões como "math-core.bin" ou "dist/index.mjs" (por exemplo, grep -R "math-core.bin" node_modules/). Verifique os locks (package-lock.json / yarn.lock) para versões citadas.

2) Parar e remover. Se detectar a presença de pacotes ou binários suspeitos, isole a máquina da rede, preserve imagens e logs para análise forense e remova os pacotes dos ambientes afetados. Reemplace artefatos reconstruindo imagens de fontes limpas e verificadas em ambientes isolados.

3) Rever e endurecer pipelines. Evite instalações automáticas sem revisão em ambientes produtivos. Configure políticas de bloqueio/allowlist em registries internos, use verificação de integridade (hashes), habilite 2FA para contas de publicação e restrinja privilégios de CI para publicação de pacotes. Implemente digitalização de dependências com ferramentas como Snyk, Dependabot ou Sonatype e valide artefatos antes de promover a produção.

4) Monitorizar e tentar detectar. Bloqueie comunicações salientes suspeitas em firewalls (especialmente servidores C2) e monitorize processos filhos inesperados que executem binários de dist/ em node_modules. Atualize regras EDR/AV para detectar RedShell/RedC2 e patterns de execução de binários empacotados.

5) Rota credenciais e privilégios. Após uma possível intrusão, considere a rotação de chaves e credenciais (APIs, SSH), e verifique usuários e acessos. Evalu a necessidade de reconstruir sistemas comprometidos em vez de os limpar a quente.

Campanha de npm instala RedC2 4.0 ao importar pacotes maliciosos
Imagem gerada com IA.

Recomendações estratégicas a médio prazo: use registries privados e assinaturas de pacotes para ambientes críticos; adopte abordagens reprodutíveis para builds (bloqueio de versões e SLSA ou assinaturas) e aplique controles de confiança aos mantenedores de pacotes. A comunidade de segurança também precisa melhorar a detecção de binários empacotados em módulos que se prometem como livrarias puramente JavaScript.

Contexto adicional: esta intrusão se encaixa numa tendência maior de ataques à cadeia de fornecimento de software (em diferentes ecossistemas como npm e crates.io). Em meses recentes, foram documentados incidentes onde pacotes legítimos foram autorizados para inserir código malicioso executado durante compilações ou instalações automáticas. Para referência geral sobre riscos e boas práticas em cadeia de fornecimento, consulte projetos da indústria como OWASP Software Supply Chain (https://owasp.org/www-project-supply-chain-security/) e documentação oficial de npm (https://www.npmjs.com/). O relatório original da análise técnica foi publicado pela Trend Micro; sua página de pesquisa oferece detalhes adicionais e atualizações (https://www.trendmicro.com/en_us/research.html).

Em suma, a ameaça demonstra que os pacotes aparentemente inocuos podem portar implantes potentes e que a execução automática — mesmo por importações transitivas — facilita compromissos em larga escala. A resposta eficaz exige detecção proativa em repositórios e pipelines, bloqueio de dependências não verificadas e procedimentos claros para conter e recuperar sistemas afetados.

Cobertura

Relacionadas

Mas notícias do mesmo assunto.