Lab 11-2

Analyze the malware found in Lab11-02.dll. Assume that a suspicious file named Lab11-02.ini was also found with this malware.

Questions and Short Answers

1. What are the exports for this DLL malware?

   A: Lab11-02.dll contains one export, named installer.

2. What happens after you attempt to install this malware using
   rundll32.exe?

   A: If you run the malware from the command line using rundll32.exe Lab11-02.dll,installer, the malware copies itself to the Windows system directory as spoolvxx32.dll and installs itself persistently under AppInit_DLLs. The malware also tries to open Lab11-02.ini from the Windows system directory, but it doesn’t find it there.

3. Where must Lab11-02.ini reside in order for the malware to install properly?

   A: Lab11-02.ini must reside in %SystemRoot%\System32\ in order for the malware to run properly.

4. How is this malware installed for persistence?

   A: The malware installs itself in the AppInit_DLLs registry value, which causes the malware to be loaded into every process that also loads User32.dll.

5. What user-space rootkit technique does this malware employ?

   A: This malware installs an inline hook of the send function.

6. What does the hooking code do?

   A: The hook checks if the outgoing packet is an email message containing RCPT TO:, and if this string is found, it adds an additional RCPT TO line containing a malicious email account.

7. Which process(es) does this malware attack and why?

   A: The malware targets only MSIMN.exe, THEBAT.exe, and OUTLOOK.exe because all are email clients. The malware does not install the hook unless it is running inside one of these processes.

8. What is the significance of the .ini file?

   A: The INI file contains an encrypted email address. After decrypting Lab11-02.ini, we see it contains billy@malwareanalysisbook.com.

9. How can you dynamically capture this malware’s activity with Wireshark?

   A: See “Capturing the Network Traffic” on page 580 for our method of capturing data using Wireshark, a fake mail server, and Outlook Express.

Detailed Analysis

We begin with basic static analysis of Lab11-02.dll. The DLL has only one export, named installer. The malware contains imports for manipulating the registry (RegSetValueEx), changing the file system (CopyFile), and searching through a process or thread listing (CreateToolhelp32Snapshot). The interesting strings for Lab11-02.dll are shown in Listing 11-6L.

Listing 11-6L: Interesting strings in Lab11-02.dll

The strings AppInit_DLLs and SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows indicate that the malware might use AppInit_DLLs to install itself for persistence. The string \Lab11-02.ini indicates that the malware uses the INI file provided in this lab.

Examining the contents of Lab11-02.ini, we see that it appears to contain encoded or encrypted data. The send and wsock32.dll strings may indicate that the malware uses networking functionality, but that is unclear until we dig deeper. The process names (OUTLOOK.EXE, MSIMN.EXE, and THEBAT.EXE) are email clients, and combining those strings with RCPT TO: leads us to suspect that this malware does something with email.

NOTE

RCPT is an SMTP command to establish a recipient for an email message.

Next, we use basic dynamic tools like procmon to monitor the malware. We begin by trying to install the malware using the installer export with the following command:

rundll32.exe Lab11-02.dll,installer

In procmon, we set a filter for the process rundll32.exe, and see the malware create a file named spoolvxx32.dll in the Windows system directory. Upon further inspection, we see that this file is identical to Lab11-02.dll. Further in the procmon listing, we see the malware add spoolvxx32.dll to the list of AppInit_DLLs (causing the malware to be loaded into every process that loads User32.dll). Finally, we see that the malware attempts to open Lab11-02.ini from the Windows system directory. Therefore, we should copy the INI file to the Windows system directory in order for the malware to access it.

我们详细浏览 Procmon 中的信息，可以观察到以下有意思的信息：

还有的就是试图打开 C:\WINDOWS\system32\Lab11-02.ini 文件，但是 C:\WINDOWS\system32\ 该目录下没有该文件，所以打开失败：

所以，我们将文件 Lab11-02.ini 拷贝到 C:\WINDOWS\system32\ 目录下，以便恶意代码访问它。

We move our analysis to IDA Pro to look more deeply into the malware. We begin by analyzing the installer export. A graph of the cross-references from installer is shown in Figure 11-2L.

Figure 11-2L: Cross-reference graph of the installer export

