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).
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).
Exploit Kit Gate
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.
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.
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.
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.
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.
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.
Image seven: extract of a Wikipedia article explaining RC4 encryption algorithm
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.
Image eight: dropped jscripts by RIG EK (time difference: one week)
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 .
Image nine: virustotal detection on dropped jscripts by RIG EK
Rig EK gate sample (virustotal)
Rig EK landing page sample (virustotal)
Rig EK flash exploit sample (virustotal)
Rig EK dropped payload sample (Locky ransomware) (virustotal)
Rig EK dropped jscript (one)
Rig EK dropped jscript (two)
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)