EtherHiding: When the Blockchain Becomes Your C2

Traditional command-and-control infrastructure has a fundamental weakness: it’s centralized. A domain can be sinkholed. A server can be seized. A CDN can be subpoenaed. Law enforcement and security researchers have spent decades perfecting the playbook for disrupting C2 channels.

North Korea’s UNC5342 decided to make that playbook obsolete.

EtherHiding stores malware payloads and C2 instructions inside smart contracts on public blockchains — Ethereum and BNB Smart Chain. The “server” is a distributed network of thousands of nodes. Nobody controls it. Nobody can take it down. The data is immutable.

HACK

Once C2 information is committed to the blockchain, it possesses a level of permanence and availability that traditional hosting cannot offer. There is no central server to seize, no registrar to compel, no hosting provider to contact.

How Traditional C2 Fails

The cat-and-mouse game of C2 infrastructure follows a predictable pattern:

Attacker registers domain → Malware beacons to domain
     ↓
Security team discovers domain → Contacts registrar
     ↓
Registrar suspends domain → C2 channel dies
     ↓
Attacker registers new domain → Cycle repeats

Variations exist — fast-flux DNS, domain generation algorithms (DGAs), Tor hidden services — but they all share a common trait: somewhere in the chain, there’s an entity that can be compelled or compromised to disrupt the channel. Registrars comply with abuse reports. Hosting providers respond to court orders. Even bulletproof hosting in sympathetic jurisdictions eventually gets shut down.

EtherHiding breaks this model entirely.

The Architecture

The technique is elegant in its simplicity:

1. Deploy a smart contract on Ethereum or BNB Smart Chain. The contract contains encoded C2 instructions or payload URLs in its storage variables.

2. Malware queries the blockchain using standard JSON-RPC calls (e.g., eth_call) through public RPC endpoints like Infura, Alchemy, or any Ethereum node.

3. The response is parsed to extract the C2 address, payload URL, or configuration data.

4. Update when needed. If the contract is deployed with a mutable storage pattern, the attacker can update C2 instructions by sending a new transaction — while all historical data remains immutable on-chain.

┌──────────────┐     JSON-RPC      ┌───────────────────┐
│   Infected    │ ───eth_call()───→ │  Ethereum / BNB   │
│   Host        │                   │  Smart Contract    │
│              │ ←──ABI response── │  (C2 instructions) │
└──────────────┘                   └───────────────────┘
       │                                    ↑
       │                             Transaction (update)
       ↓                                    │
┌──────────────┐                   ┌───────────────────┐
│  Fetch stage  │                   │  Attacker Wallet  │
│  2 payload    │                   │  (pseudonymous)   │
└──────────────┘                   └───────────────────┘

From a network monitoring perspective, the malware’s traffic looks like ordinary Web3 API calls — the same requests that millions of DeFi applications, wallets, and dApps make every second.

The DPRK Toolchain

Google’s Threat Intelligence Group (GTIG) first observed UNC5342 adopting EtherHiding in February 2025, marking the first time a nation-state actor embraced the technique. The campaign was tied to the “Contagious Interview” operation — fake job postings targeting software developers.

JADESNOW (Stage 1 Downloader)

The initial JavaScript downloader interacts with a malicious BNB Smart Chain contract to retrieve the next-stage payload. JADESNOW queries the transaction history associated with a specific Ethereum address to fetch encrypted payload URLs.

INVISIBLEFERRET (Stage 2 Backdoor)

A Python-based backdoor with extensive capabilities:

• Browser data theft — credentials, cookies, crypto wallet extensions
• Cryptocurrency targeting — steals from 13+ different wallet types
• Keylogging and clipboard monitoring
• File exfiltration via FTP and Telegram bots
• Persistent remote access via AnyDesk installation
• System reconnaissance — geolocation, system fingerprinting

EtherRAT (Post-Exploitation)

Documented by Sysdig, EtherRAT was deployed via React2Shell (CVE-2025-55182) exploitation. It represents the convergence of two DPRK capabilities: the EtherHiding C2 technique with the React2Shell initial access vector.

INFO

The full infection chain: Social engineering (fake job interview) → JADESNOW (JavaScript downloader, blockchain C2) → INVISIBLEFERRET (Python backdoor) → credential theft, crypto wallet drain, persistent access.

Why It’s Hard to Stop

The advantages for attackers are significant:

Traditional C2	EtherHiding C2
Domain can be sinkholed	No domain to sinkhole
Server can be seized	“Server” is thousands of nodes
Hosting provider can comply with law enforcement	No single entity to compel
Traffic is anomalous	Traffic mimics legitimate Web3 calls
Historical infrastructure can be studied post-takedown	All data remains on-chain permanently

Blocking specific RPC endpoints (Infura, Alchemy) provides only temporary relief — the malware can switch to any public Ethereum node, including self-hosted ones. The blockchain itself is the infrastructure, and blocking the blockchain means blocking all of Web3.

The pseudonymous nature of blockchain transactions makes attribution harder, too. While chain analysis can sometimes link wallet addresses to identities, deploying a smart contract from a freshly generated wallet leaves minimal traces.

Detection Approaches

EtherHiding isn’t invisible. It has detectable characteristics if you know where to look:

Network monitoring:

• Watch for eth_call or eth_getStorageAt JSON-RPC requests from hosts that have no business interacting with blockchain infrastructure
• Monitor for connections to public RPC endpoints (Infura, Alchemy, QuickNode) from non-Web3 applications
• Flag processes that make blockchain API calls followed by downloading and executing payloads

Endpoint detection:

• Look for JavaScript or Python processes making Web3 RPC calls
• Monitor for ABI decoding libraries being loaded by unexpected processes
• Watch for the JADESNOW → INVISIBLEFERRET execution chain

Smart contract analysis:

• Contracts storing encoded URLs or IP addresses in their storage
• Contracts with update functions called from known-malicious wallets
• Unusual patterns in contract interaction frequency

# Example: Query a contract's storage slot for suspicious content
cast storage <contract_address> 0 --rpc-url https://eth.llamarpc.com
# Decode and check for URLs, IP addresses, or encoded payloads

WARN

If you detect EtherHiding C2 traffic on your network, assume full compromise. The malware families deployed through this technique — particularly INVISIBLEFERRET — are designed for deep, persistent access and credential theft.

The Philosophical Problem

There’s an irony that’s hard to ignore: blockchain technology was built on the principles of decentralization, censorship resistance, and immutability. These were features, designed to protect against authoritarian control and corporate censorship.

North Korea is using those exact features to run untakedownable malware infrastructure.

The blockchain doesn’t distinguish between a DeFi protocol storing collateral ratios and a nation-state storing C2 instructions. Both are just bytes in a smart contract. The censorship resistance that protects activists in authoritarian regimes also protects the attackers stealing billions in cryptocurrency to fund weapons programs.

This isn’t a bug in the blockchain. It’s a fundamental tension in the design philosophy. And it doesn’t have a clean solution.

---

The server you can’t take down is the one that belongs to everyone.

-- bl0ckd3ad