- Malicious npm packages colortoolsv2 and mimelib2 fetched C2 URLs from an Ethereum smart contract to evade detection.
- On-chain indirection let operators rotate endpoints without republishing packages; colortoolsv2 was removed on July 7 before a pivot to mimelib2.
- A coordinated GitHub push used faux trading-bot repos, inflated stars, and scripted commits to mask the malicious dependencies.
- IoCs include package versions, SHA1 hashes, and the contract 0x1f171a1b07c108eae05a5bccbe86922d66227e2b, plus guidance for defenders.
Threat actors have turned to a novel trick: routing malicious infrastructure through an Ethereum smart contract to conceal command-and-control (C2) pointers used by npm packages. According to ReversingLabs, two packages—colortoolsv2 and mimelib2—quietly reached out to the blockchain to retrieve URLs for second-stage payloads, sidestepping routine checks that look for hardcoded domains.
Rather than exploiting a bug in Ethereum itself, the scheme leverages the network as a public, resilient indirection layer. After colortoolsv2 was blocked on npm on July 7, the operators quickly shifted to mimelib2 with near-identical logic, continuing to reference the same on-chain contract for the next step.
From npm install to on-chain lookup: how the detour worked
Inside colortoolsv2, a minimal loader (index.js) acted as a dispatcher that invoked an external command and fetched its target from a smart contract instead of a local script or static config. Etherscan shows the contract at 0x1f171a1b07c108eae05a5bccbe86922d66227e2b, whose read functions returned a URL used to reach the C2 service.
This on-chain pointer complicated blocking: defenders could not simply rely on finding or blacklisting a hardcoded domain in the package because the active endpoint lived behind a contract the operators controlled. Rotating destinations only required updating contract storage, not republishing the npm artifact, and any resulting blockchain traffic blended in as legitimate.
Once executed during install or runtime, the loader retrieved a second-stage component (SHA1 021d0eef8f457eb2a9f9fb2260dd2e39ff009a21), which handled follow-on activity. Mimicking colortoolsv2’s behavior, mimelib2 reused the same contract for the same purpose with near-identical code paths.
ReversingLabs described the approach as unusual in the npm ecosystem: malicious URLs were hosted via a smart contract’s state, not on traditional web services often seen in past supply-chain campaigns (e.g., cloud storage or gists).
GitHub smoke and mirrors: fake trading-bot repos as cover
The npm packages did not appear in isolation. Operators stood up a network of GitHub projects presented as crypto trading utilities—repositories such as solana-trading-bot-v2—and then wired them to the malicious dependencies. To the casual observer, these repos looked “alive,” boasting thousands of commits, multiple maintainers, stars, and watchers.
A closer look revealed much of the activity was scripted and superficial, including repetitive license file churn and newly minted accounts with sparse content (some created around July 10 with README files as minimal as “Hello”). Usernames that surfaced in commit histories—including slunfuedrac, cnaovalles, and pasttimerles—appeared repeatedly across the staged projects.
Commits showed exactly where the packages were threaded into the codebase—adding colortoolsv2 and later mimelib2 as dependencies in bot.ts, and corresponding imports appearing in src/index.ts. The manufactured social proof made the dependency insertion far less obvious during a superficial review.
In effect, the GitHub façade amplified trust signals while the real decision point for the malware’s next move lived on Ethereum. By splitting social engineering (GitHub) from control (smart contract), the operators made the campaign harder to spot and disrupt.
IoCs and concrete steps for defenders
ReversingLabs published a detailed inventory of artifacts linked to this activity, along with the key on-chain reference that drove the second stage. The following items can be used to hunt, block, and validate exposures in build pipelines and developer workstations:
- 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
- Smart contract used for C2 indirection: 0x1f171a1b07c108eae05a5bccbe86922d66227e2b
Additional context from the takedown phase: colortoolsv2 was removed from npm on July 7, after which the operators switched to mimelib2 with the same on-chain reference and nearly identical loader behavior.
Recommended actions for engineering and security teams include: flag on-chain lookups performed by install scripts; block or warn on child_process execution in package lifecycle hooks; deny network egress during npm install in CI; enforce allowlists for registries and maintainers; lock transitive versions; and monitor for requests tied to the contract address above.
More broadly, treat repository popularity metrics as non-security signals. Trust should derive from code, artifacts, and network indicators, not star counts, commit volume, or the appearance of many “maintainers.” Independent verification—static analysis, sandboxed execution, and SBOM-driven provenance checks—remains essential.
What stands out in this campaign is not a flaw in Ethereum, npm, or GitHub individually, but the way public infrastructure can be woven into a stealthy delivery chain. By moving C2 discovery onto a smart contract and laundering credibility through GitHub, the actors stretched traditional detection out of shape. Careful dependency hygiene and layered controls are the counterweight.
