Historically, criminal or corporate investigations involving computer equipment began by immediately disconnecting any compromised machines from the network, powering them down, and securing them in a proper environment where they would be imaged and analyzed. The rationale for this approach as the first step in the response process originates in the idea of preserving the state of the hard disk at the time of response at all costs. Thus, the thought was that if the system was allowed to continue running, valuable evidence may be inadvertently or intentionally overwritten.

This investigative model worked very well for several years, but times have changed. Knowing that an investigator’s first action would be to “pull-the-plug” on a compromised system before performing any analysis, malware authors began reducing their footprint on the victim’s hard disk and instead storing as much as possible within the machine’s volatile Random Access Memory (RAM). Since the contents of RAM are cleared when the computer is powered down, once the investigator ”pulls the plug,” all traces of potential malicious code, including its capabilities, any commands given to it by the attacker, and data it may have exfiltrated from your network, have vanished.

As a result of this shift in tactics by malicious software authors, it is now widely recognized in the forensics and incident response communities that an investigator cannot take the risk of immediately powering down machines involved in a security incident. The new investigative approach starts with an understanding of what resides in volatile memory by using tools that quickly analyze Random Access Memory (RAM) and allow the investigator to include volatile memory as part of the evidence. Investigators that limit their analysis to the non-volatile data stored on the hard drive not only leave vital evidence behind, but also completely destroy it once the machine is shut down.

Additionally, advanced threats residing in volatile memory are typically hidden from the administrator and Windows Application Programming Interface (API). Therefore, rogue processes may execute without visibly affecting the user experience or tripping host-based security mechanisms. As the sophistication of malware continues to increase, capturing the volatile data at the onset of an incident investigation is becoming critical to identifying, tracking and remediating the threat. In fact, in some cases, volatile memory analysis is the only way to identify, track and remediate the threat.

Whether you are a law enforcement officer or a corporate security officer, the analysis of memory within Windows systems should be a standard procedure for all computer security incidents and digital investigations. Without this analysis, you are leaving valuable evidence behind. Not only is it important to quickly review the contents of memory structures, but it is also important to be able to enumerate and export the malicious findings. There are a number of tools on the market that allow you to acquire data, but these tools do not necessarily allow you to analyze memory on the local system, let alone remote systems across the network. Additionally, most of them do not facilitate searching memory for specific artifacts. This paper will discuss the importance of memory search and analysis with a focus on Microsoft Windows hosts.

Volatile Memory Explained

Understanding how volatile memory operates is quite complex and cannot be fully addressed in this white paper. However, a basic overview will help the reader understand how Windows organizes its internal structures in memory and how these structures can be manipulated to hide code and data from both the user and the operating system.

Figure 1 shows how Windows represents the list of running processes. Each process is represented by an _EPROCESS block. You will notice that contained within each _EPROCESS block is both a pointer to the next process (fLink – Forward Link) and a pointer to the previous process (bLink – Back Link). When the operating system is operating normally, the _EPROCESS blocks and their pointers come together to resemble a chain, which is also known as a doubly-linked list. This chain is stored in kernel memory and is updated every time a process is launched or terminated. The Windows API walks this list from head to tail when enumerating processes via Task Manager, for example.

FIGURE 1

Figure 2 shows the most common method used by malicious code authors to hide processes from the Windows API. This process, known more generically as Direct Kernel Object Manipulation (DKOM), involves directly manipulating the list of _EPROCESS blocks to “unlink” a given process from the list. In this illustration, a malicious code author wishes to hide the second process from the user. By changing the forward link of process 1 to point to the third process, and changing the “bLink” of process 3 to point to process 1, the attacker’s process is no longer part of the list of _EPROCESS blocks. Since the Windows API uses this list to enumerate processes, the malicious process will be hidden from the user but still able to operate normally. Of course, even though the _EPROCESS block is no longer part of the list, the _EPROCESS block data itself still resides in memory. Therefore, through memory analysis, we can find this process, find that it is no longer properly linked with the other legitimate processes running on the system, and flag it as suspicious.

FIGURE 2

Why is it important?

“To put it bluntly, we are getting our heads handed to us by targeted attacks originating from brilliant children.”

The goal in an investigation is to leave no stone unturned. As Dr. Staggs stated rather directly, our adversaries are very creative and talented when it comes to hiding data. So, not only do you need a forensically sound solution that can acquire memory, but you also need a solution that analyzes the volatile areas of RAM at the original point of seizure.

The tool at minimum needs to quickly capture a snapshot of the following items found in volatile memory:

· Running and linked processes, running and unlinked processes, terminated processes
· Process ID (PID) /Parent ID
· The command line and arguments
· Full path to the executable (image path/environment path)
· Loaded DLLs, their metadata and sizes
· Window title
· Process create /exit time and its current working directory
· Handles for each process
· Thread enumeration for each process
· Network socket enumeration (active /listening) associated to each process