When scanners miss the attack: how Cloudflare Client-Side Security protects storefronts

The opening article in this series followed eight malicious payloads surfaced by Cloudflare's Page Shield ML across four live operations. Public scanners were largely blind to them: seven of the eight never appeared in VirusTotal, and URLScan returned no malicious verdict for any. The same blind spots apply to known families. A specific Lnkr payload sat indexed by URLScan for nearly two and a half years under "No classification," including a direct scan in January 2024 — yet Page Shield ML independently surfaced those exact bytes on a retailer's storefront. VirusTotal had ingested the payload earlier, and now flags it as malicious, but public history does not show when that verdict was first assigned. A hash can be known long before the code behind it is classified, so a defense that waits for the label is already late.

Detection at scale: graph reasoning, then second opinions

The GNN behind these findings had already flagged malicious npm packages and an in-the-wild Magecart payment skimmer. It does not read JavaScript as flat text. It treats the code as a graph — a syntax tree connecting symbols and exposing what calls what, what the attacker buried, and what still phones home. That structure lets it spot suspicious patterns across minification, renaming, and some obfuscation without leaning on a known URL or byte signature.

Scripts the GNN marks malicious amount to under 0.3% of analyzed traffic. Those go to a lightweight LLM on Workers AI for a live second opinion, which cuts false positives while holding recall high. When the LLM corroborates the GNN, customers are alerted.

For the hardest scripts, an ensemble of frontier models — the teachers — each analyze the same suspicious script in a fresh, independent session. The cohort spans roughly six model families, including open-weight models on Workers AI. Agentic tool access lets them run a restricted JavaScript evaluator to unpack small snippets and expose hidden behavior. Cloudflare Sandbox will soon extend this workflow for deeper isolated analysis.

Disagreement among the teachers is treated as signal. Each label becomes a vote weighted by the model's score on the Artificial Analysis Intelligence Index, producing a probability distribution over four labels: benign, payment skimming (magecart), other malware, and cryptomining. Only scripts flagged malicious or lacking a clear two-thirds majority reach human reviewers. Those distributions then feed back into GNN training, sharpening its handling of nuanced cases; the loop is still partly manual but is beginning to be automated.

Operation 1: affiliate-commission hijacking after hours

A shopper on a phone taps a product. Instead of following the tap, the script opens an attacker-preselected product or campaign page in a new tab and routes the original tab through an affiliate link. The storefront still appears to work. If the shopper buys — then or later — attribution shifts to an account that did not earn the referral.

What the retailer pays for it

The shop may pay a commission to an account that brought no shopper. If a legitimate partner made the referral, the forced request can misattribute it, diverting credit and payout from the partner who did the work. The damage can outlast a single commission: partners who lose trust in the attribution system may lose trust in the retailer behind it.

Attack chain

Qualified mobile visitor → intercepted product tap → script-selected page opens in new tab + original tab follows attacker’s affiliate route

Why crawlers saw nothing

Five related builds were found: two active, three paused at capture. Each active variant passes a different set of gates — device and local time, whether the trick ran recently, whether a product button has appeared, whether anyone clicks it. That maze of conditions keeps the behavior invisible to a brief automated visit unless a variant's exact requirements are met. The active scripts use a MutationObserver to watch for product tiles and buttons that appear after the initial load, so they can intercept clicks on late-arriving elements — a crawler that loaded the HTML once and stopped would miss the redirect path entirely.

On a qualifying click, the later active variants write a three-day cooldown to localStorage, staying dormant on that device for days, then run a dual-tab maneuver: an attacker-chosen product page opens in a fresh tab to keep the shopper engaged, while the original tab makes a quick, unnoticed round-trip through the attacker's affiliate tracking link and back to plant the attribution cookie in the background. Console masking and self-defending source checks hinder inspection, while cooldowns and narrow schedules limit how often the malicious path appears during normal shopping.

A sanitized excerpt shows how the payload hooks dynamic product tiles and executes the dual-tab detour. Identifiers were simplified, code reformatted, and destination URLs neutralized for readability.

