Cisco Blogs

RIG Exploit Kit Strikes Oil

June 5, 2014 - 1 Comment

This post was co-authored by Levi Gundert with contributions from Emmanuel Tacheau and Joel Esler.

In the last month we have observed high levels of traffic consistent with the new “RIG” exploit kit (EK), as identified by Kahu Security. This new EK reportedly began being advertised on criminal forums in April, which coincides with when we first began blocking this traffic on April 24th. Whilst the release of a new EK is not uncommon, RIG’s appearance is significant in three ways. First, because of the sheer amount of traffic we are seeing – we have so far blocked requests to over 90 domains for more than 17% of our Cloud Web Security (CWS) customers. Second, because we have seen it being used to distribute “Cryptowall”, the latest ransomware to follow in the success of the now infamous “Cryptolocker”. And third, because it continues the trend of an increased reliance upon Silverlight in EKs which we have previously written about for both the Fiesta and Angler kits. Like these other kits, we have seen RIG using malvertising to perform a drive-by attack on visitors to high profile, legitimate websites. This accounts for the high amount of traffic we have seen in the last month.


Requests for RIG landing pages April 24 - May 22

Requests for RIG landing pages April 24 – May 22

The above chart shows the number of requests over time for RIG landing pages between April 24th and May 22. These landing pages have a similar URI structure: query string which contains a constant alphanumeric string, a vertical bar, and then a variable alphanumeric string. E.g:


The constant string which they are using before the vertical bar has changed over time:

Until May 16
May 16 – 18
May 16 – 21
After May 21


Visitors to the landing pages get served one of several exploits, which helpfully identify themselves via the “req” query string:

req=jar / req=xml
req=swf OR swfIE


If we look at the content type of the files requested, we can see that Flash, which is detected as “application/octet-stream” makes up the bulk of the requests, followed by Silverlight. The java applet is distributed via Java Web Start which makes use of jnlp files: these are detected as “text/xml”.

Content type distribution for exploit URLs

Content type distribution for exploit URLs

We have observed RIG using files with the following MD5s :


These appear to be exploiting the following vulnerabilities:

  • Silverlight: cve-2013-0074
  • Java: cve-2013-2465 and cve-2012-0507
  • Flash: cve-2013-0634


Upon successful exploitation the payload is downloaded from paths with the query parameter “req=mp3”. We have observed this infection path resulting in Cryptowall ransomware. The following message was present as a unicode Registry Key after infection:

Path: HKEY_USERS\Software\9BEFA355ED9F4D1C986110581468323D Name: 2 Type: unicode Data: What happened to your files ?All of your files were protected by a strong encryption with RSA-2048 using CryptoWall.More information about the encryption keys using RSA-2048 can be found here: ******What does this mean ?This means that the structure and data within your files have been irrevocably changed, you will not be able to work with them, read them or see them,it is the same thing as losing them forever, but with our help, you can restore them. ****How did this happen? Especially for you, on our server was generated the secret key pair RSA-2048 – public and private.All your files were encrypted with the public key, which has been transferred to your computer via the Internet. Decrypting of your files is only possible with the help of the private key and decrypt program, which is on our secret server. ****What do I do ?Alas, if you do not take the necessary measures for the specified time then the conditions for obtaining the private key will be changed.If you really value your data, then we suggest you do not waste valuable time searching for other solutions because they do not exist. ****For more specific instructions, please visit your personal home page, there are a few different addresses pointing to your page below: 1.hxxps://kpai7ycr7jxqkilp[.]torexplorer[.]com/5f2i 2.hxxps://kpai7ycr7jxqkilp[.]tor2web[.]org/5f2i 3.hxxps://kpai7ycr7jxqkilp[.]onion[.]to/5f2i ****If for some reasons the addresses are not available, follow these steps: 1.Download and install tor-browser: 2.After a successful installation, run the browser and wait for initialization. 3.Type in the address bar: kpai7ycr7jxqkilp[.]onion/5f2i4.Follow the instructions on the site. ****IMPORTANT INFORMATION: Your personal page: hxxps://kpai7ycr7jxqkilp[.]torexplorer[.]com/5f2i **Yourpersonal page (using TOR): kpai7ycr7jxqkilp[.]onion/5f2i Your personal identification number (if you open the site (or TOR ‘s) directly): 5f2i

Like other forms of ransomware, Cryptowall encrypts your local files and requires you to pay a ransom for the key stored on their servers. Upon infecting our test system, we were provided with the above links to TOR sites, and a personal identifcation number. Visiting the page presents you with a captcha followed by information about your ransom:


Ransom page

Ransom page

