De-obfuscating the DOM based JavaScript obfuscation found in EK’s such as Fiesta and Rig

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. 

Let’s start by taking a look at a Rig EK sample. 

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

Analysis of a VBScript bot

Introduction:

In the long list of complex threats that we see daily, it is interesting to see malware that is rather simple but effective in terms of the payload that it carries. At Zscaler ThreatLabZ, we recently 

came across one such innocent looking Bot, which targeted our customers. The file arrived as an attachment to a spam email message. The malware was written in VBScript.

Analysis:

Virustotal scan results show 14 out of 50 vendors detecting the malware.

Figure 1: Virus-total Result

The image below shows the malware opened in notepad. We can see that the file is obfuscated. That’s because the file has a “.vbe” extension (a “.vbe” is an encoded VBscript file), which would otherwise have a “.vbs” extension. The encoding support is provided to prevent people from reading the script.

Figure 2: Obfuscated VBScript

To be persistent, the malware copies itself into the startup folder in Windows (Figure 3)

Figure 3: Copy of Malware in the startup folder

Registry entry created by the malware to run itself at the system startup.(Figure 4)

Figure 4: Windows Registry (run entry)

It also adds a copy of itself to the Windows temporary folder (Figure 5).

Figure 5: Copy of Malware in temp folder

Next, the malware attempts to establish a connection to it's server (here wscript.exe is the Script Engine which executes VBScript).

Figure 6: Network communication

To extract more information we need to decode the file and obtain the original malware code in a readable form. Let's have a look at the decoded file.

Figure 7: Malware install code

The image above shows the code that is responsible for adding entry in the registry which 

allows the malware to execute every time the system starts , Also create it's own copy in the startup, temporary folder.

Another interesting part of this malware is it's ability to communicate over the network. The malware can actually receive a set of commands and execute them in an infected machine

At the time of analysis, the server to which the malware communicates seems to be down. Therefore, in order to fully understand how the malware communicates and also to demonstrate how effective and damaging this Bot is, I have decided to create an HTTP server and issue commands to the bot directly.

We can see from the code below, the wide range of commands that can be executed by this Bot. The commands are simple and self explanatory. 

Figure 8: Remote Commands

Let's see the effects of a few of these commands in detail. The “execute” command is capable of executing additional VBScript statements in the infected machine. The “update” command is issued to update the Bot , while “uninstall” removes the Bot entry from the Windows registry and startup folder.

There are also commands such as “send”, ”recv” and “site-send”. Interesting commands include “enum-driver”, “enum-faf”, “enum-process”, “cmd-shell”, “delete”, “exitprocess”.

Let us execute our server and wait for the Bot to connect to us and send information so we can then issue commands.

Figure 9: Malware callback

As seen in the image above, a “POST” request is made with it's path as “/is-ready”, indicating

that the Bot is up and ready. We can also observe information about the infected machine such as “volumeserialnumber”, “computername”, “username”,“operating system type”, installed

“anti-virus name” etc. To retrieve such information, the malware relies on Windows Management Instrumentation (WMI) queries.

Let us issue the command “enum-driver”. This command fetches the drive name and drive type of the infected machine as seen in the image below.

Figure 10: enum-drive

The next command “enum-faf” enumerates and fetches the content of an input directory or drive of the infected machine.

Figure 11: enum files 

The “enum-process” command fetches a list of processes that are running on the infected system.

Figure 12: enum-process

The “cmd-shell” command will allow the attacker to execute all DOS commands on the infected

system.

Figure 13: Execute Dos Command

Those are just a few of the powerful commands that the malware can execute in the infected system. This gives the malware near limitless power to control and steal data from the infected machine. The Bot and all it's communication are blocked by Zscaler.

The story of a Trojan Dropper I

Introduction:

Recently, Zscaler ThreatlabZ  received a suspicious file from one of our customers, which 

was named “OrderDetails.zip”. After extracting the executable file from the archive I have 
performed a virustotal scan  to get some information about the file. At that time, very 
few antivirus vendors had definitions in place, which flagged the file as malicious.

As such, I decided to take look at the file in greater detail. After completing the analysis,
I've  decided to blog about the threat. Given the amount of information derived during the analysis, I've decided to divide the blog into multiple parts.

Figure 1:  virus total results

Modern day malware generally implements some kind of packing or obfuscation on the binary, in order to evade antivirus detection. Hence, it’s a good idea to determine which packer may have been used while analyzing the file. In order to do this, I implemented a popular tool called PEiD to check for the existence of a known packer.

Figure 2:  PEiD results

As we can see above, PEiD was not able to pick up anything from this file, but that doesn't mean that the file is not packed. Let’s have a closer look at the file.

While going through the file sections, one of the sections (.data) contained an unusually large amount of data, which at first glance gave the impression that it is obfuscated. This is an important clue and something we have to keep in mind while debugging the file.

Figure 3:  obfuscated data

While looking at the resource section, we can see that the file icon resembles that of a PDF file, which adds to our suspicion. Also, the file is not digitally signed.

Figure 4: File icon at resource section

Lets go further and execute the file. When doing so, I was greeted with a crash report where Windows was telling me that “Adobe.exe” had crashed during execution.

Figure 5:  windows error report 

