Authors
We recently came across a very interesting suspicious web page. The HTML page of course contained malicious code that linked to the Trojan. However, it was a separate HTML page inside the benign one – the authors of the code went against HTML standards, and put in an extra <html></html> container.
What’s surprising is that browsers (we checked using Internet Explorer, Firefox and Opera) don’t have any problem processing a page like this. On the other hand, who would expect malicious users to observe standards?
However, this isn’t the main issue. We’re interested in the script that the malicious users integrated into the web page. Of course, the script is designed to make analysis as difficult as possible, using techniques to obfuscate the JavaScript.
The script itself looks more or less like this:
Nothing particularly surprising here – the majority of scripts like this can be decrypted without analysing all the steps taking to manipulate the code. You just have to find the part of the code which prints to the original web page in order to run the payload. And in this case it’s the document.write() function:
If we modify this, we can see the decrypted code for the payload. Change document.write(P7E87DE2) to textarea1.innerHTML=P7E87DE2, with textarea1 being the HTML textarea container on the copy of infected page that we deliberately created on a local harddrive. Now we can see what the script does in the textarea field. Which gives us the following:
And it seems that this script doesn’t print anything. This is the first impression – but a closer look at the script turns up this string:
What does this mean? It’s very simple – this function gets its own code, and transforms it into a ‘key’ text string which is made up of letters and numbers. Within the function this string is used to generate the payload i.e. what gets entered in the text area depends on the body of the function itself!
As a consequence, if the code is modified in the slightest way, the result generated will be completely different, and may be completely nonsensical – this is what happened on our first attempt. It’s a sort of defense mechanism against modifying the body of the JavaScript function. I haven’t seen anything like this before in JavaScript – it’s pretty smart.
However, it’s possible to get round all of this simply by getting the same string from outside the function, assigning the variable q2854da60, which should be contained in the key string, to the result.
If you’re an analyst doing this, and you’re trying to get the script from inside the encrypted code, then you might suddenly find that when you open a correctly crafted page in order to get the hidden contents of the script, the browser will freeze. I’ll just stick my two cents in here, and point out that this is the moment when your computer will get infected.
The construction used by an analyst within the <textarea></textarea> tags is crafted in such a way as to not only infect users’ machines, but also to infect the computer of an analyst who’s trying to get to the payload code by printing it to textarea! The construction looks like this:
So if the code is placed inside the textarea container, the code will close the textarea tag and add an iframe container – the browser uses this to load an external script which contains the exploit Trojan that infects the system.
This example shows very clearly how virus writers are combating antivirus professionals who want to protect rank and file users. And if a virus analyst makes the smallest error, his or her machine will become infected. And that’s one of the reasons that I love my job – because it teaches me that there’s no room for error!
Authors
From the same authors
In the same category
Active anti-reverse techniques in Javascript