Thursday, July 25, 2013

Styxy Cool Exploit Kit: One Applet to Exploit All Vulnerabilities

Styxy Cool Exploit Kit is a particular kit because it is a "merge" between Cool and Styxy Exploit Kit.

Here we will cover only Java related exploits so, if you want to know what vulnerabilities it has and why its called Styxy Cool go check Kafeine's post here.

Between 8 and 9 of July two interesting things happened:
  1. Jar size increased from 5Kb to 28 Kb
  2. Payload (Reveton) disappeared from fiddler 

Let's take a step back and analyze the exploit chain from 8 of July.

The first page /abortion-success_conductor.php display a bounch of phrases about Yahoo France, but what really does is checking if you have some vulnerable Java plugin installed in your browser.

The page contains an instance of PluginDetect version 0.8 and an obfuscated javavascript code at the end.

What does this code do ?

It takes the content of the textarea from /objection_confident_sulphur.html since in the middle of the first page there is an iframe pointing to that one.

Then converts two chars per time into an int base 30 and converts the result into a character with the help of String.fromCharCode.

Once deobfuscated.

If you are vulnerable the next and last page executes the malicious applet. In this case i was using Java SE 7 update 17 so /test_membrane.html contains CVE-2013-2423.

Jar size

The size of the applet is increased by 25 Kb because now it contains four Java vulnerabilities and not one as usual.

If we open the malicious jar with JD-Gui we can see an if/else statement inside the Main.class where it tries several exploits.

If one these successfully set the SecurityManager to null (disabled it), it runs some code inside MainAdd2 class, which is supposed to download and execute Reveton.

This new way of using Java vulnerabilities, has certainly an advantage when it comes to obfuscate the code, because you don't have to FUD all four jar but just one.

Missing Reveton

The other interesting thing is the disappearance of Reveton from fiddler. Below is part of the image from 9 of July posted at the beginning.

As you can see Reveton is never downloaded but you still get infected.

Thus, how the payload is downloaded ?

My first thought was that it was embedded into the jar, but after a deep search i haven't found any trace. Looking better after the infection, i noticed an uncommon V.class file inside the Temp folder.

Part of disassembled V file.

Mistery solved, this java compiled class is responsible of downloading and executing Reveton.

How this class is executed ?

At the beginning of the init function useInner variable takes the value of usein applet parameter, but since there isn't any parameter called usein, its value will be null.

The following line calls dgsdgDG from MainAdd2.

Once again there isn't any parameter called val, so getUrls it's executed.

After obtained the URL of the applet and substituted the extension jar with exe?e=15, a last function called run is executed. Its purpose is to write V.class into Temp folder and call it through the command "javaw -cp <path_tmp_folder> V <reveton_url>".

There isn't a lot of code to deobfuscate, but you can find whole V.class here.

Jar is available on Kernelmode previous registration:

Maybe a better title for this post is: One exploit to rule them all, one exploit to exploit them, one exploit to infect them all and in a botnet bind them.

# Edit 1
Balck Dragon and Blackhole 2.1 have the same behaviour.

Related post: