EpicKit aka Epic JDB: "Do you want fries with that?"

NOTE: The information is based on a sample captured on 2014-01-14.

Thanks to @cryptoron for raising the awareness and @MaartenVDantzig for sharing some intel.

"You know, for kids!"

Here's a quick description of this kit.

part of Epic Java advertisement from Hackforums

In 'Terms & Conditions' part it's being referenced as 'Educational Java Drive-By'. I'm not quite sure if it's a type of an account under their service or they sell this product under 'educational purpose only' banner.

part of 'Term & Conditions' for Epic Java

The features advertised are just a little bit an overkill for being 'educational purpose only' though.

Epic Java features as per advert on Hackforums

"I'm not confident on which end that came out of."

In terms of implementation, this kit doesn't have any exploit code. It used certificate signed JAR files to bypass Java Security Warning Window(works only on Java 1.7.21 and earlier) and to escalate applet's runtime privileges. The Java code is obfuscated with Zelix KlassMaster using Name, Control Flow obfuscation and String Encryption techniques.

Compromise attempt start with a landing on a website that serves pages injected with Epic JDB malicious <applet>.

sample of injected <applet>

The following URL pattern was observed with this Epic JDB sample.

sample of Epic JDB URL pattern

The JAR file is signed with the following certificate.

certificate the JAR file is signed with

JAR file structure is quite simple - only 1 class file inside.

JD-GUI - Epic JDB JAR file structure

As can be seen in the screenshot above, ZKM is doing a good job at obfuscating the code. JD-GUI couldn't handle it. After some Voodoo magic with JMD reversing some of ZKM changes and Procyon Java Decompiler restoring Java code and getting Bytecode AST, I got some readable code. The applet execution starts with gathering some system data and pulling values of some parameters from the landing page.

Epic JDB - information gathering and retrieval

After 'massaging' the gathered data a little bit, a GET request is made to pull down the Initial Payload from a predefined location stored in applet's 'ca' parameter.

Epic JDB - data manipulations and Initial Payload request

After the Initial payload is downloaded, the code checks the type of the file downloaded by looking for '.ex' expression in applet's 'us' parameter.

Epic JDB - Initial Payload type check (bytecode AST view)

If an 'exe' filename is detected the code goes straight to executing it, redirecting the browser to the initial compromised website which address is stored in applet's 'uk' parameter and reporting to C2.

Epic JDB - Initial Payload execution, browser redirect and callback request

C2 URL is hardcoded and pointing at 'epickit.net' website. The following parameters and data are being added to the URL before being sent:

• 'username=' holds predefined value that is stored in applet's 'nl' parameter and in this sample is 'fox33'. Possibly, it defines the campaign owner.
• 'os=' holds the type of the OS the applet is running on. It's gathered through 'System.getProperty("os.name");'
• 'pc=' holds the username of the currently logged in user. It's gathered through 'System.getProperty("user.name");'

In addition, the word 'Traditional' is added to the request. I'm not quite sure about the purpose of it, but my best guess is it's work in progress artefact. Purposely or not, I was greeted with the following response after C2 GET request:

Epic JDB - Callback response

The file execution part is slightly different if the Initial Payload is a 'jar' file. After confirming that underlying platform is 'windows', the following code is executed:

Epic JDB - JAR file execution routine

There are some code artefacts that might be an indication of ongoing code development or could be simply the results of ZKM messing with the code.

Summary

Summary Information
Name:	Epic Java Drive-By a.k.a EpicKit
Date captured:	2014-01-14
Date analysed:	2014-01-14
Source/Credits:	Intel source - @MaartenVDantzig @cryptoron. Data source - live traffic capture with Fiddler.
Infection vectors detected:	Java
Vulnerabilities targeted:	None
Landing page
Transfer mode:	plain text
Obfuscation:	None
TDS:	No
JNLP:	No
JVM parameters:	Yes - 4
Java infection vector
Analysed with:	Java 1.7.07
Obfuscation:	Zelix KlassMaster - String encryption, Variable Names & Control Flow obfuscation
JAR hidden content:	None
Initial Payload delivery method:	URL
Initial Payload encryption/encoding:	None
Initial Payload store location:	System's Temp folder
Initial Payload filename:	javasan.exe
Adobe infection vector
Analysed with:	NA
Initial Payload delivery method:	NA
Initial Payload store location:	NA
Initial Payload filename:	NA
Automated analysis
Exploit components:	JAR - https://www.virustotal.com
Delivered malware:	EXE(MD5 f79eb2c78a11194cde18cc7190304ec5) https://malwr.com/ https://www.virustotal.com
Additional Information
	Uses certificate signed JAR to bypass Java security measures. Supports 2 Initial Payload file formats - EXE and JAR Shares some similarity with Zuponcic Kit

External References:
http://blog.malwarebytes.org/fraud-scam/2014/01/musical-bitcoin-bubbles-serve-java-applets-malware/