RIG Exploit Kit

[TheCount.]

RIG Exploit Kit Overview

The following image shows an example of an iFrame which has been injected into a compromised website.

The iFrame redirects users to a proxy that hosts the RIG exploit kit landing page.

 

 

The RIG infrastructure itself, as shown below, is optimized to segregate servers that host the landing page, exploits and payloads. Victims are only able to see the proxy server with the landing page; resellers and customers are only able to work with the admin server. The actual exploits are stored on the VDS under custody of the RIG crew [2].

 

 

 

 

 

After the user is redirected to the proxy, it attempts to exploit the victim’s machine if it is using outdated components such as Adobe Flash. If successful, the RIG exploit kit will then drop and execute CrypMIC ransomware onto the machine and encrypt all files silently in the background. CrypMIC ransomware is still fairly new and it wants to follow the footsteps of the very popular CryptXXX ransomware. It can encrypt 901 different types of files to which it doesn’t add an extension unlike for example Locky, where .locky is added to the end of each file making it easier to detect [3,4]. This ransomware is particularly dangerous for business organizations because of its ability to encrypt files on removable and network drives. During encryption, the ransomware replaces the user’s wallpaper with the one shown below.

 

 

 

 

 

The image states that RSA-4096 is used for encryption when, in fact, research has shown that CrypMIC uses AES-256 [3,4]. The same information is placed in the form of pictures and text files into every folder that is encrypted. The amount of ransom demanded varies from 1.2 to 2.4 bitcoin, that is between $792 and $1,597 [5]. The user is being prompted to download TOR, a network that disguises their identity by moving traffic across different TOR servers and encrypting that traffic, and visit a payment page similar to the one shown below. After payment is received, the victim is supposedly able to download the “Microsoft Decryptor” (please note that this tool has nothing to do with Microsoft).

 

 

                                                                                    

 

 

As with all ransomware, the delivery of a decryptor tool and therefore the successful decryption of files is not guaranteed. The question of whether to pay or not to pay has been discussed rigorously throughout the industry. The recent articles about ransomware payment by Nettitude, Kaspersky and Sophos, to name but a few, all have a similar tone: there is no guarantee that the cyber criminals will deliver the key that is required to successfully decrypt the files and in many cases the data is irretrievably lost. It is therefore strongly advised that payments should not be made [6, 7, 8].

 

Intrusion Detection Systems, such as Snort, provide signatures for the RIG exploit kit. The signature ID for Snort is 33905

. The following rule is associated with the SID:

alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"EXPLOIT-KIT Rig exploit kit outbound commu
nication"; flow:established,to_server; urilen:>220,norm; content:"/index.php?"; depth:11; http_uri; c
ontent:"=l3S"; within:4; distance:15; fast_pattern; http_uri; pcre:"/^\\/index\\.php\\?[A-Za-z0-9_-]
{15}=l3S/U"; flowbits:set,file.exploit_kit.flash; metadata:impact_flag red, policy balanced-ips drop,
policy max-detect-ips drop, policy security-ips drop, service http; classtype:trojan-activity; sid:3
3905; rev:3;)

 

 

The rule looks for a connection from IP’s defined in the variable $HOME_NET  to IP’s defined in the variable $EXTERNAL_NET on port 80. It will only match URI’s that are greater than 220 bytes.

 

 

The image below shows an example of a malicious string that matches the Snort signature.

 

 

 

 

 

As mentioned above, the exploit kit injects iFrames into compromised websites to redirect users to a proxy. A comparison of several packet captures containing the RIG exploit kit has shown that the iFrame redirection after the URL is always between 169 and 175 bytes long. The first 16 bytes are truly random characters that change with every iFrame injected into a website. The next 24 bytes are random characters as well, but the comparison has shown that these characters remain the same. The remaining bytes are randomly generated, dependent on the actual payload that is being delivered. More random characters are added on, resulting in a string that is always larger than 220 bytes.

 

 

 

 

