A look at the new Gameover Zeus variant

Background

Zeus, also known as Zbot is one of the most notorious and wide-spread information stealing banking Trojans. It was first spotted in early 2007 and since then over the years it has evolved into a very sophisticated malware family with such features as:

• Man-in-The-Browser keystroke logging
• Form grabbing
• Web injects
• Kernel-mode rootkit update
• Custom Peer-to-Peer (P2P) protocol for Command and Control communication
•     Domain name Generation Algorithm (DGA)
• Mobile Zeus, also known as Zeus in the mobile (Zitmo)

In June 2014, the U.S. Justice department launched an international law enforcement operation dubbed 'Operation Tovar'  to take control of the Gameover Zeus P2P Botnet. This operation turned out to be a success with the shutdown of the Botnet activity and related Cryptolocker infection cycle.

New Gameover Zeus variant

We started seeing infection reports involving a new Gameover Zeus variant early last month (July 2014). The major infection vector still remains the same where the Cutwail Botnet is being leveraged by the cyber-criminals to send out spam e-mails with a malicious attachment. The malicious attachment on most occasions masquerades as a financial PDF document in order to lure an unsuspecting user into opening it. This is achieved by a combination of a fake PDF icon and double file extension as common file extensions are hidden by Windows unless disabled by the user. Some sample filenames we have seen includes:

• Invoice.pdf.scr
• E-statement.pdf.scr
• Securedoc.pdf.scr

Once the user opens the attachment, it downloads the latest Gameover Zeus variant from a predetermined location as seen below in the unpacked payload memory:

Decrypted payload showing hardcoded URL

Download of latest Zeus variant

The downloaded Gameover Zeus variant further drops a copy of itself and runs it as:

• %Local Settings%\Temp\Eqxav\epoxs.exe

It also drops and runs a batch file to delete the original executable file from the %TEMP% directory:

"C:\WINDOWS\system32\cmd.exe" /C "C:\DOCUME~1\zuser\LOCALS~1\Temp\MLZ6405.bat"

@echo off
:akkaoz
del /F /Q /A RSHAIL "C:\Documents and Settings\zuser\Local Settings\Temp\mss3.exe" >nul
if exist "C:\Documents and Settings\zuser\Local Settings\Temp\mss3.exe" goto akkaoz

It creates the following registry entry to ensure persistence upon system reboot:

• HKCU\Software\Microsoft\Windows\CurrentVersion\Run\ Epoxs = "%Local Settings%\Temp\Eqxav\epoxs.exe"

The bot further injects code into multiple system processes including Explorer.exe. It creates a remote thread that is responsible for running the Domain name Generation algorithm and connection to the Command & Control (C2) server. Upon successful connection to a C2 server, the bot will download the latest configuration containing list of banking URLs and web-inject plugins. Below is the list of sample domains that were generated by the DGA thread:

• 1vi2us1syijqh1gmhwuxmr1iwt[.]com
• 1i5ch6c1rvz8y7rp9bkbzme3v4[.]net
• cul4hleyh07we1j2cc1ma964m[.]org
• 1l9asc2b3mmf3dpth1d1ct987[.]net
• w7vld0891u1d1lhbvh17b5lfo[.]com
• 1aipcuziz5kqakplu9c5upujb[.]org
• uccm0d1tdx38tonp9vh1jo2fq4[.]biz
• i8gwl8hwjijd1ldh10ovl05iu[.]org
• qxvt8m18q3wbf12992zo16mx3rb[.]com
• 14h98mo70orwoj8gf9j1a6sz4r[.]net
• hv1eifdb3pxw1fp250cnpe34f[.]biz
• 17f2nku9i6zbtzs1u1v1pih3ie[.]net
• 1hn3lbe1qwdo6k1qm3b0q1yklg1r[.]com
• ukoizw1g9vy8c1jxlh7610o2h8z[.]net
• zja38vktoo9i1yc8xk16sq76p[.]biz
• 1ahnharg5apuxe5oeex1qy80ql[.]org
• 1qozjh16vj4xz1rhcr31x7hrtf[.]com

It also enumerates through all the running processes and steals information from them if any of the following strings are present:

Decrypted list of finance & banking related strings

Feature evolution or de-evolution

