What is EtherHiding ?

EtherHiding is a technique first documented by Guardio Labs in 2023 where attackers store malicious JavaScript payloads inside a blockchain smart contract instead of on a traditional attacker-controlled server. A compromised WordPress site injects a small loader into every page via the wp_footer hook. When a victim visits the page, their browser silently fetches the current payload from the blockchain via a JSON-RPC eth_call, then executes it with eval().

The key advantage for the attacker is resilience. A traditional C2 domain can be taken down or blocklisted within hours. A smart contract deployed on the Binance Smart Chain (BSC) cannot be removed by any third party, including Binance itself. The attacker only needs to call setPayload() to rotate their C2 domain or update their lure template — all compromised WordPress sites update simultaneously without the attacker ever touching them again.

The full attack chain from the victim's perspective looks like this:

 1. Victim visits a legitimate but compromised WordPress site
 2. Browser loads the page — wp_footer fires the injected loader
 3. Loader makes a POST request to a BSC RPC endpoint via eth_call
 4. Smart contract returns the current malicious payload (ABI-encoded string)
 5. Loader decodes the ABI response and calls eval(payload)
 6. Browser renders a fake Cloudflare Turnstile CAPTCHA (ClickFix lure)
 7. Victim clicks the checkbox — clipboard is poisoned with a malicious PowerShell command
 8. Victim follows Win+R instructions — malware executes on the host

The Smart Contract

The smart contract is the core of the technique. It stores the malicious payload as a state variable on the blockchain. Unlike a hardcoded return value in bytecode, a state variable can be updated by calling setPayload() without redeploying the contract — the contract address never changes, only the stored value does.

The contract is written in Solidity and compiled using Remix IDE at remix.ethereum.org. For the simulation we deploy to the Sepolia testnet rather than BSC Mainnet — functionally identical but using worthless test ETH.

Deploying the Contract (deploy.js)

The contract is deployed using Node.js and the ethers.js library. Remix's built-in deployment requires a browser wallet extension (MetaMask), which may not always be available. Using a Node.js script with a raw private key bypasses this dependency entirely.

First, generate a test wallet and fund it with free Sepolia ETH from Google Cloud Faucet:

Rotating the Payload (update.js)

Once deployed, the contract address never changes. The attacker updates the payload by calling setPayload() — this is a state-changing transaction that permanently updates the stored string on-chain. Every compromised WordPress loader automatically serves the new payload on the next page visit.

update.js reads the payload from a file to avoid one-liner limitations on complex HTML/JS content:

WordPress wp_footer Injection

The wp_footer hook is an action hook in WordPress's core rendering lifecycle. It fires on every page, on every request, right before the closing </body> tag. Any callback registered to it renders its output into every page of the site automatically — which is why attackers target it. One injection point reaches every visitor.

In a real compromise, the attacker gains write access to functions.php via one of several paths: stolen wp-admin credentials and the Theme File Editor, a vulnerable plugin CVE granting remote code execution, FTP/SFTP credential compromise, or SQL injection directly into the wp_options database table. For this simulation we use a Docker-hosted WordPress instance and edit functions.php directly.

First, identify the active theme:

The ClickFix Lure Payload

The payload stored in the smart contract is a JavaScript string that gets passed directly to eval(). It uses document.body.innerHTML to replace the entire page with a fake Cloudflare Turnstile CAPTCHA — the ClickFix lure.

Note: script tags injected via innerHTML do not execute — this is a browser security feature. The payload must be pure JavaScript executed via eval(), not HTML containing <script> tags.

Create payload.js:

ABI Decoding the Response

The raw response from eth_call is an ABI-encoded hex string. Ethereum's ABI encoding for a string type always follows a three-chunk structure of 32 bytes (64 hex characters) each:

 Chunk 1 (bytes 0-63): offset pointer — always 0x20 (32) for a single string return, indicating where the string data starts
 Chunk 2 (bytes 64-127): string length in bytes, as a hex integer
 Chunk 3 (bytes 128+): the actual UTF-8 bytes of the string, zero-padded to the next 32-byte boundary

Proxy Log Analysis

When a victim visits the compromised WordPress page, three distinct log entries appear in the proxy — chained by the same source IP and Referer header:

 Request 1 — GET to the WordPress page (normal page load)
 Request 2 — POST to the Alchemy/RPC endpoint (eth_call fetching the payload)
 Request 3 — GET to google.com (eval() executes the redirect payload)

Request 2 is the detection signal. With SSL inspection enabled on Zscaler or a similar proxy, the POST body is visible and contains the full JSON-RPC payload:

Detection

The following detection strategies are ordered from highest to lowest confidence.

Network layer — POST to blockchain RPC endpoint from browser
The most reliable signal: a browser process making a POST request to a known blockchain RPC provider domain. Legitimate users do not browse to WordPress sites that call Ethereum nodes.