Threat Research Blog

Ads Gone Bad

FireEye Labs tracks malvertising activity and recently discovered hundreds of sites that may have been exposed to malvertisements via abuse of ad networks that use real-time bidding (RTB).

Since February 4, 2015, FireEye Labs has seen over 1,700 advertiser RTB requests that resulted in downloading of malicious SWF files. We believe this activity is part of an active malvertising operation.

Quick Primer

Online advertisements are hosted by 3rd party servers (i.e., ad networks) and loaded seamlessly into a webpage. In a malvertising attack, a user is delivered a malicious ad. These ads can come from ad servers that are part of a legitimate ad network or rogue ad servers controlled by attackers.

Real Time Bidding is an ad sale and delivery system that allows for instant, autonomous ad auctions at the time the ads are served. A number of buyers set up bids ahead of time for a certain amount of ad impressions (i.e., page loads) on pre-selected sites and certain target demographic characteristics. When a user requests an ad, the Ad Exchange awards the highest bidder who has an active bid on advertising matching the incoming user's demographic profile. As a result, the auction winner's ad is displayed. This all occurs in real-time, as each ad is requested from the ad servers.

RTB Activity Leading to Malicious Ads

Most of these malvertising attacks followed a similar chain of requests. Visible in the URL parameters are additional bits of information like system information, bid amount and the original ad URL, similar to hXXp://

Multiple domains are employed; active ones we detected are shown in Figure 1. Additional associated domains are included at the end of this report.








Figure 1 – Active ad servers involved

Each request to a different domain has a corresponding HTTP Referer as shown in Figure 2. We found these pairings all correlate with the campaign date starting on February 4, 2015.

Ad Server URL












Figure 2 – Table of ad server URLs and corresponding referers

After an ad is clicked or loaded in the background, the visitor’s information is sent back to the ad exchange, resulting in URL’s like the ones shown in Figure 3.

These URL’s by themselves are not malicious; however, after inspecting the URL a bit closer, we see some interesting data associated with advertising systems, such as the price, which belongs to a self-serve RTB platform.

Figure 3 – Logged URL’s (truncated) show RTB activity and geolocation data.

A closer look at the URLs reveals demographic, OS and browser info as well as impression price and bid amount in Base64.

Figure 4 – HTTP request involving RTB activity.

The returned HTML page loads the SWF files and additional scripts. Ironically, the HTML code returned something worth noting, considering it belongs to an advertiser network. Visible in the HTML page contents is an interesting function named “F*ckAdBlock” shown in Figure 5.

Figure 5 –Ad blocker function

SWF Files

Following the RTB data exchange, the SWF file request activity occurs.

The SWF files are requested using a hostname like this one:


The SWF requests all have the same URL structure:


Most of the campaign activity appears to be from two “users” identified in the URL.



with the following “camp” ID’s (campaign ID).

camp_3698, camp_3693, camp_3674, camp_3709, camp_3830

The attackers use a packer that unpacks and loads two SWF files. The first SWF is the flash exploit, and the second contains a seemingly unrelated advertisement. The attackers may package and serve different advertisements, but the exploit is always the same.

The exploit is CVE-2014-0569, which is an integer overflow vulnerability in casi32 of the avm2.intrinsics.memory module designed to optimize bytearray operations ( CVE-2014-0569 was reported to ZDI (, who reported the vulnerability to Adobe. Adobe patched CVE-2014-0569 on October 14th, 2014 (, and exploit kits began adopting the vulnerability shortly thereafter.

Payload Stage

If the attack is successful a payload is delivered using the following HTTP request, which lacks a User-Agent, making it easy to identify.

Figure 6 – Payload Request with filename “ee2un066aepv4.php”

ee2un066aepv4.php has shown up before, oddly enough, some of the samples we examined were benign Windows operating system files.

In other cases we have seen Ransomware including Cryptowall and other Crimeware.

We detected payloads coming from the following IP’s.

Additional Ad Server Domain Info

As this activity is ongoing, we will continue to update the FireEye Blog with developments and additional technical analysis.


FireEye Labs would like to thank Fanfang Zhang and Dan Caselden for their contributions to this blog.