EH-Net

Fortinet have recently posted a new article (http://blog.fortinet.com/booby-trapped-javascripts-threaten-malware-analysts/) 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 (http://infosanity.blogspot.com/2009/04/booby-trapped-javascript.html) 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?....)

I've been seeing a greater amount of Javascript malware in the wild recently than I had before, but I haven't seen anything this cunning.  In fact, almost nothing I've seen has tried to do any real obfuscation.  I'll certainly be careful not to substitute print() for eval() though in the future.  Now all we need is a function to make sure that the print function has not been overloaded and we'll be back ahead of the malcode writers...

Thanks for the heads up.

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

Sorry, bit ambiguous there. I meant that I don't think anyone will be surprised that Javascript is starting to take steps to mess with an analysts toys, I used malware/VMware detection as a comparison, not a specific ability of the javascript.

I'm not aware of any javascript ability to detect virtual environment, similar to the red pill techniques etc. If anyone knows differently, let me know.

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

I was doing some research on this as well.   I found a few ways to detect vmware, including some nifty assembly code.   I tried and could not port any of it to javascript.   I am not an expert in javascript, but I find it limiting.   It just doesn't have the necessary access to memory like C does.  I am sure that with a nice ActiveX control, you can detect it

BTW, dean, nice signature tag.

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

I've had an interest in obfuscated javascript for several months because I was "got" by the technique and had to reinstall my OS!  I managed to get the malicious code and deobfuscate it manually and just wonder if the technique used (via RDS.DataSpace object) and detailed here:

http://spamwars.com/dl/javascript_malware_delivery.pdf

might be of use when doing a pen test?  If you were on the network and had a page containing the code on a web server under your control, a target machine could browse to the page.

I doubt it would need to be obfuscated but just wonder if any AV might react violently.  I guess there are techniques which could be used to bypass tha AV.  Is this likely to add to the battery of techniques that the experts here might use?

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

Thanks dean - that's exactly the sort of thing that was going through my mind.  I'm relieved to know that my idea (for using this in a pen test) wasn't completely ridiculous!

I'll dust off my books and take the purposely-modified snippets that you provided to see if I can come up wth something that I can use for testing purposes in a VMWare network.