De Umgang mit dem Shai-Hulud-Wurm 2.0: Die aktualisierte Reaktion von Elastic auf die Kompromittierung der npm-Lieferkette.

Fortsetzungen sind doch immer beliebt, oder? Seit Montag, dem 24. November, beschäftigt die Softwareentwickler-Community die Nachricht, dass der Shai-Hulud-Wurm zurückgekehrt und auf Version 2.0 aktualisiert wurde. Die Community ist in Reaktion, und Elastic bildet da keine Ausnahme. Obwohl Elastic-Produkte nicht standardmäßig mit dem Node Package Manager (npm) versenden, nutzt unsere Software – wie viele andere auch – npm, um Pakete  während des Build-Prozesses von der Paketregistrierungnpmjs.com abzurufen.

In diesem Blogbeitrag erläutern wir die Schritte, die Elastic unternommen hat, um die Bedrohung durch die stetig wachsende Zahl kompromittierter Pakete zu überwachen und entsprechende Maßnahmen zu deren Minderung zu ergreifen. Wir werden außerdem unsere Präventions- und Erkennungsregeln, Suchabfragen und Empfehlungen im Einklang mit dieser neuen Version von Shai-Hulud teilen. 

So tickt die weiterentwickelte Bedrohung: Shai-Hulud 2.0

Die schiere Größe des npm-Ökosystems macht es zu einem bevorzugten Ziel für Cyberangriffe. Im November 2025 tauchte nach dem ersten Angriff im September 2025, eine neue Variante des bösartigen npm-Wurms auf, die aufgrund der in den GitHub-Repository-Beschreibungen verwendeten Kampagnenmarkierung alsShai-Hulud: The Second Coming bezeichnet wird und aktiv Daten abgreift. Sie hat Hunderte von Paketen kompromittiert, darunter beliebte Projekte von AsyncAPI, Zapier, PostHog und Postman.

Die Ähnlichkeit zur ursprünglichen Variante besteht darin, dass npm-Pakete mit selbstreplizierender Malware infiziert sind. Shai-Hulud 2.0 unterscheidet sich jedoch von seiner ersten Version dadurch, dass es bun mit der Datei setup_bun.js, installiert und diese dann verwendet, um bun_environment.js auszuführen, die den bösartigen Code enthält. Anschließend exfiltriert es gestohlene Daten, indem es zufällig benannte GitHub-Repositories erstellt und oft die Daten eines Opfers in einem Repository veröffentlicht, das mit einem separaten, nicht verbundenen Opfer verbunden ist, bekannt als „Cross-Victim Exfiltration“. Die neu erstellten GitHub-Repositories tragen die Beschreibung Shai-Hulud: The Second Coming.

Letztlich bedeutet das, dass das einfache Durchsuchen Ihrer eigenen Repositorys möglicherweise keine Daten aufdeckt, die aus Ihren Umgebungen durchgesickert sind. Darüber hinaus ist Shai-Hulud nicht mehr auf die Infektion von 20 npm-Paketen beschränkt; es infiziert nun bis zu 100 npm-Pakete und löscht das Home-Verzeichnis des Nutzers, wenn es sich nicht mit GitHub- oder npm-Anmeldeinformationen authentifizieren kann.

Die Reaktion von Elastic

Mithilfe der Erkenntnisse und Mechanismen, die nach dem ersten Shai-Hulud-Vorfall eingeführt wurden, war Elastic in der Lage, sofortige und umfassende Abwehrmaßnahmen bereitzustellen.

  • Abhängigkeitsinventar: Elastic scannt unsere Produkte kontinuierlich mit Software-Kompositionsanalyse (SCA)-Tools, die es uns ermöglichen, schnell zu verstehen, welche Pakete verwendet werden und wo.

  • Threat-Intelligence: Wir nutzen mehrere Threat-Intelligence-Feeds, um die wachsende Liste schädlicher Pakete mit unserem Abhängigkeitsinventar abzugleichen und Warnmeldungen auszulösen.

  • npmjs Best Practices und Einschränkungen: Seit Shai-Hulud 1 im September stellen die Elastic-Teams auf Trusted Publisher um, wodurch es diesen weiterhin möglich ist, Inhalte zu veröffentlichen; alle verbleibenden Token wurden widerrufen, wodurch die Möglichkeit, mit einem langlebigen Token zu veröffentlichen, unterbunden wird.

  • Mindestalter für Abhängigkeit: Wir haben in unserer Automatisierung ein Mindestalter für die Paketfreigabe (Abklingzeit) eingeführt, um sicherzustellen, dass neue Paketversionen erst automatisch abgerufen werden, wenn sie seit 14 Tagen verfügbar sind.

  • Endpoint-Scan implementierung: Mit der OSQuery-Integration für Elastic Agent haben wir eine kontinuierliche Überwachung der bekannten kompromittierten npm-Pakete auf Elastic-Laptops implementiert.  

  • Standard-Erkennungsregeln (Out-of-the-Box, OOTB): Elastic Security Labs stellt bereits Standard-Erkennungsregeln für Elastic Security bereit, um Systeme zu identifizieren, die ein kompromittiertes Paket installiert haben und ausführen. Nachfolgend finden Sie weitere Details zu den Schutzmaßnahmen, die Sie für Ihre eigene Bedrohungssuche verwenden können.

  • Benachrichtigung an Elastic-Entwickler Es wurden Empfehlungen an Elastic-Entwickler gesendet, die sie über die laufende Untersuchung informieren und die Aktualisierung oder Installation neuer npm-Pakete untersagen.

