Category Archives: Malvertising

Search Arbitrage

by
Posted by wesleyb in Arbitrage | Malvertising - (0 Comments)

Interesting article from BrandVerity on Search Arbitrage using parked domains.

The gist of the tactic discussed is as follows:

  • Unscrupulous publisher of an ad network sets himself up as an advertiser and buys low cost search traffic (sometimes from the very same ad Network).
  • The landing page of the ads are configured to route through to the publisher’s own pages, which look like low-quality parked pages. In the context of previous articles on iPensatori, this landing page is a demilitarized zone. The publisher is using the landing page to hinder automated discovery and/or investigations from ad networks or concerned advertisers
  • Upon detecting that the source of the traffic is good (not automated), the parked page presents ads, the highest ranked of which is related to the low cost search traffic that was originally purchased. The trick is that these ads are of higher value (when clicked) than the search ads originally paid for, enter arbitrage.

This is a clever scam that is not easily detected.

Cookie-stuffing Via barnesandnoble.com

by
Posted by wesleyb in Adware | Affiliate Fraud | Cookie-Stuffing | Mad Monday | Malvertising - (0 Comments)

If you are a legitimate Amazon affiliate, you stand absolutely no chance against today’s fraudster (he is probably stealing your commissions!). Having followed this fraudster for almost an entire year, I am of the opinion that he is laughing all the way to the bank when he receives his check from Amazon every month.

Here’s what he is up to:

  • Fraudster registers as a premium Google advertiser
  • Fraudster creates custom display banners that will run on Google’s display network
  • These banners use a tracking pixel that calls home to a remote third party when loaded. The tracking pixel is not affiliated with the tracking system provided by Google, i.e., it is under the fraudster’s control
  • When the time is right, the tracking pixel 302 redirects back to Amazon via an affiliate id (essentially faking a click)
  • This will result in cookies being placed on the machine that signal Amazon to pay the affiliate in the event of a purchase. This is fraud.

So that’s it. The fraudster is using Google’s advertising network to target the user’s of popular publishers.

This attack is very plain, very simple and very effective. We talked about this chap a few times last year:

  • We know that he is cycling through hundreds of affiliate ids.
  • We know that he must be getting away with what he is doing because, at the end of the day people, buying Google ads costs money and no self-respecting fraudster would pay for a service that was not profitable.

Here’s a recent example (1/21/2013 6:42:46 PM PST) of our fraudster using Google to run his ads on barnesandnoble.com (good targets for Amazon cookie-stuffing!). Red arrow leads the way:

Amazon affiliate fraud - cookie-stuffing

Amazon affiliate fraud - cookie-stuffing

Amazon affiliate fraud - cookie-stuffing

The ad that has been highlighted with the red arrow 302 redirects the tracking pixel to Amazon using an affiliate id (keep loading the ad and it will keep rotating through different affiliate ids). Note that this happens without having to click on the ad, i.e., just viewing the ad will result in the fraudster claiming a commission on a purchase in the near future from Amazon. Shock!

Want to know more about this fraudster? I will be presenting this chap (and many bozos monkeys gentlemen like him) at the Digital Crimes Consortium in February, so if you are invited then be sure to come and say hello for all of the juicy details.

Otherwise I rate this fraudster 7/10:

  • 4 points featuring on iPensatori a few times now and still managing to slip one past the Amazon fraud detection team
  • 1 point for basic cookiestuffing (302 redirects from an image request)
  • 1 point for exploiting Google’s advertising network
  • 1 point for geolocation (he routes you through to Amazon UK if you are from a UK IP and Amazon DE if from a DE IP — nice!)

AM Days Presentation

by
Posted by wesleyb in Affiliate Fraud | Cookie-Stuffing | Malvertising | Typosquatting

Earlier this week I attended the AM Days conference in Florida. All in all it was well worth the trip. The slides from my presentation are available here: Mirror, mirror on the wall. With only 40 minutes to present about a year’s worth of research and development, I introduced the basics of affiliate fraud and presented eight types of fraudsters in increasing levels of complexity:

