This article was transferred from the @herrcore blog.
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 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
The Exploit Kit Landing Page
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 reference 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:
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
http://www.noip.com under the domain sytes.net. 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: 22.214.171.124 (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).
|File MD5||Virus Total|