Analyzing a New Exploit Pack

A new exploit pack has recently appeared and is getting a decent amount of drive-by traffic. This pack employs several exploits and includes two different social engineering ploys so there's something for everyone.

This pack can be primarily found on the kein.hk domain so let's call this the "Kein Exploit Pack". Here are the parts of this pack that we'll be analyzing. As you can see, the majority of the exploits used in this pack is outdated but they have little AV coverage.

The entry page (which is random text) first calls up an external JS file. If you're an IE user, the external Javascript recreates an AV scan. It will eventually prompt you to download a malicious executable which is being delivered via another server.

In the background, an iframe opens up. The iframe'd webpage, as seen below, does a few things: 1) opens a Java applet; 2) opens another iframe, and 3) opens a PDF file depending on what Acrobat version you're running.

If you're not running IE then you'll see a fake YouTube screen which will eventually try to get you to download a Flash update which is the same malicious executable.

Most of the code in the Java applet is readable so we can see that it is exploiting the latest vulnerability. But as luck would have it, JD-GUI can't open an important class file. The underlying code indicates that this class file has been XOR'd with 0x0A.

So let's go ahead and do that. We can now see the contents of this class file which takes in a URL input, writes out the incoming data to a file, then executes it (or registers it as a DLL).

Going back to the main HTML file we saw earlier, we notice that there was obfuscated Javascript present. Let's clean that up. It seems straightforward enough until we notice the "callee" function. Based on the script's logic, it collects all of the alpha characters from the script, determines its length, then uses each of its characters to decrypt the blob of hex. Any tampering of the script will result in an incorrect decryption.

Since the script only uses alpha characters, we can use that to our advantage and deobufscate that hex code easily. We need to carefully make a change to the script, from this:

return uxoDGz.join('');

To this:

_return=uxoDGz.join('');

Then add this to the bottom:

<script>document.write("<textarea>"+_return);</script>

Here's what it should look like:

What we've done is re-route the output to an external script that dumps its value to a textbox.

The deobfuscated script reveals that it determines which version of Acrobat the user has then gives them the appropriate PDF exploit. Both PDF files uses the same obfuscation technique which is to swap characters around. This appears to be good enough to get past most AV scanners.

When we deobfuscate it, we can see that it concatenates base64-decoded values with NOP sleds and the shellcode.

Here's the list of exploits used by the "Kein Exploit Pack":

• CVE-2007-5659 - Acrobat Collab.collectEmailInfo
• CVE-2008-2992 - Acrobat util.printf
• CVE-2010-0188 - Acrobat LibTiff
• CVE-2011-2110 - Flash AVM
• CVE-2012-1723 – Java Applet Field

And here are the results from VirusTotal:

File: dacCILV.pdf
MD5: 6938e7888e057794b0238351928db343
VT: 4/42

File: VCnpR.pdf
MD5: 0296d40f6efb173f1f2cff396f603f7f
VT: 5/41

File: mehMcQxhE.jar
MD5: 5c2b9fbf62804ba80b08433be94bd2df
VT: 3/40

File: Main.swf
MD5: c7d98d9b5d353f17fa50837af8751048
VT: 2/42

File: scandsk.exe
MD5: b8249924126b8245d6cac4119a58e307
VT: 7/42

MD5: e67fdafa45b788b1a998c75402b0be21
VT: 9/42

Posted on: 08/15/2012