Ataque Shai-Hulud à cadeia de suprimentos do NPM: uma nova geração de ameaças autorreplicantes

Anatomia do verme Shai-Hulud

O ataque Shai-Hulud não é um simples caso de força bruta. Ele opera por meio de um processo de múltiplas etapas, que começa com uma carga maliciosa meticulosamente injetada em pacotes populares do npm. Os atacantes inocularam o malware em um número significativo de pacotes, provavelmente usando tokens npm que haviam sido roubados anteriormente no ataque s1ngularity/Nx. A prova disso vem dos metadados de usuário nos arquivos dos 49 pacotes iniciais, que continham a assinatura digital reveladora de uma distribuição Kali Linux — uma ferramenta frequentemente usada por profissionais de segurança e atores de ameaças, não por desenvolvedores comuns.

Em essência, o malware é um arquivo JavaScript sofisticado e minificado chamado bundle.js, que geralmente tem mais de 3 MB. Este arquivo não é um script simples; é um mecanismo modular de várias etapas que utiliza chunks do Webpack para organizar suas diversas funções. Ele é executado automaticamente após a instalação de um pacote comprometido, normalmente por meio de um script postinstall sequestrado e incorporado ao arquivo package.json do pacote. Os atacantes baixavam o arquivo tarball de um pacote, injetavam seu script malicioso, reempacotavam o arquivo e o republicavam como uma nova versão. Esse processo é tão sutil que os usuários podem facilmente instalar uma versão comprometida sem notar nada de errado.

Script postinstall adicionado ao package.json. (Fonte da imagem.)

Uma vez executado na máquina da vítima, o design modular do malware entra em ação. As principais funcionalidades da carga útil incluem:

• Reconhecimento de sistema e credenciais: O malware primeiro realiza um reconhecimento do sistema host e coleta um perfil, incluindo o sistema operacional e a arquitetura. Em seguida, ele esvazia todo o process.env, capturando uma ampla gama de variáveis de ambiente sensíveis, como GITHUB_TOKEN, NPM_TOKEN, AWS_ACCESS_KEY_ID e AWS_SECRET_ACCESS_KEY.

• Coleta direcionada de credenciais da nuvem: Shai-Hulud visa especificamente as credenciais de grandes provedores de serviços em nuvem. Usando seus próprios SDKs (kits de desenvolvimento de software) embutidos na nuvem e wrappers de API, ele tenta enumerar e acessar segredos de serviços como AWS Secrets Manager e Google Cloud Platform (GCP) Secret Manager. Ele pode até mesmo sondar endpoints de metadados da nuvem para capturar credenciais IAM (gerenciamento de identidades e acessos) efêmeras, que podem conceder privilégios ainda mais altos. O malware é projetado para falhar silenciosamente em erros de permissão, tornando sua atividade ainda mais difícil de detectar.

• Escaneamento de segredos do sistema de arquivos: Para maximizar seu ganho, o malware reutiliza ferramentas de código aberto como TruffleHog, uma ferramenta legítima de escaneamento de segredos. Ele inicia um processo para escanear todo o sistema de arquivos em busca de segredos de alta entropia e arquivos confidenciais, como ~/.aws/credentials ou outros arquivos de configuração que possam conter credenciais codificadas. Esse escaneamento agressivo expande o escopo do roubo de dados muito além das variáveis de ambiente.

É importante notar que o malware foi observado como gerado por IA em algumas variantes, sugerindo que os atores da ameaça podem ter usado ferramentas como Claude, Gemini ou Q para auxiliar na escrita do código malicioso. O design também pressupõe um ambiente de execução Linux ou macOS, pois aparentemente inclui uma verificação para omitir deliberadamente os sistemas Windows.

Persistência, exfiltração e a propagação incessante do ataque

O verdadeiro perigo do ataque Shai-Hulud reside em sua capacidade não apenas de roubar dados, mas também de se replicar e estabelecer persistência. Após coletar credenciais, o verme ou worm as utiliza imediatamente para se propagar ainda mais e garantir acesso contínuo.

Exfiltração de dados via GitHub e Webhooks

Os dados roubados não são enviados para um único local; os atacantes usaram uma estratégia de exfiltração dupla:

• Repositórios públicos do GitHub: O malware usa um token de acesso pessoal (PAT) do GitHub roubado para criar um novo repositório público sob a conta da vítima. Este repositório é tipicamente chamado Shai-Hulud e contém um despejo dos segredos coletados, muitas vezes dentro de um arquivo chamado data.json. Os dados são então duplamente codificados com Base64 para torná-los menos legíveis para observadores casuais. Esse método é particularmente eficaz, pois se mistura com a atividade normal do desenvolvedor e contorna muitos controles de segurança tradicionais. Investigadores de segurança observaram centenas de repositórios como este aparecendo no GitHub, demonstrando a escala e a natureza contínua do ataque.

