Dr. Fu's Security Blog: Malware Analysis Tutorial 32: Exploration of Botnet Client

Wednesday, August 15, 2012

Malware Analysis Tutorial 32: Exploration of Botnet Client

Learning Goals:

Practice WinDbg for Inspecting Kernel Data Structure
Use Packet Sniffer to Monitor Malware Network Activities
Understand Frequently Used Network Activities by Malware
Expose Hidden/Unreachable Control Flow of Malware

Applicable to:

Operating Systems
Assembly Language
Operating System Security

1. Introduction

This tutorial explores the botnet client part of Max++. We assume that you have completed tutorial 31 where our lab setting directly results from its analysis. You should have the following before the analysis, as shown in Figure 1.

Figure 1. Process Network Message

As shown in Figure 1, there is a big loop of calling zwReplyWaitReceivePortEx, which tries to wait for a message from the port. EAX represents the return code of the function, e.g., 0x0 represents OK and 0x102 represents time-out. If time-out, it calls function 0x35671D03. Otherwise, it proceeds to process the message.

Max++ first reads the 2nd word in the message, this is supposed to be an integer between 1 and 3. For case 3, it calls function 0x3567162D. for case 1, it calls function 0x3567204F. Note that all the four parameters of 0x3567204F are from the msg (5th, 7th, 8th and 10th words from the message respectively).

2. Execute Remote Command (#1).
Now let's delve into function 0x3567204F. Again, notice that this function gets executed ONLY WHEN the second word of the remote network message is 0x1. Figure 2 shows its function body.

Figure 2. Mysterious Function 0x3567204F

As shown in Figure 2, one of the input parameters of the function is ESI register (pointing to 0x00181580). This is a mysterious data structure. We suspect that it is the COM interface of the fake JScript COM object (the remote max++.x86.dll). The COM interface wraps a C++ object so that the program (Max++) can call the functions available in the DLL.

Next, the function clears memory region 0x009FFEE8, and copies the first four parameters passed in the stack to this region. Notice that these four parameters are the 5th, 7th, 8th, and 10th words in the remote message. Then it saves 0x009FFFE8 to EBP-10.

Max++ then proceeds to call some function of the remote DLL (see the second highlighted area in Figure 2). It seems to be taking out the virtual function table of the object and it invokes the function located at offset 0x18. This function takes at least 7 parameters, and they are [ESI+18], [ESI+20], 0x356782A4, 0, 1, [EBP-20], and [EBP-10]. Here [ESI+18] and [ESI+20] must be some data attributes of the COM interface object, and [EBP-20] is a pointer to collect result. From the VariantClear call (see the last highlighted area of figure 2), we can infer that [EBP-20] is a pointer to VARIANTARG. Lastly notice that [EBP-10] stores 0x009FFEE8, which contains the four words from the remote message.

Although we have no access of the remote DLL, we can infer that this part of the malware is taking some command/parameters of the remote message, and execute some functions correspondingly. It looks like a bot-net client.

3. Initilization (command #3)
We now look at case #3 (where the 2nd word of the remote message is 3). In this case, function 0x3567162D is invoked.. To enforce the control flow into this case, we simply change the register values correspondingly. Figure 3 displays the body of function 0x3567162D.

Figure 3. Function Body of 0x3567162D

As shown in Figure 3, function 0x3567162D extracts a file from the hidden drive into a newly allocated heap area. The contents of the file seem to be some special javascript tags and HTTP request headers. The file name is read from an absolute location 0x3567806C. Unless the address is being re-written, it's always reading the same file.

Then Max++ jumps to function 0x356719E4, as shown in Figure 4. Again, it's invoking the COM interface of the remote object which is not available. As shown in Figure 4, it loads the virtual function table of the COM object multiple times and calls several functions of that COM interface.

Figure 4. Calling COM Object

4. Conclusion
Since the remote object is not available, we are not able to drill deeper into Max++. The bottomline via the analysis in this tutorial is that the maxware is able to listen to a port and receive commands from a remote server. The remote command has a fairly simple structure, the second word of the remote message decides the action to take at the max++ client side. #3 seems to be initializing service; and #1 seems to be executing some actions, where four words from the remote message serve as the parameters.

In the next tutorial, we will submit Max++ to various malware analysis engines and match their discovery with our manual analysis.