Malicious JavaScript Evaded VirusTotal in Seven of Eight E

Cloudflare's client-side security research team disclosed yesterday that four active malicious JavaScript campaigns targeting online storefronts have been operating in the open, with seven of eight payloads carrying no VirusTotal detection and none drawing a malicious verdict from URLScan — a finding that exposes a structural gap in signature-based threat intelligence tools whenever attackers use condition-gating to keep their code dormant until the right victim arrives. The shift behind Operations 1 and 2 in this disclosure is especially significant: affiliate commission fraud — long associated with infected browser extensions running on shoppers' devices — has migrated into merchant infrastructure, arriving through the same tag management pipelines that merchants use to deploy analytics and advertising. The defensive responsibility has moved from consumer to merchant.

VirusTotal's Structural Blind Spot: What Condition-Gating Does to Signature Scanners

The scanner-gap finding is not a performance failure by VirusTotal or URLScan — it is a consequence of a fundamental architectural mismatch. Both tools operate by submitting samples or crawling URLs at a single moment and checking them against known signatures. Condition-gated malicious JavaScript is designed to do nothing during that moment: it checks the visitor's device type, local time, geographic location, referrer tag, session page count, viewport width, and network type, and executes its payload only when all conditions align. A crawler visiting once, from a cloud IP, during business hours, with no UTM parameters, will see a script that appears inert.

In one illustrative case from this disclosure, a specific version of the Lnkr-derived payload had been indexed by URLScan for nearly two and a half years — including during a direct scan in January 2024 — and received no classification. VirusTotal had ingested the payload earlier, and its public record currently shows a malicious flag, but the timeline of when that verdict was first assigned is not visible in the public history. In both cases, Cloudflare's ML pipeline had already independently surfaced the same bytes operating live on a merchant's storefront.

This is why Cloudflare's research team frames their finding not as evidence that VirusTotal is inadequate but as evidence that a one-time scan is the wrong tool for this threat class. A hash can be known long before the code behind it is classified as malicious. If a defense waits for that label, it is already late.

How Cloudflare's Detection System Works: Graph Neural Networks on Code Structure

Cloudflare's Client-Side Security product processes 3.5 billion scripts daily , using a three-layer detection pipeline that begins with a graph neural network (GNN) and does not rely on signatures at any stage.

The GNN does not analyze JavaScript as a flat sequence of characters. Instead, it first parses code into a syntax tree — a tree structure in which every element of the program (function calls, variable assignments, DOM interactions, network requests) is represented as a node, and the relationships between them are represented as edges. The GNN then performs message-passing across that tree : each node aggregates information from its neighbors, building up a structural embedding that captures what the code actually does — what calls what, what it hides, what it phones — regardless of how the surface syntax has been obfuscated, minified, or renamed.

This structural approach is what allows the GNN to recognize suspicious intent across the character-concatenation obfuscation in Operation 2 (assembling property names one character at a time, turning createElement into 'c'+'r'+'e'+'a'+'t'+'e'+'E'+'l'+'e'+'m'+'e'+'n'+'t' ), the rotated string tables in Operation 3, and the deliberately unreachable code branches scattered through Operation 4. The syntactic surface changes; the behavioral structure does not.

Scripts that the GNN flags — fewer than 0.3% of all analyzed traffic — are passed to a large language model for triage for a second opinion. When the LLM corroborates the GNN, customers are alerted. For the most complex cases, Cloudflare deploys an ensemble of frontier models — "teachers," drawn from around six model families including open-weight models on Workers AI — each analyzing the same script in its own independent session, with each verdict weighted by the model's score on the Artificial Analysis Intelligence Index. Disagreement within the ensemble is treated as a signal that the obfuscation warrants closer examination.

The system caught all four operations in live traffic. Human analysts verified the findings only after the automated pipeline had already flagged them.

Operation 1: How Affiliate Commissions Get Stolen Without Touching Payment Data

The first campaign targeted mobile shoppers specifically and required a real click to trigger. When a qualified visitor tapped a product tile, the script executed a dual-tab maneuver: it opened an attacker-chosen product page in a new tab to keep the shopper engaged, while simultaneously routing the original tab through the attacker's affiliate tracking link — planting the attacker's attribution cookie in the background. If the shopper completed a purchase, the commission would flow to an account that had done nothing to earn the referral.

The script used a MutationObserver API to monitor product tiles that load dynamically after the initial page render — catching elements that a one-time HTML crawl would never see. A three-day cooldown written to localStorage kept the device dormant after each successful interception, limiting exposure on a per-device basis. Paused variants carried embedded configuration with status: "paused" , allowing the campaign to go dark without removing the payload; one paused build included a version-history confirming it had been paused after Black Friday.

Delivery ran through the merchant's own tag management infrastructure. One confirmed path: Google Tag Manager → a second tag manager → malicious script. The payload arrived from adtargett[.]com , registered in 2025 and presenting its homepage as a "Performance Marketing Agency" — a single-letter typosquat of adtarget[.]com , a legitimate advertising domain registered in 1998.