We knew from the beginning that this was not a proper PDF file and would not therefore work with Adobe Reader. Let’s now look to determine where Adobe.exe exists in the file system. A 
Windows file search reveals Adobe.exe inside the temp folder, which when executed, produces exactly the same result as was shown above 

Figure 6: dropped file named adobe.exe

At the same time, a Wireshark capture was not able to output anything that was of interest.At this point we have adequate evidence to proceed with additional debugging, which i will explain in detail in the 2nd part of this blog post. The story of a Trojan dropper II

Figure 7: wireshark packet capture

The story of a Trojan Dropper II

Analysis:

Lets analyze the PE file in detail and see what it’s up to. Like most malware, this sample was packed and in order to properly analyze it, we must begin by unpacking the binary. Keeping this in mind, I began by debugging the file, hoping to find the reference to the data section in order to determine precisely where the encrypted portion of data was to be found.

Fortunately, I was not disappointed and was soon able to find the reference point.

Figure 1: Obfuscated data 

After further debugging, we are able to see the code decrypted in memory. The decryption occurs in multiple iterations, until the data is completely decrypted.

Figure 2: Decryption of obfuscated data

Now we have a full view of the decrypted code in memory. The portion that was decrypted contains position independent code (i.e shellcode).

Figure 3: Decrypted data in memory

Since the code is decrypted in memory, we can assume that at some point, control will be transferred to that region, which in this case happens immediately. We also can see that the VirtualProtectEx API is used to change the protection of the memory region and by doing so the malware will be able to execute and manipulate the memory.

Figure 4: Change memory protection

After this occurs, control is transferred to the region by an instruction of JMP EDI. Here, EDI will hold the address to which EIP (instruction pointer) lands and we can see that it is the same portion of the 

code that was decrypted earlier.

Figure 5: Control transferred to new code

There's an interesting bit of code here if we look at first couple of instructions on the landed region. We can see a NOP instruction, followed by SUB EAX,EAX and a CALL and POP EBX. If we carefully observe the address that is called, it is that of the POP EBX. This is a common technique found in shellcode and file infectors where one needs to get the address of the region that is currently being executed.

When this CALL is executed, it pushes the return address onto the stack (in this case it is the address of POP EBX). Now POP EBX is executed, as that instruction pops the value from the top of the stack to EBX. The address is then added to a constant of 0x33, to point to the region that is then decrypted by the decryption loop. This reveals more code, after which a JMP instruction transfers the control to the newly revealed code.

Further, I was able to identify another interesting piece of code here. The code below retrieves the address of the PEB (process environment block) and navigates to PEB_LDR_DATA->InLoadOrderModuleList, where it retrieves the names of the loaded modules (DLL’s) .

Figure 6: Fetch base address of kernel32.dll

There's another catch here. The malware looks for specific DLL’s (in this case kernel32.dll), but instead of using the string kernel32.dll to compare with retrieved module names from the PEB, it carries the hash of the DLL names and then calculates the hash value for the retrieved module names and compares them. This allows the malware to make minimum noise and avoid some antivirus rules.

Figure 7: Dll name hash 

Once the malware gets kernel32.dll, it then retrieves the base address of the kernel32.dll, which in this case is 0x7c800000. Now, using the PE file format, the malware moves to the export table of kernel32.dll, as illustrated in the code below,

Figure 8:  Finding exportaddresstable of kernel32.dll

Looking at code above the instruction MOV EBX, DWORD PTR DS:[EAX+78], lands us at the datadirectory-->exportaddresstable of the kernel32.dll. The malware then retrieves the value and adds it to the imagebase (ie 0x7c800000) in order to reach the export table, where it retrieves the address of the exported function. Here too, the malware never uses the names of the function, but instead it uses a stored hash.

After further analysis, we stumble onto another piece of code, which copies data again from the data section to a newly allocated memory region.

Figure 9: Copy more data 

Investigating further, we see that this data is decrypted to reveal what looks like some sort of an address table.

Figure 10: Address table 

The table has significance as it is used as an address calculator, To calculate the address of

the region from where it copies bulk data, Which is further decrypted to form what looks like

a compressed file.

Figure 11: Compressed data

And there it is. Moving ahead, we land in the decompression routine, which quickly reveals that

the data is compressed using “aplib”.

Figure 12: Aplib decompression routine

Once the decompression is completed it does some familiar actions by flushing out the bytes of the original EXE file starting from the imagebase 0x400000 and copy the decompressed data to its new imagebase (i.e 0x400000)

Figure 13: Copy decompressed PE -file 

Finally using “LoadlibraryEx” and Getprocaddress the IAT is rebuild in the memory after which the control is transferred to the new code at the address 0x401021

Figure14: Rebuild IAT in memory

The job of this code is limited. It writes a PE-file which is embedded within itself into the temporary folder as “Adobe.exe” using the api “GetTempPathA”.

Figure 15: Transfer control to OEP

In the end, the file (Adobe.exe) is dropped in the temp folder and executed using the API “ShellExecuteA”.

Figure 16: Execute dropped "Adobe.exe"

A dummy PDF file is also written to the current directory named “Bestellung.pdf”. In a subsequent blog post, we will see why the malware dropped this PDF file.

That’s all for now. In the next post, we’ll continue the analysis of the dropped file “Adobe.exe”