Skip to content

Malicious redirects and traffic-distribution systems in the malvertising economy

· 21 min read
Copyright: MIT
malware ad-fraud web-security
TDS wordmark over a request-routing diagram splitting a visitor into a clean white page and a hidden payload

When a security researcher fetches a suspicious URL and gets a harmless page, two things might be true. The page might be clean. Or the page might have looked at the request, decided the visitor was a researcher, and served the clean version on purpose. The second case is the more interesting one, and in the malvertising economy it is also the more common one. The decision to show you a payload or a decoy is not made by the malware. It is made earlier, by a piece of routing infrastructure that sits between the ad or the compromised site and the thing that actually infects you.

That piece of infrastructure is a traffic distribution system. A TDS is a router for human attention. It takes an incoming click, scores it against a set of rules, and forwards it to one of several destinations. The legitimate version of this product is an ad-tracking and campaign-optimization tool that an affiliate marketer uses to send German Android users to one landing page and American iPhone users to another. The malicious version is the same software, configured so that “users who look like real victims” go to an exploit kit or a fake update, and “users who look like crawlers, sandboxes, or analysts” go to a blog about gardening. Same engine. Different rule set. That symmetry is the whole problem.

This post walks the chain. It starts with what a TDS actually does and why the commercial ones are so hard to block. It then covers the gating logic, the white-page/black-page split that every cloaking operation reduces to, and the specific signals used to make that split: IP and ASN reputation, geolocation, user-agent and header order, and the client-side fingerprinting that runs in JavaScript before any payload is fetched. It looks at how malicious code gets injected into ad supply chains and compromised CMS sites, then at four real systems that have been studied in detail: Parrot TDS, VexTrio’s DNS-based router, SocGholish, and the ClearFake blockchain variant. It closes on why this infrastructure is durable, and on what the takedown numbers from 2025 and early 2026 actually show.

What a traffic distribution system is

Strip away the malware and a TDS is a boring piece of marketing software. Keitaro, the most-cited commercial example, is a self-hosted tracker built in Estonia for affiliate marketers who buy traffic from ad networks and need to route it. You install it on your own server, point your ad campaigns at it, and it sends each incoming click somewhere based on rules you define. The rules are the product. The point of paying for a tracker like this is to slice incoming traffic finely enough that you can run twenty offers at once and send each visitor to the one most likely to convert.

Keitaro’s own documentation lists more than thirty filter types. A campaign is built from streams (the docs also call them flows), and each stream carries its own filters and its own destination. The filters cover geography down to the city, the visitor’s ISP and mobile operator, connection type, browser and browser version, OS and OS version, device type and model, language from the Accept-Language header, referrer, the X-Requested-With header, custom URL parameters, time of day, click-frequency limits, uniqueness per visitor, IP ranges in CIDR or interval form, and a dedicated bot filter backed by a database of known crawler IPs and user-agent signatures. Filters combine with AND or OR, and each one has an IS and an IS-NOT mode. None of this is exotic. It is the same targeting vocabulary any ad platform exposes.

incoming click GET /?cid=… filter stack geo / ASN / UA bot list / IP JS fingerprint AND / OR white page (decoy) black page (payload) default (catch-all)

one click in, one of several destinations out — the rule set decides which The same routing engine an affiliate marketer uses to optimise conversions, repurposed so that “looks like a victim” and “looks like a researcher” land on different pages.

The reason this matters for security is that the abuse is configuration, not code. There is nothing in a Keitaro instance that flags it as malicious. The bytes on the server are identical whether the operator is a legitimate marketer or a malware crew. That is exactly why blocking the software wholesale generates unacceptable false positives, a point made repeatedly by defenders who have tried. You cannot blocklist Keitaro the way you blocklist a malware family, because half the traffic flowing through it is real advertising. The malicious operators know this and shelter inside the ambiguity.

The white page and the black page

Reduce any cloaking operation to its core and you get two destinations. The affiliate-marketing world even has standard names for them. The white page is the clean, benign site you show to anything you do not trust: ad-network reviewers, search-engine crawlers, sandboxes, researchers. The black page is the real offer, shown only to traffic that passes the filters. In a malware context the black page is the exploit kit, the fake update, or the scam. Keitaro campaign guides written for traffic arbitrage describe the pattern openly: a forced stream sends bots and ad-network moderators to the white page, a regular stream sends targeted traffic to the black page, and a default stream catches anything unclassified and also routes it to white. The conservative default is the tell. When the system is unsure, it shows the safe page, because a false negative (a researcher who sees the payload) is far more costly to the operator than a false positive (a victim who sees the decoy and is never infected).

