LightsOut EK: "By the way... How much is the fish!?"

Thanks to @Set_Abominae for sharing details about this Exploit Kit.

Update 2013-10-14:
Thanks to @tlansec for identifying this EK - LightsOut.

NOTE: Information is based on the sample captured on 2013-09-27

Emmanuel Tacheau a Threat Researcher at Cisco shared his findings on this Exploit Kit in his latest blog post linking it to a watering-hole type of attack aimed at Energy & Oil Industries. Below is the list of target types he identified:

• An oil and gas exploration firm with operations in Africa, Morocco, and Brazil;
• A company that owns multiple hydro electric plants throughout the Czech Republic and Bulgaria;
• A natural gas power station in the UK;
• A gas distributor located in France;
• An industrial supplier to the energy, nuclear and aerospace industries;
• Various investment and capital firms that specialize in the energy sector.

Originally thinking that this Exploit Kit must be a state of art code with all possible obfuscation in the world applied (taking the target types into account), I was a little bit disappointed to see another 'somehow-somewhat' job - unused code, copy-paste from 'packetstormsecurity.com', almost no Java code obfuscation, no use of encryption or encoding, etc.

"It's the first page of the second chapter"

The below pattern is specific to this particular EK sample.

There are 2 layers of landing pages. The first landing page is a single '<iframe>' loading the second landing page.

The JavaScript on the second landing page will try to identify the following components before proceeding with any exploit attempts.

• Internet browser type
• Internet browser version
• Operating System version
• Operating System type (32/64 bit)

variables that hold gathered values

browser type check - 'BkEvhdwRlG' hold the UA string

The function(screenshot above) returns one of the following values - 'msie', 'opera' or 'firefox'. It's worth noting that 'opera' value is not being used in any conditions or anywhere else in the code. Code leftovers? Future plans?

browser version check

Another unused code branch here. Even though Firefox browser version is being identified, the value is not used anywhere else in the code.

OS version check

OS type check

Yet again, the OS type is being identified, but the value is not used. It's quite possible that the content of the second landing page is being generated on the fly and depending on some conditions parts of the code are chosen. If that's the case they need to work on the generation logic. Below are other samples of some 'dead' code.

function to check Adobe Reader plugin version

The function above is never called.

execution control code based on Adobe Reader version detected

If Adobe infection vector would be used the code above controls the execution flow.

three possible Adobe exploit branches

Currently empty, but if armed the three functions will be targeting Adobe Reader plugin versions '9.3.4', '9.4.0' and '10.1'.

Once Internet browser and Operating System types and versions are identified, one of the following code branches will be taken.

IE7 on XP or W2K or W2K3

Exploit code for IE7 on XP or W2K or W2K3 will be called following a request for malicious JAR file. I couldn't identify the IE7 exploit used in this instance and would appreciate the community  help on it. The code is posted on pastebin.com. Please contact me on Twitter or email if you have any information.

IE8 on XP or W2K or W2K3

CVE-2013-1347 is targeted if IE8 on XP or W2K or W2K3 is detected. Malicious JAR will be requested after IE8 exploit attempt. The last condition is a 'safety net' - targets all other types of Internet browsers with Java plugin enabled.

all other browser + Java

Malicious JAR file is selected using the simple logic below.

JAR selection logic

There are 2 JAR files to choose from - for Java 6 or for Java 7. Just as simple as that - no patch level checks, no narrowing the attack surface to increase the success rate and reduce the detection chance. This logic is probably dictated by the choice of Java vulnerabilities targeted - 'CVE-2012-1723(Java 6)' and 'CVE-2013-2465(Java 7)'. In both cases the call for a JAR file is implemented through a GET request for an HTML page that would have an '<applet>' to pull the JAR file down.

requesting JAR files through a separate HTML pages

The content of HTML pages for both Java 6 and 7 paths is quite simple - a single '<applet>' to request a JAR file.

Java 6 JAR request

Java 7 JAR request

I can't think of a good enough reason to request the JAR files through an additional HTML page. The author hasn't leant how to do it using JavaScript yet? That actually can also explain why there is no JNLP file used to launch Java 7 JAR file - it's probably in the last chapters of the book the author is reading as he/she is learning Web Programming.

"The chase is better than the catch!"

