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:
VT: 31 / 43
VT: 1 / 43
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.