A Taste Of Reality

The usage of anti VM/Sandbox detection tricks is becoming more common nowadays. These are used by malwares to detect that they are running inside a sandbox.

However, most of the tricks used in malwares make it evident that they are trying to detect VM. For instance, they look up Registry Keys/Process Names for strings like "vmware", "virtual", "qemu", "xen". If the reverser is stepping through the code of a virus, they can easily make out that this malware is VM-Aware.

I am more interested in methods which detect the VM using assembly language instructions only. There are certain assembly language instructions for which there is a different behavior exhibited by VMWare guest than host operating systems. Tricks that use SIDT, SLDT, SGDT, backdoor interface of virtual machine (VMXh) and others are known.

I was working on finding a new way to detect that we are running inside VMWare. At the same time, I did not want this method to rely on evident strings as mentioned above. After exploring the memory address space of the *.vmem file of my Virtual Machine, I developed a good method.

VMWare has a specific OEM String that looks like: MS_VM_CERT/SHA1/

This OEMString will be present in the SMBIOS. On operating systems like Linux you can view it using dmidecode which is able to extract information from the SMBIOS structures.

On Windows, you can get some information from the SMBIOS using wmic (Windows Management Instrumentation Console).

I noticed that you can also get the same information from the process address space of csrss.exe. Below you can see the result of scanning the process address space of Windows XP SP3 Virtual Machine using the yarascan plugin of volatility framework. It shows that OEMString was found in csrss.exe's address space:

So, we can detect the presence of VMWare by scanning csrss.exe's process address space and looking for the string, MS_VM_CERT. I wrote the following code in C to do this:



Here is the output of the code:


Advantages:

1. We are not scanning for an evident string like "vmware", "virtual" and so on which would give away the trick to the reverser.
2. Currently my code scans for MS_VM_CERT. However, it is also possible to scan for the SHA-1 hash. I have observed that the SHA-1 hash is consistent on most VMWare Virtual Machine instances. This would need to be tested further.
3. Scanning in the memory is much more effective than checking the Windows Registry, Processes or File System artifacts for strings related to VMWare. These can be modified easily by the malware analysts in the VM to prevent basic VM detection tricks from working. However, modifying the OEM String in memory is not that easy.

To test:

1. On different products of VMWare like VMWare Fusion, different versions of VMWare Workstation.
2. By setting the option, SMBIOS.reflectHost = True in the VMWare configuration file.

c0d3inj3cT

Recently while analyzing a virus, I came across an interesting sample. It is a package of several anti debugging, anti sandbox and control flow obfuscations tricks. All these are used to deter the reverse engineering.

Let us discuss them one by one:

It invokes certain subroutines by triggering an exception. It first registers an exception handler. Then it decrypts the code of that exception handler. Once this is done, it triggers an exception by executing a privileged instruction like CLI and STI (both these instructions are privileged in the protected mode).

Since an exception is triggered, the corresponding exception handler from the SEH chain will be invoked. This is a control flow obfuscation trick. Below screenshot shows an exception triggered after executing the CLI instruction. On the stack we can see the exception handler address as: 0x00401610. To continue the analysis in Olly Debugger, we can press, Shift + F9 and pass the exception to the exception handler or we can just set the EIP to 0x00401610.


Inside this handler, it uses a well known anti debugging trick. It checks the value of BeingDebugged field of PEB (Process Environment Block), at offset 0x2. If the program is being debugged, then this field is set to 0x1. There are Olly Debugger plugins available which will patch this value in the PEB structure to protect from such anti debugging tricks. If you do not have the plugin, you can just patch the conditional jump after the comparison.


The below screenshot shows the encrypted code of the exception handler at address, 0x00401577. The decryption routine is an easy single byte XOR decryption routine. Once decrypted, we find an INT 2D instruction after the LOOPD instruction.


