"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)
