- Two npm packages, 'colortoolsv2' and 'mimelib2', routed C2 via an Ethereum smart contract to evade detection.
- Fake GitHub trading-bot repos inflated trust with staged commits and accounts before adding the malicious dependency.
- The same on-chain contract (0x1f171a1b07c108eae05a5bccbe86922d66227e2b) supplied second-stage URLs.
- IoCs include specific package versions and SHA1 hashes; teams should monitor unexpected blockchain calls in install scripts.
ReversingLabs has flagged two npm packages that quietly routed installation logic through an Ethereum smart contract, turning a public blockchain into a covert directory for command-and-control (C2) infrastructure. The packages, ‘colortoolsv2’ and ‘mimelib2’, posed as simple utilities while enabling the retrieval of a second-stage payload.
By outsourcing the C2 address to an on-chain contract, the operators wrapped their traffic in what looks like ordinary blockchain activity, a move that complicates static and reputation-based detection. The contract at 0x1f171a1b07c108eae05a5bccbe86922d66227e2b exposed read functions returning a URL that installers would later contact.
From npm loader to an on-chain C2
Inside ‘colortoolsv2’, a thin index.js loader invoked an external command whose location was not hardcoded locally. Instead, it queried an Ethereum smart contract for the endpoint that would direct the host toward command-and-control.
Public explorers like Etherscan show the contract exposing simple read functions that return a URL, effectively using the chain as a resilient pointer to attacker infrastructure. Because the final hop is derived from a blockchain call, defenders do not see a static domain baked into the npm package.
Following its discovery, ‘colortoolsv2’ was blocked on npm on July 7. Shortly after, the operators published ‘mimelib2’, which reused near-identical logic and the same smart contract to deliver the second stage, according to the analysis.
Once executed, the loader fetched a second-stage component whose hash was published by researchers (SHA1: 021d0eef8f457eb2a9f9fb2260dd2e39ff009a21). This indirection let attackers rotate destinations at will by editing on-chain data rather than repackaging code.
A GitHub credibility play to mask malicious dependencies
ReversingLabs also traced a web of faux GitHub projects that presented as crypto trading bots, complete with thousands of commits, multiple maintainers, stars and watchers. Repositories such as ‘solana-trading-bot-v2’ looked lively but much of the activity was automated clutter.
Many commits churned trivial files (for example, repeated LICENSE edits), while clusters of lookalike accounts created around July 10 held almost no real content—some README files said only ‘Hello’. Usernames including ‘slunfuedrac’, ‘cnaovalles’ and ‘pasttimerles’ appeared frequently, inflating signals of legitimacy.
Code diffs showed the malicious dependency being added to trading-bot code (for example, in bot.ts and imports in src/index.ts), first via ‘colortoolsv2’ and later via ‘mimelib2’. That association became far less obvious to a casual reviewer amid the noisy commit history.
By seeding npm and GitHub together, the actors blurred traditional trust signals, making the hidden dependency blend into a project that appeared active, well-maintained and community-endorsed.
IoCs, scope and what defenders should watch
ReversingLabs published the following indicators of compromise (IoCs) tied to this campaign:
- npm packages: colortoolsv2 1.0.0 (SHA1 678c20775ff86b014ae8d9869ce5c41ee06b6215), 1.0.1 (1bb7b23f45ed80bce33a6b6e6bc4f99750d5a34b), 1.0.2 (db86351f938a55756061e9b1f4469ff2699e9e27)
- npm package: mimelib2 1.0.0 (bda31e9022f5994385c26bd8a451acf0cd0b36da), 1.0.1 (c5488b605cf3e9e9ef35da407ea848cf0326fdea)
- Second stage: SHA1 021d0eef8f457eb2a9f9fb2260dd2e39ff009a21
- Smart contract: 0x1f171a1b07c108eae05a5bccbe86922d66227e2b
This approach echoes prior abuse of trusted hosting like Gists or cloud storage, but the on-chain twist undermines static blocklists and simple source checks. The C2 location can be changed in the contract without touching the package, and blockchain traffic can be misread as routine in crypto-adjacent environments.
Practical steps include reviewing dependency provenance beyond stars and commits, monitoring unexpected blockchain RPC calls during install/build phases, validating any runtime-resolved URLs, and pinning known-good versions with integrity checks. Security teams should also hunt for repositories whose activity is artificially inflated by trivial, automated commits.
The case shows how Ethereum smart contracts can be repurposed as resilient pointers for malware distribution in the npm ecosystem, while staged GitHub activity conceals malicious dependencies in plain sight; awareness of these overlaps between open source and on-chain infrastructure is now essential for developer and enterprise defenses.
