3ROS exploit framework kit – one more for the infection road!

Browser exploit kits are used on a large scale to infect systems in an automated manner. 3ROS is a new entry in the world of exploit kits: another piece of crimeware designed to ease the process of carrying out infections on the Internet. The 3ROS exploit kit has some advanced operational functionalities including a very sophisticated design from a GUI perspective. The name ‘3ROS’ appears to have been taken from Diablo III Reaper of Souls [1], an action game published by Blizzard Entertainment. Researchers from Proofpoint have recently written about the Hunter exploit kit [2], which they believe is a rebranded version of the 3ROS exploit kit. In terms of layout, the two exploit kits do indeed look similar. We have been following the 3ROS exploit kit for the last four to five months, and it is quite possible that the same author has transformed 3ROS into the Hunter exploit kit. However, since the Hunter exploit kit is based on 3ROS, we prefer to discuss the design of the latter, because it is the primary source. In this article, we discuss 3ROS version 1.0.0.

We believe, based on indicators including the language and terminology encountered during the analysis of the 3ROS exploit kit, that it is of Russian or Ukrainian origin. We also discovered the dedicated domain 3ros.io, which we assume was for selling the exploit kit. The Whois record for the domain lists its IP location as Kiev (see Figure 1), although the domain no longer resolves.

Figure 1. Whois record for the 3ros.io domain.

In addition, when we looked at the infection statistics (shown in Figure 2), we noted that there were no infections in the Russian/Ukrainian region despite other large countries being targeted.

Figure 2. 3ROS infection statistics.

In the following sections, we concentrate on the 3ROS exploit kit’s exploit generation and delivery process.

3ROS provides attackers with a very smart exploit generation functionality. It has a well designed GUI that makes the steps involved in creating an exploit very straightforward. The process is as follows:

Exploit selection phase

A number of exploits are provided for the ‘exploit selection’ phase; the attacker can pick his/her preferred exploit from a selection box. Figure 3 shows the exploit generation component, in which a number of Internet Explorer, Mozilla Firefox, Adobe Flash, Oracle Java, etc. exploits are available.

Figure 3. Exploit selection component.

Malware selection phase

Once an exploit has been selected, the next step is to upload the malware that will be downloaded onto the targeted user system after successful exploitation. 3ROS gives full control to the attacker to build the same exploit with different malware binaries including bots, advanced spyware, ransomware or other (malicious) binaries, depending on the attacker’s specific needs. Figure 4 shows the malware selection component.

Figure 4. Malware selection component.

Shellcode selection phase

The exploit kit also provides the option to select a variety of shellcodes, as shown in Figure 5. The shellcodes can be selected as follows:

• For cases in which the attacker is more interested in gaining control of the compromised machine than in delivering malware, the exploit kit supports shellcodes for the direct binding of a shell on the provided port, executing a reverse shell, and adding an unauthorized account to the compromised machine. The attacker can easily configure the shellcode arguments for all the shellcodes by supplying information as required by specific network environments.

• If the attacker is interested in delivering and executing malware on the target system, the malware binary selected in the earlier malware selection phase is used together with ‘Download&Execute’ shellcode, which simply downloads the malicious binary on the target system and executes it after successful exploitation of the vulnerability in the targeted component in the browser.

Figure 5. Shellcode selection component.

Anti-detection check phase

Once the shellcode has been selected or a binary has been generated, the 3ROS exploit kit provides the functionality to check the effectiveness of the shellcode/binary against anti-virus engines and other detection tools. The anti-detection component is already embedded in this process; it is thus easy for the attacker to check whether the shellcode and malware binary can be detected. The attacker first checks the shellcode (including binary) against all anti-virus engines using the exploit kit’s built-in functionality. Like the majority of exploit kits, 3ROS uses the anonymous AV checker service Scan4You [3] to validate and verify the detection rate of shellcode including malware binaries. If the malware is found to be detected, 3ROS provides a File Update (FUD) service, which can be used to ‘update’ the malware binary so that it can no longer be detected by AV engines. There is an ‘Undetect’ option for this purpose. Figure 6 highlights the various options that are provided as part of the anti-detection check.

