Analyze the malware found in the file Lab07-01.exe.
Questions and Short Answers
-
How does this program ensure that it continues running (achieves persistence) when the computer is restarted?
A: This program creates the service MalService to ensure that it runs every time the computer is started.
-
Why does this program use a mutex?
A: The program uses a mutex to ensure that only one copy of the program is running at a time.
-
What is a good host-based signature to use for detecting this program?
A: We could search for a mutex named HGL345 and for the service MalService.
-
What is a good network-based signature for detecting this malware?
A: The malware uses the user-agent Internet Explorer 8.0 and communicates with www.malwareanalysisbook.com.
-
What is the purpose of this program?
A: This program waits until midnight on January 1, 2100, and then sends many requests to http://www.malwareanalysisbook.com/, presumably to conduct a distributed denial-of-service (DDoS) attack against the site.
-
When will this program finish executing?
A: This program will never finish. It waits on a timer until the year 2100, and then creates 20 threads, each of which runs in an infinite loop.
Detailed Analysis
The first step in analyzing this malware in depth is to open it with IDA Pro or a similar tool to examine the imported function list. Many functions in the list provide little information because they are commonly imported by all Windows executables, but a few stand out. Specifically OpenSCManager and CreateService indicate that this malware probably creates a service to ensure that it will run when the computer is restarted.
The import of StartServiceCtrlDispatcherA hints that this file actually is a service. The calls to InternetOpen and InternetOpenUrl tell us that this program might connect to a URL to download content.
Next, we jump to the main function, which IDA Pro has identified and labeled *_wmain* at location 0x401000. A quick glance at the code shows that it’s short enough to analyze completely. The *_wmain* function calls only one other function, as shown in the following listing. If the code were longer, we would need to focus on only the most interesting function calls based on our review of the import table.
This code begins with a call to StartServiceCtrlDispatcherA at \({\color{red} 2 }\). According to the MSDN documentation, this function is used by a program to implement a service, and it is usually called immediately. The function specifies the service control function that the service control manager will call. Here, it specifies sub_401040 at \({\color{red} 1}\), which will be called after the call to StartServiceCtrlDispatcherA.
This first portion of code, including the call to StartServiceCtrlDispatcherA, is bookkeeping code that is necessary for programs that are run as services. It doesn’t tell us what the program is doing, but it does tell us that it expects to be run as a service.
Next, we examine the sub_401040 function, as shown in the following listing.
The first function call is to OpenMutexA at \({\color{red} 1}\). The only thing of note is that this call is attempting to obtain a handle to the named mutex HGL345 at \({\color{red}2}\). If the call fails, the program exits.
The next call is shown in the following listing.
This code creates a mutex at \({\color{red}1}\) named HGL345 \({\color{red} 2 }\). The combination of these two mutex calls is designed to ensure that only one copy of this executable is running on a system at any given time. If a copy was already running, then the first call to OpenMutexA would have been successful, and the program would have exited.
Next, the code calls OpenSCManager, which opens a handle to the service control manager so that the program can add or modify services. The next call is to the GetModuleFileName function, which returns the full pathname to the currently running executable or a loaded DLL. The first parameter(hModule) is a handle to the module for which the name should be retrieved, or it is NULL to get the full pathname of the executable.
The full pathname is used by CreateServiceA to create a new service. The CreateServiceA call has many parameters, but the key ones are noted in the following listing.
The key CreateServiceA parameters are BinaryPathName at \({\color{red}1}\), dwStartType at \({\color{red}2}\), and dwServiceType at \({\color{red}3}\). The binary path to the executable is the same as the path to the currently running executable retrieved by the GetModuleFileName call. The GetModuleFileName call is needed because the malware may not know its directory or filename. By dynamically obtaining this information, it can install the service no matter which executable is called or where it is stored.
The MSDN documentation lists valid entries for the dwServiceType and dwStartType parameters. For dwStartType, the possibilities are SERVICE_BOOT_START (0x00), SERVICE_SYSTEM_START (0x01), SERVICE_AUTO_START (0x02), SERVICE_DEMAND_START (0x03), and SERVICE_DISABLED (0x04). The malware passed 0x02, which corresponds to SERVICE_AUTO_START, indicating that the service runs automatically on system startup.
A lot of code manipulates time-related structures. IDA Pro has labeled a structure to be a SYSTEMTIME structure, which is one of several Windows time structures. According to MSDN, the SYSTEMTIME structure has separate fields for the second, minute, hour, day, and so on, for use in specifying time. In this case, all values are first set to 0, and then the value for the year is set to 0x0834 at \({\color{red}1}\), or 2100 in decimal. This time represents midnight on January 1, 2100. The program then calls SystemTimeToFileTime between time formats.
注：我们可以通过 IDA 的 Imports 找到 SystemTimeToFileTime，然后使用下图方法定位到上图：
Next, the program calls CreateWaitableTimer, SetWaitableTimer, and WaitForSingleObject. The most important argument for our purposes is the lpDueTime argument to SetWaitableTimer. The argument is the FileTime returned by SystemTimeToFileTime, as shown in the preceding listing. The code then uses WaitForSingleObject to wait until January 1, 2100.
The code then loops 20 (0x14) times, as shown in the following listing.
Here, ESI is set at \({\color{red}1}\) as the counter to 0x14 (20 in decimal). At the end of the loop, ESI is decremented at \({\color{red}2}\), and when it hits zero at \({\color{red}3}\), the loop exits. A call to CreateThread at \({\color{red}4}\) has several parameters, but only one is important to us. The lpStartAddress parameter at \({\color{red}5}\) tells us which function will be used as the start address for the thread—labeled StartAddress in this case.
We double-click StartAddress. We see that this function calls InternetOpen to initialize a connection to the Internet, and then calls InternetOpenUrlA from within a loop, which is shown in the following code.
The jmp instruction at the end of the loop at \({\color{red} 1 }\) is an unconditional jump, which means that the code will never end; it will call InternetOpenUrlA \({\color{red}2}\) and download the home page of www.malwareanalysisbook.com \({\color{red}3}\) forever. And because CreateThread is called 20 times, 20 threads will call InternetOpenUrlA forever. Clearly, this malware is designed to launch a DDoS attack by installing itself on many machines. If all of the infected machines connect to the server at the same time (January 1, 2100), they may overload the server and make it impossible to access the site.
In summary, this malware uses mutexes to ensure that only one copy is running at a time, creates a service to ensure that it runs again when the system reboots, waits until January 1, 2100, and then continues to download www.malwareanalysisbook.com indefinitely.
Note that this malware doesn’t perform all of the functions required of a service. Normally, a service must implement functions to be stopped or paused, and it must change its status to let the user and OS know that the service has started. Because this malware does none of this, its service’s status will always display START_PENDING, and the service cannot be stopped while it is running. Malware often implements just enough functionality to achieve the author’s goals, without bothering to implement the entire functionality required by the specification.
NOTE
If you ran this lab without a virtual machine, remove the malware by entering
sc delete Malserviceat the command line, and then deleting the file itself.