Kompromittierung von npm-Paketen durch die ChainDrop-Supply-Chain-Attacke

Die digitale Lieferkette, insbesondere im Kontext von Software-Entwicklung und -Bereitstellung, stellt ein komplexes Ökosystem dar, dessen Integrität von größter Bedeutung ist. Jüngste Ereignisse haben die potenziellen Schwachstellen dieses Systems auf dramatische Weise offengelegt. Eine weitreichende Supply-Chain-Attacke, die unter dem Namen „ChainDrop“ bekannt wurde, hat mehr als 400 npm-Pakete betroffen und dabei weitreichende Konsequenzen für die betroffenen Organisationen und Entwickler nach sich gezogen.

Analyse des ChainDrop-Angriffs

Die Angriffskampagne, die von Sicherheitsexperten detailliert analysiert wurde, zeichnet sich durch ihre Raffinesse und die Geschwindigkeit ihrer Ausbreitung aus. Im Zentrum stand eine Variante des „Mini Shai-Hulud“-Wurms, einer selbstverbreitenden Malware, die darauf ausgelegt ist, Zugangsdaten zu stehlen.

Initialer Kompromittierungsvektor und Ausbreitung

Der Angriff begann mit der Kompromittierung von npm-Paketen, die von verschiedenen, voneinander unabhängigen Publishern gepflegt wurden. Die Angreifer nutzten modifizierte npm-Paket-Tarballs, die den bösartigen Code enthielten. Die Ausführung der Malware erfolgte automatisiert über sogenannte „Preinstall Lifecycle Hooks“ noch bevor die eigentliche Paketinstallation auf Entwickler-Systemen oder in Continuous Integration/Continuous Delivery (CI/CD)-Umgebungen abgeschlossen war.

Diese Preinstall-Skripte sind ein regulärer Bestandteil des npm-Installationsprozesses. Die npm-Dokumentation listet verschiedene Skripte wie „preinstall“, „install“ und „postinstall“ auf, die während der Installation ausgeführt werden können. Neuere npm-Tools bieten zwar Kontrollmechanismen, welche Abhängigkeiten installationszeitliche Skripte ausführen dürfen, doch die Angreifer nutzten bestehende Konfigurationen aus.

Auffällig war, dass viele der infizierten Releases als gewöhnliche Patch-Version-Updates erschienen, denen jedoch entsprechende Source-Code-Commits, Pull Requests oder Release-Tags fehlten. Dies deutet darauf hin, dass die Angreifer die Paketarchive direkt modifiziert und veröffentlicht haben, anstatt die öffentlichen Quellcode-Repositorys hinter den Paketen zu kompromittieren.

Datenerfassung und Exfiltration

Nach der Ausführung analysierte die Malware ihre Umgebung, um festzustellen, ob sie auf einer Entwickler-Workstation oder in einer CI/CD-Umgebung operierte. Auf Entwickler-Systemen konnte sich die Malware vom Installationsprozess lösen und im Hintergrund weiterlaufen. In CI-Umgebungen verblieb sie im aktiven Build-Job, um Zugriff auf Workflow-Secrets, Runner-Zugangsdaten und Veröffentlichungsberechtigungen zu erhalten.

Der Payload sammelte eine breite Palette von Zugangsdaten aus verschiedenen Quellen:

• Umgebungsvariablen
• Lokale Konfigurationsdateien
• Shell-Historien
• Befehlszeilen-Tools
• SSH-Schlüssel
• GitHub Actions Runner-Speicher

Die so erbeuteten Zugangsdaten wurden anschließend gegen Dienste wie npm, GitHub, Amazon Web Services, Kubernetes und HashiCorp Vault getestet. Die Malware nutzte gültige Zugangsdaten, um Service-APIs abzufragen und zusätzliche Ressourcen oder Secrets zu identifizieren, auf die diese Identitäten Zugriff hatten.

Propagation und Missbrauch von Trusted Publishing

