Fortinet have just released a nice blog post highlighting and analysing some changes in the obfuscated Javascript they are seeing.
De-obfuscating javascript is (should be) straight forward as it is interpreted on the fly and you have the source code available (as opposed to a compiled malware binary requiring more advance RE techniques, as discussed in previous posts).
One basic change has been to include some debugger specific command calls, such as quit(), which stop the code from been executed in debugger or sandbox (Malzilla is a common favourite), but is generally ignored by most browsers. More of an annoyance than an actual problem, as the analyst has the source these extra commands can be removed manually, but will add extra time to the analysis and may catch out less experienced analysts. In the long term this may be a short-lived change and may prove to be beneficial to the prevention of malicious Javascript. As these commands should only useful when run under a debugger rather than a browser, such commands shouldn’t appear (or be very uncommon) in non-malicious Javascript. As such it may be possible to scan for and filter for Javascript containing these commands.
A slightly more worrying change (from an analysts perspective) is that it appears the malcode authors are growing smart to analysis techniques. As highlighted by Fortinet, a common method to gain de-obfuscated Javascript code is to replace the eval() calls with print(), causing the malcode to de-obfuscate itself and present the analysis with readable commands (sometimes requiring several iterations).
Fortinet have found examples of malicious Javascript overloading the print() function with code of their own. Potentially this code could do anything, the example detailed by Fortinet shows a deadly combination of commands ‘ls’ and ‘rm’ (assumes the analyst is running ‘nix) to give the analyst a really bad day.
One more reason to stick with lab environment when dealing with any potentially malicious code or files, even something as ‘harmless’ as de-obfuscating javascript.
Andrew Waite
Update: Discussion on The Ethical Hacker Network in response to this generated some interesting discussions and resulted in this very nice article by Dean for the Carnal0wnage Blog on detecting VMWare environments in Javascript. As Dean points out it’s a fairly pointless exercise from a malware perspective, but interesting non the less.
— Andrew Waite
P.S. Thanks to Lenny Zeltser for mentioning the post, may have missed it otherwise