Die zweite Wiederholung ist treffsicher

Durch unseren Partner Entro wurde Elastic darauf aufmerksam gemacht, dass eine Continuous-Integration-Pipeline (CI) von Elastic die Malware Shai-Hulud 2.0 ausgeführt und Daten in einem öffentlichen GitHub-Repository veröffentlicht hatte. Diese Pipeline wird für GitOps verwendet, speziell als Orchestrator für Elastic Cloud. Es gab keine Auswirkungen auf Elastic Cloud-Systeme oder Elastic-Kunden. Es stellte sich heraus, dass die Ursache eine transitive Abhängigkeit war. Durch unsere schnelle Reaktion und die enge Abstimmung mit unseren Ingenieurteams konnten wir die Bedrohung eindämmen und beheben, bevor sie möglicherweise ausgenutzt werden konnte.

Schnelle Eindämmung und Sanierung

  • Die Open-Source-Abhängigkeit, die die Malware enthielt, wurde aus allen identifizierten Elastic GitHub-Repos entfernt.

  • Identifizierte Pipelines oder manuelle Prozesse, in denen die Schadsoftware ausgeführt werden würde

  • Identifizierte CI-Läufe und betroffene Nutzer

  • Identifizierte Geheimnisse, die diesen Läufen zur Verfügung stehen.

  • Alle Geheimnisse rotiert (nicht kurzlebig)

Es wurde bestätigt, dass es keine Auswirkungen auf die Kunden gibt.

  • GitHub hat das Repository, das die von Elastic extrahierten Daten offenlegte und vier Dateien enthielt, schnell gelöscht:

    • cloud.json ohne Daten

    • contents.json enthält Details über einen CI-Runner sowie einen nicht verwandten GitHub-Nutzer und dessen GitHub-Token

    • Die Datei truffleSecrets.json enthält irrtümlich positive Geheimbefunde.

    • environment.json enthält Umgebungsvariablen, die mit einem CI-Runner verbunden sind, einschließlich Geheimnisse, die im Build verwendet werden. Hinweis: Elastic sorgte dafür, dass diese Geheimnisse widerrufen wurden.

  • Es gibt keine Beweise dafür, dass Elastic-Secrets jemals außerhalb von Elastic verwendet wurden.

  • Es gibt keine Hinweise darauf, dass sich der Wurm auf ein npm-Paket auf Elastic ausgebreitet hat.

  • Die Pipeline ist nicht mit einem Elastic-Produkt verknüpft.

  • Es gibt keine Auswirkungen auf die Elastic-Kunden.

Suchabfragen

Wir empfehlen Kunden von Elastic Security auch, in ihren eigenen Umgebungen nach potenziellen Kompromittierungen zu suchen. Die folgenden KQL-Abfragen können verwendet werden, um Verhaltensweisen zu identifizieren, die mit dieser Kompromittierung der Lieferkette in Zusammenhang stehen:

// 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)

Beispiel für Übereinstimmungen:

OOTB Elastic-Erkennungen

Die folgenden sofort einsatzbereiten Erkennungs- und Präventionsregeln bieten auch einen aktualisierten Schutz für die Aktivitäten des Shai-Hulud-Wurms 2.0:

Unser Bekenntnis zur Sicherheit

Sicherheit ist grundlegend für den Entwicklungszyklus und die operativen Prozesse von Elastic. Der neue Shai-Hulud-Wurm unterstreicht die anhaltende und sich rasant entwickelnde Natur von Cyberbedrohungen für globale Software-Lieferketten. Der Vorfall in unserer Umgebung zeigt die Wirksamkeit unserer Sicherheitsteams und die Bedeutung einer schnellen Reaktion. Wir setzen uns weiterhin für Folgendes ein:

  • Kontinuierliche Überwachung: Überwachen unserer Systeme und Netzwerke rund um die Uhr auf Anzeichen einer Kompromittierung.

  • Schnelle Reaktion: Sicherstellen, dass unsere Sicherheitsteams darauf vorbereitet sind, schnell und effektiv auf neue Bedrohungen zu reagieren.

  • Transparenz: Offene Kommunikation mit unseren Nutzern und der Community über Sicherheitsvorfälle und unsere Maßnahmen zur Minderung.

Wir werden die weiteren Entwicklungen beobachten. Sobald wir mehr über dieses Ereignis erfahren, werden wir diese Veröffentlichung aktualisieren. Für weitere Informationen darüber, wie Elastic Ihre Umgebung sichern kann, besuchen Sie bitte unsere Seite für Sicherheitslösungen.

Die Entscheidung über die Veröffentlichung der in diesem Blogeintrag beschriebenen Leistungsmerkmale und Features sowie deren Zeitpunkt liegt allein bei Elastic. Es ist möglich, dass noch nicht verfügbare Leistungsmerkmale oder Features nicht rechtzeitig oder überhaupt nicht veröffentlicht werden.