• Pontos finais de Webhook: O malware também tenta exfiltrar dados para um ponto final de webhook codificado, especificamente hxxps://webhook[.]site/bb8ca5f6-4175-45d2-b042-fc9ebb8170b7. No entanto, devido ao alto volume de atividade, a plataforma de webhook acabou desativando a conta, tornando esse método não funcional. Apesar disso, os segredos ainda estavam sendo expostos nos registros de fluxo de trabalho no GitHub, o que forneceu uma nova via para os atacantes acessarem dados sensíveis.

O mecanismo de autorreplicação

Com um token npm válido em mãos, o malware se torna um verdadeiro worm. Ele aproveita a função NpmModule.updatePackage para consultar o registro npm em busca de outros pacotes pertencentes ao mantenedor comprometido, podendo recuperar até 20 pacotes por vez. O worm então cria e publica automaticamente novas versões maliciosas de cada um desses pacotes. Isso é feito injetando o script malicioso bundle.js e adicionando um comando postinstall ao arquivo package.json. Este processo automatizado cria um efeito em cascata, onde cada pacote infectado serve como um novo vetor de distribuição, infectando novos hosts e roubando suas credenciais para repetir o ciclo. Este "comprometimento em cascata" transforma uma única brecha bem-sucedida em uma ameaça exponencial que se propaga na velocidade dos pipelines de CI/CD.

Estabelecendo persistência

Além do roubo imediato de dados, o malware trabalha para estabelecer persistência de longo prazo. Ele usa um PAT do GitHub roubado para injetar um novo fluxo de trabalho do GitHub Actions, frequentemente chamado shai-hulud-workflow.yml, em todos os repositórios acessíveis. Este fluxo de trabalho é projetado para ser acionado em eventos de push e exfiltrar mais segredos do próprio pipeline de CI/CD usando a expressão ${{ toJSON(secrets) }}.

Além disso, o worm exibe outro comportamento malicioso, que lembra o ataque s1ngularity: a "migração" de repositórios privados. O malware usa um script para clonar repositórios privados e republicá-los como repositórios públicos sob um usuário controlado pelo atacante. Estes novos repositórios públicos são nomeados com um sufixo -migration e a descrição "Shai-Hulud Migration". Essa tática é provavelmente uma tentativa de obter acesso a segredos que estão codificados no código-fonte ou simplesmente de roubar código proprietário. O malware cria o repositório como privado e imediatamente muda sua visibilidade para pública, deixando dois eventos observáveis nos registros de auditoria do GitHub: um CreateEvent seguido por um PublicEvent. Uma busca por esses repositórios no GitHub rendeu cerca de 700 resultados, indicando a escala massiva desta faceta particular do ataque.

O vínculo com o ataque s1ngularity/Nx: uma trilogia perigosa

O ataque Shai-Hulud está profundamente interligado com o ataque à cadeia de suprimentos s1ngularity, que visou o amplamente utilizado pacote de sistema de construção Nx, no final de agosto de 2025. Compreender o ataque s1ngularity fornece um contexto crucial para Shai-Hulud.

No ataque s1ngularity, os atores da ameaça comprometeram o repositório nrwl/nx explorando um fluxo de trabalho defeituoso do GitHub Actions. O fluxo de trabalho, que se destinava a validar solicitações de pull, foi executado com permissões elevadas e era vulnerável à injeção de código por meio de títulos de solicitação de pull não higienizados. Isso permitiu que os atacantes executassem comandos arbitrários, exfiltrassem o token npm da equipe para um webhook e publicassem versões maliciosas do pacote Nx.

O malware s1ngularity também era uma carga útil de coleta de dados, mas tinha suas próprias características únicas:

• Carga útil do malware: Usava um arquivo malicioso telemetry.js acionado por um script postinstall. A carga útil visava especificamente sistemas Linux e macOS e procurava arquivos confidenciais, incluindo carteiras de criptomoedas, chaves SSH e arquivos .env.

• Reconhecimento impulsionado por IA: O malware notavelmente aproveitou ferramentas de linha de comando de IA como Claude, Gemini e Q, solicitando-lhes com sinalizadores perigosos (--dangerously-skip-permissions, --yolo) para auxiliar no reconhecimento e roubar o conteúdo do sistema de arquivos. Essa foi uma abordagem nova na época.

