Overview
Happy belated birthday to RIG exploit kit! First seen around April 2014, RIG has been in the news several times over the past year. In February, the source code was
reportedly leaked online, which likely spurred some of the recent changes we've observed in the kit. ThreatLabZ has been keeping an eye on RIG and in this post we'll cover an example of a full RIG infection cycle.
Delivery
In the past, RIG used malvertising and compromised sites to send users to RIG landing pages and we've seen no change in this tactic. Compromised sites leading to RIG usually contain an iframe in the page header that loads a RIG proxy domain, which also contains an iframe leading to the RIG landing page. The full infection cycle is shown in the annotated Fiddler session below.
 |
| Fig 1: RIG Infection Cycle |
In this example, the compromised site actually contains three different malicious iframes in its header. These iframes correspond to line items 37-39 in Fig 1.
 |
| Fig 2: iframes on Compromised Site |
Out of the three RIG proxy iframes on the compromised site, only one, sunfuji[.]com, is still redirecting victims to RIG landing pages. Much like the iframe on the compromised site, the RIG proxy page contains an iframe redirecting victims to the actual landing page.
 |
| Fig 3: RIG Proxy Redirects to RIG Landing |
Note that the RIG proxy is a persistent redirector, which will change the landing page location arbitrarily. Taken at a different time, the same page returned the following result:
 |
| Fig 4: RIG Proxy Changed Landing Page |
Landing Page
The landing page has multiple consistent attributes, starting with the URI. Every RIG landing page URI starts with a question mark, followed by 171 characters. Two examples are below:
- four.pavementexpress[.]org/?xH6Af7ieJRvHDIs=l3SKfPrfJxzFGMSUb-nJDa9GPkXCRQLPh4SGhKrXCJ-ofSih17OIFxzsmTu2KV_OpqxveN0SZFT_zR3AaQ4ilotXQB5MrPzwnEqWwxWeioWBrxaIYwMU95LEQOdviwijm7VFJMonk0DRvWcDnrtMU0gbrA
- trip.slotsbid[.]com/?xniKfredKx_HCYY=l3SKfPrfJxzFGMSUb-nJDa9GPkXCRQLPh4SGhKrXCJ-ofSih17OIFxzsmTu2KV_OpqxveN0SZFT_zR3AaQ4ilotXQB5MrPzwnEqWwxWeioWAqBHbYw1MrcOTEOcz0Aj2yeVBd892zxWA4GMBmL5MVUgbrA
The landing page itself contains three blocks of obfuscated code along with some portions of text from a popular CNET article. The majority of the code is actually a long list of character-delimited strings that are passed to a function that basically splits them on the delimiter and runs 'fromCharCode':
 |
| Fig 5: Top of the RIG Landing Page - strings use 't' delimiter |
The decode function for each of the three code blocks immediately follows the set of character-delimited strings, as shown in Fig 6.
 |
| Fig 6: Decode function for first set of character-delimited strings |
The deobfuscated first block of code attempts to detect known virtual machine characteristics and other attributes that might indicate an analysis environment. If anything is found, the next two code blocks are not deobfuscated or executed.
 |
| Fig 7: Code block 1 deobfuscated - detect analysis environment |
The second code block is a large base64-encoded VBScript segment:
 |
| Fig 8: Code block 2 deobfuscated - vbscript |
The VBScript is executed from the following code:
function time() {window.execScript(base64_decode(scriptvar), "VBscript");}setTimeout(time, 3001);
Once executed, the VBScript exploits CVE-2014-6332, the so-called 'Godmode' exploit (
VT detection - 4/57). AV detection tends to be particularly bad on the VBScript even though the code very closely matches the proof of concept originally publicized. There is a
good writeup from TrendMicro, which delves into the details of this vulnerability. If exploitation is successful, the encrypted exe is downloaded, decrypted, and executed on the system. The encryption key for the binary is conveniently in cleartext within the VBScript:
If objHTTP.Status = 200 Then
Set objFile = objFSO.CreateTextFile(strSaveTo,True)
objFile.Write EnDeCrypt(ByteArray2String(objHTTP.responseBody), "nkiOaWsg")
objFile.Close
End If
The third block of code simply serves up a malicious SWF with no secondary obfuscation:
 |