The previous Gameover Zeus variant used a P2P command and control protocol in addition to a failover domain generation algorithm (DGA), to establish connection with a C2 server. However, this newer variant does not feature a P2P command and control protocol, instead it is falling back to the old DGA with fast flux tactics to hide the C2 servers. This in our opinion is a step backward as P2P was a more resilient feature.

Another step backward that we observed is the absence of the kernel-mode rootkit that was pushed out as an update early this year by the Gameover Zeus operators in the previous version. The rootkit made removal of the malware extremely difficult and disabled multiple security features on the infected system.

DGA active domains and Command & Control server trends

The bot's DGA outputs 1,000 new unique domains each day but the Gameover Zeus operators are keeping the domains that they intend to use confidential until a few hours before the actual day when they get registered. Below is the mapping of DGA domains that were registered by the the Botnet operators and were actively resolving to C2 servers in past seven days:

Command and Control server IP information and Geo-distribution map:

Active C2 Server location and ASN information

Below is the trend of C2 callbacks we have intercepted in past seven days:

One of the most active C2 server IP addresses also appeared to be the Control server for a Zeus in the mobile (Zitmo) variant in the past as seen below:

This further re-affirms the fact that the same gang is involved.

Conclusion

This new Gameover Zeus variant certainly appears to be the beginning of a comeback attempt for this notorious Banking Trojan Botnet family, but in many ways it has been a step backward. The number of infections are still very low and it has a long way to go to reach the infection rates observed prior to the Government takedown. Zscaler ThreatLabZ will continue to monitor the activities of this Botnet family in the coming months for active C2 servers as well as any feature updates and will ensure protection for customers.

- Deepen Desai

The Story of a Trojan Dropper III

Introduction:

In previous posts (story of Trojan dropper part I, II) we performed both static and dynamic analysis on the threat and also developed a broad idea of what the malware was doing in it’s initial stages. We now set out to investigate the reason behind the crash of the dropped file (“Adobe.exe”) and at the same time we want to retrieve the payload from this particular malware sample.

Analysis:

Let’s go ahead and debug the file. This file (“Adobe.exe”) was found to be packed (custom variant) and the unpacking routine is similar to the approach detailed in part II of this post, so let’s skip all the gory details and dive right into it.

After unpacking the entire binary in memory, control is transferred to a newly unpacked region at the address "0x401634". Now the action begins from here and we get our first decryption routine, which is a simple 1-byte XOR with a static key as seen in the image below which reveals more code

Figure 1: Decrypt code

If we carefully look at the new code below, we can observe that it is riddled with JMP instructions and occasionally we find a few garbage values. The code is crafted in such a way that it resists disassemble attempts which makes reverse engineering the sample more difficult and somewhat painful.

Hidden in between these JMP’s in plain sight is an instruction that is familiar to us by now(i.e the instruction to fetch the address of PEB (Process Environment Block)).

Figure 2: Fetch address of PEB

At this point we can only speculate on why the malware needs the PEB address. Moving further in the code, we encounter another decryption point that is exactly same as the first one, which decrypts more code. Now the control is transferred to the newly decrypted code.

Figure 3: NtGlobalFlag (anti-debug)

In the image above, we have an interesting bit of code. Recall that the malware already collected the address of PEB. At this point, using the instruction CMP DWORD PTR DS:[EDI+68], ECX (here EDI holds the address of PEB which is "0x7FFD4000" and ECX holds a constant 0x70 ) a comparison is performed, after which a JNZ instruction decides the fate of the control flow.

Here we get our first glimpse of the anti-debugging technique employed by this malware. The instruction CMP DWORD PTR DS:[EDI+68], ECX compares the value of the ECX register (i.e. 0x70) to the location in the PEB structure known as “NtGlobalFlag”. The field is set to a value of “0x70”, if the process is spawned under a debugger.

In our case, this is true since we are debugging the file. Finally, the JNZ instruction at "0x401511" is not taken, which lands us in an invalid region in memory, thus triggering the anti-debugging. Let’s jump here and continue with our analysis. We now have another layer of decryption, which reveals more code after which, as usual, control is transferred to this region.

We then reach another piece of code, which is revealed only if we keep up with the control flow.

Figure 4: File-path, name identification (anti-debug)

