Anatomy of an MS08-078 exploit, part 1

Often times I'm asked what actually happens to a system when the browser is exposed to a modern web exploit.  By "web exploit", I'm referring to the type of exploit where your browser only need visit a site - no user interaction (like opening a file) is necessary.  I thought it might be interesting to take a look at a real-world implementation of the new IE exploit (MS08-078) to see what the payload was.  I'm going to break this up into two posts just because of the size of the screenshots.

In this example, I looked at hxxp://b81.8800.org  / hf / x / ieee.htm (don't attempt to load this, although the exploit page is not wget-aware) 

The first level of the page uses some obfuscation to get around signature detections.  Below you can see the page is decoded and executed with Javascript:

There are lots of ways to decode this.  PHP is my tool of choice, although we could certainly put the browser to work doing it in Javascript.  I anticipated doing more parsing later, so I started in PHP.  Here is a simple way to do the decoding:

$arr = explode("\\", $long_string_of_encoded_characters);
foreach ($arr as $chr) {
    $unencoded .= chr(octdec($chr));
}

There were two seperate segments of Javascript.  The first, when unencoded (and a few of the variable rewritten) shows the following VBScript:

The second is double encoded, so you need to run it through the loop again, and when you do you see an almost ctrl+c/ctrl+v from the public exploit:

Right away we can see more than one web exploit in play here - this is the norm.  There are rarely less than 5, and often more than 10 exploits on a single page.  The more there are, the greater the chance that the payload will be executed.

More about what it did to the OS and on the network in the next post.

Alex Lanstein @ FireEye Malware Intelligence Lab
Questions/Comments to research [dontoverp@yforteixeira] fireeye . com