Dead Man’s Switch: malware destrutivo se espalha pela cadeia npm | Riscos e Ameaças

Pesquisa do GitLab descreve um ataque massivo via pacotes npm que distribui uma variante de Shai‑Hulud com funcionalidade de wipe caso os atacantes percam controle de infraestrutura; o malware rouba tokens e se replica publicando pacotes infectados, criando risco sistêmico ao ecossistema JavaScript.

Pesquisadores do GitLab Vulnerability Research identificaram uma campanha em larga escala que usa pacotes npm comprometidos para distribuir uma variante evoluída do malware conhecido como Shai‑Hulud, agora com mecanismo de destruição de dados caso os atacantes percam controle da infraestrutura — um "dead man’s switch" autodestrutivo.

Panorama e descoberta

A análise identifica um pacote de instalação que baixa uma distribuição do runtime Bun que, na prática, atua como disfarce para um binário ofuscado (~10 MB) que executa no host vítima. O comportamento observado combina roubo agressivo de credenciais (tokens GitHub, chaves npm, credenciais de AWS/Google Cloud/Azure) com capacidade worm‑like de se propagar entre pacotes mantidos pelo mesmo desenvolvedor usando tokens npm roubados.

Fluxo de infecção e proliferação

Ao instalar um pacote comprometido, um script automatizado baixa a carga-ofensa que: (1) executa e coleta tokens e chaves locais; (2) usa esses tokens para automaticamente modificar package.json, incrementar versões e republicar pacotes para o registro npm, infectando outros projetos do mantenedor; (3) exfiltra credenciais para repositórios GitHub controlados por invasores marcados com "Sha1‑Hulud: The Second Coming".

Capacidade destrutiva — o "dead man’s switch"

O aspecto mais grave é a lógica destrutiva incorporada: se o sistema infectado detectar perda simultânea de acesso ao GitHub e ao npm (por exemplo, remoção de repositórios ou revogação de tokens), o malware aciona rotinas de wipe. Em Windows tenta apagar arquivos de usuário e sobrescrever setores; em Linux/macOS executa técnicas avançadas de wiping projetadas para dificultar ou impedir recuperação de dados. As fontes alertam que remoções massivas de infraestrutura pelos provedores podem, inadvertidamente, desencadear perdas em larga escala em hosts infectados.

Implicações para a cadeia de desenvolvimento

Este vetor explora expectativas legítimas: desenvolvedores esperam que pacotes npm executem scripts na instalação. A capacidade de se mover lateralmente dentro do ecossistema de um mantenedor e de republicar artefatos infectados eleva o risco de uma propagação exponencial por dependências transversais.

Mitigações práticas apontadas

Habilitar Dependency Scanning e verificação de supply‑chain em pipelines (GitLab recomenda ativar Dependency Scanning).
Monitorar scripts preinstall/postinstall e variações atípicas em versionamento das dependências.
Restringir e rotacionar tokens de publicação, usar autenticação de máquina com escopos mínimos e práticas de segredo zero‑trust.
Auditar contas de mantenedores e pacotes de terceiros antes de inclusão em cadeias de produção.

Limitações e recomendações operacionais

As observações vêm de análise de amostras e telemetria: são descritos tipos de artefatos e comportamentos (10MB ofuscado, uso do Trufflehog para localizar segredos, exfiltração a repositórios GitHub). As fontes não divulgam lista completa de pacotes afetados para evitar ampliação do ataque, então equipes de segurança devem assumir exposição latente e priorizar varredura de dependências internas.

Conclusão

A combinação de worm‑like propagation, roubo de tokens de publicação e mecanismo de destruição condicional transforma esta campanha em uma ameaça sistêmica para o ecossistema JavaScript. A defesa passa por varredura automatizada, controles de publicação rígidos e resposta coordenada entre registries e plataformas de código.