Nordkorea hinter den npm-Angriffen auf debug, chalk und axios: Die Attribution von Amazon

Einleitung

Am 29. Juli 2026 hat Amazon Threat Intelligence mit mittlerer Sicherheit die Kompromittierung einiger der weltweit meistgenutzten npm-Pakete der nordkoreanischen Gruppe Sapphire Sleet (auch als UNC1069 oder BlueNoroff verfolgt) zugeschrieben. Die Untersuchung führt erstmals drei Kampagnen auf eine gemeinsame Urheberschaft zurück, die innerhalb von zwölf Monaten debug und chalk (September 2025), axios (März 2026) sowie die bösartige Veröffentlichung des Pakets typo‑crypto (März 2025) betrafen.
Frühere Analysen von Aikido und Wiz hatten keinen spezifischen Akteur identifiziert: Jetzt rundet sich das Bild und zeigt eine anhaltende, finanziell motivierte Bedrohung der Open-Source-Softwarelieferkette.

Technische Analyse

Vergleich der drei Kampagnen

Die Operationen zeigen unterschiedliche Angriffstechniken, was auf einen Gegner schließen lässt, der sich an Sicherheitskontrollen anpassen kann.

• debug und chalk (September 2025): Die Angreifer kompromittierten die Maintainer-Konten durch Social Engineering und veröffentlichten infizierte Updates. Der eingeschleuste Schadcode – ein browserbasiertes Skript – nutzte keine npm-Hooks wie postinstall, sondern wurde direkt ausgeführt, wenn Webanwendungen die Pakete luden. Durch das Abfangen von fetch, XMLHttpRequest und den APIs von Krypto-Wallets veränderte der Code stillschweigend die Transaktionsadressen (Wallet-Drainer), ohne eine Persistenz auf dem Gerät zu installieren.
• typo‑crypto (31. März 2025): Ein gefälschtes Paket, das crypto‑js imitierte (Typosquatting), wurde als eigenständiges Paket veröffentlicht, nicht durch einen kompromittierten Maintainer. Es enthielt einen verschleierten Trigger (XOR mit Schlüssel 01042025), der nur unter bestimmten Bedingungen aktiv wurde – vermutlich ein Testlauf zur Verfeinerung der Techniken.
• axios und Mastra (März 2026): Der Zugriff auf die Maintainer erlaubte das Einfügen von Lifecycle-Skripten (postinstall), die eine Backdoor (WAVESHAPER.V2) zum Diebstahl von Zugangsdaten und zur lateralen Bewegung in Entwicklungsumgebungen verteilten.

Beweise und Diskrepanzen

Die von Amazon vorgelegten öffentlichen Belege – Wiederverwendung von Code und gemeinsame C2-Infrastrukturen (npmjs[.]store, IP 216.74.123.126) – geben jedoch keine genaue Auskunft über das Bindeglied zwischen den Kampagnen. Es zeigen sich einige Ungereimtheiten: Der für core.js angegebene SHA256-Hash stimmt mit keiner Datei im Archiv von typo‑crypto überein, und das Paket scheint eine originäre Typosquatting-Aktion zu sein, nicht die Übernahme eines Maintainer-Kontos.

Google und Microsoft hatten den Angriff auf axios bereits demselben Akteur zugeordnet, doch kein anderer Anbieter hat öffentlich die Verbindung auch für debug, chalk und typo‑crypto bestätigt. Aikido gibt an, die Vorfälle schon länger aufgrund von C2-Überschneidungen zwischen axios und Mastra verknüpft zu haben.

Reaktion der Plattform

npm v12 (veröffentlicht am 8. Juli 2026) deaktiviert standardmäßig Lifecycle-Skripte von Abhängigkeiten und beseitigt damit den von axios ausgenutzten postinstall-Vektor. Allerdings schützt es nicht vor Angriffen wie dem auf debug und chalk, bei denen der Schadcode direkt im Paket ausgeliefert und von den Anwendungen ohne Installations-Hooks ausgeführt wurde.

Auswirkungen

