|
|
With the building blocks described in the previous section, we can now build a system that is capable of automatically analyzing a given malware sample: CWSandbox. This system outputs a behavior-based analysis — that is, the malware binary is executed in a controlled environment, and all relevant function calls to the Windows API are observed. In a second step, a high-level summarized report is generated from the monitored API calls. The analysis report contains a separate section for each process that was involved. For each process, there are several subsections that contain associated actions — that is, there is one subsection for all accesses to the filesystem and another section for all network operations. As one focus lies on the analysis of bots, CWSandbox is capable of extracting and evaluating the network connection data. In the following, we describe the sandbox in more detail.
The sandbox routes nearly all API calls to the original API functions after it has analyzed their call parameters. Therefore, the malware is not blocked from integrating itself into the target operating system — for example, by copying itself to the Windows system directory or adding new registry keys. To enable a fast automated analysis, we thus execute the CWSandbox in a virtual environment so that after the completion of an analysis process, the system can easily be brought back into a clean state. We would like to emphasize that this has some drawbacks, such as, detectability and slower execution. We have already presented some possible ways to identify the presence of virtual machines in Section 9.2.4, and the execution is slower, since the analysis process does not execute on a native machine. Up until now, we run only in limited problems with this approach. However, this drawback can be circumvented by using CWSandbox in a native environment — that is, a normal commercial off-the-shelf system and an automated procedure to restore a clean state.
CWSandbox itself consists of two applications: cwsandbox.exe and cwmonitor.dll. The sandbox creates a suspended process of the malware application and injects the DLL into it (DLL injection). At the initialization of this DLL, API hooks for all critical API functions that are installed (API hooking). The sandbox then sends some runtime options to the DLL and the DLL in turn answers with some runtime information of the malware process. After this initialization phase, the malware process is resumed and executed for a given amount of time. During the malware's execution, all hooked API calls are rerouted to the referring hook functions in the DLL. These hook functions inspect the call parameters, inform the sandbox about the API call in the form of notification objects, and then, depending on the type of the API function called, delegate control to the original function or return directly. If the original API is called, the hook function inspects the result and sometimes modifies it before returning to the calling malware application. This is, for example, done to hide the presence of the sandbox: Certain files, processes, or registry keys that belong to the sandbox are filtered out from the results, and thus their existence is hidden.
Besides the monitoring, the DLL also has to ensure that whenever the malware starts a new process or injects code into a running process, the sandbox is informed about that. The sandbox then injects a new instance of the DLL into that newly created or already existing process so all API calls from this process are also captured. A schematic overview of this process is given in Figure 12.2.
There is a lot of communication between the executable and all the loaded instances of the monitoring DLL. Since the communication endpoints reside in different processes, this communication is called interprocess communication (IPC). Each API hook function sends a notification object to inform the sandbox about the call and the used calling parameters. Some hook functions also require an answer from the sandbox that determines the further proceeding — for example, if the original API function should be called or not. A lot of data has to be transmitted per notification, and various instances of the DLL can exist, so there is a heavy communication throughput. Besides the high performance need, a very reliable mechanism is needed also, since no data is allowed to be lost or modified on its way. Thus, a reliable IPC mechanism with high throughput is also implemented in CWSandbox.
The work of the sandbox can be summarized into three phases:
Initialization phase
Execution phase
Analysis phase
In the first phase, the sandbox initializes and sets up the malware process. It then injects the DLL and exchanges some initial information and settings. If everything worked well, the process of the malware is resumed, and the second phase is started. Otherwise, the sandbox kills the newly created malware process and also terminates. The second phase lasts as long as the malware executes, but it can be ended prematurely by the sandbox. This happens if a timeout occurs or some critical conditions require an instant termination of the malware. During this phase, there is a heavy communication between the cwmonitor.dll instances in all running processes and cwsandbox.exe. In the third phase, all the collected data is analyzed, and an XML analysis report is generated from that. Later in this chapter, we will see what such an analysis reports looks like.
The cwmonitor.dll is injected by the sandbox into each process that is created or injected by the malware. The main tasks of the DLL are the installation of the API hooks, realization of the hook functions, and the communication with the sandbox.
Similar to the sandbox, the life cycle of the DLL can be divided into three parts: initialization, execution, and the finishing phase. The first and the last of these phases are handled in the DLL main function; the execution phase is handled in the several hook functions. Operations of the DLL are executed only during initialization and finishing phase and each time one of the hooked API functions is called.
There often are multiple API functions that can be used for the same purpose. Just as often there are layered API functions that call each other recursively. So it is necessary to find a minimal subset of those functions that cover all possible execution chains. The main policy used in CWSandbox is all API functions are hooked at the lowest level possible. There are also some exceptions to that, since sometimes it is necessary to hook at a higher level. The details of the hooking choices are rather complex and require a deeper understanding of the Windows internals. We refrain from explaining the choices in detail here.
Since the malware sample should not be aware of the fact that it is executed inside of a controlled environment, the cwmonitor.dll implements some rootkit functionality. All system objects that belong to the sandbox are hidden from the malware binary. In detail, these are processes, modules, files, registry entries, mutexes events, and handles in general. This at least makes it much harder for the malware sample to detect the presence of the sandbox. Up to now, we only ran into trouble with this approach in only a small number of cases.
|
|