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.
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:
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.
0 comments: