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.
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):
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.
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.
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
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.
The diagram below provides an overview of the above information, summarising how Redkit infects victims with malware.
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.
6 comments on “A closer look at the malicious Redkit exploit kit”
"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.)
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!
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.
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*).
In some samples, the Key and IV are ASCII strings that need to be converted to hex before running the decryption command in OpenSSL.
JAVA is nothing but a big joke… dont use java… I uninstalled java long time back