NPM-Supply-Chain-Angriff auf Krypto-Wallets: Was ist passiert und wie kannst du dich schützen?

In den letzten Tagen hat die Sicherheits-Community der Kryptowelt einen beispiellosen Supply-Chain-Angriff aufgedeckt, der insbesondere Krypto-Nutzer ins Visier nimmt. Über manipulierte NPM-Pakete konnten Angreifer gezielt Adressen von Krypto-Wallets austauschen, um an Gelder ahnungsloser Nutzer zu gelangen. In diesem Artikel erfährst du, wie genau dieser Angriff ablief, warum er so gefährlich ist, welche Wallet-Software betroffen war und wie du dich und deine Krypto-Bestände jetzt am besten schützt.

Was ist eigentlich passiert?

Der Ausgangspunkt des Angriffs war das kompromittierte NPM-Account des renommierten Entwicklers „qix“, bekannt für zahlreiche beliebte JavaScript-Pakete. Nach einer erfolgreichen Phishing-Attacke erhielten die Angreifer Zugang zu seinem Account und veröffentlichten manipulierte Versionen von essenziellen Paketen wie chalk, strip-ansi, color-convert, color-name und mehreren weiteren. Diese Pakete sind zentrale Bausteine in der JavaScript-Welt und werden wöchentlich milliardfach heruntergeladen, selbst von Anwendungen, die nichts direkt mit Krypto zu tun haben.

Die Folgen: Sobald ein Projekt (z.B. eine Wallet-Anwendung) eine der befallenen Versionen installierte oder aktualisierte, wurde Schadsoftware eingeschleust, die Krypto-Transaktionen heimlich auf Wallets der Angreifer umlenken konnte.

Hintergrund: Was bedeutet „Supply-Chain-Angriff“ und warum ist NPM so kritisch?

Supply-Chain-Angriffe richten sich nicht direkt gegen die Endanwender, sondern gegen zentrale Bausteine (Teile der „Lieferkette“) in der Software-Entwicklung. Im Fall von NPM, dem größten Paketmanager für JavaScript, bedeutet das: Mit wenig Aufwand können Angreifer eine riesige Zahl von Anwendungen und somit Nutzer schädigen, indem sie Schadcode in scheinbar harmlose Pakete einschleusen.

Für Nicht-Entwickler ein Vergleich: Stell dir vor, du baust ein Auto und bestellst allerlei Komponenten bei verschiedenen Zulieferern. Wenn einer dieser Zulieferer (z.B. für Bremsen) heimlich fehlerhafte Teile liefert, kann das Auto unabhängig vom Hersteller gefährdet sein.

In Softwareprojekten ist das ähnlich: Entwickler nutzen tausende Bausteine und müssen darauf vertrauen, dass diese sicher sind. Unter den Zielgruppen waren dieses Mal auch zahlreiche Krypto-Wallets und Web-Apps, die auf JavaScript-Ökosysteme setzen.

Wie funktionierte der Angriff technisch?

Zwei Hauptangriffspfade des „Crypto-Clipper“

Die Schadsoftware (Malware) agierte als raffinierter „Crypto-Clipper“ und verfolgte zwei Hauptstrategien:

1. Passives Austauschen von Wallet-Adressen

Wenn im Browser keine Wallet-Erweiterung wie MetaMask gefunden wurde, setzte die Malware zu einem passiven Angriff an: Sie „monkeypatchte“ die Funktionen fetch und XMLHttpRequest. Damit konnte sie den Datenverkehr der Webseite überwachen und Wallet-Adressen im Hintergrund mit eigenen Adressen austauschen.

Clevere Methode: Die Software suchte aus einer langen Liste von Angreifer-Wallets genau die Adresse heraus, die der echten Adresse visuell am ähnlichsten sieht (mittels Levenshtein-Algorithmus, der die Ähnlichkeit von Zeichenfolgen misst). So wird es extrem schwer, einen Tausch auf den ersten Blick zu erkennen – ein perfider Trick!

2. Aktive Übernahme von Transaktionen (bei Wallet-Erkennung)

Falls eine Wallet-Extension wie MetaMask erkannt wurde, startete die Malware einen zielgerichteten Angriff: Sie fing die Kommunikation (request, send) der Wallet ab und manipulierte dort die Zieladresse, bevor der Nutzer die Transaktion signierte. Der Nutzer unterschrieb so – oft ohne es zu merken – eine Transaktion an die Wallet der Angreifer.

