- Zwei npm-Pakete, colortoolsv2 und mimelib2, haben Ethereum-Smart Contracts abgefragt, um C2-URLs für Malware der zweiten Stufe abzurufen.
- Angreifer führten eine inszenierte Kampagne durch, bei der sie gefälschte GitHub-Trading-Bot-Repos nutzten, um Entwickler anzulocken.
- Die Technik vermischt sich mit legitimem Blockchain-Verkehr, was die Erkennung und Deaktivierung erschwert.
- ReversingLabs hat IoCs freigegeben, darunter Paket-Hashes und eine Vertragsadresse, die zum Bereitstellen von URLs verwendet wird.
Forscher haben ein Lieferkettenschema im npm-Repository aufgedeckt, bei dem zwei JavaScript-Bibliotheken Ethereum-Smart-Contracts konsultierten , um Download-Orte für nachfolgende Schadsoftware zu ermitteln. Diese im Juli 2025 beobachtete und inzwischen aus npm entfernte Taktik zeigt, wie öffentliche Blockchains als Verschleierungsschicht missbraucht werden können, um die Command-and-Control-Infrastruktur (C2) zu verbergen.
Anstatt feste URLs einzubetten, bezog der Schadcode diese zur Laufzeit aus einem Smart Contract auf Ethereum, wodurch die Aktivität wie gewöhnliche On-Chain-Abfragen aussah. Diese Verlagerung hin zur Nutzung eines dezentralen „Adressbuchs“ für die Payload-Übermittlung verdeutlicht, wie sich Angreifer anpassen, um herkömmliche Scans und simple Blocklisten zu umgehen.
Was wurde auf npm hochgeladen
Laut ReversingLabs wurden die Pakete colortoolsv2 und mimelib2 im Juli 2025 veröffentlicht und später wieder entfernt. Jedes Paket fungierte als kleiner Loader: Nach der Installation oder dem Import führte es Code aus, der einen Ethereum-Smart-Contract kontaktierte, einen Wert auslas und anschließend eine Komponente der nächsten Stufe von der zurückgegebenen URL abrief.
Während die npm-Bibliotheken ihr Ladeverhalten nicht stark verschleierten, wurde Glaubwürdigkeit an anderer Stelle geschaffen: Verlinkte GitHub-Projekte verwendeten vertraute Namens- und Aktivitätsmuster, um legitim zu wirken und es Entwicklern zu erleichtern, die Abhängigkeit auf einen Blick zu akzeptieren.
So funktionierte der Smart-Contract-Pivot
Die Speicherorte der Nutzdaten waren nicht fest codiert. Stattdessen fragte der Loader einen Vertrag unter 0x1f171a1b07c108eae05a5bccbe86922d66227e2b ab und verwendete dazu Lesefunktionen, die einen String zurückgaben, der als URL für den zweiten Schritt interpretiert wurde. Durch das Speichern des Zeigers in der Blockchain erreichten die Angreifer eine höhere Widerstandsfähigkeit: Er ist öffentlich, abfragbar und aktualisierbar, ohne dass neue npm-Releases veröffentlicht oder ein einzelner, anfälliger Server betrieben werden muss.
Da Blockchain-Abfragen harmlosen Krypto-Tools und -Analysen ähneln, lassen sie sich nahtlos in normale Entwickler-Workflows integrieren. Der Ansatz erinnert an frühere Ideen wie EtherHiding, wurde hier aber direkt in die npm-Paketausführung eingebunden und verwandelt so eine routinemäßige Installation in einen Prozess für die gestaffelte Auslieferung.
Ein breiterer GitHub-Vorstoß zur Förderung der Akzeptanz
Die npm-Pakete wurden in einem Netzwerk von GitHub-Repositories referenziert, die als Krypto-Handels-Tools positioniert waren. Beispiele hierfür waren solana-trading-bot-v2 , ethereum-mev-bot-v2 , arbitrage-bot und hyperliquid-trading-bot . Die Aktivitäten rund um diese Repositories – Sterne, Forks, Beobachter und häufige Commits – wurden gezielt eingesetzt, um Legitimität und Dynamik vorzutäuschen.
ReversingLabs bringt diese Verstärkung mit einem Distribution-as-a-Service-Cluster namens Stargazers Ghost Network in Verbindung , in dem koordinierte Accounts Popularitätssignale künstlich erhöhen und schädliche Abhängigkeiten in Projekte einschleusen. Der zugehörige GitHub-Account eines der wichtigsten Repositorys wurde später entfernt, doch die Commit-Historie zeigte, wie die schädlichen Importe im Laufe der Zeit in den Code integriert wurden.
Zeitleiste und Paketrotation
Colortoolsv2 tauchte zuerst auf und wurde um den 7. Juli 2025 auf npm blockiert . Kurz darauf wechselten die Akteure zu einem nahezu identischen Ersatz namens mimelib2 , wobei der Smart-Contract-Lookup für die URL der zweiten Stufe beibehalten wurde. Dieser rasche Austausch unterstreicht ein bekanntes Muster bei Lieferkettenvorfällen: Sobald ein Artefakt markiert wird, übernimmt ein ähnliches Paket schnell dessen Rolle.
Kompromittierungsindikatoren (IoCs)
ReversingLabs meldete die folgenden Indikatoren, die auf die Kampagne hindeuten. Organisationen können diese nutzen, um ihre Erkennungs- und Jagdbemühungen zu steuern :
- npm-Pakete und -Versionen:
- colortoolsv2 1.0.0 (SHA1 678c20775ff86b014ae8d9869ce5c41ee06b6215)
- colortoolsv2 1.0.1 (SHA1 1bb7b23f45ed80bce33a6b6e6bc4f99750d5a34b)
- colortoolsv2 1.0.2 (SHA1 db86351f938a55756061e9b1f4469ff2699e9e27)
- mimelib2 1.0.0 (SHA1 bda31e9022f5994385c26bd8a451acf0cd0b36da)
- mimelib2 1.0.1 (SHA1 c5488b605cf3e9e9ef35da407ea848cf0326fdea)
- Datei der zweiten Stufe: SHA1 021d0eef8f457eb2a9f9fb2260dd2e39ff009a21
- Ethereum contract: 0x1f171a1b07c108eae05a5bccbe86922d66227e2b
Warum diese Methode die Verteidigung erschwert
Indem die Angreifer die Entscheidung über das weitere Vorgehen an einen Smart Contract auslagern , entkoppeln sie die Logik der Malware von einem zentralen Endpunkt. Wird eine URL blockiert, kann der Wert des Vertrags aktualisiert werden, und dasselbe npm-Paket ermittelt unverändert den neuen Speicherort. Diese Dynamik schwächt statische Indikatoren und erschwert die Bekämpfung der Malware.
Zudem interagieren viele Entwicklerumgebungen bereits mit Web3-Endpunkten, sodass EVM-Aufrufe nicht per se verdächtig sein müssen. Die Grenze zwischen legitimem Blockchain-Datenverkehr und bösartigem Beaconing verschwimmt, was sowohl Netzwerküberwachung als auch Endpunkterkennungsstrategien vor Herausforderungen stellt.
Praktische Schritte für NPM- und Web3-Entwickler
Teams sollten vor der Einbindung einer Abhängigkeit Code, Maintainer und Netzwerk prüfen. Neben Downloadzahlen und Sternen sollten auch die Maintainer-Historie , das Alter des Repositorys, die Commit-Qualität, der Release-Zyklus und die Frage, ob das Paket unerwartet auf On-Chain-Verträge oder unbekannte Hosts zugreift, berücksichtigt werden.
- Überprüfen Sie Install- und Postinstall-Hooks sowie Einstiegspunkte für Netzwerkanrufe oder Ausführung untergeordneter Prozesse.
- Blockieren oder warnen Sie bei unerwarteten EVM-RPC-Abfragen von CI/CD- oder Build-Pipelines; legen Sie fest, auf was Ihre Tools zugreifen sollen und leugne den Rest.
- Pin-Versionen, verwenden Sie Lockfiles und spiegeln Sie geprüfte Pakete in ein internes Register, um die Gefährdung durch Pakettausch.
- Nehmen Sie Artefakt-Bescheinigungen und Signaturüberprüfungen an (z. B. SLSA-Herkunft), damit die Abhängigkeitsintegrität gewährleistet ist beim Build überprüft.
- Scannen Sie Abhängigkeitsdiagramme kontinuierlich auf neu gemeldete IoCs und Anomalien Änderungen beim Betreuer.
Bei Repositories, die von der Kampagne betroffen waren, sollten die letzten Commits auf die Einführung von colortoolsv2 oder mimelib2, Rollkeys und Tokens, die während kompromittierter Builds verwendet wurden, überprüft werden. Außerdem sollte erwogen werden, Systeme, auf denen die betroffenen Pakete ausgeführt wurden, neu zu installieren, um etwaige Artefakte der zweiten Phase zu entfernen.
Die Episode verdeutlicht, wie eine vertraute Plattform – npm – zusammen mit Ethereum genutzt werden kann, um die Spuren zwischen einer Abhängigkeit und ihrem Payload-Host zu verschleiern. Da On-Chain-Daten als zuverlässiger Indikator dienen, sind die Sicherheitsverantwortlichen gezwungen, das Paketverhalten, GitHub-Signale und Blockchain-Lesevorgänge zu korrelieren , um Schwachstellen aufzudecken, die einfache statische Prüfungen übersehen.