Score out of 10 Merchant Impacted Affiliate Id Methods of concealment and additional aggravating factors
1 Amazon.com authentic09-20 Basic cookie-stuffing, redirects through proxy host, thwarts static analysis
2 Amazon.de knutbarth-21 Investment in own resources: domain reg, SEO et cetera
3 Amazon.co.uk camandgadrevo-21 Manually crafted JavaScript/CSS
4 Amazon.com lofalocare-20 Obfuscated JavaScript works with server-side code, uses several sites, hits multiple merchants, cycles through affiliate ids
5 Alaska Air GAN: 21000000000056921 Scrubbing the traffic, facade prepared for investigators, doesn’t always typosquat, targets multiple variations of alaskaair.com, targets multiple merchants
6 Amazon.com thegadwiz08-20 Adware makes it difficult to reproduce the attack.  Precision targeting.  Multiple vendors collaborate to produce the fraud
7 Amazon.com lyrloo-20Uses Multiple compromised hosts.  Uses “Flash Bandit” SWF-based cookie-stuffing.  Avoids targeting users in demilitarized zones.  Cycles among multiple affiliate IDs.
8 Amazon.com Hundreds Can also send traffic to malware and exploits.  Reproducing the attack can compromise a researcher’s system.  Sites can detect human versus non-human visitors as well as repeat visitors.  Geotargeting.

Naturally, the most interesting fraudster also happened to have the highest score. Ben Edelman and I have briefly discussed this fraudster in a few earlier posts. In a nutshell, the fraudster is using Google ads to cookie-stuff the users of merchants, sometimes from within the very merchants page! This attack scores so high because it exploits a flaw in Google’s services and allows for super precise targeting, no adware required!

If you have seen any of the following ads (note that these represent a small sample of the ads), then you have been touched by this fraudster. If you buy from Amazon, then they have been touched as well, for the ads cheat Amazon out of a commission that they need not pay.

The question I tried to address after presenting exactly how these ads defraud Amazon is whether or not Amazon is detecting this.

Based upon a constant crawl rate, I presented a graph illustrating the number of unique Amazon affiliate ids observed every month and in use exclusively by this fraudster:

My take on what’s going on here is as follows:

  • (A) The fraudster is still figuring things out during this phase. As a result he is burning through affiliate ids
  • (B) Two months of turbulence followed by relative calm. The fraudster has found the right rate at which to burn accounts and remain profitable
  • (C) Improvement in the fraudster’s system or a weakness in Amazon’s detection results in less accounts being burned
  • (D) Amazon steps up their game and their detection improves. The fraudster has to start burning through more affiliate ids in order to remain profitable
  • (E) After three months of research and development, the fraudster picks up his own game and introduces a change that allows him to burn less accounts. This trend continues today

Add to this that these ads cost money. In order for the perpetrator to defraud Amazon in this manner it requires significant investment. If he was not profitable then it’s natural to assume that he would not be paying Google to run these ads.

In some ways, Amazon is detecting this. After all, the fraudster is burning through affiliate ids. Some months he needs more, and other months he needs less. In other ways, Amazon is not detecting this. The best example of this is that I have seen affiliate ids that have persisted for months. Some were first seen as far back as February 2012 and last seen only a few weeks ago, suggesting that the accounts in question are alive and well (and undetected by Amazon).

Ad Injector Workflow

by
Posted by wesleyb in Ad Injectors | Mad Monday | Malvertising

Ad injectors turn a profit primarily by presenting a user with advertisements. Sometimes the advertisements are served on a CPM model (Cost Per Mille or Cost Per Impression), this is where the ad injector organization is paid every time an ad is seen by a user. Other times it’s CPC (Cost Per Click), in this model the ad injector folks are paid every time a user clicks on an ad that was presented to them. Another money making model involves CPA (Cost Per Action, also referred to as Pay Per Action) which is integral to affiliate marketing. .

Ad injectors leverage off of the hard work of other publishers by literally injecting foreign content (advertisements) into their sites. In almost every single case involving an ad injector that I have looked at, the ad injectors do not have the permission of the publisher to modify the site in question. From a number of previous posts, we have seen ad injectors push foreign content into sites like Wikipedia (intended to always be free from ads!), Amazon, Google, Facebook and Bing. Note that a fairly consistent workflow has been adopted by the ad injector community:

  1. Install the ad injector software on a user’s machine
  2. Monitor the sites browsed over time
  3. Inject an ad upon detecting a suitable site

Let’s go through each of these steps in a little more detail using the PlayBryte ad injector as an example.

Install

It appears that PlayBryte gets their software installed on a machine via the PPI (Pay Per Install) model. So PlayBryte sets themselves up as an advertiser who will pay publishers for each unique install that they can get onto a user’s machine. The publisher that they are deploying their software through uses a binary that has been digitally signed by Click Run Software, which is deployed from todownload.com. This organization convinces users to download and execute the binary using online advertising. In this scenario, they are advertisers offering Firefox and Chrome as a download.

Search for “download chrome” or “download firefox” on Google.com:

Clicking on the highlighted ad (URL for Firefox and for Chrome) will take you through to mozilla-firefox.todownload.com and google-chrome.todownload.com (for Firefox and Chrome respectively). The destination URL in both cases is offering downloads of these browsers.

Needless to say, these sites are not the official sources for the free software in question. From my experience, advertisers that use these kinds of tactics are, more often than not, deploying malware.

So Click Run Software/todownload.com is an advertiser on Google.com. A user comes along wanting to download Chrome or Firefox. They mistake the first ad for the first organic link and click through on the ad. They click on “download now”, download the binary (Virustotal report here — 10/41 alerts), execute and then click through the installation screens presented .

One of the install screens presents PlayBryte:

If the user doesn’t alter the default settings then (1) PlayBryte will be installed (2) Click Run Software/todownload.com gets paid and (3) the ad injection workflow moves on to Monitoring. Of interest in this scenario is that the PlayBryte installer does eventually hand off to the Google Chrome installer. If Google Chrome has a PPI program, it is likely that the folks behind Click Run Software/todownload.com are signed up to it.

Monitor

The gist behind monitoring is to determine when the time is right to inject into a site. In general, for every visit the user makes to a site, the ad injection software will:

  • Initiate a call back to home base, informing them of which site the user is browsing to
  • If the site visited applies, then the response from home base typically includes custom-tailored Javascript
  • This Javascript is responsible for requesting an ad (either from home base or an ad network) and having it rendered

Inject

Injection can be in a number of forms:

  1. The ad injector may remove existing advertisements and replace them with its own
  2. It may add more advertisements onto the page
  3. It will take original content on the page and overload it with ads.

PlayBryte serves as a great example when it comes to modifying original content. From this video:

  • 00:06 start up Internet Explorer
  • 00:10 load Amazon.com
  • 00:21 search for “kindle”
  • 00:23 hover over first link returned (Kindle, Wi-Fi, 6″ E Ink Display ….)
  • 00:27 click first link
  • 00:28 SHOCK: A popup appears. It dominates the screen real esate and it’s an ad! Sample packet trace available here.

Note that the ad injector has overloaded original content on Amazon’s DOM. There was no indication that clicking on the first link returned when searching for “kindle” would result in a popup for a visitor survey (and the opportunity to win a $1000 Walmart Gift card).

PlayBryte is up to the same nonsense on Wikipedia’s site:

PlayBryte may argue that they have the user’s permission to do this, so what is the problem? Some may say that having the user’s permission is inconsequential, for it is the publisher’s permission that matters.

MAD Monday

by
Posted by wesleyb in Affiliate Fraud | Cookie-Stuffing | Mad Monday | Malvertising

How would you feel if I arranged with your employer to pay me a portion of your pay check every month? You wouldn’t know who I am, you wouldn’t know why I am doing this, you would just see a portion of what you were earning simply disappear. Now you could ask your employer what is going on, but don’t expect anything more than a seemingly worried look and a polite pointer to the door.

Affiliate marketers who unknowingly clash with fraudsters have been experiencing something similar to this scenario. One month an affiliate can happily be earning whatever it is that he/she earns and the next month they suddenly see their earnings drop substantially. Sure, markets change, people shift gears and the money goes somewhere else. But every now and again a fraudster enters the scene and there’s trouble.

I call affiliates that use unscrupulous techniques to steal earnings from legitimate affiliates “fraudsters” but they call themselves “blackhats”. A legitimate affiliate simply can’t compete with these guys. Sprinkled amongst the back patting and boasting about six figure incomes in their secret forums these guys share a lot of knowledge with each other. Every now and again a newbie asks if what they are doing is illegal, responses are typically along the lines of

It’s not illegal bro, just smart

They don’t seem to realise that there are people out there that make an honest living from affiliate marketing. It’s these people that they are stealing their earnings from. Fortunately, sooner or later someone does do something about these kinds of people: UNITED STATES OF AMERICA V SHAWN D. HOGAN. See page 6, line 11 (just under the Cookie Stuffing header)

17. As set forth more fully below, beginning on a date unknown to the Grand Jury, but no later than in or about mid-2005, and continuing to in or about June 2007, in the Northern District of California and elsewhere, the defendant, SHAWN D. HOGAN, did knowingly devise and intend to devise, an did participate in, a material scheme and artifice to defraud, and to obtain money and property by means of materially false, misleading, and fraudulent pretenses, representations, omissions, and promises, which scheme and artifice is summarized below.

