Three separate mechanisms can each hand a scanner a clean page. A single automated fetch meets all three

The page decides what you are before it decides what to show you

CTM360 published ClickFix and Beyond on 22 September 2026, a campaign-level and host-level analysis of the technique that persuades a user to paste a command into their own shell. The campaign set runs to more than 3,000 active compromised websites. One of them, a painting and decorating business in Surrey, was taken apart in detail using nothing but the responses it returned to an ordinary visitor.

The finding worth carrying out of that analysis is not about the lure. It is about the word clean.

Three mechanisms sit between an incoming request and the malicious instruction, and each one of them, on its own, is enough to return a page with nothing wrong on it.

One: the traffic distribution system. Before the lure is shown, a background script polls two operator endpoints roughly every 1.5 seconds, one checking a skip_captcha flag and one checking whitelist and found status. If either comes back true, the script silently signals success and reloads. The visitor never sees a command.

Two: the suppression cookie. CTM360's table of visitor conditions records that any visit within 90 days of the first sets a suppression cookie on that first view. Phones and tablets get no overlay at all, because no mobile command exists. macOS and Linux landing pages were built and switched off in the configuration observed.

Three: the fingerprint gate. The PowerShell dropper collects the machine GUID, the C: volume serial number, the computer name, the BIOS manufacturer, the system model, the GPU name and the username, base64-encodes the lot and puts it in the download path itself. The command and control server therefore knows the machine before it serves anything, and can return a payload chosen per machine, or nothing.

The part that makes this a finding rather than a list. The three do not overlap. A crawler that discards cookies is untouched by the second mechanism and still meets the first. A sandbox that keeps cookies and runs Windows gets past both and still meets the third. A checker running anything other than Windows is filtered before any of it. There is no configuration of a single automated fetch that clears all three, which is why CTM360 writes that absence of a payload in a sandbox is not evidence that a site is clean.

What that does not establish. It does not establish that automated scanning is worthless, and CTM360 does not say so: the report's own method is built on externally observable responses. It does not establish that every ClickFix campaign is built this way, because two operator clusters are described and the detailed host analysis is of one site. It does not name the final malware family for that host, because the archive served to that fingerprint was not retrieved. And it does not establish how the site was first taken: the My Calendar plugin flaw, CVE-2026-6854, is offered as a suspected possible entry point and nothing more.

What each mechanism actually filters

The three cloaking mechanisms as documented in CTM360's report, and what each one fails to stop. Read the last column first.

Mechanism	What it filters	What it does not stop
Traffic distribution system, polled every 1.5 seconds	Any session the operator marks as verified or whitelisted, silently	A visitor the operator wants, who is served the lure immediately
Suppression cookie, 90 days from first view	Repeat visits from the same browser profile	A checker that discards cookies between runs
Fingerprint in the download path	Machines the operator does not recognise or want	Nothing about the fetch itself; the lure was already shown

The method that does work, and it is seven requests

The useful counterweight in the report is that CTM360 establishes its central technical claim, that the loader is appended by PHP at the output layer rather than inserted into any page, post or theme, using seven ordinary requests. Each one eliminates a competing explanation, and the combination is what makes the conclusion firm. No single request would.

The root page is the baseline. A request for a page that does not exist returns the 404 template, still injected, which eliminates injection into a specific post. wp-login.php loads neither the theme nor the footer hook, and is still injected, which eliminates the theme. The RSS feed eliminates any template path, and /wp-json/ eliminates every WordPress output path at once. robots.txt is PHP-generated and injected, which shows the loader follows PHP rather than file extension. And a static stylesheet comes back clean, which eliminates the webserver, a content delivery network and a web application firewall.

That last row is the one that turns the set into proof. A method that only ever returns a positive cannot distinguish anything.

There is a free indicator hiding in the same evidence. Appending a script block to every dynamic response breaks the site's own interfaces: the REST API stops returning valid JSON and the feed becomes malformed XML. Owners report this as an unrelated plugin conflict. If you run a portfolio of sites, a request to /wp-json/ that does not parse is a passive check you can run across all of them tonight, and it does not depend on being shown the lure.

Why the report ends on four chokepoints rather than a block list

The reason all of this matters operationally is that the parts of a ClickFix campaign that a defender can enumerate are the parts that are cheap to change. The lure art, the brand impersonated, the keyboard shortcut and the payload family all move constantly. The report's own timeline shows the instruction surface migrating from the Run dialog to Windows Terminal, to the File Explorer address bar, to a fake upload dialog, to the macOS Terminal and then, after Apple shipped a mitigation for pasted Terminal commands, to Script Editor. Each move answers a control that had started working.

What has not moved in nearly three years is the shape: a page writes to the clipboard, a user opens an interpreter, the interpreter reaches the network, something persists. CTM360 names those as four chokepoints and says which to pick if you can only do one this quarter.

That framing is worth more than the indicator lists that usually close a report like this one, and CTM360 is explicit about the limits of its own indicators. Fourteen Polygon remote procedure call providers appear across the observed loaders, alongside api.telegram.org and IP reflection services, and all of them are shared infrastructure with legitimate users. The report's answer is contextual rather than destination based: alert when a script interpreter contacts them, not when anything does. PowerShell reaching a Telegram API endpoint is anomalous in almost every enterprise regardless of how legitimate that endpoint is.

What to do about it

The question this leaves

The uncomfortable implication is not that this campaign is sophisticated. Most of it is not: the account farm on the Surrey site used usernames with a lowercase L in place of an I, and the injection is crude enough to break the site's own feed. The uncomfortable implication is about the shape of the evidence we accept.

A negative result from a scanner is treated everywhere as information. In this chain it is the designed output for anything the operator does not recognise, produced at three separate points, and it looks exactly like the negative result you would get from a site that had never been touched.

So the question for your own reporting: when a tool tells you something is clean, do you know whether that is an observation or a response?