Quase 800 pacotes npm maliciosos são usados para distribuir

O que aconteceu?

Uma nova campanha de ataque à cadeia de suprimentos de software está utilizando pacotes publicados no npm para distribuir malware em computadores de desenvolvedores.

O npm é um dos principais repositórios utilizados pelo ecossistema JavaScript e Node.js. Na prática, desenvolvedores recorrem ao serviço para incorporar bibliotecas prontas aos seus sistemas em vez de desenvolver determinadas funcionalidades do zero.

O problema ocorre quando um pacote aparentemente legítimo contém código malicioso.

A OpenSourceMalware informou em 6 de agosto que estava acompanhando 788 pacotes relacionados à campanha. Já a Sonatype informou anteriormente ter identificado 846 componentes, nomeando a operação como Flooding Dropper. A diferença existe porque as empresas utilizam seus próprios critérios e momentos de coleta; portanto, não é correto tratar os dois números como se fossem uma contagem única e definitiva.

Segundo a investigação, muitos dos nomes utilizados nos pacotes parecem ter sido gerados aleatoriamente ou construídos para se parecer com bibliotecas que poderiam ser consideradas legítimas. A OpenSourceMalware também avalia a possibilidade de uso de AI slopsquatting, técnica relacionada ao registro de nomes de pacotes plausíveis ou sugeridos por sistemas de IA, embora essa associação seja apresentada pelos pesquisadores como avaliação, e não como fato definitivamente comprovado.

Como o ataque funciona?

O ponto mais incomum dessa campanha é que o malware não depende exclusivamente dos conhecidos scripts preinstall ou postinstall, que podem executar comandos automaticamente durante a instalação de uma biblioteca.

Em um dos pacotes analisados, basta o desenvolvedor carregar a biblioteca com require() para iniciar a cadeia maliciosa. O código importa um arquivo auxiliar que executa automaticamente a rotina responsável pela infecção.

Em termos simples

O processo pode ser entendido desta forma:

O desenvolvedor adiciona um pacote malicioso ao projeto.
A aplicação importa esse pacote.
O código identifica o sistema operacional e a arquitetura da máquina.
O malware tenta baixar um arquivo compatível com o computador.
O arquivo é armazenado temporariamente e executado em segundo plano.

Isso significa que simplesmente bloquear scripts executados durante o npm install não elimina completamente o risco, pois o comportamento malicioso pode ocorrer posteriormente, quando a dependência for carregada pela aplicação.

Windows, Linux e macOS estão na mira

O downloader identificado pelos pesquisadores consegue distinguir diferentes plataformas e arquiteturas.

A análise da OpenSourceMalware mostrou caminhos específicos para:

Linux x64;
Linux ARM64;
macOS Intel e Apple Silicon;
Windows x86 e x64.

Após identificar o equipamento, o código tenta obter o próximo estágio da infecção através de servidores hospedados em Cloudflare Workers.

DNS TXT funciona como canal alternativo

Se o download convencional por HTTPS falhar, o malware utiliza uma técnica mais incomum: registros DNS TXT.

Em condições normais, o DNS é utilizado para converter nomes de domínio em endereços IP e fornecer outros tipos de informações sobre domínios. Registros TXT, porém, conseguem armazenar conteúdo textual.

Os atacantes aproveitam essa característica para dividir o payload em várias partes codificadas. O malware consulta esses registros, reúne os fragmentos e reconstrói o arquivo binário na máquina da vítima.

Por que isso é importante?

Muitas empresas possuem controles rigorosos sobre downloads HTTP e HTTPS, mas permitem consultas DNS de maneira mais ampla.

Nesse caso, bloquear apenas os servidores usados para download convencional pode não ser suficiente, porque existe um segundo mecanismo de entrega do malware. A própria Sonatype destacou esse comportamento como um fator relevante da campanha.

O que acontece depois da infecção?

A atividade varia conforme a plataforma.

Windows

Segundo a Sonatype, a amostra analisada no Windows apresentou mecanismos para interferir no ETW (Event Tracing for Windows) e no AMSI (Antimalware Scan Interface), tecnologias utilizadas para telemetria e inspeção de conteúdo no sistema.

Também foram observados:

verificações de debuggers, máquinas virtuais e sandboxes;
persistência através do Registro do Windows;
criação de tarefa agendada;
download de um payload adicional;
execução do estágio seguinte em memória.

macOS

