Black Dragon: "... and all will burn beneath the shadow of my wings"

NOTE: Information is based on a sample captured on 2013-07-18

Black Dragon EK is an offspring of BlackHole2 Exploit Kit. The most noticeable similarity is the URL pattern. More details can be found on mawaresigs.com.

"Fly my monkeys, Fly!... oh, wait..."

The URL pattern in this sample is fairly unique.

The landing page has a single Java Script that contains an algorithm to assemble another page that is later being passed to 'eval'.
 

'key string' and the decoding algorithm

snippet of the encoded page

Revelo tool from Kahu Security can be used to assemble the page.

Revelo settings

NOTE: The original JS from the landing page has 'newline' characters within the string that holds the encoded page. They have to be removed prior deobfuscation.

PluginDetect script is used to detect installed Java version only. There are 3 code branches for Java infection vector named 'java1', 'java2' and 'java3'.

• 'java1' branch is taken if 'Java 1.5 - 1.6.32' or 'Java 1.7 - 1.7.09' is detected
• 'java2' branch is taken if 'Java 1.7.10 - 1.7.17' is detected
• 'java3' branch is taken if no 'Adobe Acrobat' plugin is detected

Code for 'java1' and 'java3' branches is identical though.

'java2' code branch uses a JNLP file embedded into an 'applet' allowing 'base64' encoding to be employed to 'hide' the content of the file.

Decoded using another great tool by Kahu Security.

decoded with Kahu Security 'Converter' tool

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.

• 'CVE-2012-0507' - Java 1.7.2 and earlier, Java 1.6.30 and earlier, and Java 1.5.0.33 and earlier
• 'CVE-2013-0431' - Java 7 through update 11
• 'CVE-2013-2423' - Java 7 through update 17
• 'CVE-2013-1493' - Java 1.7.15 and earlier, Java 1.6.41 and earlier, and Java 1.5.0.40 and earlier

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:

• has relatively unique URL pattern
• landing page uses 1 obfuscation layer
• uses PluginDetect script to identify Java version only
• targets 'Java 1.5 - 1.6.32' and 'Java 1.7 - 1.7.17'
• has custom code to identify browser plugins and 'Adobe Acrobat' or 'Adobe PDF Reader' versions
• armed with exploits for 'CVE-2012-0507', 'CVE-2013-0431', 'CVE-2013-2423' and 'CVE-2013-1493'
• initial payload URL is stored encoded and split between 2 parameters on the landing page
• contains 'hidden' encoded class file
• initial payload is transferred encoded
• uses Java Temp folder to store the hidden class file and the initial payload

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