First published October 2009
by Access Data
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 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.
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
As investigators, we now have established a need to acquire the entire RAM image before the machine has been turned off. But oftentimes we run into situations where there simply isn’t enough time to image the entire file system. Memory analysis can solve both problems. Since acquiring memory is far quicker than imaging the entire file system, taking a snapshot of volatile data will provide an instant determination whether a full acquisition is necessary. This leads into a discussion about having an entire image of the file system as it existed compared to having a snapshot of the volatile memory. This is an important conversation and certainly helps us determine Need vs. Speed. Regardless of your position on this subject, we can all agree that having access to the volatile data would without a doubt help out in the investigation rather than not having the data from volatile memory.
Using AccessData Enterprise for Memory Search and Analysis
Building a functional and thoughtful workflow around memory acquisition and memory analysis is critical to quickly and accurately resolving an investigation or security breach. AccessData has developed a best practices approach to acquiring live or dumped physical memory by parsing the _EPROCESS blocks and enumerating all contents within volatile memory. Recall the _EPROCESS block described above. Contained within each process’ _EPROCESS block are several important items that describe the process: its Process Identifier (PID), its Parent Process Identifier (PPID), the list of loaded modules, etc. One of the most important parts of this structure is the process’ Directory Table Base (DTB). This item helps the operating system manage which physical memory pages belong to which process’ virtual memory space. AccessData technology uses the full memory image and each process’ DTB to create a physical to virtual mapping, allowing further analysis of the memory image to identify which process owns which page of memory. Furthermore, the technology is also able to determine whether that virtual address corresponds to the executable itself, a loaded dll, or some other virtual address in the process’ virtual memory space—likely a heap or stack. The workflow is captured in Figure 3 below. This approach allows our technology to find\locate\capture rogue processes that you would not otherwise be aware of.
Using the memory analysis feature makes AccessData’s hidden process detection capabilities some of the strongest in the industry. By brute force searching for _EPROCESS blocks, the kernel-level driver is able to identify all processes running on the system regardless of whether they are included in the _EPROCESS block chain. Then the results are compared against Windows API and those processes that Windows is not aware of are labeled as suspicious and highlighted, so the investigator can see what processes are hidden from Windows. Additionally, the user has the ability to set up a differential view of what is running in RAM, compared to an analysis taken earlier in time.
An additional function of AccessData’s memory analysis capabilities is the capability to search through all of memory for specific artifacts. This is also an important aspect of the examination process since you can now search through the binaries looking for artifacts that are not accessible through other means. When performing incident response types of investigations, this is important since more and more attacks are taking place in RAM only, and without this capability an investigator would not normally find what they are looking for.
The following key capabilities are critical when analyzing memory, and they are all available in AccessData’s digital investigations technology:
· Memory capture and analysis of Windows operating systems, from Windows 2000 to Vista SP1.
· Memory analysis is performed on the agent itself.
· The agent holds strings of data provided by the examiner, will find responsive items, and then send them back to the examiner machine for further analysis.
· The examiner can investigate the responsive items, and if the event is found to be real, the examiner is given the ability to then fully acquire memory from said target.
· The examiner can carve out individual files from volatile memory for further analysis.
· Once the memory file is acquired, the investigator is given an easy-to-use workflow, allowing for the easy entry of search criteria.
FIGURE 3 (click to enlarge): Workflows for Memory Storage, Display and Analysis, and Import and Analysis
Since malware authors and other adversaries are no longer relying on the file system to store and execute their data, the “pull-the-plug” procedure is no longer an acceptable approach. Too much valuable data is lost that can assist the investigator or incident responder in resolving a case. Investigators are always being challenged to provide additional evidence that would directly affect the results of the case or security incident. With this said, the job of the investigator is becoming more and more complex, and the industry requires tools that are feature rich, respond quickly to complex tasks, and are easy to deploy and use. AccessData’s digital investigations technology delivers a best practices approach to acquiring live or dumped physical memory by finding and parsing the _EPROCESS blocks and enumerating all content within volatile memory. With the release of FTK 3 and AD Enterprise, AccessData is firmly at the forefront of addressing these issues. The memory search and analysis capabilities now available to FTK and AD Enterprise users have surpassed most other tools on the market today.
©2009 AccessData, Inc. All Rights Reserved. AccessData, Forensic Toolkit and FTK are registered trademarks owned by AccessData in the United States and other jurisdictions and may not be used without prior written permission. All other marks and brands may be claimed as the property of their respective owners.