Chinese Pack Using Dadong’s JSXX VIP Script

Another week, another pack. But this one is using Dadong’s JSXX 0.41 VIP obfuscation script which makes the task of Javascript deobfuscation a more difficult than the others. We’ll get to that in a bit but let’s talk about the exploit pack itself first.

This exploit pack calls up three exploits across several files. There’s numerous references to “gondad” in the script so we’ll call this “Gong Da Pack” (according to translation sites, “gong da” means “attack” in Chinese). Here’s the main page and the start of the exploitation process:

Near the top of the screenshot above, you can see that it iframes “ff.html”. This page calls up a Flash exploit (CVE-2011-2140).

The second page it iframes is “i.html”. It loads up a MIDI file which exploits Windows Multimedia Library (CVE-2012-0003).

Finally, in one of the obfuscated content, it calls up a JAR file that exploits Rhino (CVE-2011-3544). You’ll see this at the end when we deobfuscate the script.

If the exploits are successful, “Gong Da Pack” drops two executables onto the client’s PC:

Filename: top.exe
MD5: DAA26AC034C368CE43B7EF1F952DAD01
VT: 31 / 43

Filename: topx.exe
MD5: 2FBC5B68C1D744610CD583FA366DFE6C
VT: 1 / 43

Now let’s talk a little about the script obfuscation. Prior to this pack’s discovery, I’ve never heard of “Dadong’s JSXX 0.41 VIP” Javascript obfuscator. I tried searching for the obfuscation program, script, or service but I couldn’t find anything (if anyone can share, please email to me).

Next I tried to get more information about the obfuscation technique and see what others had to say about it. I didn’t find much but apparently, this obfuscator has been used to hide exploits before. I also found two programs that tries to deobfuscate the scripts but both fail on this particular version. Seems like another cat-and-mouse game is going on between the author(s) and researchers.

Here’s the main page again and you can see the reference to the obfuscator:

This is one clever piece of code which takes the blob of hex at the top and turns it into exploit code but does so in a way that any kind of tampering of the deobfuscation script below causes it to return gibberish instead.

What the author has done is made the deobfuscation script tamperproof (kind of like using the callee function) where an addition, deletion, or change of any character will cause the “decryption” key to be modified. How is it doing that? By using the value of each of the characters in the deobfuscation script. Nice!

Here’s what happens if you try to modify the script to deobfuscate it. The variable “vTeXx3″ contains what we want to see so we try to view its value. We replace “IPUk4(vTeXx3)” with “alert(vTeXx3)” as seen here:

And this is the result:

Let’s try again but this time we intercept “IPUk4″ (which is set to execScript — similar to eval) and route the variable to “alert”. However, we need to be mindful of what the code is doing so we will change “IPUk4″ to “IPUl3″ (increment “k” and decrement “4” which is a wash) and add the alert outside of the “VXWBks7″ variable like so:

When we execute the script, the deobfuscated text appears:

And it’s here that we see the Java Rhino exploit.

This entry was posted in Exploit Packs, Malscript and tagged , , , , . Bookmark the permalink.