Die offizielle Client-Software für das Derivateprotokoll dYdX v4 ist Ziel eines ausgefeilten Supply-Chain-Angriffs geworden. Kompromittierte Pakete in den Ökosystemen npm und PyPI wurden genutzt, um Seed-Phrasen von Krypto-Wallets zu stehlen und einen vollwertigen Remote-Access-Trojaner (RAT) in Entwickler- und Produktionsumgebungen einzuschleusen. Angesichts eines kumulierten Handelsvolumens von über 1,5 Billionen US‑Dollar und täglichen Volumina im mittleren dreistelligen Millionenbereich ist dies ein sicherheitsrelevanter Vorfall für das gesamte Krypto-Ökosystem.
Supply-Chain-Angriff auf dYdX v4: Kompromittierte npm- und PyPI-Pakete
Nach Angaben des Sicherheitsunternehmens Socket wurden zwei zentrale Clients für das dYdX v4-Protokoll manipuliert: das npm-Paket @dydxprotocol/v4-client-js und das Python-Paket dydx-v4-client auf PyPI. Diese Bibliotheken werden eingesetzt, um Transaktionen zu signieren, Orders zu platzieren und Wallet-Zugriffe zu verwalten – sie befinden sich damit im hochvertrauenswürdigen Kern der Infrastruktur von Börsen, Bots und institutionellen Nutzern.
Die Angreifer veröffentlichten scheinbar legitime Updates über die offiziellen dYdX-Accounts in den Paketregistern. Das spricht für eine Kompromittierung von Entwicklerkonten und nicht für eine Schwachstelle in npm oder PyPI selbst. Betroffen waren die Versionen 3.4.1, 1.22.1, 1.15.2, 1.0.31 von @dydxprotocol/v4-client-js sowie 1.1.5post1 von dydx-v4-client.
Der Vorfall reiht sich in eine wachsende Zahl von Supply-Chain-Angriffen ein, bei denen Angreifer nicht die Zielorganisation direkt attackieren, sondern Vertrauensanker in der Software-Lieferkette missbrauchen. Branchenberichte von ENISA, NIST und spezialisierten Security-Anbietern zeigen seit Jahren einen deutlichen Anstieg solcher Angriffe auf Paketmanager wie npm, PyPI oder RubyGems.
JavaScript-Payload in npm: Seed-Phrase-Diebstahl und Geräte-Fingerprinting
Im npm-Ökosystem wurde der bösartige Code in die zentralen Dateien registry.ts und registry.js integriert – Komponenten, die bei normaler Nutzung des Clients zwangsläufig ausgeführt werden. Die modifizierte Logik fing Seed-Phrasen von Wallets ab und ergänzte diese um einen detaillierten Geräte-Fingerprint.
Die Exfiltration erfolgte an den Domainnamen dydx.priceoracle[.]site, der mittels Typosquatting gezielt an den legitimen dYdX-Auftritt (dydx.xyz) angelehnt ist. Durch die Kombination von Seed-Phrase und Geräteprofil können Angreifer:
- Opfer über mehrere Kompromittierungen hinweg eindeutig wiedererkennen,
- gezielt hochvolumige oder institutionelle Konten priorisieren,
- gestohlene Seeds mit On-Chain-Aktivitäten korrelieren und Bewegungsprofile erstellen.
PyPI-Paket mit integriertem RAT-Trojaner
Das manipulierte Python-Paket dydx-v4-client ging noch einen Schritt weiter. Neben dem Diebstahl von Seed-Phrasen enthielt es einen Remote Access Trojaner (RAT), der unmittelbar nach dem Import des Moduls aktiviert wird und im Hintergrund als Dämon-Thread läuft.
Alle 10 Sekunden baut der Trojaner eine Verbindung zu dydx.priceoracle[.]site auf, authentifiziert sich mit einem hartkodierten Token 490CD9DAD3FAE1F59521C27A96B32F5D677DD41BF1F706A0BF85E69CA6EBFE75 und lädt von dort beliebigen Python-Code nach. Dieser wird in einem separaten Subprozess ausgeführt; unter Windows wird der Prozess mit dem Flag CREATE_NO_WINDOW gestartet, sodass kein Konsolenfenster erscheint und die Aktivität weitgehend unsichtbar bleibt.
RAT in Entwicklerumgebungen: Angriffsfläche weit über Krypto-Assets hinaus
Mit einem solchen RAT erhalten Angreifer de facto eine Remote-Shell im Kontext des betroffenen Benutzers. In Entwicklungs- und Betriebsumgebungen eröffnet dies ein breites Spektrum an Angriffsmöglichkeiten:
- Ausführung beliebigen Codes mit den Rechten des Entwicklers oder Service-Accounts,
- Diebstahl von SSH-Schlüsseln, API-Tokens, Wallet-Dateien und CI/CD-Konfigurationen,
- Exfiltration von proprietärem Quellcode und internen Tools,
- Nachladen weiterer Malware und Persistenzmechanismen,
- Manipulation kritischer Repositories und Build-Pipelines,
- Lateral Movement in andere Systeme und Cloud-Umgebungen.
Gerade im Trading-Umfeld, in dem häufig automatisierte Bots, Hochfrequenzstrategien und komplexe Infrastruktur genutzt werden, kann ein solcher Fernzugriff zu erheblichen finanziellen und regulatorischen Schäden führen.
Gezielte Kampagne: dYdX als wiederkehrendes Angriffsziel
Die verwendeten Dateien – registry.ts/registry.js im JavaScript-Client und account.py im Python-Client – zeigen, dass die Angreifer die Architektur der dYdX-Software detailliert verstanden haben. Der PyPI-Schadcode wurde zudem mehrfach obfuskiert, was auf eine professionelle Vorbereitung und langfristige Planung schließen lässt.
Der aktuelle Vorfall steht nicht isoliert: Bereits 2022 wurde ein npm-Account eines dYdX-Mitarbeiters kompromittiert und zur Verteilung datendiebstahlender Pakete genutzt. 2024 kam es zu einem DNS Hijacking der dYdX v3-Website, bei dem Nutzer auf eine Phishing-Seite umgeleitet wurden, die schädliche Transaktionen unterschieben sollte. Zusammengenommen entsteht das Bild einer anhaltenden, zielgerichteten Kampagne, die systematisch vertrauenswürdige Distributionskanäle wie DNS, Paketregister und Entwicklerkonten missbraucht.
Schutz der Software-Lieferkette und von Krypto-Assets: praktische Maßnahmen
Die dYdX-Entwickler bestätigten den Vorfall am 28. Januar 2026 und betonten, dass der GitHub-Quellcode im Repository dydxprotocol sowie die dort verfügbaren Paketversionen als sauber gelten. Der Angriff konzentrierte sich auf die in npm und PyPI veröffentlichten Artefakte – ein klassisches Muster moderner Supply-Chain-Angriffe.
Für Organisationen, die mit Krypto-Protokollen oder sensiblen Finanzdaten arbeiten, lassen sich aus diesem Fall mehrere konkrete Handlungsfelder ableiten:
- Starke Absicherung von Entwicklerkonten: verpflichtende Nutzung von FIDO2-/Hardware-Token, strikte MFA, rollenbasierte Berechtigungen und regelmäßige Überprüfung von Zugriffsrechten auf Paketregister.
- Security-Scanning von Abhängigkeiten: Einsatz von Software Composition Analysis (SCA), Monitoring von Änderungen in kritischen Bibliotheken und automatisierte Prüfungen auf Anomalien in neuen Versionen.
- Vertrauenswürdige Build-Prozesse: reproduzierbare Builds, signierte Releases, getrennte Build- und Entwicklungsumgebungen sowie interne Spiegel (Mirrors) wichtiger Open-Source-Repositories.
- Härtung von Krypto-Workflows: keine langfristige Aufbewahrung großer Beträge in Wallets, deren Seed-Phrasen jemals in Entwicklungs- oder Testumgebungen eingegeben wurden; bei Verdacht konsequentes Rotieren von Seeds und Schlüsseln.
Wer Krypto-Assets, Handelsinfrastruktur oder kritische Anwendungen betreibt, sollte die Software-Lieferkette wie ein eigenes, schützenswertes System behandeln: mit kontinuierlicher Überwachung, klar definierten Prozessen und technischer Abwehr auf mehreren Ebenen. Je früher Organisationen solche Praktiken etablieren, desto schwerer wird es Angreifern, vergleichbare Supply-Chain-Angriffe erfolgreich gegen das Krypto-Ökosystem zu richten.