Welche Pakete waren betroffen? – Ausmaß des Angriffs

Hier ein Auszug der meistgenutzten Pakete, die kompromittiert wurden (Downloads pro Woche):

• chalk: ~300 Mio.
• strip-ansi: ~261 Mio.
• color-convert: ~193 Mio.
• color-name: ~191 Mio.
• error-ex: ~47 Mio.
• simple-swizzle: ~26 Mio.
• has-ansi: ~12 Mio.

Fast jedes größere JavaScript-Projekt, darunter hunderte Webanwendungen und auch viele Wallets, beziehen eines dieser Pakete direkt oder indirekt.

Wurde der Angriff gestoppt? Gibt es erste Schäden?

Nach der Meldung an den Entwickler und das NPM-Sicherheitsteam wurden bereits viele infizierte Pakete entfernt und die Lücke geschlossen. Es kam laut ersten Berichten nicht zu massenhaften Schäden – vor allem, da bei einigen Build-Prozessen Fehler auftraten und Entwickler stutzig wurden. Hätten diese Hinweise gefehlt (z.B. in moderneren Umgebungen), wäre der Angriff wahrscheinlich weit weniger schnell entdeckt worden.

Allerdings besteht nach wie vor die Gefahr, dass manipulierte Versionen in Projekten verbleiben, etwa durch Lockfiles oder veraltete Package-Versionen.

Wie schützt du dich jetzt? Praktische Tip

1. Keine Panik, aber erhöhte Vorsicht! Wenn du eine reine Software-Wallet (ohne Hardware-Absicherung) nutzt, solltest du bis zur vollständigen Klärung des Angriffs möglichst keine neuen Transaktionen durchführen.
2. Überprüfe deine Wallet-Adressen doppelt – besonders bei Transaktionen! Am sichersten: Vergleiche die Zieladresse am PC/Smartphone mit der Anzeige auf dem Display deiner Hardware-Wallet (sofern vorhanden – Ledger, Trezor, Bitbox, etc.).
3. Setze auf Hardware-Wallets mit Display: Nur Geräte mit Display zeigen die echte Zieladresse unabhängig von deinem Rechner an. Das schützt dich gegen verdeckte Manipulationen in der Software.
4. Als Entwickler:
   • Aktualisiere alle Paketabhängigkeiten (Dependencies)
   • Nutze das overrides-Feature im package.json, um garantiert sichere Versionen zu erzwingen:{ "overrides": { "chalk": "5.3.0", "strip-ansi": "7.1.0", "color-convert": "2.0.1", "color-name": "1.1.4", "is-core-module": "2.13.1", "error-ex": "1.3.2", "has-ansi": "5.0.1" } }
   • Lösche anschließend node_modules und package-lock.json und führe ein frisches npm install durch.
5. Vertraue nicht blind auf Software-Abhängigkeiten! Supply-Chain-Angriffe verdeutlichen, dass grundsätzlich jedes Softwarepaket eine potenzielle Risikoquelle ist. Sensibilisiere dich und andere in deinem Umfeld für solche Gefahren.

Fazit: Handeln, aber mit Augenmaß

Das Krypto-Ökosystem lebt von offenen Bausteinen, gegenseitigem Vertrauen und permanenter Wachsamkeit. Der aktuelle Angriff auf NPM zeigt schmerzhaft, wie großflächig die Folgen sein könnten, wenn ein Schlüsselentwickler kompromittiert wird. Glück im Unglück: Durch Zufall und die rasche Reaktion der Community blieb das Schlimmste diesmal offenbar aus.

Merke: Gehe jede Transaktion bewusst an, prüfe Zieladressen sorgfältig und überstehst du solche Vorfälle am besten mit Hardware-Wallet und gesunder Skepsis beim Thema Software-Updates. Entwickler sind nun in der Pflicht, ihre Projekte zu prüfen und zu härten.

Quellen:

• https://jdstaerk.substack.com/p/we-just-found-malicious-code-in-the
• https://www.reddit.com/r/programming/comments/1nbqt4d/largest_npm_compromise_in_history_supply_chain/
• https://x.com/P3b7_/status/1965336272550899932