Fortinet Blog | News and Threat Research

Legitimate – and sometimes renowned – web sites are more and more subject to code-injection attacks; and it’s not rare today to find your every day site injected with malicious JavaScript code, which sole purpose is to silently redirect all visitors to malicious servers “behind the scenes.”

What happens on those servers is called a “drive-by-install” in the jargon, and results in malicious executable files being (again) silently pushed and run on the victim’s computer.

Details on the drive-by-install process, while interesting, are out of the scope of this post, which instead focuses on the initial, “silent redirection” code injected in the targeted web site.

This injected code is today systematically obfuscated, to evade manual and automatic methods of detection. Such obfuscation methods are very interesting to look at, as they are always evolving, in an ever-going race-to arms between malicious code authors and security analysts.

Our most security-oriented readers are probably already aware of the heavy use of the JavaScript “argument.callee” function made by malicious code authors to slow down the analysis of their obfuscated code.

As it name says, “argument.callee” returns the source code of the function that called it. For instance, the following code:

function my_example() { alert(argument.callee) }

Would pop up a message box displaying the content “function my_example() { alert(argument.callee) }”

Malicious code authors use this somewhat odd function for fun, profit, and above all to irritate malicious code analysts: indeed, the decryption function of the obfuscated code uses as a decryption key… argument.callee! or in other terms, its own code.

Consequence: should an analyst change a single character in the decryption function, the decrypted code will be bogus, thus valueless.

Typical bits that an analyst may want to change in the decryption function would be “eval” for “print”, which eases the whole analysis a good deal.

Of course, there are ways for analysts to get around this, like for instance automatically replacing “argument.callee” by a static variable containing the expected key (i.e. the callee source code).

Malicious code authors seemed to become aware of it lately, as we started to see attempts to masquerade references to argument.callee. This is a “real life” example:

eval('a+rDgDu,mBeDn[tDs[.,c,aDl+lDe+e['.replace(/[D\[B\+,]/g,'')).toString().replace(/[^@a-z0-9A-Z_.,-]/g,'')

And so continues the race to arms…