This is the structural shift Cloudflare's disclosure documents: affiliate fraud has moved off the consumer's device (browser extensions, adware) and into the merchant's delivery infrastructure. A shopper who audits their Chrome extensions will not find this campaign. A merchant who audits their tag manager — carefully — might.

Operation 2: Clickless Affiliate Theft Through a Hidden iframe

The second campaign required no user interaction at all. When the script's conditions aligned — a time window computed in the Asia/Kolkata timezone, an affiliate-network configuration chosen by odd/even hour rules, and a successful call to a public IP geolocation service — the payload silently loaded an affiliate tracking URL inside a hidden, off-screen iframe with the referrer suppressed.

The geolocation call revealed a deliberate evasion design: the script fetched the visitor's country data from a public IP service, then ignored everything it returned. If the geolocation request failed — as it might in a network-restricted sandbox — the script terminated silently, a fail-closed behavior that helps it evade automated analysis environments. If the iframe errored or failed to load within one to two seconds, the script created a hidden anchor element and clicked it programmatically, which could navigate the user's active tab to the affiliate URL. To a qualifying shopper, nothing appeared out of place.

The campaign used TradeDoubler — a legitimate affiliate marketing network — and configured three geographic markets (Australia, US, UK) with time-gated activation windows. Neither TradeDoubler nor the affiliate network itself was involved in or responsible for the fraud.

Operation 3: A Decade-Old Ad Injector Returns as a Storefront Backdoor

Lnkr is a malware family first documented by Netskope in 2019 as an ad-injection framework hidden inside Chrome browser extensions. It hid inside shady extensions, intercepted Google and Bing searches, and redirected results to pocket advertising revenue. Cloudflare's research documents that its codebase has now been repurposed as a storefront backdoor — likely through compromised admin credentials, an unauthorized template edit, or an infected third-party plugin.

The old -redirect modules remained dormant on the storefront: they only activate on target engines, and a merchant's site is not one. The active branches served two purposes: evasion and remote control. On the evasion side, the script inherited Lnkr's browser-extension-era self-defense: it monitored inputs for adware-related terms, and typing two or more security keywords wrote a persistent opt-out record to localStorage , permanently silencing the script on that analyst's machine so repeated tests would find nothing.

More dangerously, the script could phone visitor telemetry to hardcoded domains, request new instructions, and pull down fresh JavaScript directly into shoppers' browsers — giving attackers a live backdoor to execute arbitrary code on the storefront at any time, without modifying a single server-side file. Cloudflare noted it could not determine what second-stage payloads were served to real shoppers during the campaign's operation.

Operation 4: How Attackers Blind a Store to Its Own Paid Traffic

The fourth campaign was designed specifically to target visitors the merchant had already spent money to acquire. It activated only for shoppers arriving via paid or marketing campaigns — UTM medium tags including ppc , cpc , sms , and paid — on a viewport narrower than 477 pixels (a handheld smartphone), within their first two page loads. The script checked visitor connections against IP intelligence, immediately aborting for business networks, cloud providers, VPNs, Tor exit nodes, and proxies. It also excluded visitors from specific US regions (New York, California, and a coded third region) and five named cities — San Francisco, Plymouth, Compton, Hopkinton, and Lafayette — and maintained a handcrafted denylist of 325 raw IPv4 strings covering 249 distinct /24 address prefixes, matching them by simple substring against the visitor's IP. The engineer most likely to debug a suspicious script would never see it fire.

For qualifying visitors, the payload executed an analytics sabotage chain: it searched the DOM and removed script tags for nine observability and analytics tools — Lucky Orange, Segment, Optimizely, New Relic, Bugsnag, LogRocket, Hotjar, Microsoft Clarity, and the merchant's Google Tag Manager container — string-replacing references to those tools with dummy identifiers so calls to them failed silently. It then injected CSS to hide customer support chat and form elements, cutting off shoppers' access to merchant support. Finally, it replaced Google Ads publisher identities and injected a Microsoft Clarity session-replay script configured with a rogue project ID.

The payload arrived from sdk-amazonaws[.]com — a domain registered in 2024, wholly unaffiliated with Amazon Web Services — prefixed with a subdomain mimicking a popular e-commerce marketing platform. Amazon Web Services and the impersonated marketing platform were not involved in or compromised by this campaign.

How Do These Attacks Reach Merchant Storefronts?

These four campaigns illustrate three distinct delivery routes that collectively cover a large of e-commerce infrastructure. Operations 1 and 4 arrived through legitimate tag management infrastructure, exploiting the trust that merchants place in tag managers to inject advertising and analytics tools without code review. Operation 3 was embedded directly in the merchant's HTML — the most likely vector being compromised admin credentials, an unauthorized template edit, or an infected third-party theme or plugin. Operation 2 was delivered through the page's own script loading, with condition-gating preventing static detection.

