Mini Shai-Hulud: a campanha de fornecimento comprometido que rouba Tokens, exibe cargas maliciosas e reinfecta suas pipelines desde npm

Pesquisadores de várias assinaturas de segurança alertaram sobre uma campanha de fornecimento comprometido que aponta para o ecossistema JavaScript da SAP, distribuída em pacotes npm legítimos, mas versionados com um instalador malicioso. O ataque — autodenominado "mini Shai-Hulud" pelo ator— usa um gancho de instalação (preinstall) para baixar e executar um binário de Bun desde o GitHub Releases e, a partir daí, carregar um carregador JavaScript que instala um exfiltrador de credenciais e um marco de propagação executado no ambiente do desenvolvedor ou em pipelines de CI/CD.

O notável desta campanha não é apenas a técnica de entrega, mas o seu objetivo e alcance: roubar tokens e segredos locais e na nuvem (GitHub, npm, GitHub Actions, AWS, Azure, GCP e Kubernetes), cifrar os dados roubados com AES-256-GCM e empacotar a chave com RSA-4096 para que só o atacante possa decifrar, e depois publicar os artefatos exfiltrados em repositórios públicos criados na conta da vítima. Além disso, incorpora mecanismos de auto-propagação que usam os tokens roubados para injetar workflows maliciosos em repositórios e publicar novas versões no registro npm, fechando um ciclo de re-compromissão que pode expandir o dano de forma exponencial.

Há outra dimensão preocupante e relativamente inovadora: o uso de configurações de agentes de programação de IA e do próprio editor como vetores de persistência. O malware introduz arquivos como ".claude/settings.json" para aproveitar hooks de sessão de Claude Code e arquivos de VS Code com "runOn": "folderOpen", de modo a abrir o projeto nestes ambientes, volta a executar o código malicioso. Essa tática transforma ferramentas que aceleram o desenvolvimento em armadilhas que reinfectam as equipes de trabalho e novas máquinas que clonem o repositório.

As implicações práticas são graves: um desenvolvedor pode comprometer sem saber não só sua máquina, mas também pipelines de CI/CD, repositórios e contas de serviços na nuvem. Desde lá os atacantes podem colocar cargas, extrair dados sensíveis, publicar pacotes contaminados que infectem terceiros e manter acesso persistente a ambientes corporativos. A incorporação de criptografia forte e chaves RSA de 4096 bits também complica a resposta forense sobre o conteúdo exfiltrado.

Para mitigar o risco imediato, é fundamental agir rápido e em ordem. Primeiro, identifique e deixe de usar as versões comprometidas (por exemplo, as versões publicadas pelos pesquisadores) e purgue as instalações locais e caches de npm em estações de trabalho e runners de CI. Examine os repositórios em busca de commits ou arquivos inesperados — por exemplo, comprobando a presença de ".claude/settings.json" e ".vscode/tasks.json"— e verifique qualquer GitHub Actions workflow novo ou modificações recentes. Revocar e rodar imediatamente todos os tokens pessoais e de serviço expostos, e rotar chaves de acesso à nuvem, é indispensável: as credenciais devem assumir-se comprometidas até demonstrar o contrário. O GitHub oferece guias práticas para a gestão de tokens e boas práticas que podem ajudar na contenção: Documentação de tokens do GitHub.

Nos pipelines e na política de desenvolvimento, convém reforçar os controlos a médio prazo: activar a digitalização de segredos e a detecção de dependências na plataforma de repositórios, exigir assinaturas de pacotes ou usar registos privados com políticas de admissão, e adotar a rotação automática de credenciais com princípios de mínimo privilégio. Além disso, restringir a execução automática de programas de instalação e auditar hooks como pré-install em package.json ajuda a reduzir as superfícies de ataque que exploram comportamentos por defeito de npm. Para compreender como os scripts npm podem ser utilizados como vetores, a própria documentação do npm é um recurso útil: Programas em npm.

Do ponto de vista operacional, é recomendável reconstruir o runners e ambientes de build a partir de imagens limpas, remover e regenerar chaves e credenciais, e revisar logs do GitHub e de serviços na nuvem para detectar atividade incomum (creação de repositórios, pushes automáticos, workflows novos com permissões elevadas). Ferramentas de segurança da cadeia de abastecimento como scanners de dependências, políticas de bloqueio de versões e soluções de observabilidade para repositórios podem detectar e conter reintentos de publicação maliciosa.

Finalmente, o incidente sublinha a necessidade de entender e controlar não só as dependências de livrarias, mas também as configurações dos agentes de código e os editores que fazem parte do fluxo de trabalho. A indústria deve considerar medidas técnicas que limitem a execução automática de código ao abrir projetos e exigir confirmações explícitas ou sandboxes para integrações com assistentes de IA. Para desenvolvedores que queiram avaliar componentes executáveis como Bun, convém baixar binários de fontes oficiais e verificadas (por exemplo, o site oficial de Bun: Bun) e verificar assinaturas ou checksums quando disponíveis.

Este tipo de campanhas demonstra que a próxima geração de ataques da cadeia de abastecimento já não só aponta pacotes populares, mas sim a atalhos e máquinas que tornam mais rápido o trabalho diário. A resposta deve combinar contenção imediata, rotação de credenciais, limpeza de artefatos e uma política de desenvolvimento que empodere a prevenção e a resiliência frente à execução de código não verificado.