Fortinet have recently posted a new article detailing some new anti-analysis techniques they have seen used by javascript malcode authors.

Couple of new techniques being used: first is fairly basic, adding debugger specific code into the malicious script to cause different operation inside a debugger/sandbox than when run in a browser. Nothing too unusual there similiar to VM detection used by full-blown malcode, and as Javascript is source, this is more an annoyance than a problem, but may catch out less experienced analysts (or those that haven't had their morning coffee. In the long run this may be a beneficial change, as the added commands have no/limited legitimate use outside of annoying analysts debugging attempts, then only malicious scripts are likely to contain them, making filtering/scanning detection easier. Of course the additional commands could be obfuscated to hide their true purpose....

Which leads us to the other change. Command de-obfuscation techniques can be as simple as replacing the eval() method with print() causing the script to spit out it's inner workings in a more readable manner. Some malicious code is starting to overload the print()  method with the malcode author's own code (and who wants to execute that code?) Potentially this would be capable of doing anything, the Fortinet example shows a somewhat deadly combination of ls and rm to give an analyst a bad day.

Similar analysis over at InfoSanity with additional links to further sources for those wanting to look at this in more depth, my primary question though is: Is this something people are commonly seeing the wild?

(P.S. I need to take note of this, could have caught me out in the past when I've been away from my lab and 'bored' or 'curious'. After all javascript should be fairly harmless, right?....)

How does javascript (in the browser?) detect that it is in a VM?

I spend a lot of my time with web-based malware, the kits for distribution, etc.. and while I've seen a lot of different obfuscation methods, I don't know if it would be possible without the users permission to exec js/java that would determine if you're running in a vm or not.

The authors are making assumptions that a researcher may use rhino or njs and will set up code to exec cmds through the app, as discussed in the article link that was part of the original post.

I've seen code that uses everything from chr(), ord(), arguments.callee(), encode(), replace(), rand(), string splitting, adding non-ascii characters to the page and custom encryptors to obfuscate JavaScript. But the cool thing is that however they do it, the decrypting routine needs to be included in the js or vb. Or just use a site like this: http://www.iwebtool.com/html_encrypter

Here is a sample of an encryption routine from mpack, a malware distribution webkit:

/dean

here you go:

really stupid way to detect a vm using javascript:

http://carnal0wnage.blogspot.com/2009/04/detecting-vmware-with-javascript-or-how.html

/dean

Most web based malware takes advantage of the various ClassID's that are part of the RDS.Dataspace Objects. Still works great especially with IE6. IE7 will prompt when the control is loaded. Look at the MS06_014 patch for more info about it.

Post I did a while ago on using it in a pentest:

http://carnal0wnage.blogspot.com/2008/08/owning-client-without-and-exploit.html

Depending on your payload AV may or may not react but any good network IDS will flag on it. This object is used in AJAX a lot so you'll likely see some false positives too.

/dean