Spammers seem to be adding layers of obfuscation to their malware attachments in an attempt to evade spam filters that look inside attachments. Most malware attachments come in the form of executables, or, increasingly, Word files with malware-laden macros. These files are usually zipped, a common method of passing files via email. Most email gateways can unzip attachments to inspect the underlying file, so this simple layer of masking the file's true nature is becoming increasingly useless.
We've seen some recent examples of malware attachments that are adding an extra layer of obfuscation to make inspecting attachments more difficult. We've seen attachments that are double-zipped (whereby the executable is zipped and that resulting zip file is zipped again). We've also seen a Word document with macro-malware embedded inside a PDF file. This blog post discusses another type of double-obfuscation we observed in a JavaScript attachment.
The example we'll take a look at purports to attach a copy of a requested passport. The email body looks like:
Having a zipped attachment doesn't raise too many red flags by itself. When this attachment is unzipped, it reveals an obfuscated JavaScript file. This is not unusual in spam. Most zipped JavaScript malware attachments create something like an ActiveXObject which does an HTTP "GET" to download malware from a specified site. Since JavaScript is plain text, it's not too hard for spam filters to unzip the attachment and look for certain strings in the JavaScript file like "ActiveXObject" or "Wscript.Shell", which would indicate intent to download files. In this "passport" example, once this first layer is de-obfuscated, it doesn't contain any of these tell-tale strings. It looks fairly innocuous, like this:
While it does create an ActiveXObject, it only creates a "Scripting.Dictionary" one, which is fairly benign -- not much here would be suspicious to spam filters. The tricky part comes in the random-looking text assigned to the four variables at the top (the highlighted lines). When the JavaScript attachment is run, it creates another JavaScript file that does actually retrieve malware. This first JavaScript file merges the four variables, going through the resulting string and only printing every other letter to the new JavaScript file. For instance, the string "fnugnicptlioosnr" becomes "function" and "ooypfehns(s"qGdEzTk"t," becomes "open("GET",". This method allows for the replacement of the skipped letters with different ones for each spam run, preventing spam filters from looking for the obfuscated string. The last few lines use programming tricks to obfuscate the fact that the final line is really an eval call with the second script in a single variable. This runs the second script, which when properly formatted looks like this:
This looks much more like a typical script that results in the download of malware. The script visits the web sites listed at the bottom, retrieves what would seem to be pictures (judging from the URLs) but are in reality executables (as evidenced by the script saving the files as .exe files in the TEMP directory). The downloaded files are then executed by the "Run" statement. The malware files it downloads are in the MSIL Trojan Injector family.
This type of multi-layered obfuscation is often used by exploit kits. When an unsafe link is clicked, the kit uses this sort of trick to provide the landing page code that's rendered in the browser in an attempt to evade AV scanners and web gateways looking for suspicious traffic. As spammers try to transfer these tactics to email attachments, safe email practices become increasingly necessary. As always, DO NOT open attachments from senders you don't recognize, and be suspicious of any attachment you weren't expecting. If needed, verify with the sender before opening.