Blockchain malware’s neverending novelty

Crypto has been abuzz about EtherHiding, a clever new attack method where bad actors hide malicious code inside smart contracts to spread malware through the blockchain. MetaMask’s Taylor Monahan shares her take on why every new wave of so-called blockchain malware grabs headlines, and why defenders should keep their eyes on the basics before getting carried away.

An infinite loop

Each time a new report about onchain malware drops, security researchers declare again: “The first decentralized, immutable, unstoppable threat has arrived!” LinkedIn lights up. Blogs are churned out. Fear-infused headlines are optimized. AI-powered endpoint detection and response is hawked. 

A chorus of replies echoes: “I told you so! The blockchain is the perfect delivery mechanism for scammers!” Then, as always, the campaign fizzles out. Analysts move on to the next shiny exploit—and, in preparation for next year’s report, forget that “the first decentralized, immutable, unstoppable threat” ever arrived. 

The headlines about blockchain malware aren’t entirely wrong. It’s malware. It leverages the blockchain. But that’s basically it. The campaigns are unremarkable in every way except for their one clever trick, which is why they are so quickly forgotten.

Things might be different if they were both novel and consequential—something groundbreaking or devastating. But, really, security researchers just love novelty. It’s our catnip. Anything even slightly out of the ordinary, like botnets fetching less than 80 bytes from OP_RETURN or malware updating configs via a smart-contract, sets us off. We can’t help but roll around in it, imagining a world full of decentralized, unstoppable malware.

To be fair, a subset of threat actors does share this same affliction. The cybercriminal auteurs who push a narrative alongside their exploits craft dramatic messages to attract the media and sign their malware to make sure everyone knows it’s them. Their runs are flashy, entertaining, and predictably short-lived. They’re often too busy competing for attention to notice they netted $13 today (or that the FBI took over their group chat yesterday).

Yes, there are lessons to be learned from those operations. “How to be an unstoppable immutable threat actor” is just not one of them.

The threat actors that do real damage are pragmatic. ROI is their North Star. Stealth, scale, and sustainability are how they get there. And they are constantly shifting their techniques in response to blockers.

• No one is reading emails → move to Telegram

• GitHub takes down repos → move to private repos

• Private repos are abnormal, raise suspicions → move to Bitbucket or GitLab

• MetaMask flags the malicious frontends as soon as they appear → use Google Docs or Github repos instead of landing pages

Thus, whenever I see another threat actor using the blockchain, I always ask what problem the blockchain solves for them. How does it move the needle in terms of turning unsuccessful campaigns into successful ones? 

Malware, meet blockchain

Malware is malicious software. It’s code. It doesn’t fall out of the sky or spawn magically. The code itself must get on the victim’s device and then run in order to carry out its operations.

With normal software, you visit a website or app store and download the application, which is then installed and runs on your device. This installation process unpacks the actual software, and then runs the code contained within. It might do things like move files to the right place, set up configurations for your personal settings, check a server somewhere for any available updates, or set itself up to automatically begin each time you start your computer.

Malware does all of this, too. It just has to be sneaky about it. Malicious software cannot do malicious things if the end user, or anyone else, detects that it’s malicious.

And people are always trying to protect end users from malware. Google Chrome redscreens malicious URLs and downloads. Your operating system prevents malicious code from installing, especially without your knowledge. Social media sites, web hosts, domain registrars, and code repositories all take steps to detect and prevent malware operators from using them to achieve nefarious goals.

As a result, how malware is delivered to end users has evolved significantly over time. Malware creators and operators go to great lengths to break up the malicious payloads into multiple stages, obfuscate URLs, and build in fallbacks in case something gets taken down.

Wait, where’s the blockchain?

Different threat actors have used the blockchain in different ways over the years.

The role the blockchain plays is generally the same, even if the exact mechanism and technical details differ:

• Malicious code needs to communicate with various resources in order to obtain or maintain control of a victim’s device. 

• Those resources often change (e.g. when a server gets taken down).

• If a piece of malicious code can’t change (e.g. malware is already on a victim’s device or code is deployed across thousands of compromised Wordpress websites), then it dies when a resource it’s relying on is taken offline.

