Trustwave SpiderLabs Uncovers Unique Cybersecurity Risks in Today's Tech Landscape. Learn More

Trustwave SpiderLabs Uncovers Unique Cybersecurity Risks in Today's Tech Landscape. Learn More

Services
Capture
Managed Detection & Response

Eliminate active threats with 24/7 threat detection, investigation, and response.

twi-managed-portal-color
Co-Managed SOC (SIEM)

Maximize your SIEM investment, stop alert fatigue, and enhance your team with hybrid security operations support.

twi-briefcase-color-svg
Advisory & Diagnostics

Advance your cybersecurity program and get expert guidance where you need it most.

tw-laptop-data
Penetration Testing

Test your physical locations and IT infrastructure to shore up weaknesses before exploitation.

twi-database-color-svg
Database Security

Prevent unauthorized access and exceed compliance requirements.

twi-email-color-svg
Email Security

Stop email threats others miss and secure your organization against the #1 ransomware attack vector.

tw-officer
Digital Forensics & Incident Response

Prepare for the inevitable with 24/7 global breach response in-region and available on-site.

tw-network
Firewall & Technology Management

Mitigate risk of a cyberattack with 24/7 incident and health monitoring and the latest threat intelligence.

Solutions
BY TOPIC
Microsoft Exchange Server Attacks
Stay protected against emerging threats
Rapidly Secure New Environments
Security for rapid response situations
Securing the Cloud
Safely navigate and stay protected
Securing the IoT Landscape
Test, monitor and secure network objects
Why Trustwave
About Us
Awards and Accolades
Trustwave SpiderLabs Team
Trustwave Fusion Security Operations Platform
Trustwave Security Colony
Partners
Technology Alliance Partners
Key alliances who align and support our ecosystem of security offerings
Trustwave PartnerOne Program
Join forces with Trustwave to protect against the most advance cybersecurity threats
SpiderLabs Blog

RIG Exploit Kit – Diving Deeper into the Infrastructure

Following our previous blog post about the leaking of the RIG exploit kit's source code, we dug deeper into the architecture that facilitates the massive infections using RIG. The screen shot below diagrams RIG's infrastructure.

12587_f0225eda-27c0-42e4-9126-0dec65c09654
RIG Exploit Kit Infrastructure

Most commonly we see only the one end of this rabbit hole--the compromised site and the proxy server. Below we will detail what happens behind the scenes during the infection and explain how RIG customers use it to deploy their infection campaigns.

We weren't kidding about digging deep, so grab a cup of coffee because you may be here a while.

First thing first

RIG's infrastructure might look complicated, but it's rather straightforward for the customer who simply wants to infect victims and generate revenue. So, we'll start with the basics. For the purposes of our analysis, we'll take the perspective of a RIG customer that already maintains a backdoor on a popular web site and now wants to monetize that traffic. First, the RIG customer needs a URL to which they can redirect the traffic to exploit victims' machines.

RIG customer API - "api.php"

