Die Folgen von Shai-Hulud 2 und was man anders hätte machen können

Der Shai-Hulud 2.0 npm-Wurm ist einer jener Vorfälle, auf die AppSec-Teams noch jahrelang in Nachbesprechungen Bezug nehmen werden.

Lassen Sie uns analysieren, was passiert ist, wer betroffen war und wie eine SSCS-Plattform wie ScribeHub hätte Organisationen helfen können, den Explosionsradius zu verhindern oder zumindest drastisch zu begrenzen.

1. Was ist Shai-Hulud 2.0?

Shai-Hulud erschien erstmals im September 2025 als Selbstreplizierender Wurm, der das npm-Ökosystem angreiftDabei werden Hunderte von JavaScript-Paketen kompromittiert und die Schadsoftware über gestohlene Zugangsdaten und automatisierte Wiederveröffentlichung verbreitet. 

Nur ein paar Monate später begannen Forscher, Folgendes zu beobachten: weitaus aggressivere und automatisierte Folgewelle, heute allgemein als bezeichnet „Shai-Hulud 2.0“, „Sha1-Hulud 2.0“ oder „Die zweite Ankunft“. 

Hauptmerkmale von Shai-Hulud 2.0:

• Fokus auf die Lieferkette. Statt ein einzelnes Unternehmen anzugreifen, greift es an vertrauenswürdige npm-Pakete und in späteren Varianten sogar Java-Ökosysteme (Maven), wodurch Bausteine ​​vergiftet werden, die in Tausenden von Projekten verwendet werden.
• Selbstvermehrender Wurm. Sobald ein Wartungssystem kompromittiert ist, öffnet es automatisch Hintertüren. alle Die Pakete dieses Maintainers werden erneut veröffentlicht, wodurch eine exponentielle Verbreitung über Abhängigkeitsgraphen hinweg ermöglicht wird.
• Geheimnisse stehlender Infostealer. Die Payload sammelt aggressiv Umgebungsvariablen, GitHub- und npm-Tokens, Cloud-Zugangsdaten und CI/CD-Geheimnisse von Entwicklerrechnern und Build-Pipelines. 
• Zerstörerischer „Totmannschalter“. Wenn die Schadsoftware ihren C2-Server nicht erreichen kann oder sich nicht verbreiten kann, versuchen einige Varianten, das Home-Verzeichnis des Benutzers zu löschen, wodurch eine Kompromittierung der Lieferkette zu einem potenziell zerstörerischen Vorfall wird.

2. Wie der Angriff ablief – Schritt für Schritt

Verschiedene Anbieter verwendeten leicht unterschiedliche Tools und Skripte, aber die allgemeine Angriffskette sieht in etwa so aus:

2.1 Erster Zugriff: Kompromittierte Benutzerkonten

Angreifer:

1. Kompromittierte npm-/GitHub-Maintainer-Konten Verwendung zuvor gestohlener Token, Phishing, Wiederverwendung von Passwörtern oder schwache MFA.
2. Ich habe diese Konten zum Veröffentlichen verwendet. Trojanisierte Versionen legitimer Pakete – oft nur mit einem Versionssprung auf Patch-Ebene, sodass sie sich in die normalen Update-Muster einfügten.

Da die Pakete von den rechtmäßigen Entwicklern signiert/veröffentlicht wurden, erschienen sie den nachfolgenden Nutzern vertrauenswürdig.

2.2 Infektion über npm install / CI-Pipeline

Organisationen haben diese Pakete zurückgezogen:

• über normale npm installieren in der lokalen Entwicklung
• oder indirekt in CI / CD-Pipelines als Teil automatisierter Builds.

Die schädlichen Pakete nutzten typischerweise npm-Lebenszyklusskripte (Vorinstallation, installieren, Nachinstallation) als Ausführungsvektoren, Herunterladen und Ausführen einer Nutzlast der zweiten Stufe wie z. B. Bundle.js, setup_bun.jsoder ähnliche große verschleierte Dateien. 

