npm-Supply-Chain-Angriffs vom September 2025: Ein technischer Deep Dive in den Krypto-Diebstahl

Die Kompromittierung der npm-Lieferkette im September 2025

Im September 2025 wurde das npm-Ökosystem Zeuge eines der potenziell weitreichendsten Supply-Chain-Angriffe seiner Geschichte. Dutzende grundlegender JavaScript-Pakete, darunter allgegenwärtige Tools wie chalk und debug, wurden kompromittiert.¹ Diese Pakete verzeichnen zusammen über 2,6 Milliarden wöchentliche Downloads, was eine immense potenzielle Angriffsfläche schuf.³ Der Vorfall unterstreicht die systemische Fragilität der Open-Source-Softwarelieferkette und die zunehmende Raffinesse von Bedrohungsakteuren, die auf die Kompromittierung von Krypto-Assets abzielen.

Der initiale Angriffsvektor war eine hochentwickelte Social-Engineering-Kampagne, die erfolgreich die Anmeldedaten eines produktiven Paket-Maintainers, Josh Junon (GitHub-Handle: qix), durch Phishing erlangte.³ Dieser unbefugte Zugriff ermöglichte es dem Angreifer, bösartige Versionen von vertrauenswürdigen Paketen direkt in der öffentlichen npm-Registry zu veröffentlichen.

Die eingeschleuste Nutzlast war ein hochspezialisierter, clientseitiger Kryptowährungs-Drainer, der darauf ausgelegt war, unbemerkt in den Browsern der Endbenutzer zu operieren.³ Sein Hauptziel war das Abfangen und Umleiten von Web3-Transaktionen über mehrere Blockchains hinweg, indem Gelder an vom Angreifer kontrollierte Wallets umgeleitet wurden.⁷

Ein zentrales Merkmal dieses Vorfalls ist der starke Kontrast zwischen der astronomischen potenziellen Reichweite des Angriffs und seinem minimalen finanziellen Erfolg. Schätzungen zufolge beliefen sich die gestohlenen Gelder auf weniger als 1.000 US-Dollar.⁵ Dieses Paradoxon deutet entweder auf eine fehlerhafte Ausführung, einen Testlauf für eine zukünftige Operation oder das primäre Ziel hin, weitreichende Störungen anstelle von direktem finanziellen Gewinn zu verursachen.⁶

Die entscheidende Rolle bei der Eindämmung des Schadens spielte die schnelle Reaktion der Open-Source- und Sicherheits-Community. Die bösartigen Pakete wurden innerhalb weniger Stunden nach ihrer Veröffentlichung identifiziert und aus der Registry entfernt, was die potenziellen Auswirkungen erheblich abschwächte.¹ Der Vorfall dient als eindringliche Fallstudie über die Verwundbarkeit der modernen Softwareentwicklung und die Notwendigkeit robuster, mehrschichtiger Verteidigungsstrategien.

Anatomie des initialen Einbruchs: Dekonstruktion der Adversary-in-the-Middle (AiTM) Phishing-Kampagne

Der Erfolg des gesamten Supply-Chain-Angriffs hing von einem einzigen, entscheidenden Faktor ab: der Kompromittierung eines vertrauenswürdigen menschlichen Glieds in der Kette. Der Angreifer nutzte keine Zero-Day-Schwachstelle in der npm-Infrastruktur, sondern eine meisterhaft ausgeführte Social-Engineering-Kampagne, die auf menschliches Vertrauen und psychologische Dringlichkeit abzielte.

Der Köder: Eine Social-Engineering-Meisterleistung

Der Angriff begann mit einer äußerst überzeugenden Phishing-E-Mail, die an Paket-Maintainer, darunter Josh Junon („qix“) und später den „duckdb_admin“-Account, gesendet wurde.³ Die E-Mail war sorgfältig gestaltet, um den offiziellen Support von npm zu imitieren, und stammte von der Typosquatting-Domain npmjs[.]help. Diese Domain wurde nur drei Tage vor dem Angriff, am 5. September 2025, registriert, was auf eine gezielte Vorbereitung hindeutet.⁵

Die Nachricht bediente sich klassischer Social-Engineering-Taktiken, um ein falsches Gefühl der Dringlichkeit zu erzeugen. Sie behauptete, dass ein obligatorisches Update der Zwei-Faktor-Authentifizierung (2FA) innerhalb von 48 Stunden erforderlich sei, um eine Sperrung des Kontos zu vermeiden.⁸ Diese Taktik zielt darauf ab, das rationale Denken des Opfers zu umgehen und es zu einer schnellen, unüberlegten Handlung zu bewegen.

Die Falle: Abfangen von Anmeldedaten und 2FA-Token

Der in der E-Mail enthaltene Link leitete das Opfer auf eine pixelgenaue Nachbildung der npm-Anmeldeseite.¹¹ Diese Seite fungierte jedoch nicht nur als einfache Credential-Harvesting-Seite, sondern als hochentwickelter Adversary-in-the-Middle (AiTM)-Proxy.