18. It was part of the scheme and artifice that, through various means, the defendant disseminated on a large number of web pages computer code that, when those web pages were viewed by a computer user, was designed to cause that computer to make a request to eBay’s home page merely for the purpose of prompting eBay’s servers to serve up a cookie, which would then be “stuffed” onto the user’s computer. These cookies contained information that identified an Affiliate ID of Digital Point Solutions. In such situations, the human user never actually clicked on an eBay advertisement or link on Hogan’s affiliate websites.

It’s been a while since a large affiliate marketer has been in trouble.

Are you an Amazon affiliate marketer? If so, you may be seeing a sudden drop in earnings and here are some of the reasons why:

Each of the Google ads above is potentially stealing earnings from legitimate Amazon affiliate marketers. These ads target popular sites all over the world. Just the fact that they are being displayed means that they are doing what they intended (drop cookies on unsuspecting users).  A sample packet trace from loading an ad is here. Note the Flash banner, the requests for images that redirect through 302s and secure HTTP sessions, this makes it incredibly tricky for investigators to get to the bottom of things.

As can be seen from the packet trace, if you saw these banners, you most likely visited Amazon in the background via an affiliate link. The next time you buy something from Amazon (within a certain amount of time — typically 7 days), the fraudster behind the ads will be paid a commission and not the legitimate affiliate marketer who may have sent you there previously.

For a quick summary of what I am talking about, take the red text from a few paragraphs above and replace the word “eBay” with “Amazon”.

MAD Monday

by
Posted by wesleyb in Affiliate Fraud | Cookie-Stuffing | Mad Monday | Malvertising

Some readers may remember this banner from Mad Monday June 4, 2012. In a nutshell, it is an ad that is forcing cookies via affiliate link redirects into the browsers of most users that see it.

If you are a coupons Web site that makes a living as an affiliate in addition to displaying online ads, this banner may cause some problems for you. On the one hand, you will be paid to display it. But on the other hand, its display alone may result in lost revenue (by overwriting the cookies of the users that you are targeting).

As of twenty minutes ago it is  still up to no good exploiting a number of publishers by targeting their users through Google’s ad network (with Amazon as its end goal – refer to packet  capture for details).

A few minutes ago on dealreview360.com:

A campaign of this nature is most likely bought and paid for, so it seems reasonable to assume that Amazon has not yet caught this guy.

MAD Monday

by
Posted by wesleyb in Affiliate Fraud | Cookie-Stuffing | Mad Monday | Malvertising

Cookie-stuffing attack through ads on a Merchant’s site

In a previous post today, we looked at a Google ad that cookie-stuffed users of a popular deals site. The victims in this scenario are the publisher of the ad (an affiliate) and, of course, the merchant (Amazon).

In this post we look at a very similar ad that is using Google’s network to directly cookie-stuff the users of a merchant’s site. In this attack, the advertiser is skipping the middle man (the deals site from the last post) and going directly to the merchant.

The merchant is cheapoair.com. They are displaying Google ads, at least one of which is claiming unearned commission through their affiliate program.

In targeting the merchant, the advertiser behind this ad is minimizing the likelihood of his forced-cookie being overwritten by another affiliate (legitimate or otherwise):

Sample of the packet trace (cookie-stuffing link in red) when this ad was displayed on cheapoair.com:

GET /images2/1/blank.png HTTP/1.0
Accept: */*
Accept-Language: en-US
Referer: http://pagead2.googlesyndication.com/pagead/imgad?id=CICAgKD14qfeswEQ2AUYWjIIPdUm7V0mHrU
x-flash-version: 10,3,183,7
User-Agent:
Host: imagelly.com
Connection: Keep-Alive

HTTP/1.1 302 Moved Temporarily
Date: Mon, 04 Jun 2012 22:22:47 GMT
Server: Apache/2.2.22 (Unix) mod_ssl/2.2.22 OpenSSL/0.9.8e-fips-rhel5 mod_auth_passthrough/2.1 mod_bwlimited/1.4 FrontPage/5.0.2.2635
X-Powered-By: PHP/5.3.13
location: https://imagelly.com/images2/ssl/1/blank.png
Cache-Control: max-age=0, public
Expires: Mon, 04 Jun 2012 22:22:47 GMT
Content-Length: 0
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: text/html

----------------------------------------------------------------------

GET /images2/p/1/blank.png HTTP/1.0
Accept: */*
Accept-Language: en-US
x-flash-version: 10,3,183,7
User-Agent:
Connection: Keep-Alive
Host: imagelly.com

