Como o vazamento do código do worm Shai‑Hulud gerou uma avalanche de malwares no npm

Os participantes eram avaliados pelo impacto do ataque — por exemplo, pelo número de downloads dos pacotes comprometidos. Isso cria um incentivo claro para atacar bibliotecas populares ou cadeias de dependências grandes, aumentando o alcance do malware.

Pesquisadores descreveram o modelo como uma forma de “gamificação” de ataques à cadeia de suprimentos, incentivando vários atores independentes a executar campanhas simultaneamente usando o mesmo kit de ataque.

Clones do malware aparecem rapidamente no npm

Quase imediatamente após a divulgação do código, pesquisadores detectaram novos pacotes maliciosos enviados ao npm por atores imitadores. Uma investigação identificou quatro exemplos:

• chalk-tempalte
• @deadcode09284814/axios-util
• axois-utils
• color-style-utils

Pelo menos um deles continha um clone não ofuscado do Shai‑Hulud, enquanto outros incluíam ladrões de credenciais ou funcionalidades de botnet.

A velocidade com que esses pacotes apareceram mostra como um malware open source pode se espalhar rapidamente quando a infraestrutura do ataque se torna pública.

Typosquatting: o truque por trás de nomes como “chalk-tempalte”

Grande parte desses pacotes utiliza uma técnica comum chamada typosquatting.

O método consiste em publicar pacotes com nomes quase idênticos aos de bibliotecas legítimas. A ideia é que desenvolvedores instalem o pacote errado por engano — ou que o erro passe despercebido em atualizações automáticas de dependências.

Alguns exemplos:

• chalk-tempalte, que imita o padrão do pacote legítimo chalk-template
• axois-utils, que lembra bibliotecas relacionadas ao popular cliente HTTP axios

Como muitas instalações do npm acontecem automaticamente em pipelines de build ou em cadeias de dependências, um único pacote malicioso pode executar código durante a instalação e comprometer o ambiente de desenvolvimento.

O que o malware Shai‑Hulud é capaz de fazer

O Shai‑Hulud não é apenas um pacote malicioso comum. Ele se comporta como um worm de cadeia de suprimentos que se propaga sozinho.

Análises de pesquisadores indicam que o malware pode:

• Roubar credenciais de ambientes de desenvolvimento e runners de CI/CD
• Coletar tokens e segredos de nuvem de serviços como AWS, GCP e Azure
• Exfiltrar dados sensíveis para repositórios controlados pelos atacantes
• Inserir backdoors em outros pacotes caso encontre tokens de publicação de mantenedores

Em incidentes anteriores, o worm conseguia publicar automaticamente versões comprometidas de qualquer pacote ao qual tivesse acesso via token roubado — permitindo que o ataque se espalhasse pelo ecossistema npm sem um servidor central de comando.

Por que especialistas veem isso como uma grande escalada

O Shai‑Hulud já era preocupante por seu comportamento semelhante a um worm e por focar diretamente na infraestrutura usada por desenvolvedores.

Mas dois fatores elevaram o risco para outro nível:

1. Código do ataque disponibilizado publicamente

Ao liberar o código‑fonte, os criadores transformaram o malware de uma campanha específica em uma ferramenta reutilizável por qualquer ator malicioso.

2. Incentivos financeiros e competição

O concurso promovido em fóruns hackers criou um incentivo direto para experimentar e lançar novos ataques.

Juntos, esses elementos mudam o modelo de ameaça: em vez de um único grupo operando o malware, agora múltiplos atores podem lançar ataques simultaneamente usando a mesma base de código.

O alerta para o ecossistema open source

O caso Shai‑Hulud evidencia uma tendência crescente: atacantes estão mirando a infraestrutura de desenvolvimento de software — registries de pacotes, pipelines CI/CD, fluxos de release e credenciais de mantenedores.

Quando um pacote malicioso entra nesse ecossistema, ele pode executar código na instalação, extrair segredos de sistemas de build e potencialmente comprometer todos os projetos que dependem daquela biblioteca.

A rápida aparição de clones do malware após a divulgação do código mostra como um único ataque à cadeia de suprimentos pode escalar rapidamente quando as ferramentas do ataque se tornam públicas.

Para equipes de segurança e desenvolvedores, a lição é clara: proteger aplicações não basta. É preciso proteger também toda a cadeia de ferramentas e dependências usada para construí‑las.