Als der Maintainer seinen Benutzernamen, sein Passwort und den zeitkritischen 2FA-Code (TOTP) eingab, erfasste die Phishing-Seite diese Anmeldeinformationen in Echtzeit.³ Die erfassten Daten wurden sofort über eine WebSocket-Verbindung an einen vom Angreifer kontrollierten Endpunkt unter websocket-api2.publicvm[.]com exfiltriert.³ Dies ermöglichte es dem Angreifer, die Anmeldedaten und den gültigen 2FA-Token zu verwenden, um sich bei der echten npm-Website anzumelden, bevor der Token ablief.

Kontoübernahme und Aussperrung

Sobald der Angreifer authentifiziert war, änderte er sofort die mit dem Konto des Maintainers verknüpfte E-Mail-Adresse.¹¹ Dieser Schritt sperrte den rechtmäßigen Besitzer vorübergehend aus seinem eigenen Konto aus und gab dem Angreifer die alleinige Kontrolle, um bösartige Paketversionen zu veröffentlichen.

Die Effektivität dieses Angriffs offenbart eine kritische Schwäche in weit verbreiteten Sicherheitsarchitekturen. Obwohl der Entwickler bewährte Sicherheitspraktiken befolgte und 2FA aktiviert hatte, erwies sich diese Schutzmaßnahme als unzureichend.¹¹ Der Angreifer musste den 2FA-Algorithmus nicht knacken; er umging ihn, indem er einen Proxy zwischen den Benutzer und den legitimen npm-Dienst schaltete. Der Benutzer authentifiziert sich gegenüber dem Proxy des Angreifers, im Glauben, es sei die echte Website. Der Proxy leitet die Anmeldeinformationen an npm weiter, empfängt die 2FA-Aufforderung, präsentiert sie dem Benutzer und fängt dann den 2FA-Token des Benutzers ab. Diese Echtzeit-Weiterleitung macht den 2FA-Token für den Angreifer für eine einzige, erfolgreiche Anmeldung nutzbar.

Dieses Vorgehen beweist, dass standardmäßige TOTP-basierte 2FA-Methoden (wie sie von Apps wie Google Authenticator verwendet werden) grundlegend anfällig für gut ausgeführte AiTM-Phishing-Kampagnen sind. Der Angriff hat nicht die 2FA-Technologie gebrochen, sondern die menschliche Interaktion mit ihr ausgenutzt. Für hochwertige Ziele wie Paket-Maintainer, die als Schlüssel zur Softwarelieferkette fungieren, muss die Sicherheitsgrundlage auf Phishing-resistente MFA-Methoden wie Hardware-Sicherheitsschlüssel (FIDO2/WebAuthn) angehoben werden. Diese binden die Authentifizierungssitzung kryptografisch an die Ursprungsdomain und machen sie immun gegen diese Art von Phishing-Angriffen, da der Schlüssel sich weigern würde, mit der gefälschten Domain zu interagieren.³

Die als Waffe eingesetzten Pakete: Umfang, Zeitachse und Verbreitung

Nach der erfolgreichen Übernahme des Maintainer-Kontos verschwendete der Angreifer keine Zeit und begann, die kompromittierten Pakete als Vektor für die Verbreitung seiner Malware zu nutzen. Die Geschwindigkeit und der Umfang der Operation waren bemerkenswert und verdeutlichen die Effizienz von Supply-Chain-Angriffen in einem hochgradig automatisierten Ökosystem.

Zeitachse des Angriffs

Die kritischen Ereignisse spielten sich innerhalb eines sehr kurzen Zeitfensters ab, was sowohl die Effizienz des Angreifers als auch die schnelle Reaktionsfähigkeit der Community unterstreicht:

8. September 2025, ca. 13:16 UTC: Der Angreifer beginnt mit der Veröffentlichung bösartiger Versionen von Paketen, die vom „qix“-Konto verwaltet werden.¹⁴
ca. 15:20 UTC: Die Sicherheits-Community wird auf verdächtige Aktivitäten aufmerksam. Ein Benutzer im GitHub-Repository debug-js/debug stellt fest, dass eine auf npm veröffentlichte Version nicht im Quellcode-Repository existiert. Dies löst den ersten Alarm aus.¹
ca. 17:39 UTC: Große Infrastrukturanbieter wie Vercel aktivieren ihre Incident-Response-Protokolle, um ihre Kunden und Systeme zu schützen.¹²
Innerhalb weniger Stunden: Die bösartigen Pakete werden von den npm-Administratoren und dem kompromittierten Maintainer, der die Kontrolle über sein Konto wiedererlangt hatte, aus der npm-Registry entfernt.¹ Das Expositionsfenster war auf etwa zwei bis drei Stunden begrenzt.
9. September 2025: Die Kampagne weitet sich aus. Dieselbe Wallet-Drainer-Malware taucht in Paketen auf, die von einem zweiten kompromittierten Konto, „duckdb_admin“, veröffentlicht wurden. Dies bestätigt, dass es sich um eine koordinierte und andauernde Anstrengung handelte.¹