That cost asymmetry shapes everything downstream. A cloaking gate is tuned to over-refuse. It would rather lose a thousand real victims than expose its payload to one analyst with a packet capture, because the analyst is the one who can get the whole campaign taken down. This is the same logic an anti-bot vendor uses, inverted. Where a CAPTCHA or bot-management product tries to admit humans and block bots, a malicious TDS tries to admit a specific slice of humans and block everything that might report it, crawlers and humans alike. The mechanics overlap heavily with the defensive side, which is why a lot of this reads like the phishing-kit cloaking playbook run in reverse.

Server-side gating: IP, ASN, and the request itself

The first filter runs before a single line of JavaScript executes, on signals the operator gets for free from the HTTP request. The source IP is the richest of these. A malicious gate checks it against geolocation, against ASN reputation, and against lists of known datacenter, VPN, proxy, and hosting ranges. Traffic from a cloud provider’s address space is the single loudest “this is not a victim” signal, because real targets browse from residential and mobile networks, and researchers and automated scanners overwhelmingly do not. Malvertisers selectively decline to drop payloads on visitors behind proxies, VPNs, or datacenter IPs precisely because those ranges are dominated by scanners, sandboxes, and analysts spoofing their geolocation. If you have ever wondered why your cloud-hosted crawler keeps getting clean pages, this is the reason. The gate sorted you out at layer 3.

Geography narrows it further. A campaign targeting German speakers will refuse everyone outside a geofence, which doubles as anti-analysis because much takedown infrastructure and many sandboxes resolve to the wrong country. The request headers add another layer. User-agent strings get matched against both allow-lists (current Chrome on Windows, current Safari on iOS) and deny-lists (anything that smells like curl, python-requests, or a headless token). The Accept-Language header has to agree with the IP’s country. The referrer has to look like it came from where the ad or injected link actually lives. Header order and casing are themselves a fingerprint, because a real browser emits headers in a stable, recognisable sequence and a hand-rolled HTTP client usually does not, a topic worth its own treatment in header order and casing as a fingerprint. The Confiant malvertising attack matrix catalogues these server-side checks alongside the client-side ones: GeoIP, IP targeting by connection type, passive TCP/IP and OS fingerprinting, HTTP and TLS fingerprinting. TLS in particular is hard to fake from a script, because the ClientHello byte order reveals the real library long before the application layer says anything.

where the gate checks you, in order 1. IP / ASN — datacenter, VPN, proxy, hosting reputation 2. GeoIP — country / city must match campaign + lang 3. Request — UA, header order, referrer, TLS/HTTP fp 4. JS fingerprint — webdriver, WebGL, screen, timezone

fail any layer and you get the white page; the payload only loads after layer 4 passes — so the malicious bytes never touch a request the gate distrusts The cheapest, most decisive checks run first. By the time JavaScript executes, most untrusted traffic has already been routed to the decoy.

Client-side gating: fingerprinting before the payload

If the request survives the server-side filters, the gate runs a second pass in the browser. This is where the malvertising chain borrows the entire device-fingerprinting toolkit that anti-bot vendors use, and points it the other way. The script that does this is usually small, Base64-encoded, and loaded before any payload, and its job is to confirm the visitor is a real human on real hardware.

The checks are familiar if you have read anything on sandbox-evasion fingerprinting. The script reads navigator.webdriver, which a normal browser leaves false and an automated one often sets true. It compares window and screen dimensions, because a headless or off-screen browser frequently reports an implausible viewport. It computes the timezone offset between UTC and local time and checks it against the IP’s geography. It probes rendering: a recurring trick reads WEBGL_debug_renderer_info to pull the GPU’s unmasked renderer string, which on a VMware or VirtualBox guest names the virtual adapter and gives the sandbox away. The renderer string is one of the higher-entropy signals available to a script, which is why both WebGL fingerprinting and these malvertising gates lean on it. Some variants also check codec support, querying whether the browser can play a specific MP4 profile, because real consumer devices and stripped-down analysis VMs differ there.

The Confiant matrix lists these client-side techniques as a family: WebGL, user-agent parsing for mobile tokens, hardware concurrency (CPU core count), enumeration of native browser objects, plugin detection, and time-based activation that only fires the payload during certain hours or days. Mouse movement gets watched too. Several injected scripts only proceed after observing a mousemove event, on the theory that a sandbox detonating the page in a headless loop never moves a pointer. The collected signals are bundled into a POST request, scored on the server, and only a passing score returns the malware destination. Everything else gets a dead end or an error, which is exactly the “crafty dead-end” researchers describe when the same URL that infected a victim returns nothing for an analyst.

None of this is novel cryptography or a clever exploit. It is the commodity fingerprinting stack, the same navigator and WebGL and timezone reads that a fraud-scoring vendor collects, run by the attacker to keep the payload away from anyone who might analyse it. The arms race here is identical to the one on the defensive side, with the roles swapped.

Getting into the chain: malicious injection and ad supply