Die betroffenen Pakete verzeichneten über 2 Milliarden wöchentliche Downloads. Der dokumentierte unmittelbare Gewinn beträgt lediglich 600 USD (Quelle Socket), doch das systemische Risiko ist enorm und nach wie vor aktuell.

• Endnutzer: Das Skript in debug/chalk fing Krypto-Transaktionen im Browser ab und leitete die Gelder um, ohne Spuren auf dem Gerät zu hinterlassen.
• Entwickler: Die Backdoor in axios ermöglichte den Zugriff auf Anmeldedaten und Unternehmensumgebungen und setzte interne Netzwerke und Repositories dem Risiko aus.
• Ökosystem: Die Kompromittierung vertrauenswürdiger Maintainer und die Verwendung eines gefälschten Pakets als Test zeigen eine ausgeklügelte Planung und eine reale Bedrohung der Lieferkette, die das Vertrauen in Open-Source-Betreuer ausnutzt.

Gegenmaßnahmen

• Aktualisieren Sie npm auf die neueste Version (v12), um Lifecycle-Skripte zu blockieren; leider reicht dies nicht für Code-injizierende Angriffe wie die gesehenen aus.
• Schützen Sie Maintainer-Konten: Zwei-Faktor-Authentifizierung (2FA) erzwingen, anormale Zugriffe überwachen und jedes verdächtige Update prüfen – das sind unverzichtbare Gegenmaßnahmen.
• Indizien einer Kompromittierung erkennen: Suchen Sie in Ihren Umgebungen nach der Domain npmjs[.]store, der IP 216.74.123.126 und der Datei core.js. Prüfen Sie Webanwendungen auf anomale Hooks in fetch, XMLHttpRequest und Wallet-APIs.
• Integrität der Pakete überprüfen: Vergleichen Sie Hashes mit den angegebenen und seien Sie misstrauisch bei Paketen, deren Autor vom Veröffentlichungskonto abweicht (wie im Fall typo‑crypto).
• Nicht gewartete Abhängigkeiten entfernen und Hinweise wie OSV MAL‑2026‑3400 für typo‑[email protected] konsultieren.
• Analysetools einsetzen (z. B. Socket), um Abhängigkeiten kontinuierlich zu überwachen.

FAQ

1. Wer ist Sapphire Sleet und warum zielt die Gruppe auf npm?

Sapphire Sleet (UNC1069, BlueNoroff, STARDUST CHOLLIMA) ist eine nordkoreanische Gruppierung, die auf Finanzangriffe spezialisiert ist. Sie hatte zuvor Banken und Kryptowährungsbörsen ins Visier genommen; heute hat sie ihre Operationen auf die Software-Lieferkette ausgeweitet, um Schadcode in großem Stil zu verteilen, mit dem Ziel, Kryptowährungen zu stehlen oder Zugang zu Unternehmensnetzwerken zu erlangen. npm ist mit seinen Millionen von Entwicklern ein idealer Vektor.

2. Wie kann ich feststellen, ob ich betroffen bin?

Falls Ihre Anwendung kompromittierte Versionen von debug, chalk oder axios verwendete, untersuchen Sie die clientseitigen Bundles auf Skripte, die fetch oder XMLHttpRequest abfangen. Suchen Sie bei axios in den Netzwerkprotokollen nach Hinweisen auf die C2-Indikatoren (npmjs[.]store, 216.74.123.126) und überprüfen Sie die Integrität der Pakete mithilfe von Hashes und Audit-Tools. Das Vorhandensein der Datei core.js ist ein Warnsignal.

3. Warum reicht npm v12 nicht aus, um diese Angriffe zu blockieren?

npm v12 neutralisiert Lifecycle-Skripte (z. B. postinstall), den von axios genutzten Vektor. Die Angriffe auf debug und chalk injizierten den Code jedoch direkt in die JavaScript-Dateien des Pakets, der ohne Installations-Hooks ausgeführt werden konnte. Daher erfordert der Schutz sichere Entwicklungspraktiken, Integritätsprüfungen und eine kontinuierliche Überwachung der Abhängigkeiten – nicht nur Plattform-Updates.