2.3 Diebstahl von Zugangsdaten und Umgebungsanalyse

Nach dem Start wird die Nutzlast wie folgt verarbeitet:

• Aufgezählte Umgebungsvariablen und lokale Konfigurationsdateien.
• Geerntet Cloud-Zugangsdaten, GitHub/GitLab-Tokens, npm-Zugriffstokens, SSH-Schlüssel und andere Geheimnisse.
• Gelegentlich verwendete Werkzeuge wie TruffleHog-ähnliches Scannen um Repositories nach Geheimnissen zu durchsuchen.

Diese Anmeldeinformationen waren dann exfiltriert in vom Angreifer kontrollierte GitHub-Repositories oder andere C2-Infrastrukturen, die oft so benannt werden, dass sie nicht auffallen (z. B. „Shai-Hulud“-Repositories, die mit gestohlenen Umgebungsdumps gefüllt sind). 

2.4 Laterale Bewegung innerhalb von Entwickler-Ökosystemen

Mithilfe der gestohlenen Tokens wurde die Schadsoftware wie folgt vorgegangen:

• Alle npm-Pakete wurden mit einer Hintertür versehen Die von den kompromittierten Betreibern verwalteten Dateien enthalten dieselben schädlichen Skripte, die eingeschleust und erneut veröffentlicht werden.
• Planted bösartige GitHub Actions-Workflows und Hintertüren in den Opfer-Repositories, um die Daten während CI-Läufen persistent zu halten und die Datenexfiltration fortzusetzen.
• In einigen 2.0-Varianten wurde die Funktionalität über npm hinaus erweitert. Maven-Repositorysund demonstriert damit eine echte, ökosystemübergreifende Lieferkettenreichweite. 

Da viele populäre Bibliotheken weit oben in den Abhängigkeitsstrukturen stehen, führt ein Kompromiss von nur wenigen Betreuern zu Folgendem: Zehntausende betroffene Repositories stromabwärts.

3. Ausmaß und Auswirkungen auf die Opfer

Die verschiedenen Sicherheitsanbieter melden leicht unterschiedliche Zahlen, aber in einem Punkt sind sie sich alle einig: Shai-Hulud 2.0 ist riesig.

• Sicherheitsforscher schätzen, dass mehr als 25,000 GitHub-Repositories kombiniert mit einem nachhaltigen Materialprofil. Hunderte bis ca. 700 Pakete wurden in den späteren Wellen betroffen, von denen einige in mehr als ein Viertel der Cloud-/Code-Umgebungen Sie haben gescannt.
• Analysten nennen es einer der sich am schnellsten verbreitenden npm-Lieferkettenangriffe, die jemals gesehen wurdenmit einer Automatisierung, die Kompromisse einging Hunderte von Paketen innerhalb weniger Stunden.
• Zu den prominenten Opfern gehörten Projekte und Pakete von Zapier, ENS Domains, PostHog, Postman, und andere – was bedeutet, dass sowohl SaaS-Anbieter als auch Tausende ihrer Kunden einem potenziellen Risiko ausgesetzt waren.

3.1 Direkte technische Auswirkungen

Für Organisationen, die ein mit einem Trojaner infiziertes Paket heruntergeladen hatten, waren die typischen Folgen:

• Offenlegung von CI/CD-Geheimnissen (Cloud-Provider-Schlüssel, Bereitstellungstoken, Codesignaturzertifikate usw.).
• Heimliche Hintertüren in GitHub-Repos und CI-Aktionen, wodurch Angreifer in zukünftigen Builds beliebige Befehle ausführen können.
• Manipulierte Artefakte: das Risiko für Angreifer, bösartige Logik in entwickelte Anwendungen einzufügen, ohne dass die Entwickler dies bemerken.
• Für einige unglückliche Entwickler, zerstörerische Löschung der $ HOME Verzeichnis als die Ausweichfunktion der Malware aktiviert wurde.

3.2 Auswirkungen auf das Geschäft

