Unmasking Etherhiding: Reverse Engineering a Modular ClickFix Loader

Unmasking Etherhiding

The ClickFix campaign is notorious for leveraging social engineering (often fake browser updates or CAPTCHA prompts) to trick victims into executing malicious code. Recently, I analyzed a highly sophisticated variation of this campaign.

Rather than dropping a monolithic infostealer straight to disk, this variant uses a heavily obfuscated multi-stage loader, custom rolling decoders, and a fascinating Web3-based C2 resolution mechanism known as Etherhiding.

Collaboration: This research was conducted alongside QurtiDev and miikie.

1. High-Level Execution Flow

Before diving into the technical weeds, here is a summary of the execution chain:

Initial Infection — rundll32 execution leads to Stage 2 shellcode injection
Evasion — Millions of delay loops defeat sandboxes and emulators
Decryption — Reveal CHOC config header → 0xa4f1 bytewise rolling XOR decoder
Decompression — LZNT1 payload decompressed via RtlDecompressBuffer
Stage 3 — Modular payload executes: crypto clipper hooks + Etherhiding C2 resolution
Download — Browser stealer module loaded reflectively from C2

2. Bypassing Stage 2 Anti-Emulation

The Stage 2 loader is a self-modifying shellcode stub. When analyzing it dynamically or attempting to emulate it (e.g., using Capstone or Unicorn Engine), you are immediately met with massive nested delay loops. These loops execute millions of iterations per byte without altering critical registers. Their sole purpose is to exhaust the execution limits of automated sandboxes and emulators.

Instead of fighting the loops statically, we built a Python harness using ctypes to inject the shellcode into a suspended child process. By allowing the shellcode to run natively for a few seconds, it naturally bypassed its own delay loops and decrypted its internal state. We then dumped the memory via ReadProcessMemory.

3. The CHOC Header and 0xa4f1 Decoder

Inside the decrypted memory dump, we located a configuration structure anchored by the magic bytes CHOC (0x434F4843). By cross-referencing the assembly, we identified a loop (near offset 0xa4f1) responsible for decrypting the main payload blob.

It utilizes a clever bytewise rolling XOR algorithm. Instead of using a static XOR key for every byte, it feeds the previously decrypted byte back into the equation. Here is how we recreated the decoder in Python:

def decode_a4f1(src_buffer, key_byte):
    dest_buffer = bytearray(len(src_buffer))
    for i in range(len(src_buffer)):
        al = 0 if i == 0 else dest_buffer[i - 1]
        al = (al + key_byte) & 0xFF
        al = al ^ src_buffer[i]
        dest_buffer[i] = al
    return bytes(dest_buffer)

Once decoded, the first four bytes represent the uncompressed size, followed by an LZNT1-compressed stream. We successfully recovered the final Stage 3 Portable Executable by passing it to the native ntdll.RtlDecompressBuffer API.

4. Stage 3: Etherhiding and Modular Downloads

When analyzing the decompressed Stage 3 binary, something immediately stood out: there were no static strings related to browsers. No references to sqlite3 or Login Data. Instead, the binary acts as a modular Crypto Clipper and Downloader.

Crypto Clipper Hooks

The binary explicitly imports OpenClipboard, GetClipboardData, and SetClipboardData. It establishes these hooks immediately upon execution to monitor the clipboard for cryptocurrency wallet addresses, swapping them out for attacker-controlled addresses on the fly.

Etherhiding C2 Resolution

The malware does not contain a hardcoded Command & Control (C2) IP address or domain. Instead, it relies on Etherhiding. We extracted the following strings from the binary:

bsc-dataseed.bnbchain.org
{"id":1,"jsonrpc":"2.0","method":"eth_call","params":[{"to":"0x7CC3cFC1Ac007B8c6566fD2C7419b15a75473468"

The malware sends an eth_call JSON-RPC request to a public Binance Smart Chain (BSC) node. This request queries a malicious smart contract (0x7CC...). The smart contract responds with a string containing the actual C2 IP address or URL.

⚠️ Evasion Architecture: Because the blockchain is immutable and decentralized, law enforcement cannot take down the domain. If the attacker's actual server is seized, they simply update the smart contract variable to point to a new IP, and all infected bots seamlessly migrate.

Fetching the Browser Stealer

Once the C2 is resolved via the blockchain, Stage 3 utilizes the WinINet API (InternetOpenA, HttpSendRequestA, InternetReadFile) to pull down the browser stealer module dynamically. This secondary payload is then loaded reflectively into memory, meaning the actual infostealing logic never touches the disk and avoids static detection entirely.

5. Defense & Mitigation

The ClickFix campaign is uniquely dangerous because it relies heavily on social engineering rather than exploiting software vulnerabilities. It tricks users into manually executing the initial loader. Here is how you can protect yourself and your organization:

Common Attack Vectors

Fake CAPTCHA Prompts: Sites claiming you need to "verify you are human" by pressing Windows Key + R and pasting a command.
Fake Browser Updates: Pop-ups insisting your Chrome, Edge, or Firefox is out of date and downloading a malicious script.
Malvertising: Malicious ads pushed to the top of search engines for popular software downloads.

How to Stay Safe

Never Paste Blind Commands: Legitimate websites will never ask you to open the Windows Run dialog, Command Prompt, or PowerShell to verify your identity or update your browser.
Use Ad Blockers: Extensions like uBlock Origin significantly reduce the risk of encountering malvertising or fake update pop-ups.
Verify Cryptographic Addresses: Because the final payload includes an active crypto clipper, always visually double-check the first and last few characters of any cryptocurrency wallet address immediately after pasting it.
Endpoint Protection: While this specific variant utilizes Etherhiding and rolling decoders to evade static signatures, behavioral analysis from modern EDR solutions can often catch the anomalous rundll32 execution patterns before the shellcode can fully inject.

6. Research Artifacts & Samples

⚠️ Warning: Live Malware — The samples analyzed in this research contain actual malicious payloads. Do not execute these files on a host system. Handle with extreme caution and only within a secure, isolated sandbox environment.

Files analyzed:

c.txt — The original infected shellcode text file
stage2_decoded.bin — The Stage 2 memory dump after bypassing delay loops
stage3_packed.bin — The LZNT1 compressed blob post 0xa4f1 decryption
stage3_unpacked.bin — The final modular Stage 3 payload