Wednesday, October 2, 2013

Sweet Orange - Update

This content has moved to

After 48h of monitoring the Sweet Orange EK noted in our previous post some of the indicators have changed. Now that we know what changes and what doesn't we can refactor our previous indicators and make them more robust.

We now know the refresh rate for the domain generation and url parameter changes. The EK changes url parameters every minute while the domain is changed ever 6 minutes.

What Has Changed

The strings used to obfuscate the applet parameters have been changed and the applet has been recompiled to adapt the decryption/de-obfuscation algorithm.


The port that the malware host is using has changed so the URL regex indicators need to change.


The IP address is now fluctuating within the same (AS12695) the IPs seen include

What Has Stayed The Same

The exploits and the general frame of the exploit landing page have stayed the same.

No-ip dynamic DNS is still being used with the domain "".

The binary exploit remains the same, it has been repacked but I wrote a terrible python script that is able to identify it based on a unique pattern of strings in the binary.

You can download the bin checker script here.

Once I get some free time I'll post about the second Java exploit and reverse the payload.

Tuesday, October 1, 2013

Sweet Orange In Action

This content has moved to

In this write up we will examine an operational Sweet Orange Exploit Kit. The focus will be on the exploits delivered and the behaviour of the exploit kit.

The Drive-By

The Sweet Orange kit that we will be examining was using an iframe injected into a compromised website to load the exploit landing page. We can see that the iframe has clearly been injected as it sits above the <!DOCTYPE> tag.

The Exploit Kit Landing Page

The iframe loads the exploit kit landing page which contains some fairly simple obfuscated javascript and a Java applet. The landing page doesn't use any browser/plugin profiling to tailor it's exploits, but the server does use the user agent string to filter out un-exploitable os/browser combinations. If the server deems you un-exploitable you get a nice 404 error (this may also be used to avoid detection).

Once we de-obfuscate the javascript we can see that it's written a Java JNLP applet tag to the document. The JNLP applet tag includes a BASE64 encoded JNLP file in the "value" parameter (see ref. here). There is also another applet on the page that does not use JNLP. This writeup will focus on the JNLP applet as it targets victims who are running Java 1.7 while the second applet targets Java 1.6.

Once we decode the BASE64 JNLP file we can see just what this exploit kit is up to. We can see the parameter "__applet_ssv_validated" has been set to "true" which is a Java security warning (Click2Play) bypass released on April 24, 2013 (see ref. here).

Inside the Exploit

With the Java security warning safely circumvented the exploit kit is free to run the applet. Let's take a closer look at the applet JAR file "CNOeJXH.jar". We can see there are a few classes in the JAR and a file called "wgSqXvtqE.mp4". Spoiler alert: we find out later that the mp4 file is just a cleverly obfuscated class file.

Let's start by decompiling the main class "piXDw.class" and go from there. Once we decompile the class files we can see that they are obfuscated. At first these look pretty difficult to decipher but upon closer inspection we can see there is just some junk code added (all of the Math.ulp assignments are junk) and there is some string manipulation. To illustrate I've included a snip of some obfuscated code before de-obfuscation.

After we de-obfuscate we can see the init() for the applet simply checks to see if the victim is running Java 1.7+ then calls a method "wnYoY(piXDw pixdw, Class aclass[])" from "GVep.class". Lets investigate further.

Taking a look at "GVep.class" we can see that it reads in the mp4 file, de-obfuscates it, then transformed it into a binary file and loads it. We will get to just what is inside the mp4 file in a minute but for now we have spotted the exploit that is being used: CVE-2013-2460.

Well this is interesting, let's take a look at the "wgSqXvtqE.mp4" file and see if we can't extract the class. At first we see we will need to de-obfuscate the ascii by removing "------------|||||||||||||||||||||||||||||||||||||".

And now we are left with what appears to be an ascii representation of the hex bytes of a class file.

We can use some python to quickly convert this into binary and decompile into it's original java.

Judging by the similarity of the exploit structure to other examples of "Sweet Orange" we can assume that this is some variation of the Sweet Orange exploit kit. An excellent writeup on the the kit can be found here

Now that we have confirm that this is indeed CVE-2013-2460 what happens after the security manager is disabled? We can see that there is one line of code after the security manger has been disabled, let's start there. 

If we work backwards we can see that "String as[]" contains the applet params.

Let's decrypt these parameters and see what we have (you can download a copy of my terrible python script here).

ParamDecrypted Value

If we follow this example all the way through we can see that the malware constructs a url request like so in order to download the binary payload (the count.exe parameter number is randomly generated) . 

After some manual testing it was confirmed that the "count.exe" parameter is not required to obtain the payload. 


Before we move on to behavioural analysis we will recap what we have learned so far:

Behaviour and Indicators

The exploit kit uses dynamic DNS provided by under the domain "". The kit uses a subdomain generation algorithm to generate a new subdomain every few minutes. Old subdomains are unregistered making research a bit more difficult. After tracking the subdomain generation for 24h it is confirmed that all subdomains that have been used resolve to this IP: (AS12695), not a big surprise. 

A list of identified domains can be found below.

The url pattern for landing page:

The url pattern for the payload binary is:

The payload is also re-generated every few minutes. It is UPX packed and has a low VT hit rate (about 5/46 for each new generation). Once I have some more time I will take a closer look.

File MD5Virus Total
50e073712917e5cc1c53005dc377bdb0 virustotal

Zip of some payloads can be found here.


Updated indicators and analysis can be found here.