A closer look at the malicious Redkit exploit kit

Filed Under: Featured, Java, SophosLabs, Vulnerability

Red eye. Image from ShutterstockIn 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:

Obfuscated payload URL passed into Java

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

Java code to decode payload URL

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:

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.

Security bypass in Redkit

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:

Reversed AES/CBC/NoPadding 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!):

Start of encrypted, downloaded file

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):

Decryption key and iv parameter within the Java code

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.

Java code to check for marker in decoded file

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

Logic to save and execute one or two payload executables

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).

Decoded payload showing marker separating the two malicious executables

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.


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

Summary of Redkit exploitation process


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.

You might like

6 Responses to A closer look at the malicious Redkit exploit kit

  1. njorl · 886 days ago

    "an undocumented parameter ... to bypass security restrictions", AKA a back door!

    Java is surely the greatest practical joke ever perpetrated.

    Is it being listed as a PUP, yet? (We've certainly been sold one.)

  2. This, "(no user prompt) execution of an unsigned applet", is what makes life a little more *interesting*. It certainly motivates one to research, learn and not bop about without a care in the world. It a good feeling to be informed and do as much for yourself as you can to be careful and protect your investment. If one has money to burn then I could see just paying someone to mop up after yourself but this is not going to end. This is an ongoing dilemma that you don't want to fall behind and sit in the dark waiting and wondering. B.T.W. Thank you SOPHOS for being my online learning tool…at such a good price to boot! Free!

  3. Moe · 885 days ago

    Hello Fraser,

    Very informative deep dive. One question though: after locating the Key and the IV in the JAR file, to decrypt the file we need to run the openssl command described above. Is there another step after that? I have been trying to replicate the activity on a sample I have and after I run the decryption commnad, the sample still looks packed/encrypted. i don't see the "MZ"at the beginning of the file or anywhere for that matter?

    Any advice will be helpful.

    • Fraser Howard · 883 days ago

      The executable should be visible once you have decrypted, so check you have the correct iv and decryption key (*and confirm they are in hex*).

  4. Julian · 882 days ago

    In some samples, the Key and IV are ASCII strings that need to be converted to hex before running the decryption command in OpenSSL.

  5. Bruce · 748 days ago

    JAVA is nothing but a big joke... dont use java... I uninstalled java long time back

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

About the author

Fraser is one of the Principal Virus Researchers in SophosLabs. He has been working for Sophos since 2006, and his main interest is in web related threats.