Zuponcic: "Is it a bird?... Is it a plane?... No, it's another... wait, what!?" --- Part 2

Special thanks to Mike Strobel for help with decompiling the Java code and William Metcalf for sharing some Zuponcic samples.

NOTE: Information is based on Zuponcic samples captured on 2012-11-29 and 2013-06-10

"... there is no spoon ..."

There is no exploit code. The JAR file includes just 1 .class file with 2 methods that perform the following roles:

• String decoder
• Store path and filename builder
• Initial Payload handler (downloader, decryptor, executor and cleaner)

Anti-forensic techniques used:

• 'control flow obfuscation' - makes it incredibly difficult to decompile the code
• 'encoded String values' - hides all the String values
• 'use of StackTraceElement' - uses dynamic values on the Stack(see decoding strings section below)

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.

1. 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.
2. 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.
3. 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.
4. 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.
5. 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'. 
6. 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. 
7. 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.