Dr. Fu's Security Blog: Malware Analysis Tutorial 26: Rootkit Configuration

Learning Goals:

Practice the use of user mode WinDbg for inspecting process in non-invasive mode
Practice the use of IMM and WinDbg for data analysis
Understand registry operations
Understand file operations at multiple levels
Understand the high level network operations
Practice the general unpacking technique and searching for the decoding key

Applicable to:

Operating Systems
Assembly Language
Operating System Security

1. Introduction
In this section, we go back to the analysis of lz32.dll and finish the rest of it. We will see a wide variety of malicious operations performed by the malicious lz32.dll injected by Max++, including disk formatting of the hidden drive, generation of network payload and configuration, unpacking of code segment, and infection of other system library files.

Our analysis will be mostly performed in the address range 0x3Cxxxx, and for some part we will have to dig into the raspppoe.sys again. We start the analysis from the address 0x3C1B3E. Follow the instructions below.

2. Lab Configuration
We could simply reuse the lab configuration of Tutorial 20. In general, you need two windows XP instances, one for taking notes and the other for running the malware. Also you need a WinDbg instance sitting on the host to debug the win_debug instance. Specifically, in the win_debug instance, you need to set a breakpoint at 0x3C1B3E. This is the place right before the call of loadDriver("raspppoe.sys"), as shown in Figure 1 below.

Figure 1. Code of Lz32.dll after zwLoadDriver

3. Clean Up Operations
Recall that at 0x3C1B3F, max++ (at lz32.dll) calls zwLoadDriver to load rasppoe.sys. The behavior of rasppoe.sys is explained in the Tutorials 20 to 25. Now lz32.dll has to perform some clean up operations to further hide the trail of the malware. At 0x003C1B48 (see the first highlighted area of Figure 1), it closes the file handle of raspppoe.sys, and then from 0x3C1B55 to 0x3C1B3B, there is a loop which resumes a collection of threads one by one. This is actually to re-enable the windows file protection service.

Challenge 1. Use data tracing/breakpoint technique to prove that the loop from 0x3C1B55 to 0x3C1B3B is to re-enable the windows file protection service.

Note that major responsibility of the infected rasspppoe.sys is to set up the I/O handler for disk operations and also the infection of TDI (TCP/IP) service stack. Many services in raspppoe.sys are delayed for 15 seconds using deferred procedure call or delayed timer on system thread, because they need the further configuration done in lz32.dll. We now present the details.

4. Creation of Virtual Drive
The first interesting part of the code is the creation of a virtual drive. The code is shown in Figure 2. It consists of four steps: it first loads the "fmifs" library, and then it gets the procedure address of "FormatEx", and then it calls the function to format the drive. If you look at the stack content, you will notice the name of the drive is "C2CAD...". Once everything is done, it unloads the library.

Figure 2. Create Virtual Drive \??\C2CAD...

5. Storing Malicious File in Hidden Drive
The next action performed by Max++ is to save the infected driver file raspppoe.sys into the newly created hidden drive. The details is shown in Figure 3.

Figure 3. Store Malicious raspppoe.sys file into Hidden Drive. file name: snifer67

As shown in Figure 3, the first action at 0x3C2000 is a call of MapViewOfSection. Essentially, it maps a section object to the address space of the current object. The section object, before this call, is set up by Max++ to be the mapping of the raspppoe.sys driver file (which is infected). After the call is completed, the entire section object will be mapped to somewhere in the current process, in our case, the starting address is 0x00380000. If you look at the memory dump in Figure 3, you can notice the "4D 5A", which is the magic code of a PE file. Then Max++ creates a file named "osseqw" (which is the result of encoding "snifer67" using the current time stamp). It then saves the contents of the rassppoe.sys into the newly created file.

Challenge 1. Prove that the section object used in the MapviewOfSection call at 0x3C2000 is the one for raspppoe.sys (infected driver).

Challenge 2. Find out when the snifer67 file in the hidden drive is used.

6.Configuration File
The next function to analyze is 0x3C2162. Figure 4 shows its function body. Its main job is to create the configuration file used by the TDI_SEND activities introduced in section 5 of Tutorial 25.

Figure 4. Writing IP/domain names of malicious servers

As shown in Figure 4, Max++ loads and encodes several strings such as<ip>85.17.239.212</ip> and <host>intensivedive.com</host>. It's your job to find out all the malicious servers saved to the configuration file.

Challenge 3. Analyze the function at 0x003C20E0. What are its input parameters?

Challenge 4. Identify all the IP addresses and domain names saved into the configuration file in hidden drive.

Challenge 5. Find the name of the configuration file.

7. Saving Decoding Key in Registry
The next action Max++ performs is to save the "decoding key" which is used for self-packing into registry. Figure 5 shows the code.

Figure 5. Saving Decoding Key

As shown in Figure 5, the decoding key is "1100100", which is retrieved from the PE header of Max+++downloader2010.exe and it is used in decoding/unpacking the code. Max++ creates a registry key in IE explorer and saves the value there.

Challenge 6. Prove that the key 11001800 is from the PE header of Max++.

Challenge 7. Find out where the key is used.

8. Creating HTTP Request
Max++ proceeds to function 3C220A, which creates the HTTP request header for downloading more malicious files. Figure 6 shows its contents. The highlighted area in Figure 6 shows the HTTP request header. It is basically to invoke /install/setup.ppc.php on intensivedive.com.

Figure 6. Creating HTTP Request Header

9.Creation of Malicious File max++.00.x86
Next we analyze the function located at 0x3C16b8. Figure 7 shows its contents. It first opens the ntdll file and reads its basic file information. Then it creates a file called max++.00.x86 in the hidden drive. The file uses the same configuration (basic file information) of ntdll.

Challenge 8. Observe the function call at 0x3C16CD (in Figure 7). It creates a decoding table. Where does the decoding table start and end?

Figure 7. First Part of 0x3c16b8

Figure 8 shows the rest of the function. It establishes the contents of max++.00.x86. The first action is to allocate a virtual memory of 0x8000 bytes (see the highlighted area in Figure 7). Then it first establishes a decoding table in the stack (in range of 0x12D3XX). Then using this decoding table, Max++ first copies the encrypted code from 0x3C2550 to 0x380000 and deciphers the information via multiple passes of decryption. Finally it writes all the contents into max++.00.x86. The file will be later loaded by another system driver.

Figure 8. Establish file max++.00.x86

10. Contact Malicious Server
Next Max++ contacts the malicious server, as shown in Figure 9. It constructs a winsock and connects to 85.17.239.212 and send a HTTP request to it. Notice that the interesting part is the encoding key "11001800" is embedded in the HTTP request (see the memory dump part of Figure 9). The function does not have a receive operation though. It seems to just inform the malicious server that the infection of Max++ is successful.