Aus geschäftlicher Sicht bedeutet dies:

• Krisenreaktionsereignisse in großem UmfangDie IR-Teams mussten jedes Projekt, das betroffene Pakete verwendete, prüfen, Tokens rotieren und manchmal Deployments einfrieren.
• Regulatorische und vertragliche Risiken: Regulierte Branchen (Finanzwesen, Gesundheitswesen, staatliche Zulieferer) sehen sich nun der Möglichkeit gegenüber, dass regulierte Daten oder kritische Systemzugangsschlüssel über eine Drittanbieter-Software exfiltriert wurden.
• Vertrauensverlust in Open SourceSicherheits- und Entwicklungsleiter sind gezwungen, ihr Vertrauensmodell für öffentliche Register zu überdenken und strengere Kontrollen im Zusammenhang mit dem Abhängigkeitsmanagement in Betracht zu ziehen.

4. Wo traditionelle Verteidigungsstrategien an ihre Grenzen stoßen

Warum konnte Shai-Hulud 2.0 so viele Abwehrreihen durchbrechen?

1. Es handelte sich um einen Vertrauensmissbrauch, nicht um eine einfache Schwachstelle. Die Pakete waren „legitim“ – sie wurden unter echten Maintainernamen veröffentlicht, oft aus bestehenden Repositories.
2. Statische SCA/SAST reichte nicht aus. Selbst wenn Teams über SBOMs und Schwachstellenscanner verfügten, suchten viele von ihnen nicht danach. Verhaltens- Indikatoren wie verdächtige Lebenszyklusskripte oder ausgehende Datenexfiltration während Builds.
3. Geheimnisse und CI/CD waren das eigentliche Ziel. Viele Organisationen haben für CI/CD-Umgebungen schwächere Kontroll- und Überwachungsmechanismen als für Produktionsumgebungen, wodurch diese zu perfekten Zielen werden.
4. Fehlende lückenlose Herkunftsnachverfolgbarkeit. Die meisten Teams konnten diese Frage nicht ohne Weiteres beantworten: „Welche Builds, Artefakte und Deployments genau enthielten ein infiziertes Paket – und welche sind sauber?“

Genau diese Lücke Sicherheit der Software-Lieferkette (SSCS) Plattformen wie ScribeHub sind darauf ausgelegt, zu adressieren.

 

5. Wie ScribeHub SSCS dazu beitragen kann, Angriffe im Stil von Shai-Hulud zu verhindern und abzuschwächen

Ich werde die Techniken von Shai-Hulud 2.0 den Funktionen zuordnen, die man typischerweise mit der ScribeHub-Plattform von Scribe Security und den dazugehörigen Tools implementiert (z. B. Valint Policy-as-Code).

5.1 Leitplanken für die Aufnahme von Abhängigkeiten

Problem in Shai-Hulud 2.0:
Organisationen bezogen aktualisierte npm-Pakete automatisch (über ^/~ Versionsbereiche, Renovate/Dependabot oder CI-Skripte) mit geringer Verhaltensprüfung.

Mit ScribeHub:

• Richtliniengesteuerte Abhängigkeitskontrollen. Verwenden Sie Valint-Richtlinien, um einzuschränken, welche Registrierungsstellen und Bereiche als „vertrauenswürdig“ gelten, Zulassungslisten für kritische Pakete durchzusetzen und Warnungen auszugeben, wenn:
  • Ein neuer Entwickler veröffentlicht eine Version,
  • Es treten unerwartete Lebenszyklusskripte auf,
  • oder ein Paket plötzlich ein neues Netzwerk-/Ausführungsverhalten erhält.
• Bestätigung von Komponenten von Drittanbietern. ScribeHub kann Daten aufnehmen und überprüfen Herkunftsnachweise und Baubescheinigungen für Pakete, sofern verfügbar (z. B. SLSA-Metadaten, Sigstore, in-toto), Aktivierungsregeln wie „Wir verwenden nur Abhängigkeiten, deren Build-Herkunft wir vertrauen.“

