As consequências de Shai-Hulud 2 e o que poderia ter sido feito de forma diferente.

O worm Shai-Hulud 2.0 do npm é um daqueles incidentes que as equipes de segurança de aplicativos (AppSec) irão citar em suas análises pós-incidente por muitos anos.

Vamos analisar o que aconteceu, quem foi afetado e como uma plataforma SSCS como essa funciona. ScribeHub poderia ter ajudado as organizações a prevenir ou, pelo menos, limitar drasticamente o raio da explosão.

1. O que é Shai-Hulud 2.0?

Shai-Hulud apareceu pela primeira vez em setembro de 2025 como um verme autorreplicante que tem como alvo o ecossistema npm, comprometendo centenas de pacotes JavaScript e se espalhando por meio de credenciais roubadas e republicação automatizada. 

Apenas alguns meses depois, os pesquisadores começaram a observar uma onda de acompanhamento muito mais agressiva e automatizada, agora comumente referido como “Shai-Hulud 2.0”, “Sha1-Hulud 2.0” ou “A Segunda Vinda”. 

Principais características do Shai-Hulud 2.0:

• Foco na cadeia de suprimentos. Em vez de atacar uma empresa, ataca outra. pacotes npm confiáveis e, em variantes posteriores, até mesmo ecossistemas Java (Maven), contaminando componentes básicos usados ​​em milhares de projetos.
• Verme que se reproduz por conta própria. Uma vez que comprometa um mantenedor, ele automaticamente cria backdoors. todos os dos pacotes desse mantenedor e os republica, permitindo uma disseminação exponencial pelos grafos de dependência.
• Ladrão de segredos e informações. O payload coleta agressivamente variáveis ​​de ambiente, tokens do GitHub e npm, credenciais de nuvem e segredos de CI/CD de máquinas de desenvolvedores e pipelines de compilação. 
• Interruptor de segurança destrutivo. Se o malware não conseguir alcançar seu servidor de comando e controle (C2) ou falhar em se propagar, algumas variantes tentam apagar o diretório pessoal do usuário, transformando uma falha na cadeia de suprimentos em um incidente potencialmente destrutivo.

2. Como o ataque funcionou – Passo a passo

Diferentes fornecedores utilizaram ferramentas e scripts ligeiramente diferentes, mas a cadeia de eliminação geral se parece mais ou menos com isto:

2.1 Ponto de apoio inicial: contas de manutenção comprometidas

Atacantes:

1. Contas de mantenedores do npm/GitHub comprometidas Utilizando tokens roubados anteriormente, phishing, reutilização de senhas ou autenticação multifator (MFA) fraca.
2. Usei essas contas para publicar versões trojanizadas de pacotes legítimos – geralmente com apenas uma atualização de versão em nível de patch, de forma que se misturavam aos padrões normais de atualização.

Como os pacotes foram assinados/publicados pelos responsáveis ​​legítimos pela manutenção, eles pareceram confiáveis ​​para os usuários subsequentes.

2.2 Infecção via npm install / pipeline de CI

As organizações retiraram estes pacotes:

• via normal npm install em ambiente de desenvolvimento local,
• ou indiretamente em Pipelines de CI / CD como parte de compilações automatizadas.

Os pacotes maliciosos normalmente exploravam scripts de ciclo de vida do npm (pré-instalação, instalar, pós-instalação) como vetores de execução, baixando e executando uma carga útil de segundo estágio, como pacote.js, setup_bun.jsou arquivos grandes e semelhantes, com formatação incorreta. 

2.3 Roubo de credenciais e reconhecimento do ambiente

Após a execução, a carga útil:

• Variáveis ​​de ambiente enumeradas e arquivos de configuração locais.
• Colhidas credenciais de nuvemTokens do GitHub/GitLab, tokens de acesso do npm, chaves SSH e outros segredos.
• Ferramentas usadas ocasionalmente, como Escaneamento no estilo TruffleHog Para pesquisar segredos em repositórios.

