Private EK: "Well.. hey, hey... I wanna be a rockstar..."

Thanks to @Set_Abominae for sharing this sample.

NOTE: Information is based on a sample captured on 2013-06-26

UPDATE: 2013-07-05. This kit appears to be 'Private Exploit Kit'. Thanks to @kafeine for help identifying it and clarifying a few things.

"Born to crawl will never fly"

The following URL pattern has been seen:

The landing page is being transferred 'chuncked' using GZIP as a content encoding method. Chunked Transfer Encoding is supported by HTTP 1.1 standard. Its main feature is to use 'Transfer Encoding' HTTP header instead 'Content Length' one to allow dynamically-generated content to be transferred before knowing the total size of that content. The landing page is being generated 'on-the-fly' based on browser's UA - defines what exploits to include. For example, CVE-2013-1347 will be included only if IE8 is detected, the same goes for IE6,7 and CVE-2006-0003. 'Chunked' transfer also allows to 'hide' the content of the landing page.

The HTML code is unreadable for a human eye.

part of 'chunked' HTML code

HTML page is simply being transferred as a GZIP archive that is automatically processed/extracted by the browser. If the page is reassembled from a PCAP file any archiving tool that supports GZIP can be used to unpack it. Once extracted, it appears to be fairly obfuscated. The following algorithm makes it more readable.

It uses 'indexing' technique where a string of characters is constructed based on a 'character index value' in a predefined string. Character index value is calculated using an algorithm and another predefined string of characters. RedKit EK uses the same technique. The only difference is the algorithm to calculate the 'character index value'.

"Where no one has ever been before... NOT!"

'document.write' is tossed the deobfuscated code that will launch PluginDetect script to check for versions of Java and Adobe Reader installed.

There is no code branch when Adobe Reader is detected(work in progress?), but there are three branches for when Java is detected.

• first branch is for Java 6 version 1.6.27 and lower
• second branch is for Java 6 version between 1.6.28 and 1.6.41
• third branch is for Java 7 version 1.7.17 and lower

JAR file URL path depends on the branch taken. Java 7 branch requests JAR through JNLP file.

Taken code branch will create a new <applet> element and append it to the main 'document'.

<applet> sample for a Java 6 branch

There is some simple obfuscation applied on the strings holding the URL location for the JAR file and the parameter passed to JVM. There isn't any fancy algorithm used to deobfuscate them - they are simply 'reversed' and '#' character is removed.

Since JNLP file for Java 7 branch is enclosed into <applet>, it's encoded with Base64. After using Kahu Security's Converter tool, decoded JNLP file reveals the JAR file and additional parameter details.

Sense of humor or pure overlook by authors, but applet's name might make you smile.

"Jam in a JAR"

NOTE: The malicious JAR file details outlined below are for Java 6 '1.6.27 and lower'.

The JAR file contains only 1 class file that is armed with an exploit code for CVE-2011-3544 - 'Oracle Java Applet Rhino Script Engine RCE'. Rhino is a JavaScript implementation that has a way of interacting with Java code when executed within an applet. Doing some crafty manipulations with 'this' object, 'toString' method and Java error handling it's possible to disable Java Security Manager. Michael 'mihi' Schierl explains this vulnerability in great detail in one of his posts.

Decompiled Java code is not obfuscated - at most the values of the string variables are reversed and in some cases padded with a simple pattern.

Reflection methods are used for the exploit part.

'str7' in the snippet above hold the JavaScript that sets the Security Manager to 'null' - disabling it.

assembled JavaScript

JavaScript calls 'start()' method that will identify user's Temp folder location, generate a random filename for the initial payload, download and execute it.

'C:\Users\user\AppData\Local\Temp\3fef61ce8112d381.exe'

filename and location example

"Summary"

In overall, this exploit kit is relatively simple. Judging by the incomplete parts, some naming through the landing page, JNLP and Java code the authors are still working on it. Major points to note:

• uses relatively unique URL pattern
• landing page is transferred 'chuncked'
• landing page is dynamically generated depending on browser's UA
• uses 2 layers of obfuscation to hide the content of the landing page
• utilizes 'PluginDetect' script to identify versions of 'Adobe Reader' and 'Java'
• currently has no Adobe Reader infection vector, but has an empty code branch for it
• armed with 3 malicious JAR files for different Java versions
• employs JNLP technology for Java 7 exploit
• armed with an exploit for CVE-2011-3544 for Java 6 1.6.27 and lower
• uses user's 'Temp' folder to store the Initial Payload
• Initial Payload filename is randomly generated

Recommended read:

http://en.wikipedia.org/wiki/Chunked_transfer_encoding
http://schierlm.users.sourceforge.net/CVE-2011-3544.html
http://malware.dontneedcoffee.com/2013/07/pep-new-bep.html

Unknown EK: "Knock, knock... Who's there?"

NOTE: Information is based on a sample shared by @Set_Abominae  on 2013-06-05.

"My name is Bond... James Bond..."

The exploit kit appeared to start surfacing on 2013-06-01. The following URL pattern has been seen with this sample:

'urlquery.net' detected 'Phoenix exploit kit post-compromise behavior' activity after a successful Java vulnerability exploit. Phoenix EK is way more complex though.

Sample reports:

http://urlquery.net/report.php?id=2895619
http://urlquery.net/report.php?id=2788425

Straight to the business exploit kit - no PluginDetect use, no PDF infection vector, no Java code obfuscation, no 'padding' code, no Initial Payload encoding/encryption. Most of the variables and methods are meaningfully named. Java exploits used are stored in separate JAR files that are named according to the CVE number they target. The creator of this kit seems to know Russian language - one of the class files in one of the JARs is named 'BlyahaMuha' which is a word specific to Russian language only(not translatable).

"Requesting permission to land"

The landing page simply consist of the <applet>s with a link to a malicious JAR file and a parameter holding encoded Initial Payload URL.

Sample of an <applet>:

The landing page is redirected to by an injected <iframe> from a page hosted on a compromised website.

"Programming language or Coffee?"

4 JAR files deliver exploits for the following Java vulnerabilities:

• CVE-2011-3544
• CVE-2012-1723
• CVE-2012-5076
• CVE-2013-0422

1 exploit code per 1 JAR file. The code is almost as if it was copied from Metasploit package with very little effort to modify.

The Initial Payload URL decoding code is following a quite simple algorithm.

'Unprotected' payload is delivered as an 'application/octet-stream' with filename 'update_8251.exe' (name varies).

Once downloaded: the Initial Payload will be stored in Java Temp folder with hardcoded filename - '~.exe'.

Once executed: the following POST request is sent

following a number of GET requests 

In this case, they all received 404 response.

The Initial Payload was 'Zbot/Fareit' with 24/47 coverage on VT.

"How much is the fish?..."

Rather 'interesting' exploit kit. Hopefully, it has a name and it's not another 'random_word+hole'.

Brief summary:

• no protection/evasion employed throughout the exploit kit(landing page, Java, payload)
• targets Java vulnerabilities only
• no Java version check
• Initial Payload URL encoding algorithms is quite simple
• the payload is stored in Java Temp folder
• the payload filename is hardcoded
• the creator of the kit is more likely a Russian language speaker

Would like to hear from people who have any additional information on this exploit kit. Contact details can be found under Blogger profile.