Heute Morgen hat TeamPCP den vollständigen Quellcode des worm „Shai-Hulud“ worm GitHub veröffentlicht. MIT-Lizenz. Zwei Repositorys. Innerhalb weniger Stunden gab es bereits 44 Forks, von denen einer FreeBSD-Unterstützung hinzufügte, noch bevor die meisten Sicherheitsteams die Schlagzeile gelesen hatten.
Ist es auf die Stimmung abgestimmt? Ja. Funktioniert es? Die Ergebnisse sprechen für sich. Passe die Tonarten und C2 nach Bedarf an. Liebe Grüße – TeamPCP
Ich habe letztes Jahr über Shai-Hulud geschrieben. In diesem Beitrag ging es um die grundlegenden Funktionsweisen: wie worm der worm bei der Installation von Paketen worm , die Laufzeitumgebungen wechselt, um einer Entdeckung zu entgehen, Anmeldedaten sammelt, Daten über öffentliche GitHub-Repositories nach außen schleust und sich verbreitet, indem er das bestehende Vertrauen des Opfers in das Ökosystem ausnutzt.
Diese Funktionsweise gilt nach wie vor. Doch die im Mai 2026 gegen TanStack und mehr als 170 weitere Pakete durchgeführte Kampagne brachte etwas ans Licht, das im ursprünglichen Beitrag nicht behandelt wurde. Der worm , wie er seine schädlichen Pakete als zertifiziert tarnen konnte.
Was hat sich bei der TanStack-Kampagne geändert?
Bei jedem bisherigen Shai-Hulud-Angriff worm der worm npm-Tokens und veröffentlichte manipulierte Pakete unter dem Konto des Opfers. Die Pakete wirkten vertrauenswürdig, da sie von einem bekannten Herausgeber stammten. Darin lag der Trick.
Die TanStack-Kampagne umfasste einen weiteren Schritt. Laut einer von Wiz, StepSecurity und Snyk veröffentlichten Studie worm der worm ein OIDC-Token aus dem Speicher des GitHub-Actions-Runner-Prozesses. Anschließend nutzte er dieses Token, um ein kryptografisches Signaturzertifikat von der Sigstore-Zertifizierungsstelle Fulcio zu beziehen. Mit diesem Zertifikat signierte er das schädliche Paket.
Das Ergebnis: Das manipulierte Paket wies eine gültige SLSA-Herkunftsbescheinigung der Stufe 3 auf. Keine gefälschte. Eine echte, die von Sigstore für die GitHub-Actions-Identität des Opfers ausgestellt worden war.
Die gestohlenen Anmeldedaten wurden an git-tanstack[.]com weitergeleitet, eine speziell für diese Operation registrierte Lookalike-Domain, sowie an Endpunkte von Session Network und eine Reihe von GitHub-Repositorys mit Dunetheme-Design. Während der Angriff lief, hinterließ TeamPCP folgende Nachricht auf dieser Domain:
(Der YouTube-Link führt zu Martin Solveigs Musikvideo „Hello“. Es handelt sich nicht um eine Payload.)
Was OIDC-Token sind und warum sie im Runner-Speicher liegen
OIDC steht für OpenID Connect. Im Zusammenhang mit GitHub Actions löst es ein spezifisches Problem bei der Verwaltung von Anmeldedaten : CI/CD-Pipelines müssen sich bei externen Diensten (npm-Registries, cloud , Sigstore) authentifizieren, ohne dass langfristig gültige Geheimnisse im Repository gespeichert werden.
Die Lösung ist ein kurzlebiges Token. Wenn ein Job ausgeführt wird, stellt der OIDC-Anbieter von GitHub ein Token aus, das die Identität des jeweiligen Jobs repräsentiert: diesen Workflow, dieses Repository, diesen Commit, diesen Akteur. Das Token steht dem Runner über eine Umgebungsvariable und einen lokalen endpoint zur Verfügung. Es läuft innerhalb weniger Minuten nach der Ausstellung ab.
Die Sicherheitsannahme lautet, dass das Token kurzlebig und an einen bestimmten Kontext gebunden ist. Ein Angreifer, der an die gespeicherten Geheimnisse eines Entwicklers gelangt, kann ein Token aus einem früheren Auftrag nicht wiederverwenden, da dieses bereits abgelaufen ist. Diese Annahme ist unter normalen Umständen stichhaltig.
Der worm unter normalen Bedingungen nicht aktiv. Er führt Code innerhalb des „Actions“-Jobs selbst aus, sobald das Token aktiv ist.
So funktioniert die Extraktion in der Praxis
Der worm die ACTIONS_ID_TOKEN_REQUEST_TOKEN Umgebungsvariable aus dem Runner-Prozess und nutzt sie, um ein OIDC-Token vom OIDC endpoint von GitHub anfordern. Anschließend übermittelt dieses Token an die Fulcio-Zertifizierungsstelle von Sigstore, das ein kurzlebiges X.509-Zertifikat ausstellt, das an die Job-Identität von GitHub Actions gebunden ist. Mit diesem Zertifikat und einem Eintrag im Rekor-Transparenzprotokoll, Der worm eine gültige COSIGN-Signatur und eine SLSA-Herkunftsbescheinigung für das Paket, das er veröffentlichen wird.
Jeder Schritt ist ein legitimer API-Aufruf an einen legitimen Dienst. Der Runner verfügt über die Berechtigung, alle diese Aufrufe auszuführen. Genau das ist der springende Punkt. Der Schadcode läuft innerhalb eines Jobs, der diese Berechtigungen über die Vertrauenskonfiguration des Repositorys erhalten hat, und nutzt sie genau so, wie vorgesehen.
Warum die Herkunftsprüfung fehlschlägt
Die SLSA-Herkunftsüberprüfung soll eine bestimmte Frage beantworten: Wurde dieses Artefakt vom erwarteten Build-System aus der erwarteten Quelle und ohne unbefugte Eingriffe erstellt? Build-Level 3 schreibt ausdrücklich eine abgesicherte Build-Umgebung vor, die verhindert, dass der Job seine eigene Herkunft manipuliert.
Die Shai-Hulud-OIDC-Technik umgeht die Konstruktionsannahme, nicht jedoch die technische Steuerung:
- Das Build-System ist nicht beeinträchtigt.
- Der OIDC endpoint nicht kompromittiert.
- Die Fulcio-Zertifizierungsstelle von Sigstore ist nicht kompromittiert.
Was die Bescheinigung nicht erfassen kann, ist, dass der innerhalb des Jobs ausgeführte Code nicht der Code war, den der Betreuer ausführen wollte. Der worm über eine Abhängigkeit ins System, die zuvor in der Pipeline installiert worden war.
Aus Sicht von Sigstore hat ein legitimer GitHub-Actions-Runner, der unter einer legitimen Repository-Identität läuft, ein legitimes Artefakt signiert. Die Bescheinigung gibt diese Tatsachen korrekt wieder. Sie enthält jedoch keine Angaben dazu, wie die Nutzlast dorthin gelangt ist.
Das Zertifikat bestätigt die Identität des Unterzeichners. Es bestätigt jedoch weder die Absichten des Unterzeichners noch, welche anderen Prozesse im selben Prozess abliefen.
Zwei Erkennungsprobleme, nicht nur eines
Der ursprüngliche Beitrag von Shai-Hulud beschrieb dies als ein Problem, bei dem „nichts auffällig erscheint“: Die einzelnen Aktionen worm – das Installieren von Paketen, das Ausführen von Skripten und das Veröffentlichen auf npm – sind allesamt Routinevorgänge, die keine malware erzeugen und keine Richtlinienverletzung auslösen. Jeder Schritt sieht aus wie normale Entwicklungsarbeit.
Die OIDC-Technik bringt ein zweites, damit zusammenhängendes Problem ans Licht: Der Vorgang selbst ist nicht sichtbar. Die Token-Extraktion und der Sigstore-Signaturaufruf sind seitliche Bewegungen durch die Identitätsschicht der CI/CD-Vertrauensstruktur. Der worm eine föderierte Berechtigung von GitHub, legt diese bei Sigstore vor und erhält ein Zertifikat, das die Veröffentlichung auf npm unter der Herkunftskette des Opfers autorisiert. Die Bewegung durchläuft drei verschiedene Systeme: den OIDC-Anbieter von GitHub, die Zertifizierungsstelle von Sigstore und das npm-Register. Jedes System protokolliert ein einwandfreies Authentifizierungsereignis.
Das sind drei Prüfprotokolle und drei erfolgreiche Authentifizierungen. Der fehlende Protokolleintrag ist derjenige, der darauf hindeuten würde, dass der Code, der diese Aufrufe ausführt, dort eigentlich nicht sein sollte.
In dem Rahmenkonzept, das ich in „Mind Your Attack Gaps“ verwende, lassen sich diese auf zwei der drei zentralen Erkennungslücken zurückführen: „Nichts sieht verdächtig aus“ (Lücke 1) und „Bewegungen sind nicht sichtbar“ (Lücke 3). Die meisten Angriffe über die Lieferkette lösen eine dieser Lücken aus. Diese Technik löst beide gleichzeitig aus, weshalb sie automatisierte Scans von 170 Paketen überstanden hat, bevor ein Anbieter sie als verdächtig markierte.
Was sich durch die Umstellung auf Open Source ändert
Bis heute gehörte die OIDC-Extraktionstechnik zu einer einzigen Gruppe. Jeder Vorfall, bei dem sie zum Einsatz kam, ließ sich auf TeamPCP zurückführen. Forensische Analysen von Wiz, Ox Security und ReversingLabs konnten die spezifischen Indikatoren dieser Gruppe nachverfolgen: die C2-Domains, die Dateinamen der Payloads sowie die Muster der Datenexfiltration in Repositorys von Session Network und Dune.
Durch die Veröffentlichung als Open Source wird dieses Eindämmungsmodell durchbrochen. Jeder Akteur, der das Repository forkt, erhält die Fähigkeit zur OIDC-Extraktion. Die konkreten Indikatoren ändern sich mit jeder Variante. Die Technik bleibt dabei dieselbe.
Der FreeBSD-Fork, der innerhalb weniger Stunden nach der Veröffentlichung der Repositorys hinzugefügt wurde, verdeutlicht das Tempo. Der worm läuft worm auf Plattformen, auf denen das Original nie getestet wurde. PyPI ist ein bestätigtes Ziel-Ökosystem aus der Kampagne vom Mai 2026. RubyGems und Maven sind die naheliegenden nächsten Kandidaten. Die 401 bösartigen Paketversionen, die am 11. Mai innerhalb von fünf Stunden über 170 Pakete hinweg veröffentlicht wurden, setzen einen Maßstab. Nachahmer, die dieses Toolkit einsetzen, werden nicht langsamer sein.
Wie die Erkennung aussieht
Das Scannen von Artefakten kann dies nicht erkennen. Die Bescheinigung ist gültig. Die Signatur ist gültig. Das Paket ist funktional korrekt. Nachgelagerte Nutzer, die die SLSA-Herkunft vor der Installation überprüfen, erhalten eine positive Rückmeldung.
Die Anzeichen sind verhaltensbezogen und treten auf, bevor das manipulierte Paket veröffentlicht wird. Ein CI-Runner, der ein OIDC-Token anfordert und endpoint von Sigstore aufruft, endpoint an sich nichts Ungewöhnliches. Ein Runner, der dies tut und gleichzeitig im Rahmen derselben Jobausführung ausgehende Verbindungen zu einem unbekannten Host herstellt, ist jedoch eine Abfolge, die es zu untersuchen gilt. Eine Paketveröffentlichung, die auf anomale Netzwerkaktivitäten in derselben Runner-Sitzung folgt, ist die Kette, auf die man achten muss.
Der ursprüngliche Beitrag führte folgende Verhaltensmerkmale auf: ein GitHub-Token, das Repositorys in unerwartet großem Umfang anlegte, einen CI-Runner, der cloud abfragte, die über den Umfang seines deklarierten Auftrags hinausgingen, sowie einen cloud , der Dienste aufrief, die er noch nie zuvor genutzt hatte. Neu hinzugekommen sind eine OIDC-Anfrage, ein Sigstore-API-Aufruf und eine npm-Veröffentlichung im selben Auftrag, der zudem unbekannte ausgehende Verbindungen erzeugte.
Jede einzelne Handlung ist legitim. Die Kombination ist es nicht.
Warum der Kontext über verschiedene Umgebungen hinweg hier eine Rolle spielt
Vectra AI beobachtet Verhaltensmuster über Identitätssysteme, Netzwerke und cloud hinweg. Bei Vorfällen in der Lieferkette finden sich die relevanten Signale selten in einem einzelnen Protokoll. Sie liegen in der Korrelation: Was hat dieser Prozess getan, bevor er veröffentlicht wurde? Welche externen Hosts tauchten im Netzwerkverkehr dieses Jobs auf, die bei den letzten fünfzig Durchläufen nicht vorhanden waren? Was hat dieser cloud aufgerufen, was er zuvor noch nicht aufgerufen hat?
Das Erkennungsproblem, das Shai-Hulud aufwirft, ist kein Signaturproblem. Es ist ein Kontextproblem. Der Kontext erstreckt sich über drei Audit-Protokolle und einen Netzwerk-Trace. Wenn diese miteinander in Zusammenhang gebracht werden, wird der Verhaltensfingerabdruck worm sichtbar, noch bevor das schädliche Paket einen nachgelagerten Empfänger erreicht.
--
Das übergeordnete Muster, bei dem sich föderierte Identitätsdaten lateral durch die CI/CD-Vertrauensstruktur bewegen, um sich bei nachgelagerten Diensten zu authentifizieren, bezeichne ich als die Lücke „Bewegung ist nicht sichtbar“ (Lücke 3) im E-Book „Mind Your Attack Gaps“. Kapitel 3 behandelt das umgebungsübergreifende Bewegungsmuster im Detail, wobei die OAuth-Supply-Chain-Welle als primäre Fallstudie dient. Die Shai-Hulud-OIDC-Technik stellt dasselbe strukturelle Problem innerhalb der Build-Pipeline dar und nicht auf der SaaS-Ebene.
--
Primärquellen:
- Shai Hulud Open-Source-Repository auf GitHub
- Wiz Research: „Mini-Shai-Hulud schlägt erneut zu: TanStack und weitere npm-Pakete kompromittiert“ (12. Mai 2026)
- StepSecurity: „TeamPCPs ‚Mini Shai-Hulud‘ ist zurück: Ein sich selbst verbreitender Supply Chain trifft das npm-Ökosystem“ (11. Mai 2026)
- Snyk: „TanStack-npm-Pakete kompromittiert“ (11. Mai 2026)
- Tanstack: „Nachbetrachtung: Kompromittierung der TanStack-npm-Lieferkette“ (11. Mai 2026)