• Exfiltração: Os dados roubados foram codificados dupla e triplamente com Base64 e enviados para repositórios de vítimas controlados pelo atacante, de acesso público, chamados s1ngularity-repository.

• Persistência: O malware tentou alcançar persistência e um efeito de negação de serviço adicionando sudo shutdown -h 0 aos arquivos ~/.bashrc e ~/.zshrc do usuário.

• Exposição de repositórios: Uma segunda fase do ataque s1ngularity envolveu o uso dos tokens do GitHub roubados para tornar repositórios privados públicos e renomeá-los para um padrão como s1ngularity-repository-#5letras#. Mais de 5.500 repositórios privados de mais de 400 usuários foram afetados.

A sobreposição funcional entre as duas campanhas é significativa. Ambos os ataques:

• Visaram pacotes populares de código aberto com milhões de downloads semanais.

• Focaram na coleta de variáveis de ambiente e informações secretas.

• Aproveitaram contas do GitHub de propriedade do usuário para a exfiltração de dados.

• Expuseram repositórios privados tornando-os públicos.

No entanto, Shai-Hulud representa uma escalada. Como observou um investigador de segurança, os atacantes por trás de Shai-Hulud provavelmente estavam sentados nas credenciais roubadas do ataque s1ngularity, esperando o momento oportuno para lançar uma nova campanha, mais automatizada. O fato de que Shai-Hulud inclui um mecanismo de autorreplicação — que não estava presente no s1ngularity — é o que o torna uma ameaça muito mais perigosa. A natureza consistente e refinada desses ataques demonstra que os atores da ameaça estão aprendendo e se adaptando, usando cada comprometimento bem-sucedido como um modelo para o próximo. As chaves do reino foram vazadas, e como o mesmo pesquisador expressou acertadamente, este pode ser apenas o começo de uma trilogia.

O escopo do ataque: pacotes, usuários e o ecossistema em geral

O ataque Shai-Hulud afetou uma ampla gama de pacotes e desenvolvedores, desde mantenedores de alto perfil até estudantes e líderes técnicos. O grande número de pacotes envolvidos, juntamente com a natureza de autorreplicação do worm, criou uma superfície de ataque massiva que é difícil de quantificar completamente.

Alguns dos pacotes mais populares afetados incluíram:

• @ctrl/tinycolor (com mais de 2,2 milhões de downloads semanais)

• ngx-bootstrap (com mais de 309 mil downloads semanais)

• ng2-file-upload (com mais de 94 mil downloads semanais)

O ataque também comprometeu múltiplos pacotes pertencentes à conta npm @crowdstrike, publicados por crowdstrike-publisher. Isso demonstra que o verme não se limitou a desenvolvedores individuais, mas também pôde infectar pacotes de propriedade de importantes fornecedores de segurança.

A lista de pacotes comprometidos e suas versões é extensa. Para ajudar desenvolvedores e organizações a identificar se foram afetados, compilamos uma tabela completa de todos os pacotes afetados conhecidos e as versões maliciosas que foram publicadas.

O impacto deste ataque é significativo. Além do roubo imediato de segredos, que pode levar a roubo de dados, criptomineração ou a exclusão de ambientes de produção, a natureza de autorreplicação do ataque deixa um rastro de contas comprometidas e código-fonte potencialmente exposto. Uma empresa de segurança analisou os dados vazados e encontrou um total de 278 segredos, com 90 coletados de sistemas locais e 188 de fluxos de trabalho maliciosos. Os segredos mais vazados foram tokens do GitHub, tokens do npm e chaves AWS, o que destaca os principais alvos da campanha.

O que desenvolvedores e organizações podem fazer: algumas recomendações

O ataque Shai-Hulud é um alerta para todo o ecossistema de código aberto. O incidente demonstra que o risco da cadeia de suprimentos de software não se trata mais apenas de vulnerabilidades no código, mas também de identidades comprometidas e automação confiável. Dado que o malware se propaga na velocidade do CI/CD, deixando muito pouco tempo para detecção e remediação, uma defesa forte e proativa é crucial.

Aqui estão recomendações práticas para mitigar o risco deste ataque e ameaças semelhantes:

Contenção e remediação imediatas

• Remover pacotes maliciosos: Em primeiro lugar, audite as dependências do seu projeto e remova ou faça o downgrade de qualquer pacote afetado. Você pode usar ferramentas como npm audit para identificar versões vulneráveis. Após remover os pacotes, limpe seu cache executando npm cache clean --force e depois reinstale uma versão limpa e conhecida como boa.

