O worm Shai-Hulud infecta pacotes npm: uma análise aprofundada do incidente na cadeia de suprimentos

Início » Python » O worm Shai-Hulud infecta pacotes npm: uma análise aprofundada do incidente na cadeia de suprimentos

O que começou como mais um susto na cadeia de suprimentos no mundo JavaScript se transformou em um grande incidente que afetou o ecossistema npm. Relatos de diversas fontes confirmam uma cepa de malware autopropagante. rastreado como Shai‑Hulud, que compromete as credenciais do desenvolvedor, expõe o código e republica pacotes contaminados para manter a infecção em andamento.

Embora as contagens variem de acordo com a fonte, o consenso é claro: estamos lidando com centenas de lançamentos envenenados, incluindo uma biblioteca amplamente utilizada, baixada milhões de vezes por semana. O GitHub removeu mais de 500 versões comprometidas para conter a disseminação, e equipes de segurança em todo o mundo estão incentivando os desenvolvedores a rotacionar credenciais e vasculhar seus repositórios e pipelines em busca de pistas de intrusão.

O que aconteceu e por que isso importa

As investigações indicam que a operação provavelmente começou com coleta de credenciais atrai falsificação npm, incentivando os mantenedores a "atualizar" as configurações do MFA. Com o acesso em mãos, o agente da ameaça implantou um worm que é executado após a instalação, busca segredos e republica compilações infectadas sob a identidade da vítima — transformando mantenedores confiáveis ​​em amplificadores do ataque.

Shai‑Hulud combina duas ideias perigosas: propagação automatizada e roubo de segredos. Ele utiliza tokens npm roubados para publicar novas versões de pacotes e utiliza tokens do GitHub e chaves de nuvem (AWS, GCP, Azure) para se mover lateralmente e exfiltrar dados. Essa combinação potencializa o raio de ação, permitindo que um único ataque se espalhe por inúmeros usuários downstream.

Os alvos parecem estar inclinados para sistemas do tipo Unix. A análise observa que a maioria lógica maliciosa é executada no Linux e no macOS, com base em verificações de ambiente, embora a fase de descoberta de segredos (notavelmente com o TruffleHog) possa ocorrer de forma mais ampla. Esse foco restringiu o alcance do worm, mas ainda deixou uma ampla gama de máquinas de desenvolvedores expostas.

Pacotes de diversas organizações notáveis ​​foram impactados, juntamente com módulos populares da comunidade. Em um exemplo de destaque, o @ctrl/tinycolor O pacote — baixado milhões de vezes por semana — foi incluído na briga, demonstrando o quão profundamente a infecção poderia se infiltrar no gráfico de dependência.

Como o worm funciona (análise técnica)

A carga útil do núcleo é enviada como um arquivo JavaScript robusto, comumente chamado pacote.js (mais de 3 MB em amostras observadas). Ele é executado por meio de um gancho postinstall adicionado ao package.json, o que significa que o código malicioso é executado automaticamente logo após o usuário instalar o pacote pelo npm.

Dentro do bundle.js estão os módulos para Interação da API do GitHub, SDKs de nuvem (AWS/GCP), auxiliares de rede e rotinas para executar o TruffleHog para descoberta de segredos. O script inventaria o sistema operacional, localiza um token npm e verifica se há um token GitHub válido; se nenhum for encontrado, ele desiste — caso contrário, inicia a exfiltração e a replicação.

Uma peculiaridade notável: alguns pacotes infectados continham um arquivo chamado pacote.tar Em vez da convenção de nomenclatura usual, um indicador que ajudou os pesquisadores a sinalizar artefatos comprometidos. Os analistas também observaram uma variante que era executada como um gancho de pré-instalação; um dos primeiros casos citados foi ngx-bootstrap 18.1.4, que pode ter servido como uma cabeça de praia inicial na propagação.

Uma vez executado, o malware enumera os pacotes mais baixados do desenvolvedor por meio da API de pesquisa npm, descompacta cada tarball, remove o bundle.js, injeta um comando postinstall, atualiza a versão e republica no npm com o token da vítima. Isso transforma o portfólio do desenvolvedor em um veículo para novas infecções.

Exfiltração de segredos e fluxos de trabalho do GitHub

Para coleta de credenciais, o Shai-Hulud verifica tokens npm, tokens de acesso pessoal do GitHub e chaves de API de nuvem (AWS, GCP, Azure). Em seguida, ele cria um repositório público no GitHub chamado "Shai-Hulud" na conta da vítima, enviando um arquivo de dados (por exemplo, data.json) com os segredos roubados — expondo-os efetivamente ao mundo.

Paralelamente, os pesquisadores observaram um ângulo astuto do GitHub Actions: o worm cria um branch chamado 'shai‑hulud' em repositórios acessíveis e envia um arquivo de fluxo de trabalho (shai‑hulud‑workflow.yml). Acionado em envios, o fluxo de trabalho coleta segredos e os envia para a infraestrutura do invasor, às vezes após codificação Base64 dupla para ofuscar o conteúdo em trânsito.

Há também evidências de um roteiro de migração que clones repositórios privados/internos de organizações às quais a vítima tem acesso, hospedando-as novamente na conta do usuário como espelhos públicos. O objetivo parece ser o roubo automatizado de código-fonte de projetos privados, aumentando a pressão sobre as organizações afetadas.

Vários relatórios observam artefatos de assistência de IA nos scripts bash (comentários e até emojis), sugerindo que o invasor pode ter usado um LLM para acelerar o desenvolvimento dos componentes de automação do malware.

Escopo e pacotes notáveis

Em remoções coordenadas, o GitHub removeu Mais de 500 versões comprometidas para interromper a propagação do worm. Embora o total exato continue a evoluir, a lista abrange diversos ecossistemas e organizações, com impacto posterior para os desenvolvedores que atualizaram durante o período ativo.