Essas credenciais foram então exfiltrados para repositórios do GitHub controlados pelo atacante ou outras infraestruturas de C2, muitas vezes nomeadas para se camuflarem (por exemplo, repositórios "Shai-Hulud" preenchidos com dumps de ambiente roubados). 

2.4 Movimentação lateral entre ecossistemas de desenvolvedores

Utilizando os tokens roubados, o malware:

• Todos os pacotes npm foram instalados por meio de backdoor. pertencentes aos mantenedores comprometidos, injetando os mesmos scripts maliciosos e republicando-os.
• Plantado fluxos de trabalho maliciosos do GitHub Actions e backdoors em repositórios de vítimas para persistência e exfiltração contínua durante execuções de CI.
• Em algumas variantes da versão 2.0, o projeto foi estendido além do npm para Repositórios Maven, demonstrando um verdadeiro alcance da cadeia de suprimentos em todo o ecossistema. 

Como muitas bibliotecas populares estão localizadas em níveis elevados nas árvores de dependências, um acordo com apenas alguns mantenedores se traduz em dezenas de milhares de repositórios afetados Rio abaixo.

3. Escala e impacto nas vítimas

Diferentes fornecedores de segurança relatam números ligeiramente diferentes, mas todos concordam em uma coisa: Shai-Hulud 2.0 é enorme.

• Pesquisadores de segurança estimam que mais de 25,000 repositórios do GitHub e centenas a aproximadamente 700 pacotes foram impactados nas ondas posteriores, alguns dos quais aparecem em mais de um quarto dos ambientes de nuvem/código Eles fizeram a varredura.
• Os analistas chamam isso de Um dos ataques à cadeia de suprimentos do npm de propagação mais rápida já vistos., com automação que comprometeu Centenas de encomendas em poucas horas.
• Entre as vítimas de alto perfil, estavam projetos e pacotes de Zapier, Domínios ENS, PostHog, Postman, e outros – o que significa que tanto os fornecedores de SaaS quanto milhares de seus clientes tinham potencial exposição.

3.1 Impacto técnico direto

Para organizações que instalaram um pacote infectado por um cavalo de Troia, as consequências típicas incluíram:

• Revelação de segredos de CI/CD (chaves do provedor de nuvem, tokens de implantação, certificados de assinatura de código, etc.).
• Backdoors furtivos em repositórios do GitHub e ações de CI, permitindo que invasores executem comandos arbitrários em builds futuros.
• Artefatos adulterados: o potencial de invasores inserirem lógica maliciosa em aplicativos já desenvolvidos sem que os desenvolvedores percebam.
• Para alguns desenvolvedores azarados, um limpeza destrutiva do $ HOME anuário quando o mecanismo de segurança alternativo do malware entrou em ação.

3.2 Impacto nos negócios

Do ponto de vista empresarial, isso se traduz em:

• Eventos de resposta a incidentes em grande escalaAs equipes de resposta a incidentes (IR) tiveram que auditar todos os projetos que utilizavam os pacotes afetados, rotacionar tokens e, às vezes, congelar as implantações.
• Exposição regulatória e contratualSetores regulamentados (finanças, saúde, fornecedores governamentais) agora enfrentam a possibilidade de que dados regulamentados ou chaves de acesso a sistemas críticos tenham sido extraídos por meio de um pacote de terceiros.
• Erosão da confiança no código abertoLíderes de segurança e engenharia são forçados a rever seu modelo de confiança para registros públicos e a considerar controles mais rigorosos em torno do gerenciamento de dependências.

4. Onde as defesas tradicionais encontram dificuldades

Por que Shai-Hulud 2.0 conseguiu furar tantas defesas?

1. Abusou da confiança, não de uma simples vulnerabilidade. Os pacotes eram “legítimos” – publicados sob nomes de mantenedores reais, frequentemente provenientes de repositórios já existentes.
2. A análise estática de SCA/SAST não foi suficiente. Mesmo que as equipes tivessem SBOMs e scanners de vulnerabilidades, muitas delas não estavam procurando por... comportamental indicadores como scripts de ciclo de vida suspeitos ou exfiltração de dados durante as compilações.
3. Os segredos e a CI/CD eram o verdadeiro alvo. Muitas organizações têm controles e monitoramento mais fracos para ambientes de CI/CD do que para produção, tornando-os alvos perfeitos.
4. Falta de rastreabilidade de ponta a ponta. A maioria das equipes não conseguiu responder facilmente: “Quais exatamente as compilações, artefatos e implantações envolviam um pacote infectado por um cavalo de Troia – e quais estão limpos?”