HTTP/1.1 302 Moved Temporarily
Date: Mon, 04 Jun 2012 22:22:48 GMT
Server: Apache/2.2.22 (Unix) mod_ssl/2.2.22 OpenSSL/0.9.8e-fips-rhel5 mod_auth_passthrough/2.1 mod_bwlimited/1.4 FrontPage/5.0.2.2635
X-Powered-By: PHP/5.3.13
location: http://click.linksynergy.com/fs-bin/click?id=OeRNcvnZo1U&offerid=215652.10000466&type=3&subid=0
Cache-Control: max-age=0, public
Expires: Mon, 04 Jun 2012 22:22:48 GMT
Content-Length: 0
Keep-Alive: timeout=5, max=99
Connection: Keep-Alive
Content-Type: text/html

The affiliate id in this attack is “OeRNcvnZo1U” and the host used as a redirect proxy is imagelly.com.

If this all still seems a little confusing and you want to replay this attack for yourself:

  1. Visit cheapoair.com
  2. Remember that if you got there via an affiliate link and if you then engage in a transaction on the site, the affiliate responsible for sending you there will be paid a commission
  3. Now keep in mind that there may be an ad on the site that is forcing affiliate links to you the user
  4. One of the links is the affiliate link highlighted in red above
  5. Take this link and paste it into your browser, note what the final URL is

MAD Monday Continues

by
Posted by wesleyb in Affiliate Fraud | Cookie-Stuffing | Mad Monday | Malvertising

In a post earlier today we took a look at Google ads that were targeting two publishers with a cookie-stuffing attack. The first publisher (highdefforum.com) ranks quite high on Alexa at 54,390 and the second (clipwithpurpose.com), whilst not as popular with a rank of 1,697,999, can be used for finding deals (and is also an affiliate site).

What happens when you combine these attributes into a single site?

Since an attacker is paying for each of his ads to display on a publisher’s site, he could maximize profit by targeting a single popular site frequented by users looking for deals. These users, after all, generally intend to buy something.

Enter slickdeals.net, an Amazon affiliate with a global Alexa rank of 639 and US rank of 127. Site Analytics estimates that slickdeals.net has approximately 1.1 million unique visitors per month.

This Google ad is running on Slickdeals.net and is cookie-stuffing their users (targeting Amazon):

To be clear, slickdeals.net is an Amazon affiliate that is displaying Google ads. At least one of these ads is targeting their hard earned users. This ad will force Amazon cookies onto the user’s machine via image redirects. If the user then makes a purchase from Amazon, the advertiser behind the Google ad (not slickdeals) will be paid an unearned commission.

A sample from the attack (amazon cookie-stuffing in red):

GET /images/j/B.png HTTP/1.0
Accept: */*
Accept-Language: en-US
Referer: http://pagead2.googlesyndication.com/pagead/imgad?id=CICAgICQ3qL6ngEQ2AUYWjIIozg0gGGm4TE
x-flash-version: 10,3,183,7
User-Agent: 
Host: www.imagelly.com
Connection: Keep-Alive

HTTP/1.1 302 Moved Temporarily
Date: Mon, 04 Jun 2012 20:04:08 GMT
Server: Apache/2.2.22 (Unix) mod_ssl/2.2.22 OpenSSL/0.9.8e-fips-rhel5 mod_auth_passthrough/2.1 mod_bwlimited/1.4 FrontPage/5.0.2.2635
X-Powered-By: PHP/5.3.13
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Set-Cookie: PHPSESSID=dd229442777b9cd95d5fc24959d13665; path=/
Location: http://www.amazon.com/gp/redirect.html?ie=UTF8&location=http%3A%2F%2Fwww.amazon.com%2F&tag=theblogtopdai-20&linkCode=ur2&camp=1789&creative=9325 Cache-Control: public
Connection: close
Content-Type: image/png

The Amazon affiliate id in this attack is “theblogtopdai-20″ and the host that is being used as a proxy for the redirect is www.imagelly.com.

MAD Monday

by
Posted by wesleyb in Affiliate Fraud | Cookie-Stuffing | Mad Monday | Malvertising

Cookie-stuffing ad attacks continue

I recently started adding the malvertizing category to posts which discuss Flash-based cookie-stuffing ads. There can be no question that this form of advertising is nothing short of deliberately harmful. At the end of the day, an unscrupulous advertiser is using the online advertising networks to target the hard earned users of legitimate publishers. The nature of the targeting is such that if the publisher gets in the way (let’s say if the publisher is an Amazon affiliate and the attacker is targeting Amazon), then not only is the attacker potentially stealing from Amazon the merchant, but from the publisher as well (the publisher loses conversions!).

If you are an Amazon affiliate and you see the following Google display ads on your Web site (red arrows), then you may have a problem:

Ad #1

Ad #2

From the screenshots above, we see Google ads displayed on highdefforum.com and clipwithpurpose.com. These ads are engaging in Flash-based cookie-stuffing. We know from previous posts that this means these ads are forcing cookies into the browsers of unsuspecting users. The cookies will signal merchants to pay an affiliate in the event that a purchase is made. In this scenario, the ads are targeting Amazon. So in the event that the consumers who see these ads then make a purchase from Amazon with 24 hours, well then the affiliate (the advertiser in this case) is paid a small percentage.

If you browse through clipwithpurpose.com, you will encounter a number of affiliate links, i.e., clipwithpurpose.com is a legitimate affiliate. Now whilst I have only seen the ads from today’s post targeting Amazon, it’s possible that they are targeting other merchants as well. In which case, clipwithpurpose.com may see a significant decline in their own conversion rate.

Attack Analysis

The attack from ad #2 is not as sophisticated as the first. As a result, it makes for a good example when trying to understand an attack in detail. I’ll step you through a packet capture from the attack with some comments (// this is a comment added by me).

 

GET /pagead/imgad?id=CICAgICQ0Z-rThD6ARj6ATIIE2mQJPQmZJQ HTTP/1.1 // the browser makes a request for an ad
Accept: text/html, application/xhtml+xml, */*
Accept-Language: en-US
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0)
Accept-Encoding: gzip, deflate
Connection: Keep-Alive
Host: pagead2.googlesyndication.com