The shared constraint is that all four had to execute in a real shopper's browser to accomplish their objectives. Continuous browser-side monitoring catches this; a one-time scan cannot. The campaigns shared no common delivery mechanism, no common obfuscation technique, and no common objective — but the GNN's structural analysis caught all eight payloads because their logic, however disguised, had to act on real browser state.

Indicators of Compromise

Cloudflare published a table of indicators covering all four operations.

For Operation 1 (Affiliate Hijacker): adtargett[.]com (script delivery and affiliate redirect); gdataroute[.]com (affiliate redirect service).

For Operation 3 (Storefront Backdoor): scrprime[.]com , youronlinesearches[.]com , jullyambery[.]net , hublosk[.]com , hanstrackr[.]com , sugabit[.]net , votetoda[.]com , cdnpps[.]us , adrs[.]me , youradexchange[.]com , searchvalidation[.]com .

For Operation 4 (Paid-Mobile Cloaker): sdk-amazonaws[.]com (script delivery lookalike); maper[.]info (visitor telemetry beacon).

No indicators were published for Operation 2; Cloudflare withheld them to protect victims to avoid disclosing the identities of affected organizations.

What Can Merchants Do?

Cloudflare's research distills four practical conclusions for defenders.

Behavior beats signatures. Every payload had to act in the browser — observe events, inspect state, alter the page, make network requests, or fetch a stage. Structural analysis looks for that logic even as URLs, signatures, and attacker objectives change across campaigns.

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

Obfuscation raised the cost of analysis but did not prevent detection. Self-defending loops, console suppression, debugger traps, rotated string tables, and dead code branches complicated investigation across all four campaigns. The ML pipeline surfaced all eight payloads regardless.

Context completes the picture. Code that looks unremarkable in isolation reveals its intent once static analysis is combined with dynamic context: how it arrived, which browser state activated it, what connections it opened, and what it did at runtime.

Cloudflare's Client-Side Security, including continuous script monitoring for first- and third-party scripts, is available across all Cloudflare plans. Automated malicious-script detection and alerting require the Client-Side Security Advanced tier. The full technical write-up, including payload excerpts and the complete indicator of compromise table, is available on the Cloudflare Blog's four-campaign disclosure .

Frequently Asked Questions

How did seven of eight malicious JavaScript payloads evade VirusTotal?

All four campaigns used condition-gating: their payloads remained dormant unless the visitor's device, local time, geographic location, referrer tag, session count, viewport size, and network type all matched a specific set of requirements simultaneously. VirusTotal and URLScan operate by submitting a sample or crawling a URL at a single point in time — a method that will never satisfy the conditions that trigger the malicious behavior. Cloudflare's system observes scripts executing in real shoppers' browsers continuously, which is the only method that can see what the code actually does when live conditions are met.

What is the difference between Magecart attacks and the campaigns Cloudflare documented here?

Classic Magecart attacks steal payment card data — they intercept what shoppers type into checkout forms and exfiltrate it to attacker-controlled servers. None of the four campaigns in this disclosure stole card numbers. Instead, they pursued affiliate commission fraud (Operations 1 and 2), arbitrary remote code execution in shoppers' browsers (Operation 3), and analytics sabotage combined with advertising identity replacement (Operation 4). These represent a broader and less-monitored category of client-side attack: the store appears to function normally, customers can still buy, and no card data is stolen — which is part of why these campaigns have operated without being noticed.

How does a graph neural network detect malicious JavaScript without relying on known signatures?

A graph neural network applied to JavaScript code first parses the script into an Abstract Syntax Tree — a structured representation of the code's logical relationships rather than its raw text. The GNN then performs message-passing across that tree, aggregating information from neighboring nodes to build a structural embedding of what the code does: what it calls, what it hides, what it phones , and how its logic flows. Because this embedding is derived from code structure rather than byte sequences, it generalizes across minification, variable renaming, and most obfuscation techniques — the structural fingerprint of hostile behavior remains even when the surface appearance changes entirely.

Can merchants protect themselves if they are not Cloudflare customers?

The technical mitigations available outside Cloudflare's ecosystem are meaningful but require ongoing effort. Content Security Policy (CSP) headers can restrict which domains may load scripts in shoppers' browsers, limiting new payload delivery — but maintaining an accurate allowlist across thousands of frequently updated third-party scripts is operationally demanding. Subresource Integrity (SRI) checks can block scripts whose content has changed since deployment, but only for scripts served from known URLs. Neither approach provides continuous behavioral monitoring of scripts that are already on your allowlist. Security teams can also run periodic audits of tag manager configurations and monitor affiliate attribution data for anomalies — unexpected spikes in a single affiliate account's conversions, or conversions attributed to affiliates who generated no traffic — as signals that cookie stuffing or click-injection may be occurring.