Thus they throw a blockchain in there and now nothing can be taken down, everything is magical and invisible and anonymous, and the decentralized, immutable, unstoppable threat has arrived!

When

What

Blockchain element

Blockchain benefits

2016-2017, 2023

Cerber Ransomware

Ransomware-as-a-service (RaaS) model, which allows non-technical attackers to deploy the ransomware while the technical developers handle the creation and maintenance. 

Any money made from extorting victims is split between the attacker and the developer.

Infected machines queried hardcoded wallet addresses using four Bitcoin APIs until they successfully retrieved the data from the blockchain.

The malware would then decrypt this data to obtain the IP of the server used for command-and-control communication.

Resilience: Hard-coded URLs/IPs are easy to block and render the malware inoperable. 

Cerber ransomware coordinated with its owner using transaction data on the Bitcoin blockchain, which could dynamically update the server’s location in real time.

2010–Present

Peaked in 2019-2021

Glupteba Botnet

Malware that got full backdoor control of infected machines, exfiltrated credentials and cookies, deployed proxies for traffic anonymization, facilitated credit card fraud and ad abuse, and (as of 2019) even had a cryptominer.

Bitcoin’s OP_RETURN opcode was used to embed an encrypted backup C2 domain within transactions.

Whenever primary C2 servers went offline, infected machines could loop through a list of Bitcoin Electrum servers until they successfully retrieved blockchain data.
That string was then decrypted to get the URL of the up-to-date C2 server.

Resilience: Adds a layer of resilience that ensured infected machines remained infected, even if the original C2s were taken offline.

Sep 2023–
Jul 2025

Etherhiding - CLEARSHORT
UNC5142

Multistage JavaScript downloader used to facilitate malware distribution.

First, a JavaScript payload is injected into vulnerable websites that retrieves the second-stage payload from a malicious smart contract. 

The smart contract  fetches a CLEARSHORT landing page from an attacker-controlled server. That landing page leverages ClickFix, a popular social engineering technique that lures victims into locally running  a malicious command using Windows Run.

Instead of embedding their entire attack chain within the compromised website, malicious actors stored components on the BNB Smart Chain using smart contracts to store short payloads.

Initially the data put on the blockchain was an encrypted payload (rather than a literal URL string) but this payload was a very short snippet that would make a request to a specified URL and then eval() whatever that URL returned.

Over time the mechanism evolved to involve multiple layers of contracts that each run some checks and then point to the next contract. The final contract then housed the URL hosting the encrypted payload + decryption key and the URL hosting the second stage payload.

Resilience: Increases resiliency in the face of detection and takedown efforts. Network-based protection mechanisms are more difficult to implement for Web3 traffic. Seizure and takedown operations are also hindered, given the immutability of the blockchain.

Stealth: Storing malicious code within a smart contract makes it harder to detect with traditional web security tools. Calls to legitimate endpoints help the malicious traffic blend in with normal activity.

Agility: By using multiple contracts the attackers had a stable entry point that could then point to different places (and payloads) as needed.

Feb 2025–
Present

Etherhiding
UNC5342 / DPRK / Contagious Interview

This campaign targets developers, particularly in the cryptocurrency and technology sectors, to steal sensitive data/cryptocurrency and gain persistent access to corporate networks.

The campaign employs a multi-stage malware infection process to compromise the victim's system across Windows, macOS, and Linux systems.

Utilizes EtherHiding to fetch, decrypt, and execute malicious payloads from smart contracts on the BNB Smart Chain and Ethereum.

The victim runs code that executes an initial JavaScript downloader that then interacts with a malicious smart contract and downloads the second-stage payload.

Typically uses eth_call or eth_getStorageAt (read operations for grabbing the data from the chain).

Resilience: No central server to take down. Once a smart contract is deployed, it cannot be easily removed or altered by anyone other than the contract owner.

Stealth: Attackers can retrieve the malicious payload using read-only calls that do not leave a visible transaction history.

Agility: The attacker can update the malicious payload at any time to change their attack methods, update domains, or deploy different types of malware.

2025

Cross-Chain TxDataHiding

Bounces across TRON, Aptos, and BSC blockchains to further obfuscate the trail. One blockchain acts as an index or pointer system that stores a reference to a transaction hash on a second blockchain (typically BSC), which ultimately contains the malicious payload.

Employs an arbitrary blockchain that acts as a pointer to a BSC transaction hash.

It then uses eth_getTransactionByHash to get the data of that BSC transaction, which ultimately has an obfuscated payload used to deliver the next stage of the malware.

TRON calls are `raw_data.data` and Aptos calls are `payload.arguments[0]`—both read calls to retrieve information from the chain. Any chain supporting custom data fields in transactions could serve as the pointer layer.

Resilience: Traditional C2 servers can be seized by law enforcement or shut down by hosting providers, but blockchain-stored data is replicated across thousands of nodes.

Stealth: Connections to `api.trongrid.io` `aptoslabs.com` `binance.org` appear as generic HTTPS to legitimate services with no obvious malicious indicators. Traditional C2 leaves server logs, TLS certificates, hosting records, IP geolocation, but a “blockchain C2” creates only pseudonymous addresses and transaction hashes with no servers or logs.

Agility: Can modify payloads at any time by posting new blockchain transactions while the malware's hardcoded addresses never change. Machines can automatically fetch updated payloads without code modifications.

Not so fast

Landing malware on a victim’s device requires multiple stages, multiple resources, and some amount of communication between those resources. Some of these stages exist solely to evade detection and others exist to maintain control over time.

This is important to understand because the malware is never “running on the blockchain.” The blockchain doesn’t even replace the entire infection chain.

For example, here’s a (simplified) before-and-after of Glupteba’s infection chain, circa 2019:

Before

After

Dropper lands on victim’s device

Dropper lands on victim’s device

Malware creates a registry containing a hardcoded list of C2 URLs & installs components.

Malware creates a registry containing a hardcoded list of C2 URLs & installs components.

Periodically sends information from the victim's device to the C2 server.

Periodically sends information from the victim's device to the C2 server.

Periodically pings the C2s for further commands, often including updating the registry with new C2 URLs.

Periodically pings the C2s for further commands, often including updating the registry with new C2 URLs.

If unable to reach any of the C2s, try again later.

If unable to reach any of the C2s, loop through a list of Bitcoin API endpoints to retrieve data from a txn hash -> decrypt data -> add new C2 URL to the registry.

And here’s the before-and-after of the initial evolution of UNC5142’s Etherhiding:

Before

After

Compromise WordPress websites

Compromise WordPress websites

Inject simple JavaScript in all articles / pages

Inject simple JavaScript in all articles / pages

User visits compromised site

User visits compromised site

Injected Javascript retrieves a second-stage payload from Cloudflare Workers

Injected Javascript retrieves a second-stage payload from data stored in a txn on the BNB blockchain

Payload eval()’s a specified URL to transform the page into “You need to update your browser” overlay.

Payload eval()’s a specified URL to transform the page into “You need to update your browser” overlay

User clicks the Update button

User clicks the Update button

Fetches & downloads malicious payload from Russian-based IP address

Fetches & downloads malicious payload from Russian-based IP address

Looking at it this way, it becomes clearer that the blockchain elements are grafted onto an otherwise conventional infection chain. It is an evolution of an existing operation. Sometimes it’s even in direct response to being disrupted.

This difference matters for defenders who need to separate the novelty from the risk. The primary controls that stop these campaigns ultimately remain the same. Threat actors will always sidestep disruptions like C2s being taken down when they know the campaign is still otherwise landing successfully. People and organizations must work to reduce initial compromises, detect threats based on behavior and not static indicators, and ensure there are controls to contain endpoints post-compromise. The blockchain’s existence changes none of this.

The benefits of the blockchain

With that in mind, let’s revisit the blockchain benefits highlighted in our table by researchers over the years.

Resilience

• “Hard-coded URLs are easy to block and thus render the malware installation inoperable.” Source: Cerber Ransomware

• “Ensures infected machines remain infected, even if the original C2s are taken offline.” Source: Glupteba

• “Increases resiliency in the face of detection and takedown efforts. Seizure and takedown operations are also hindered given the immutability of the blockchain.” Source: UNC5142's EtherHiding

• “There’s no central server to take down.” Source: UNC5342's EtherHiding

