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”

In depth analysis - decoding HTML Style tag based malicious Iframes

Injecting clear text or obfuscated malicious Iframes has become a common attack vector. By taking advantage of known/unknown vulnerabilities in web servers or applications, an attacker can inject a malicious Iframe which will point to a malicious domain hosting malware. Attackers continually modify the way they inject malicious Iframes, leveraging various encoding techniques, to hide their malicious code from security products. They also do this to add complexity for security researchers trying to decode the attacks in the first place. Recently, we came across another malicious Iframe attack which was carried out with the help of HTML style tags. Here is the screenshot of an attack found on an infected website:

Attackers have been able to insert a malicious style tag and malicious JavaScript code at the bottom of the page in two separate locations. With the help of some JavaScript code and JavaScript DOM objects and properties, the attacker has injected his obfuscated malicious code. This code is difficult to decode with the help of tools like Malzilla or online services like jsunpack.org. This blog will explain how to decode such malicious hidden Iframes by properly reading the code step by step. Let’s start by formatting the code.

The above code contains one style sheet defined by “#c19”. After further inspection of the code, we determine that variable “WnmaQ” is defined with function “YYSXc()”. After that, there are 3 other variables defined, with 2 of them containing garbage or useless functions and then there is a call to the original function by accessing “Wnmaq.YYSXc()”. This means this code will call the function inside the first defined variable which is “Wnmaq”. Now let’s format that function and break the code into parts so that we can decode it step by step. Here is first part of the script,

Looking at the code above, we can see there are some garbage or useless variables and functions are declared for no purpose, such as variable “l”, “v” and function “nB()”. There are many such garbage variables and functions declared throughout the script. They are never used for any significant purpose. So we will skip those dirty useless variables, functions. We will only concentrate on useful variables, code and functions used for decoding this malicious JavaScript. There is variable “g” declared with a “new Date()” function, which is in the form of an array. The first array element is a year and second is a month and so on. Then variable “o” is defined with a “g.getMonth()” function which means variable “o” will contain value “10” which is the second array element and called as month. Then variable “r” will contain the string “from10e”. The value 10 in this variable and is replaced by the “CharCod” string, so finally we have an interesting string in variable “r”, which is nothing but “fromCharCode”. Variable “i” is defined with object “document.styleSheets”, which will return list of style sheets. Let’s decode the second part of the main script,

The above “for()” loop will actually extract the array data from the style tag defined earlier. I have put some comments inside the image to better explain the components of the code. Initially, variable “q” is matched with elements corresponding to the style sheet rule with the help of the “.selectorText” property. If the loop matches the string”#c19” of the style sheet, the code will continue. The next variable “w”, actually retrieves the array from the style sheet rule with the help of the property “.style.backgroundImage”. Now, we finally have useful variables. At this point, we should test to ensure everything seems reasonable. Let’s create a simple “test.html” file and add only important variables, style sheet tags and code inside the HTML file. We will test what the variable “w” will contain after above code with the help of “alert()” function. The sample HTML file is shown below:

We have removed everything and added only those variables which we decoded earlier. We should get array values from style tag. Here is what the variable “w” will contain after running above file.

So, the second part of the script just retrieved values from style tag. This shows our analysis is on the right track. We will keep this “test.html” file as it is and will add more interesting code after additional analysis. Let’s look into next part of the main script:

The above code explains that variable “c” will contain string called “split” and variable “m” will contain array values separated by commas. The variable “k” will contain a value which will be the array length divided by 2. We will add all above 3 lines of code into our “test.html” file and will then alert the value of “k” for our purposes. The variable “k” will contain the value 90 if you run the modified “test.html” file. The above code also contains garbage code as mentioned earlier. Let’s decode the last part of the main script,

The above code is the last part of the main malicious script. Here we will finish the decoding of the code and will come to determine the main malicious code behind this. As analyzed earlier, variable “k” will contain value 90 and this “for()” loop will run 90 times. The function “parseInt()” is used to obtain the exact integer. The variable “o” will contain the month of the date object, which is 10. The variable “r” contains the string “fromCharCode”, which we found earlier. So finally variable “j” will look like,

j += String[“fromCharCode”][rZ];

The loop will continue and variable “j” will be appended with characters retrieved from above expression. This is the main code behind the entire script. The last variable “kW” contains the JavaScript function “eval()” and then there is call to this function with parameter “j”. This tells us that the malicious content will evaluate the code inside the variable “j”. Let’s add this “for()” loop inside our earlier “test.html” file and we will alert the value of “j” to find out the hidden code. This is what our final “test.html code will look like:

We have only added useful variables, loops and JavaScript code in the above file. We have removed useless variables and functions from the main script. Now here is what you see when you run the above file:

The malicious Iframe pointing to malicious domain is finally revealed. The attacker has created the malicious JavaScript code with the help of a style tag to generate a malicious Iframe. This process can be difficult to analyze and tools or services may fail due to the complex nature of the code and various tricks used by attacker. However, if you have a little patience and good eyes, it is very easy to decode such malicious JavaScript code by understanding the flow of the code. That’s it for now.

Happy Decoding

Umesh