As you can see, installer sets a value in the registry and copies a file to the Windows system directory. This matches what we saw during dynamic analysis and is confirmed in the disassembly. The installer function’s only purpose is to copy the malware to spoolvxx32.dll and set it as an AppInit_DLLs value.

In Listing 11-7L, we focus on DllMain, which starts by checking for DLL_PROCESS_ATTACH, as with the previous lab. It appears that this malware runs only during DLL_PROCESS_ATTACH; otherwise, DllMain returns without doing anything else.

Listing 11-7L: Code in DllMain that attempts to open Lab11-02.ini from the system directory

In Listing 11-7L at \({\color{red}1}​\), we see the Windows system directory retrieved, as well as the string for Lab11-02.ini at \({\color{red}2}​\). Together, these form a path with the strncat at \({\color{red}3}​\). The malware attempts to open the INI file for reading at \({\color{red}4}​\). If the file cannot be opened, DllMain returns.

If the malware successfully opens the INI file, it reads the file into a global buffer, as shown in Listing 11-8L at \({\color{red}1}\).

Listing 11-8L: Reading and decrypting the INI file

After the call to ReadFile, the malware checks to make sure the file size is greater than 0 at \({\color{red}2}\). Next, the buffer containing the file contents is passed to sub_100010B3 at \({\color{red}3}\). sub_100010B3 looks like it might be a decoding routine because it is the first function called after opening a handle to a suspected encoded file, so we’ll call it maybeDecoder. To test our theory, we load the malware into OllyDbg and set a breakpoint at 0x100016CA. (Make sure you copy the INI file and the malware into the Windows system directory and rename the DLL spoolvxx32.dll.) After the breakpoint is hit, we step over the call maybeDecoder. Figure 11-3L shows the result.

Figure 11-3L: OllyDbg showing the decoded contents of Lab11-02.ini

At \({\color{red}1}\) in Figure 11-3L, the decrypted content—the email address billy@malwareanalysisbook.com—is pointed to by EAX. This email address is stored in the global variable byte_100034A0, which we rename email_address in IDA Pro to aid future analysis.

We have one last function to analyze inside DllMain: sub_100014B6. Because this function will install an inline hook, we’ll rename it hook_installer. The hook_installer function is complicated, so before diving into it, we provide a high-level overview of what this inline hook looks like after installation in Figure 11-4L.

The left side of Figure 11-4L shows what a normal call to the send function in ws2_32.dll looks like. The right side of the figure shows how hook_installer installs an inline hook of the send function. The start of the send function is replaced with a jump to malicious code, which calls a trampoline (shown in the figure’s lower-right box). The trampoline simply executes the start of the send function (which was overwritten with the first jump) and then jumps back to the original send function, so that the send function can operate as it did before the hook was installed.

Before hook_installer installs the hook, it checks to see which process the malware is running in. To do so, it calls three functions to get the current process name. Listing 11-9L contains code from the first of these functions, sub_10001075.

Listing 11-9L: Calling GetModuleFileNameA to get the current process name

As you can see, GetModuleFileNameA is called at \({\color {red}1}\), and it returns the full path to the process in which the DLL is loaded because the argument hModule is set to 0 before the call to this function. Next, the malware returns the name in arg_4 (the string pointer passed to the function). This string is passed to two more functions, which parse the filename and change all of its characters to uppercase.

NOTE

Malware that uses AppInit_DLLs as a persistence mechanism commonly uses GetModuleFileNameA. This malicious DLL is loaded into just about every process that starts on the system. Because malware authors may want to target only certain processes, they must determine the name of the process in which their malicious code is running.

Next, the current process name in uppercase letters is compared to the process names THEBAT.EXE, OUTLOOK.EXE, and MSIMN.EXE. If the string does not equal one of these filenames, the malware will exit. However, if the malware has been loaded into one of these three processes, the malicious code seen in Listing 11-10L will execute.

Listing 11-10L: Malicious code that sets an inline hook

Listing 11-10L has several functions for us to analyze. Inside \({\color{red}1}​\), we see calls to GetCurrentProcessId and then sub_100012FE, which we rename to suspend_threads. The suspend_threads function calls GetCurrentThreadId, which returns a thread identifier (TID) of the current thread of execution. Next, suspend_threads calls CreateToolhelp32Snapshot and uses the result to loop through all of the TIDs for the current process. If a TID is not the current thread, then SuspendThread is called using the TID. We can conclude that the function called at \({\color{red}1}​\) suspends all executing threads in the current process.

Conversely, the function called at \({\color{red}3}​\) does the exact opposite: It resumes all of the threads using calls to ResumeThread. We conclude that the code in Listing 11-10L is surrounded by two functions that suspend and then resume execution. This behavior is common when malware is making a change that could impact current execution, such as changing memory or installing an inline hook.

Next, we examine the code in the call at \({\color{red}2}​\). The function sub_100012A3 takes four arguments, as shown by the series of pushes in Listing 11-10L. Since this function is called only from this location, we can rename all of the arguments to match what is passed to the function, as shown in Listing 11-11L beginning at \({\color{red}1}​\).

Listing 11-11L: sub_100012A3 resolving the send function

In Listing 11-11L, we see a handle to wsock32.dll obtained using GetModuleHandleA at \({\color{red}2}\). That handle is passed to GetProcAddress to resolve the send function at \({\color{red}3}\). The malware ends up passing the address of the send function and the two other parameters (sub_1000113D and dword_10003484) to sub_10001203, which we renamed place_hook.

Now, we examine place_hook and rename the arguments accordingly in order to aid our analysis. Listing 11-12L shows the start of place_hook.

Listing 11-12L: Address calculation for the jump instruction

The code in Listing 11-12L calculates the difference between the memory address of the send function and the start of sub_1000113D. This difference has an additional 5 bytes subtracted from it before being moved into var_4 at \({\color{red}1}​\). var_4 is used later in the code and prepended with 0xE9 (the opcode for jmp), making this a 5-byte instruction to jump to sub_1000113D.

Let’s see how the malware installs this code as a hook later in place_hook. The start of the send function is modified by the instructions shown in Listing 11-13L.

Listing 11-13L: The inline hook installation

At \({\color{red}1}\), the code copies the 0xE9 opcode into the start of the send function. Following that, it copies var_4 into memory just after the 0xE9 at \({\color{red}2}\). Recall from Listing 11-12L that var_4 contains the destination of the jump, sub_1000113D. The code in Listing 11-13L places a jmp instruction at the beginning of the send function that jumps to the function in our DLL at sub_1000113D, which we’ll now rename hook_function.

Before we examine hook_function, let’s wrap up our analysis of the inline hook installation. Listing 11-14L shows place_hook manipulating memory.

Listing 11-14L: place_hook (sub_10001203) manipulating memory

In Listing 11-14L, place_hook calls VirtualProtect at \({\color{red}1}​\) on the start of the send function code. This action changes the memory protection to execute, read, and write access, thereby allowing the malware to modify the instructions of the send function. Another call to VirtualProtect at the end of the function restores the original memory-protection settings. Then, immediately after calling VirtualProtect, the malware allocates 0xFF bytes of memory using malloc and stores the result in var_8 at \({\color{red}2}​\). Because this dynamically allocated memory will play an important role in the installation of our hook as a trampoline, we’ll rename var_8 to trampoline.

NOTE

In order for this to execute properly, the memory returned by the call to malloc must be executable memory, which might not always be the case if, for example, Data Execution Prevention (DEP) is enabled via /Noexecute=alwayson or similar.

Listing 11-15L shows the creation of the trampoline’s code.

Listing 11-15L: Trampoline creation for the inline hook

In Listing 11-15L, the memcpy at \({\color{red}1}\) copies the first 5 bytes of the send function into the trampoline. Since the malware overwrites the first 5 bytes of the send instruction (Listing 11-13L), it needs to make sure that the original instructions are saved. The malware assumes that the send function’s first several instructions align exactly on 5 bytes, which might not always be the case.

Next, the malware adds a jmp instruction to the trampoline code at \({\color{red}2}\) and \({\color{red}3}\). At \({\color{red}2}\), the 0xE9 opcode is added. At \({\color{red}3}\), the location to jump is added. The jump location is calculated by subtracting the location of the trampoline from the location of the send function (meaning it will jump back to the send function).

Finally, place_hook ends by setting the global variable dword_10003484 to the trampoline location. We rename dword_10003484 to trampoline_function to aid analysis.

