What better way to start a new year than with some JavaScript deobfuscation!

Couple of weeks ago, one of our readers, Rick, found a compromised server with an interesting “addon” planted by the attacker. The attacker added a relatively simple PHP script – nothing we have not seen before. The PHP script was more or less standard for such attacks: the first part checks the submitted User Agent as well as if the request came from a list of predefined network ranges (you probably guessed it – those that belong to search engines and AV companies). If this is true, the PHP script just displays a fake 404 not found error page.

You can see that part of the code, which is self explanatory in the picture below:

Now, if this test passed, an interesting part comes. The PHP script simply prints a huge, heavily obfuscated and very nasty JavaScript blob.

This huge part is about 300 kb in size (!!!) so, as the first thing when encountering such JavaScript, I always try to use the wonderful Wepawet service (available at http://wepawet.iseclab.org/). In case you aren’t familiar with Wepawet, it allows you to submit JavaScript (and PDF and Flash) files for automatic analysis. During years, Wepawet became increasingly good in deobfuscation of such files so I was surprised to see that it failed to analyze the submitted JavaScript file. VirusTotal was no good either (as expected, 0/42). So time for some hacking ...

After trying typical tricks with defining parts of the document object (see more about these methods in Lenny’s diary at http://isc.sans.edu/diary.html?storyid=12157) I noticed that the JavaScript file I was analyzing depended on way too many properties/methods from the document object. While it is certainly possible to define all them, I decided to skip that tedious part and go directly with a debugger – after all, nothing gives you more thrills than the possibility to infect your own machine :) (of course, this was done in an isolated VM).

While people usually do not like analyzing such potentially malicious JavaScript files in Internet Explorer, I have to admit that I like the Internet Explorer’s developer tools addon *a lot*. So, to get this into a debugger, I normally paste the JavaScript file into a very simple HTML document that just defines the body. I also add the keyword “debugger;” to make sure that the debugger will stop at the beginning (so I don’t end up infecting my own machine). After this has been done, we just need to start debugging and open the HTML file in Internet Explorer. The Developer Tools will automatically break at the beginning:

We can now easily go through the code, setup further break points and use all the Developer Tools’ powerful debugging options such as variable and call stack inspection. When I reached the end I was a bit disappointed – the JavaScript file tried to retrieve an URL that was not available any more. It also depended on certain elements in the original web page which was unavailable to me as well.

Back to obfuscation – while it managed to evade analysis in Wepawet, I remember that I’ve seen such methods before. If you have been a constant reader of SANS ISC you maybe remember the diary I wrote back in 2009: http://isc.sans.edu/diary.html?storyid=6142. The attackers used the same method here – very, very long and complex if/then/else statements which end up calling various DOM methods and properties. While this method has been known for a while, it is obviously still very effective, especially since it allows practically unlimited combinations that an attacker can use in order to obfuscate their malicious JavaScript code.

--
Bojan
INFIGO IS