Ein zentraler Mechanismus der Wurm-Ausbreitung war der Missbrauch von npm-Veröffentlichungsrechten, die aus kompromittierten Umgebungen erlangt wurden. Nach dem Erwerb eines nutzbaren Veröffentlichungs-Tokens identifizierte die Malware Pakete, die vom betroffenen Konto modifiziert werden konnten. Sie lud das neueste Paketarchiv herunter, injizierte ihren Payload und Loader, ersetzte Lifecycle-Skripte, erhöhte die Patch-Version und veröffentlichte das manipulierte Paket.

Besondere Beachtung verdient der Umstand, dass die Attacke auch GitHub Actions Workflows ins Visier nahm, die für das „npm Trusted Publishing“ konfiguriert waren. Dieses Verfahren ermöglicht es autorisierten CI/CD-Workflows, Pakete über OpenID Connect zu veröffentlichen, anstatt sich auf langlebige npm-Veröffentlichungs-Tokens zu verlassen. Da die Veröffentlichung aus einer legitimen Workflow-Identität stammte, konnten Pakete, die über diesen bösartigen OIDC-Pfad neu veröffentlicht wurden, eine gültige Provenienz behalten, was die Erkennung erschwerte.

Ausweitung des Angriffs über npm hinaus

Der Angriff beschränkte sich nicht auf die npm-Registry. Gestohlene GitHub-Zugangsdaten konnten genutzt werden, um Repositorys zu modifizieren und so einen weiteren Ausführungspfad für die Malware zu schaffen. Die Malware zielte auch auf Konfigurationspfade von Entwicklungstools wie Claude und Visual Studio Code ab, indem sie bösartige Konfigurationsdateien injizierte. Diese Dateien konnten den Payload bei späterer Nutzung der Tools erneut starten.

Ein Fallback-Mechanismus ermöglichte die Installation einer Komponente, die gestohlene GitHub-Zugangsdaten überwachte. Sollte ein überwachter Token widerrufen werden, konnte ein destruktiver Handler ausgelöst werden.

Datenexfiltration und Infrastruktur

Die gesammelten Informationen wurden im JSON-Format konvertiert, komprimiert und verschlüsselt, bevor sie an vom Angreifer kontrollierte HTTPS-Endpunkte gesendet wurden. Für die Verschlüsselung der Daten kam AES-256-GCM zum Einsatz, wobei der AES-Schlüssel mittels des öffentlichen RSA-Schlüssels des Angreifers verschlüsselt wurde.

Als aktive Domain für die Exfiltration wurde npm-cache[.]com identifiziert. Weitere beobachtete Infrastrukturen umfassten pypi-get[.]com und js-mirror[.]com. Die Malware verfügte über Mechanismen, um ihren aktiven Endpunkt über einen On-Chain-Vertrag oder eine kryptografisch signierte GitHub-Commit-Nachricht zu ändern. Sollte der primäre Kommunikationskanal nicht verfügbar sein, konnte der Payload ein öffentliches GitHub-Repository erstellen und die verschlüsselten Ergebnisse dort hochladen, oft unter Verwendung der Beschreibung „Shai-Hulud: Here We Go Again“.

Empfehlungen und Gegenmaßnahmen

Angesichts der Komplexität und Reichweite des ChainDrop-Angriffs sind umfassende Maßnahmen zur Abwehr und Eindämmung erforderlich. Für Unternehmen, die von derartigen Supply-Chain-Angriffen betroffen sein könnten, ergeben sich folgende Handlungsempfehlungen:

Sofortige Maßnahmen

