Der Angriff NPM ChainDrop zeigt erneut, wie schnell sich eine Supply-Chain-Kompromittierung in der Softwarewelt ausbreiten kann. Laut den vorliegenden Berichten wurden im Rahmen einer neuen Kampagne mehr als 2.200 bösartige Versionen von 440 Paketen in das NPM-Ökosystem eingebracht. Insgesamt haben die infizierten Pakete laut den Beobachtungen über 500 Millionen Downloads pro Woche erreicht.
Besonders kritisch: Während der Installation führten die präparierten Pakete schädlichen Code aus. Dabei ging es nicht nur um das Auslesen von Daten, sondern auch um eine gezielte Weiterverbreitung über Tokens, GitHub-Aktionen und veröffentlichte Paketversionen.
Was hinter NPM ChainDrop steckt
Die Kampagne wurde als ChainDrop bezeichnet und gehört thematisch zu den bekannten Mini Shai-Hulud-Initiativen. Den Startpunkt bildeten 11 Schadträger in bestimmten NPM-Namensräumen (keyv und cacheable), deren Maintainer-Konten zuvor kompromittiert worden waren. Sobald die Angreifer Kontrolle über die Veröffentlichungspfade erlangten, konnten sie schädliche Paketversionen in Umlauf bringen.
Die vergifteten Pakete wurden anschließend so präpariert, dass beim Installieren Malware-Komponenten aktiv werden. In mehreren Fällen kam es darüber hinaus zu einer Kettenreaktion: Durch die Vergiftung einzelner Abhängigkeiten wurden zusätzliche Pakete infiziert. Insgesamt sollen so 433 weitere Pakete als betroffen hinzugekommen sein.
Wie die Malware Secrets findet und exfiltriert
Die schädlichen Versionen zielen darauf ab, auf betroffenen Maschinen möglichst viele Secrets zu finden. Dazu gehört, dass die Malware entsprechende Informationen sammelt, sie verschlüsselt und anschließend exfiltriert.
Als Abflusswege kommen verschiedene Mechanismen infrage. In den Berichten wird beschrieben, dass die Daten entweder an einen dynamischen HTTPS-Endpunkt gesendet werden oder an vom Angreifer angelegte öffentliche GitHub-Repositories. Dabei taucht auch eine spezifische Repository-Beschreibungszeile auf, die als Erkennungsmerkmal dient.
Für die Arbeit in Entwicklerumgebungen ist vor allem relevant, dass die Malware nicht nur lokal stiehlt, sondern sich auch mit wiederhergestellten Identitäten bei wichtigen Diensten authentifizieren kann. Genannt werden dabei unter anderem NPM, GitHub, Amazon Web Services (AWS), Kubernetes sowie HashiCorp Vault. Dadurch lässt sich im weiteren Verlauf systematisch auslesen, welche Pakete, Repositories oder Workflows existieren und welche Geheimnisse in Secrets-Stores verfügbar sind.
Weiterverbreitung über NPM-Tokens und GitHub-Aktionen
Ein zentraler Hebel von NPM ChainDrop ist die Nutzung von kompromittierten NPM-Publishing-Credentials. Nachdem die Malware einen Publishing-Token erhalten hat, enumeriert sie die Pakete, auf die die kompromittierte Identität Zugriff hat. Danach werden aktuelle Paket-Tarballs geladen, die Malware eingefügt und zusätzlich ein Setup-Loader sowie ein preinstall-Hook hinzugefügt.
Um die infizierte Version in den Registry-Fluss zu integrieren, wird die Patch-Version erhöht und das modifizierte Paket anschließend erneut veröffentlicht. Dadurch können Angreifer weitere Pakete erreichen, die in ihrer Reichweite liegen, ohne dass Nutzer die eigentlichen Änderungen sofort bemerken.
Auch GitHub spielt eine direkte Rolle: Die Berichte nennen, dass gestohlene GitHub-Credentials sowie GitHub Actions genutzt werden, um zusätzliche Repositories anzustecken. Ziel ist dabei vor allem, weitere Geheimnisse für Credential Theft zu erlangen. Darüber hinaus werden Konfigurationsdateien in Projekten manipuliert, darunter u. a. Inhalte, die mit Claude und Visual Studio Code in Verbindung stehen sollen, um Persistenz aufzubauen. Zusätzlich wird eine weitere Verbindung zwischen Entwicklern beschrieben, die den Infektionsweg verlängern kann.
Warum das Muster so auffällig schnell eskalierte
In einer besonders kritischen Phase wurden viele historischere Versionen der betroffenen Pakete ebenfalls erneut veröffentlicht bzw. erneut manipuliert. Dadurch stieg die beobachtete Anzahl schädlicher Paketiterationen am 4. August binnen weniger als vier Stunden auf insgesamt 2.212.
Diese schnelle Zunahme ist in der Praxis deshalb gefährlich, weil sie die Abgrenzung im Nachhinein erschwert. Selbst wenn einzelne Releases entfernt oder als bösartig identifiziert werden, können Nutzer in ihren Installationsdaten oder CI-Ausführungen weiterhin ältere (aber manipulierte) Versionen verwendet haben.
Technische Details: Installer, zweite Stufe und EtherHiding
Alle infizierten Paketversionen enthielten laut den Berichten einen Preinstall-Dropper. Dessen Aufgabe ist es, beim Installieren zunächst eine legitime Laufzeitumgebung zu laden – in diesem Fall den Bun-JavaScript-Runtime. Zusätzlich wird anschließend eine zweite Stufe nachgeladen: 710 KB obfuskierten Codes, der die eigentliche Schadfunktion enthält.
Die Malware wird als Weiterentwicklung eines bekannten Worm-Ansatzes eingeordnet. Besonders hervorgehoben wird eine Methode namens EtherHiding, bei der eine Ethereum-Blockchain für Command-and-Control (C&C) verwendet wird. Damit können Angreifer Befehle ableiten, ohne dass klassische Netzwerkmuster zwingend eindeutig sind.
Ergänzend installieren die Schadsoftware-Varianten außerdem eine Art Dead-Man’s Switch auf Hosts. Nach dem Erreichen von Persistenz auf macOS und Linux wird alle 60 Sekunden über die GitHub-API geprüft, ob der gestohlene Token noch funktioniert. Sobald das Token nicht mehr gültig ist, löscht die Malware ihren Zustand und beendet sich. Zusätzlich wird ein Selbstschutzmechanismus beschrieben, der nach 24 Stunden eine bereinigende Selbstlöschung auslöst.
Was betroffene Teams jetzt tun sollten
Wenn ein Entwickler oder ein Build-System eine der infizierten Paketversionen installiert hat, sollten die betroffenen Maschinen als kompromittiert betrachtet werden. Die Empfehlungen aus den Berichten konzentrieren sich auf schnelles Entfernen, sauberes Wiederaufsetzen sowie konsequentes Credential-Management.
1) Systeme isolieren und Beweise sichern
Als erster Schritt wird geraten, betroffene Systeme zu isolieren. Gleichzeitig sollen relevante Artefakte gesichert werden, um den Zeitraum der Exposition besser eingrenzen zu können. Genannt werden dabei unter anderem Package-Tarballs, NPM-Logs, CI-Logs, GitHub Audit Logs sowie Runner-Images. Ohne diese Daten wird es später deutlich schwerer, die tatsächliche Ausbreitung zu rekonstruieren.
2) Malware entfernen und CI/CD neu aufbauen
Im Anschluss sollten die infizierten Komponenten entfernt werden. Da CI-Runner und Build-Maschinen häufig wiederverwendet werden, wird empfohlen, diese Umgebungen neu aufzusetzen bzw. neu zu bauen. So wird verhindert, dass ein einmal kompromittierter Build-Host weitere Deployments weiter kontaminiert.
3) Tokens sperren, Credentials rotieren
Ein weiterer Schwerpunkt liegt auf dem Revoke und der Rotation potenziell kompromittierter Zugänge. Dazu zählen besonders NPM Publishing Tokens, GitHub Credentials sowie weitere Secrets aus Cloud- und Secret-Stores. Da die Malware explizit die Identitäten für mehrere Dienste ansteuern kann, sollte die Rotation nicht nur auf ein einziges System beschränkt bleiben.
4) GitHub-Repositories und Aktivität prüfen
Schließlich sollten GitHub-Repositories auf Auffälligkeiten untersucht werden. Dazu gehört insbesondere, ob bösartige Änderungen in Workflows oder Repository-Konfigurationen vorgenommen wurden und ob ungewöhnliche Aktivitäten in Audit Logs erkennbar sind.
Fazit: NPM ChainDrop ist ein Weckruf für Supply-Chain-Hygiene
NPM ChainDrop verdeutlicht, wie stark eine Supply-Chain-Attacke sein kann, wenn Angreifer nicht nur Pakete manipulieren, sondern anschließend auch weitere Ziele durch Credentials und veröffentlichte Updates erreichen. Die Kombination aus Secret-Theft, Exfiltration und automatisierter Weiterverbreitung über NPM und GitHub macht den Vorfall besonders gefährlich.
Für Teams heißt das: Bei verdächtigen Installationen sollten Sie schnell reagieren, betroffene Systeme isolieren, Belege sichern und anschließend Credentials konsequent rotieren. Nur so lässt sich das Risiko eindämmen und die eigene CI/CD-Pipeline wieder in einen sicheren Zustand bringen.
Quelle: https://www.securityweek.com/over-400-npm-packages-infected-in-chaindrop-supply-chain-attack/