A TDS only matters once it has traffic flowing into it, and there are two main on-ramps. The first is the programmatic advertising supply chain. Publishers do not sell their ad slots to advertisers directly. They sell through a chain of exchanges, supply-side platforms, demand-side platforms, and resellers, and the real-time bidding auction that fills a slot happens in milliseconds with no human reviewing the winning creative. A malvertiser buys inventory like any advertiser, often through a less scrupulous reseller, and ships a creative whose JavaScript redirects qualifying visitors into a TDS. Because the publisher never sees or controls the final creative, the malicious redirect rides legitimate ad infrastructure straight onto a reputable site. Cloaking is what keeps it there: the creative shows benign content to the ad network’s scanners and the malicious redirect only to traffic that passes the gate.

The second on-ramp is mass website compromise, and it is the one that produces the campaigns researchers have mapped in the most detail. The pattern is consistent. Attackers find content-management systems with weak credentials or vulnerable plugins, overwhelmingly WordPress, and inject a small loader into the site’s own JavaScript or database. That loader is the front door to a TDS. When a visitor loads the page, the injected script profiles them and, if they qualify, redirects into the distribution system, which routes them onward to whatever the current campaign is pushing. The compromised site is both the traffic source and the camouflage, because the redirect comes from a domain with real history and reputation. For a sense of where that redirect can lead once it fires, the drive-by download and browser exploit kit eras are the historical reference; the fake-update lure is the modern descendant.

Parrot TDS: the injected two-stage loader

Parrot TDS, documented by Avast in 2022 and traced in depth by Palo Alto’s Unit 42, is the clearest worked example of the compromise-driven model. Avast found it on web servers hosting more than 16,500 sites, ranging from personal blogs to university and local-government domains. Between March 1 and March 29, 2022, Avast reported protecting more than 600,000 unique users from Parrot-infected sites, with the largest counts in Brazil, India, and the United States. The infection vector was the familiar one: poorly secured WordPress and Joomla installs accessed through weak admin credentials.

The injected code splits into two stages, which is the structural signature of the whole class. A landing script runs first and performs environment checks to decide whether the visitor is worth pursuing. If the checks pass, it fetches a payload script over XMLHttpRequest, and that second stage either sets a tracking cookie or injects a new <script> tag pointing at the malicious destination. Unit 42 tracked four landing-script versions from August 2019 through October 2023, watching the obfuscation thicken over time. Early versions were single-line injections. Later ones added random token strings, stored keywords in scrambled arrays to defeat static keyword matching, and pulled in Canvas, decodeURI, and WebAssembly to make the profiling harder to read. The injected files carried consistent markers across versions, with the landing scripts identifiable by the keywords ndsj and ndsw and the payload by ndsx. Parrot’s main campaign was FakeUpdate, the fake-browser-update lure that drops a remote-access trojan, and the same ndsw/ndsx naming shows up across the broader fake-update ecosystem.

VexTrio: routing over DNS

VexTrio is the largest mapped example, and its routing innovation is worth attention because it sidesteps the usual takedown surface. Infoblox, which has tracked the operation since it surfaced publicly, describes a network active since around 2017 that processes enormous transaction volumes and feeds dozens of affiliates. Its domain registration runs on a dictionary-based generation algorithm that has produced tens of thousands of domains, the kind of DGA machinery that makes blocklisting a moving target.

The technically distinctive piece is how some VexTrio infrastructure routes over DNS rather than HTTP. Malicious JavaScript on a compromised site collects two things: the name of the compromised site and the visitor’s public IP address. It encodes them into the subdomain of a query and resolves that query through Google’s Public DNS, against an authoritative server VexTrio controls. The server parses the data out of the subdomain and answers with a Base64-encoded redirect URL packed into the DNS response, which the script decodes and follows. Routing the lookup through Google’s resolver is the clever part. From the victim’s network the traffic looks like an ordinary DNS query to 8.8.8.8, so the TDS channel is far harder to block at the URL or DNS-reputation layer than a direct HTTP call to an attacker domain would be. Infoblox reported the dictionary feeding the DGA expanding over time and the subdomain labels shifting from random letters toward random digits, the ordinary churn of a system staying ahead of detection.

VexTrio’s later reporting also tied the operation to the commercial cloaking-and-tracking stack directly. Infoblox documented VexTrio routing victims through self-hosted Binom and Keitaro trackers, taking demographic data such as age group passed in from push-notification ad networks, and applying rule-based routing to pick a landing page, including straightforward antivirus and tech-support scams. The same operation that pioneered a custom DNS router also runs the off-the-shelf affiliate tooling, which is a good reminder that these crews are not choosing between bespoke and commercial infrastructure. They run both.

SocGholish and ClearFake: the fake-update chain in 2025

