Spammed redirects using anti-emulation tricks

A few weeks ago Richard posted a blog about malicious HTML attachments we were seeing in spam. Well, the attacks have continued since then along much the same lines. For example:

Current attachments are being blocked as Troj/JSRedir-BV.

As noted before, if the victim opens the HTML attachment, the embedded script will run within the browser, and redirect them to a another remote web page (hosted within a legitimate but compromised site). Sophos products block this page as Mal/Iframe-Q. From there, the attack is two-fold:

• META redirect to some spammy site (Canadian Pharmacy and similar)
• malicious IFRAME loading further content from another site

In this post I wanted to highlight one of the tricks used in the malicious JavaScript within the HTML attachments. The script is minified and peppered with junk code, hindering readability, but after prettifying and removing the junk code, it is fairly simple. The decryption function is called via setTimeOut, and consists of a simple xor.

There is a cunning little trick in the script, designed to break JavaScript emulation tools. By calling the decryption routine via setTimeOut, the script is able to ensure there has been a sufficient delay. Most emulation tools will tend to ignore the setTimeOut delay, resulting in an incorrect xor key being generated, and decryption failing.

When correctly deobfuscated, you can see that the script redirects the victim with a location.href:

These attacks are just another example of the growing number of tricks being used within malicious JavaScript to evade generic detection and hinder automated analysis techniques.