The above code uses “strstr” to look for a string named “sample” anywhere in file path of our currently debugged file. If found, “strstr” returns a pointer to first occurrence of search string(i.e "sample") in file-path, or else it returns zero. The malware then checks the return value in EAX and takes a conditional jump in the form of JE instruction at "0x401135". If the jump is not taken, the code lands in “ExitProcess”, a call which terminates the process.

This is the second anti-debugging technique the malware employs, although not-an effective one in my opinion considering the odds of a file-path or malware name containing the name “sample”.

Figure 5: GetVolumeinformation, Volumeserial (anti-debug)

Again, here we have another anti-debugging technique where the malware retrieves the Volumeserial number using the API GetVolumeinformation and compares it with  “0CD1A40” and “70144646”. If either comparison matches, the code jumps to the ExitProcess call.

Another anti-debugging technique follows immediately thereafter in the form of “EnumSystemLocalesA”. The first argument that "EnumSystemLocalesA" accepts is a pointer to the callback function. Here the malware does a neat trick. If we look at the code below, at address “0x401179” a constant “0x2” is pushed onto the stack, which is followed immediately by a CALL. 

When this CALL is executed, it pushes the return address onto the top of the stack (which is "0x401180") and the EIP (Instruction pointer) now lands at the "EnumSystemLocalesA" call. Now if we observe the stack, the value on top of the stack is the return address, which naturally becomes the callback function address for "EnumSystemLocalesA" . When the "EnumSystemLocalesA" API is executed, control falls to the callback function, which continues the execution of the code. 

Figure 6: EnumSystemLocalesA (anti-debug)

Let's now continue our debugging from the address “0x401180”. Not far from here, yet another anti- debugging technique is uncovered. This time the malware retrieves the ‘Diskname’ from the registry. 

Figure 7: Diskname (anti-debug)

"RegOpenKeyExA" (HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Disk\Enum)  and  "RegQueryValueExA" then uses “strstr” and searches for signs of a virtual environment such as “Xen”, “Vmware”, “Qemu” and also looks for string “virtual”.

Figure 8: Search vm strings(anti-debug)

Once the malware detects a virtual environment, it changes the control flow and land us in an invalid memory region. If we play along, we can observe something interesting here.

Figure 9: Adobe.exe crash

There we go. We can finally reproduce the crash that happened during the first stage of our analysis.
Ok, so a through binary analysis is often not so straight forward after all !!!

Figure 10: sandbox identification(anti-debug)

Let’s move on and see what surprises the malware has this time. Below, we can see anotherpiece of code that checks for a DLL name called “sbiedll” . Here, the malware checks whether it is run in a popular sandbox called “sandboxie”. If found, as usual, the malware bails out.


Immediately afterward, the malware performs a decryption routine to reveal compressed data, which is again packed with aplib and below we can observe the aplib unpacking routine which decompresses the data to a PE file.

Figure 11: Aplib decompression routine

Soon after, control is passed to the newly decompressed file. Below, we can see the new file being executed.

Figure 12: New PE-file in memory

Debugging further, we can observe the malware revealing the final trick that it has up it’s sleeve ,which I will explain in the next post in this series.

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”

Analysis of multiple exploits

The most common type of malware seen in Blackhat spam SEO is the fake antivirus. But I also see other types of exploits from time to time. This week, the same malicious page came up on different domains: 4rukel.cz.cc, 4lofs.tk, 1polidsf.co.cc, 1barede.co.cc, 3timesto.tk, 4greaix.cz.cc, 4krudi.cz.cc, etc.

This page is interesting because it uses exploits rather than social engineering to install the malicious code. Below are the details of the exploits / malicious code.


Heavy obfuscation

The JavaScript code is heavily obfuscated. It cannot be de-obfuscated by a simple copy-paste of the code into Malzilla, some of the decoding has to be done by hand.

Original malicious code

One common technique, used in this page, to break the JavaScript de-obfuscation tool is to make references to the DOM. On this page, part of the JavaScript code is included in a textarea HTML tag. It is retrieved and executed later with code like this:

eval(document.getElementByTagName('textarea')[0].value);

While executing the obfuscated JavaScript code, new HTML elements are added to the page, and used to store values or JavaScript code retrieved again later in the JavaScript code.

First de-obfuscation pass generated new obfuscated JavaScript code!