At the time of writing, our ransom had reportedly been increased three times to $600, with a deadline of 18/06/14 at 06:51 after which time the data would be irretrievable. This threat should be taken seriously – other ransomware has been known to make good on its warnings of data loss. Given the recent high profile reports of an FBI shutdown of Cryptolocker, it is worth remembering that whilst Cryptolocker has proven to be an extremely potent threat it is just one of several forms of ransomware including Cryptowall and Cryptodefense. Ransomware has proved to be a very successful form of extortion and we are likely to see new variants on the Cryptolocker theme for quite some time.

Traffic generation and distribution

The many-to-one relationship between websites and the affiliate ads included on them (the same ads can be served across many sites, and the same site can serve many different ads) makes determining the precise path which sent users to the malicious landing pages difficult. However, ad-networks like to track where their clicks came from, and because there are many stages of redirection involved in the complicated distribution of ads, they don’t usually have direct access to this information in the form of an HTTP header referer (sic) field. To get around this they often pass information about the original referrer across the various redirects using a query string parameter. For example, this is one of the referrer URLs to a RIG landing page:[…]./

Looking at the query string we can see that although this request came from, the “BMPClickURL” parameter suggests that it was redirected from the domain of another ad-network – who have used their own “./” separator to nest additional information within the BMPClickURL parameter. This information includes a “referrer” field which suggests that the original ad was encountered at “” (the guardian is a high-profile UK news site). Around 47% of the requests for RIG landing pages that we have seen came from this host, and of these, 90 were redirects from domains. Extracting the referrer fields from these requests gives us a sample of the variety of sites likely playing host to the malicious ads, including several high-profile ones such as, and (full list below).

We can also look at the location of our CWS customers encountering RIG to get a sense of which users are being redirected:

Location of CWS customers requesting RIG landing pages

Location of CWS customers requesting RIG landing pages

The US is, predictably, the most effected, with the UK coming in second.

Until May 22 RIG appears to have been making use of both newly registered domains and compromised legitimate sites to both host its landing pages and serve its exploits, all from paths ending in “proxy.php” (full list below).

A look at the landing page URLs reveals a high prevalence of the tell-tale “/wp-content/themes/” path which suggests that at least some of these domains are running the WordPress content management system. Using the Plecost fingerprinting tool which is included in Kali Linux, we can check all the domains for WordPress installations and plugins. An scan of the compromised domains returns responses from 35 of them, of which 29 are identified as running WordPress (versions from 2.9.x – 3.9.x). The variety in plugins and versions running on these sites suggests that these domains were probably compromised through a brute-force attack, rather than the exploitation of a particular vulnerability in the WordPress platform. Using existing legitimate sites to host the EK alleviates the need to create and maintain a dedicated domain infrastructure, and mitigates some of the problems associated with doing so: registering new domains, randomizing naming, using multiple email addresses, etc., in order to avoid easy attribution.

However after May 22 distribution appears to be from newly registered domains only using a variety of paths (full list below), including:

The switch is probably an attempt to avoid detection after having gained visibility over the last month. Despite this change, the query string pattern for both the landing pages and the exploits remains constant after this switch.


There is a continuous churn in the EK market: new kits arrive, old kits mutate and evolve. RIG may have been very active during May, but no doubt that will soon change. However amidst the churn, patterns emerge: Silverlight continues to rise in prevalence, and Java exploits appear to be on the wane. We have seen a lot of exploit kits generating their traffic using malvertising recently, and this will surely continue to be a powerful and readily exploitable way of infecting users. When it comes to dealing with ransomware the best advice is to be proactive: maintain regular and full backups incase the worst should happen. But it bears remembering that however malicious the payload an EK happens to be armed with, it is still only as good as its exploits. Regularly updated and patched machines which do not have rich media platforms such as Flash and Silverlight enabled remain relatively immune from these kinds of attacks.


Sourcefire VRT Signature ID numbers: 30936, 30934, 30935

Sample RIG landing page URIs

Sample RIG exploit and payload URIs

Domains seen hosting RIG from “proxy.php” before May 22:

Domains seen hosting RIG after May 22 change of path:

Example domains extracted from the query string of referrers:

In an effort to keep conversations fresh, Cisco Blogs closes comments after 60 days. Please visit the Cisco Blogs hub page for the latest content.


  1. According to the analysis of Cryptolocker done by Emisoft back in September (, Cryptolocker uses AES 256 to encrypt the files (generating one AES key per file extension locally), and one RSA 2048 public key from the Command and Control Server to encrypt the AES keys. That makes sense.

    I have seen no similar reporting on Cryptowall. Everything that I have been able to find seems to indicate that Cryptowall is using RSA 2048 to encrypt the files, with no mention of AES or other private key algorithm.

    Can you confirm that, unlike Cryptolocker, Cryptowall is using one Command and Control Server provided RSA 2048 public key exclusively to encrypt the victim’s files?

    Thank you.