Quantifizierung des potenziellen Schadens

Die potenzielle Reichweite des Angriffs war enorm und machte ihn zu einem der bedeutendsten seiner Art:

Der initiale Angriff kompromittierte mindestens 18 Pakete unter dem „qix“-Konto. Spätere Berichte identifizierten insgesamt 25 bis 27 Pakete, wenn man die duckdb-Kompromittierung und andere kleinere Vorfälle mit einbezieht.⁵
Die kombinierten wöchentlichen Downloads dieser Pakete übersteigen 2,6 Milliarden, was diesen Angriff gemessen an der potenziellen Reichweite wohl zum größten Supply-Chain-Angriff in der Geschichte von npm macht.³
Das Sicherheitsunternehmen Wiz berichtete, dass während des kurzen zweistündigen Zeitfensters der bösartige Code in Assets von mindestens 10 % aller von ihnen überwachten Cloud-Umgebungen entdeckt wurde.⁶ Dies demonstriert die unglaubliche Geschwindigkeit, mit der sich bösartiger Code durch automatisierte CI/CD-Pipelines (Continuous Integration/Continuous Deployment) verbreiten kann.

Kompromittierte Pakete und bösartige Versionen

Die folgende Tabelle bietet eine konsolidierte Übersicht der primär betroffenen Pakete, ihrer bösartigen Versionen und der ungefähren wöchentlichen Downloadzahlen. Diese Daten sind entscheidend für Organisationen, um ihre Exposition zu bewerten und sofortige Abhilfemaßnahmen zu ergreifen.

Paketname	Bösartige Version(en)	Ungefähre wöchentliche Downloads	Maintainer-Konto
debug	4.4.2	357,6 Mio.	qix
chalk	5.6.1	300 Mio.	qix
ansi-styles	6.2.2	371,4 Mio.	qix
strip-ansi	7.1.1	261,2 Mio.	qix
supports-color	10.2.1	287,1 Mio.	qix
ansi-regex	6.2.1	243,6 Mio.	qix
wrap-ansi	9.0.1	198 Mio.	qix
color-convert	3.1.1	193,5 Mio.	qix
color-name	2.0.1	191,7 Mio.	qix
is-arrayish	0.3.3	73,8 Mio.	qix
slice-ansi	7.1.1	59,8 Mio.	qix
error-ex	1.3.3	47,2 Mio.	qix
color-string	2.1.1	27,5 Mio.	qix
simple-swizzle	0.2.3	26,3 Mio.	qix
supports-hyperlinks	4.1.1	19,2 Mio.	qix
has-ansi	6.0.1	12,1 Mio.	qix
chalk-template	1.1.1	3,9 Mio.	qix
backslash	0.2.1	0,26 Mio.	qix
duckdb	1.3.3	Variiert	duckdb_admin
@duckdb/node-api	1.3.3	Variiert	duckdb_admin
@duckdb/node-bindings	1.3.3	Variiert	duckdb_admin
@duckdb/duckdb-wasm	1.29.2	Variiert	duckdb_admin
… (und andere wie proto-tinker-wc, prebid.js)	…	…	…

Detaillierte Malware-Analyse: Der Multi-Chain-Krypto-Drainer

Die bösartige Nutzlast, die in die kompromittierten Pakete eingeschleust wurde, war eine einzelne, stark verschleierte JavaScript-Zeile, die an die index.js-Datei der jeweiligen Pakete angehängt wurde.¹ Trotz ihrer kompakten Form handelte es sich um eine hochentwickelte Malware, die speziell für den Diebstahl von Kryptowährungen im Browserumfeld entwickelt wurde.

Aktivierung und Browser-Environment-Hooking

Die Funktionsweise der Malware war präzise und auf Tarnung ausgelegt:

Verschleierung: Die Nutzlast war stark verschleiert, um eine statische Analyse zu erschweren. Techniken wie hexadezimale Variablennamen und String-Array-Lookups wurden verwendet.⁵ Sicherheitsforscher stellten jedoch fest, dass wahrscheinlich ein gängiges Werkzeug, javascript-obfuscator, verwendet wurde, was die schnelle Deobfuskierung erleichterte.¹⁷
Clientseitige Ausführung: Die Malware war so konzipiert, dass sie ausschließlich in einer clientseitigen Browserumgebung ausgeführt wird. Sie enthielt keine serverseitige (Node.js) Logik, was sie für viele Backend-Sicherheitsscanner unsichtbar machte.³
Umgebungserkennung: Nach der Ausführung bestand der erste Schritt darin, das Vorhandensein von Web3-Browser-Wallets zu erkennen, indem nach dem window.ethereum-Objekt gesucht wurde, das von Wallets wie MetaMask in die Browserumgebung injiziert wird.⁷
API-Hooking: Wenn ein Wallet erkannt wurde, „hakte“ sich die Malware in zentrale Browser-Netzwerkfunktionen ein, darunter fetch und XMLHttpRequest, sowie in Wallet-spezifische APIs wie window.ethereum.request.³ Dadurch positionierte sich die Malware effektiv als „Man-in-the-Browser“ und konnte alle relevanten ein- und ausgehenden Daten inspizieren und manipulieren.

