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.
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.
The features advertised are just a little bit an overkill for being 'educational purpose only' though.
"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>.
The following URL pattern was observed with this Epic JDB sample.
The JAR file is signed with the following certificate.
JAR file structure is quite simple - only 1 class file inside.
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.
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.
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.
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.
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");'
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.
|Name:||Epic Java Drive-By a.k.a EpicKit|
|Source/Credits:||Intel source - @MaartenVDantzig @cryptoron.
Data source - live traffic capture with Fiddler.
|Infection vectors detected:||Java|
|Transfer mode:||plain text|
|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|
|Initial Payload delivery method:||NA|
|Initial Payload store location:||NA|
|Initial Payload filename:||NA|
|Exploit components:||JAR - https://www.virustotal.com|
|Delivered malware:||EXE(MD5 f79eb2c78a11194cde18cc7190304ec5)
|Uses certificate signed JAR to bypass Java security measures.
Supports 2 Initial Payload file formats - EXE and JAR
Shares some similarity with Zuponcic Kit