With the exception to some naming of some .class files, there is no obfuscation applied to Java source code or bytecode. Most of the methods and variables are meaningfully named. No parameters are passed to JVM running the JAR file.

part of exploit code for 'CVE-2012-1723'

Java 6 JAR file attempts to exploit 'CVE-2012-1723' and if successful proceeds to download the Initial Payload from hardcoded URL.

Initial Payload URL + store location + filename

The Initial Payload will be stored in Java Temp folder with hardcoded filename - 'TMPprovider0.dll'. The payload is executed with the following code.

Initial Payload execution code

That's pretty much all functionality included in Java 6 JAR file. Java 7 JAR is as straight to the business as the Java 6 one only with 1 extra step though. The execution starts with a slightly modified 'CVE-2013-2465' exploit code copied from 'packetstormsecurity.com' advisory.

part of exploit code for 'CVE-2013-2465'

The Initial Payload is downloaded through the same URL and will be stored in the same location with the same filename as in Java 6 sample.

Initial Payload URL + store location + filename

There is one extra step performed for the Initial Payload delivered by Java 7 JAR file.

applying file attributes - 'hidden' and 'system'

'hidden' and 'system' file attributes are set on the Initial Payload file stored in Java Temp folder. It's worth mentioning the Initial Payload is not 'protected' in any way during transmission.

"Summary"

Lack of originality, lack of sophistication... Really simple exploit kit. Nothing to highlight here. I wonder about the success rate for it. Some details below.

General Information
Name:	Unknown
Date captured:	2013-09-27
Date analysed:	2013-09-28
Source/Credits:	PCAP from @Set_Abominae. Live Fiddler capture
Infection vectors detected:	Java 6, Java 7, IE7, IE8
Vulnerabilities targeted:	CVE-2012-1723 CVE-2013-1347 CVE-2013-2465 CVE-???
Landing page
Transfer mode:	encoded / gzip
Obfuscation:	No
TDS:	No
JNLP:	No
JVM parameters:	None
Java infection vector
Captured with:	Java 1.6.23 / Java 1.7.15
Obfuscation:	None
JAR hidden content:	None
Initial Payload delivery method:	URL
Initial Payload encryption/encoding:	No
Initial Payload store location:	Java Temp folder
Initial Payload filename:	Hardcoded - 'TMPprovider0.dll'
Adobe infection vector
Captured with:	Not implemented
Initial Payload delivery method:
Initial Payload store location:
Initial Payload filename:
Automated analysis
Exploit components:	Java 6 JAR - virustotal.com Java 7 JAR - virustotal.com
Delivered malware:	EXE(MD5 8f8471acff7e18f61dc2def2bc353574) https://malwr.com/ https://www.virustotal.com
Additional Information
	Initial Payload crashes in VM Possibly VM/debug aware

External links:

http://urlquery.net/report.php?id=5963492
http://blogs.cisco.com/security/watering-hole-attacks-target-energy-sector/
http://www.exploit-db.com/exploits/25294/

Unknown EK: "Here's Johnny!"

NOTE: Information is based on a sample captured on 2013-06-14

The exploit kit was delivered through a poisoned advertisement feed. The following pattern has been seen:

Other examples of the pattern and a some detection tips can be found on Malwaresigs.com

"...as seen on TV..."

Request for an ad delivered a JScript that simply assembles a string using a number of other predefined strings.

The result is another JScript that takes the browser to 'www.googlecodehosting.net' hosting the landing page.

part of the assembled JScript

The landing page has yet another JScript with two 'document.writeln' calls. The first one requests a malicious JAR file armed with 'CVE-2012-1723' and 'CVE-2013-1493'. The request is implemented with an <applet> where one of the parameters in it is the Initial Payload URL encoded with 'Base64'.

The second 'document.writeln' call requests a JNLP file. The file is embedded into an <applet> - this allows to encode the content of the file with 'Base64'.

part of 'Base64' encoded JNLP file

'version' attribute of 'j2se' element in the decoded JNLP file is set to '1.7+' - meaning the file will be executed with Java 7 only. The JAR file targeting Java 7 is armed with 'CVE-2013-2423' and will be requested through a slightly different URL. The Initial Payload URL is stored in plain text.

part of decoded JNLP file

"Package full of goodness"