Logik zur Transaktionsabfangung und -umleitung

Die Malware war für mehrere Blockchains ausgelegt und enthielt Logik zur Identifizierung und Manipulation von Adressen und Transaktionen für Ethereum, Bitcoin, Solana, Tron, Litecoin und Bitcoin Cash.⁵

Passiver Adressentausch: Bei allgemeinem Webverkehr, der über fetch und XMLHttpRequest abgefangen wurde, scannte die Malware JSON-Antworten nach Zeichenketten, die Mustern von Kryptowährungsadressen entsprachen. Bei einem Treffer ersetzte sie die legitime Adresse durch eine vom Angreifer kontrollierte, bevor die Daten in der Anwendung gerendert wurden.²
Aktive Transaktionsumleitung: Dies war der fortschrittlichere Vektor. Wenn ein Benutzer eine Transaktion mit seinem Web3-Wallet initiierte, fing die Malware den Aufruf ab, bevor er zur Signierung an das Wallet gesendet wurde. Sie zielte speziell auf wichtige Ethereum-Smart-Contract-Funktionen anhand ihrer Funktionsselektoren ab:⁷
- approve() (0x095ea7b3): Die Malware änderte die „Spender“-Adresse in die eines Angreifers und setzte den Genehmigungsbetrag auf den maximal möglichen Wert.
- transfer() (0xa9059cbb): Sie ersetzte die Empfängeradresse durch die eines Angreifers.
- transferFrom() (0x23b872dd): Sie modifizierte den Aufruf, um Token aus einer genehmigten Zuweisung zu stehlen.
- permit() (0xd505accf): Sie manipulierte gaslose Genehmigungssignaturen.

Der Schlüssel zu diesem Angriff liegt darin, dass die Manipulation stattfindet, bevor der Benutzer die Transaktion signiert. Der Benutzer sieht in seinem Wallet eine Bestätigungsaufforderung, die legitim aussehen mag, aber die zugrunde liegenden Parameter wurden bereits bösartig verändert.²

Die Kunst der Täuschung: Fortschrittlicher Adressentausch mit Levenshtein-Distanz

Das raffinierteste und innovativste Merkmal der Malware war ihre Methode zur Adressersetzung. Anstatt einfach die Adresse des Opfers durch eine einzige Angreiferadresse zu ersetzen, enthielt die Malware eine fest codierte Liste von 280 Angreifer-Wallets.¹⁰

Wenn sie eine legitime Zieladresse abfing, iterierte sie durch ihre Wallet-Liste und verwendete den Levenshtein-Distanz-Algorithmus, um die „Editierdistanz“ (die Anzahl der Einzelzeichenänderungen, die erforderlich sind, um eine Zeichenkette in eine andere umzuwandeln) zwischen der legitimen Adresse und jeder ihrer eigenen zu berechnen.²

Anschließend wählte sie die vom Angreifer kontrollierte Adresse aus, die der ursprünglichen Adresse visuell am ähnlichsten war (d. h. die geringste Editierdistanz aufwies). Wenn ein Benutzer beispielsweise beabsichtigte, Geld an 0xAbC123...DEF zu senden, könnte die Malware diese durch ihre eigene Adresse 0xAcB123...DFF ersetzen. Für das bloße Auge, insbesondere bei langen hexadezimalen Zeichenketten, ist diese Änderung während einer abschließenden Transaktionsüberprüfung nahezu unmöglich zu erkennen.

Diese Technik stellt eine signifikante Weiterentwicklung von Finanz-Malware dar. Sie geht über rein technische Exploits (wie API-Hooking) hinaus und integriert Prinzipien der kognitiven Psychologie. Sie nutzt gezielt die Grenzen der menschlichen Aufmerksamkeit und Mustererkennung aus, um die manuelle Transaktionsüberprüfung zu umgehen. Der Standard-Sicherheitshinweis für Krypto-Benutzer lautet: „Überprüfen Sie immer die Adresse, bevor Sie signieren.“ Der Angreifer antizipierte diesen Abwehrmechanismus. Er erkannte, dass ein grober Adressentausch (z. B. das Ersetzen einer Adresse, die mit 0xA beginnt, durch eine, die mit 0x9 beginnt) von einem sorgfältigen Benutzer bemerkt werden könnte. Der Levenshtein-Algorithmus ist eine rechnerische Methode zur Quantifizierung von „visueller Ähnlichkeit“. Durch seine Implementierung automatisierte der Angreifer den Prozess, aus seinem Pool die täuschendste Ersatzadresse zu finden.

