Vorwort

Wir setzen in vielen unserer Produkte NPM-Pakete ein, weshalb wir uns gerade sehr intensiv mit „Shai-Hulud“ beschäftigen.

Warum NPM für uns (und unsere Kunden) so wichtig ist

Ein Großteil unserer Software basiert auf JavaScript-/TypeScript.

Dazu gehören unter anderem:

• Frameworks und Bibliotheken aus dem npm-Registry-Universum
• Build-Werkzeuge, Test-Frameworks und CLI-Tools
• UI-Komponenten, die wir in unseren Oberflächen einsetzen

Kurz: Unsere Anwendungen bestehen nicht nur aus eigenem Code, sondern auch aus vielen Open-Source-Bausteinen aus dem npm-Ökosystem.

Genau dieses Ökosystem ist derzeit Ziel einer massiven Supply-Chain-Attacke: genannt Shai-Hulud.

Was ist Shai-Hulud?

Shai-Hulud ist der Name eines selbstreplizierenden Wurms, der gezielt npm-Pakete angreift. Sicherheitsforscher ordnen Shai-Hulud bzw. „Shai-Hulud 2.0“ als eine der aggressivsten Supply-Chain-Kampagnen im npm-Ökosystem des Jahres 2025 ein.

Der Angreifer kompromittiert dabei zunächst Maintainer-Konten auf npm und veröffentlicht veränderte Versionen bestehender Pakete – also Versionen, die scheinbar legitim aussehen, aber zusätzlichen bösartigen Code enthalten. Sobald ein Entwickler oder eine CI-Pipeline ein solches Paket installiert, wird der Schadcode ausgeführt.

Was macht Shai-Hulud konkret?

Die aktuellen Analysen verschiedener Security-Teams zeichnen ein klares Bild:

• Infektion über npm-Pakete
  Kompromittierte Maintainer veröffentlichen manipulierte Paketversionen (oft mit nur minimalen Versionsänderungen).
• Ausführung beim Installieren
  Der Schadcode hängt sich an npm-Lifecycle-Scripte, z.B. preinstall/postinstall.
  In der zweiten Welle kommen neue Payload-Dateien wie setup_bun.js und bun_environment.js zum Einsatz.
• Diebstahl von Zugangsdaten
  Shai-Hulud durchsucht Entwicklungs- und CI/CD-Umgebungen nach Zugangsdaten, u.a.:
  • npm-Tokens
  • GitHub-Tokens
  • Cloud-Credentials (AWS/GCP/Azure etc.)
    Oft wird dazu das Open-Source-Tool TruffleHog eingebunden, um Secrets in Repositories und Konfigurationen zu finden.
• Exfiltration und weitere Verbreitung
  Gefundene Secrets werden in neu angelegten Git-Repositories oder Workflows abgelegt und so exfiltriert.
  Der Wurm nutzt diese Zugangsdaten, um weitere Pakete und Repositories des Opfers zu kompromittieren – daher der „Wurm-Charakter“.
• Aggressive neue Variante
  In der aktuellen Kampagne („Shai-Hulud 2.0“) wurden tausende Repositories und hunderte Pakete betroffen, darunter prominente Open-Source-Projekte.

Wer ist gefährdet?

Gefährdet sind im Wesentlichen alle, die:

• npm-Pakete aus dem öffentlichen Registry nutzen (direkt oder über Proxies/Mirror),
• automatisierte Builds über CI/CD-Systeme (z.B. GitLab CI, GitHub Actions, Jenkins) ausführen,
• ihre Pipelines mit dauerhaften Tokens/Secrets konfigurieren.

Konkret erhöht sich das Risiko, wenn:

• automatisch alle Updates/Minor-Updates eingespielt werden („immer das Neueste“),
• Install-Scripte (preinstall, postinstall) ohne Einschränkungen in CI-Umgebungen ausgeführt werden,
• Secrets dauerhaft in Umgebungsvariablen oder Konfigurationsdateien liegen.

Worin besteht die Gefährdung?

Die Gefährdung durch Shai-Hulud geht weit über „nur“ ein einzelnes kompromittiertes Paket hinaus:

1. Diebstahl von Zugangsdaten
   Abgezogene Tokens können für weitere Angriffe auf Git-Repos, Build-Systeme und Cloud-Infrastrukturen missbraucht werden.
2. Kompromittierte Lieferkette (Supply Chain)
   Wird ein bösartiges Paket in ein Produkt eingebaut, kann dieses unbemerkt Schadcode in Kundensystemen ausführen oder weitere Lieferketten kompromittieren.
3. Langfristige Kompromittierung der Entwicklungsumgebung
   Einmal kompromittierte CI- oder Dev-Umgebungen lassen sich oft nicht mit einem einfachen „Update“ bereinigen; hier sind Token-Rotation, forensische Analysen und ggf. Neuaufbau erforderlich.

Für Unternehmen, die Software entwickeln und ausliefern, ist das eine strategische Bedrohung der gesamten Software-Lieferkette.

Unsere Infrastruktur

Wir betreiben unsere Entwicklungs- und Build-Infrastruktur selbst – on-prem, auf unseren eigenen lokalen Servern – ohne externen Zugriff.

GitLab

Wir nutzen GitLab als zentrale Plattform für:

• Quellcode-Verwaltung (Git-Repos)
• Merge Requests und Code Reviews
• CI/CD-Pipelines für Build, Tests und Deployments

Damit ist GitLab das Herzstück unserer Entwicklungsprozesse: Hier laufen die automatisierten Builds, und hier würden kompromittierte Pakete im Zweifel ausgeführt.

Nexus Repository

Als zentrales Artefakt- und Paket-Repository setzen wir Sonatype Nexus Repository ein.

Nexus dient uns als:

• Proxy für externe Registries,
• Cache für häufig genutzte Pakete,
• zentrale Quelle für interne Artefakte und Bibliotheken.

Kurz: Jedes npm-Paket, das in unseren Builds verwendet wird, läuft über unseren Nexus-Proxy – ein idealer Kontrollpunkt, um potenziell kompromittierte Pakete zu erkennen.

Im Nexus-Cache befinden sich alle Pakete, die wir seit August 2024 eingesetzt haben.

Wie wir auf Shai-Hulud reagieren

1. Wir haben die automatische Ausführung von Installationsskripten deaktiviert

Auf lokalen Entwicklungssystemen haben wir die Ausführung von Lifecycle-Skripten deaktiviert:

npm config set ignore-scripts true

Skripte wie preinstall, postinstall, prepare etc. werden so nicht ausgeführt.

Das schützt vor dem, was Shai-Hulud als Einfallstor nutzt: Code, der beim Installieren automatisch ausgeführt wird.

2. Wir verwenden nicht automatisch immer die neueste Paketversion

Wir setzen Pakete stets in ausgewählten Versionen ein (manueller Prozess). Mittels verteilter package-lock.json wird sichergestellt, dass jeder Entwickler genau die ausgewählte Paketversion installiert und verwendet.

Unter keinen Umständen werden pauschal und automatisiert die neuesten Paketversionen in Build-Prozessen verwendet.

3. Automatisierte und manuelle Prüfungen

Sicherheitsforscher von Wiz veröffentlichen zu der aktuellen Shai-Hulud-Kampagne laufend aktualisierte Indikator-Listen (IoCs), darunter eine CSV-Liste betroffener npm-Pakete und Versionen:

https://github.com/wiz-sec-public/wiz-research-iocs/blob/main/reports/shai-hulud-2-packages.csv

Wir nutzen diese Liste, um unsere Umgebung gezielt und automatisiert zu prüfen.

Abgleich aller durch unseren Proxy gegangenen Pakete

Wir haben ein automatisiertes Verfahren eingerichtet, das:

1. die von Wiz gepflegte Liste kompromittierter Pakete und Versionen einliest,
2. für jedes dieser Pakete eine Abfrage gegen unseren Nexus-Proxy durchführt,
3. prüft, ob diese Paketversion jemals über unseren Proxy bezogen wurde.

Damit beantworten wir die Frage:

„Ist eines der bekannten Shai-Hulud-Pakete in unsere Build-Infrastruktur gelangt?“

Das Ergebnis dieser Prüfung:

NB: Wir setzen auch keines der kompromittierten Pakete in anderen Versionen ein.

Weitere Prüfschritte in unserer GitLab-Umgebung

Ergänzend haben wir:

• unsere npm-Lockfiles und Build-Konfigurationen geprüft,
• nach bekannten Indikatoren wie verdächtigen Install-Scripten und typischen Shai-Hulud-Artefakten gesucht (z.B. bestimmte JavaScript-Dateien und Workflow-Muster).

Kein Indiz für eine Kompromittierung

Zusammengefasst:

• Wir setzen für viele unserer Produkte npm-Pakete ein und nehmen die aktuelle Shai-Hulud-Bedrohung sehr ernst.
• Shai-Hulud ist ein selbstreplizierender Wurm, der über kompromittierte npm-Pakete Zugangsdaten stiehlt und sich über Entwicklungs- und CI-Umgebungen weiterverbreitet.
• Unsere Entwicklungs- und Lieferkette basiert auf selbst-gehostetem GitLab und Nexus Repository, die wir als zentrale Kontrollpunkte nutzen.
• Wir haben ein automatisiertes Prüfverfahren implementiert, das alle durch unseren Nexus-Proxy gehenden Pakete gegen die von Wiz veröffentlichte Shai-Hulud-Paketliste abgleicht – ohne Auffälligkeiten.
• Zusätzlich konnten wir in unserer GitLab-Umgebung keine Hinweise auf andere kompromittierte Pakete oder Shai-Hulud-Artefakte finden.

Wir beobachten die Lage weiterhin aktiv und passen unsere Schutzmaßnahmen laufend an.

Sollten sich neue Erkenntnisse oder zusätzliche Indikator-Listen ergeben, werden wir diese in unsere automatisierten Prüfungen integrieren – um die Sicherheit unserer Produkte und damit auch Ihrer Systeme bestmöglich zu gewährleisten.