There is little doubt that exploit kit (EK) developers are continuing to improve their techniques and are making exploit kits harder to detect. They have heavily leveraged obfuscation techniques for JavaScript and are utilizing browser functionality to their advantage. Recent exploit kits such as ‘Fiesta’ and ‘Rig’ for example, have been found to be using DOM based JavaScript obfuscation. In this blog I will demonstrate a simple approach to de-obfuscate DOM based JavaScript obfuscation.
Before we dive in, it’s important to understand the difference between older EK’s such as Blackhole and Incognito versus newer ones such as Fiesta and Rig. A key difference between them is the way they de-obfuscate code in the victim’s browser. The newer approach de-obfuscates JavaScript snippets and stores them into DOM by building an element tree. Older EK’s by contrast were heavily using JavaScript functions such as ‘eval’and ‘document.write’ to de-obfuscate the JavaScript.
Again, I’ve added a ‘console.log’ function to get the de-obfuscated JavaScript, which later will be appended to DOM tree and will be executed.
Before we dive in, it’s important to understand the difference between older EK’s such as Blackhole and Incognito versus newer ones such as Fiesta and Rig. A key difference between them is the way they de-obfuscate code in the victim’s browser. The newer approach de-obfuscates JavaScript snippets and stores them into DOM by building an element tree. Older EK’s by contrast were heavily using JavaScript functions such as ‘eval’and ‘document.write’ to de-obfuscate the JavaScript.
Let’s start by taking a look at a Rig EK sample.
Rig EK page:
Rig EK page:
 |
| Heavy obfuscation of Rig EK JavaScript code |
Unlike most EK’s, instead of running plugin detection code first, it instead starts by checking for the presence of Kaspersky and TrendMicro antivirus (AV) programs. If any of the AV driver files are found on the victim’s machine, the exploit execution stops. In order to check for the presence of these driver files, the EK uses the ActiveX object ‘Microsoft.XMLDOM’. The routine labeled ‘df3z’ does the inspection.
 |
| AV driver checking code |
Driver file information:
Take note of the following statement,
The above value of variable ‘sdf43w’ is used later on in the JavaScript.
If no AV driver for Kaspersky or TrendMicro is found on the victim’s machine, the code then initializes the de-obfuscation routine. First the Javascript creates a ‘div’ element and appends it to the DOM. The remaining JavaScript, which is heavily obfuscated contains exploit code targeting vulnerabilities for Java, Flash and SilverLight browser plug-ins.
First JavaScript:
Let’s take a look at the JavaScript code to understand how it’s building the DOM element tree.
 |
| First JavaScript |
To summarize,
- Function ‘alz’ concatenates a string passed to it and assigns the concatenated string to the ‘ty6’ variable. This is later used by the de-obfuscation routine.
- Element ‘dn3d’with a type of “script” is created.
- De-obfuscated (final) JavaScript is assigned to the element ‘dn3d.text'.
- Element ‘dn3d’is appended to the ‘document.body’ i.e into the DOM tree for later execution.
To get the de-obfuscated code for this JavaScript we need to get the value of ‘dn3d.text’. For that I added a line called ‘console.log(‘dn3d- 1: ‘ + dn3d.text)’. I am using the Google Chrome browser to complete de-obfuscation and all of the analysis is carried out in an isolated environment. To get the console logs, you need to open developer tools in Google Chrome browser. Apart from console.log you can also leverage other JavaScript functions like ‘alert’ or ‘document.write’ to get the de-obfuscated code
.
De-obfuscated code for first JavaScript segment:
 |
| JavaScript Console Output |
The beautified version is shown below:
Here you can see the value of ‘dn3d.text’ is a JavaScript, which is then, is added into DOM tree. This JavaScript contains function ‘dsg45’, which creates element ‘bd6’ of type ‘div’ and appends it to DOM tree and also assigns a passed value of variable ‘hgd1’ using property ‘innerHTML’ of the created element.
All the remaining obfuscated JavaScript is structured like the aforementioned code. The following shows the second snippet of JavaScript, which actually contains the malicious applet code.
Second JavaScript snippet: Exploits Java vulnerability
Again, I’ve added a ‘console.log’ function to get the de-obfuscated JavaScript, which later will be appended to DOM tree and will be executed.
De-obfuscated code for the Second JavaScript snippet:
 |
| Malicious Applet Code |
You can see above, the malicious applet code is assigned to variable ‘jg67fgf’. This value is then passed to JavaScript function ‘dsg45’, which was appended into the DOM tree by the first JavaScript snippet (see above).
Similarly the remaining two JavaScript snippets are de-obfuscated using the aforementioned method.
De-obfuscated code for the third JavaScript snippet: Exploits Silverlight vulnerability
 |
| Malicious SilverLight Code |
De-obfuscated code for the fourth JavaScript snippet: Exploits Flash vulnerability
 |
| Malicious Flash Code |
To get all of the de-obfuscated code above I would normally need to conduct code analysis to find the ‘dn3d.text’ variable, which contains the de-obfuscated JavaScript code. This would require fair bit of code analysis and understanding of JavaScript and DOM. As such, I wanted to find a simple solution which would provide all of the de-obfuscated JavaScript at once. Fortunately, I was able to identify a shortcut. Since all of the de-obfuscated JavaScript is stored in DOM tree, we can crawl the DOM tree and get the element value once for all of the EK script has executed. For this, I wrote a simple JavaScript routine which I call ‘domWalkerAndDeobfuscator’. By putting this code at the end of the EK sample, we can get all the JavaScript being stored into DOM, which in turn contains the de-obfuscated code.
domWalkerAndDeobfuscator at the end of EK:
 |
| domWalkerAndDeobfuscator |
‘console.log’ output after appending domWalkerAndDeobfuscator:
 |
| JavaScript Console Log |
Malicious Applet code:
 |
| JavaScript Console Log |
Malicious Silverlight code:
 |
| JavaScript Console Log |
Malicious Flash code:
 |
| JavaScript Console Log |
My trick worked and gave me the full de-obfuscated code of the Rig EK sample. This increased my curiosity and tried the same ‘domWalkerAndDeobfuscator’ on the Feista exploit kit sample.
Fiesta EK:
 |
| Fiesta EK |
De-obfuscated code obtained from ‘domWalkerAndDeobfuscator’ through console.log for Feista EK:
 |
| JavaScript Console Log |
The Feista EK also contains exploit code for Java, Flash and SilverLight plugins.
Adding a simple DOM walker (crawler) script made the job easy of de-obfuscating DOM based obfuscated EK far easier. I’ve tested the approach with samples of Rig and Fiesta so far and every time was able to get the de-obfuscated code in seconds instead of doing the heavy lifting required for manual analysis.
Conclusion: Previously with older EK’s it was easy to de-obfuscate the code using many online tools and with manual analysis, but due to the introduction of DOM based obfuscation techniques the difficulty has increased. Many tools are failing to de-obfuscate the code for newer EK samples. Fortunately, the approach of walking the DOM solved the issue in seconds.
Pradeep