HTTP/1.1 200 OK
P3P: policyref="http://www.googleadservices.com/pagead/p3p.xml", CP="NOI DEV PSA PSD IVA IVD OTP OUR OTR IND OTC"
Content-Type: application/x-shockwave-flash // Google responds with an ad and it's flash
Date: Fri, 01 Jun 2012 16:20:27 GMT
Expires: Fri, 08 Jun 2012 16:20:27 GMT
Cache-Control: public, max-age=604800
X-Content-Type-Options: nosniff
Server: cafe
Content-Length: 16180
X-XSS-Protection: 1; mode=block

------------------------------------------------------------------
GET /img/0/R.jpg HTTP/1.1 // the flash ad has rendered, it is now requesting an image
Accept: */*
Accept-Language: en-US
Referer: http://pagead2.googlesyndication.com/pagead/imgad?id=CICAgICQ0Z-rThD6ARj6ATIIE2mQJPQmZJQ
x-flash-version: 11,2,202,235
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0)
Host: www.dogsvscats.info // this is the host that the image is being requested from
Connection: Keep-Alive

HTTP/1.1 302 Found // the host says it doesn't have the image, but it knows where it can be found
Vary: Accept-Encoding
Date: Fri, 01 Jun 2012 16:20:29 GMT
Server: LiteSpeed
Connection: close
X-Powered-By: PHP/5.2.11
Set-Cookie: PHPSESSID=85e9465ed033e8202a0959538f4516f6; path=/
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Location: https://www.dogsvscats.info/img/kick/0/R.jpg // new location of the image, note the tricky https Content-Type: text/html
Content-Length: 0

------------------------------------------------------------------
CONNECT www.dogsvscats.info:443 HTTP/1.0 // setup an ssl tunnel
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0)
Host: www.dogsvscats.info:443
Content-Length: 0
Proxy-Connection: Keep-Alive
Pragma: no-cache

HTTP/1.1 200 DecryptTunnel Established
Timestamp: 09:20:25.341

------------------------------------------------------------------
GET /img/kick/0/R.jpg HTTP/1.1 // ssl redirects to new image location
Accept: */*
Accept-Language: en-US
Referer: http://pagead2.googlesyndication.com/pagead/imgad?id=CICAgICQ0Z-rThD6ARj6ATIIE2mQJPQmZJQ
x-flash-version: 11,2,202,235
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0)
Host: www.dogsvscats.info
Connection: Keep-Alive
Cookie: PHPSESSID=85e9465ed033e8202a0959538f4516f6

HTTP/1.1 302 Found // host says doesn't have the image, but knows where it can be found
Content-Encoding: gzip
Vary: Accept-Encoding
Date: Fri, 01 Jun 2012 16:20:30 GMT
Server: LiteSpeed
Connection: close
X-Powered-By: PHP/5.2.11
Location: http://www.dogsvscats.info/img/t/0/R.jpg // new image location
Content-Type: text/html
Content-Length: 20