• Assumir o comprometimento e rotacionar credenciais: Qualquer máquina ou runner de CI que tenha instalado um pacote afetado deve ser considerado totalmente comprometido. Você deve revogar e regenerar imediatamente todas as credenciais potencialmente expostas, incluindo tokens npm, PATs do GitHub, chaves SSH e todas as chaves de API na nuvem.

• Auditar contas e logs do GitHub: Revise sua conta do GitHub em busca de qualquer atividade suspeita. Procure por:

  • Repositórios públicos recém-criados chamados "Shai-Hulud".

  • Repositórios privados que de repente se tornaram públicos e têm a descrição "Shai-Hulud Migration" com um sufixo -migration.

  • Novas branches chamadas "shai-hulud".

  • Commits inesperados ou modificações nos arquivos de fluxo de trabalho do GitHub Actions, procurando especificamente por shai-hulud.yml ou shai-hulud-workflow.yml.

Fortalecimento da segurança a longo prazo

• Aplicar autenticação forte: Exija o uso de autenticação multifatorial (MFA) em todas as plataformas de desenvolvimento críticas, incluindo GitHub e npm. Sempre que possível, use chaves de segurança de hardware para o mais alto nível de proteção.

• Implementar o princípio do privilégio mínimo: Limite o escopo dos seus tokens. Use tokens de curta duração e escopo restrito que tenham apenas as permissões necessárias para sua tarefa específica. Por exemplo, um token usado para CI/CD não deve ter amplos direitos administrativos ou de publicação se não for estritamente necessário.

• Fortalecer os pipelines de CI/CD: Trate seus ambientes de construção como alvos potenciais. Use runners efêmeros que são destruídos após cada construção para evitar que o malware estabeleça persistência. Restrinja as conexões de rede de saída dos seus pipelines de construção apenas para os domínios necessários.

• Fixar dependências e monitorar anomalias: Em vez de permitir atualizações automáticas ou flutuantes (^ ou ~), fixe todas as dependências em uma versão específica e conhecida como boa no seu arquivo package.json ou package-lock.json. Isso evita que uma construção automatizada puxe, sem saber, uma versão recém-comprometida. Monitore continuamente os logs em busca de eventos incomuns de npm publish ou processos filhos inesperados, o que poderia indicar que um script malicioso está em execução.

• Usar soluções de segurança avançadas: O aumento desses ataques sofisticados, que exploram identidades e automação confiável, exige uma nova abordagem de segurança. Soluções que oferecem análise de composição de software (SCA) e a lista de materiais de software (SBOM) podem ajudá-lo a rastrear e gerenciar continuamente suas dependências, identificar pacotes vulneráveis e bloquear os maliciosos. Essas ferramentas ajudam você a ver o que está no seu software e a interromper mudanças arriscadas antes que entrem no seu pipeline. Na Fluid Attacks, nossa solução completa de Hacking Contínuo inclui AST automatizado e PTaaS, e também fornecemos SCA, incluindo SBOM, para ajudar as empresas a rastrear e gerenciar continuamente suas dependências, identificar vulnerabilidades e proteger de forma proativa sua cadeia de suprimentos de software. Convidamos você a iniciar agora mesmo nosso teste gratuito de 21 dias.

Os clientes da Fluid Attacks podem determinar rapidamente se seus aplicativos estão expostos a esses pacotes vulneráveis. Basta ir para a seção Inventory e filtrar a tabela de Packages por nome do componente:

Conclusão: um ponto de virada para a segurança da cadeia de suprimentos

O ataque Shai-Hulud é um momento decisivo para a segurança da cadeia de suprimentos de software. Ele significa uma mudança de comprometimentos isolados e pontuais para ameaças automatizadas, escaláveis e que se autorreplicam. Esta nova geração de ataques, que aproveita credenciais roubadas para alimentar uma propagação viral, deixa as organizações com pouca ou nenhuma margem para detecção e remediação lentas.

Este incidente com pacotes npm, assim como o ataque de esvaziamento de carteiras que o precedeu, sublinha uma verdade crítica: Todo o nosso ecossistema digital depende da segurança da cadeia de suprimentos de código aberto. A resposta rápida dos investigadores de segurança e da comunidade de desenvolvedores neste caso é um testemunho do espírito de colaboração que sustenta o software de código aberto. No entanto, também destaca a necessidade urgente de as organizações irem além dos modelos de segurança tradicionais e adotarem uma abordagem proativa e contínua para proteger sua cadeia de suprimentos de software. Ao implementar práticas de segurança robustas, aproveitar ferramentas modernas e permanecer vigilantes, podemos enfrentar coletivamente este desafio crescente e proteger nosso futuro digital compartilhado.