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
Posts
