npm-incident-response

Englisch | Português

Eigenständiger Scanner für den keyv/cacheable-Lieferketten-Zwischenfall („Shai-Hulud: Here We Go Again", 4. Aug. 2026) — mehr als 440 npm-Pakete, kompromittiert durch einen sich selbst verbreitenden Wurm, der Cloud-/CI-Anmeldedaten stiehlt und mit einem Dead-Man's Switch Persistenz einrichtet.

Erkennt in Minuten und ohne etwas zu installieren:

• Kompromittierte Pakete in package-lock.json, npm-shrinkwrap.json, yarn.lock (v1 und Berry), pnpm-lock.yaml und bun.lock — einschließlich transitiven Abhängigkeiten, mit der vollständigen Kette (z. B. eslint → file-entry-cache → flat-cache → [email protected]);
• Installierte Payloads in node_modules (Name + SHA-256-Hash der bekannten Artefakte);
• Varianten, die noch nicht auf den IOC-Listen stehen (Heuristik: verdächtige Lifecycle-Skripte, Dateien mit den Namen des Wurms) — immer als SUSPECT markiert, niemals ohne Hash bestätigt;
• Host-Persistenz-Implantate: LaunchAgent (macOS), systemd-User-Service + linger (Linux), Hooks in .claude/settings.json und .vscode/tasks.json, temporäre Artefakte (bun-dl-*);
• Den Dead-Man's Switch: Das Implantat überwacht ein GitHub-Token und führt einen entfernten Befehl aus, wenn die Sperrung (Revocation) 4xx zurückgibt. Das Rotieren von Anmeldedaten vor der Bereinigung des Hosts löst die Falle aus — der Bericht warnt Sie, und die Reihenfolge der Maßnahmen unten vermeidet den Fehler.

Den Angriff verstehen

1. Das Maintainer-Konto der keyv/cacheable-Familien wurde kompromittiert; der Angreifer veröffentlichte neue Versionen mit einem "preinstall": "node setup.mjs"-Hook — Code, der vor der Installation des Pakets läuft, mit den Rechten dessen, der npm install ausgeführt hat.
2. setup.mjs lädt die Bun-Laufzeit von GitHub herunter und führt die Payload darin aus — eine Umgehung von Tools, die nur node-Prozesse überwachen.
3. Math_Symbol.js (~728 KB, verschleiert) stiehlt Anmeldedaten: AWS-Instance-Metadaten, AWS/GCP/Azure-Schlüssel, Vault-Tokens, Kubernetes-Service-Accounts, GitHub-Actions-Secrets, npm-Tokens sowie einen generischen Regex-Sweep nach privaten Schlüsseln und Bearer-Tokens auf der Platte.
4. Es ist ein Wurm: Mit dem gestohlenen npm-Token injiziert er denselben Hook in andere Pakete, die diese Identität veröffentlichen kann, berechnet die Integritäts-Hashes neu und veröffentlicht erneut. So wuchs es von ~10 auf Hunderte von Paketen.
5. Es exfiltriert ohne festes C2 (spontan erstellte GitHub-Repos, DNS) und hinterlässt eine Falle — siehe unten.

Die beiden Vektoren (der zweite ist subtiler)

• Vektor A — Installation: jeder, der seit 2026-08-04 09:35 UTC npm install/npm ci mit aktivierten Lifecycle-Skripten ausgeführt hat. Mit --ignore-scripts lief der Hook nicht.
• Vektor B — Klonen: Das Quell-Repository erhielt Autostart-Hooks in .claude/settings.json (SessionStart) und .vscode/tasks.json (folderOpen), die den Loader beim Öffnen des geklonten Ordners ausführen — kein npm install, nichts installiert. Das betrifft Personen, die das Repo zur Untersuchung des Vorfalls geklont haben, sowie KI-Coding-Agenten, die das Verzeichnis geöffnet haben — einer der ersten öffentlichen Fälle von AI-Agent-Hooks (.claude/) als Lieferketten-Vektor.

Die Falle (Dead-Man's Switch)

Das Implantat installiert einen „Watcher" (gh-token-monitor), der von einem LaunchAgent (macOS) oder einem systemd-User-Service + loginctl enable-linger (Linux) am Leben gehalten wird. Alle 60 Sekunden validiert er das gestohlene GitHub-Token gegen die API. Solange das Token funktioniert, passiert nichts. Wenn die Antwort 4xx wird — also in dem Moment, in dem Sie das Token sperren —, führt er per eval den Inhalt von ~/.config/gh-token-monitor/handler aus: einen beliebigen Befehl, den der Angreifer remote definiert hat. Die öffentliche Analyse weiß nicht, was er enthält — es könnte Datenvernichtung, erneutes Implantieren, Ransomware oder nichts sein. Das Risiko ist nicht abschätzbar; genau deshalb ist die Reihenfolge der Maßnahmen absolut.

Drei Eigenschaften, die das Vorgehen verändern:

• Das Isolieren vom Netzwerk ist sicher: Ohne Konnektivität gibt es keine HTTP-Antwort, also kein 4xx — die Falle löst nicht aus, und die Exfiltration stoppt. Zuerst isolieren, nicht ausschalten (flüchtiger Speicher ist Beweismittel).
• Sie ist Einmal-Zündung (Single-Shot) und räumt sich selbst auf nach dem Auslösen — das Verhalten bleibt unerklärt, ohne dass ein Artefakt zur Untersuchung zurückbleibt.
• ~24h TTL: Der Watcher zerstört sich selbst nach einem Tag. Das Fehlen von Artefakten beweist nicht, dass die Maschine sauber war — der Scanner warnt im host-Modus davor.

Warum die üblichen Abwehrmaßnahmen es meist übersehen

• „Die Signatur war gültig" — [email protected] wurde mit einer bestandenen SLSA-Attestierung ausgeliefert. Provenance bezeugt die Build-Integrität, nicht die Quelle: Der legitime Workflow kompilierte bereits trojanisierten Code.
• „Der Code-Diff hat sich nicht geändert" — korrekt: Die Bibliothek selbst wurde nicht modifiziert. Die Schadsoftware steckt in package.json (der preinstall-Hook) und in zwei neuen Dateien, die dem Paket hinzugefügt wurden (setup.mjs, Math_Symbol.js).
• „Wir nutzen keyv nicht" — doch, indirekt: Die häufigste Kette ist eslint → file-entry-cache → flat-cache → keyv. Deshalb zeigt der Scanner die Kette bei jedem Befund.
• „Niemand hat npm install ausgeführt" — nicht ausreichend: siehe Vektor B.

Was das Skript in diesem Repository ist

scan.mjs hat die folgenden Eigenschaften — wichtig für alle, die auf einen Lieferketten-Zwischenfall reagieren:

• Eine einzelne Datei, ~880 gut lesbare Zeilen, null Abhängigkeiten. Kein npm install. Prüfen Sie das gesamte scan.mjs in 15 Minuten, bevor Sie es ausführen.
• Null Egress (kein ausgehender Datenverkehr). Keine Daten verlassen Ihre Maschine. Keine Telemetrie, kein „senden Sie das Ergebnis zur Analyse". Die einzige Netzwerkoperation ist --update (Herunterladen eines frischen IOC-Manifests), explizit und optional.
• Schreibgeschützt. Der Scanner modifiziert, entfernt oder führt nichts aus, was er findet.
• Funktioniert offline. docker run --network=none oder eine isolierte Maschine: einfach scan.mjs + iocs.json kopieren.

So verwenden Sie es in Ihrem Unternehmen

Voraussetzung: Node.js ≥ 18 (jede Maschine mit npm hat es bereits). Laden Sie die beiden Dateien herunter — scan.mjs + iocs.json — und das war's: keine Installation.

Hinweis: Wenn Sie dieses gesamte Repository geklont haben, enthält der Ordner fixtures/ inerte IOCs, die in den Tests verwendet werden (echte Namen und Versionen, Dummy-Inhalt — keine Malware). Der Scanner überspringt ihn automatisch und warnt in der Ausgabe; Befunde daraus erscheinen nur, wenn Sie ihn absichtlich scannen.

Es gibt zwei Betriebsmodi, die unterschiedliche Fragen beantworten, und das entscheidet, wo Sie ausgeführt werden:

• Der repo-Modus liest Lockfiles und node_modules — und Lockfiles leben in Git, also kann er zentralisiert werden: Eine Person scannt jedes Repository im Unternehmen.
• Der host-Modus sucht nach dem Implantat (Watcher, LaunchAgent/systemd, IDE-Hooks), das auf der Maschine lebt, auf der der Code ausgeführt wurde — das ist nicht in Git und kann nicht zentralisiert werden.

Schritt 1 — AppSec scannt alle Repositories (eine Person, eine Maschine)

node scan.mjs repo /pfad/mit/allen/repos --json=result.json --html=report.html