Published 17 September 2026
We add a host to this list when it shows up in customer reports doing something it shouldn't. Usually
that judgement takes a few minutes: a skimmer posts card data somewhere, a redirector sends people
off the site, a fake payment field draws itself over a real one. This one took longer, because on the
sites where we see it, almost none of the code does anything at all.
Most of it never runs
The script is a toolkit rather than a payload. It carries modules for rewriting links to extension
stores, for dropping a transparent layer over a page and harvesting the clicks that land on it, for
reading queries out of a search box, and for catching common typos of well-known domains and sending
those visitors somewhere else. A lookalike of a large travel booking site is hard-coded into that
last one.
None of it applies to a shop, and the code knows that. Each module checks the hostname before it acts,
so on a storefront they sit there switched off. Several of the hosts we track for this campaign are
named only inside those sleeping branches, and we have never seen one of them fetched from a retail
site.
We list them anyway, and the reason is worth being clear about. A dormant branch is dormant because
of a condition in a file the operator serves. They can change that file whenever they like. What is
inert on your site today is inert by their choice, not yours.
It checks whether anyone is looking
Before any of that, the script reads the page's search input and the URL query for words an analyst
investigating adware would be likely to type. Hit one of them and it stays quiet for the rest of the
visit. Hit two or more and it writes a record into local storage that keeps it quiet on that browser
from then on.
It is a habit from the extension days and it is tied to the URL shape of one search engine, so on a
shop it never fires. We mention it because it explains something about the people behind this. Anyone
who tested the old version by searching for "virus" or "popup" to see what happened got a clean
result and no hint that they had just been fingerprinted.
The branch that does run
What survives the move to a storefront is short. The script reports visitor details to hosts the
operator controls, asks those hosts what to do, and will take JavaScript back from them and run it in
the page.
That is a backdoor in the ordinary sense. The file on the site never has to change again; everything
after this point is decided on a server we cannot see. We have no idea what has been served through
it, and neither does anyone outside the operation. On the site where we found it, the shop was
working normally the whole time.
It has been here four years
Our corpus covers 1,518 days. Two of these hosts appear on more than 1,200 of them, starting at the
end of June 2022 and continuing through to reports we received this August. One has been reported by
42 separate accounts and the other by 39. A third host is thinner but sits in the same window: 286
days, four accounts, last seen in May.
Four years without needing to change infrastructure says something about how much attention this has
had. There is nothing disposable about these hosts. They are a stable back end that nobody has
bothered to take away, still being reached from sites whose owners have no idea they are reaching it.
What it looks like in your reports
A script load or a connection to a host you don't recognise, from a page with no obvious third-party
component on it. The volume is low and fairly even rather than spiky, because the telemetry runs for
every visitor instead of waiting for a particular one. There is nothing visible on the page and no
redirect for anyone to notice.
If it is your domain in the report, assume for now that the script tag is in your own markup rather
than someone else's.
What to do about it
Look in your templates first. This one was placed directly rather than arriving through an ad tag or
a tag manager, so the reference is probably somewhere you control and can find. Once you have it,
the more useful question is how it got written: an admin account with more access than it needs, a
theme or plugin from outside your supply chain, a change nobody remembers making.
Block the hosts as well, by all means. It stops today's fetch. It does not do anything about the
person who was able to edit your storefront, and that is the part that will still be true next month.
Indicators
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.
Observed in Report URI report telemetry. We classify these on what we saw them doing, not on any claim about who runs them.
Disputing a classification →
FAQ
Frequently asked questions
No. Nothing in the code we have goes near a card field. It fetches JavaScript from a server the operator controls and runs it, so what it does on any given day is a decision made at the other end rather than something you can read off the file.
Because inactive here means the branch that would call them is switched off, not that the host is gone. Whoever serves the script decides which branches run, and they can change that without touching your site.
Our guess is that it was simply the tool to hand. Getting code onto a site and choosing what that code does are separate problems, and the parts of this toolkit that only make sense on a search engine just sit there unused.
On the site we could see, it was referenced straight from the site's own HTML rather than pulled in by a tag manager. Browser telemetry cannot tell you how the reference got written, but admin credentials, a template edit and a third-party theme are the usual three.
Find the script tag in your own markup first. The host is replaceable and whoever wrote that line into your template can write another one, so the question worth answering is who has edit access to your storefront and when they last used it.
Find out if this is running on your site.
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