Das löst das Problem des npm-Ökosystems nicht auf magische Weise, aber es verbessert es deutlich. setzt die Messlatte höher bevor eine neue Version in Ihre Builds aufgenommen wird.

5.2 Die CI/CD-Pipeline als „erstklassiges Asset“ absichern

Der Hauptwert von Shai-Hulud lag in der Ausbeutung von Entwickler-Laptops und CI/CD-Knoten als geheime Tresore.

Verwendung von ScribeHub:

• Pipeline-Attestierung für jeden Durchlauf.
  Jeder CI-Job erzeugt eine signierte Bescheinigung, die Folgendes beschreibt:
  • welche Repositories und Branches erstellt wurden,
  • welche Abhängigkeiten und Container-Images verwendet wurden,
  • welche Skripte ausgeführt wurden (einschließlich Lebenszyklus-Hooks),
  • und auf welche Geheimnisse zugegriffen wurde.
• Diese Daten landen in ScribeHubs Beweisseeund liefert Ihnen eine fälschungssichere Historie darüber, „wer was wo mit welchen Ressourcen gebaut hat“.
• Laufzeitprüfungen für Richtlinien als Code.
  Bevor ein Build-Artefakt in die Staging-/Produktionsumgebung übernommen werden kann, validiert eine Richtlinien-Engine Folgendes:
  • dass nur zugelassene npm-Registries verwendet wurden
  • dass keine verbotenen Lebenszyklus-Skripte (Locken | Bash, verschleiert Bundle.jsusw.) werden ausgeführt,
  • dass der Runner nicht als Root ausgeführt wurde und keine sensiblen Hostpfade eingebunden hat.

Wenn Shai-Hulud zusätzlich Nachinstallation Skript, das Geheimnisse exfiltriert, diese Läufe Die Richtlinie scheitert und erreichen niemals die Produktionsphase.

5.3 Schnelle Analyse des Explosionsradius

Eine der schwierigsten Aufgaben in einer solchen Kampagne ist die Beantwortung folgender Fragen:

„Wo genau haben wir manipulierte Versionen des Pakets X verwendet, und was genau wurde dadurch verändert?“

Mit ScribeHub:

• Jeder Build, jede Bereitstellung und jedes Artefakt ist mit Folgendem verknüpft: kryptografisch verknüpfte Bescheinigungen: Abhängigkeiten, Umgebungsdetails, Commit-SHAs, Container-Digests usw.
• Wenn in einer neuen Empfehlung steht „Versionen 4.8.1–4.8.5 von einige-Bibliothek „Sind Teil von Shai-Hulud 2.0“, fragen Sie ScribeHub ab:
  
  
  „Zeigen Sie mir alle Builds der letzten 90 Tage, die diese Versionen enthielten, und welche Deployments oder Images sie erzeugt haben.“
  
• Sie können dann Zielgeheimnisrotation und gezielte Korrekturmaßnahmen dort durchzuführen, wo sie wirklich wichtig sind, anstatt alles blindlings umzudrehen (was unter Umständen operativ unrealistisch sein kann).

Anders ausgedrückt: ScribeHub wandelt eine ökosystemweite Panik in eine abgegrenzter, überprüfbarer Vorfall.

5.4 Schutz Ihrer besitzen Pakete vor der Bewaffnung schützen

Viele Organisationen nutzen Open Source nicht nur, sondern auch veröffentlichen Pakete, die von Kunden, Partnern oder internen Teams verwendet werden. Wenn ein Maintainer-Konto in Ihrer Organisation kompromittiert würde, könnten Sie, genau wie die Shai-Hulud-Maintainer, ungewollt zum Überträger werden.

ScribeHub kann dabei helfen, indem es:

• Anforderung von unterzeichneten Bestätigungen von Ihrem CI bevor ein Paket auf npm oder in einer internen Registry veröffentlicht werden kann:
  • Paketversionen, denen die erwarteten Bestätigungen fehlen, werden abgelehnt oder markiert.