// Watch for late-rendering product elements and hook clicks
new MutationObserver((_, observer) => {
  const tile = document.querySelector(TARGET_SELECTOR);
  if (!tile) return;
  observer.disconnect();

  tile.addEventListener("click", (e) => {
    // Bail out if cooldown is still active on this device
    const stored = JSON.parse(localStorage.getItem(STORAGE_KEY) || "null");
    if (stored && stored.expires > Date.now()) return;

    e.preventDefault();
    e.stopPropagation();
    localStorage.setItem(
      STORAGE_KEY,
      JSON.stringify({ value: "tracked", expires: Date.now() + COOLDOWN_MS }),
    );

    // Keep shopper engaged in new tab...
    window.open(target.link, "_blank");

    // ... while routing original tab through the attacker's affiliate link
    setTimeout(() => {
      window.location.href = target.redirectUrl;
    }, 200);
  }); // Note: some variants added { once: true } to detach after the first tap
}).observe(document.body, { childList: true, subtree: true });

The paused builds show how the campaign could go dark without removing the script. Their embedded configuration set status: "paused", so they exited before installing click handlers. These scripts carried different per-shopper cooldown configurations — 3, 4, and 5 days — and one recorded a version-history comment explicitly noting the campaign was paused after Black Friday.

Delivery ran through the marketing supply chain: the third-party scripts and tag managers e-commerce sites embed for ad tracking and analytics. One confirmed path went Google Tag Manager → another tag manager → malicious script. That is how the payload reached the browser, not evidence that either tag manager was compromised.

The hosting domain was disguised to pass a quick marketing review. adtargett[.]com differed by a single "t" from adtarget[.]com, an advertising domain registered in 1998. The lookalike was registered in 2025, and its homepage identified itself as "Adtarget.com - Performance Marketing Agency." Mimicking a real ad agency let the host blend in with routine marketing tags while it served the payload that hijacked shopper clicks and redirected them through affiliate payout links.

The invisible affiliate click

Some scripts do not even wait for a click. A shopper can open a booking page, browse the product options and never touch an ad, while the script quietly issues an affiliate request that may later make a genuine sale look as though it came from someone else's referral. When its conditions line up, the payload fires that request through a hidden iframe or a link that clicks itself.

The victim here is the economics of customer acquisition: a legitimate booking or purchase could be credited to an unearned affiliate account. The code demonstrates covert, automated affiliate requests, but whether any particular request produced completed attribution, account crediting or paid commission was not observed.

Time-gated browser → covert affiliate request (off-screen iframe) → 1-hour throttle cookie → when blocked, automated hidden-link click fallback

Selective execution, stealth delivery

The affiliate request is concealed in two layers: a pre-flight network gate and hourly schedule decide whether to run at all, and an off-screen iframe delivers the request invisibly. Notably, the country labels involved have nothing to do with geography — neither the shopper's location nor the shop's drives the choice.

The script does call a public IP-based geolocation service, but ignores everything it returns, the shopper's country included. Why it required a successful response while discarding the data is unclear; it could have been an attempt to confuse investigators or simply a leftover from an earlier version. If that geolocation request fails, the script stops silently — its promise chain ends with .catch(() => {}). The intent is unproven, but fail-closed behavior of this kind could help it evade network-restricted sandboxes.

The payload's real configuration is three embedded TradeDoubler affiliate-marketing network objects labelled AU, US and UK, each holding an affiliate URL plus start and end times. The script computes Asia/Kolkata time in JavaScript, checks the configured windows, then uses fixed odd/even-hour rules to pick one of the three — or skip the request for that run entirely. The selection is deterministic, and schedule plus browser-state checks add up to time-gated selective execution, a form of cloaking. When the conditions don't align, the behavior stays dormant and a one-off inspection can miss it.

Having chosen a configuration, the script writes a local cookie named affiliateClicked_<market> as a one-hour retry throttle so it won't re-fire for that region. This is a client-side noise limiter, not an affiliate-network attribution cookie. It then loads the affiliate URL into an off-screen iframe with the referrer suppressed. The iframe is the primary path, backed by an aggressive fallback: if it errors or fails to finish loading after one to two seconds, the script builds a hidden <a> with no target attribute and clicks it programmatically, which could navigate the user's active tab. The qualifying shopper sees nothing unusual — no ad, no click, and they can close the tab as if nothing happened.

The obfuscation is simple but effective: even property names are assembled one character at a time. The sanitized excerpt below shows the payload building its invisible off-screen iframe. Key identifiers were renamed and the code reformatted for readability; the destination has been removed.

