Malvertising: Not all Java from is legitimate

Isn’t it ironic getting a Java exploit via, the primary source for one of the most common used browser plugins? Current malvertising campaigns are able to do this. This blog post details a relatively new trend: real-time advertisement bidding platforms being infiltrated by cyber criminals spreading malware.




Malvertising has changed over the years starting with exploitation of weak advertisement management panels and has now evolved into pretending to be a legit third party advertiser with social engineering. The current malvertising techniques are quite deceptive and most of the times only noticeable at the client side.

Combating this malvertising technique is hard due to the large layered setup of the bidding platforms currently in place. It can be a malicious advertiser 3 layers down in the chain but it can also be on the 1st level. Trust is the current system many advertisers use but it seems to be insufficient for today’s malvertising campaigns and techniques, a new system needs to be implemented in order to combat them.

Findings in network monitoring

Over the last week, from Tuesday august 19th until Friday august 22nd, the Security Operations Center of Fox-IT’s ProtACT service observed multiple high-profile websites redirecting their visitors to malware. These websites have not been compromised themselves, but are the victim of malvertising. This means an advertisement provider, providing its services to a small part of a website, serves malicious advertisement aimed at infecting visitors with malware.

While monitoring network traffic to and from workstations we observed a higher than usual amount of infections. When investigating these incidents in depth we noticed that they were infected with advertisements served via high-profile websites. During this period at least the following websites were observed redirecting and/or serving malicious advertisements to their visitors:


The advertisement in this case included the Angler exploit kit. Upon landing on this exploit kit a few checks were done to confirm whether the user is running a vulnerable version of either Java, Flash or Silverlight. If the user was deemed vulnerable the exploit kit would embed an exploit initiating a download of a malicious payload, in this campaign it was the Asprox malware. This whole process of malvertising towards an exploit kit is also visualized in the image at the top of this post.
Please note, a visitor does not need to click on the malicious advertisements in order to get infected. This all happens silently in the background as the ad is loaded by the user’s browser.

One aspect of advertisement networks that makes tracking these threats really complicated is ‘retargetting’. Retargetting is the process of one or multiple ad and content providers leaving tracking data, cookies or other files, so the next time an advertiser can deliver different advertisement as was shown the previous time. A website that rents advertisement space can sometimes show retargetted advertisement without knowing. The way it works is that a user with an interesting set of tracking cookies and other metadata for a certain adprovider is retargetted from the original advertisement content on the website to the modified or personalized data. We have seen examples where the website that helped with the ad redirect to infect a user had no idea it was helping the delivery of certain content for a certain adprovider.

While half the world is already familiar with exploitation of browser plugins, keep in mind drive-by and water-hole attacks are not solely focusing on the common browsers. A couple of months ago we also noticed advertisement loaded by the ‘Skype’-application was also serving malicious content.

In both cases Fox-IT contacted the affected advertiser, AppNexus in these cases, to quickly stop the malvertising.

The problem

The biggest problem with these malicious advertisements is that separating good from bad is a difficult process in the world of online advertising. With specific schemes such as real-time bidding, bad advertisements can remain hidden for extended periods of time. The Dutch website has recently published a detailed article about the problem here.

AppNexus as an example for this case, is one of the companies providing real-time bidding on advertisements and is used by many of the top ranking websites.

What is real-time bidding?

Real-time bidding is a process many advertisers have to serve ads. When a user visits a website, for example, this triggers a bidding request among the affiliates of the advertiser who will get to see meta-data about the visiting user. This metadata can include: geographical location, browser type, and web browsing history. The affiliates in their turn then automatically bid on this impression. The highest bidding advertisers gets to display their ad. In the case of this malvertising campaign the malicious advertisers were the highest bidders. For more details please see

The Payload

The aim of the exploit kit is to execute a malicious file on the visitor’s computer to infect them. The Angler exploitkit has been observed to deliver different payloads in the last few days. Although the dropped malware can vary, Fox-IT has only seen the Asprox malware being spread with this campaign.

