The most deceptive malware on a website does not necessarily break the site. The product may display normally, the basket may work, the customer may be able to pay and there may be no red warning message anywhere. The real problem can be happening quietly in the background, inside the user’s browser.

Cloudflare described four campaigns built around exactly that idea. One intercepted clicks and routed them through an affiliate link. Another generated an affiliate request without the user clicking anything. A third could download and execute additional JavaScript from an attacker-controlled server. The fourth activated only for selected mobile users arriving from paid campaigns and tried to disable analytics and support tools.

Why a normal scan can miss this completely

The common thread across these operations was not one signature or one particular way of hiding code. The scripts could check the device, country, time of day, traffic source, campaign parameters, browser state or the user’s network, then activate the real behaviour only when a specific combination of conditions matched.

WebsiteGarage / Services

Explore our services.

That means someone checking the store from a laptop in the office may see completely different behaviour from a customer arriving through an ad on a phone. One of the campaigns Cloudflare described even contained a list of 325 IP address fragments and stayed dormant on selected networks, making it harder to catch during analysis.

That is exactly why the static question “Is this file already known to be malicious?” is not always enough. Cloudflare says that when the campaigns were discovered, seven of the eight payloads were not listed in VirusTotal, and URLScan had not flagged any of the eight as malicious.

The first campaign did not steal card details. It stole the credit for the sale

In one case, the malicious script waited for the right moment and intercepted a mobile user’s click. The customer still saw the store, but the traffic was routed through an affiliate path prepared by the attacker.

The result could be incorrect sales attribution and a commission being assigned to someone who had not acquired the customer at all. It is a very good example of why a “security incident” does not always mean stolen passwords or card numbers. Sometimes the attack goes straight after the economics of marketing and the data a business uses to judge whether its campaigns are working.

Cloudflare is careful to separate what the code was capable of doing from the effects that were actually confirmed. In a second variant, the script could generate a hidden affiliate request without any user click, but the researchers did not confirm whether those requests actually resulted in commission payments.

The marketing chain is part of the attack surface too

In one operation, the route into the browser ran through a chain of marketing scripts: Google Tag Manager loaded another tag manager, which then loaded the malicious script. Cloudflare explicitly notes that this is not evidence that the tag managers themselves were compromised. What it does show is how quickly the number of places a website loads code from grows as more marketing tools are added.

That matters because store owners usually think about security in terms of the server, WordPress, administrator accounts and plugin updates. But the customer’s browser is also running JavaScript from analytics platforms, advertising systems, chats, widgets and other services. If one layer in that chain starts delivering something the site owner never authorised, the server itself may still look completely normal.

The most interesting case: a store with an active back door in the browser

The third operation used code that had previously been associated with search redirects. On the store, the older modules remained largely dormant, but one active branch sent telemetry and could fetch remote JavaScript.

In practice, that meant the attackers could change what the operation did without modifying the store’s files again. Cloudflare did not establish which second-stage payloads were actually being served, so there is no basis for turning this into a story about confirmed data theft that the researchers never reported. What was confirmed was the ability to fetch and execute remote code inside customers’ browsers.

The fourth campaign targeted the traffic the store had already paid for

Another script activated only for selected mobile visits carrying particular campaign parameters. It tried to disable analytics and monitoring tools, hid the chat and contact form, and loaded replacement tracking mechanisms at the same time.

In dynamic analysis, Cloudflare confirmed that the replacement analytics script sent a beacon – an invisible request used to record activity. What was not confirmed was whether the attackers actually captured session telemetry or advertising revenue. That distinction matters: malicious capability and proven harm are not the same thing.

WebsiteGarage says

The most useful lesson from this research is inconveniently simple: “the website works” is not a security test. Neither is “the checkout works”.

Many modern websites consist of their own code plus an entire trainload of external scripts for advertising, analytics, chat, A/B testing, affiliate systems and automation. Every additional piece of JavaScript runs on the customer’s side – exactly where it can see a click, change how the page behaves or send data somewhere else.

I would not take this as a reason to “remove every tag”. That is about as practical as saying “disconnect the internet”. The useful conclusion is different: a store should know and control the list of scripts it loads, and monitoring cannot rely entirely on a one-off scan of the files. If malicious code wakes up only at a particular time, on a particular device or for traffic coming from a campaign, a single scan has a very good chance of seeing nothing more than the well-behaved version of the site.