Todo mundo adora uma continuação, não é? Desde segunda-feira, 24 de novembro, a comunidade de desenvolvimento de software tem lidado com a notícia de que o verme Shai-Hulud retornou, e foi atualizado para a versão 2.0. A comunidade está em modo de resposta, e a Elastic não é exceção. Embora os produtos da Elastic não sejam enviados com o Node Package Manager (npm), nosso software, como muitos outros, utiliza o npm para obter pacotes do npmjs.com durante as compilações.

Neste blog, abordaremos as etapas que a Elastic tomou para monitorar e implementar medidas para mitigar a ameaça representada pelo número cada vez maior de pacotes comprometidos. Também compartilharemos nossas regras de prevenção e detecção, consultas de caça e recomendações alinhadas com essa nova versão do Shai-Hulud. 

Compreendendo a ameaça evoluída: Shai-Hulud 2.0

A enorme escala do ecossistema npm o torna um alvo privilegiado para atividades maliciosas. Em novembro de 2025, uma nova variante do worm malicioso npm, conhecida como Shai-Hulud: The Second Coming (devido ao marcador de campanha usado nas descrições dos repositórios do GitHub), surgiu após o ataque inicial de setembro de 2025 e está vazando dados ativamente. Ela comprometeu centenas de pacotes, incluindo projetos populares da AsyncAPI, Zapier, PostHog e Postman.

A semelhança com a variante inicial reside no fato de que os pacotes npm são infectados com malware autorreplicante. No entanto, o Shai-Hulud 2.0 difere da sua primeira versão por instalar o bun com o arquivo setup_bun.js e, em seguida, utilizá-lo para executar o arquivo bun_environment.js, que contém o código malicioso. Ele então exfiltra os dados roubados criando repositórios no GitHub com nomes aleatórios, frequentemente publicando os dados de uma vítima em um repositório associado a outra vítima não relacionada, um processo conhecido como "exfiltração entre vítimas". Os repositórios do GitHub recém-criados têm a descrição Sha1-Hulud: The Second Coming

No fim das contas, isso significa que simplesmente pesquisar nos seus próprios repositórios pode não revelar dados vazados dos seus ambientes. Além disso, o Shai-Hulud não se limita mais a infectar 20 pacotes npm; agora ele infecta até 100 pacotes npm e apaga o diretório pessoal do usuário se não conseguir autenticar usando credenciais do GitHub ou npm.

Resposta da Elastic

Utilizando as lições e mecanismos implementados após o incidente inicial Shai-Hulud, a Elastic conseguiu implantar defesas imediatas e abrangentes.

  • Inventário de dependências: a Elastic escaneia continuamente nossos produtos usando ferramentas de análise de composição de software (SCA), que nos permitiram entender rapidamente quais pacotes estão sendo usados e onde.

  • Inteligência de ameaças: utilizamos diversas fontes de inteligência de ameaças para verificar a crescente lista de pacotes maliciosos em nosso inventário de dependências e acionar alertas.

  • Prática recomendada e restrições do npmjs: desde o Shai-Hulud 1 em setembro, as equipes da Elastic têm migrado para o Trusted Publisher, permitindo que continuem publicando; quaisquer tokens restantes foram revogados, evitando a publicação com um token de longa duração.

  • Idade mínima da dependência: implementamos uma idade mínima de lançamento de pacotes (período de espera) em nossa automação, garantindo que novas versões de pacotes não sejam baixadas automaticamente até que estejam disponíveis por 14 dias.

  • Implementar varredura de endpoints: usando a integração do OSQuery para o Elastic Agent, implementamos varredura contínua para os pacotes npm conhecidos e comprometidos instalados em laptops Elastic.  

  • Execute regras de detecção prontas para uso (OOTB): o Elastic Security Labs já fornece regras de detecção prontas para uso do Elastic Security para auxiliar na identificação de sistemas que instalaram e estão executando um pacote comprometido. Incluímos mais detalhes sobre as proteções listadas abaixo, que você pode usar para sua própria busca por ameaças.

  • Avise os desenvolvedores da Elastic: avisos foram enviados aos desenvolvedores da Elastic, notificando-os sobre a investigação em andamento e proibindo a atualização ou instalação de novos pacotes npm.

A segunda vinda chega mais perto