------------------------------------------------------------------
GET /img/t/0/R.jpg HTTP/1.1 // new request for new image location
Accept: */*
Accept-Language: en-US
Connection: Keep-Alive
x-flash-version: 11,2,202,235
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0)
Cookie: PHPSESSID=85e9465ed033e8202a0959538f4516f6
Host: www.dogsvscats.info

HTTP/1.1 302 Found
Content-Encoding: gzip
Vary: Accept-Encoding
Date: Fri, 01 Jun 2012 16:20:30 GMT
Server: LiteSpeed
Connection: close
X-Powered-By: PHP/5.2.11
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Location: http://www.amazon.com/dp/B006596HUC/?tag=conshomgarvar-20 // host says go to amazon for the image
Content-Type: text/html
Content-Length: 20

------------------------------------------------------------------
GET /dp/B006596HUC/?tag=conshomgarvar-20 HTTP/1.1 // request to amazon using an affiliate id, game over
Accept: */*
Accept-Language: en-US
Connection: Keep-Alive
x-flash-version: 11,2,202,235
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0)
Host: www.amazon.com

HTTP/1.1 200 OK
Date: Fri, 01 Jun 2012 16:20:31 GMT
Server: Server
x-amz-id-1: 0NX7W235169WKP4TZ3D5
p3p: policyref="http://www.amazon.com/w3c/p3p.xml",CP="CAO DSP LAW CUR ADM IVAo IVDo CONo OTPo OUR DELi PUBi OTRi BUS PHY ONL UNI PUR FIN COM NAV INT DEM CNT STA HEA PRE LOC GOV OTC "
x-frame-options: SAMEORIGIN
x-amz-id-2: rSCvAcCbhoCS+ofniG5M0DZDB3bMY/mjZhnowEdTXvk3BTweCfPw1UoODVrXZCAR
Vary: Accept-Encoding,User-Agent
Content-Encoding: gzip
Content-Type: text/html; charset=ISO-8859-1
Set-cookie: session-id-time=2082787201l; path=/; domain=.amazon.com; expires=Tue, 01-Jan-2036 08:00:01 GMT
Set-cookie: session-id=176-4249818-9170718; path=/; domain=.amazon.com; expires=Tue, 01-Jan-2036 08:00:01 GMT
Set-cookie: UserPref=fyG2emcg8AGmjd5hBs/xlsRUdz58jxKO6c/4Bmc7RO7Udec+o+eyNYHpabDenGo3i3rTW+PdRhKBCiB41uU/DI4FzaFNsbhbdggJoOGIGc4T0Tb/aS5VzYLHap8aqHGMr7vT/eBqIm6QxUdab5Nj7SeL/JxwYPyt/tjCzxJm596k3mVAWPTvGgWVLqc9hnQTUWbmWxAkH8iTm+RF3In1MoZOfyUeKyhqftHIju1qoNrVdlXFWtrS944JCJS267FAT96WUJnRb0RdGlS+bYB1KN3O5pYjsaDNTGOOqf7iPZbLBJb7PoHK8Tt4rSRrJNWElt0gsCgasmN15ySn7BzgZnP2PKH9qpIgVcHi6TK2ml1BRjinks4wpeNNEzYI8jrV1Q7GLMQNyYXt829DUdOL/AkO/l40knUmIFsh7+KBg7oMQIy8axUUNNeTZUw64KNcvXb5oGMEp/E=; path=/; domain=.amazon.com; expires=Fri, 08-Jun-2012 16:20:31 GMT
Transfer-Encoding: chunked

------------------------------------------------------------------

The Amazon affiliate id responsible for cookie-stuffing from ad #2 is “conshomgarvar-20″. It cycles through a few others, but not as many as ad #2 (which involves several redirect domains, better targeting and at least a dozen affiliate ids). I’m not sure why these guys use so many redirects, I have seen as many as twenty redirects in other attacks. Perhaps it is an attempt to throw off other archaic forms of fraud detection?

Why are these advertisers allowed to do this?

Fortunately there already exists some mitigation to prevent attacks like these: normal advertisers like you and I are simply not allowed to upload our own Flash creative into the Google network. Google and the large online advertising networks have fairly rigid templates defined, and whatever it is that we want to advertise simply has to fit within those guidelines or it is a no go. This works out really well until someone manages to jump over this barrier and into the trusted advertiser zone.

When elevated to this privilege, it appears that advertisers are allowed to construct creative that depend upon a third party beyond the control of Google. So if you were allowed to take a look at Google’s threat model for this scenario, you would see an arrow in one of their data flow diagrams that shoots out of trusted territory and into the unknown.

