Alerta em npm: 800 pacotes maliciosos que se ativam com require e entregam um dropper com RAT multiplataforma

Um amplo operacional de pacotes maliciosos inundau o registro npm: cerca de 800 módulos —publicados sob nomes que parecem gerados aleatoriamente ou typo‐squatting — contêm um carregador que desemboca em um troiano de acesso remoto (RAT) e um infostealer multiplataforma. Os investigadores confirmaram que a cadeia de infecção não se apoia em hooks de instalação (preinstall/postinstall) mas em instruções para que o desenvolvedor invoque require () do seu código, o que ativa um download chamado WEL1DROPPER.

Como funciona tecnicamente a campanha: o pacote malicioso introduz código que, uma vez importado com require (), executa um dropper que detecta sistema operacional e arquitetura de CPU. O dropper tenta baixar a próxima etapa desde três Workers de Cloudflare (domínios observados pelos pesquisadores). Se o download HTTPS falhar, a amostra recorre a um mecanismo alternativo baseado em registros DNS TXT apontando para um domínio de infraestrutura (wel1[.]ru). Nesse fluxo, o dropper pede primeiro um registro TXT que indica quantos fragmentos de carga há, pede esses fragmentos numerados, concatena as cadeias recebidas e descodificadas desde Base64 para reconstruir o binário, que depois é escrito em uma pasta temporal e executada com /bin/sh no Linux/macOS ou cmd.exe no Windows.

Na etapa final, segundo Sonatype e outras análises, o malware exibe comportamentos próprios de ameaças persistentes: a amostra do Windows adesivo ETW e AMSI para evitar a detecção, verifica ambientes de análise/sandbox, estabelece persistência (Run key e tarefa programada), descarga um payload cifrado e executa; macOS segue uma cadeia similar com LaunchAgent; Linux descarrega um ELF comprimido com UPX que acaba por instalar Sliver, um framework de C2 de código aberto. As mesmas publicações também apontam que muitos pacotes incluem um arquivo "lib/telemetry.js" - um SDK de telemetria aparente - que contém o mesmo downloader mas não é importado pelo entrypoint, o que sugere intenção de camuflar a finalidade maliciosa durante uma revisão superficial.

Atos confirmados: a existência de centenas de pacotes maliciosos em npm com o padrão descrito, os domínios de Cloudflare Workers envolvidos, o uso de wel1[.]ru para a entrega por DNS TXT, a técnica de reconstrução por fragmentos Base64 e a detecção de Sliver na cadeia de Linux. Fontes públicas que cobrem o operacional e explicam técnicas semelhantes incluem pesquisas de resposta e análise pública ( Cobertura de BleepingComputer) e documentação da plataforma utilizada como infra-estrutura (Cloudflare Workers: Documentação oficial).

Estimações e incertezas: alguns indicadores encontrados dentro de binários macOS referenciam domínios com nomes de serviços financeiros russos, pelo que os analistas estimam que o ator poderia se interessar em objetivos do setor financeiro russo; isto é uma inferência baseada em artefatos internos, não uma declaração do atacante nem prova de objetivos concretos. Também foi comentado que a campanha poderia ser uma evolução de outra operação denominada "Moika" observada anteriormente, mas a relação entre campanhas é uma hipótese razoável baseada em táticas e objetivos, não uma certeza comprovada.

Quem afeta isto? Desenvolvedores e projetos que importam pacotes de npm sem vetos rigorosos, ambientes de CI/CD que executam código de dependências em pipelines, e equipamentos de operações que não filtram egress para infra-estruturas externas ficam expostos. Além disso, qualquer estação de trabalho ou servidor onde um desenvolvedor requer um pacote comprometido (localmente ou builds automatizados) pode terminar executando o dropper e receber a carga maliciosa. Organizações com repositórios públicos ou privados que permitam pacotes de terceiros sem controle são de alto risco.

Conseqüências reais: a campanha permite exfiltração de credenciais e ambiente (segundo análise prévia de campanhas semelhantes), execução remota e persistência do atacante em máquinas Windows, macOS e Linux, e eventual incorporação de equipamentos a uma botnet ou a uma infraestrutura de C2 (Sliver) que facilita movimentos laterais e roubo de dados. Para equipes de desenvolvimento, isso também implica risco de comprometer segredos e credenciais usadas em CI/CD, implantaçãos e repositórios.

Medidas concretas e urgentes que devem tomar leitores e equipamentos técnicos:

1) Não require () pacotes desconhecidos ou de nomes suspeitos. Se deve ser avaliado um novo pacote, verifique localmente num ambiente isolado ou sandbox e não o importa diretamente na pipeline de produção.

2) Implementar políticas de allowlist/denylist em repositórios e gestores de pacotes. Use controlos na organização do npm, um 'proxy' de registo interno (por exemplo, Nexus, Artifactory) ou um bloqueio por nome para evitar que os pacotes externos sejam transferidos directamente em ambientes de build.

3) Proteger pipelines CI/CD e evitar execução de código de dependências sem revisão. Não execute programas ou processos de terceiros em estágios que tenham acesso a segredos; habilite a separação de credenciais e variáveis de ambiente, e aplique o princípio de menor privilégio.

4) Aplicar a digitalização de dependências e análise estática/ dinâmica. Integrar ferramentas como Snyk, Dependabot, ou soluções de SCA (Software Composition Analysis) para detectar pacotes maliciosos ou incomuns; complementar com EDR/antivírus capaz de detectar armadilhas como manipulação de ETW/AMSI e binários ofuscados/UPX.

5) Restringir o tráfego de saída e bloquear domínios/infrastructuras suspeitas. Filtrar egress com proxy/firewall para evitar downloads a partir do Cloudflare Workers/domínios externos não autorizados e bloquear comunicações para wel1[.]ru até investigar. Registar e revisar conexões salientes desde sistemas de compilação e estações de desenvolvimento.

6) Rever persistências e artefatos em endpoints. No Windows procurar Run keys, tarefas programadas recentes e processos filhos invulgares; no macOS listar LaunchAgents/Daemons; no Linux rever binários temporários, crontabs e processos que falem com infra-estruturas externas. Use ferramentas forenses para detectar Sliver ou C2 ativo.

7) Rotar credenciais e segredos expostos. Se um projeto ou pipeline usou pacotes comprometidos, rote imediatamente chaves, tokens e certificados que poderiam estar acessíveis e audite os logs de acesso para atividade incomum.

Por último, é fundamental adotar uma prática sustentada de minimização de dependências, revisão manual de pacotes críticos, e segregação entre ambientes de desenvolvimento e produção. Campanhas como esta exploram a confiança implícita em ecossistemas abertos: mitigar exige controles técnicos e mudanças de processo na gestão de dependências. Para quem precisa de uma visão técnica mais ampla sobre pacotes maliciosos em registros públicos, pesquisas de equipes de resposta e blogs técnicos continuam atualizando IOCs e recomendações operacionais ( Unidade 42 de Palo Alto Networks, entre outras fontes especializadas.