Fortunately, all the JavaScript code is inline. There is no external file, which always make the de-obfuscation harder.


Multiple exploits

Like many malicious pages, several exploits are included on this page:

1. 2 malicious Java applets, using different techniques for Internet Explorer and Firefox
2. PDF exploit
3. Quicktime '_Marshaled_pUnk' Remote Code Execution Vulnerability
4. Heap spray attack
5. Internet Explorer MDAC exploit
6. Internet Explorer "iepeers.dll" exploit
7. 3 Flash exploits

Part of the code for the Java exploit

I believe these exploits come from different sources because the coding style of the various functions varies greatly.


This malicious page tries the different exploits until one is successful. Users need to make sure they keep both their browser and their plugins up to date.

-- Julien

PHP deobfuscation

When I was analyzed the PHP scripts used for the "Hot Video" pages, I had to find a way to deobfuscate the PHP code. There are many tools and online services to obfuscate PHP, but very few to deobfuscate it.

Obfuscated PHP code: one big eval()

PHP obfuscation is generally done with:

• Base64 encoding
• Encoding strings into hexadecimal and octal values
• Assigning functions to variables
• Multiple calls to eval()

Evalhook

This code can be deobfuscated by hand, but it takes multiple iterations and can be time-consuming. Fortunately, Steffan Esser wrote evalhook to make deobfuscation easier. His article about the tool describes how it works. Basically, it is a library used with PHP to render code that is executed by the eval() function.

There are no instructions for compiling the source code, so it took me a little bit of time to understand all the necessary steps to use the code on CentOS5. Here are basic instructions to compile the code.

First, you need:

• PHP >= v5.2
• php-devel
• PHP Zend Optimizer

CentOS5 comes with PHP 5.1, so you will need to obtain a newer version from another YUM repository. I used AtomicCorp to install the new PHP version and Zend.

Then, run these commands:

tar xvfz evalhook-0.1.tar.gz
cd evalhook
phpize 
./configure
make
sudo make install

Now, you can use the evahlhook library to deobfuscate PHP files, as described in the original article:

$ php -d extension=evalhook.so encoded_script.php

The only inconvenience I had to deal with when using evalhook, was that the resulting code still has strings encoded with hexadecimal and octal. So I wrote a small (and ugly!) Perl script to parse these strings into ASCII. Download strings.pl if you're interested in using it.

perl strings.pl source.php target.php

-- Julien

Public Service Announcement: EFF Coder's Rights Project

I ran across this today, and thought it was just too valuable to not make mention of. The EFF has a "Coder's Rights Project" that includes FAQs and guides related to the legalities of security disclosure, reverse engineering, and ethical hacking/testing for security vulnerabilities. They are absolutely fantastic layman summations of all the legal nuances (US-centric) that you should be aware of while pursuing any of these legally grey endeavors. The FAQs and guides concisely lay out how the various US laws, such as DMCA, copyright, and Computer Fraud and Abuse Act can come into play during security testing, disclosure and reverse engineering efforts. The EFF material also provides very good advice regarding how to reduce/limit your risk.

If you had any doubt, it should be thoroughly dispelled by the time you are finished reading the material on EFF: testing software and web sites for vulnerabilities is NOT a legally granted right. The law does NOT recognize the concept of "ethical" hacking. As such, the true key to ethical hacking is the confidence that the person you are hacking is not going to legally pursue you after your activities. Hack only when you have permission to do so. Without permission, you are putting yourself legally on the hook regardless of your morals and non-malicious intentions.

If you are still steadfast in your desire to perform security tests without explicit permission in a manner that you feel is morally clean, then you need to ensure that you keep all your actions above board and follow through on your non-malicious intentions. If you do find a problem, report it immediately. Taking the time, for example, to dump the entire user database along with passwords and play around with it for a few weeks before you finally disclose the problem is not going to be seen as aligned with clean intentions. Also keep in mind that law enforcement agencies are very keen on people trying to hide their identities while undergoing these types of activities; using anonymizers and the like is not looked upon favorably and as such could push your activities to the 'blackhat' end of the spectrum rather than the 'whitehat.' If your intentions are good and you have nothing to hide, then don't hide it.

Above all else, if there is any doubt, then just don't do it.

Until next time,
- Jeff