The most active branch of this ecosystem in the current window is the fake-update family, and two operations define it. SocGholish, also tracked as FakeUpdates, has run since 2017 as a JavaScript downloader that reaches its operators over HTTP. It seeds compromised sites, frequently fronting the redirect through a Keitaro instance, and the injected loader profiles the visitor before serving the lure. Public analysis of its injected code describes reads of navigator.webdriver to catch automation, checks on screen height and width, and gating on a mousemove event before the script proceeds, with the second stage fetched over XMLHttpRequest (older variants reach for ActiveXObject("MSXML2.XMLHTTP")) and the response handed to eval. The closely related NDSW/NDSX injection variant, named for the ndsw variable that opens its obfuscated block, accounted for tens of thousands of detections in the first half of 2024 and differs from vanilla SocGholish by serving its second stage through a PHP proxy on the compromised host.

ClearFake is the more recent and more inventive operation, and it shows where payload hosting is heading. It first appeared in July 2023 with the standard fake-browser-update page. By May 2024 it had adopted the ClickFix lure, dropping the download in favour of a fake error dialog that instructs the victim to paste a command into the Windows Run box and execute it themselves, which neatly sidesteps the browser’s download protections by making the human the delivery mechanism. The genuinely new piece, documented by Guardio Labs in October 2023 under the name EtherHiding and analysed in depth by Sekoia in early 2025, is where ClearFake keeps its operational data. Instead of an attacker-controlled web server, it reads from smart contracts on the Binance Smart Chain. Sekoia’s analysis of the February 2025 variant describes the injected script instantiating an Ethereum contract object and pulling several method results from it: a campaign open/close flag, an AES-256 key, the URL of a Cloudflare-hosted encrypted HTML lure, and the obfuscated PowerShell command itself. The lure HTML decrypts client-side with AES-GCM. The visitor still gets profiled first, with the script doing OS and browser detection from the user-agent before choosing what to serve.

2017 SocGholish VexTrio 2021 Parrot TDS 2023 ClearFake EtherHiding 2024 ClickFix lure 2025-26 Keitaro takedowns

the lure changed (download, then fake update, then paste-this-command); the gating-and-routing layer underneath stayed the same shape throughout Different crews, different payloads, one architecture: profile the visitor, route the trusted ones to the lure, hide everything from the rest.

Sekoia’s count, using the campaign’s blockchain wallet address as an indicator, found more than 9,300 compromised sites as of February 24, 2025, with the chain delivering the Emmenhtal loader and then Lumma Stealer or Vidar Stealer. Storing the payload logic on a public blockchain is a hosting decision with one specific property the attackers want: it cannot be taken down. A registrar can suspend a domain and a host can pull a server, but no one can delete a transaction from the Binance Smart Chain. The redirect infrastructure becomes as durable as the ledger it lives on.

Why the infrastructure is durable

The honest answer to “why can’t this just be blocked” is that the malicious and legitimate versions of every layer are the same thing. The TDS software is real ad-tech. The fingerprinting is the same commodity stack a fraud vendor sells. The ad inventory is bought through real exchanges. The compromised sites are real sites. The DNS queries go through Google’s real resolver. The payload data sits on a real blockchain. At no point in the chain is there a clean signature that says “malware” without also catching something legitimate, which is the entire design goal. The cloaking gate exists to make sure the only people who ever see the malicious version are the people who cannot report it.

The 2025 and early-2026 takedown work against Keitaro shows both the limits and the one place defenders have real pressure. Infoblox, tracking Keitaro abuse over the October 2025 to January 2026 window, recorded around 226,000 DNS queries across roughly 13,500 domains and attributed more than 8,000 new domain registrations to threat actors in that period, concentrated at five registrars and timed to coincide with Dynadot promotional discounts. A meaningful share of the abuse ran on cracked or nulled copies of the tracker, versions 7 through 11 traded on forums, with named actors including TA2726 and TA576 using stolen or pirated version-11 licenses. The pressure point was the vendor itself. After Infoblox reported more than a hundred instance domains and Keitaro moved to an email abuse-reporting channel in September 2025, the company cancelled more than a dozen accounts tied to the activity. That works against operators paying for real licenses. It does nothing to the ones running cracked builds on their own servers, which is most of them, and that gap is the durable core of the problem. You can deny a malware crew a license. You cannot deny them software that already runs offline and routes traffic exactly as well without one.

The thing worth holding onto is that the redirect is never the interesting artifact. By the time a victim’s browser follows the redirect, every consequential decision has already been made, upstream, by a router scoring the request against a rule set. The payload is downstream of the gate, and the gate is the part that decides whether you, specifically, are allowed to see it. Which means the clean page a researcher gets back is not the absence of an attack. It is the attack, working as designed, declining to show its hand to the one visitor who could end it.

Sources & further reading

Further reading