| Fig 9: Code block 3 deobfuscated - malicious SWF |
This code is almost the same as in other exploit kits, and the URL of the encrypted binary is being passed to the SWF as a parameter. The exploit in this case was
CVE-2015-0313, which affects Flash versions prior to 16.0.0.305, and the exploit code is contained in a script called 'wow.'
Detection on VirusTotal shows 10/57, and there are several public writeups on this vulnerability.
Payload #1 - Injector
The binary payload is encrypted with an 8-byte key, which you can guess from the stream or retrieve from the deobfuscated VBScript.
 |
| Fig 10: Encrypted Binary - key is 'WsgnkiOa' |
VirusTotal detection is a bit better than 50% for this payload at 32/57. The binary file is a Nullsoft Installer self-extracting archive and extracting the archive reveals three files inside:
 |
| Fig 11: Extracted Files from EXE |
In addition to these three files, another executable 'b8.exe' is dropped. Once the installer finishes dropping files, it loads the DLL (
15/55 on VirusTotal) and begins executing functions to read in the other two files. The file '6ag1rqashtwqw1hgqa' contains data XOR'd with the first 10 bytes of the filename, and the decrypted contents reveals several API calls that give us an idea of what will happen next, for example CreateProcessA, WriteProcessMemory, and ResumeThread.
 |
| Fig 12: Decrypting file data with filename |
Similarly, the 'Stevie Nicks' .m3u is unfortunately not actually a playlist, but instead an encrypted binary that is decrypted by the DLL using the XOR key "ZhmGqqKwXmJiiS7dzjzPyyaTw0PANF".
 |
| Fig 13: Decrypting 'Stevie Nicks' playlist binary |
VirusTotal detection on the decrypted Stevie Nicks binary is 35/56. Ultimately, this leads to creating a hollow process of itself (process hollowing -
PDF) which then creates an explorer.exe process and injects code to beacon to the Command & Control (C&C) server. Beacons were frequent and used the URI string '/power/logout.php' to POST to the domain 'starpowerss.com'
 |
| Fig 14: C&C Traffic Sample |
Other notable activity includes:
- Copying to 'C:\Program Files\Common Files\Windows Search 5.3.10\<random>.exe'
- Using the registry for persistence
- Hooking ZwOpenFile and ZwOpenProcess
- Clipboard control
Payload #2 - Blue Bot
After quite some time, a second payload is downloaded named 'cfajrs.exe' from 'a.pomf.se' which beacons to 141.138.157.240. Four URIs were observed:
- /help/proxy
- /help/blog
- /help/botlogger.php
- Returns div of HTML with "visitors online" (see Fig 15)
- /help/target
- Returns 'STOP|STOP|STOP' during analysis (see Fig 16)
 |
| Fig 15: /help/botlogger.php response |
 |
| Fig 16: /help/target response |
VirusTotal detection is 41/56 and indicates this is part of BlueBotnet. Looking at the binary, we see it's a .NET executable and uses no obfuscation at all to make decompilation difficult. Looking at the namespace and classes confirms this is called 'Blue_Botnet' and appears to be a DoS tool.
 |
| Fig 17: Blue_Botnet Code Overview |
One of the more interesting functions is the 'updateTarget' function, which expects a pipe-delimited list of IP, port, and method. There are multiple different methods accepted for the 'target' command: UDP, TCP, SYN, MCBOTALPHA, HTTP, HTTPROXY, PRESS, and STOP.
 |
| Fig 18: Blue_Botnet updateTarget Function |
To perform its attacks, the bot has a list of 37 different user agent strings to make detection more difficult (
paste of user agents); each request uses a different user agent from the list so requests look like they are coming from multiple different clients instead of from the same source. There is an Italian-language theme to the code, both in some of the variable names and in some of the HTTP headers, for example the Accept-Language header in the HTTP attack function shown below.
 |
| Fig 19: Blue_Botnet HTTP Attack Function |
Interestingly, the response from botlogger.php is not used in the code and the request may simply be a beacon to the server to keep count of infections.
Conclusions
RIG continues to be a popular and effective exploit kit choice and has evolved over the past year, indicating active development. While other exploit kits are moving toward ransomware and adfraud for monetization of infected victims, RIG is apparently not following this trend and still pushes more traditional malware. ThreatLabZ will continue to monitor RIG for any new developments. For a look at the infrastructure supporting RIG,
Trustwave has a great post on the topic.
Posts
