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