Ethereum malware C2 techniques are being used by hackers to hide command-and-control server details inside blockchain transactions, giving infected systems a resilient way to locate active infrastructure. Instead of relying only on a hardcoded domain or IP address, the malware can read Ethereum activity and recover the server it needs to contact. The technique turns ordinary-looking blockchain activity into a signaling system that can help malware operators rotate infrastructure while making takedowns more difficult.
Recent research into a DPRK-linked campaign shows how this idea has evolved beyond simply storing data in smart contracts. In one technique, malware reads specially crafted Ethereum transaction destination addresses and decodes them into the IP address and port of its current command-and-control server.
Ransom-ISAC documented the technique in September 2026 as part of the ongoing XCTDH campaign, while earlier research from OpenSourceMalware described a closely related approach called NullReceiver. Both demonstrate the same defensive problem: attackers can use a public blockchain as a resilient directory for malware infrastructure without needing a normal DNS record that defenders can simply suspend.
For broader coverage of state-linked cyber operations, see our Nation-State Cyber Warfare and APT Threats 2026 guide.
How Ethereum Malware C2 Works
Traditional malware commonly contains a domain name or IP address that tells the infected machine where to contact its command-and-control server. That creates a weakness for attackers because defenders can identify the infrastructure, block it and potentially have the domain or hosting account taken down.
Blockchain-based dead drop resolvers change that model. Instead of storing the active C2 address directly inside the malware, the infected system reads information from a public blockchain and derives the server location at runtime.
In the XCTDH campaign analyzed by Ransom-ISAC, a JavaScript module queries Ethereum mainnet activity associated with an attacker-controlled signaling wallet. The malware examines a transaction’s recipient address and decodes specific bytes into an IPv4 address and network port.
That means what appears on-chain as an Ethereum destination address can actually function as a hidden instruction telling malware where to connect next.
HashHiding Encodes the C2 Server Inside an Ethereum Address
Ransom-ISAC tracks the newer technique as HashHiding. Researchers found it in September 2026 samples associated with the broader DPRK-linked XCTDH operation.
The technique does not need to place a large payload or obvious command inside a smart contract. Instead, selected bytes inside the Ethereum transaction’s to address encode the active C2 endpoint.
| Element | Observed Behavior |
|---|---|
| Blockchain | Ethereum mainnet |
| Purpose | Recover current malware C2 address |
| Signal source | Attacker-controlled Ethereum wallet |
| Encoded data | IPv4 address and port inside recipient-address bytes |
| Observed beacons | 2,655 transactions during the analyzed period |
| C2 rotations | Four observed rotations across roughly 90 days |
Ransom-ISAC’s on-chain collection covered activity from June 23 through September 21, 2026. The signaling wallet generated 2,655 outbound beacon transactions during that window, while the operator changed the encoded C2 destination four times.
Most of those transactions transferred zero wei, while a small number moved only 150 wei. This keeps the blockchain signaling cost extremely low while maintaining fresh transactions that infected systems can discover.
Why Attackers Use Ethereum Instead of a Normal Domain
A normal malware domain creates a central point defenders can attack. Security teams can block the domain, registrars can suspend it and hosting providers can remove the associated server.
Ethereum itself does not work like a conventional hosting provider. Historical transactions remain part of the blockchain, and public RPC services make that information broadly readable. The attacker therefore does not need control of a traditional web page simply to tell malware where the next server is located.
The operator can rotate infrastructure by publishing another transaction containing a newly encoded destination. Malware checking the blockchain can discover that change without receiving a new executable or configuration file.
This does not make the actual C2 server untouchable. Defenders can still block or seize conventional infrastructure used after the blockchain lookup. The advantage for the attacker is that infected systems retain another method of discovering replacement infrastructure.
NullReceiver Makes Blockchain C2 Even Harder to Spot
OpenSourceMalware documented another technique called NullReceiver in August 2026. It was discovered in trojanized npm packages associated with DPRK-linked activity.
NullReceiver uses an empty Ethereum transfer with no payment value and no transaction input data carrying an obvious payload. Instead, the malware reads the recipient address from a recent outbound transaction and converts bytes from that address into a C2 IP.
This differs from earlier EtherHiding techniques that commonly relied on smart-contract data. The transaction can look much closer to ordinary blockchain activity because there is no malicious script or configuration string sitting in an obvious data field.
Sonatype later found the same Ethereum wallet being used by malicious npm packages to locate infrastructure hosting additional JavaScript payloads, reinforcing the supply-chain risk for developers installing compromised dependencies.
DPRK-Linked Campaign Uses Multiple Blockchains for Resilience
The Ethereum activity is not an isolated experiment. Ransom-ISAC’s analysis places HashHiding inside the broader XCTDH campaign, which previously used TRON, Aptos and BNB Smart Chain infrastructure.
By September 2026, Ethereum had become a fourth blockchain used by the operation. The malware also maintained multiple C2 resolution paths rather than depending entirely on the new Ethereum mechanism.
This redundancy matters operationally. Blocking one IP address, one blockchain RPC provider or one recovery channel may not completely disconnect an infected system if another configured route remains available.
The campaign has delivered malware including DEV#POPPER.js, a cross-platform Node.js remote access trojan, and OmniStealer, a Python-based credential stealer targeting browser information, password-management data and dozens of cryptocurrency wallet extensions.
CyberUpdates365 has previously covered broader North Korean cryptocurrency operations in our North Korean Cryptocurrency Hacking Operations report.
What Defenders Should Look For
Ethereum traffic alone should not be treated as proof of compromise. Developers, financial applications and legitimate blockchain tools routinely access public RPC services. Detection needs to focus on the combination of endpoint behavior, blockchain queries and subsequent connections to suspicious infrastructure.
- Monitor unexpected Ethereum RPC activity: investigate systems that have no legitimate reason to make repeated
eth_getBlockByNumberor similar blockchain queries. - Correlate RPC requests with new outbound connections: blockchain queries immediately followed by connections to unfamiliar raw IP addresses can be more meaningful than either event alone.
- Inspect suspicious Node.js execution: Ransom-ISAC highlighted Node.js processes using unusual
-evalarguments as one detection opportunity in this campaign. - Review npm dependencies: compromised and typosquatted packages have already been used to deliver blockchain-aware malware.
- Do not rely only on domain blocking: endpoint detection and behavioral monitoring become more important when the malware can retrieve replacement infrastructure from a public blockchain.
Organizations that identify these behaviors should isolate the affected endpoint and investigate the original execution path, installed packages, stolen credentials and any secondary payloads rather than treating the blockchain connection itself as the entire incident.
Does This Mean Ethereum Was Hacked?
No. The research does not describe a vulnerability or compromise of the Ethereum network. Attackers are abusing legitimate, publicly accessible blockchain functionality as a communication mechanism.
The distinction is similar to malware operators using GitHub, Telegram, cloud storage or other legitimate internet platforms as dead drop resolvers. The underlying service is functioning normally; the malicious behavior comes from how threat actors use information hosted or transmitted through it.
For defenders, the important shift is architectural. Malware infrastructure no longer has to expose every critical configuration value through attacker-owned servers. Public decentralized systems can provide enough persistent information to reconnect compromised machines with constantly changing infrastructure.
Frequently Asked Questions
How are hackers using Ethereum for malware?
Researchers have observed malware reading Ethereum blockchain activity to discover current command-and-control server addresses. Some techniques use smart contracts, while newer approaches encode information directly inside transaction recipient addresses.
What is NullReceiver?
NullReceiver is a blockchain-based C2 resolution technique documented by OpenSourceMalware. It hides an encoded malware server address inside the recipient address of an otherwise empty Ethereum transaction.
Is Ethereum compromised by these attacks?
No. The attackers are abusing legitimate blockchain features. The available research does not indicate that the Ethereum protocol or network itself was compromised.
Official and Primary Sources
Ransom-ISAC — XCTDH Adopts Hash Hiding
OpenSourceMalware — NullReceiver Research
Sonatype Research — Malicious npm Packages Using Ethereum Transactions
Netskope — Blockchain Dead Drop Resolvers Explained
Cyber Security News — Ethereum Secret Messaging System Report