To reduce the possibility of false positives, the IDS/IPS rule is very specific by looking for the string index.php?  in the first 11 bytes of the payload, then ignores the next 15 bytes and then looks for the string =l3S  The string  =l3S however, has to match within the next 4 bytes.

 

As security professionals, we have to investigate this alarm, as well as any associated alarms, to determine whether the exploit kit was successfully delivered and executed. A good way to start an investigation is to look up the IP address at VirusTotal (virustotal.com). However, the IP’s change so frequently that the result of VirusTotal alone should not be taken as an indication for success or failure. As a next step, a search for the IP address using URLQuery (urlquery.net) provides a good indication as to whether the IP has been flagged as malicious. Furthermore, URLQuery will show you a screenshot of what the actual website looks like without resolving the IP on your machine and potentially risking an infection. As the image below demonstrates, the website has been associated with the RIG exploit kit.

 

 

 

 

A packet capture helps us to investigate this alarm further. The website malware-traffic-analysis.net provides some packet captures that show the delivery of the exploit kit from the exact same IP addresses that we have observed in the last two weeks [10].  A look at the packet capture provides some useful information about the computer that has been infected with the RIG Exploit Kit.  If we take a closer look at the User-Agent above, we can see that the victim is running Windows 7 (Windows NT 6.1) and an outdated browser, Internet Explorer 8. Additionally, we can see that the victim is using a vulnerable version of Adobe Flash by looking at the x-flash-version, which indicates a version of 11.9.900.117. A quick search for Adobe’s Security Bulletin reveals that Adobe has released security updates for Adobe Flash Player 11.9.900.117 and earlier versions [11].

 

 

 

The HTTP object list in the image below shows the content types that are transmitted; application/x-msdownload is associated with .exe and .dll files, while application/x-shockwave-flash is related to Adobe Flash.

 

 

 

 

We have already identified that the victim was running a vulnerable version of Adobe Flash which was exploited to deliver the malicious payload. The image below shows post-infection traffic to 65.49.8.96 and the same IP has been observed throughout various packet captures related to CrypMIC ransomware.

 

 

 

 

 

At this point, we can conclude that the user has visited a compromised website and was redirected to the proxy server. An outdated version of Adobe Flash was identified and exploited and the malicious payload was successfully dropped and executed. As a result, all files on the hard drive were encrypted and a ransom demanded.

Without having a packet capture, it is relatively hard to determine the actual success of the delivery of ransomware but an outbound connection to a known malicious site should always be an indicator of success. If the host wasn’t infected it wouldn’t need to communicate to that IP address.

As a countermeasure we would recommend, if possible, taking the infected host offline, scanning it for malicious software and blocking the IP address at the perimeter firewall. Blocking the IP alone is not an effective countermeasure because it does not treat the root cause of the problem: a potentially infected host. At this point it doesn’t matter whether the request to the potentially malicious site was blocked by a proxy or a firewall; the fact still remains that there is a host on a network that is actively trying to establish an outbound communication to a malicious site.

 

 

Conclusion

 

Ransomware has become one of the most feared cyber threats in recent years. The FBI predicts a total loss of around 1 billion US dollars caused by crypto-ransomware in 2016 [12]. CrypMIC was neither the first ransomware, nor will it be the last but it shares the common goal: extort money. Ransomware targets everyone. The same attack can harm an international organization as well as a local restaurant or private Internet users. Ransomware is usually only detected after the malicious software has been installed and files have been encrypted making an early detection all the more important. Intrusion prevention systems can trigger and block a predictable chain of events that happens during the Diffie-Hellman key exchange. If you are able to block the key exchange, you can avoid that files are being encrypted because the ransomware won’t progress beyond this point. Ransomware continues to be one of the biggest cyber threats and we cannot simply rely on detecting ransomware from one single source. Instead, we must deploy a comprehensive solution: proactively monitoring traffic and logs to detect ransomware as early as possible.

 

thecount.