É precisamente esta a lacuna que segurança da cadeia de suprimentos de software (SSCS) plataformas como ScribeHub são projetados para abordar.

 

5. Como o ScribeHub SSCS pode ajudar a prevenir e mitigar ataques do tipo Shai-Hulud

Vou mapear as técnicas do Shai-Hulud 2.0 para funcionalidades que você normalmente implementaria com a plataforma ScribeHub da Scribe Security e ferramentas relacionadas (por exemplo, política como código da Valint).

5.1 Diretrizes para a ingestão de dependências

Problema no Shai-Hulud 2.0:
As organizações consumiram pacotes npm atualizados automaticamente (via ^/~ intervalos de versões, Renovate/Dependabot ou scripts de CI) com pouca análise comportamental.

Com o ScribeHub:

• Controles de dependência orientados por políticas. Use as políticas do Valint para restringir quais registros e escopos são considerados “confiáveis”, impor listas de permissões para pacotes críticos e gerar alertas quando:
  • um novo responsável pela manutenção publica uma versão,
  • Aparecem scripts de ciclo de vida inesperados,
  • ou um pacote repentinamente adquire um novo comportamento de rede/execução.
• Atestado de componentes de terceiros. O ScribeHub pode ingerir e verificar procedência e atestados de construção Para pacotes onde disponíveis (por exemplo, metadados no estilo SLSA, Sigstore, in-toto), habilitar regras como “Consumir apenas dependências cuja origem de compilação seja confiável.”

Isso não resolve magicamente o problema do ecossistema npm, mas o melhora significativamente. eleva o padrão antes que uma nova versão seja permitida em suas compilações.

5.2 Fortalecendo o pipeline de CI/CD como um “ativo de primeira classe”

O principal valor de Shai-Hulud vinha da exploração de Laptops de desenvolvedores e nós de CI/CD como cofres secretos.

Usando o ScribeHub:

• Atestado de pipeline para cada execução.
  Cada tarefa de CI gera uma declaração assinada descrevendo:
  • Quais repositórios e branches foram criados?
  • Quais dependências e imagens de contêiner foram utilizadas?
  • Quais scripts foram executados (incluindo os ganchos de ciclo de vida),
  • e quais segredos foram acessados.
• Esses dados chegam a lago de evidências do ScribeHub, fornecendo um histórico inviolável de “quem construiu o quê, de onde e com quais recursos”.
• Verificações de tempo de execução de políticas como código.
  Antes que um artefato de compilação possa ser promovido para o ambiente de teste/produção, um mecanismo de políticas valida:
  • que apenas registros npm aprovados foram utilizados,
  • que nenhum script de ciclo de vida proibido (enrolar | bater, ofuscado pacote.js, etc.) são executados,
  • que o processo não estava sendo executado como root e não montava caminhos sensíveis do host.

Se Shai-Hulud injetar um adicional pós-instalação script que exfiltra segredos, essas execuções falhar na política e nunca chegam à produção.

5.3 Análise rápida do raio de explosão

Uma das tarefas mais difíceis em uma campanha como esta é responder:

“Onde exatamente usamos versões trojanizadas do pacote X e o que elas afetaram?”

Com o ScribeHub:

• Cada compilação, implantação e artefato está associado a atestados criptograficamente vinculadosDependências, detalhes do ambiente, SHAs de commit, resumos de contêineres, etc.
• Quando um novo aviso diz “versões 4.8.1–4.8.5 de alguma-biblioteca “Fazem parte do Shai-Hulud 2.0”, você pergunta ao ScribeHub:
  
  
  “Mostre-me todas as compilações dos últimos 90 dias que incluíram essas versões e quais implantações ou imagens elas produziram.”
  