This particular exploit kit sample had only the malicious JAR file delivered through the first 'document.writeln' call from the landing page. The file is fairly obfuscated. The two exploits it caries are separated into two different packages/folders within the JAR. 'CVE-2012-1723' is stored in 'site' package. 'CVE-2013-1493' is stored in 'site/color' package. The exploits do not share any methods - their code is completely separated. 'CVE-2012-1723' exploit code is executed first. Due to the code separation, the Initial Payload filename is created using two different methods.

• payload delivered by 'CVE-2012-1723' is stored in Java Temp folder with hardcoded filename - '1.exe'
• payload delivered by 'CVE-2013-1493' is stored in Java Temp folder with the filename generated using a random number between '0' and '10000' + '.exe'

There is no encryption or encoding used for protecting the Initial Payload file.

Some of the class files, methods and variable names used in the kit are either existing words in Russian or a close variation of ones. The creator of this exploit kit is more likely to know Russian language.

"Ivanoff, Petroff, Smirnoff.... Dotcacheff"

 Quick summary:

• exploit kit URL pattern is relatively unique
• was delivered through Malvertising
• Java Script seems to be a preferred language for the redirect and landing pages
• targets Java only
• JNLP fie is protected with 'Base64'
• armed with 'CVE-2012-1723', 'CVE-2013-1493' and 'CVE-2013-2423'
• Initial Payload URL is stored in 'Base64' format
• no encryption or encoding employed for Initial Payload delivery
• Initial Payload filename depends on the exploit code executed
• creator is more likely to know Russian language

The exploit kit is rather simple, but not as simple as the one seen on 2013-06-07. @MalwareSigs tagged this exploit kit with a catchy name - 'Dotcachef'. Sounds like a Russian surname. Good fit for it, ah. Just need another 'f' at the end to make it look totally cool.

Recommended read:

http://www.malwaresigs.com/2013/06/14/dotcachef/
http://www.basemont.com/new_exploit_kit_june_2013

Update 2013-08-23:

Malforsec's latest analysis on DotCacheF - http://malforsec.blogspot.com/2013/08/dotcachef-short-story.html

Unknown EK: "Knock, knock... Who's there?"

NOTE: Information is based on a sample shared by @Set_Abominae  on 2013-06-05.

"My name is Bond... James Bond..."

The exploit kit appeared to start surfacing on 2013-06-01. The following URL pattern has been seen with this sample:

'urlquery.net' detected 'Phoenix exploit kit post-compromise behavior' activity after a successful Java vulnerability exploit. Phoenix EK is way more complex though.

Sample reports:

http://urlquery.net/report.php?id=2895619
http://urlquery.net/report.php?id=2788425

Straight to the business exploit kit - no PluginDetect use, no PDF infection vector, no Java code obfuscation, no 'padding' code, no Initial Payload encoding/encryption. Most of the variables and methods are meaningfully named. Java exploits used are stored in separate JAR files that are named according to the CVE number they target. The creator of this kit seems to know Russian language - one of the class files in one of the JARs is named 'BlyahaMuha' which is a word specific to Russian language only(not translatable).

"Requesting permission to land"

The landing page simply consist of the <applet>s with a link to a malicious JAR file and a parameter holding encoded Initial Payload URL.

Sample of an <applet>:

The landing page is redirected to by an injected <iframe> from a page hosted on a compromised website.

"Programming language or Coffee?"

4 JAR files deliver exploits for the following Java vulnerabilities:

• CVE-2011-3544
• CVE-2012-1723
• CVE-2012-5076
• CVE-2013-0422

1 exploit code per 1 JAR file. The code is almost as if it was copied from Metasploit package with very little effort to modify.

The Initial Payload URL decoding code is following a quite simple algorithm.

'Unprotected' payload is delivered as an 'application/octet-stream' with filename 'update_8251.exe' (name varies).

Once downloaded: the Initial Payload will be stored in Java Temp folder with hardcoded filename - '~.exe'.

Once executed: the following POST request is sent

following a number of GET requests 

In this case, they all received 404 response.

The Initial Payload was 'Zbot/Fareit' with 24/47 coverage on VT.

"How much is the fish?..."

Rather 'interesting' exploit kit. Hopefully, it has a name and it's not another 'random_word+hole'.

Brief summary:

• no protection/evasion employed throughout the exploit kit(landing page, Java, payload)
• targets Java vulnerabilities only
• no Java version check
• Initial Payload URL encoding algorithms is quite simple
• the payload is stored in Java Temp folder
• the payload filename is hardcoded
• the creator of the kit is more likely a Russian language speaker

Would like to hear from people who have any additional information on this exploit kit. Contact details can be found under Blogger profile.

Sakura: "Cherry blossoms, cherry blossoms" --- Part 2

"Across the spring sky"

Part 1 covered a sample of Sakura exploit kit landing page. Part 2 covers analysis of malicious JAR file targeted at Java prior to 1.7.11 update. This particular sample shares a great similarity with RedKit code I analyzed previously. Sakura, though, seems to be attempting to avoid detection through the use of Java Reflection for the parts of the code that changes execution permissions. Recommended read on the subject - @SecObscurity's research/testing into AV avoidance.

In general, Sakura code can be broken into the following parts:

• Exploit code
• Initial payload URL decoder
• Initial payload fetcher
• AES decryption code
• Filename generator
• Storing and Execution code

Hard to tell what came out first: Sakura or Redkit, but it looks like one is a copy of the other.

NOTE: Code obfuscation changes variable, function, class file names as well as code execution flow. Names and code execution flow analyzed in this sample is different from other instances of Sakura, though the basics stay the same.

"Fragrant in the morning sun."

Execution starts with an exploit for CVE-2012-1723. Specially crafted method creates a condition called 'type confusion' and combines it with ClassLoader to instantiate a class object with elevated privileges. Article by Michael 'mihi' Schierl explains this vulnerability in great details.

Core code of CVE-2012-1723 in this Sakura sample:

Granting 'AllPermission' using Reflection methods:

Creating a new 'ProtectionDomain' using Reflection methods:

Passing control to 'Chie.class' to do the rest of the dirty work:

Setting 'SecurityManager' to 'null' using Reflection methods:

At this stage the code is running without any restrictions.

"In fields and villages"

Following successful exploitation, string of characters held in one of the parameters on the landing page is converted into Initial Payload URL. The algorithm for conversion is identical to the one used in RedKit strains prior to March 2013. It can be broken down into the following steps:

• The order of the characters is reversed (last --> first, 2nd last --> 2nd, etc.)
• 'Padding pattern' is removed from the string
• Every 3rd character is taken and stored in a new string

Implementation of this algorithm in Sakura is slightly different. It also uses different 'padding' pattern.

Reversing the characters order and removing the 'padding' pattern:

Constructing URL by storing every 3rd character in a new String

The decoded string is passed to Initial Payload fetcher. 

"Flowers in full bloom."

Fetcher is a quite standard Java code for receiving a data stream over HTTP.

The encrypted payload was delivered as 'application/octet-stream' with filename 'pixz.gif'

Received stream is converted to a 'byte []' and passed to AES decryption module.

"As far as you can see."

AES decryption module is also a quite standard piece of Java code for decrypting a byte array using a cypher generated from predefined 'Secret Key' and 'Initialization Vector' values.

'Secret Key' and 'Initialization Vector' values:

Decrypted byte array is passed to a method that saves it into a file:

Before the array is saved into Java Temp folder, a filename is generated with the following algorithm:

The filename is 6 characters long and made up of random letters from 'a' to 'z'.

"Come now, come now, Let's look, at last!"

The final touch is the Initial Payload execution.

Summary: In overall it's a straight forward execution logic. In some way Sakura looks like a simplified version of Redkit even though it attempts to use some evasion techniques. The following are the key points of this particular sample of Sakura Exploit kit:

• Initial Payload URL is encoded and stored in <applet> tag on the landing page
• Uses Java and Adobe infection vectors
• Has a specific Java JAR file aimed at Java 1.7.11
• Attempts to exploit CVE-2012-1723
• Uses Java Reflection methods in attempt to avoid being detected by AV software
• Initial Payload is encrypted with AES
• Delivers only 1 Initial Payload
• Generates a filename consisting of 6 random characters from 'a' to 'z'
• The Initial Payload is stored in Java Temp folder

The Initial Payload delivered by this sample was only 10/43 on VT at the time and classified as 'Trojan-Ransom.Win32.Foreign.bdjk'(Kaspersky)