Wer mit JavaScript oder Node.js arbeitet, kennt den Moment: Man tippt npm install in die Konsole. Das ist der universelle Ausdruck digitalen Vertrauens – ein Knopfdruck, der bedeutet, dass man ein paar Kilobyte fremden Codes in sein Projekt lädt. Meist funktioniert das reibungslos. Doch Microsoft Threat Intelligence hat eine Kampagne dokumentiert, die genau diese Vertrauensbasis angreift. Die Attacke ChainDrop, ein npm-Supply-Chain-Angriff, hat Hunderte Pakete kompromittiert. Der Angreifer manipulierte nicht nur einzelne Bibliotheken, sondern installierte eine selbstverbreitende Malware, die sich wie ein Wurm durch das Ökosystem frisst. Ein einzelner gestohlener Token genügte, um aus einem harmlosen Patch ein massives Sicherheitsproblem für Entwicklerteams weltweit zu machen.
Warum ein Preinstall-Skript zum Einfallstor wird
Um die Gefahr zu verstehen, muss man sich den Lebenszyklus eines npm-Pakets ansehen. Vor der Installation prüft npm die Paketdefinition, die package.json. Dort dürfen Entwickler neben dem Code auch Lifecycle-Hooks definieren – Skripte, die automatisch ausgeführt werden. Kritisch ist der preinstall-Hook, denn er läuft, bevor das Paket final in das Projekt geschrieben wird. Genau hier hat sich der Angreifer eingenistet. Die bösartigen Paketversionen, die im Rahmen von ChainDrop veröffentlicht wurden, schleusen über diesen Hook ein unbekanntes Skript ein, das eine große, stark verschleierte JavaScript-Datei lädt. Laut Microsoft handelt es sich um einen Bun-basierten Payload mit dem Codenamen „Mini Shai-Hulud“. Dieser Code ist nicht darauf ausgelegt, nur einmal zu laufen. Er prüft zunächst, ob er sich auf einer Entwickler-Workstation oder in einer CI/CD-Umgebung befindet. Auf einem lokalen Rechner löst er sich vom Installationsprozess und läuft im Hintergrund weiter. In einer Build-Pipeline bleibt er bewusst im aktiven Prozess, um Workflow-Secrets und OIDC-Berechtigungen zu erbeuten. Der Angriff nutzt keine ausgefallene Sicherheitslücke, sondern die normale Funktionsweise des Paketmanagers – den impliziten Konsens, dass Skripte bei der Installation ausgeführt werden dürfen.
Der Wurm greift um sich: Ein Token, unzählige Pakete
Die Gefahr dieser Malware liegt in ihrer Fähigkeit, sich selbst zu replizieren. Nachdem der Payload auf einem System Fuß gefasst hat, sucht er systematisch nach Zugangsdaten. Er liest lokale Dateien, Shell-Historien, SSH-Schlüssel, Umgebungsvariablen und den Speicher des GitHub Actions Runners. Diese Daten sind die Grundlage für den nächsten Schritt: die Authentifizierung gegenüber externen Diensten. Der Wurm testet, ob er mit den gestohlenen npm-Tokens Schreibrechte besitzt. Ist das der Fall, kommt der entscheidende Automatismus zum Zug. Er kontaktiert die npm-Registry, listet alle Pakete auf, die der kompromittierten Identität gehören, lädt die neuesten Tarballs herunter, fügt den eigenen Malware-Code hinzu, erhöht die Patch-Version und veröffentlicht das manipulierte Paket erneut. Das ist der Kern des „selbstverbreitenden Wurms“. Ein einziger kompromittierter Publisher-Account kann so innerhalb kürzester Zeit hunderte scheinbar legitime Patch-Updates produzieren. Die Analyse zeigt: Über 400 Pakete waren über mehrere voneinander unabhängige Publisher hinweg betroffen. Die Angreifer haben die Token-Hierarchie des Ökosystems verstanden. Für Außenstehende sehen diese Releases aus wie gewöhnliche Versionssprünge, weil sie im Patch-Modus stattfinden. Es gibt keinen Quellcode-Commit, kein Pull Request, keinen Tag. Die Tarballs wurden direkt in der Registry ersetzt, was die forensische Aufarbeitung erschwert.
Datendiebstahl und Persistenz: Die Technik hinter der Tarnung
Abgesehen von der Replikation ist der Wurm ein hocheffizienter Datenspion. Die gestohlenen Anmeldedaten für AWS, Kubernetes, HashiCorp Vault oder GitHub nutzt er nicht nur zur Bestätigung seiner Existenz, sondern zur aktiven Erkundung. Er ruft API-Schnittstellen auf, validiert die Rechte und zieht alle Geheimnisse ab, die mit der jeweiligen Identität erreichbar sind. Die Übertragung der gesammelten Daten erfolgt verschlüsselt: Der Wurm erzeugt einen zufälligen 256-Bit-AES-Schlüssel, verschlüsselt die Daten damit und verschlüsselt diesen Schlüssel anschließend mit einem öffentlichen RSA-Schlüssel des Angreifers. Als Zielserver dient eine dynamische HTTPS-Endpunkt-Adresse, die sich über einen Smart Contract (0xE1f2395ee43e45A1556EC6438a88c31B83493103) oder einen kryptografisch signierten GitHub-Commit ändern lässt. Sollte dieser Kanal nicht erreichbar sein, gibt es einen Fallback: Der Wurm veröffentlicht die verschlüsselten Daten als JSON-Dateien in einem öffentlichen GitHub-Repository mit der Beschreibung „Shai-Hulud: Here We Go Again“. Diese Redundanz sorgt dafür, dass die Operation auch unter widrigen Netzwerkbedingungen fortgesetzt werden kann. Doch damit nicht genug. Um nach der eigentlichen Infektion bestehen zu bleiben, injiziert der Payload schädliche Konfigurationsdateien in Claude- und Visual Studio Code-Verzeichnisse. Die Dateien .claude/settings.json, .claude/setup.mjs oder .vscode/tasks.json werden manipuliert, sodass ein erneuter Start der IDE oder des KI-Assistenten den Malware-Payload wieder aufruft. So entsteht eine Infektionskette, die über die ursprüngliche npm-Installation hinausreicht. Entwickler, die denken, sie hätten die Systeme gesäubert, werden erneut konfrontiert.
Die stille Gefahr: OIDC und die kompromittierte Build-Pipeline
Beunruhigend ist die Fähigkeit des Wurms, die Trusted-Publisher-Funktion von GitHub Actions für npm zu missbrauchen. Moderne CI/CD-Pipelines nutzen OpenID Connect (OIDC), um temporäre, kurzlebige Zugriffstoken zu erhalten. Diese Token sind eine Sicherheitsmaßnahme, da sie nicht dauerhaft gültig sind und das Risiko statischer Secrets verringern. Der Wurm hat diese Logik umgangen. Wenn er in einer CI-Umgebung läuft, die als npm-Trusted-Publisher konfiguriert ist, kann er das OIDC-Token abgreifen und damit Pakete veröffentlichen. Das Tückische: Diese veröffentlichten Pakete tragen eine gültige Herkunftsbescheinigung (Provenance), weil sie tatsächlich von einer legitimierten Workflow-Identität erstellt wurden. Herkömmliche Sicherheitsfilter, die auf Provenance-Daten setzen, können die bösartigen Releases nicht von echten unterscheiden. Die Attacke zielt nicht nur auf direkte Opfer ab, sondern untergräbt das Vertrauen in die gesamte Infrastruktur der Softwarelieferkette. Für Unternehmen, die ihre Softwareproduktion über CI/CD automatisieren, ist das ein Alarmsignal. Es reicht nicht mehr, nur die eigenen Hosts zu schützen; die konfigurierten Rechte der Build-Identitäten müssen kontinuierlich hinterfragt werden. Die Autoren des Microsoft-Berichts weisen ausdrücklich darauf hin, dass dieser Angriff als CI/CD-Pipeline-Missbrauch klassifiziert werden muss.
Konkrete Maßnahmen: So räumst du deine Software nach ChainDrop auf
Microsoft gibt klare Handlungsempfehlungen, um die Folgen dieser Kampagne einzugrenzen. Wer ein betroffenes Paket mit aktivierten Lifecycle-Skripten installiert hat, muss die jeweilige Workstation oder den Build-Runner als potenziell kompromittiert betrachten. Eine reine Wiederherstellung aus Backups reicht nicht aus. Teams sollten unverzüglich alle Zugangsdaten, die von der betroffenen Identität erreichbar waren, von einem sauberen Host aus rotieren – also entfernen und neu vergeben. Dazu gehören npm-Tokens, GitHub-Tokens, Cloud-Zugangsschlüssel und Passwörter für Secret-Stores wie Vault. Ebenfalls essenziell ist die Bereinigung des Caches. Sowohl der npm-Cache als auch der Yarn-Cache müssen auf den betroffenen Endpoints und Build-Hosts geleert werden, besonders wenn kompromittierte Tarballs in geteilte CI-Caches geschrieben wurden. Außerdem sollten Sie die npm-CLI auf Version 12 aktualisieren und die Funktion min-release-age nutzen, die verhindert, dass frisch veröffentlichte, potenziell bösartige Pakete sofort installiert werden. Statten Sie Ihre Entwicklungs- und CI-Assets mit Microsoft Defender for Endpoint und Defender for Cloud aus, um die Telemetriedaten zu erfassen. Schließlich ist eine Überprüfung der Release-Prozesse selbst unerlässlich: Token-Scopes einschränken, Workflow-Approvals einführen, Protected Environments nutzen und Anomalien bei automatisierter Paket-Publikation überwachen. Nach der Bereinigung sollten betroffene Systeme aus einer bekannten, vertrauenswürdigen Abhängigkeitsbasis neu aufgebaut werden – inklusive der Basis-Images für Entwicklungscontainer und Build-Runner.
Einordnung: Was diese Attacke für die Zukunft der Supply-Chain-Sicherheit bedeutet
ChainDrop ist mehr als ein weiterer Zwischenfall in einer langen Liste von Sicherheitswarnungen. Er zeigt, wie fragil das Fundament ist, auf dem die moderne Softwareentwicklung ruht. Wir verlassen uns täglich auf eine unüberschaubare Anzahl von Drittanbieter-Paketen, ohne den tatsächlichen Code zu prüfen. Die Angreifer haben keine ausgefallene Zero-Day-Lücke in einem Browser ausgenutzt, sondern die schlichte Mechanik von Paketmanagern und CI/CD-Pipelines. Das ist die eigentliche Lektion. Einzelne Entwickler können sich kaum gegen einen so hochautomatisierten Wurm schützen, wenn er die üblichen Authentifizierungswege übernimmt. Die Lösung liegt in einem Umdenken: Dependency-Management ist Sicherheits-Management. Lockfiles müssen eingecheckt werden, Software-Bill-of-Materials (SBOM) müssen automatisiert erstellt werden, und die Anzahl der Personen und Identitäten mit Schreibzugriff auf die Produktions-Registry sollte auf ein Minimum reduziert werden. Wer heute noch glaubt, dass npm install ein unbedenklicher Befehl ist, sollte sich ansehen, wie leicht ein einzelner gestohlener Token in dieser Welt zu Hunderten kompromittierter Releases führen kann. Die Werkzeuge sind vorhanden – jetzt liegt es an uns, sie konsequent einzusetzen.
Quelle: microsoft.com