INT 2D has a special behavior in Olly Debugger. Olly will skip the next byte in execution as a result of which the control flow is obfuscated. We need to manually set the EIP to the exception handler code at: 0x00401577.


Inside the second exception handler, it again uses a well known anti debugging trick by checking the value of NtGlobalFlags inside the PEB at offset 0x68. If this value is set to 0x70, then the program is being debugged. Once again, there are plugins available to patch these fields in the PEB structure.


Now, it decrypts the code of the third exception handler which is invoked using another privileged instruction, STI.


Inside the third exception handler, it uses the strstr() function to find the substring, "sample" inside the full path name of the virus.

Though this trick is simple, it can be effective since many malware analysts set the name of the virus or the folder in which they store it, as "sample". If it finds this substring, it exits the process using ExitProcess().

The next trick checks the volume serial number of C: Logical Drive by calling GetVolumeInformation(). It compares the volume serial number with: 0x0CD1A40 and 0x70144646. If either of these matches are true, it exits the process.

00401160   817D 00 401ACD00 CMP DWORD PTR SS:[EBP],0CD1A40
00401167   74 09            JE SHORT gvtfifjh.00401172
00401169   817D 00 46461470 CMP DWORD PTR SS:[EBP],70144646
00401170   75 05            JNZ SHORT gvtfifjh.00401177


Next, it queries the following registry key to get information about the Disk.

HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\Disk\Enum

For example, in the case of VMWare the value of the subkey, "0" is set to:

IDE\DiskVMware_Virtual_IDE_Hard_Drive___________00000001\3030303030303030303030303030303030303130

This string is converted to lowercase and then using the strstr() function, it checks for the presence of following substrings inside the above string:

1. xen
2. vmware
3. virtual
4. qemu


If it finds any match, then it exits the process.

In the next trick, it tries to get the module handle for dbghelp.dll and sbiedll.dll files using GetModuleHandleA. If the module handle is returned, then it exits the process. These DLL files are used by common sandboxes like Sandboxie and ThreatExpert.


It also uses a recently discovered bug in Olly Debugger where it does not break at the exception handler when we trigger an exception by calling RaiseException() with the exception code, 0x80000003.

It first registers an exception handler which has the malicious subroutine code and then triggers the exception by calling RaiseException.

In this case, we can manually set the EIP to 0x0040126D as shown below and continue debugging from there:

I wanted to write an article which discusses in depth the method used for hooking the entry point of an API. This method is often used in malwares to alter the behavior of some APIs. Usually the Networking APIs imported from ws2_32.dll, wininet.dll are hooked in this way.

As an example I have taken the Win32/Gepys virus family. The code examples are in assembly. This will help in understanding clearly the method used for hooking.

In order to hook the entry point of the API we need the following:

1. API Address. This can be retrieved by calling GetProcAddress() on the API.
2. Buffer: This buffer will be used to store the first few opcodes of the API along with the jump trampoline. You can get this buffer by calling VirtualAlloc().
3. Malicious Subroutine: This is the subroutine which we want to execute before executing the main API. It will be invoked each time the main API is called from the program.

Now, let's call the API hooking routine:

We need to call VirtualProtect() on both the API and the buffer to mark these regions of memory as PAGE_EXECUTE_READWRITE. We will be executing the code from the buffer as well.

VirtualProtect(buffer, 0x10, 0x40, &oldProtect);
VirtualProtect(api, 0x10, 0x40, &oldProtect);

Now comes the main code for hooking the API. I have explained it with comments:



Once we are done with it, we again mark these regions of memory as: PAGE_EXECUTE_READ.

VirtualProtect(api, 0x10, 0x20, &oldProtect)
VirtualProtect(buffer, 0x10, 0x20, &newProtect)

So, the buffer format is:

[first 5 bytes of the API][E9 - opcode for jump][function pointer - buffer - 0x5]

and the first 5 bytes of the API are calculated as:

E9 - jump opcode
Address = malicious subroutine address - function pointer - 0x5

