ClickFix to a macOS Stealer, Served From Thousands of Hacked WordPress Sites

This is the same social-engineering idea as any other ClickFix chain - the page asks the visitor to run the payload themselves, so nothing malicious is downloaded for a browser control to catch - but it is worth tracking in its own right because of where it lives and who it targets.

The injection hides as an analytics tag

The compromised sites are ordinary WordPress installs - small businesses, clinics, schools, a run of government and diplomatic sites - with one script added to every page. It is labelled to sit unnoticed next to real Google tags:

<script id="ganalytics-tracker-js" src="[rotating-domain]/t.js?site=[hex32]">

The site value is a stable per-victim identifier, so the same site keeps the same token while the domain it loads from changes underneath it.

Patching the site does not clean it

The loader is emitted through WordPress's own script API rather than hardcoded into a template, which means it is enqueued by code the attacker left behind - a must-use plugin, a modified theme functions.php, or a stored option. Core updates do not touch any of those. A site can be running the current WordPress release and still serve the loader on every page, which is exactly what we see: many affected sites are fully patched. Cleaning one means removing the injected enqueue and finding the persistence behind it, not updating core.

The domains rotate; the hosting does not

The lure domains burn fast - a fresh one appears roughly daily - and run three naming styles in parallel: random adjective-noun-gibberish, Google-Analytics typosquats, and analytics-flavoured words on cheap top-level domains. Chasing them one at a time is a losing game. What holds still is the hosting: every lure origin we resolved sits on the same sanctioned network, so the autonomous system is a far better pivot than any single domain.

What the visitor is shown

On a Mac, the loader renders a fake reCAPTCHA, then a "verification steps" panel that walks the person through opening Terminal and pasting a command. The command is a decoy line followed by a base64 blob piped to a shell, which pulls a macOS stealer that goes after crypto wallets, browser logins and the Keychain. Everything harmful happens in a terminal the browser cannot see, so the page-side evidence is the overlay and the connection that delivered it.

What to look for

The loader has to come from somewhere, so an unfamiliar host in script-src reports on a page that has no reason to load third-party analytics is the first signal - especially a freshly registered domain on an unusual top-level domain. Because the domains rotate, alert on the shape rather than the name, and treat a script host that appears once and is never seen again as worth a look rather than something to tune away.

The hosts we're tracking for this campaign

These are the entries in our threat intelligence feed for this campaign, shown exactly as we match them. An entry starting *. covers that domain and everything under it, so an attacker cycling through subdomains doesn't get away from it. We only do that when the attacker registered the domain themselves.

The feed changes as we go. We add hosts when they show up and pull them out when the evidence no longer holds, so this is what we're matching today rather than a permanent record.

Frequently asked questions