RIG Exploit Kit Strikes Oil

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.

Exploitation

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:

njrMNruDMlmbScafcaqfH7sWaBLPThnJkpDZw-4

Until May 16

njrMNruDMlmbScafcaqfH6dbZBCNAhXUhduH2_aR

May 16 – 18

njrMNruDMh7GA5zBJPPcTKVDKU7WGFnYmMzMhe6JVg

May 16 – 21

njrMNruDMhvJFIPILuXASbtANlCDQgTe2c7B2w

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

java

req=xap

silverlight

req=swf OR swfIE

flash

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”.

Cryptowall

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: http://en.wikipedia.org/wiki/RSA_(cryptosystem) ******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: http://www.torproject.org/projects/torbrowser.html.en 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

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 ads1.solocpm.com, the “BMPClickURL” parameter suggests that it was redirected from the domain of another ad-network -ams1.ib.adnxs.com – 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 “http://www.theguardian.com/uk-news/2014/may/06/boston-college-tapes-gerry-adams/clickenc=” (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 ads1.solocpm.com host, and of these, 90 were redirects from adnxs.com 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 altervista.org, apps.facebook.com and ebay.in (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

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:

/config.php
/img/
/img/index.php
/index.php
/js/
/js/index.php
/video_plugin.php
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.

Conclusion

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.

1 Comments.

According to the analysis of Cryptolocker done by Emisoft back in September (http://blog.emsisoft.com/2013/09/10/cryptolocker-a-new-ransomware-variant/), 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.
Ted

Some of the individuals posting to this site, including the moderators, work for Cisco Systems. Opinions expressed here and in any corresponding comments are the personal opinions of the original authors, not of Cisco. The content is provided for informational purposes only and is not meant to be an endorsement or representation by Cisco or any other party. This site is available to the public. No information you consider confidential should be posted to this site. By posting you agree to be solely responsible for the content of all information you contribute, link to, or otherwise upload to the Website and release Cisco from any liability related to your use of the Website. You also grant to Cisco a worldwide, perpetual, irrevocable, royalty-free and fully-paid, transferable (including rights to sublicense) right to exercise all copyright, publicity, and moral rights with respect to any original content you provide. The comments are moderated. Comments will appear as soon as they are approved by the moderator.