Por meio de nosso parceiro, Entro, a Elastic foi informada de que um pipeline de integração contínua (CI) da Elastic havia executado o malware Shai-Hulud 2.0 e publicado dados em um repositório público do GitHub. Esse pipeline é usado para GitOps, especificamente um orquestrador para Elastic Cloud. Não houve impacto resultante nos sistemas Elastic Cloud ou nos clientes da Elastic. Foi descoberto que o culpado era uma dependência transitiva. Nossa resposta rápida e coordenação com nossas equipes de engenharia garantiram que contivemos e remediamos a ameaça antes de uma possível exploração.

Contenção rápida e remediação

  • Removemos a dependência de open source que continha o malware de todos os repositórios do GitHub da Elastic identificados

  • Pipelines ou processos manuais identificados onde o malware é executado

  • Execuções de CI identificadas e usuários afetados

  • Segredos identificados disponíveis para essas execuções

  • Rotacionou todos os segredos (não efêmeros)

Confirmado que não houve impacto no cliente

  • O GitHub rapidamente excluiu o repositório que expunha os dados extraídos pelo Elastic, que incluía quatro arquivos:

    • cloud.json sem dados

    • contents.json contendo detalhes sobre um runner de CI, bem como um usuário do GitHub não relacionado e o token do GitHub desse usuário não relacionado

    • truffleSecrets.json contendo achados secretos falsos positivos

    • O arquivo environment.json contém variáveis de ambiente associadas a um executor de CI, incluindo segredos usados na compilação. Observação: a Elastic garantiu que esses segredos fossem revogados.

  • Não há evidências de que segredos Elastic tenham sido usados fora da Elastic.

  • Não há evidências de que o worm tenha se espalhado para um pacote npm da Elastic.

  • O pipeline não está associado a um produto da Elastic.

  • Não há impacto para os clientes da Elastic.

Consultas de caça

Também recomendamos que clientes do Elastic Security busquem possíveis comprometimentos em seus próprios ambientes. As seguintes consultas KQL podem ser usadas para identificar comportamentos associados a esse comprometimento da cadeia de suprimentos:

// IOC for the Github Self-Hosted Actions runner name
process.name:Runner.Listener and process.command_line:*SHA1HULUD*

// IOC - node/bun executing bun_environment.js
process.name:(node or bun) and process.args:*bun_environment.js

// credentials discovery using trufflehog from node/bun or node_modules related working directory 
process.name:("trufflehog" or "trufflehog.exe") and process.args:"filesystem" and process.args:"--json" and (process.parent.name : (node or bun or node.exe or bun.exe) or process.working_directory:*node_modules*)

// curl used to download GH actions runner to victim machine
process.name:(curl or or curl.exe or powershell.exe or wget or wget.exe) and process.command_line:*github.com/actions/runner/releases/download*

//docker escape via mounting the host file system and executing bash commands to tamper with the host file system
process.name:docker and process.args :("--privileged" and run) and process.args :"-v" and process.args :/\:/*  and  process.args :(bash or sh or cp)

Exemplo de correspondências:

Detecções OOTB da Elastic

As seguintes regras de detecção e prevenção prontas para uso também fornecem cobertura atualizada para as atividades do Shai-Hulud Worm 2.0:

Compromisso com a segurança

A segurança é fundamental para o ciclo de vida de desenvolvimento e os processos operacionais da Elastic. O novo Shai-Hulud Worm destaca a natureza persistente e em rápida evolução das ameaças cibernéticas às cadeias globais de suprimentos de software. O incidente em nosso ambiente demonstra a eficácia de nossas equipes de segurança e a importância de uma resposta rápida. Continuamos comprometidos com:

  • Monitoramento contínuo: mantemos monitoramento constante de nossos sistemas e redes, 24 horas por dia, 7 dias por semana, em busca de quaisquer sinais de comprometimento.

  • Resposta rápida: garantir que nossas equipes de segurança estejam preparadas para responder de forma rápida e eficaz a novas ameaças.

  • Transparência: comunicamos abertamente com nossos usuários e comunidade sobre incidentes de segurança e nossos esforços de mitigação.

Continuaremos monitorando novas informações. E à medida que aprendermos mais sobre esse evento, atualizaremos esta publicação. Para mais informações sobre como a Elastic pode ajudar a proteger seu ambiente, visite nossa página de soluções de segurança.

O lançamento e o tempo de amadurecimento de todos os recursos ou funcionalidades descritos neste artigo permanecem a exclusivo critério da Elastic. Os recursos ou funcionalidades não disponíveis no momento poderão não ser entregues ou não chegarem no prazo previsto.