As an example, if we are hooking the API, ws2_32.gethostbyname with the following details:

buffer = 00D90010
api = 71AB5355 (gethostbyname)
malicious subroutine: 00C8159B

This is how the first 3 instructions of the API look before hooking:

71AB5355 > 8BFF                 MOV EDI,EDI
71AB5357   55                      PUSH EBP
71AB5358   8BEC                  MOV EBP,ESP

Using the above format of the buffer, we know the buffer should look like this for hooking:

buffer = 8b ff 55 8b ec e9 45 53 d2 70

The opcodes in the above buffer correspond to:

00D90010   8BFF                  MOV EDI,EDI
00D90012   55                       PUSH EBP
00D90013   8BEC                 MOV EBP,ESP
00D90015  -E9 4053D270    JMP WS2_32.71AB535A

This jump instruction will redirect the execution to the 4th instruction of the API, ws2_32.gethostbyname.

Also, the first 5 bytes of the function pointer can be calculated using the above method as:

jump opcode: e9
address: 8F1CC241

API after hooking:

71AB5355 >-E9 41C21C8F      JMP 00C8159B    ; malicious subroutine
71AB535A   81EC 14020000        SUB ESP,214

malicious subroutine:

00C8159B   6A 00                    PUSH 0
00C8159D   FF7424 08            PUSH DWORD PTR SS:[ESP+8]
00C815A1   E8 23FDFFFF        CALL 00C812C9
00C815A6   59                         POP ECX
00C815A7   59                         POP ECX
00C815A8   50                         PUSH EAX
00C815A9   FF15 0030C900     CALL DWORD PTR DS:[C93000]
00C815AF   C2 0400               RETN 4

at address, 0xC93000 we have the address of the buffer.

So, the instruction, call dword ptr ds:[buffer] will redirect the execution to the buffer which has the opcodes for the first 3 instructions of the API and then redirects execution to the 4th instruction of the API.

Now, that we have understood this method of API hooking. Let us see how we can detect it.

In the case of Win32/Gepys virus family, it will add the full path of the malicious DLL to the Registry Entry: AppInit_DLL. This will allow the DLL to be loaded into the address space of any new process on the system (it should be linked with user32.dll).

Also, it performs the API hooking only when it is loaded in the address space of a Browser like firefox.exe, chrome.exe, iexplore.exe, opera.exe and so on.

So, to detect this method of API hooking, we will check the calls to VirtualProtect(). Since in API hooking we are writing our jump trampolines to the API, we will check specifically for calls to VirtualProtect() that mark the regions of memory as: PAGE_EXECUTE_READWRITE.

Also, we are interested in those VirtualProtect() calls which are invoked on the API addresses.

I wrote the following Pintool which can help automate this:



Below screenshot shows it detecting the API hooks in firefox.exe:

Recently while analyzing a virus family, I found an interesting way to introduce delay before invoking the malicious code. It also helps in not making evident the location of the malicious code. This can be obfuscated further though.

After unpacking the malware, the first thing it does is to register a Window Class with the name, "Runtime Check" with the Window Procedure subroutine at address, 00402680. It then creates the Window. During the creation of the Window, the Window Procedure is invoked which handles the initial window messages like WM_CREATE.

After the Window is created, it retrieves the message from the Thread's queue using GetMessage() and dispatches it to the Window Procedure using DispatchMessage().

Inside the Window Procedure, it reads the code of the Window Message from the stack and stores it in the EAX register. It then checks whether the window message code is greater than 0xF. If it is equal to 0x113, then it sets up a Timer that elapses after 1 second. Since the last parameter to the SetTimer() function is NULL, the system will post a WM_TIMER message to the queue every time the timer elapses. Each time a WM_TIMER message is retrieved from the application thread's message queue using GetMessage(), it increments a counter. Once the counter is equal to 5, it calls the malicious subroutine. Since the timer is set to elapse after 1 second, so overall delay introduced is approximately, 5 seconds.