• “Traditional C2 servers can be seized by law enforcement or shut down by hosting providers, but blockchain-stored data is replicated across thousands of decentralized nodes.” Source: Cross-Chain TxDataHiding

• “Once a smart contract is deployed, it cannot be easily removed or altered by anyone other than the contract owner.” Source: UNC5342's EtherHiding

Reality check: The blockchain is most commonly being used as a pointer and exists between two pieces of traditional infrastructure. 

Malware authors have employed a diverse range of “pointer” mechanisms that hide in plain sight, on bulletproof hosts, or on legitimate content platforms for years. These too can be very hard, or even impossible, to detect and/or take down.

The calls to retrieve the data from the blockchain are still via traditional API endpoints hosted by traditional infrastructure service providers, and sometimes even use traditional API keys. While you can’t take down the entire system (as it’s ultimately a business operated in good faith and primarily servicing legitimate users), security researchers can educate companies about this type of activity and work with them to take action.

This is no different than any other situation where a malicious actor is using legitimate infrastructure to deliver their payloads. It’s always frustrating when you know a certain entity could take action, but isn’t. The blockchain industry in particular has its own network of security researchers that isn’t fully integrated with traditional security research networks. However, that doesn’t mean it doesn’t exist. If you ever need introductions or to share intel of this nature, there are people in blockchain who care deeply, know everyone, and are always willing to help. This includes all of us at MetaMask Security, as well as organizations like SEAL. Get in touch.

Stealth

• “Storing malicious code within a smart contract makes it harder to detect than with traditional web security tools that might scan website content directly.” Source: UNC5142’s EtherHiding

• “The BNB Smart Chain is a legitimate platform. Using it can help the malicious traffic blend in with normal activity as a means to evade detection.” Source: UNC5142’s EtherHiding)

• “Attackers can retrieve the malicious payload using read-only calls that do not leave a visible transaction history.” Source: UNC5342's EtherHiding

• “Connections to blockchain APIs—api.trongrid.io, aptoslabs.com , binance.org, etc—appear as generic HTTPS to legitimate services with no obvious malicious indicators.”  Source: Cross-Chain TxDataHiding

• “Traditional C2 leaves extensive evidence (server logs, TLS certificates, hosting records, and IP geolocation), but blockchain C2 creates only pseudonymous addresses and transaction hashes with no servers or logs.” Source: Cross-Chain TxDataHiding

• “Network-based protection mechanisms are more difficult to implement for web3 traffic compared to traditional web traffic given the lack of use of traditional URLs.” Source: UNC5142’s EtherHiding

Reality check: Interacting with “the blockchain” is like interacting with any other cloud service provider 

The blockchain is just a massive public database of all historical transactions alongside some complex cryptographic verification that must happen every ~10 seconds. It is almost always running on traditional, dedicated infrastructure with all sorts of load balancing, APIs, and other orchestrations. What each service provider logs and retains depends entirely on its usage, users, history, privacy policy, location, relationship with users, and the services being offered.

As an example, if a blockchain service requires a monthly payment, it typically charges via a credit card, like a web2 company. If it accepts crypto payments, its onchain addresses are widely known, and you can see the threat actor paying. Unlike with traditional payments, anyone can watch DPRK pay Namecheap for domains and Debank for API credits. This is high-confidence, actionable intelligence that wasn’t previously available.

The average end-user’s computer does not randomly ping anything crypto-related. If your sandbox running a mysterious payload suddenly does, you should definitely look directly at it. Even under normal conditions, blockchain calls are not nearly as legitimate as, say, calls to Microsoft, GitHub, AWS, Google, or Cloudflare. And all of those regularly deliver malicious payloads.

Sure, crypto companies can’t block all crypto traffic as a means of prevention. “Luckily, crypto companies don’t have any monitoring, so it’s fine!” I’m kidding, of course. Every serious crypto company has serious Security Information & Event Management (SIEM) and Endpoint Detection & Response (EDR), which are designed to successfully detect and contain real Lazarus payloads. Contagious Interview or MaaS payloads—even those using the blockchain—are detected in the exact same way they were detected prior to their use of the blockchain.

Agility

