Traffic Laundering and Referer Faking

When VPT automation tests adware and browser plugins, we routinely see traffic bounce through multiple servers. Perpetrators have multiple reasons to use this method.

• Sometimes they seek to conceal their identity through subaffiliates, superaffiliates, and subnetworks.  (If merchant A already told affiliate B to stay away, B may become a subaffiliate of C, sending traffic B->C->A and getting paid indirectly.)  
• Some merchant systems genuinely require multiple trackers.
• Most problematic, redirects let perpetrators make traffic appear to originate from one site, when it actually comes from another site or, worse, adware or a browser plugin.

It’s easy to fake simple URL parameters like “source=google” or “subid=paidsearch”.  Merchants know not to believe labels in the querystring, no more than we believe the return-address on postal mail or the FROM field on email. But perpetrators can also fake HTTP Referer headers, which are generated by web browsers and in principle should be outside an affiliate’s control.  

The trick is to bounce traffic briefly through an intermediate server, using a redirect method that rewrites the Referer header.  A 301 or 302 redirect preserves the original Referer header. But a JavaScript redirect — even a single simple line like window.location.href=”…” — causes the browser to overwrite the Referer with the URL of the bounce server. The result: merchants see traffic as coming from the fraudster’s bounce domain rather than its true origin.

Let me be specific.  In VPT incident 7849, on October 14, 2025, we tested with a Chrome adware-style plugin installed. (This adware maker uses many names that no single name adds much insight.  So I’m not listing its name here.)  We requested the home page of electronics retailer newegg.com, but then the adware opened a second tab. This tab contacted its control server (v2i8b.com), which redirected to Discounthero, then to Rakuten Advertising (ID RS843rWg1v0), and finally back to Newegg.  Here’s how it looked on-screen (cropped screenshots from the full-motion video our automation preserved).

If the user made a purchase in either tab, Rakuten and Newegg would credit this purchase to affiliate RS843rWg1v0.  Newegg would have to pay an affiliate commission for traffic that should have been free (a pure type-in).  And if another affiliate had referred the user shortly before–still within the return-days period–that affiliate would lose its commission, which RS843rWg1v0 would capture instead.

From Rakuten’s dashboard, Newegg staff would see nothing obviously wrong.  The transactions are genuine – real users buying real products.  Basket sizes, payment declines, and product returns are average too.  Call the customers, and they’ll confirm.  At first glance, everything appears ordinary.

The traffic reaches Newegg’s server with tracking tags referencing an affiliate called Shoptastic.  See yellow highlighting below:

GET https://www.newegg.com/?utm_medium=affiliate&utm_campaign=afc-ran-com-Shoptastic&utm_source=afc&-Shoptastic&AFFID=4197399&AFFNAME=Shoptastic&ACRID=1&ASUBID=...&ASID=https%3A%2F%2Fwww.shoptastic.io%2Fus%2Fshopnow%2Fnewegg-com-vn... 

Referer: https://www.shoptastic.io/us/shopnow/newegg-com-vn?c=...

Notice that the references to Shoptastic appear in multiple tags in the HTTP Querystring, and also in the Referer header.  And these two sources line up – both reference Shoptastic.  Everything seems to check out.

Shoptastic’s site indicates it provides cashback to customers – not unlike better-known cashback services such as Rakuten, Honey, Capital One, and Topcashback.  Cashback could even explain high transaction volume: Many bloggers and content sites struggle to get volume, but giving users a rebate can reliably drive traffic.

So from everything Rakuten and Newegg see, this traffic looks legitimate.

But in reality, the traffic touched Shoptastic only for two rapid redirects, less than two seconds in total.  Because VPT runs adware and shopping plugins in a test environment, we can see what truly happened, including the deceptive use of Shoptastic.  First, the plugin’s controlling server (v2i8b, in green) sent traffic to Discounthero (blue):

GET https://r.v2i8b.com/api/v1/bid/redirect?campaign_id=...&url=https://www.newegg.com&source=...&cid=...&ec=...&ecr=...&t=.&vc=... HTTP/1.1
...
HTTP/1.1 302 Found
location: https://discounthero.org/us/s/red_u_plain.php?sub=...&d=https%3A%2F%2Fwww.newegg.com&t=direct&pub=...

Next, discounthero ran an internal redirect followed by a redirect to Shoptastic (orange).

GET https://discounthero.org/.../... HTTP/1.1
...
HTTP/1.1 302 Found ...
Location: https://www.shoptastic.io/us/store/newegg-com-vn?userId=10437&subId=...

As of the traffic reaching Shoptastic, the traffic had no Referer header.  But Shoptastic runs an internal redirect – this time a JavaScript window.location.href= redirect (grey), which causes the next Shoptastic to include a Referer (red).

GET https://www.shoptastic.io/us/store/newegg-com-vn?userId=10437&subId=... HTTP/1.1
...
HTTP/1.1 200 ...
<script>window.location.href="/us/shopnow/newegg-com-vn?c=...";</script>

GET https://www.shoptastic.io/us/shopnow/newegg-com-vn?c=...&clientTime=...&trackingCode=...&trackingLink=https%3A%2F%2Fclick.linksynergy.com%2Ffs-bin%2Fclick%3Fu1%3D...%26id%3DRS843rWg1v0%26offerid%3D1749796%26type%3D3%26subid%3D0 HTTP/1.1 ...
Referer: https://www.shoptastic.io/us/store/newegg-com-vn?userId=10437&subId=...
...
HTTP/1.1 200 ...
<script>window.location.href="https://click.linksynergy.com/fs-bin/click?u1=...&id=RS843rWg1v0&offerid=1749796&type=3&subid=0";</script>

Thus, when traffic reaches Rakuten Marketing, at server linksynergy.com, it bears a Referer header still referencing Shoptastic (red).

GET https://click.linksynergy.com/fs-bin/click?u1=...&id=RS843rWg1v0&offerid=1749796&type=3&subid=0 HTTP/1.1 ...
Referer: https://www.shoptastic.io/us/shopnow/newegg-com-vn?c=...

This is classic Referer stuffing.  Rakuten and Newegg can be forgiven for seeing nothing amiss.  Without installing the adware in a lab and observing what it actually does, the scheme is difficult to uncover.

Note the multiple levels of intermediation – the originating adware control server (v2i8b.com), to Discounthero to Shoptastic to Rakuten Advertising, to Newegg.  Suppose if Rakuten and Newegg eject Shoptastic.  Or suppose they are convinced that this is one rogue Shoptastic user (so they close that user’s account and help Shoptastic guard against this form of abuse).  Still, the plugin can send the traffic to some other intermediary.  That makes the problem a game of whack-a-mole.  Detecting and stopping this mess requires looking well beyond Referer headers and the affiliate-management console: you must observe the client-side behavior that creates the chain in the first place.