Below are the corresponding sections of code:


and here is the code rewritten in C:

if(wind_code > 0xF)
{
    if(wind_code == 0x113)
    {
        counter++;
        if(counter == 0x5)
        {
            call malicious_code;
        }
    }
}
else if(wind_code == 0xF)
{
    // code for handling the WM_PAINT message
}
else if(wind_code == 0x1)
{
    SetTimer(hWnd, 1, 0x3e8, 0)
}

Zeus bot uses some techniques which make it difficult to debug. Few of these techniques are common and used by other malwares as well. I will mention the techniques which I found interesting and worth mentioning. It will help in analyzing malwares which use similar techniques:

1. Code Injection: Like most malwares today, they inject the malicious code into the process address space of a benign system process like explorer.exe, winlogon.exe, svchost.exe and others, Zeus does the same thing. It injects the malicious code into winlogon.exe

At first, it needs to find the PID (process id) of winlogon.exe. To do this, it uses following sequence:

CreateToolHelp32Snapshot() to get the snapshot of all the running processes in the system.
Then it walks through the list of the running processes using, Process32First() and Process32Next() till it finds winlogon.exe.
Once it finds, winlogon.exe, it gets the PID from the PROCESSENTRY32 structure.

This same technique is also used to find svchost.exe PID. It makes sure that the process is running under SYSTEM account by using the following APIs:

OpenProcessToken (with Token_Query access)
GetTokenInformation (Token_User)
LookupPrivilegeValue

If in case the svchost.exe process is not running under SYSTEM account, then it continues to enumerate the processes further till it satisfies this condition.

Now, it needs to open the process with the desired access (CREATE_THREAD|VM_OPERATION|VM_READ|VM_WRITE|QUERY_INFORMATION) using OpenProcess API.

It is important to open the process with this access since we will be injecting our code into it and also creating a remote thread in it.

Once the process has been opened, we receive a handle for it. Now, we proceed to inject the code in phases.

It allocates memory into the remote process using VirtualAllocEx().

It finds the size of the sections, .text, .data, .reloc and .data1 of the malicious executable embedded within itself,  in sequence and then uses WriteProcessMemory to write it into the process address space of winlogon.exe

Now it calls RtlCreateUserThread() to create the thread in remote process.

Most malwares resume execution in the remote process using CreateRemoteThread, ResumeThread and so on. This was one of the features where Zeus differs from the rest by using the not so commonly used API.

One of the key differences between RtlCreateUserThread and CreateRemoteThread is in the way they initialize the context structures (value of the registers, eax and eip). It has been documented in detail here:

http://waleedassar.blogspot.in/2012/06/createremotethread-vs.html

The stack parameters for the call to RtlCreateUserThread look like this:


Since we know the StartAddress of the remote thread (0x00A766F8) in winlogon.exe, we can attach our debugger to winlogon.exe and set a breakpoint at it to debug further.

2.  Remote Thread Execution: The entry point of the remote thread looks like this:


In the remote thread it has a callback function (0x0A766E9) which is invoked using the CreateTimerQueueTimer() function. We get the address of the callback function from the arguments of above API, so we set a breakpoint at it.


This will create a new thread with the start address, 0x0A764E4 which is one of the parameters passed to the callback function.

After creating the necessary files on the filesystem like sdra64.exe, user.ds, local.ds and so on, it proceeds to create another thread with the following parameters:

If we look at the parameter passed to the thread start function above, it is a structure that looks like this:

 
In this structure, we have the address of a subroutine, 0x00A76361 which is the main controller routine. We will discuss more about this routine later.

We also have the handle of the NamedPipe (\Device\NamedPipe\_AVIRA_2109), two events and a pointer to the string, "_AVIRA_2109"

Let us take a look at the thread function at 0xA7A1D2 now:


It will create a mutex with the name, _AVIRA_2109 and then connect to the NamedPipe. This is the server end of the named pipe. Data is read from the NamedPipe using ReadFile and written to it using WriteFile. This is used for inter process communication.

It reads 4 bytes from the NamedPipe (which is the code of the command) that is passed to the controller function mentioned above (0x00A76361).

Here is the call to the controller function:


 And the controller function:


The command code is passed in the ecx register which is checked in the controller function.

The use of Named Pipes is another feature in Zeus that is not used in many malwares. It makes the process of debugging its code more difficult.

Similar to NamedPipes, there is another way for interprocess communication using CreateMailSlot which can be used by malwares.

Often times, while analyzing malicious documents for instance a malicious PDF file obtained as an attachment in a spear phishing email, we locate obfuscated JavaScript.

This obfuscated JavaScript is used to spray the heap of the process with Shellcode and NOPsled. Now, the shellcode could be either regular shellcode which can be disassembled in IDA Pro or analyzed in a Debugger. In some cases, when you load the shellcode in IDA Pro and disassemble it, the x86 code does not look proper.

This is because the shellcode we are trying to analyze is a ROP Shellcode. Since most of the latest exploits have to bypass Data Execution Prevention on the target, it is becoming more and more common to find ROP Shellcodes while analyzing malicious files.

To analyze a ROP Shellcode we need to find the assembly language code corresponding to the ROP gadgets. This can be done by manually looking up each ROP Gadget in the corresponding module's address space. However, this can be tedious. To make this process more efficient, I wrote a code in C which will automatically extract the opcodes specific to a ROP gadget from a module's address space.

After you dump the shellcode from the deobfuscated JavaScript into a file, you need to check this shellcode either by opening it in IDA Pro and check the disassembly, or open it with a hex editor and observe it. This way you can confirm whether it is a regular shellcode or a ROP shellcode.

As an example, I have taken a malicious PDF file with the MD5 hash: 975d4c98a7ff531c26ab255447127ebb which was found in the wild exploiting the CVE-2010-2883

After dumping the shellcode into a file and opening it with a hex editor we can see that it is not a regular shellcode. I have highlighted some of the ROP gadgets:


In most cases, all the ROP gadgets will be used from a single Non ASLR module. In this case, as you can see all the gadgets are from a module whose base address is: 0x07000000

Let's open Adobe Reader with Windbg and we can see that BIB.dll module has the base address, 0x07000000


So, all the ROP gadgets in our case were taken from this module.

I wrote the following C code to scan the address space of a module and find opcodes corresponding to each ROP gadget and dump it to another file.


My code will differentiate between ROP gadgets and parameters to ROP gadgets. Now, we will load this file again in IDA Pro and mark appropriate sections as code and data.


We can analyze the ROP shellcode in a more efficient way now.

In some cases, we may need to step through the ROP shellcode to understand it better. In these cases, we need to debug the ROP shellcode. This can be done by setting a breakpoint on the first ROP gadget in the ROP chain.

As an example, I will take the previous PDF which can exploit versions of Adobe Reader >= 9.0 and <= 9.4.0

This malicious PDF has multiple ROP shellcodes which are used according to the version of Adobe Reader. We will now look at a ROP shellcode which uses ROP gadgets from icucnv36.dll

We open Adobe Reader with windbg. You can press, g to run Adobe Reader and observe that it loads more modules.

It is important to note here that icucnv36.dll is not loaded by Adobe Reader yet. If I try to set a breakpoint on the first ROP gadget now, it will not allow me to do that as shown below:


This is because we are trying to set a breakpoint at a memory address present inside a DLL's address space which has not yet been loaded.

We can automatically break into the debugger when this module is loaded with the command:

sxe ld icucnv36.dll

Now, we can run Adobe Reader process, open the malicious PDF and moment it loads icucnv36.dll, we break into the debugger.


We can now set a breakpoint at the first ROP gadget successfully:


We can run the process now and moment the first ROP gadget is executed, we break into the debugger. If we observe the register contents, we can see that ESP points to 0x0c0c0c10


The attacker was able to successfully switch the stack with the help of a stack pivot gadget.

If we view the contents of memory address, 0x0c0c0c0c we can see the entire ROP shellcode present there:

We are given a PE32 file which displays an encrypted flag when you run it.


After analyzing the file with a debugger, it was found that it stores the encrypted flag at 0x00409B10.


It calls the subroutine at 0x004010A6 which will copy the encrypted key from the above memory address to 0x00BB1EA0

After returning from this subroutine, it checks for the presence of a debugger by checking the value of BeingDebugged flag at offset 0x2 in the PEB (Process Environment Block):


If it is being debugged, it jumps to the address, 0x0040106E where it displays the message box with the encrypted flag:


We need to patch the conditional jump right after it checks the BeingDebugged flag. There is also a breakpoint placed after the conditional jump. Binary edit the file to overwrite 0xCC with 0x90

Now, we reach the decryption routine of the flag. It performs an XOR decryption of the encrypted flag with a 4 byte key, 0x8899AABB


We can set a breakpoint right after the decryption subroutine and view the decrypted flag in the memory dump:


key:number2isalittlebitharder:p

In this challenge, we were given a PCAP file and we have to find the flag using it.



Since no other information is given in the question apart from the PCAP file, we open it with Wireshark. Now, let's check the HTTP traffic.

Using the filter: http.request.method == "GET", we check all the HTTP GET requests captured in the PCAP file:

We can see several HTTP GET requests to download files whose name is a 32 char hex string.


Let us now sort this using the Info Column and we get this:


We open the PCAP with Network Miner which will analyze the PCAP file and extract any files from it. You can get Network Miner from here:

http://sourceforge.net/projects/networkminer/

Network Miner is able to reconstruct a few files from the TCP Streams:



After checking these files, it was found that the file with the name: d33cf9e6230f3b8e5a0c91a0514ab476 is a 7-zip file. But when you try to open it with 7-zip, it would not work. So, the 7-zip file is corrupted.

This is where the other chunks being downloaded in the PCAP will come to use. So, let's go ahead and get all those chunks.

Since Network Miner was unable to get all of them, we use tcpflow to get all the TCP Streams from the PCAP file.



Let us search these TCP Streams for some interesting information at first. We check the first TCP stream from our search results and find that it has an Index of Files:



So we extract the HTML response from this TCP stream and view it with the Browser:



So, we have a directory listing of the files. By looking at the size of these files we can see that almost all of them have a size of 61440 bytes. We analyze all the TCP streams with a size >= 58000 (the smallest file in the directory listing above).

 Now, we have the TCP Streams of interest:


We now need to extract the data from these TCP Streams. These TCP Streams also contain the HTTP Response Headers, so we need to remove that.

Since the HTTP Response Headers end with \r\n\r\n (in Hex, 0xd0xa0xd0xa), we can use that as a delimiter and extract all the data after this:


we extract data from all these streams, then calculate the MD5 hash of each of these chunks and compare with the ones we got in the directory index above. We keep only the ones required.

Now, we need to put all these chunks of data together with the 7-zip file and extract it. The sequence of these chunks can be determined according to the file timestamps mentioned in the directory index above. Since there are 2 pairs of files having the same timestamp, we have to try combining the chunks in different orders to get it working.

When we try to extract it, it asks for a password:



We check the TCP Streams once again for the password by searching for some common keywords like password, secret and so on:


So, the Entire Password is again broken down into chunks and present in the TCP Stream:


It was present in the first TCP Stream.

So, the password is: M)m5s6S^[>@#Q3+10PD.KE#cyPsvqH

Flag is present on the image inside the archive file.



This challenge was good and it gives a lot of scope for automation. The entire process of extracting the chunks of data from the TCP Streams and then comparing their MD5 hashes with the required chunks can be automated.