Next, we analyze hook_function (sub_1000113D), which will have the same arguments as the send function since it is installed as a hook. We begin our analysis by right-clicking the function name, selecting Set Function Type, and entering the following:

int __stdcall hook_function(SOCKET s, char * buf, int len, int flags)

The hook function looks for the string RCPT TO: in buf. If the string isn’t found, the malware just calls trampoline_function, which causes send to operate as it did before the hook was installed. Otherwise, the code in Listing 11-16L will execute.

Listing 11-16L: Creating the string to add a recipient

The code in Listing 11-16L builds a string that is added to the outgoing buffer. This string starts with RCPT TO: < at \({\color{red}1}\), followed by email_address at \({\color{red}2}\), and ends with >\r\n at \({\color{red}3}\). The email_address value in this case is billy@malwareanalysisbook.com (extracted from Lab11-02.ini, as explained earlier when we looked at the contents of that file). This code adds a recipient to all outgoing email messages.

Low-Level Hook Operation Summary

Here’s a summary of the hook’s operation (also illustrated at a high-level in Figure 11-4L, shown earlier):

• The program calls the send function.
• The first instruction of the send function transfers execution to sub_1000113D.
• sub_1000113D manipulates the outgoing buffer only if it contains a RCPT TO string.
• sub_1000113D calls the trampoline code located on the heap and pointed to by dword_10003484.
• The trampoline code executes the first three original instructions of the send function (which it overwrote to install the hook).
• The trampoline code jumps back to the send function 5 bytes in, so that send can function normally.

Examining the Hook in OllyDbg

We can examine the inline hook using OllyDbg by installing the malware and then launching Outlook Express. (Outlook Express is bundled with Microsoft Windows XP and runs as msimn.exe.) We attach to the process using File -> Attach and selecting msimn.exe from the process listing. Attaching to a process immediately pauses all of the threads. If we examine the memory map, we see that spoolvxx32.dll is loaded in the process because it is an AppInit_DLLs value.

1. 安装恶意代码

   

   因为前面我们已经将文件 Lab11-02.ini 拷贝到了 C:\WINDOWS\system32\ 目录下，所以执行是成功的：

   

   

2. 执行 Outlook Express

3. 附加 msimn.exe 到 OllyDbg

   

Next, we examine send by pressing CTRL-G and entering send in the text box. Figure 11-5L shows the start of the send function with the jmp hook to sub_1000113D. (If you like, you can set a breakpoint at this jump and analyze the code during runtime.)

Figure 11-5L: Examining the inline hook for the send function in msimn.exe

Capturing the Network Traffic

To capture this malware in action and see how it manipulates network traffic, set up a safe environment as follows:

1. Turn on host-only networking in your virtual machine.
2. Install the malware on your virtual machine with the command rundll32.exe Lab11-02.exe,installer.
3. Copy Lab11-02.ini into C:\Windows\System32\ .
4. Launch Wireshark and start capturing packets on the virtual machine network interface.
5. Set up Outlook Express to send email to the host system.
6. Run a fake mail server on your host machine with the command python -m smtpd -n -c DebuggingServer IP:25, where IP is the IP address of the host machine.
7. Send an email from Outlook Express.
8. Review the packet capture in Wireshark and select Follow TCP Stream on the email message.

Summary

Lab 11-2 is a malicious DLL that exports installer, which installs the malware persistently using AppInit_DLLs, causing the malware to be loaded into most processes. The malware checks to see if it is loaded into a mail client by using a preset list of process names to target. If the malware determines that it is running inside one of these processes, it will act as a user-mode rootkit by installing an inline hook for the send function. The hook takes the form of a jmp instruction placed at the beginning of the send function. The hook executes a function that scans every data buffer passed to the send function and searches for RCPT TO. If the malware finds the RCPT TO string, it inserts an additional RCPT TO containing an email address retrieved by decoding Lab11-02.ini, essentially copying the malware author on every email sent from the targeted email programs.

Preference

PRACTICAL MALWARE ANALYSIS: MALWARE BEHAVIOR(LAB 11-02)

恶意代码分析实战 Lab 11-2 习题笔记

What version of Wireshark works on Windows XP SP2 ?