• “While smart contracts themselves are immutable, they deploy a first-level smart contract that contains a pointer to a second-level smart contract. The first-level contract acts as a stable entry point whose address never changes on the compromised website, directing the injected JavaScript to fetch code from a second-level contract, giving the attackers the ability to change this target without altering the compromised website.” (UNC5142's EtherHiding)

• “The attacker can update the malicious payload at any time to change their attack methods, update domains, or deploy different types of malware.” (UNC5342's EtherHiding)

• “The attacker can modify payloads at any time by posting new blockchain transactions while the malware's hardcoded addresses never change, meaning infected machines automatically fetch updated payloads without code modifications.” (Cross-Chain TxDataHiding)

Reality check: This is also how the internet works

Threat actors hide a payload in an image, update the image, and now the malware is magically different. URLs are pointers to IP addresses, which are pointers to content hosted on servers. If you can’t take down the literal content, you take down the routes used to access the content. If you can’t take down the routes, you have those doing the routing block them.

The key difference between arbitrary data stored on a website versus a blockchain is that it costs money to write arbitrary data to the blockchain and there is a public event that occurs whenever it happens. Transaction fees can range from $1-$100+ depending on network conditions. Some chains are cheaper than others, making this less of an issue. But it still has a cost and those payments leave a trail.

The blockchain is public after all. Service providers and exchanges have databases of correlated end-user activity, IP addresses, device fingerprints, and sometimes full KYC dox. Even basic transactions require some amount of interaction with traditional internet elements which obviously have some amount of traditional internet data. How much data depends entirely on how the threat actor is interacting with the blockchain. But the blockchain is not anonymous.

The end game

In theory, a censorship-resistant, irreversible, decentralized storage system is a threat actor’s dream come true. In reality, these “blockchain-powered” malware strains never seem to catch on like other tradecraft does. 

CLICKFIX, for example, was quickly picked up by a huge number of different threat groups. The idea that you could convince end users to copy-paste directly into their command line to bypass frontline protections was actually a game changer. Meanwhile, seven years later, malware on the blockchain is still novel enough to set the security world on fire every time someone finds a new implementation.

In part, this is because blockchains don’t (and can’t) replace the entire infection chain, or even the majority of it. There are social media accounts, web hosts, domain registrars, and one or more C2 servers that are being utilized to deliver various stages of the malware, point to the next one, or fallback in case one goes down. The blockchain is adding another workflow and another step on top of all the existing flows.

It’s also because the blockchain comes with its own costs and risks. 

Why risk permanently leaving your OpSec on a public ledger for anyone to uncover when there are bulletproof hosts, compromised WordPress sites, and free content platforms all begging to serve as disposable infrastructure? Why risk your otherwise-undetected thing being insta-detected by all the public WiFis, hotels, cruise ships, schools, and/or workplaces that still block everything remotely “blockchain-y” by default?

Part of the answer is simply because they can. It’s fun and clever and novel and unique. Maybe it’ll make them more successful—or at least feel like they’re futuristic scammers. Threat actors are people, too. They have goals and motivations. They don’t always operate rationally. 

However, I think the real answer reveals itself in the public reporting on these mechanisms. It seems like it actually does evade detection. Somehow, just using a blockchain allows them to keep their C2s hidden for longer. Somehow, sandboxes get confused when they can’t find the malware because it’s in a blockchain API call.

Ironically, this benefit isn’t because it can’t be detected. (It can). It’s not because it’s actually more anonymous or stealth or private than everything else they do. (It’s really, really not). The benefit is derived almost entirely from the fact that security researchers perceive it to be that way.

As such, we should expect threat actors to continue experimenting in this way. Security researchers should also continue to track and post about these campaigns. But, for now at least, “blockchain malware” remains a relatively fun footnote in a much larger, much grimmer story.

The bulk of our time and energy must be spent taking action on the things that have a real impact on people and institutions—the things that prevent loss and keep people safe, even when they insist on pasting random commands into a black box just because a stranger on the internet told them to. 

If for some reason the blockchain aspects of these campaigns are truly the blocker for any security companies trying to better detect, deanonymize, and disrupt these campaigns, the web3 security world is more than happy to help. Please get in touch with us at MetaMask Security.