function loadAttribution(target) {
  const frame = document['c'+'r'+'e'+'a'+'t'+'e'+'E'+'l'+'e'+'m'+'e'+'n'+'t'](
    'i'+'f'+'r'+'a'+'m'+'e'
  );
  frame['s'+'r'+'c'] = target;
  frame['r'+'e'+'f'+'e'+'r'+'r'+'e'+'r'+'P'+'o'+'l'+'i'+'c'+'y'] =
    'n'+'o'+'-'+'r'+'e'+'f'+'e'+'r'+'r'+'e'+'r';
  frame['s'+'t'+'y'+'l'+'e']['c'+'s'+'s'+'T'+'e'+'x'+'t'] =
    'w'+'i'+'d'+'t'+'h'+':'+'1'+'p'+'x'+';'+'h'+'e'+'i'+'g'+'h'+'t'+':'+'1'+'p'+'x'+';'+
    'p'+'o'+'s'+'i'+'t'+'i'+'o'+'n'+':'+'a'+'b'+'s'+'o'+'l'+'u'+'t'+'e'+';'+
    'l'+'e'+'f'+'t'+':'+'-'+'9'+'9'+'9'+'9'+'p'+'x'+';'+
    'v'+'i'+'s'+'i'+'b'+'i'+'l'+'i'+'t'+'y'+':'+'h'+'i'+'d'+'d'+'e'+'n';
  document['b'+'o'+'d'+'y']['a'+'p'+'p'+'e'+'n'+'d'+'C'+'h'+'i'+'l'+'d'](frame);
}

An old malware family as a storefront backdoor

Years ago the Lnkr family became known for hiding in shady browser extensions, intercepting Google and Bing searches to redirect results and collect ad money. Its codebase has now been repurposed to plant a backdoor in an online retailer's website.

Running on a shop rather than a search engine, the script's redirect tricks stayed dormant. Instead it sent telemetry back to the attacker and, more dangerously, provided a remote doorway to download and run fresh JavaScript in customers' browsers at will, without touching a single server-side file. It also carried an old extension-era habit: it switches itself off when someone types words like "virus" or "popup" into Google. From the outside the store kept selling with no visible sign of trouble.

What the shop lost was control over what code executes in its customers' browsers. Visitors' sessions were secretly tracked, and attackers could push and run arbitrary JavaScript on the storefront at any time.

HTML-referenced script → analyst evasion gates → parallel host-gated branches (dormant search vs. live backdoor) → arbitrary remote JavaScript execution

Dormant modules, live branches

Unlike the tag-manager campaigns, this script was embedded directly in the merchant's HTML. The exact initial intrusion vector could not be determined; direct HTML insertions typically come through compromised store admin credentials, an unauthorized template edit, or an infected third-party theme or plugin.

Structurally the script is a modular toolkit holding active and dormant code side by side. Its older modules — transparent click overlays, search-engine query interceptors, extension-store link rewriters and redirects for typosquatted domains such as buking[.]com for booking[.]com — only activate on specific target sites, so they remained off on this storefront. Those disabled modules contain several embedded domains (sugabit[.]net, votetoda[.]com, cdnpps[.]us) and the telemetry endpoint hanstrackr[.]com.

The branches that were live on the shop addressed evasion, telemetry and remote control:

• Playing dead for security researchers. Inherited from its browser-extension days, the script monitored search inputs and URL queries for telltale adware terms. A single security keyword paused it for that visit; two or more wrote a persistent opt-out record to localStorage, silencing the script permanently on that analyst's machine so repeated tests would find nothing. Originally built to dodge analysts on search engines, the check appeared hard-coded to Google search URLs and stayed dormant on the storefront.
• Dynamic remote code execution. The script did not need to modify the storefront to change its behavior. The hardcoded domains (scrprime[.]com, youronlinesearches[.]com, jullyambery[.]net) matched those in older captures, but what those endpoints returned was entirely up to the attacker. The script could report visitor telemetry, request new instructions and pull fresh JavaScript into the shopper's browser — a live backdoor for arbitrary code on the storefront. What second-stage payloads were actually served could not be determined.

A static snapshot of the site therefore showed only the normal storefront, while the state checks, anti-analysis traps and remote-loading branches underneath revealed the backdoor.

A cloaker tuned for paid mobile traffic

This operation only ever targeted visits the merchant had already bought. The script waited for a campaign-tagged mobile arrival, let it through, then severed the store's own visibility into that session: analytics stopped reporting, the support chat disappeared, and a rogue analytics identity began recording telemetry on traffic the shop had paid for.