Update (August 27th): It was pointed out by Kimberly on twitter that it was in fact Rerdom that was distributed which we mistook for Asprox ( Although, Asprox and Rerdrom do have a close relationship and affiliate with each other. More about the Asprox ecosystem can be read here on the StopMalvertising website: [ Urgent eviction notification – A deeper dive into the Asprox Ecosystem ].

Asprox is a notorious spam botnet which has upped its game over these past few months by using the infected machines to perform advertisement clicking fraud. Since this move the actors behind this botnet have started spreading Asprox on a much larger scale, at first via e-mail attachments and now by employing various exploit kits. Statistics provided by FireEye provided back in May 2014 shows big fluctuations in the botnet size and botnet activity:

FireEye Asprox tracking

In 2013 Trendmicro also published a paper about Asprox which explained the variety of functionality of the botnet. While Asprox is known as a spam botnet to most the spam is only 1 component of a modular botnet called Asprox. Asprox has gone through many changes and modifications which includes spam modules, website scanning modules and even credential stealing modules. This history and current events show Asprox is still actively being developed and used.

Indicators of compromise

These IOC’s relate to the malvertising campaign on the high-ranked websites specifically. The advertisement content first redirects to: ( which will give redirects towards the exploit kit.

The exploit kit:

Domains that were observed:

  • (on port 37702)
  • (on port 37702)

PassiveDNS logging shows 3 IP’s having been associated with these domains:


All the exploit kit hosts were observed using port 37702. Running exploit kits on high ports at best prevents certain network tools from logging the HTTP connections, as these are typically configured to monitor only HTTP ports. It does mean this exploit kit is blocked on a lot of corporate networks as they do not allow for browsing outside the normal HTTP ports, port 80 (or proxy ports) and 443 for SSL.

The ‘Asprox’ malware:

Since this botnet makes use of a fast flux technique the domain names make for better indicators of compromise than IP’s:


The following MD5 hash was seen for the dropped payload:

  • Crypted payload: 554c5dbb12e3fd382ce16e5bb34a17c2
  • Decrypted payload: 5304bc5b9454e6bc5a0ba2bff0eba605


There is no silver bullet to protect yourself from malvertising. At a minimum:

  • Enable click-to-play in your browser. This prevents 3rd party plugins from executing automatically.
  • Keep all plugins running in the browser up-to-date using tools like Secunia PSI.
  • Consider turning off unneeded plugins if you don’t use them. For example, Java can be installed without the web-plugin component lowering the risk of exploitation and infection.

Usage of Adblockers

In cases of malvertising on websites ad blockers are usually effective in blocking redirects.
However, on the case of Skype on May 15th it would have been insufficient. Most adblockers are part of the Browsers as an add-on, incapable of filtering for other applications. Skype makes use of Adobe Flash to display certain advertisements, this happens to be a plugin which the Angler can exploit.

Fox-IT Security Research Team

CryptoLocker ransomware intelligence report

In the beginning of September 2013, the CryptoLocker malware variant appeared in the wild, spread exclusively by the infamous P2P ZeuS (aka Gameover ZeuS) malware. CryptoLocker had a simple purpose: to act as ransomware, encrypting important files such as images and documents, and then asking the victim for money to unlock the files.

CryptoLocker warning
Image source: Ars Technica

In collaboration with FireEye, InTELL analysts at Fox-IT worked on the investigation. By the end of 2013, certain groups that were focused on online banking fraud, were moving to less risky attacks, such as ransomware, click fraud, and crypto coin mining. All of these attack types pose lower risk to the criminals compared to online banking attacks. P2P ZeuS was one of these groups.

US Law Enforcement led a joint operation from the 30th of May 2014, leading to a long term disruption of both P2P Zeus and CryptoLocker. A detailed description of the operation is available here.

CryptoLocker used AES symmetric cryptography to encrypt the files and encrypted the AES key with an RSA-2048 bit public key generated on the server side of CryptoLocker. For each infection a new RSA asymmetric key pair was generated on the CryptoLocker server. This rendered files impossible to recover for CryptoLocker victims on their own. To recover files, the malware offered victims the option to purchase the required RSA-2048 private key. The CryptoLocker authors began charging victims 100 USD in September 2013 to recover their files, and by May 2014, were charging victims 500 USD for recovery.

Not every computer infected with P2P ZeuS malware became infected with CryptoLocker. The reason for this is that CryptoLocker ran on victim machines alongside P2P ZeuS malware, which was used to commit financial fraud. In order for P2P ZeuS to be successful, a victim had to remain unaware that his/her system was compromised. Therefore, only a handful of P2P ZeuS botnets within the full P2P ZeuS network installed CryptoLocker. From September 2013 through May 2014, over half a million (545,146) infections occurred. This is much less than the amount of infections of P2P ZeuS over the same period.

Of the botnets distributing CryptoLocker, infections were mostly limited to victims located in the US, Canada, UK and Australia. These regions were most likely selected for their use of English as the primary language. This is shown in the heat map below – with over 60% of the CryptoLocker infections located in the US.


While CryptoLocker infections started in the beginning of September 2013, the largest number of infections in one month occurred during October 2013, with over 155000 systems affected worldwide. This accounts for nearly 29% of all infections between September and May 2014. After October 2013 the rates dropped, but still steadily pacing at around 50,000 infections per month.

The CryptoLocker infrastructure was separate from the P2P ZeuS infrastructure. It used a fast-flux network offered by a bulletproof hoster and a service hidden in the TOR network. These two channels were terminated on a proxy system that lead directly to the backend system, allowing victims to pay the ransom even though the fast flux network experienced various disruptions by security researchers.

The majority of victim payments to CryptoLocker were processed through Moneypak, but also a considerable amount of money was paid through the use of Bitcoins. A new Bitcoin address was created for each infection, making it harder for researchers to track and easier for CryptoLocker operators to distinguish transactions. In total, over 1400 Bitcoins (1407.24575477 BTC, around 700,000 USD in current exchange rates) were received. That is more than the 1388 BTC the malware requested, apparently some victims tried to transfer partial amounts. Unfortunately for them these lower amounts were lost for them and they added a small bonus for the criminals. A small number of early payments were received via Paysafecard and Ukash. In total, the amount of money made during the 9 month CryptoLocker operation was around 3 million USD. This accounts for the fluctuating Bitcoin exchange rate over time.

In the end, 1.3% of victims paid a CryptoLocker ransom, therefore, a large amount of victims likely permanently lost files due to this attack. Fox-IT InTELL and FireEye provide a free service to victims, to recover the private keys associated to CryptoLocker infections. This was announced on August 6 2014, in this press release. This gives CryptoLocker victims the ability to recover their files and restore the contents.

A big thank you to Kyrus tech for their tool Cryptounlocker. And finally we wish to thank Surfright for their assistance by providing encrypted files they generated using CryptoLocker.

Michael Sandee