A Wild Exploit Kit Appears... Meet RedKit

After signing up with your jabber account the authors behind this new project contact you and provide you with a demo account for their software. The author doesn't provide any "official" name for this kit so we'll refer to it as the RedKit, simply because they used a red coloring scheme. Logging to the admin panel presents you with options which are typically used by other exploit kits.

The panel allows you to check the statistics for incoming traffic, upload a payload executable and even scan this payload with no less than 37(!) different AV's.

Any aspiring cybercriminal who's looking to distribute some malware, will usually face a quest of acquiring three different resources for a successful botnet:

1. Exploit kit services
2. Traffic of unsuspecting victims
3. A payload exe - the file which will launch on the victim side upon successful exploitation.

Our promising cybercriminal will set up the traffic sources to redirect users to a malicious exploit kit page. Within a few hours, the number of infected clients will climb up on the admin panel for that attack and our ill-intended friend will fantasize about sipping ice cold beer on some sunny island with the expenses covered by his brilliant scheme. It will be a real blow for him when the these numbers stop climbing after 24-48 hours as the malicious URL is now recognized and blocked by most security vendors. The poor lad will have to go through the irritating process of contacting the exploit kit provider for using an updated malicious URL. Getting online with a helpdesk clerk is never a pleasant experience, surely not in this underground world.

Luckily, the authors of RedKit have solved this issue by providing an API which will produce a fresh URL every hour. How convenient! Any customer of this exploit kit can now set up an automated process for updating the traffic sources every hour or so to point to the new URL.
This basically means that people behind this project have invested considerable amount of resources and reserved a big batch of domains to use over a period of time. Just like in any other business, one has to put some money in order to generate more money and the profit is proportional to the initial investment.

The link circled in blue is the currently used malicious URL. The green one is a constant API URL which produces a fresh URL one every hour or so.

A Terms Of Service page is also supplied. The rules for business seem to be the same everywhere, even when the judge is not a person with 7 years of college and 20 more of law practicing, but just a guy that runs the forum where the business took place. Here is a translation of some key points:

The next step was to analyze and take apart the exploits it serves. The RedKit is armed with two of the most popular exploits but the authors probably will add more exploits soon in order to catch up with the "industry leaders" such as BlackHole and Phoenix exploit kits. The first exploit is a fairly obfuscated PDF file that exploits the LibTIFF vulnerability (CVE-2010-0188). An analysis of the PDF file, by the excellent wepawet service, can be found here.

This time we'll focus on the second exploit. We're talking about the latest Java exploit, dealing with the AtomicReferenceArray vulnerability (CVE-2012-0507). It is interesting to examine this Java attack, but not due to the vulnerability it exploits but due to the obfuscation used on the bytecode.

Until not long ago, Java exploits were much less common. The analysis of such samples was easy as well. As you probably know, Java is compiled to bytecode, which can be decompiled back to original source with tools such as JAD and JD. Yet, in the past year or so the bad guys started paying much more attention to Java exploits. Java is a very appealing target, since it can be found on your home desktop, on your mobile and even on many embedded devices. But even a sweeter treat are the vulnerabilities like AtomicReferenceArray that can be exploited with a shell-bytecode (bytecode that acts as the shellcode, but for the JVM), meaning exploitation will be successful regardless of the operating system! As evidence to this, you all saw Flashback hitting OS X in the past weeks with exactly the same vulnerability.

The fact that bytecode can be easily decompiled was less than comfortable for exploit kit developers, as it made detection logic as straight forward as searching for specific strings in the decompiled source. But the bad guys don't let go that easily and bytecode obfuscators become increasingly popular among java attacks.

Let's go back and take a look at the main loading page, serving obfuscated JavaScript – which is a standard for at least a few years by now.

After quick deobfuscation, we get to the code loading the PDF and JAR exploits. Notice the JAR is loading prior to the plugin detection code and without any version checks . Sloppy and unprofessional – I wouldn't pay for this product :)

The JAR contains several classes with meaningless names, such as the main class "tyu.class" (as seen in the figure above). The attempt to decompile tyu.class using JAD produces unreadable code:

Time for some creative analysis! First of all, I noticed that throughout the code there's a repeated use of a function named ALLATORI_DEMO. A quick Google search reveals that this is a commercial Java bytecode obfuscator. I sent the vendor a query about whether they have a deobfuscator for the good guys, but haven't received a response yet. No worries – we can manage without that response.

What you see in the screen shot above is a typical example of what happens during the self deobfuscation stage. Weird looking strings are passed as arguments to functions from a limited set of functions, including the mentioned ALLATORI_DEMO function, which return a String object. Now wouldn't it be great to just execute this function specifically for this input and see the result?? This is exactly what I did. Java supports loading compiled classes at runtime. There are two methods to do this, ClassLoader and Reflection. In this case reflection is the suitable method. An example with much more info on how to use Reflection can be found here.

At first sight, the resulting "decoded" strings still didn't make much sense. But after some further analysis of the bytecode, there was a piece of code that stood out. It looked like a loop which was intentionally obfuscated, and that loop dealt with some of the previously decoded strings. Unfortunately due to obfuscation, the loop wasn't stored as a single callable function and thus reflection won't be much of a help in this case. The bytecode of the loop:

After tracing this code for a couple of times, it was easy to reconstruct the original loop source. The loop takes the decoded strings, one of which is passed using the "param" HTML tag, and recovers the original string that the authors wish to hide. Here is the reversed loop in JavaScript syntax:

'key3' and 'key4' are two of those strings mentioned earlier which were decoded by the ALLATORI_DEMO function. 'paramStr' is the parameter passed from the parent HTML and decoded by an auxiliary function (such as ALLATORI_DEMO). This exhibits a key-lock relation between the parent HTML page and the JAR file, as the java applet won't execute properly without the decoding key.

The final resulting string is a URL of the payload executable file. A further analysis of the bytecode clearly shows the use of AtomicReferenceArray vulnerability in order to run shell-bytecode that downloads the exe file from this URL and executes it on the victim's machine.

During the last several weeks we witness a disturbing rise of campaigns based on the RedKit in the wild. Fortunately, all customers of our Secure Web Gateway are protected by default from these attacks.