Pages

Thursday, 28 March 2013

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.

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.

Tuesday, 5 March 2013

RedKit Exploit Kit made its public appearance in the
beginning of 2012. The discovery was reported by Arseny Levin - a specialist at Trustwave SpiderLabs. I couldn't find any solid information pointing at the origins of the exploit kit, but i strongly believe it was more likely developed by Russian cyber criminals or at least Russian speaking ones. This assumption is based on the fact that RedKit Customer Control Panel and its FAQ are written in Russian.

RedKit is no different to the majority of Exploit Kits in regards to distribution mechanism. It has a landing page, exploit files (JAR/PDF) and an initial payload. The way these components stick together has been changing since the original release of the exploit pack and more likely will continue to do so. As an example, RedKit used to use a very popular technique of applying JavaScript obfuscation for its landing page to 'hide' GET requests for the JAR files and the script for checking version of Adobe Reader or Acrobat installed on a machine. Now, most of the time the GET requests and the script are plain text. Similar change happened to the Java byte-code files, where original Java class files were protected by a commercial product called Allatori and now they are obfuscated by something else that in my opinion is easier to reverse-engineer. It is not clear from the original report if RedKit used TDS(Traffic Distribution System) at the time. Samples I have come across of were all utilizing some sort of TDS.

In September 2012, authors introduced a new payment option - 5% of the traffic. 'Customers' willing to use this option required to have traffic from US, CA, GB or AU though. Some treated this move as an indication of the project loosing revs and opened speculations of its end. Further lack of activity from the authors strengthened the speculations, but in November 2012 RedKit made a new big entry. The event was premeditated and well planned. Denis Laskov described it in details in his blog.

The below are known indicators of RedKit components. The list is not comprehensive.

TDS:

Number of different TDS were seen paired with RedKit. The most 'popular' ones are SimpleTDS and SutraTDS.