ReversingLabs found two malicious NPM packages that used Ethereum smart contracts to conceal downloader URLs and fetch second-stage malware, enabling threat actors to evade security scans by hiding command-and-control links on-chain.
-
New evasion tactic: smart contracts host download URLs for second-stage malware.
-
Attackers published poisoned NPM packages named colortoolsv2 and mimelib2 that functioned as simple downloaders.
-
Security context: researchers logged 23 crypto-related repo campaigns in 2024; these attacks combine blockchain traffic with social engineering to reduce detection.
Ethereum smart contract malware in NPM packages: read how attackers hide malicious URLs on-chain and what to watch for — learn detection steps now.
What is Ethereum smart contract malware in NPM packages?
Ethereum smart contract malware in NPM packages is code that queries on-chain smart contracts to retrieve concealed command-and-control (C2) URLs or commands, then downloads second-stage payloads. This technique hides malicious links off the package registry, making standard static scans less effective.
How do malicious NPM packages use smart contracts to hide payloads?
Attackers publish minimal downloader packages that call Ethereum smart contracts to fetch encoded URLs or commands. The packages then download the second-stage malware from those addresses. This shifts malicious infrastructure from registries to blockchain transactions, which often appear legitimate and bypass conventional URL-based scanning.
ReversingLabs researchers uncovered two NPM packages that used Ethereum smart contracts to hide malicious URLs and bypass security scans.
Threat actors have adopted a novel delivery method: embedding malicious command locations inside Ethereum smart contracts to evade detection. Security firm ReversingLabs discovered the technique in two open-source NPM packages that acted as downloaders for second-stage malware.
ReversingLabs researcher Lucija Valentić identified the packages as colortoolsv2 and mimelib2, both published in July. Rather than storing malicious links in package code, the packages queried the Ethereum blockchain to retrieve URLs hosted or referenced by smart contracts.
By moving C2 references on-chain, attackers reduce visible evidence in the package registry and exploit the perception that blockchain traffic is legitimate. The downloader packages executed simple fetch routines that resolved on-chain data into HTTP(S) URLs for payload retrieval.
Why is this attack vector concerning?
Using smart contracts to host or reference malicious URLs blends blockchain traffic with software supply-chain attacks. This complicates detection because:
- Blockchain queries look like normal node traffic and may not trigger URL filters.
- Package manifests remain benign-looking, showing only simple downloader code.
- Social engineering on GitHub and fabricated project history increases trust in poisoned repositories.
How did attackers make poisoned repositories appear legitimate?
Attackers used multiple deceptive practices: fabricated commits, fake maintainer accounts, watchful accounts to simulate interest, professional documentation, and forks that mirrored active development. This social engineering increases the likelihood that developers or users will install the packages without suspicion.
Frequently Asked Questions
Can smart contracts be used to hide any type of malicious content?
Yes. Smart contracts can store or reference encoded strings and URLs; attackers can encode C2 addresses or commands on-chain and have downloader code decode them, enabling the distribution of second-stage malware without hosting malicious links on traditional servers.
How can developers detect NPM packages that use on-chain URLs?
Monitor for packages that perform blockchain RPC calls, examine runtime network activity for unexpected node queries, and apply sandboxed installation with network isolation. Static scans alone may miss on-chain references.
Are these attacks limited to Ethereum?
No. Similar methods have been observed on other chains; past incidents included fake repositories that targeted Solana and attacks on Python libraries like Bitcoinlib. Threat actors adapt across ecosystems.
Key Takeaways
- New technique: Attackers use Ethereum smart contracts to conceal C2 URLs, evading standard scans.
- Supply-chain risk: Poisoned NPM packages functioned as downloaders and relied on elaborate GitHub deception.
- Action: Harden package vetting, monitor blockchain RPC calls in builds, and sandbox installs to limit exposure.
Conclusion
This incident demonstrates a fast-evolving threat: combining blockchain infrastructure with traditional supply-chain deception. Organizations should update detection strategies to include runtime monitoring of blockchain queries, stricter package provenance checks, and sandboxed installations. ReversingLabs and other security teams recommend increased vigilance for packages that perform on-chain interactions.