9490_5c1dbb41-1546-4c96-b5e7-7fa23fd7e6b2
RIG Customer API ("Get Link" button - generates customer's specific URL)

In order to infect victims, the RIG customer has to choose a payload and upload it through the admin panel – but we won't focus on this. Once the RIG customer uploads the payload, it makes sense that the next step would be pointing victims to the infection page. However, in order to evade detection by web filters and URL lists, the landing page needs to update regularly. RIG provides an API for this purpose that creates new, valid infection URLs on demand. Clicking on the "Get Link" button in the interface pictured above will provide the API URL. The URL will be in the following format:

hxxp://[RIG-Instance-Server]/api.php?apitoken=[API TOKEN]

The "API TOKEN" at the end of the URL is a unique key that combines the user's ID with the current "Flow ID" (pictured in Figure 2 below), serializes the combination and encrypts it using RC4 with a private key configurable only by the main RIG administrator. Each RIG user can have up to 2 distinct flows, which allows for infections via different payloads for each flow.

7940_0fa73029-bf61-42e1-a996-79fc636b1868
Code snippet that appends the API token

The PROXY Layer

The output of the URL above is the "PROXY" URL which functions as the "infection page". Here is an example of the structure of the "PROXY" URL:

hxxp://[PROXY Server]/proxy.php?PHPSSESID=njrMNruDMlmbScafcaqfH7sWaBLPThnJkpDZw-4|OTMxOGYwMjdkZTMxOGFmN2M5OWZkMDNjODE0MmMyODM

Every request to a PROXY URL (e.g., "index.php?PHPSSESID=…", "proxy.php?PHPSSESID=…", or more commonly just "hxxp://current-proxy-domain/?PHPSESSID=…") contains the token of a RIG customer for the specific campaign. Basically, all customers using the same RIG exploit kit server share the PROXY URL. Before we discuss the PROXY core, let's take a closer look at the URI generated by the "api.php".

The URI is divided into 2 parts separated with the character "|". Here's the first part from our example:

njrMNruDMlmbScafcaqfH7sWaBLPThnJkpDZw-4

This encrypted string is actually a URL for a different server that handles requests to load an exploit and send it back to the victim's machine. Let's take a look at how this URL is generated:

12742_f6a50ed1-14e8-49e4-a18f-6394839b9cac
Encrypted VDS URL code

To decrypt this content we need to use RC4 with the key and then use the function "base64url_decode". Here is the result of the string above, which is the VDS server that we will examine later on:

http://vdstomama[.]com/core.php

The second part of the URL structure is less exciting. The objective is to make sure the URL becomes invalid after a certain period of time - which is configurable by the RIG exploit kit admin; the default is 720 seconds (12 minutes). This technique is very effective because after 12 minutes the URL doesn't serve the exploits and is useless to security researchers trying to analyze such URLs.

10547_8edfccbe-7354-405f-90ee-1609d1ffbc43
Token generation code

The screenshot above describes the generation process of the token, which is a combination of the time, the user ID and the user login name all together with MD5 and later on with base64url_encode.

Now, let's get back to the place where the PROXY URLs are managed:

10251_7fd3130a-ff0a-4240-b9fb-6281bef7792e
Proxy list management

Only the RIG exploit kit administrator can manage this list. RIG customers have no control over it. The admin can bulk-load domains or load them one-by-one. This list functions as a queue using the first item (topmost) until anti-virus tools begin detecting it or it is no longer online.

On every RIG admin server, a scheduled task runs every 5 minutes to check the first active PROXY on the list:

11184_acd015cd-0695-4a59-b675-0bb9e2efbb80
PHP code to check the domains to be used as proxy servers

The domain is scanned by the "avdetect.com" service, and it is removed from the active list once it is detected as malicious. Additionally, if anti-virus vendors start to blacklist the PROXY server, then the RIG admin code will send the PROXY server a command to switch its assigned domain.

10427_88d033e6-80ee-421e-9a3f-e203a1d1824b
Proxy domains blacklisting code

The RIG administration server accesses the PROXY with a unique key along with the domain that should be removed. The domain is inserted into a blacklist file that is checked each time a victim is browsing the PROXY server.

The VDS Layer – Providing the landing page and exploits

VDS stands for Virtual Dedicated Server. VDS serves the role of an exploit generator. The main objective is to avoid detection by keeping those servers hidden from the world. According to records we've collected since August 2014, the RIG developers only used three different VDS servers.

First stage – fetching the landing page:

The first time the VDS is accessed results in the landing page content. The HTML/JS code itself is obfuscated using a function called CryptJS written by RIG's developers.

12079_d845c676-d33f-4340-bc83-c5a8c3cc90b6
PHP function obfuscates the malicious JS code

After obfuscating the code, RIG's developers take extra caution by encrypting all of the data sent to the PROXY to avoid detection by IPS or anything monitoring the traffic.

9330_544f402a-3846-404f-a28f-4cd99e695864
PHP code serving the landing page (+ notify the admin server)

After sending the content back to the PROXY as depicted in the screenshot above, the VDS reports back to the RIG admin server about the exploit attempt.

Second stage – fetching the exploits:

The landing page will check if the browser supports Java, Flash or Silverlight. According to the results of the plug-in enumeration code, the victim's browser will request the respective exploits.

The PROXY receives the request from the victim machine and delivers it to the VDS.

In order to request the appropriate exploit, the victim's browser will issue another request with a new parameter named "req". For example, if the value is "swf", the VDS server will send back the Flash exploit. For example:

hxxp://[redacted].ga/proxy.php?req=swf&num=8454&PHPSSESID=njrMNruDMlmbScafcaqfH7sWaBLPThnJkpDZw-4|OTMxOGYwMjdkZTMxOGFmN2M5OWZkMDNjODE0MmMyODM

However, unlike the plug-in exploits that are only served if applicable, the Internet Explorer exploit is served without any prerequisites, already in the first VDS response along with the initial landing page.

Third stage – fetching the payload:

After it's exploited, the victim machine requests the payload using the parameter "req" with the value "mp3".

9079_49228a19-85e1-4463-a092-0dce6e8b0004
Payload serving code

The VDS sends a request to the RIG admin server along with information about the victim machine and asks for the relevant payload that should be delivered.

The payload is pulled from the RIG admin server and encrypted using an RC4 key (a different key from the previous one) to avoid anti-virus detection.

7621_00e5d5c9-cfc5-49e1-a3cd-5ae31b7991a7
Encrypted payload

Since this key is less important, it is sent to the victim machine during the exploitation phase. The executable itself is decrypted on the victim machine, written to the file system and then executed.
For example, if the successful exploit is CVE-2014-6332 then the decryption phase looks like this:

10705_95829541-5eff-48da-b715-dff017e68924
Payload decryption (part of the exploits)

RIG Administration Server

The RIG developers planned the infrastructure as a layered structure: the RIG admin server is basically nothing but a control panel and does not proactively exploit victim machines. Therefore, the RIG admin server can function for a long period of time behind a service such as CloudFlare, unlike the proxies, which are replaced regularly.

The admin server provides RIG customers with full control of their malware campaign and does not require any specialized knowledge of the back end. The RIG customer only needs to (1) figure out how to spread the infection URLs (typically by compromising web sites with large volumes of traffic, or malvertising) and (2) ensure the payload is stable.

10244_7f7f03de-f627-40e4-83e4-38e17899210d
Payload management panel

Just like its competition, the RIG exploit kit provides complete statistics of the campaign's achievements.

9454_5a4d6d17-5b31-4a78-a69c-419e6acc4f51
Flow statistics

The screenshot above displays the main statistics page of the exploit kit. The overall exploitation rate for this specific "flow" is 14.7%. You can notice that the overall exploitation is divided between Flash and Internat Explorer exploits. Specific CVEs include: CVE-0214-0311 in Flash; CVE-2013-2551 in versions 7, 8, and 9 of MSIE; and CVE-2014-6332 in Internet Explorer 10. Additional information reported includes countries targeted, browser versions and OS.

The business model

Here you'll see an advertisment for the RIG exploit kit on a Russian forum:

7622_00e6284e-a438-4312-99e8-514e95db442f
RIG advertisement

This advertisement is aimed at customers that want to distribute their malware (payload) using the RIG exploit kit. The criminals behind RIG also established a reselling model, whereby each reseller can have their own RIG admin panel from which their own customers will deploy infection campaigns.

Thus far our research has shown at least two large resellers accounting for over 250 customers combined. We can only assume there are additional resellers. Nonetheless, in comparison to the main RIG admin panel, which provided services to about 360 customers, it becomes evident that the reselling model almost doubled their profit. The data we examined accounts for the period of time between August 2014 and February 2015.

12532_edaf1e10-e8d7-4e9a-9bbc-728281476fdd
RIG reselling model

Multiplying 600 customers by $150 (the price per week of use), we estimate that the RIG exploit kit could be generating up to $90,000 per week. This rough estimate doesn't take into account operational expenses or customers that pay with a portion of their infections (similar to the Magnitude exploit kit's model), but it still shows that exploit kits can result in a very nice profit for the developers.

Trustwave customers using Trustwave SWG or Trustwave UTM are protected against RIG Exploit Kit without the need for any further updates.

Latest SpiderLabs Blogs

Zero Trust Essentials

This is Part 5 in my ongoing project to cover 30 cybersecurity topics in 30 weekly blog posts. The full series can be found here.

Read More

Why We Should Probably Stop Visually Verifying Checksums

Hello there! Thanks for stopping by. Let me get straight into it and start things off with what a checksum is to be inclusive of all audiences here, from Wikipedia [1]:

Read More

Agent Tesla's New Ride: The Rise of a Novel Loader

Malware loaders, critical for deploying malware, enable threat actors to deliver and execute malicious payloads, facilitating criminal activities like data theft and ransomware. Utilizing advanced...

Read More