The request from the creative in ad #2 to www.dogsvscats.info for an image that may have seemed fairly harmless at ingestion time (and probably served up an actual image when it was reviewed) was the dependence upon a third party. Once the ad was up and running on the Google network, all the attacker had to do was change the location of the image (the 302s we saw from the packet trace) and Voilà: enter a powerful cookie-stuffing machine.

How to mitigate this further?

Pushing the advertisers highlighted today out of the trusted zone (or simply closing their accounts) will solve the immediate problem of these two advertisers in the short term. Removing the privilege of being allowed to depend on a third party for content as a trusted advertiser would act as mitigation over the longer term. This seems like a fairly draconian step, for there are legitimate scenarios amongst trusted advertisers where this works out really well. In which case, mitigation has to be that of monitoring the ads with the consequence of a rapid takedown in the event of an infraction (a huge undertaking!).

Cookie-stuffing through advertez.com

by
Posted by wesleyb in Affiliate Fraud | Cookie-Stuffing | Malvertising

A few weeks ago, we looked at a Flash-based cookie-stuffer who was using the ad networks to do his dirty work. This technique is interesting because the fraudster has to pay the ad networks in order for his Flash ad to run on the sites of unsuspecting publishers. So if the ad is running and if the cookie-stuffing is still happening then one would assume that the fraudster is still paying and the whole scheme is still profitable (and undetected).

Note I just implied that unsuspecting publishers were not a part of this. But let’s think about that for a second.

Perhaps if I was an unscrupulous publisher as well as an affiliate that didn’t want to risk tainting a good relationship with a merchant, then I would disassociate myself with any fraudulent cookie-stuffing activity by using an ad network to do the dirty work on my site. This would be a smart way to do things. The biggest advantage for me the fraudster, would be that not only is it tricky to figure out what I’m up to but I could now call upon the incredible targeting power wielded by the advertising network. Instead of writing my own targeting scripts (which have to be thought about, written and then tested, tested, tested), I could rely upon the thousands of man hours that have gone into writing and testing a user-targeting armada. Not only would I use this to target users of my own site, but I could add all sorts of contraints to the targeting, for example, I would only target users in regions where I know (from testing) that my merchant’s fraud detection systems do not run from. This whole setup would make it incredibly difficult for any fraud investigator to reproduce, or even just understand.

Taking this just a little bit further. Perhaps I could flip this around and use it to attack the relationship that a legitimate affiliate (my competitor) has with a merchant by paying for ads that cookie-stuff the user through the legitimate affiliate’s id (making sure to target the region where the merchant’s fraud detection system runs from).

I’ve yet to see a scheme of this nature.

What I do see though, is lots and lots of cookie-stuffing! Yet another Flash-based scheme using ad networks features in today’s post. Why this fellow is interesting to me:

  • 1. He is being very particular regarding the publishers where his ads are displayed, this is what got me thinking about the scenario above. I’m not suggesting that the publishers involved are up to bad things, I just keep wondering why this advertiser is only targeting a select few sites.
  • 2. He hides his cookie-stuffing behind a seemingly legitimate advertising banner (recall that the last chap had a banner which clicked through to what was basically a useless, empty site).

Today’s fraudster uses a banner ad that targets GoDaddy:

Upon first inspection, the advertiser here seems to be GoDaddy. But this is not the case. The advertiser is just hiding behind GoDaddy. What’s actually happening is that this advertiser belongs to the GoDaddy affiliate program. I’ve drawn up a little state diagram to illustrate what is going on inside the banner:

Note what happens on the left side of this diagram is invisible to the user. When the banner is first loaded, it immediately phones home to advertez.com. Advertez then uses server-side logic (hidden from us) to decide whether or not to cookie-stuff. If it’s a green for go, then advertez redirects through to a URL which belongs to the Amazon affiliate program,  otherwise it does nothing. In the event that you click on the Banner, then the Flash looks up the ClickTag that was used to load the banner. Essentially, this is a parameter in the URL used to load the banner. In this case the ClickTag is an AdImperium URL. So when you click on the banner, it will redirect you through to adimperium, then yieldmanager and finally onto an affiliate link controlled by GoDaddy.

So not only is this advertiser cookie-stuffing through this banner, but he is maximizing the return on his cookie-stuffing investment by generating revenue in the event that his banner is actually clicked!

This whole scheme will also act as a wonderful disguise when going through the approval process run by the advertising networks. They will look at this ad and see that it’s obviously a GoDaddy affiliate

“Looks good, let’s ship it!”