Dies zielt direkt auf die menschliche Schwachstelle in der Sicherheitskette ab. Es geht davon aus, dass der Benutzer die Adresse zwar überprüfen wird, aber nicht in der Lage ist, die subtilen Einzelzeichenunterschiede wahrzunehmen. Dies erhöht die Anforderungen an die benutzerseitige Sicherheit erheblich. Es legt nahe, dass eine einfache manuelle Überprüfung keine zuverlässige Verteidigung mehr darstellt. Zukünftige Sicherheitslösungen müssen möglicherweise eine automatisierte Adressanalyse integrieren, die Unterschiede zwischen einer beabsichtigten und einer endgültigen Empfängeradresse hervorhebt, oder sich stärker auf Adressbuch-Whitelisting und ENS-Namen (Ethereum Name Service) verlassen, um die Abhängigkeit von rohen hexadezimalen Zeichenketten zu verringern.

Folgenabschätzung: Weitreichende Störung versus minimaler Diebstahl

Die Analyse der Auswirkungen des Angriffs offenbart ein tiefes Paradoxon: Trotz des massiven Umfangs und der hochentwickelten Nutzlast war der direkte finanzielle Diebstahl erstaunlich gering. On-Chain-Analysen von Firmen wie Arkham und Aikido Security verfolgten die gestohlenen Gelder zu den Wallets des Angreifers und bezifferten den Gesamtbetrag auf lediglich zwischen 500 und 1.000 US-Dollar.⁵

Die wahren Kosten: Ein globaler „Denial-of-Service“ für die Produktivität

Die eigentliche Auswirkung war nicht der finanzielle Diebstahl, sondern die massive, branchenweite Störung. Sicherheits- und Ingenieurteams in Tausenden von Unternehmen weltweit investierten unzählige Stunden in die Notfall-Reaktion.⁶ Zu den Aktivitäten gehörten:

Identifizierung der Exposition durch Scannen von Abhängigkeitsbäumen.
Bereinigung von Build-Caches.
Rotation von Anmeldeinformationen.
Erzwingung sauberer Neuinstallationen von Abhängigkeiten.
Neuerstellung und erneute Bereitstellung von Anwendungen.
Kommunikation mit Kunden.¹²

Dies stellt einen erheblichen finanziellen Aufwand in Form von verlorener Produktivität und Ingenieurressourcen dar, der weltweit wahrscheinlich Millionen von Dollar beträgt und den gestohlenen Betrag bei weitem übersteigt.

Analyse des geringen Ertrags

Mehrere Faktoren trugen zu dem geringen finanziellen Erfolg des Angreifers bei:

Schnelle Reaktion der Community: Der Hauptgrund für den geringen Ertrag war die Geschwindigkeit der Reaktion der Open-Source-Community. Die bösartigen Pakete wurden innerhalb eines Zeitfensters von zwei bis drei Stunden identifiziert und entfernt, was die Zeit, in der die Malware heruntergeladen und bereitgestellt werden konnte, stark einschränkte.¹
Implementierungsfehler: Die Malware enthielt Fehler. Insbesondere prüfte sie nicht, ob die fetch-API definiert war, bevor sie versuchte, sich einzuhaken. In Nicht-Browser-Umgebungen wie CI/CD-Runnern führte dies dazu, dass Builds mit Fehlern abstürzten. Dies fungierte als unbeabsichtigtes, aber hochwirksames Frühwarnsystem, das Entwickler auf ein Problem aufmerksam machte.⁹
Mögliche Absicht des Angreifers: Dies führt zu mehreren Hypothesen über das wahre Motiv des Angreifers:
- Ein gescheiterter Raubüberfall: Der Angreifer war ehrgeizig, wurde aber durch seine eigenen Programmierfehler und die schnelle Reaktion der Community vereitelt.
- Ein Proof-of-Concept oder Feldtest: Der Angriff war eine Live-Übung, um die Wirksamkeit der Phishing-Kampagne und der Malware-Nutzlast zu testen, mit der Absicht, die Werkzeuge für einen zukünftigen, heimlicheren Angriff zu verfeinern.
- Störung als Ziel: Das Hauptziel könnte darin bestanden haben, Chaos zu verursachen, das Vertrauen in das Open-Source-Ökosystem zu untergraben und die Reaktionszeit des „Immunsystems“ der Branche zu messen.

Threat Intelligence und handlungsrelevante Indicators of Compromise (IOCs)