Activation depended on a stacked set of conditions — the exact storefront host, a narrow mobile viewport, and a campaign tag within the first two pages of the visit. Laptops, corporate networks, cloud providers and VPNs all stayed dormant, so the engineers most likely to inspect the page never saw it fire. Selected US cities and regions were excluded as well, backed by a denylist of 325 IP strings aimed at automated scanners and analysts. Only once every gate passed did the payload dismantle monitoring, swap in replacement advertising and analytics identities, and call home.

What the storefront lost

The malware singled out high-value traffic acquired through paid-search and marketing campaigns (ppc, cpc, sms, paid). Those shoppers could still complete purchases, but the merchant faced three distinct exposures: diverted advertising attribution and unearned publisher payouts, the loss of session analytics across nine observability tools, and the suppression of the help chat and contact form, which cut shoppers off from asking questions or reporting anomalies. Dynamic analysis in a sandboxed browser confirmed that the replacement analytics script loaded and fired a tracking beacon. Whether the attacker actually captured session telemetry or diverted ad revenue in practice remains unproven.

Campaign-tagged mobile arrival → multi-tier cloaking & network gates → monitoring sabotaged → advertising, analytics, and support controls rewritten

Disguise and delivery

To blend into the store's marketing supply chain, the payload was served from sdk-amazonaws[.]com, a lookalike domain registered in 2024 and wholly unaffiliated with the official AWS domain (amazonaws.com, registered in 2005). The attacker prefixed it with a subdomain mimicking a popular e-commerce marketing platform, producing a stacked, double-trusted-brand typosquat built to survive a quick tag review. Neither Amazon Web Services nor the impersonated platform took part in the attack or suffered a compromise.

Inside the activation gauntlet

Once loaded, the script had to clear an unusually dense series of cloaking gates before its main payload would run.

• Host and browsing context. It confirmed window.location.hostname matched the specific merchant host and exited immediately anywhere else, checked that the window was top-level rather than an embedded iframe, and verified the path contained no /challenge. It also required that the marker cookies _cart_dr and _logo_alt were not already set.
• Device and campaign filtering. Viewport width had to be under 477 pixels. The visit had to arrive by first-touch campaign tagged with one of six UTM mediums — Urchin Tracking Module parameters being the standard URL tags used to track marketing campaigns — namely ppc, cpc, sms, paid, flow, or campaign, and it had to be the first or second page load of the session. A nominal non-UTM path existed but demanded a session page count simultaneously greater than -1 and less than -2, a mathematical impossibility that left the branch unreachable — possibly a diversion or a leftover from an earlier code change.
• The throttle that always fired. A probabilistic-looking check, Math.random() <= threshold, was meant to make execution seem intermittent. Solving the deobfuscated arithmetic reduces the threshold to exactly 1, and because JavaScript's Math.random() always returns strictly below 1, the gate always evaluates to true. Like the unreachable non-campaign branch, it never decides anything — a leftover throttle or deliberate camouflage for anyone reading the obfuscated math. No qualifying visitor was ever skipped by it.
• Third-party IP intelligence. The script queried an external IP intelligence API with an embedded key, requiring a US mobile consumer connection and bailing out on business networks, hosting facilities, cloud providers, bogons, Tor exit nodes, VPNs, proxies, relays and general threat indicators.
• Geographic exclusions. Visitors from US-NY, US-CA, and US-NHDD, or from San Francisco, Plymouth, Compton, Hopkinton, and Lafayette, saw nothing activate.
• The 325-entry IP trap. The visitor's IP was matched against an embedded denylist of 325 full IPv4 strings — 313 unique addresses across 249 distinct three-octet prefixes after deduplication. Instead of CIDR subnet matching, the author stripped the final octet and ran a raw substring search: !denylistString.includes(visitorPrefix).

Stripped-down pseudocode for the primary activation funnel:

// 1. Context, device, and campaign gates
let eligible = isTopWindow && host === EXPECTED_HOST && !path.includes("/challenge");
eligible &&= !hasCookie("_cart_dr") && !hasCookie("_logo_alt");
eligible &&= viewportWidth < 477 && [1, 2].includes(sessionPage);
eligible &&= ["ppc", "cpc", "sms", "paid", "flow", "campaign"].includes(utmMedium);
eligible &&= Math.random() <= 1; // Apparent random gate always resolves to true

// 2. IP intelligence & geographic gates (fetching external API)
eligible &&= ipInfo.country === "US" && ipInfo.isMobile && !ipInfo.isBusiness;
eligible &&= !ipInfo.isCloud && !ipInfo.isProxy && !ipInfo.isVpn && !ipInfo.isTor && !ipInfo.isThreat;
eligible &&= !["US-NY", "US-CA", "US-NHDD"].includes(ipInfo.region);
eligible &&= !EXCLUDED_CITIES.includes(ipInfo.city);