Entre os pacotes e namespaces frequentemente citados: @ctrl/tinycolor (milhões de downloads semanais), múltiplos @multidão/* componentes (como commitlint e bibliotecas de IU) e uma ampla gama de módulos da comunidade, incluindo ngx-bootstrap, upload de arquivo ng2, ngx-toastr, e muito mais. A CrowdStrike indicou que sua plataforma principal permaneceu inalterada e que as chaves foram giradas prontamente após detectar entradas maliciosas no registro público.

• Exemplos vinculados à onda: @ctrl/tinycolor; @crowdstrike/commitlint; @crowdstrike/foundry‑js; @crowdstrike/glide‑core; ngx‑bootstrap; ng2‑file‑upload; ngx‑toastr; @nativescript‑community/*; @teselagen/*; @things‑factory/*; e outros.
• Os pesquisadores também viram várias versões maliciosas por pacote em alguns casos — provavelmente devido ao worm se espalhar por meio de várias contas de mantenedores dentro do mesmo projeto.

Resposta da plataforma e mudanças de segurança

As ações imediatas do GitHub incluíram purgando pacotes ruins conhecidos do npm e bloqueando uploads que correspondam aos Indicadores de Comprometimento (IoCs). A empresa também está implementando controles de publicação mais rigorosos: 2FA obrigatório para publicação local, tokens granulares de vida útil mais curta (por exemplo, sete dias) e adoção mais ampla de Publicação confiável para reduzir a dependência de segredos de longa duração.

As próximas mudanças descontinuarão os tokens clássicos legados e o 2FA baseado em TOTP para publicação, padrão para proibir a publicação de tokense expandir provedores para Publicação Confiável. O GitHub sinalizou uma implementação gradual com documentação e guias de migração, reconhecendo que alguns fluxos de trabalho precisarão de ajustes.

As equipes de inteligência de ameaças e resposta a incidentes em todo o setor (incluindo a Unit 42, Kaspersky, Trend Micro e outras) orientações e detecções emitidas ao mesmo tempo em que compartilha IoCs com pares e alianças para acelerar atualizações de proteção.

Como reduzir riscos agora mesmo

Mova-se rapidamente, partindo do princípio de que qualquer máquina de desenvolvedor que instalou pacotes npm recentemente pode ter vazado segredos. A prioridade é conter abuso de credenciais, pare a persistência e elimine dependências contaminadas das cadeias de construção.

• Gire tokens npm, PATs/chaves SSH do GitHub e credenciais de nuvem (AWS/GCP/Azure) imediatamente; considere todos os segredos presentes nos hosts do desenvolvedor comprometidos.
• Audite dependências via package‑lock.json/yarn.lock; remova ou fixe longe de versões comprometidas conhecidas; reinstale a partir de fontes limpas.
• Aplique MFA/2FA no GitHub e no npm; migre para a Publicação Confiável sempre que possível para eliminar tokens de longa duração do ciclo.
• Examine o GitHub em busca de repositórios públicos inesperados chamados 'Shai‑Hulud', branches ou fluxos de trabalho desconhecidos e execuções de ações anômalas.
• Fortaleça o CI/CD com RBAC de privilégio mínimo, assinatura/verificação de artefatos e varredura SCA contínua; trate consumo de código aberto como um risco gerenciado.

Dicas de caça a ameaças (verificações de alto sinal)

Procure conexões de saída para webhook.site domínios, particularmente o URI observado em vários relatórios. Nos endpoints, procure a presença de pacote.js em diretórios temporários ou de pacotes e para um arquivo GitHub Actions chamado shai‑hulud‑workflow.yml.

• Telemetria de rede: logs de DNS/URL contendo webhook.site; sinalize o caminho específico bb8ca5f6‑4175‑45d2‑b042‑fc9ebb8170b7 se visto.
• Telemetria de arquivo: criação ou execução de bundle.js; presença de shai‑hulud‑workflow.yml em hosts de desenvolvedores Linux/macOS.
• Telemetria de processo: Invocações do TruffleHog onde não é esperado (observe que pode haver uso legítimo em algumas organizações).

Indicadores de comprometimento (IoCs)

Pistas de arquivo e string vistas em investigações incluem pacote.js e shai‑hulud‑workflow.yml, com a string literal 'shai‑hulud' aparecendo em branches, repositórios e fluxos de trabalho.

• Arquivos: bundle.js; shai‑hulud‑workflow.yml
• Strings: shai‑hulud; pacote.tar
• Hashes (selected): 46faab8ab153fae6e80e7cca38eab363075bb524edd79e42269217a083628f09; b74caeaa75e077c99f7d44f46daaf9796a3be43ecf24f2a1fd381844669da777; dc67467a39b70d1cd4c1f7f7a459b35058163592f4a9e8fb4dffcbba98ef210c; 4b2399646573bb737c4969563303d8ee2e9ddbd1b271f1ca9e35ea78062538db; C96FBBE010DD4C5BFB801780856EC228; 78E701F42B76CCDE3F2678E548886860
• Rede: https://webhook.site/bb8ca5f6-4175-45d2-b042-fc9ebb8170b7 (variantes e subcaminhos observados)

Cronograma e análise contínua

Os relatórios atribuem a descoberta inicial a meados de setembro de 2025, com pico de ações de contenção por volta de 16 a 19 de setembroDesde então, o GitHub e diversos fornecedores atualizaram proteções, detecções e orientações. Aguarde novas descobertas retroativas à medida que as organizações concluem as análises de incidentes e expandem as listas de versões afetadas.

Algumas evidências sugerem que o incidente construído sobre vazamentos secretos anteriores, destacando como tokens de longa duração e credenciais armazenadas em cache podem alimentar novas ondas de comprometimento meses depois. Isso deve reforçar os esforços para encurtar a vida útil dos tokens e adotar modelos de publicação que minimizar a expansão secreta.

Nem todos os relatórios concordam com os totais exatos ou com os primeiros pacotes da cadeia, mas o quadro geral é consistente: worm npm auto-replicante que transformou a confiança do desenvolvedor em uma arma e automatizou os direitos de publicação para escalar rapidamente — mais rápido do que muitas equipes poderiam detectar apenas com revisão manual.

O evento ilustra a rapidez com que os pipelines de construção modernos podem se transformar em rodovias para malware. autenticação mais rigorosa, removendo tokens de longa duração do caminho, reforçando o CI/CD e buscando agressivamente por IoCs, as organizações podem conter a exposição hoje e tornar a próxima onda muito mais difícil de executar.