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/

Deobfuscation tips: Reversing Java bytecode 'poisoning'

DISCLAIMER: I'm pretty sure there are better and more efficient(automated) methods exist to achieve the same results as the below exercise. My intention was to do it manually using freely available tools. Time was not a concern. I'm not aware of a proper name for this obfuscation technique - so I called it 'Java bytecode poisoning'. This is not a step-by-step guide - these are just some tips.

If you're to try this method following the steps described below you'll need to have the following skills and tools:

Skills

• Good understanding of Java class file structure
• Good understanding of Java bytecode instructions
• Basic understanding of How LIFO stack works

Tools

• dirtyJOE - Java Overall Editor
• JBE - Java Bytecode Editor
• JD-GUI - Java Decompiler

Update 2014-01-19: Discovered a tool that simplifies the task dramatically. Apart from handy text-editor type interface for bytecode editing, it also adjusts exceptions and conditional jumps addressing automatically. reJ - http://rejava.sourceforge.net/index.html

When cosmic rays hit atoms...

NOTE: Neutrino EK sample was obtained from www.malware-traffic-analysis.net

Not that long ago Neutrino EK authors started using some bytecode obfuscation technique that rendered some of the Java Decompilers useless when restoring Neutrino's source code. Here is how decompiled Neutrino EK used to look before this 'upgrade'...

Neutrino EK 2013-09 sample decompiled using JD-GUI

Apart from some string obfuscation, the code is pretty readable. And here is how one of the recent samples looks like when decompiled using the same JD-GUI tool...

Neutrino EK 2014-01 sample decompiled using JD-GUI

Where some of the source code was successfully decompiled, the methods are padded with tons of meaningless entries. First thing that comes to mind is to simply remove all of this rubbish. Lets do just that and see what happens...

Neutrino EK decompiled code after rubbish clean up

Some parts of the output can help to understand what the code is doing, but it's not a valid Java code. The same approach definitely wouldn't work for methods similar to the one below...

Neutrino EK decompiled obfuscated Java method

If we're to remove all the rubbish from this method we end up with no code left, but this method actually performs the following...

Neutrino EK decompiled deobfuscated Java method

So, how do we jump from 'no sense' to 'full picture'? The answer is in the bytecode.

'txjLPjLxt' method in bytecode view

What we're looking for are 'push' and 'pop' instructions and more importantly what happens in between. As you read through the bytecode, you might notice patterns start to emerge involving these two operations. Patterns similar to these...

examples of 'push' & 'pop' bytecode patterns

In terms of application execution, these instructions have no effect on any application parts, but doing great keeping CPU busy running them. For example, pattern 1 --> pushes 2 bytes on the stack --> swapping them --> popping them of the stack. So, what happens if we're to relief the CPU from the burden of running these instructions by removing them from the bytecode. The below is what's left of the 'real' instructions...

bytecode after 'push' and 'pop' patterns are removed

Lets now come back to the 'init' method we started with and perform the same bytecode clean up and compare the result with the previous deobfuscation method where we simply removed the rubbish entries from the decompiled code.

Neutrino EK deobfuscation results comparison

Where in a few places the results match, the majority of the decompiled source code is different. After the bytecode clean up we can clearly see what happens step-by-step.

Short breakdown

There are a few ways this bytecode clean up method can be performed in. The steps for the simplest one are below:

• take a note of the exceptions(if any exist in the method you're about to edit) - 'start', 'end' and 'handler' addresses and instructions they are pointing at.(my personal preference is to use dirtyJOE for viewing/editing exceptions).
• replace 'push' & 'pop' patterns with 'nop' instructions(Java Bytecode Editor allows you to do it more efficiently through text editor style interface).
• (optional) edit exception/s values if the addressing skewed for some reason
• save the changes and check decompilation results

To make it more challenging you could take it a little bit further and remove 'nop' instructions completely. A good care should be taken here, as any 'conditional jumps', 'goto', etc, instructions would have to be edited (in addition to any existing exceptions) to reflect the new addressing.

NOTE: Java Bytecode Editor performs bytecode integrity check before saving edited methods. It will NOT allow you to save methods that are either performing the sandbox escape(exploit) or those running instructions that leverage post-exploit condition. dirtyJOE will do this dirty job for you, but at the cost of convenient code editor interface.