Figure 6. Malware and shellcode binary anti-detection verification.

Domain selection phase

Once the AV check has finished, the final step, as seen in Figure 7, is to provide the domain information (primarily the domain name) relating to where the exploit will be hosted. Once this step has been completed, a new task appears on the dashboard, as shown in Figure 8, showing that the exploit is ready to be served.

Figure 7. Domain configuration component.

Figure 8. Exploit task generation.

The 3ROS exploit kit has a well designed notification system to tell its customers about updates such as the inclusion of new exploits, the addition of FUD services, etc.

In this section, we discuss, step by step, how the 3ROS exploit kit delivers an exploit to the target system. The exploit serving URL is distributed to the targeted user via a spear-phishing email with a message that is crafted by the attacker in a sophisticated manner using social engineering tricks. Let’s look in detail at what happens when the target clicks the embedded link pertaining to the 3ROS exploit kit.

Step 1: Once the link is clicked by the target, the browser lands on a page with the structure ‘http://www.example.com/task/mtask/index.php’. The browser tries to fetch the resource from 3ROS’s main handler website to perform the next step. 3ROS sends the HTTP response shown in Figure 9 back to the browser.

Figure 9. Pre-exploit delivery verification of plug-ins.

Step 2: The response received from the web server performs fingerprinting of the browser plug-ins, extracting the version number in order to determine whether the installed version is vulnerable against a specific vulnerability whose exploit is embedded in the exploit kit. Figure 10 shows that the Flash component (‘DetectFlash.js’) information is extracted through the browser using PluginDetect [4], which is a standard JavaScript library used to retrieve information about plug-ins installed on a target system. The Java component (‘deployJava.js’) is used to extract information about the installed version of JRE. ‘deployJava.js’ [5] is a JavaScript file that is provided with the Java deployment toolkit to enable the browser components to retrieve information about installed JRE so that applets and Java programs can be executed as required. At present, all browser exploit kits use PluginDetect as a primary tool for gathering information which is further used to make robust decisions in the selection and serving of exploits on the fly. The JavaScript libraries are fetched from URLs with the following format:

Step 3: Once a vulnerable version is detected, the browser sends a request to fetch the exploit page (‘e20113544.html’), as shown in Figure 10. The request is accepted by the web server and the response is served to the browser.

Figure 10. Exploit delivery after verification of plug-ins.

Figure 11shows that the 3ROS exploit kit served ‘Song.jar’ files, which were actually Java files serving exploits in compressed format. Since the test environment was running an obsolete version of JRE, the exploit was successfully served and the targeted user system was compromised.

Figure 11. Jar exploit file.

Table 1 shows some of the exploits that are served by 3ROS.

The signature shown in Listing 1 can be used to catch specific exploits from the 3ROS exploit kit.

Alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (
msg:”Win32.Exploit.3ROS – Exploit Detection”; 
flow:established,from_client; 
content:”GET”; 
http_method;content:”/task/mtask/”; 
http_uri; fast_pattern; 
content:”Accept-Encoding: gzip, deflate”; 
http_header; pcre:”/\/task\/mtask\/(?:DetectFlash.js|deployJava.js|e20113544.html)$/U”; pcre:”/(?:Firefox|MSIE)/H”;
 reference:url,<Add Reference URL>; 
classtype:Exploit; sid:XXXXXXXXX; rev:1; )

Listing 1 : Signature to detect specific 3ROS exploits.

In this article, we have discussed primarily the design of the 3ROS exploit kit, covering specifically its exploit generation and delivery mechanisms, thereby highlighting different techniques deployed by the 3ROS authors to make the infection process smoother during drive-by download attacks. From a management perspective, the design of 3ROS is very advanced and one can expect that the same source code will be used in different ways to generate more variants.