// 3. 325-entry IP prefix check (raw substring matching)
let clientPrefix = ipInfo.ip.slice(0, ipInfo.ip.lastIndexOf("."));
eligible &&= !DENYLIST_STRING.includes(clientPrefix);

if (!eligible) return; // Cloak passes only for qualifying consumer mobile sessions

Sabotage and identity hijacking

Only after every primary gate passed did the payload execute:

• Blinding monitoring. It located and removed script tags for nine observability and analytics services — Lucky Orange, Segment, Optimizely, New Relic, Bugsnag, LogRocket, Hotjar, Microsoft Clarity, and the store's Google Tag Manager container (GTM-<redacted>). In the remaining inline scripts it string-replaced references to those tools with an undefined dummy identifier (hji0) so calls failed silently, aiming to blind error reporting and monitoring.
• Suppressing support. Injected CSS and removed elements hid the support-chat and contact-form containers, cutting the shopper's direct line to store support.
• Replacing ad and analytics identities. It purged Google Ads globals (google_ad_modifications, adsbygoogle), tore down existing ad slots (ca-pub-<original>), and loaded Google Ads under a replacement publisher ID (ca-pub-<replacement>), then injected a new Microsoft Clarity session-replay script configured with a rogue project ID.

Independent beacons and a 600-day marker

In contrast to the elaborate primary cloak, secondary beaconing branches bypassed the viewport, hostname, campaign, geography and IP gates entirely. On the second page or beyond, the script wrote a persistent cookie (_cart_dr=1) expiring after exactly 600 days (51,840,000,000 milliseconds) and fired an invisible zero-pixel image request to a telemetry endpoint on maper[.]info.

A separate branch looked for an alternate marker (_logo_alt) and, if present, fired a second telemetry .png beacon. The script read that cookie but never wrote it, suggesting a companion script planted it. The result was a simple persistent hit-counter logging basic traffic for every visitor across the store — IP and User-Agent recorded at the endpoint — while the high-risk ad-hijacking routines stayed hidden behind the mobile cloak aimed at high-value paid arrivals. It is a clear illustration of why analyzing a single visible effect will not reveal the full reach of a multi-purpose payload.

Indicators of Compromise

These indicators are published so security teams and researchers can detect and hunt the campaign in their own environments. All are drawn directly from captured payloads and their network connections, and listed URLs are defanged. Some have been withheld or generalized because publishing them could inadvertently reveal the identities of affected organizations. The domains listed reflect infrastructure observed in the delivery, redirection, or telemetry chain; inclusion does not imply a shared service or hosting provider is exclusively malicious.

Four lessons for defenders

The operations escalate in objective, delivery path and disguise, but one constraint never changes: the browser still has to execute the attacker's logic.

Behavior beats signatures. Different monetization and manipulation goals, same requirement — observe events, inspect state, alter the page, schedule work, make network requests, or load another stage. Structural analysis targets that unavoidable logic, even as URLs, signatures and objectives shift.

Selective execution is part of the attack, not a footnote. Device, time, geography, referrer, session, network and cooldown gates can all defeat a crawler that visits once and takes a static snapshot. Continuous visibility matters because an attack may appear to one browser, in one state, at one moment.

Obfuscation raised the cost of analysis but did not prevent detection here. Self-defending loops, console suppression, debugger traps, rotated string tables and dead branches all complicated the work, yet Page Shield ML still surfaced all four operations. Fast in-house models flag suspicious code at scale while frontier models take the hardest cases; their disagreements point at the trickiest obfuscation and logic and help narrow the focus.

Context completes the picture. Code that looks ordinary alone reveals its role once static analysis is linked to dynamic context: how it arrived, which browser state activated it, what connections it opened, and what it did at runtime.

Continuous visibility into client-side execution

All four operations leaned on different misdirection, but each depended on JavaScript executing in the browser — and public scanners and static crawls can miss gated behavior. Continuous observation clarifies what code actually does when real visitors interact with the page.

Cloudflare Client-Side Security supplies that visibility on all plans. Continuous script monitoring can be enabled under Security settings to track first- and third-party scripts on a storefront, while automated malicious-script detection and alerting require Client-Side Security Advanced. Script activity can be reviewed and detections managed in the Cloudflare dashboard.