• Kontinuierliche Überwachung Ihrer eigenen Registries und Repos:
  • Warnmeldungen werden ausgegeben, wenn ein Paket aus einer unbekannten Build-Umgebung oder außerhalb Ihrer genehmigten CI-Pipelines veröffentlicht wird.
  • Erkennung neuer GitHub Actions oder npm-Skripte, die in der letzten „vertrauenswürdigen“ Version nicht vorhanden waren.

Das macht es für einen Angreifer mit einem gestohlenen Token deutlich schwieriger. um unbemerkt eine bösartige Version in Ihren Namensraum einzuschleusen.

5.5 Nachweise für Aufsichtsbehörden, Kunden und interne Stakeholder

Vorfälle wie Shai-Hulud 2.0 werden von Regulierungsbehörden und Großkunden zunehmend kritisch untersucht, insbesondere in Sektoren, die auf Rahmenwerken wie … basieren. NIST SSDF, PCI-DSS 4oder staatliche Software-Attestierungsanforderungen.

Weil ScribeHub eine Zeitgestempeltes, signiertes Protokoll der SDLC-Aktivität, Sie können:

• Zeigen Sie auf, welche Builds und Releases von den Trojaner-verursachten Abhängigkeiten nicht betroffen waren.
• Den Prüfern konkrete Nachweise über Folgendes vorlegen:
  • Abhängigkeitsrichtlinien
  • Durchsetzung des Grundsatzes der geringsten Privilegien in CI,
  • und geheime Rotationszeitpläne nach dem Vorfall.

Dadurch wandelt sich das Gespräch von „Wir denken, wir sind auf der sicheren Seite“ zu „Hier ist die nachweisliche Herkunftskette unserer Software“.

6. Praktische Erkenntnisse für Sicherheitsverantwortliche

Zusammenfassend würde ich Shai-Hulud 2.0 und die Rolle, die eine Plattform wie ScribeHub spielen kann, folgendermaßen beschreiben:

1. Angenommen, das Ökosystem ist beeinträchtigt. Öffentliche Register stellen als potenzielle Single Points of Failure eine zu große Gefahr dar. Ihr Sicherheitsmodell muss externe Abhängigkeiten so lange als nicht vertrauenswürdig behandeln, bis das Gegenteil bewiesen ist.
2. Upgrade von „Scannen und Beten“ zu „Bestätigen und Durchsetzen“. Klassische SCA und Linting bleiben wichtig, aber Shai-Hulud 2.0 zeigt, dass wir auch Folgendes benötigen:
   • starke Herkunft,
   • bestätigte Bauten,
   • und die politisch geschützte Vermarktung von Artefakten.
3. Behandeln Sie CI/CD wie eine Produktionsumgebung. Der Wurm hatte es auf Geheimnisse und Pipelines abgesehen, weil diese oft leichtere Ziele darstellen als gehärtete Laufzeitumgebungen.
4. Investieren Sie in Rückverfolgbarkeit. Wenn es zum nächsten Ökosystem-weiten Kompromiss kommt – und das wird er –, dann wird Ihre Fähigkeit, die Frage „Wo hat uns das betroffen?“ innerhalb von Stunden statt Wochen zu beantworten, den Unterschied zwischen einem kontrollierten Vorfall und einer ausgewachsenen Krise ausmachen.

ScribeHub SSCS macht npm oder Open Source nicht auf magische Weise sicher, aber es bietet Ihnen die Transparenz, Kontrolle und Beweisgrundlage, die erforderlich sind, um Angriffe vom Typ Shai-Hulud mit weitaus weniger Chaos zu überstehen.

Wenn Sie Ihren SDLC auf kontinuierliche signierte Bestätigungen, evidenzbasierte Richtlinien und eine solide CI/CD-Hygiene ausrichten, wird der nächste „größte npm-Lieferkettenangriff der Geschichte“ zu einem weiteren zu bewältigenden Vorfall und nicht zu einer existenziellen Bedrohung für Ihr Unternehmen.