I got my hands on a RedKit sample that was roaming around in January 2013. For the ease of referencing different samples I tag them based on the name of the class file specified in the <applet> tag of the kit's landing page. I have a suspicion the names might have some relation to RedKit code updates or campaigns as I've seen the class names being pretty consistent over some period of time. So far, I've seen the following names used: Ini, Runs, Gobon, Vlast and Application. So, the sample i was working on goes under a tag - 'Gobon'.
Where does it all begin?
It all starts with a landing page that has an injected <applet> tag with a location for the malicious JAR file, name of the .class file to start the execution with and a parameter that holds what looks like a set of random letters at first, but is actually an encoded URL for the initial payload.
Here is the break down:
'archive' - location of malicious JAR file
'code' - name of the class file to start the execution with
'name' - parameter name that will be passed with the JAR file to JVM
'value' - the value of the parameter passed
There were two <applet> sections in this particular sample and each of them had a set of individual items. The number of malicious <applet> tags on a landing page may vary. Possibly depends on the number of times the website has been compromised.
As seen in the snapshot above, the landing page has references to two JAR files - '332.jar' and '887.jar'. The names of the files have been changing since the first appearance of RedKit, but what seems to be consistent is that 1 of them carries exploits for Java 6 and the other for Java 7. In this particular case '332.jar' exploits Java 6 and '887.jar' Java 7 respectively. I've only encountered it once when both JAR files would be available on a compromised website. Generally, GET request for one of them receives 404 response.
Right after the malicious applet tags goes PluginDetect JavaScript(called 'Ganni' in this sample).
The script is not malicious, but it's wrapped up by the code that uses it to detect the version of Adobe Reader and depending on the result will pull a malicious PDF down.
So, there are two attack vectors on the landing page targeted at Java and Adobe Reader.
Update May 2013
Good inside look into RedKit server side operations covered by Fraser Howard / Sofos Labs.
Even more detailed analysis of RedKit server infrastructure by Kahu Security http://www.kahusecurity.com/2013/digging-deeper-into-redkit/
2010!? Seriously!?
Some exploits have a really long life span. For example, CVE-2006-0003 is still being used in Cool, BH, SweetOrange and CritXPack exploit kits. Keeping this in mind, appearance of CVE-2010-0188 in RedKit doesn't come as a big surprise. Specially crafted PDF file contains a JavaScript code that downloads an initial payload and execute it. For a better understanding on how JS fits into a PDF file and how PDFs are structured in general I'd recommend this article written by Didier Stevens.
The sample I used for this analysis was not the part of the RedKit instance mentioned above. This PDF file was a part of another RedKit captured in February 2013.
As with the JAR files, the names of the malicious PDFs have been changing too. This particular file is called '987.pdf'. Full analysis of it is available here. Object 2.0 contains a script that assembles and executes the exploit.
Variable/function names, 'padding' code and the way the code is being assembled changes from sample to sample. This particular code uses 'Title' field of the PDF document to build a JS expression. I used pdf-parser.py script to safely check the the 'Title' of the malicious document.
Function called 'ciiirsa' deletes every occurrence of 'XteTYS' in the 'Title' and returns what's left of it back. The result of this execution is the following code:
(eval(unescape(maallo.replace(/syt3tuir4 /g, gicyw.charAt(2))));)
When this expression is executed it will replace every occurrence of 'syt3tuir4' in 'maallo' string with a '%' sign. The end result is a string of characters that assemble the exploit code. Using 'Data Converter' tool from Kahu Security the string can be saved into a file. The resulting file is another JavaScript that contains some strings with hex code.
Using the same 'Data Converter' tool this hex code can be saved. The resulting file is the code that is executed upon successful vulnerability exploit. At the very bottom of the code is the URL where initial payload is fetched from.
Summary
This RedKit sample targets Oracle Java and Adobe Reader products. Exploits are delivered through a compromised website hosting pages with injected code. Attempt to exploit Java will be performed regardless of its version. Malicious PDF will be downloaded only after Adobe Reader version check is performed using PluginDetect script. JS exploit embedded into PDF file is obfuscated to avoid signature based detection.
