- Die bösartigen npm-Pakete colortoolsv2 und mimelib2 haben C2-URLs aus einem Ethereum-Smart Contract abgerufen, um einer Erkennung zu entgehen.
- Durch die On-Chain-Indirektion können Betreiber Endpunkte rotieren, ohne Pakete erneut zu veröffentlichen. Colortoolsv2 wurde am 7. Juli vor einer Umstellung auf Mimelib2 entfernt.
- Bei einem koordinierten GitHub-Push wurden gefälschte Trading-Bot-Repos, aufgeblähte Sterne und geskriptete Commits verwendet, um die bösartigen Abhängigkeiten zu verschleiern.
- IoCs umfassen Paketversionen, SHA1-Hashes und den Vertrag 0x1f171a1b07c108eae05a5bccbe86922d66227e2b sowie Anleitungen für Verteidiger.
Cyberkriminelle haben einen neuen Trick entwickelt: Sie leiten schädliche Infrastruktur über einen Ethereum-Smart-Contract, um die von npm-Paketen verwendeten Command-and-Control-Pointer (C2) zu verschleiern. Laut ReversingLabs haben zwei Pakete – colortoolsv2 und mimelib2 – unbemerkt auf die Blockchain zugegriffen, um URLs für weitere Schadsoftware abzurufen und so die üblichen Prüfungen auf fest codierte Domains zu umgehen.
Anstatt einen Fehler in Ethereum selbst auszunutzen, verwendet das System das Netzwerk als öffentliche, robuste Indirektionsschicht . Nachdem colortoolsv2 am 7. Juli auf npm blockiert wurde, wechselten die Betreiber schnell zu mimelib2 mit nahezu identischer Logik und bezogen sich für den nächsten Schritt weiterhin auf denselben On-Chain-Vertrag.
Von der NPM-Installation zur On-Chain-Suche: So funktionierte der Umweg
In colortoolsv2 fungierte ein minimaler Loader (index.js) als Dispatcher, der einen externen Befehl aufrief und dessen Ziel von einem Smart Contract anstatt von einem lokalen Skript oder einer statischen Konfiguration abrief. Etherscan zeigt den Vertrag unter 0x1f171a1b07c108eae05a5bccbe86922d66227e2b an; dessen Lesefunktionen gaben eine URL zurück, über die der C2-Dienst erreichbar war.
Dieser On-Chain-Zeiger erschwerte das Blockieren: Verteidiger konnten sich nicht einfach darauf verlassen, eine fest codierte Domain im Paket zu finden oder auf die Blacklist zu setzen, da der aktive Endpunkt hinter einem Smart Contract lag, den die Betreiber kontrollierten . Für wechselnde Ziele musste lediglich der Speicher des Smart Contracts aktualisiert werden, das npm-Artefakt musste nicht neu veröffentlicht werden, und der dadurch entstehende Blockchain-Traffic wurde als legitim eingestuft.
Nach der Ausführung während der Installation oder Laufzeit lud der Loader eine Komponente der zweiten Stufe (SHA1 021d0eef8f457eb2a9f9fb2260dd2e39ff009a21) herunter , die die nachfolgenden Aktionen verarbeitete. Analog zum Verhalten von colortoolsv2 verwendete mimelib2 denselben Vertrag für denselben Zweck mit nahezu identischen Codepfaden.
ReversingLabs bezeichnete den Ansatz als ungewöhnlich im npm-Ökosystem: Schädliche URLs wurden über den Zustand eines Smart Contracts gehostet , nicht über traditionelle Webdienste, wie sie häufig bei früheren Supply-Chain-Kampagnen zu sehen waren (z. B. Cloud-Speicher oder Gists).
GitHub-Blendwerk: Gefälschte Trading-Bot-Repos als Tarnung
Die npm-Pakete traten nicht isoliert auf. Die Betreiber hatten ein Netzwerk von GitHub-Projekten aufgebaut, die als Krypto-Handelsprogramme getarnt waren – Repositories wie beispielsweise solana-trading-bot-v2 – und diese dann mit den schädlichen Abhängigkeiten verknüpft. Für den unvoreingenommenen Betrachter wirkten diese Repositories „lebendig“ und wiesen Tausende von Commits, mehrere Maintainer, Sterne und Beobachter auf.
Eine genauere Analyse ergab, dass ein Großteil der Aktivitäten geskriptet und oberflächlich war, darunter wiederholte Lizenzdateiänderungen und neu erstellte Accounts mit spärlichem Inhalt (einige wurden um den 10. Juli mit README-Dateien erstellt, die lediglich „Hallo“ enthielten). Benutzernamen, die in den Commit-Verläufen auftauchten – darunter slunfuedrac, cnaovalles und pasttimerles –, tauchten wiederholt in den verschiedenen Projekten auf.
Die Commits zeigten genau, wo die Pakete in die Codebasis eingebunden wurden – colortoolsv2 und später mimelib2 wurden als Abhängigkeiten in bot.ts hinzugefügt, und die entsprechenden Importe erschienen in src/index.ts. Dieser künstlich erzeugte soziale Beweis machte das Einfügen der Abhängigkeiten bei einer oberflächlichen Überprüfung deutlich weniger offensichtlich.
Die GitHub-Fassade verstärkte faktisch Vertrauenssignale, während der eigentliche Entscheidungspunkt für den nächsten Schritt der Malware auf Ethereum lag . Durch die Trennung von Social Engineering (GitHub) und Kontrolle (Smart Contract) erschwerten die Betreiber die Erkennung und Unterbrechung der Kampagne.
IoCs und konkrete Schritte für Verteidiger
ReversingLabs veröffentlichte eine detaillierte Liste der mit dieser Aktivität verknüpften Artefakte sowie die wichtigste On-Chain-Referenz, die die zweite Phase auslöste. Die folgenden Elemente können verwendet werden, um Schwachstellen in Build-Pipelines und Entwickler-Workstations aufzuspüren, zu blockieren und zu validieren :
- npm packages: colortoolsv2 1.0.0 (SHA1 678c20775ff86b014ae8d9869ce5c41ee06b6215), 1.0.1 (1bb7b23f45ed80bce33a6b6e6bc4f99750d5a34b), 1.0.2 (db86351f938a55756061e9b1f4469ff2699e9e27)
- npm packages: mimelib2 1.0.0 (bda31e9022f5994385c26bd8a451acf0cd0b36da), 1.0.1 (c5488b605cf3e9e9ef35da407ea848cf0326fdea)
- Second stage: SHA1 021d0eef8f457eb2a9f9fb2260dd2e39ff009a21
- Für die C2-Indirektion verwendeter Smart Contract: 0x1f171a1b07c108eae05a5bccbe86922d66227e2b
Zusätzlicher Kontext aus der Abschaltphase: colortoolsv2 wurde am 7. Juli von npm entfernt , woraufhin die Betreiber auf mimelib2 mit der gleichen On-Chain-Referenz und nahezu identischem Loader-Verhalten umgestiegen sind.
Empfohlene Maßnahmen für Entwicklungs- und Sicherheitsteams umfassen: Kennzeichnung von On-Chain-Lookups, die von Installationsskripten durchgeführt werden ; Blockierung oder Warnung bei der Ausführung von child_process in Paketlebenszyklus-Hooks; Verhinderung des Netzwerkaustritts während npm install in CI; Durchsetzung von Zulassungslisten für Registries und Maintainer; Sperrung transitiver Versionen; und Überwachung von Anfragen, die mit der oben genannten Vertragsadresse verknüpft sind.
Generell sollten Popularitätsmetriken von Repositories nicht als Sicherheitsindikatoren betrachtet werden. Vertrauen sollte sich aus Code, Artefakten und Netzwerkindikatoren ergeben , nicht aus Sternenanzahlen, Commit-Volumen oder der Anzahl der „Maintainer“. Unabhängige Verifizierung – statische Analyse, Ausführung in einer Sandbox und SBOM-basierte Herkunftsprüfungen – bleibt unerlässlich.
Das Besondere an dieser Kampagne ist nicht ein Fehler in Ethereum, npm oder GitHub an sich, sondern die Art und Weise, wie öffentliche Infrastruktur in eine unauffällige Lieferkette eingebunden werden kann. Indem die Akteure die C2-Erkennung auf einen Smart Contract verlagerten und ihre Glaubwürdigkeit über GitHub wiederherstellten , überforderten sie herkömmliche Erkennungsmethoden. Sorgfältige Abhängigkeitsverwaltung und mehrstufige Kontrollmechanismen bilden das Gegengewicht.