• Betroffene Paketversionen identifizieren und entfernen: Überprüfen Sie Abhängigkeitsbäume, Lockfiles und Artefakt-Repositorys auf alle betroffenen Releases, einschließlich transitiver Abhängigkeiten.
• Systeme als kompromittiert behandeln: Alle Entwickler-Maschinen oder Build-Runner, auf denen ein infiziertes Paket installiert wurde, müssen als potenziell kompromittiert betrachtet und neu aufgesetzt werden.
• Zugangsdaten rotieren: Umgehend alle exponierten Zugangsdaten widerrufen und ersetzen. Dazu gehören Cloud-Zugangsdaten, GitHub-Tokens, SSH-Schlüssel, Kubernetes-Konfigurationen und HashiCorp Vault-Tokens.
• Überprüfung von Cloud- und Quellcode-Umgebungen: Führen Sie eine gründliche Prüfung auf unautorisierten Zugriff oder verdächtige Aktivitäten nach der Paketinstallation durch.
• CI-Caches bereinigen: Löschen Sie npm- und Yarn-Caches auf exponierten Entwickler-Systemen und Build-Hosts, insbesondere wenn kompromittierte Paketarchive in gemeinsamen CI-Caches gespeichert wurden.

Präventive und langfristige Strategien

• Paket-Pinning und Überprüfung: Pinnen Sie bekannte, gute Paketversionen und überprüfen Sie regelmäßig Abhängigkeitsbäume und Lockfiles.
• npm CLI mit Sicherheitsfunktionen nutzen: Verwenden Sie npm CLI 12 oder neuere Versionen und aktivieren Sie Funktionen wie „min-release-age“, um die Installation sehr neuer Paketversionen für einen bestimmten Zeitraum zu verhindern. Stellen Sie sicher, dass „allowScripts“ restriktiv gehandhabt wird und „strict-allow-scripts“ aktiviert ist, um nicht überprüfte Installationsskripte als Fehler zu behandeln.
• Automatisierte Release-Prozesse überprüfen: Für Organisationen, die Softwarepakete veröffentlichen, ist eine gründliche Überprüfung der automatisierten Release-Prozesse unerlässlich. Dies umfasst die Prüfung von Token-Scopes, Workflow-Genehmigungen, geschützten Umgebungen und der Paket-Provenienz. Achten Sie auf ungewöhnliche automatisierte Veröffentlichungsaktivitäten, insbesondere bei der Nutzung von GitHub Actions oder anderen CI/CD-Systemen.
• Aufbau von Resilienz: Implementieren Sie Maßnahmen wie Abhängigkeits-Allowlisting, Paketintegritätsprüfung und Provenienz-Kontrollen, wo verfügbar.
• Überwachung und Threat Intelligence: Bleiben Sie über veröffentlichte Indicators of Compromise (IOCs) auf dem Laufenden und integrieren Sie diese in Ihre Überwachungssysteme.

Die ChainDrop-Attacke verdeutlicht einmal mehr die Notwendigkeit einer robusten Sicherheitsstrategie in der Software-Lieferkette. Angriffe auf diese kritische Infrastruktur können weitreichende und schwerwiegende Folgen haben. Eine proaktive Haltung, kombiniert mit präzisen Analysen und schnellem Handeln, ist entscheidend, um den Risiken zu begegnen und die Integrität digitaler Produkte zu gewährleisten.

Bibliografie

• Microsoft Security Blog. (2026, 4. August). ChainDrop supply chain compromise: Anatomy of a self-propagating worm.
• Unit 42 (Palo Alto Networks). (2026, 6. August). ChainDrop: Inside a Self-Propagating npm Worm.
• Elastic Security Labs. (2026, 6. August). CHAINDROP worm hits 400+ npm packages.
• Developer-Tech.com. (2026, 6. August). npm supply-chain attack hits 400+ packages and steals developer credentials.
• CSO Online. (2026, 5. August). ChainDrop credential stealing worm infects over 400 npm packages.
• StepSecurity. (2026, 4. August). ChainDrop npm Worm: Bun-loaded CI/CD credential harvester with Ethereum dead-drop C2.
• CyberScoop. (2026, 4. August). Massive supply-chain attack compromises 440 packages under four hours.
• Infosecurity Magazine. (2026, 5. August). ChainDrop Worm Hits 400 npm Packages with Two Billion Monthly Installs.
• Endor Labs Blog. (2026, 4. August). NPM Malware Compromises keyv and cacheable with 500M+ Weekly Downloads and Spreads to Hundreds of Packages.
• Deepwatch Labs. (2026, 4. August). Supply Chain Compromise Involving keyv and Associated npm Packages.