# A Redirect Campaign That Never Touches the Site It Runs On A redirect and search-poisoning operation that runs inside trusted domains without compromising any of them, because the whole attack fits in a URL. Provenance: Observed in Report URI report telemetry. Published: 2026-09-05. Updated: 2026-09-05. Most of what reaches this feed got onto a page because something was compromised: a server, a build step, a supplier. This one did not. The sites carrying it are serving exactly the files they have always served, and the people running them would find nothing wrong if they went looking. The attack is a link. ## Everything happens in the query string Some components take the page's URL parameters and hand them to themselves as configuration. A 360 panorama viewer is a common one: it has a setting that passes the query string through to the viewer's own variables, and one of those variables names the XML file it loads its configuration from. Turn that setting on, and anyone can tell the viewer to load its configuration from somewhere else. The configuration is not inert. That format has an action language, and one of the actions runs JavaScript. So a URL, and nothing else, gets attacker-controlled script running in the origin of whatever site embeds the viewer. Old file-manager components have the same shape for the same reason: they were built to reflect what they were asked for. None of this is new, and that is the uncomfortable part. The class of flaw was written up publicly in early 2025, the viewer shipped a fix, and the campaign is still running — because the fix has to be applied by every site owner individually, and it is a setting most of them have never heard of. ## The payload has two jobs Once it is running, the injected script asks the operator's server what to do, and gets one of two answers. The first is a redirect. The visitor is sent onward, with the referrer deliberately stripped first, so whatever they land on has no idea which site sent them. The second is more patient. Instead of moving the visitor, the script rewrites the links already on the page so that each one points back at the same site with another one of these URLs attached. A search engine crawling that page finds spam content on a trusted domain, linking to more pages on that same trusted domain. The ranking that domain earned gets spent on the operator's content. This is the half that pays, and it is why high-authority sites are the targets. ## The visitor you cannot reproduce Three filters sit between a curious administrator and the payload. The redirect only fires when a specific parameter is present, so a plain visit to the page behaves normally. The final destination is geographically gated — from the wrong country it answers with a refusal rather than the offer. And because the referrer was stripped, nothing downstream can be traced back by the site owner even if they think to look. The result is a page that works perfectly for its owner, for their monitoring, and for most scanners, while real visitors in the targeted country are funnelled somewhere else. It surfaced here because a browser that actually ran the payload reported the connection it attempted, which is the one vantage point none of those filters can close. ## The domain changes, the operation does not The controller domain in the current generation was registered days before it reached us. Taken alone, it looks like a short-lived host worth blocking and forgetting. It is not. The same injection shape, the same trigger parameter and the same payload structure run back well over a year, across a succession of gateway domains that replaced each other as they burned out. What we are tracking is not a domain, it is an operation that treats domains as consumables. That shape decides what to do about it. Blocking the host currently in your reports stops today's node; the operator has more and can register another this afternoon. The part with a long life is the vulnerable component sitting on your own site, which is what every generation of this campaign has needed and the only piece they cannot replace. ## What it looks like in your reports Not what you would expect from the word "skimmer". The first sign is a `connect-src` violation rather than a script load, because the injected code's first act is to ask an operator's endpoint what to do. Volume is low and uneven, since the payload only runs for a fraction of visitors. And the page it appears on is often nothing to do with checkout — a campus map, a virtual tour, a gallery, a page nobody thinks of as sensitive. An unfamiliar host in your reports on a page with no third-party interface is the signal, whatever it turns out to be serving. ## What to do about it Find the component before you chase the domain. Anything on your site that renders a panorama, a virtual tour, or a legacy file browser deserves a look at how it treats query parameters. If a parameter can name a file for the component to load, it can name one of theirs. For the viewer at the centre of this campaign, that means updating to a version that refuses external and `data:` URLs for the parameter in question, and turning off the setting that passes the query string through at all unless you genuinely need it. For end-of-life file-manager components, delete them rather than patching them — they have not been maintained for years and nothing you run today needs them. Then check whether you are already being used: search for your own indexed pages carrying query parameters you never linked to yourself. Poisoned URLs stay in a search index long after the underlying setting is fixed. ## Indicators - *.1bots.top - *.gomore.online - *.googlo.top - *.iles.pics - *.magictrrop.works - *.sb1es.com - bvmeuro.info ## Questions ### How can a site be abused without being compromised? Because nothing is stored on it. The attack is a link. A page that reflects a URL parameter into something the browser executes will do that for anyone who sends the link, and the file on the server is the same file it always was. Nothing to find in a diff, nothing in the access log but a normal request for a page that exists. ### What is a traffic distribution system? The layer between the hijacked page and whatever the visitor finally sees. It decides per click: what country you are in, whether you look like a real browser, whether the operator wants your traffic today. That is why two people following the same link can get two different pages, and why one of them can get nothing at all. ### Why did we see it and a scanner did not? The payload only runs for a real visitor, in the targeted country, arriving the right way. A crawler checking the site gets a working page. The browser that ran the payload reported the connection it tried to make, and that report is the whole finding. ### Does it matter if the visitor was not us? It was your visitor, on your domain, under your certificate. They will remember which site sent them, and the search results being poisoned are yours. The operator picked the domain precisely because it is trusted. ### How do I know whether this affects me? Look at how any 360 tour, panorama viewer or legacy file manager on your site handles URL parameters, and search for your own indexed URLs carrying parameters you never linked to yourself. If a query string can tell a component what to load, assume someone has already tried it.