Dieser Abschnitt konsolidiert alle bekannten technischen Indikatoren, die mit der Angriffskampagne in Verbindung stehen. Diese Informationen sind für Threat Hunting, Incident Response und die zukünftige Erkennung von entscheidender Bedeutung. Sicherheitsanalysten können diese IOCs direkt in ihre Sicherheitsinformations- und Ereignismanagement-Systeme (SIEM), Firewalls und Endpunkterkennungslösungen integrieren, um automatisierte Warnungen für vergangene oder zukünftige Aktivitäten im Zusammenhang mit dieser Kampagne zu erstellen.

Konsolidierte Indicators of Compromise (IOCs)

Die folgende Tabelle dient als zentrale Informationsquelle für Sicherheitsteams und erleichtert die forensische Analyse, indem sie die notwendigen Artefakte zur Durchsuchung von Protokollen, Codebasen und Netzwerkverkehr bereitstellt.

IOC-Typ	Wert	Beschreibung/Kontext	Quelle(n)
Phishing-Domain	`npmjs[.]help`	Domain, die zur Haltung der Credential-Harvesting-Seite verwendet wurde.	5
Phishing-IP	`185.7.81.108`	IP-Adresse, auf die die Phishing-Domain aufgelöst wurde.	3
Credential Exfiltration	`websocket-api2.publicvm[.]com`	WebSocket-Endpunkt zur Exfiltration der erfassten Anmeldedaten.	3
CDN-Buckets	`static-mw-host.b-cdn[.]net`, `img-data-backup.b-cdn[.]net`	Vom Angreifer kontrollierte CDN-Buckets zur Bereitstellung von Inhalten der Phishing-Seite.	10
Angreifer-Wallet (ETH)	`0xFc4a4858bafef54D1b1d7697bfb5c52F4c166976`	Primäre Ethereum-Adresse, die für die Umleitung von approve, transfer usw. verwendet wurde.	2
Angreifer-Wallet (SOL)	`19111111111111111111111111111111`	Platzhalter-/Wegwerfadresse für Solana, die Transaktionen effektiv unterbrach.	10
Code-Artefakte	`_0x112fa8`, `checkethereumw`, `runmask`, `stealthProxyControl`	Eindeutige Funktions-/Variablennamen in der verschleierten/entschleierten Nutzlast.	3
Funktionsselektoren	`0x095ea7b3`, `0xd505accf`, `0xa9059cbb`, `0x23b872dd`	Von der Malware anvisierte Ethereum-Funktionsselektoren.	7

Strategische Gegenmaßnahmen und Härtung der Lieferkette

Dieser Vorfall erfordert eine mehrschichtige Verteidigungsstrategie, die von sofortigen taktischen Abhilfemaßnahmen bis hin zur langfristigen strategischen Härtung der Softwarelieferkette reicht.

Sofortige Abhilfemaßnahmen für betroffene Organisationen

Organisationen, die potenziell betroffen sind, sollten unverzüglich die folgenden Schritte einleiten:

Audit und Identifizierung: Scannen Sie sofort alle Projekte auf die in der Tabelle aufgeführten kompromittierten Paketversionen, indem Sie Werkzeuge wie npm audit oder andere Software Composition Analysis (SCA)-Lösungen verwenden.¹²
Eindämmung und Beseitigung:
- Isolieren Sie alle betroffenen Build-Server oder Entwicklermaschinen.³
- Löschen Sie node_modules-Verzeichnisse und Lockfiles (package-lock.json, yarn.lock).³
- Leeren Sie alle lokalen und entfernten Caches (npm cache clean --force, CI/CD-Caches, CDN-Caches), um eine Wiedereinführung des bösartigen Codes zu verhindern.¹²
Wiederherstellung:
- Pinnen Sie alle Abhängigkeiten auf bekannte, gute Versionen, die vor dem Angriff veröffentlicht wurden.¹⁹
- Führen Sie eine saubere Installation mit npm ci durch, um sicherzustellen, dass der Build ausschließlich auf dem geprüften Lockfile basiert.¹
- Erstellen und implementieren Sie alle betroffenen Anwendungen neu.³
- Rotieren Sie vorsorglich alle auf den betroffenen Systemen vorhandenen Anmeldeinformationen und Geheimnisse.³

Proaktive Verteidigung für Entwickler und Unternehmen

Um zukünftige Angriffe zu verhindern, sollten Organisationen die folgenden proaktiven Maßnahmen ergreifen:

Abhängigkeitshygiene: Fordern Sie die Verwendung von Lockfiles und reproduzierbaren Builds (npm ci) in allen CI/CD-Pipelines, um unerwartete Abhängigkeitsaktualisierungen zu verhindern.¹
Interne Registries: Nutzen Sie eine vertrauenswürdige interne oder private Paket-Registry, die als Proxy zur öffentlichen npm-Registry fungiert. Dies ermöglicht das Scannen, Überprüfen und Blockieren von Paketen, bevor sie in die Entwicklungsumgebung gelangen.⁵
Automatisiertes Scannen: Integrieren Sie robuste Abhängigkeitsscans (SCA) und statische Analysetools (SAST) in die CI/CD-Pipeline, um bekannte Schwachstellen und verdächtige Codemuster zu erkennen.¹²
Laufzeitschutz: Implementieren Sie eine Verhaltensanalyse zur Laufzeit und eine starke Content Security Policy (CSP), um bösartige clientseitige Aktivitäten wie unbefugtes API-Hooking oder Verbindungen zu verdächtigen Domains zu erkennen und zu blockieren.

Stärkung der Grundlagen: Empfehlungen für Maintainer und Registries

Die Sicherheit des gesamten Ökosystems hängt von den Praktiken seiner zentralen Akteure ab:

Phishing-resistente MFA durchsetzen: Paket-Registries wie npm sollten die Verwendung von Hardware-Sicherheitsschlüsseln (FIDO2/WebAuthn) für Maintainer kritischer Pakete dringend empfehlen oder vorschreiben, da dies die wirksamste Verteidigung gegen AiTM-Phishing ist.³
Veröffentlichungsprozess härten: Implementieren Sie strengere Kontrollen für den Veröffentlichungsprozess, z. B. die Forderung nach der Genehmigung durch mehrere Maintainer für neue Versionen von stark heruntergeladenen Paketen (ein „Multi-Sig“-Ansatz).³
Paketsignierung und Provenienz: Fördern und erweitern Sie die Einführung von Paketsignaturen (z. B. Sigstore) und Provenienzfunktionen. Diese bieten kryptografische Garantien darüber, wer ein Paket veröffentlicht hat und in welcher CI/CD-Umgebung es erstellt wurde, was es schwieriger macht, bösartigen Code unentdeckt einzuschleusen.³

Kontextanalyse: Die sich entwickelnde Landschaft der Supply-Chain-Angriffe

Dieser Angriff war keine Anomalie, sondern die Ausführung eines etablierten Drehbuchs, das von hochentwickelten Bedrohungsakteuren, einschließlich Advanced Persistent Threats (APTs) wie der Lazarus-Gruppe, verwendet wird.²¹ Die zentralen Taktiken, Techniken und Prozeduren (TTPs) – das Anvisieren von Maintainern populärer, aber unterfinanzierter Projekte mittels Social Engineering, um einen massiven Vertriebskanal zu gewinnen – sind ein wiederkehrendes Thema in der Sicherheit von Lieferketten.

Vergleich mit anderen npm-Angriffen

event-stream (2018): Ein ähnlicher Angriff, bei dem ein Maintainer die Kontrolle an einen bösartigen Akteur übergab, der dann eine Krypto-Stealing-Nutzlast einschleuste. Der chalk/debug-Angriff unterscheidet sich durch den Einsatz von aktivem Phishing anstelle von Social Engineering, um über einen längeren Zeitraum Vertrauen aufzubauen.
ua-parser-js (2021): Eine weitere Kontoübernahme, die zur Bereitstellung eines Credential-Stealers und Krypto-Miners führte. Die chalk/debug-Malware ist aufgrund ihres clientseitigen Fokus und fortschrittlicher Täuschungstechniken wie dem Levenshtein-Distanz-Algorithmus ausgefeilter.
Typosquatting/Dependency Confusion: Dieser Angriffsvektor unterscheidet sich von Kampagnen, die darauf abzielen, Entwickler zur Installation von Paketen mit ähnlichen Namen zu verleiten (z. B. die Verwechslung von colorama und colorizr).¹⁸ Hier wurde das Vertrauen in den legitimen Paketnamen als Waffe eingesetzt.

Aufkommende Trends

Die Analyse dieses Vorfalls offenbart mehrere wichtige Trends in der Bedrohungslandschaft:

Verlagerung zu clientseitigen Nutzlasten: Es gibt einen wachsenden Trend zu Malware, die für die Ausführung im Browser des Endbenutzers konzipiert ist. Dies umgeht traditionelle serverseitige Abwehrmaßnahmen und verlagert das Risiko auf die Kunden.
Zunehmende Raffinesse des Social Engineering: Phishing-Kampagnen werden personalisierter, technisch fortschrittlicher (AiTM) und potenziell KI-gestützt, was ihre Erkennung erschwert.¹³
Der Maintainer als Hauptziel: Bedrohungsakteure haben erkannt, dass die Kompromittierung eines einzigen, vertrauenswürdigen Maintainers eines grundlegenden Open-Source-Projekts einen unvergleichlichen Return on Investment für die Malware-Verbreitung bietet. Dies macht diese Personen zu hochwertigen Zielen und unterstreicht die systemische Fragilität eines Ökosystems, das auf den Sicherheitspraktiken einzelner Freiwilliger beruht.⁴ Der Vorfall ist eine deutliche Mahnung, dass die Sicherheit der Softwarelieferkette eine kollektive Verantwortung ist, die robuste technische Kontrollen, eine erhöhte Wachsamkeit der Maintainer und eine grundlegende Neubewertung des Vertrauensmodells erfordert, das der Open-Source-Entwicklung zugrunde liegt.

