How Adware Manipulates Attribution to Monetize a Merchant’s Own Traffic
When adware programs and their partners want to drain advertisers’ budgets, they have an oddly well-established path to do so: Wait for the user to browse an advertiser’s site, then invoke an advertiser’s own affiliate link. Users will typically not notice anything amiss; at most they get a second window showing the advertiser’s web site, but that is easily ignored as a small glitch. Meanwhile, the advertiser will see genuine purchases and quite logically assume the affiliate must have added value – must have done something to get the user to buy. So the advertiser will pay a commission according to its standard fee schedule. These commissions can be sizable – often, 10% or more of the user’s purchase price. Meanwhile all the affiliate had to do was get adware (or a browser plugin) onto a user’s computer, or buy clicks from some other adware already installed.
VPT automation catches this problem targeting merchants large and small. When I think affiliate, I often jump straight to Amazon – the advertiser that took affiliate marketing mainstream when countless publisher sites began promoting Amazon for books, later music, and now almost anything. So I searched VPT records for adware targeting Amazon. A representative example is VPT Incident #16880. Quoting verbatim from the automated report summarizing what our automation did and what it found:
We tested on a computer with the adware 3D Earth Maps. When the user navigated to https://www.amazon.com/, the adware invoked an affiliate link with parameters as shown below.
…
tag=namespacebran37-20
The report provides two screenshots of what was observed.
- First our automation loaded Amazon.com, just as a user would. This is shown in the left screenshot below.
- 83 seconds later, the adware opened a second tab that loaded an affiliate link for Amazon. This second request sets the affiliate’s cookie, positioning the affiliate to claim commissions on subsequent sales. See the right screenshot below, showing both tabs visible.
Our automation also made a video showing exactly what occurred. But if there’s any doubt, the packet log shows all communications between the browser, the adware, and Amazon’s site. (We even decode HTTPS encryption.) Sure enough the adware told its controlling server, v2i8b.com (yellow highlighting below), that the user was at amazon.com (blue), to which the server instructed opening the new tab loading Amazon with the specified affiliate ID (green). Here’s the relevant HTTP transaction from the packet log:
GET https://r.v2i8b.com/api/v1/bid/redirect?campaign_id=...&url=https%3A%2F%2Fwww.amazon.com&source=...&cid=...&ec=...&ecr=...&t=24570&vc=... HTTP/1.1
Host: r.v2i8b.com
Connection: keep-alive
sec-ch-ua: "Not)A;Brand";v="8", "Chromium";v="138", "Google Chrome";v="138"
sec-ch-ua-mobile: ?0
sec-ch-ua-platform: "Windows"
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/138.0.0.0 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7
Sec-Fetch-Site: none
Sec-Fetch-Mode: navigate
Sec-Fetch-Dest: document
Accept-Encoding: gzip, deflate, br, zstd
Accept-Language: en-US,en;q=0.9
HTTP/1.1 302 Found
Date: Wed, 16 Jul 2025 19:18:23 GMT
Content-Type: text/html; charset=utf-8
Content-Length: 203
Connection: keep-alive
cache-control: no-store, no-cache, must-revalidate, proxy-revalidate
expires: 0
location: https://www.amazon.com?asc_campaign=f34153f85476486748b59b061a7daf98&asc_source=01GEF8XYFYR5K9W7K9EJD4XTW2&tag=namespacebran37-20
pragma: no-cache
referrer-policy: no-referrer
server: Cowboy
surrogate-control: no-store
vary: accept-encoding
x-request-id: 01K0AARX0E20SA8N6YYRWZSTJS
<html><body>You are being <a href="https://www.amazon.com?asc_campaign=f34153f85476486748b59b061a7daf98&asc_source=01GEF8XYFYR5K9W7K9EJD4XTW2&tag=namespacebran37-20">redirected</a>.</body></html>Nothing in the packet log can tell us how much Amazon paid this affiliate. We think highly of Amazon’s sophistication, so we expect that Amazon catches many such affiliates before they paid any of the wrongfully-claimed commissions. Furthermore, Amazon’s Associates program policies are well-written and appropriately prohibit this type of abuse. But in just six days of testing, we saw this affiliate’s links appear 37 times. The affiliate probably had to pay the adware for each (fake) click, suggesting that the affiliate expects to get paid.
I began preparing reports like this in 2004. Before long, I built automation to catch the problems, but VPT’s advanced system examines incidents, writes reports, and presents findings in a dashboard. (Screenshot below.) I wish I had built these features decades ago.
In future posts, I’ll explore the quantity of incidents we’re observing and the adware apps most often involved.
