Sakura: Changes - August 2013

Thanks to Kafeine for sharing the sample.

NOTE: Information is based on a sample captured on 2013-08-16. This sample is compared to the ones captured earlier this year - May 2013. All Sakura EK blog posts can be found here.

Landing Page

URL pattern is still quite short, but the file extensions for JAR file and Initial Payload requests have changed.

Sakura EK URL pattern - August 2013

JAR file is requested through an HTTP GET for a file with '.b' extension and in case of the Initial Payload it's '.a'.

PluginDetect script 0.8.2 is now being used.

part of PluginDetect script from Sakura EK landing page

Code block for selecting what JAR file to request has been changed slightly. The execution flow logic is now simpler and a potential victim won't be getting 'Page not found' message in case if Java version running on his/her machine does not satisfy the exploit criteria.

JAR file request logic

The <applet> code for requesting the JAR file is still padded with a random characters pattern - in this case it's 'MGio@#as'. The file selection logic:

• If detected Java version is between '1.7.10' and '1.7.17' inclusive then the JAR file will be requested through a specially crafted JNLP file that allows to bypass Java Security Warning Window. The JNLP file is stored 'base64' encoded.
• If detected Java version is lower than '1.7.10' then the JAR file will be requested through a standard <applet>. No encoding applied.
• If detected Java version is '1.7.18' and higher then no exploit will be attempted.

JAR File

There are now two boolean variables that track the system architecture type and Java version.

Both variables are used within 'CVE-2013-2471' exploit code when setting up different parameters.

'_is64' variable is used when creating a new integer-based DataBuffer

'_is7u17' variable is used when setting up parameters for a new 'WritableRaster'

'_is7u17' value is set with the following Java version check code:

'_is7u17' is set to 'true' if Java version is '1.7.17' or '1.6.43' and higher

Exploit code will be attempted 5 times before giving up.

The Initial Payload URL is still stored on the landing page using the same encoding technique it 'borrowed' from RedKit EK, but the Initial Payload is no longer encrypted with AES - it now uses XOR. The XOR key is stored in one of the variables within Java code.

Initial Payload fetching routine + XOR key - 'hdlux'

The Initial Payload will be stored in Java Temp folder with a randomly generated filename using just lower case letters(6 in total).

part of 'Initial Payload' filename generator code

Coincidental or not but this code looks exactly like the one here with only 1 line difference. It's not like the first time Sakura EK author 'borrows' someone else code, but I just personally find it entertaining to some extend. Maybe it's just me expecting some creativity when it comes to writing a malicious code. On the other hand it shows that any kiddo with some basic knowledge of Java can come up with the likes of this 'copy/paste' job - I wonder now how bad the server side code looks like.

Recommended read

http://malware.dontneedcoffee.com/2013/08/cve-2013-2465-integrating-exploit-kits.html

Sakura: AES and Initial Payload URL decoding algorithm changes - May 2013

The information is based on a sample seen on 2013-05-30.

Cipher

New values for AES 'Secret Key' and 'Initialization Vector' variables.

Decoding algorithm

Initial Payload URL decoding algorithm has changed and now is exactly the same RedKit is using. One of the parameters on the landing page holds a string of characters that is being used to look up characters from yet another string to build the URL.

Using the characters in the parameter called 'param', the Initial Payload URL is assembled with the following code:

What's interesting to note, the variables names('c','o','url') used within the method match with the ones used in RedKit. Tsk-tsk, copyright infringement.



Related read:
http://malwageddon.blogspot.com/2013/05/sakura-landing-page-changes-may-2013.html
http://malwageddon.blogspot.com/2013/04/redkit-initial-payload-url-decoding.html

Sakura: Landing page changes - May 2013

The details are based on a sample seen on 2013-05-30. Credits to @Set_Abominae for sharing the sample.

URL pattern

GET requests are going over port 443, but are not using SSL. The pattern is almost the same as in previously seen sample with the exception to the initial payload GET request. It uses '.rar' file extension.

Encoded landing page

Landing page undergone some changes to hide the code that retrieves malicious JAR file and checks the version of Java installed. The 'hidden' code is stored within a <div> tag.

The following code 'unescapes' and decodes the character string.

The 'cipher' used to decode the string

Decoded landing page

Familiar code execution logic is revealed after the landing page is decoded. PluginDetect script is initialized to check for Java version and based on the findings a request to malicious JAR file is formed.

For Java 7 below 1.7.18 update, the malicious JAR will be requested using JNLP to bypass Java Security Warning window. For all other Java versions, the JAR will be requested directly.

Sakura & JNLP

Sakura went a bit further than some other EKs in employing JNLP by embedding it into an <applet> tag. Doing so allows to use Base64 encoding to 'hide' the content of the file.

Decoded JNLP file

More details on JNLP and 'performSSVValidation' flaw can be found here.

PDF no more

There is no PDF infection vector in this sample.

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)

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

The Spring has come

I fished out this sample of Sakura Exploit Kit in early April 2013. As in every EK, all starts with a landing page. What immediately stands out is a non-standard port used for HTTP. In this particular sample, port 84 was used. HTTP GET requests follow the same pattern as per MalwareSigs post .

The landing page is armed with PluginDetect 0.8.0 script that detects the version of Java RE. The code sitting on top of the script steers the execution flow depending on the version detected. Malicious applet requesting the JAR file is selected based on the following logic:

Java infection vector will not be used if Java 7 version higher than '1.7.11' is present - the script will exit displaying "Page not found" message. If Java 7 version is '1.7.11' then applet stored in 'sher' variable will be executed. For other Java RE versions applet stored in 'bewryh' variable will be used.

The variables are padded with 'ABC' pattern that is removed with JS regex command once applet is called. The GET requests for malicious JAR and PDF files are sent to 'motherother.php'. Java version number in the 'User Agent' string is used by the server to determine what JAR file to serve(for Java 1.7.11 or lower). For any other 'User Agent' strings a malicious PDF file is served.

Java bytecode files the exploit execution starts with are different. Malicious JAR file targeted at Java prior to '1.7.11' starts with execution of 'Test.class'. JAR targeted at Java 1.7.11 executed with 'Test.ser'. '.ser' file extension refers to Java Serialization Files. Serialization files represent the state of objects sufficient to reconstruct the objects. Refer to Java Object Serialization Specification for more information.

Before PDF file is requested, number of checks is performed:

•  browser's plugins array is checked for 'Adobe Acrobat' or 'Adobe PDF' plugin.

• if plugins are not found, the script will attempt to create a new instance of 'ActiveXObject' called 'AcroPDF.PDF' or 'PDF.PdfCtrl'.

'ActiveXObject' is used to create instances of OLE Automation objects in Internet Explorer. Will not work with any other Internet browsers.

• if any of the above is successful, the script will create a request for a PDF file. Otherwise, it will not be served.

'document.createElement("embed")' is used for creating a request through 'Firefox' browser

'document.createElement('iframe')' is used for any other types of Internet browsers

"Is it a mist, or clouds?"

 Quick summary for the above:

• PluginDetect script is used to detect version of Java only
• Single URL to dish out malicious JAR and PDF files
• Includes exploit targeted at specific version of Java - 1.7.11
• Uses Java Object Serialization for Java 1.7.11 infection vector
• No Adobe Acrobat version check
• Malicious PDF will be served if either Adobe browser plugin or ActiveXObject is detected
• Request for PDF file is formed based on Internet browser type

Part 2 covers analysis of malicious JAR file aimed at Java prior to 1.7.11 update.