• Você pode, então, rotação secreta alvo e a correção precisa onde é necessária, em vez de rotacionar tudo indiscriminadamente (o que pode ser operacionalmente inviável).

Em outras palavras, o ScribeHub transforma um pânico generalizado no ecossistema em uma incidente delimitado e auditável.

5.4 Protegendo seu próprio pacotes para impedir que sejam transformados em armas

Muitas organizações não apenas consomem software de código aberto – elas também publicar Pacotes usados ​​por clientes, parceiros ou equipes internas. Se uma conta de mantenedor em sua organização for comprometida, você poderá se tornar um vetor de propagação involuntário, assim como os mantenedores do Shai-Hulud.

O ScribeHub pode ajudar através de:

• Exigir declarações assinadas da sua CI antes que um pacote possa ser publicado no npm ou em um registro interno:
  • As versões de pacotes que não são acompanhadas pelas declarações esperadas são rejeitadas ou sinalizadas.
• Monitoramento contínuo de seus próprios registros e repositórios:
  • Alertas quando um pacote é publicado a partir de um ambiente de compilação desconhecido ou fora dos seus pipelines de CI aprovados.
  • Detecção de novos scripts GitHub Actions ou npm que não estavam presentes na última versão "confiável".

Isso torna muito mais difícil para um atacante com um token roubado para inserir silenciosamente uma versão maliciosa em seu espaço de nomes.

5.5 Evidências para reguladores, clientes e partes interessadas internas

Incidentes como o Shai-Hulud 2.0 são cada vez mais analisados ​​por reguladores e grandes clientes, especialmente em setores alinhados com estruturas como SSDF do NIST, PCI-DSS 4ou requisitos de certificação de software governamentais.

Porque o ScribeHub mantém um Registro de atividades do SDLC com data, hora e assinatura., você pode:

• Demonstre quais versões e lançamentos não foram afetados por dependências infectadas por cavalos de Troia.
• Fornecer aos auditores evidências concretas de:
  • políticas de dependência,
  • aplicação do princípio do menor privilégio na CI,
  • e cronogramas de rotação secreta pós-incidente.

Isso transforma a conversa de "achamos que está tudo bem" para "aqui está a cadeia de custódia atestada do nosso software".

6. Lições práticas para líderes de segurança

Em resumo, eis como eu descreveria o Shai-Hulud 2.0 e o papel que uma plataforma como o ScribeHub pode desempenhar:

1. Suponha que o ecossistema esteja comprometido. Registros públicos são pontos únicos de falha muito atraentes. Seu modelo de segurança deve tratar dependências externas como não confiáveis ​​até que se prove o contrário.
2. Evolua da abordagem "escanear e rezar" para a de "atestar e fazer cumprir". A análise sintática clássica (SCA) e a remoção de fiapos continuam sendo importantes, mas o Shai-Hulud 2.0 mostra que também precisamos de:
   • procedência comprovada,
   • construções comprovadas,
   • e promoção de artefatos protegida por políticas rigorosas.
3. Trate CI/CD como se fosse produção. O worm tinha como alvo segredos e pipelines porque estes costumam ser alvos mais fáceis do que ambientes de execução reforçados.
4. Invista em rastreabilidade. Quando o próximo comprometimento de todo o ecossistema ocorrer – e ocorrerá – sua capacidade de responder “Onde isso nos afetou?” em questão de horas, em vez de semanas, fará a diferença entre um incidente controlado e uma crise em grande escala.

O ScribeHub SSCS não torna o npm ou o código aberto magicamente seguros, mas oferece a visibilidade, o controle e a base probatória necessários para resistir a ataques no estilo Shai-Hulud com muito menos caos.

Se você estruturar seu SDLC em torno de atestações contínuas assinadas, políticas baseadas em evidências e uma forte higiene de CI/CD, o próximo "maior ataque à cadeia de suprimentos do npm da história" se tornará apenas mais um incidente para lidar, e não uma ameaça existencial para o seu negócio.