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