Referenzen

Security Alert | chalk, debug and color on npm compromised in new …, Zugriff am September 11, 2025, https://semgrep.dev/blog/2025/chalk-debug-and-color-on-npm-compromised-in-new-supply-chain-attack/
Open Source Community Thwarts Massive npm Supply Chain Attack – Infosecurity Magazine, Zugriff am September 11, 2025, https://www.infosecurity-magazine.com/news/npm-supply-chain-attack-averted/
Browser-Based Crypto-Stealer in NPM Supply Chain Attack … – SISA, Zugriff am September 11, 2025, https://www.sisainfosec.com/blogs/browser-based-crypto-stealer-in-npm-supply-chain-attack-advisory-by-sisa-sappers/
Largest NPM Supply Chain Attack : Billions of Downloads, Zugriff am September 11, 2025, https://underdefense.com/blog/npm-supply-chain-attack/
Hackers Compromise 18 NPM Packages in Supply Chain Attack, Zugriff am September 11, 2025, https://www.bankinfosecurity.com/hackers-compromise-18-npm-packages-in-supply-chain-attack-a-29396
Widespread npm Supply Chain Attack: Breaking Down Impact … – Wiz, Zugriff am September 11, 2025, https://www.wiz.io/blog/widespread-npm-supply-chain-attack-breaking-down-impact-scope-across-debug-chalk
NPM Supply Chain Attack Hits Popular Packages with Crypto Drainer – Mend.io, Zugriff am September 11, 2025, https://www.mend.io/blog/npm-supply-chain-attack-infiltrates-popular-packages/
Critical npm Supply Chain Attack – eSentire, Zugriff am September 11, 2025, https://www.esentire.com/security-advisories/critical-npm-supply-chain-attack
NPM supply chain attack on crypto contained with ‚almost no victims,‘ Ledger CTO says, Zugriff am September 11, 2025, https://www.theblock.co/post/369984/npm-supply-chain-attack-on-crypto-contained-with-almost-no-victims-ledger-cto-says
Oops, No Victims: The Largest Supply Chain Attack Stole 5 Cents – Security Alliance, Zugriff am September 11, 2025, https://www.securityalliance.org/news/2025-09-npm-supply-chain
18 Popular Code Packages Hacked, Rigged to Steal Crypto – Krebs on Security, Zugriff am September 11, 2025, https://krebsonsecurity.com/2025/09/18-popular-code-packages-hacked-rigged-to-steal-crypto/
Critical npm supply chain attack response – September 8, 2025 – Vercel, Zugriff am September 11, 2025, https://vercel.com/blog/critical-npm-supply-chain-attack-response-september-8-2025
AI-Generated Phishing: How One Email Triggered a Global NPM Supply Chain Crisis, Zugriff am September 11, 2025, https://www.varonis.com/blog/npm-hijacking
npm debug and chalk packages compromised – Aikido, Zugriff am September 11, 2025, https://www.aikido.dev/blog/npm-debug-and-chalk-packages-compromised
npm Supply Chain Attack: Massive Compromise of debug, chalk, and 16 Other Packages, Zugriff am September 11, 2025, https://www.upwind.io/feed/npm-supply-chain-attack-massive-compromise-of-debug-chalk-and-16-other-packages
Malicious npm Code Reached 10% of Cloud Environments – Infosecurity Magazine, Zugriff am September 11, 2025, https://www.infosecurity-magazine.com/news/malicious-npm-code-10-cloud/
New compromised packages in largest npm attack in history – JFrog, Zugriff am September 11, 2025, https://jfrog.com/blog/new-compromised-packages-in-largest-npm-attack-in-history/
Chalk And 17 Other NPM Packages Compromised In Supply-Chain …, Zugriff am September 11, 2025, https://checkmarx.com/zero-post/chalk-and-17-other-npm-packages-compromised-in-supply-chain-attack/
Major Supply Chain Attack Compromises Popular npm Packages Including chalk and debug, Zugriff am September 11, 2025, https://www.endorlabs.com/learn/major-supply-chain-attack-compromises-popular-npm-packages-including-chalk-and-debug
Major NPM Supply-Chain Attack: Potential Impact on Mobile …, Zugriff am September 11, 2025, https://www.nowsecure.com/blog/2025/09/08/major-npm-supply-chain-attack-potential-impact-on-mobile-applications/
npm Chalk and Debug Packages Hit in Software Supply Chain Attack, Zugriff am September 11, 2025, https://www.sonatype.com/blog/npm-chalk-and-debug-packages-hit-in-software-supply-chain-attack