An overlay that tells the visitor to fix a problem by pasting a command, turning the person into the delivery mechanism and leaving no malicious download to catch.
Published 14 July 2026
Updated 24 August 2026
Most web-delivered malware has to get past the browser. It needs a download the user accepts, a plugin, an exploit, or a script the page is allowed to run. Each of those is something a defender can watch for.
ClickFix skips all of it by asking. The page shows a message — a failed verification, a font that won't load, a document that needs a fix — and gives the visitor a command to paste into a terminal or a Run box to sort it out. If they do, the machine is compromised, and nothing the browser did was wrong.
Every control on the download path assumes the browser is fetching the harmful thing. Here it isn't. It renders an overlay containing text. The text is the payload, and it executes in a terminal the browser has no view of.
That also means the usual evidence is missing afterwards. There is no downloaded file with a bad reputation, no blocked script, no exploit attempt in the logs. What there is, on the page itself, is an overlay that should not exist and a connection carrying it.
The hosts we track for this campaign split into two roles.
One serves the reflected payload — the overlay markup and the instruction shown to the visitor. It is injected into a compromised page, so the site hosting it is a victim rather than the operator.
The other is a WebSocket C2 that drives the chain. That choice matters. A script fetched once is fixed until the attacker changes the file, and changing the file means going back into the compromised site. A WebSocket stays open, so the operator can change what the page says, swap the command, and watch who complies, all without touching the site again.
The same infrastructure moves between purposes. Part of this cluster was previously running a Magecart skimming campaign and was repurposed for ClickFix, which is a good reason to keep a host listed after the campaign it was first seen in has stopped.
Several hosts here share a naming style — chat and support-widget words on cheap top-level domains. One host came to us named alongside another we were already tracking, and it matched the pattern of two more we had listed earlier.
That resemblance is not proof on its own, and we do not list a domain because its name looks like another one. It is a reason to look closely at something that would otherwise sit unexamined, which is what the Suspicious tier exists for.
You are looking for two things, and they are governed by different directives.
The overlay comes from somewhere, so an unfamiliar host appearing in script-src or frame-src
reports on a page that has no reason to load third-party UI is the first signal.
The WebSocket is the second, and it is the one people miss. WebSocket connections are governed by
connect-src, so an attempt to open one to a host you never authorised is reported like any other
connection. A connect-src violation naming an unfamiliar host on a page that does nothing real-time
is worth treating as a finding rather than tuning away.
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.
*.onlinechatusbot.comconsent.trandiqs.commetrics.brandiser.netonlinechatmatrix.storeonlinechatmatrix.xyzCorroborated by external research. We classify these on what we saw them doing, not on any claim about who runs them.
We flag these hosts in your own reports automatically, so you hear about it from us instead of from your customers.
← All threat intelligence research · Read this page as Markdown