Pages

Monday, 26 August 2013

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.

NOTE: The screenshots in this section show the code after all the string values have been decoded. Prior to decoding, the values looked like in a sample below

encoded values sample

'SVwBIoycqCilt' is the name of the method that decodes the strings. The method wasn't fully reconstructed, but the decoding algorithm was successfully restored.

string decoding algorithm

The decoding key is built using dynamic values from the process stack.

reading stack elements

This trick works well when the class and the calling method names are static. In case of Zuponcic, it's been static since the first occurrence: class name - 'FlashPlayer' and calling method - 'init'. The resulting decoding key - 'FlashPlayerinit'. This value is later being assigned to a variable called 's2' and used to decode the strings(see decoding algorithm screenshot above). In a way, this is a 'protection' mechanism to prevent the decoding method returning valid results when called using Java 'Reflection' methods. Through some tinkering with the decoding method, the strings were decoded and any calls for the decoding routine have been manually replaced within the code, so it looks more readable.

decoded strings sample

The code above is also where the execution begins. It starts with identification of Java Temp folder and Initial Payload filename generation.

location and filename sample

The Initial Payload will be stored in Java Temp folder with a randomly generated filename using a number of digits and '.tmp' extension. It's then downloaded using 'URLConnection' methods with the following routine.

Initial Payload fetcher code

The download is implemented through an HTTP 'POST' request with 'Content-Type' set to 'application/x-www-form-urlencoded' and 'i' parameter containing a connection token. The token and the Initial Payload URL are retrieved from the landing page. The tokens appear to be different among the Zuponcic samples - possibly generated on per connection basis. The same goes for the RC4 decryption keys used to decrypt the Initial Payload.

RC4 cipher initialization

'SecretKey' value is also stored in plain text on the landing page and retrieved during the code execution. Once the payload is received, decrypted and stored on the disk it's executed through the following simple code.

execution and browser redirect

If 'writing' and 'running' operations are explicitly allowed for certificate signed applets in Java Security Policy or the process is run under a user with Administrator privileges - the Initial Payload will be successfully executed. After the Initial Payload execution(successful or not) the browser is redirected to the URL stored in 'g' parameter on the landing page. This URL is the name of the website the browser was originally trying to get to from the search results page(see part 1). If payload execution is unsuccessful the payload file is deleted and the browser is redirected to the URL stored in 'e' parameter on the landing page.

clean up routine

'e' parameter contains the last URL given by TDS(see part 1). It's pointing the browser back to the Zuponcic landing page. It's difficult to say what's going to happen at this stage, but I strongly believe the browser will be redirected to 'www.google.com' due to the request being sent directly to the website hosting Zuponcic. Any direct requests sent to it are being redirected.

'Trojan.Vundo'(Microsoft) has been delivered by the sample captured in November 2012. What makes it interesting that MD5 of the file was not known to VirusTotal at the time of writing this post. After the submission though, it shows 37/46 detection ratio - link.

Summary

What do you call an exploit kit that doesn't have any exploits? Kit? So, Zuponcic Kit is still a malware delivery method that is a part of a quite stealthy infrastructure. The use of 'protection/evasion' techniques like TDS, connection tokens, bytecode obfuscation, data encryption and encoding, code tricks with process stack, clean up routine and selective targeting is quite close bordering to an APT related threat. I personally don't like the use of these 3 letters, but some attributes of this kit are just unusual for an ordinary exploit kit and intend to make it more stealthier rather than successful. Some observations to support this theory.

TDS - Traffic Distribution System. Dynamically created/added HTTP request content that follows the original request through 2 level redirect chain prevents replaying the connection sequence and get direct access to Zuponcic components. Domain names of the servers hosting it are never linked directly from the pages on compromised websites - making it difficult to trace them.

Landing pages are dynamically generated using some of the content related to the original user request - to a certain extend, it's an attempt to put a disguise on. In all of the cases seen so far, the redirect chain starts with a user doing a Google search and clicking on one of the links from the result page that leads to a compromised website. The search criteria is being passed through all the TDS redirects in the 'Referer' value and later used when a landing page is generated. See part 1 for more details.

Java applet parameters are also generated dynamically and more likely unique per individual browser session. None of the samples seen so far had the same values. TDS must be keeping track of all of the connections and will not allow to use the parameters assigned to a session twice. This again complicates the tracing and sample/evidence collection.

The JAR file is signed with a certificate to make it look legit. It has only 1 Java class file. The class filename is rather misleading. It's is fairy obfuscated to make the analysis difficult. Uses dynamic content of the process stack to obscure the reverse engineering process. No exploits = no AV alerts = stealthy.

Initial Payload is encrypted with RC4 during the transfer and when stored is disguised as a '.tmp' file. The encryption key varies from sample to sample. Payload sample seen in November 2012 was still unknown to VT in August 2013. Good indication of low distribution possibly due to campaign not being 'commercial'.

Clean up process to remove Initial Payload from a victim's disk if infection is not achieved. This is something you don't normally see when it comes to exploit kits. Someone really cares about the file being found, submitted to AV vendors and become detectable.

Intended for the machines that can be used as a platform for further attacks. This could be called a selective targeting where who ever is behind the Zuponcic is only interested in the machines that they can turn into a 'launch pad' and having Administrator rights helps a lot.

Anyone having any additional information or would like to discuss the subject 'offline' please feel free to reach out using contact details under my Blogger profile.