Toward the Analysis of Distributed Code Injection in Post-mortem Forensics

Abstract

Distributed code injection is a new type of malicious code injection technique. It makes existing forensics techniques for injected code detection infeasible by splitting a malicious code into several code snippets, injecting them into multiple running processes, and executing them in each process spaces. In spite of the impact of it on practical forensics fields, there was no discussion on countermeasures against this threat. In this paper, we present a memory forensics method for finding all code snippets distributively injected into multiple processes to defeat distributed code injection attacks. Our method is designed on the following observation for distributed code injection attacks. Even though malicious code is split and distributed in multiple processes, the split code snippets have to synchronize each other at runtime to maintain the order of the execution of the original malicious code. We exploit this characteristic of distributed code injection attacks with our method. The experimental results showed that our method successfully found all distributed code snippets and assisted to reconstruct the original code from them. We believe that we are the first to present a countermeasure against distributed code injection attacks. We also believe that our method is able to improve the efficiency of forensics especially for a host compromised with distributed code injection attacks.

A Implementation Details

In this appendix, we explain how we implemented the component for building Thread to Thread links. To build them, we have two steps. First is how we extract the threads waiting for a synchronization object. Second is how we extract the thread holding a synchronization object. To simplify the explanation, we focus our scope into only semaphore from several synchronization objects.

Extraction of Threads Waiting for a Synchronization Object. We first explain the data structure for the extraction, i.e., KWAIT_BLOCK. Then, we explain how to extract threads using the data structure.

All threads waiting for a semaphore object are linked via KWAIT_BLOCKs. KWAIT_BLOCK structure represents a list entry of the wait list for a synchronization object. The wait list is a LIST_ENTRY-based doubly-linked list [15] linking with KWAIT_BLOCKs as many as threads waiting for the same synchronization object. A KWAIT_BLOCK also includes two pointers: Thread and Object. The Thread points to the thread object, i.e. KTHREAD object, corresponding a waiting thread. A KTHREAD object has the WaitBlockList pointing to an array of KWAIT_BLOCKs for synchronization objects waited by the thread [3]. The Object points to the synchronization object waited for by the thread pointed to by the Thread. A synchronization object has the WaitListHead that is the head LIST_ENTRY of the KWAIT_BLOCK list.

By walking each KWAIT_BLOCK list, we can retrieve all waiting threads and the waited semaphore object. After our plugin enumerates thread objects corresponding the threads executing suspicious code regions, it firstly extracts KWAIT_BLOCKs from WaitBlockList of each of the thread objects. Second, our plugin extracts the semaphore object and other waiting threads by traversing the list of each of the KWAIT_BLOCKs. Third, it distinguishes semaphore objects waited for by only threads executing suspicious code regions and defines the semaphore objects as ones for coordinating distributed code snippets. Our plugin finally extracts the threads waiting for the semaphore objects.

Extraction of Threads Holding a Synchronization Object. We first explain the problem on how to identify the thread holding a semaphore object. Then, we explain our approach to solve the problem extracting the thread via the handle for the object opened by a process.

The problem is that there is no explicit evidence to find the owners of a semaphore object in Windows environment. A KWAIT_BLOCK list for a semaphore object is defined to manage only waiting threads and does not include any information regarding the owners of the semaphore object. Semaphore object, i.e. KSEMAPHORE object, also has no direct pointer to the owners. Therefore, we need to find the owner threads of it from other data sources.

To solve this problem, we focus on processes opening the handles of a specific semaphore objects. All processes owning threads holding semaphore objects must hold handles for the semaphore objects. The semaphore objects for coordinating distributed code snippets must be unique and never acquired by threads executing benign code. Therefore, we can use processes as mediators to find out threads holding the semaphore objects.

Figure 7 illustrates how to find out the owner thread in our implementation. The detail of our approach is as follows.

Fig. 7.

Linked code snippets via threads sharing a semaphore object.

• 1. Find semaphore objects based on the results of waiting threads extraction.

• 2. Enumerate processes holding a handle for each of the objects.

• 3. Extract processes owning threads, which are detected as executing suspicious code and are not waiting for the semaphore object, from the enumerated processes.

• 4. Define the threads as the owners of the semaphore objects.

We explain each step of our plugin with Fig. 7. Our plugin first detects the thread A, B, and C executing the suspicious code (1), (2), and (3), like in the case of Fig. 3. The thread B and C are waiting for the semaphore object X and our plugin builds a link between the thread B and C from the KWAIT_BLOCK list for the semaphore object X. After that, our plugin starts extracting the owner threads of the semaphore objects. For the first step, it finds the semaphore object X via the thread B and C. For the second step, our plugin enumerates the process A’, B’, C’ as processes holding a handle for the semaphore X. For the third step, it distinguishes the process A’ owning the thread A, which is not waiting the semaphore object X, from the others. For the fourth step, our plugin defines the thread A as the current owner of the semaphore object X. Our plugin finally builds a Thread to Thread link throughout the thread A, B, and C.