Volatile memory analysis is a live system forensic technique in which you collect a memory dump and perform analysis in an isolated environment. Volatile memory analysis is similar to live response in that you must first establish a trusted command shell. Next, you establish a data collection system and a method for transmitting the data. However, you would only acquire a physical memory dump of the compromised system and transmit it to the data collection system for analysis. In this case, VMware allows you to simply suspend the virtual machine and use the .vmem file as a memory image.

As in other forensic investigations, you would also compute the hash after you complete the memory capture. Unlike with traditional hard drive forensics, you don’t need to calculate a hash before data acquisition. Due to the volatile nature of running memory, the imaging process involves taking a snapshot of a “moving target.”

The primary difference between this approach and live response is that you don’t need any additional evidence from the compromised system. Therefore, you can analyze the evidence on the collection system.

To produce digital data from a live system as evidence in court, it is essential to justify the validity of the acquired memory data. One common approach is to acquire volatile memory data in a dump file for offline examination. A dump is a complete copy of every bit of memory or cache recorded in permanent storage or printed on paper. You can then analyze the dump electronically or manually in its static state.

Programmers have developed a number of toolkits to collect volatile memory data. These automated programs run on live systems and collect transient memory data. These tools suffer from one critical drawback: If run on a compromised system, such a tool heavily relies on the underlying operating system. This could affect the collected data’s reliability. Some response tools may even substantially alter the digital environment of the original system and cause an adverse impact on the dumped memory data.

As a result, you may have to study those changes to determine whether the alterations have affected the acquired data. Data in memory is not consistently maintained during system operation. This issue poses a challenge for computer forensics.

Maintaining data consistency is a problem with live system forensics in which data is not acquired at a unified moment and is thus inconsistent. If a system is running, it is impossible to freeze the machine states in the course of data acquisition. Even the most efficient method introduces a time difference between the moment you acquire the first bit and the moment you acquire the last bit. For example, the program may execute Function A at the beginning of the memory dump and execute Function B at the end. The data in the dump may correspond to different execution steps somewhere between Function A and Function B. Because you didn’t acquire the data at a unified moment, data inconsistency is inevitable in the memory dump.

When dumping memory, it is useful for the forensic examiner to be aware of the fact that there are actually two types of memory:

• Stack (S)—Memory in the stack (S) segment is allocated to local variables and parameters within each function. This memory is allocated based on the last-in, first-out (LIFO) principle. When the program is running, program variables use the memory allocated to the stack area again and again. This segment is the most dynamic area of the memory process. The data within this segment is discrepant and influenced by the program’s various function calls.

• Heap (H)—Dynamic memory for a program comes from the heap (H) segment. A process may use a memory allocator such as malloc to request dynamic memory. When this happens, the address space of the process expands. The data in the heap area can exist between function calls. The memory allocator may reuse memory that has been released by the process. Therefore, heap data is less stable than the data in the data segment.

When a program is running, the code, data, and heap segments are usually placed in a single contiguous area. The stack segment is separated from the other segments. It expands within the memory allocated space. Indeed, the memory comprises a number of processes of the operating system or the applications it is supporting. Memory can be viewed as a large array that contains many segments for different processes. In a live system, process memory grows and shrinks, depending on system usage and user activities.

This growth and shrinking of memory is related to either the growth of heap data or the expansion and release of stack data. The data in the code segment is static and remains intact at all times for a particular program or program segment. Data in the growing heap segment and stack segment causes inconsistency in the data contained in memory as a whole. The stack data has a greater effect than the heap data. Nevertheless, the code segment contains consistent data. Consistent data is usually dormant and not affected when a process is running in memory. When you obtain a process dump of a running program, data in the code segment remains unchanged.

Tools

A number of tools and even some Windows utilities are available that can help you to analyze live data on a Windows system. This section looks at some of the more widely used tools and utilities.

PsList

Use PsList to view process and thread statistics on a system. Running PsList lists all running processes on the system. However, it does not reveal the presence of the rootkit or the other processes that the rootkit has hidden. PsList is part of a suite of tools, PsTools, available as a free download from http://technet.microsoft.com/en-us/sysinternals/bb896682.aspx. You can see this tool used in FIGURE 8-1.

PsInfo

This tool is also from the PsTools suite. It can tell you system uptime (time since last reboot), operating system details, and other general information about the system. This is good background information to put into your forensic report. This tool is shown in FIGURE 8-2.

ListDLLs

ListDLLs allows you to view the currently loaded dynamic-link libraries (DLLs) for a process. Running ListDLLs lists the DLLs loaded by all running processes. However, ListDLLs cannot show the DLLs loaded for hidden processes. Using a Trojan horse to compromise a program or system DLL, however, is a common attack vector. So, this tool can be important to your forensic investigation. This tool is also available online for free. You can download it from http://technet.microsoft.com/en-us/sysinternals/bb896656.aspx. You can see this utility in use in FIGURE 8-3.

PsLoggedOn

PsLoggedOn helps you discover users who have logged on both locally and remotely. Of most importance, it tells you who is logged on to shares on the current machine. This is also part of the PsTools suite available from Microsoft TechNet. This utility is shown in FIGURE 8-4.

Using netstat

This utility is important in the context of checking live system data. Remember that netstat is a command-line tool that displays both incoming and outgoing network connections. It also displays routing tables and a number of network interface statistics. It is available on UNIX, UNIX-like, and Windows-based operating systems.

Use the netstat utility to view the network connections of a running machine. Running netstat with the an option will show all ports, list what they are doing (listening or sending), and list them in numerical order. This can be useful information in your forensic analysis, particularly if the suspected crime uses spyware or a botnet. You can see netstat in FIGURE 8-5.

Using Fport

Fport is a free tool formerly available from Foundstone, now distributed by McAfee, which you can find at http://www.mcafee.com/us/downloads/free-tools/fport.aspx. Fport allows you to view all open TCP and UDP ports and maps those to specific processes. This lets you know which process is using which port. This tool is similar in function to running netstat -an.

Userdump

Userdump is a command-line tool for dumping basic user info from Windows-based systems. With Userdump, you can extract the memory dumps of running processes for offline analysis. This is a free tool from Microsoft, which you can download from http://www.microsoft.com/en-us/download/details.aspx?id=4060. This tool is used primarily to dump data to an external file, so you need to specify where to dump the data.

PTFinder

PTFinder, by Andreas Schuster, is a Perl script memory analysis tool; you can find more information at http://computer.forensikblog.de/en/2007/11/ptfinder_0_3_05.html. It supports analysis of Windows operating system versions.

PTFinder enumerates processes and threads in a memory dump. It uses a brute-force approach to enumerating the processes and uses various rules to determine whether the information is either a legitimate process or just bytes. Although this tool does not reveal anything new in terms of malware, it does enable repeatability of the results, which is an important benefit in volatile memory analysis. The No Threads option in PTFinder provides a list of processes found in a memory dump. This is an open source graphics language that provides a visual representation of the relationships between threads and processes.

There are certainly other tools that you can use to examine a live system forensically. However, the tools just listed are the ones most commonly used.