A análise da OpenSourceMalware encontrou verificações relacionadas a ferramentas como LLDB, DTrace, Frida, Wireshark e VMware.

O malware também pode criar persistência através de um LaunchAgent, fazendo com que seu componente seja iniciado novamente durante sessões futuras do usuário.

Linux

A amostra Linux analisada é um executável ELF empacotado com UPX e realiza downloads adicionais.

A OpenSourceMalware relata que outro pesquisador associou um estágio posterior ao framework Sliver, utilizado para Command and Control. Entretanto, a própria equipe afirma que ainda não confirmou essa identificação de forma independente. Portanto, essa associação deve ser tratada como preliminar.

Quem corre mais risco?

O alvo imediato são ambientes que utilizam pacotes npm, principalmente estações de desenvolvimento, servidores de build e pipelines CI/CD.

Isso é especialmente crítico porque computadores de desenvolvedores frequentemente possuem acesso a recursos sensíveis da organização.

Entre eles podem estar:

repositórios Git;
tokens npm;
credenciais de cloud;
chaves de assinatura;
segredos de implantação;
variáveis de ambiente;
pipelines CI/CD.

A Sonatype recomenda que organizações onde um dos componentes maliciosos tenha sido executado considerem a possibilidade de comprometimento do host, investiguem os estágios adicionais e façam a rotação de credenciais expostas após a limpeza do ambiente.

Como se proteger?

Organizações que utilizam Node.js e npm devem verificar se algum dos pacotes identificados pela pesquisa aparece em:

package-lock.json;
inventários de software;
SBOMs;
caches do npm;
logs de pipelines;
aplicações implantadas.

Caso um pacote relacionado à campanha seja encontrado, remover a dependência não deve ser a única ação. É importante descobrir se ela chegou a ser importada ou executada.

Para ambientes possivelmente afetados, os pesquisadores recomendam analisar logs DNS, tráfego de proxy, telemetria dos endpoints e artefatos criados pelo malware. Credenciais acessíveis a uma estação comprovadamente comprometida também devem ser avaliadas e, quando necessário, substituídas.

Análise Técnica

O que mais chama atenção

O aspecto mais relevante dessa campanha não é somente a quantidade de pacotes publicados.

A combinação de execução durante a importação do módulo, suporte multiplataforma e utilização de DNS TXT como canal alternativo cria diferentes caminhos para que a cadeia de infecção tenha sucesso.

Do ponto de vista defensivo, isso demonstra uma limitação importante: controlar apenas os scripts preinstall e postinstall do npm reduz riscos, mas não impede que uma dependência execute código malicioso quando for efetivamente utilizada.

Risco para empresas

A estação de trabalho de um desenvolvedor deve ser considerada um ativo de alto valor.

Ela pode possuir acesso autorizado a código-fonte, plataformas de desenvolvimento, ambientes cloud e pipelines de produção. Por isso, um comprometimento iniciado através de uma dependência pode ter consequências muito maiores do que a infecção de uma única estação.

Também merece atenção o uso de DNS.

Um comportamento como dezenas ou centenas de consultas TXT sequenciais para domínios pouco usuais, originadas por processos relacionados ao Node.js, pode representar um sinal relevante para investigação.

Recomendação CyberX

Empresas que desenvolvem software deveriam tratar dependências externas como parte da própria superfície de ataque.

Controles recomendados incluem Software Composition Analysis (SCA), SBOM, revisão de novas dependências, versionamento de lockfiles, monitoramento de DNS e proteção de credenciais utilizadas por desenvolvedores e pipelines.

O ponto central é que confiança no repositório não deve ser confundida com confiança automática em tudo que é publicado nele.

Conclusão

A campanha mostra como repositórios de software podem ser utilizados para alcançar diretamente desenvolvedores e ambientes corporativos.

Os pesquisadores confirmaram centenas de componentes relacionados à operação, execução multiplataforma e mecanismos alternativos para entrega de payloads. Ao mesmo tempo, algumas informações sobre estágios posteriores e atribuição permanecem em investigação e não devem ser apresentadas como conclusões definitivas.

Para empresas que utilizam npm, o episódio reforça uma regra importante: uma dependência externa deve receber praticamente o mesmo nível de atenção de segurança aplicado ao código desenvolvido internamente.

AVALIE ESTE CONTEÚDO

Esta análise foi útil?

Ainda não há avaliações.

Quase 800 pacotes maliciosos no npm distribuem malware para Windows, Linux e macOS

O que aconteceu?