PDF infection vector is implemented through a function that first checks if there are any plugins installed in the browser. If it detects plugins it will check for presence of 'Adobe Acrobat' and if detected will attempt to identify its version through 3 different methods.

using 'pluginName.version' value

using 'pluginName.description' value

using 'navigator.mimeTypes' value

When 'navigator.mimeTypes' value is used, hardcoded values are assigned to 'Adobe Acrobat' version.

If no plugins are detected the script will attempt to create a new 'div' element that calls 'Adobe PDF Reader'.

The detected or hardcoded version value is passed to another 'if' statement.

Malicious PDF file will be downloaded if 'Adobe Acrobat' plugin version is '8.0 - 8.2' or '9.0 - 9.3'. Otherwise, 'java3' function will be called.

There is also a timeout set to 61 seconds that suppose to redirect the browser somewhere, but this function is not implemented.

In overall, either the landing page is a work in progress or just very poorly maintained.

"Coffee fuels many bright minds"

The JAR file is somewhat obfuscated. It targets the following vulnerabilities.

The file appears to be designed for use by both exploit code branches - 'java1' and 'java2'. There is a boolean variable called 'buildFor_1_6' that is used to 'steer' the exploit execution flow. If it's set to 'true' CVE-2013-2423 exploit is skipped.

The exploits are executed in a particular order as per above screenshot. The execution sequence breaks on the first successful exploit. The initial payload URL is built next, using two parameters from the landing page - 'val' and 'prime'.

2 parameters retrieved and concatenated

values stored on the landing page

URL decoding routine

The URL is passed to a class file that is dynamically built using a string value and a decoding routine.

name, location and encoded class file stored in a string

class file assembly routine

Thanks to @bbaskin for pointing out the 'decode()' function is in fact a standard 'Base64' decode routine with a slight modification - instead of a hardcoded alphabet table, the 'getValue()' just returns the byte's table offset.

The class file will be stored in the Java Temp folder with 'V.class' filename. The execution is passed to this class file and the decoded Initial Payload URL is supplied to it as an argument.

'a' holds the decoded URL

The bytecode of the class file is 'mangled' and can't be fully decompiled using standard decompiling tools. The best decompilation results were produced by an online tool 'Show My Code'. The output from this tool still allowed to reconstruct the actions performed by the code. In brief, the class file has the following routines:

a string decoding method

initial payload filename generation routine

initial payload fetching routine

initial payload decoding and execution routine

The downloaded malware will be stored in the Java Temp folder with a randomly generated filename.

Summary

The overall impression from analyzing this exploit kit is it was made by a 'wanna be' chap or chaps. Where it uses some decent techniques, the code looks like it was put together by someone without a good understanding of these techniques. Dead code branches on the landing page and within Java code leave an 'author can't be arsed' impression. Anyway, here are some highlights:

Thursday, 4 July 2013

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.

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.

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.