As most of similar obfuscation attempts, first a function is defined, called OAEC86 (as you will see, absolutely all variables have similar names which makes them more difficult to read for a human). At the end, that function is called with a big string as the input parameter (the obfuscated content).
Replacing document.write() with alert()
As the code has been stripped down of spaces, it’s difficult to analyze so I added some spaces and tabs to make it more human readable. There is one interesting variable that gets declared immediately at the beginning of the function:
When I saw this I immediately remembered another diary I wrote some time ago (http://isc.sans.org/diary.html?storyid=1519), when I analyzed a similar thing, but this one goes a bit further.
So, the variable above gets its content from the arguments.callee.toString() call. This function returns back a text string which contains the whole called function, from the first line to the last one. A thing I found before was that there was a big difference between Internet Explorer and Mozilla in handling of white space, however, as you can see in the example above, that doesn’t matter as all non-word characters are stripped out with the replace() call (\W) and then converted to upper case. It's nice to see how attackers fixed this so it works correctly (from their point of view) in both IE and Mozilla.
So, after executing this call, the variable A112FA will contain the following string: “FUNCTION0AEC86T1F0AVARA112FA…”. You can see the beginning part of the code here.
As you can probably guess at this point in time, the function actually uses itself to deobfuscate the content. This way the author made sure that you can not change the function. However, this still doesn’t explain why the browser hangs when you change the the document.write() call to alert(). The answer lies further down.
Without analyzing every line of the code (that’s left as an exercise for you, if you are interested in this area), I’ll just explain why the browser hangs.
The big for loop in the code performs various permutations which deobfuscate the code. There is a while() loop in the code as well, which loops until the Q3A988 variable is different from zero. Now, when you change the document.write() call to alert() it will also cause this while() loop to keep looping (as Q3A988 will never have zero) which will in turn cause your browser to hang.
So the first method from the original diary is a no go here. Lets try with the second method.
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
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:
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.I will be teaching next: Web App Penetration Testing and Ethical Hacking - SANS Munich February 2022
Mar 5th 2007
|Thread locked Subscribe||
Mar 5th 2007
1 decade ago