A closer look at the malicious Redkit exploit kit

In my previous article on the Redkit exploit kit, I provided an overview of how the kit operates. Specifically, how the attack uses a network of compromised web servers to serve up the redirects and malicious content.

In this article, I will take a closer look at the malicious content used to infect the user with malware.

Payload URL

The landing pages used by current versions of Redkit are pretty simple, consisting of just a tiny web page that loads up the malicious Java content. A single param attribute is used to pass in an obfuscated URL (underlined) to the Java code:

This string is retrieved and decoded (simple character substitution):

Security bypass

As noted previously on Naked Security, there have been several recent vulnerabilities in Java that are being targeted by exploit kits like Redkit. In a successful attack, security mechanisms will be bypassed and the malicious payload silently downloaded and run.

The specific vulnerabilities that are being targeted in Redkit change quite regularly, but have recently included:

• CVE-2013-1493. Has been spotted previously, but not seen in current JARs.
• CVE-2013-2423
• CVE-2012-1723

The JNLP file referenced in the landing page (above) reveals a security bypass that is being used by several of the active exploit kits. The attacks make use of an undocumented parameter (__applet_ssv_validated) to bypass security restrictions, and enable silent (no user prompt) execution of an unsigned applet.

Payload download

The file downloaded from the payload URL is actually AES encrypted. Clues to the use of AES litter the Java code, despite various attempts to obfuscate the intent. For example, reversing the Cipher transformation string:

Sure enough, looking at the downloaded file, it is easy to confirm that it looks encrypted or encoded in some way (it is not a regular Windows executable at least!):

Of course, to infect the user, the Java has to decrypt the file first. Elsewhere within the code is the necessary decryption key (and iv parameter):

Using these we can manually decode the encrypted file:

openssl enc -d -aes-128-cbc -in <in_file> -out <out_file> -K <decryption key> -iv <iv parameter> -nosalt -nopad

Multiple payloads

The Java code does not simply decrypt and save/execute the downloaded file however. There is an additional block of code that inspects the decrypted stream, hunting for a string that is used as a marker.

The purpose of this mechanism is evident a little lower down in the code.

So, if the marker is found, the if condition is false, and two executable files are extracted from the decrypted stream and executed. If the marker is not found, only a single payload is present, and just that file is executed.

Looking at the decrypted file obtained from a recent Redkit payload, the marker is indeed present (highlighted in red), sitting between the two executables that the user is infected with (scareware and a data stealing Trojan).

This mechanism enables the Redkit exploit kit to infect the victim with up to two payloads in a successful attack. The mechanism could easily be extended to allow even more. Of course, this does not really make the attack “worse” – once any machine is infected with a single payload, it is common for that to download and execute others. Nonetheless, it is an interesting feature to note.

Overview

The diagram below provides an overview of the above information, summarising how Redkit infects victims with malware.

Summary

In these two posts on the Redkit exploit kit I have described the key characteristics of the kit. The most interesting of these are:

• use of a network of compromised web servers to “host” the kit
• proxy malicious content (landing page, JAR, payload) from the C&C server to the victim via a compromised web server
• download payload(s) in encrypted (AES) form
• enable infection of 2 payloads in a single attack

To conclude, a few points concerning how users can best protect themselves from this (and similar) attacks.

To start with users or organisations need to consider whether their machines are vulnerable to the exploits being used (just Java in the case of Redkit, at the time of writing).

Do you have Java installed? Do you actually require it? If not, remove Java from your browser.

If you do need Java, ensure you are fully patched, and running the latest version.

In terms of security software, regular good practice should be followed.

In short, use a reputable security product which is up to date.

Additionally, ensure the available functionality within that product is enabled (web reputation filtering, web content scanning, cloud protection, memory scanning, runtime protection/HIPS).

All of these features are designed to provide layered protection, which is crucial for effective protection against drive-by download attacks delivered from exploit kits like Redkit.

Image of red eye courtesy of Shutterstock.