Das JFrog Security Research Team hat eine neue Welle der Supply-Chain-Schadsoftware Shai-Hulud analysiert. Betroffen sind 96 manipulierte Paketversionen aus dem npm-Namensraum @redhat-cloud-services, einem von Red Hat selbst genutzten und damit vertrauenswürdigen Bereich. Die Angreifer haben dabei nicht etwa Typosquatting-Pakete platziert, sondern legitime, weit verbreitete Komponenten als Träger missbraucht. Im Schadcode selbst wird die Kampagne als „Miasma: The Spreading Blight “ bezeichnet.

Die Schwachstelle: Code, der vor dem ersten Import läuft

Der Kern des Angriffs liegt in einem Mechanismus, den viele übersehen, den sogenannten npm-Lifecycle-Hooks. Über sie führen die manipulierten Pakete bereits während der Installation Code aus, lange bevor eine Anwendung überhaupt etwas aus dem Paket nutzt. Im untersuchten Fall handelte es sich um ein reines Paket mit Typdefinitionen, in dem ein preinstall-Skript hinterlegt war. Das ist höchst ungewöhnlich, denn solche Pakete bringen normalerweise gar keinen Installer mit.

Eine zweite Variante geht noch raffinierter vor und umgeht gängige Sicherheitsscanner vollständig. Findet npm eine binding.gyp-Datei, aber keine sichtbaren Lifecycle-Skripte, greift es ersatzweise auf den Befehl node-gyp rebuild zurück. Genau in dieser Konfigurationsdatei lässt sich über die Syntax <!(...) ein Shell-Befehl verstecken, der den Schadcode startet, getarnt als harmlose Kompilierung eines nativen Bausteins. Sicherheitswerkzeuge, die allein nach den offensichtlichen Lifecycle-Skripten suchen, schauen hier ins Leere.

Die Angreifer: Tarnung, Diebstahl und Selbstverbreitung

Nach dem Start entfaltet die Schadsoftware das klassische Shai-Hulud-Repertoire, nutzt dafür aber eine neue Lieferkette. Ein stark verschleierter Loader entschlüsselt zwei AES-128-GCM-Blobs: einen kleinen Bun-Bootstrapper und die eigentliche Schadnutzlast. Bei Bedarf lädt er die JavaScript-Laufzeit Bun direkt von GitHub nach. Anschließend führt er die Nutzlast aus einer temporären Datei aus. Diese sammelt anschließend systematisch Zugangsdaten: GitHub- und npm-Token, Cloud-Credentials für AWS, Azure und GCP, Kubernetes-Secrets, SSH-Schlüssel und Passwortmanager-Daten. In Cloud-Umgebungen fragt sie sogar aktiv die internen Metadaten-Schnittstellen der Cloud-Anbieter und deren Secret-Stores ab.

Besonders heikel ist das Verhalten in CI/CD-Pipelines. Über die Umgebungsvariablen ACTIONS_ID_TOKEN_REQUEST_TOKEN und ACTIONS_ID_TOKEN_REQUEST_URL kann die Malware einen OIDC-Token anfordern und sich so bei der npm-Registry als legitimer Build authentifizieren. Damit zeigt sich erneut: Build-Provenance belegt zwar, wo ein Paket entstanden ist, nicht aber, ob die Build-Umgebung sauber war.

Zur Tarnung ist die Datenexfiltration so konfiguriert, dass sie wie Datenverkehr zu Anthropic aussieht. Das Ziel api.anthropic.com/v1/api ist ein echter, legitimer Host – der angesprochene Pfad existiert jedoch nicht und liefert nur einen 404-Fehler. Die Angreifer nutzen den vertrauenswürdigen Domainnamen also als Nebelkerze in den Netzwerk-Logs. Eine kompromittierte Anthropic-Infrastruktur lässt sich daraus ausdrücklich nicht ableiten.

Shai-Hulud verbreitet sich zudem selbst weiter, wurmartig: Findet die Malware npm-Token mit Veröffentlichungsrechten, injiziert sie sich in andere Pakete, erhöht die Patch-Version und publiziert diese neu. Auf GitHub manipuliert sie Actions-Workflows und legt öffentliche Repositories mit der Beschreibung „Miasma: The Spreading Blight" als Datenablage an.

Der gefährlichste Teil: ein Dead-Man-Switch

Die Schadsoftware verankert sich dauerhaft über System-Dienste (kitty-monitor unter Linux und macOS) sowie über Entwicklerwerkzeuge und KI-Assistenten wie Claude, Copilot oder Gemini, deren Konfigurationsdateien sie manipuliert. Am riskantesten ist jedoch ein destruktiver Token-Monitor: Wird ein gestohlener GitHub-Token für ungültig erklärt, kann ein hinterlegter Handler zerstörerische Befehle ausführen – bis hin zur Löschung des Benutzerverzeichnisses. Wer kompromittierte Token vorschnell widerruft, riskiert also Datenverlust.

Wenn der Entwicklerrechner zum Einfallstor wird

Bei der Bereinigung kommt es auf die richtige Reihenfolge an. Zuerst sollten betroffene Rechner und CI-Runner isoliert werden, dann gilt es die Persistenz-Mechanismen zu entfernen und forensische Spuren zu sichern. Erst danach, von einem sauberen System aus, dürfen sämtliche Token und Zugangsdaten rotiert werden. Betroffene Pakete sollten deinstalliert, Lockfiles aus vertrauenswürdigen Quellen neu generiert und in CI-Umgebungen vorübergehend mit npm ci --ignore-scripts gearbeitet werden.

Der Fall macht eine unbequeme Wahrheit deutlich. Der gute Ruf eines Pakets oder eines Namensraums ist kein Sicherheitsgarant mehr. Die Schadsoftware betrachtet Entwicklerrechner und Build-Pipelines nicht als Endziel, sondern als Sprungbrett in GitHub, npm, Cloud-Plattformen und letztlich in die gesamte nachgelagerte Lieferkette. Unternehmen sollten daher Lifecycle-Skripte, frisch veröffentlichte Versionen und unerwartete zusätzliche Programmbestandteile, die ein Paket beim Ausführen nachlädt, zu festen Prüfpunkten machen. Und sie sollten davon ausgehen, dass der nächste Angriff erneut über einen Kanal kommt, dem man bislang blind vertraut hat.

Die vollständige Untersuchung des JFrog Security Research Teams inklusive Updates finden Sie hier: https://research.jfrog.com/post/shai-hulud-miasma-redhat-cloud-services/