Archived Blog
Malicious Code Evolution from IE Zero-Day Exploit Code
03.19.2010 - 6:00 AM
We know that every security company tries to detect exploits, and malware authors try their best to avoid it. Code evasion is the key point in this endless war, and the following 3 aspects are what hackers like most and are still focused on:
- Core Code Obfuscation
Core code is the core of the malicious code, where the main purpose of the attack resides. Typically it is a piece of shellcode which will download and execute remote files after successful exploitation. By obfuscating core code, the real intent of hackers is hidden right in front of your face. - Algorithm Code Obfuscation.
Algorithm code is the helper part to ensure that core code executes. Actually algorithm code is the pick of the basket in the whole exploit code and people will pay large amounts to get it. Normally it is some JavaScript code to set up the exploitable environments. Hackers may encrypt this part to make their code less fingerprinted and hence avoid detection. - Code Position Obfuscation.
When checking for malicious code, people often first try searching the code in script and iframe tags, which is where malicious code usually resides. However, other HTML tags are also a good place to embed bad code. Typically hackers choose P and DIV tags as their first choices; sometimes they change their taste to use INPUT and TEXTAREA tags. Another common way to hide code is code fragmentation, which is putting the malcode in separate files; of course the reason for this is to avoid detection.
In this latest IE zero-day attack, malware authors have so far made many different versions based on the original one. Let's take a look at them, from easy to difficult. The first snapshot below shows literal core code and algorithm in normal script tags.
The code above is very easy to read and understand, so some people might not be satisfied with this. Hence they obfuscate the core code a little bit and the algorithm code slightly, but it is still readable. You may or may not be familiar with this trick, but we have come across it a lot - refer to Gumblar for more details. This kind of obfuscation could be done in various ways and we have quite a few examples; this blog includes 2 easy cases so you can see what they look like.
Up to now, we can easily understand what the core code will do, but some hide-and-seek-loving people have introduced a new way to make things more complicated. They put the malcode in a separate file or even many files, so people might not notice it at all, let alone read or understand it.
The next snapshot shows that hackers are still using the hide-and-seek tricks, but moving the obfuscated core code to HTML tags.
Some very simple tricks are applied in the following case: all function and variable names are randomized, making the whole code appear unreadable.
Finally, in this example the algorithm is obfuscated which makes it even harder to read. It looks complicated, right? You will never know what the real content is unless you decode it completely. However, this is still not the worst case we have encountered. The Beladen attack that happened last June has shown us how this kind of trick could be improved, and a multilayer obfuscation we have found almost brought despair to people who love manual deobfuscation.
So we have seen many obfuscation techniques so far, but it is not a problem to us since we luckily have our super tool Gustav to help. Gustav simulates the execution of inputted HTML and JavaScript code and outputs the final code to us, saving a lot of time in the process. We will introduce more details about Gustav later.
Security Researcher: Tim Xia
