Unplugging a machine before acquiring an image of the hard drive has several serious drawbacks:

Although dead forensic acquisition techniques can produce a substantial amount of information, they can't recover everything. Much potential evidence is lost when you remove the power. To avoid losing any valuable evidence when you turn off a device, forensic techniques have expanded to include evidence acquisition from a live system. Instead of just capturing an image of a persistent storage device, live forensic acquisition captures an image of a running system. A properly acquired live image includes volatile memory images and images of selected persistent storage devices, such as disk drives and universal serial bus (USB) devices. Live forensic acquisition images have the advantage of capturing state information of a running system instead of only producing historical information of a dead system.

Using live forensic acquisition techniques has advantages. It also involves some barriers. For example, the process of proving a live image that's forensically sound and unaltered is more complex than with dead system images. Running systems write to memory many times each second. Each program routinely accesses different areas of memory in its normal operation. The overall procedures in live forensics are similar to dead system image acquisition. However, additional controls are necessary to ensure that all images acquired from a live system are forensically sound.

Live forensic acquisition methods are very similar to the methods commonly used on dead systems. In both cases, you collect, examine, analyze, and report on evidence. Whether you take evidence from a live or dead system, provide proof that you've protected the evidence's integrity. You'll also have to prove that you've taken proactive steps to ensure that the evidence didn't change during the acquisition process.

One of the first steps when acquiring data in an investigation is to determine whether you will use live or dead forensic acquisition techniques. If the computer or device has already been turned off, the best choice is to use dead forensic acquisition techniques. In this case, follow the procedures covered in Chapter 7, "Collecting, Seizing, and Protecting Evidence." Any data that was in volatile memory was lost when power was removed. Dead forensic acquisition techniques provide evidence from only the remaining persistent data.

If the computer or device hasn't been turned off since the decision was made to acquire evidence, you have the option of using live forensic acquisition techniques to collect evidence. Using live forensic techniques can provide more information about the state of the suspect computer or device than similar dead acquisition procedures. If you choose to acquire evidence using a live acquisition process, follow these steps:

Even if you have chosen to pursue a live forensic investigation, you have no guarantees that you will get more valuable evidence than you'd get by using dead forensic acquisition techniques. A live system in which a user is logged on may allow you to acquire additional evidence. However, you'll be limited by the access restrictions of the logged-in user. A user account that has administrative or superuser privileges will allow you to access more resources and carry out more tasks than a user account with lesser privileges. However, many user accounts lack this additional level of capability. For instance, many organizations limit what files standard users can access and don't allow them to install new software. You'll have an easier time acquiring evidence when using a user account with elevated privileges.

Another common situation you may encounter during a live forensic investigation is the use of virtual environments. A virtual machine is a software program that appears to be a physical computer and executes programs as if it were a physical computer. You commonly use a virtual machine when you need to run an operating system on another computer. For example, you can run one or more Linux virtual machines on a computer running a Microsoft Windows operating system. Virtual machines are popular in organizations that want to save IT costs by running several virtual machines on a single physical computer. Two of the most popular software packages that implement virtual machines are VMware and VirtualBox.

Whether the suspect computer is a physical machine or virtual machine, you follow basically the same methods. However, if you find that your suspect computer is a virtual machine, you must follow a few additional steps. Because a virtual machine runs as a program on a physical machine, conduct forensic acquisition on the physical computer as well. Many physical computers that host virtual machines tend to host multiple virtual machines. Part of your evidence collection activities should include collecting images of all virtual machines on the same physical computer as the suspect computer. Other virtual machines may contain evidence related to the suspect computer as well.

Today's virtual machine software does a good job of emulating physical computers. It can be difficult to determine whether an environment is operating in the virtual or physical space. You may not immediately know whether a suspect computer is a virtual or physical computer. You can look for a number of clues to determine whether you're examining a virtual machine. Check in system files for notes or vendor identification strings. Common virtual machine software installs easily recognizable device drivers, network interfaces, virtual machine BIOS, and specific helper tools. Look for the existence of any of these telltale indications that you're examining a virtual environment. Another common technique is to use hardware fingerprinting to detect hardware that's always present in a virtual machine. For example, if you're examining a Mac environment but hardware fingerprinting shows that Microsoft Corporation made your motherboard, you can be sure you're looking at a virtual machine. You can also find software that detects the presence of virtual machines. These tools can be handy but may affect the soundness of the evidence you collect. Always investigate tools you plan to use to ensure that they protect the integrity of your evidence. The following are examples of tools that can help detect virtual machines:

Live acquisition gives you the ability to collect volatile data that can contain valuable information, such as network and system configuration settings. This volatile data can provide evidence to help prove accusations or claims in court. Examples of volatile data include a list of current network connections and currently running programs. This information would not be available from dead forensic acquisition.

The process of collecting useful volatile data limits your actions more than when you're conducting dead forensic acquisition activities. Live forensic acquisition yields the most valuable data when you collect that data before it changes. As a computer continues to run, it changes more and more of its volatile memory. The sooner you collect evidence, the more pertinent it will be to your investigation. Because volatile memory changes continually, the passing of time decreases how much useful information you can expect to collect. Also, just the presence of another program you're using to collect volatile data may change existing volatile data. It's important that you prioritize what data you need for your investigation and collect it as soon as possible. Focus on the most volatile data first and then collect data that is less sensitive to the passage of time. In other words, collect the data you most need and that is most likely to change in the near term. You can collect data that is not as likely to change later.

Although live acquisition can provide much more useful information than dead forensic acquisition, it poses unique challenges. The richness of today's software provides many options for users to customize their own environments. A forensic specialist must possess a wide breadth of knowledge of common computer hardware, operating systems, and software. Users have many different ways to configure each computer component, and knowing how these components operate is crucial to successfully collecting solid information. For example, one question is whether to terminate a program. Many Web browsers make it easy to delete history and temporary files upon exit from the program. In these cases, you may not want to terminate the program before collecting evidence. Other programs may automatically save data periodically and overwrite previous evidence you may need. In such a case, collect evidence before the program overwrites it. It is also helpful to understand the general reasons users may choose some configuration options. If you find that a user has configured a Web browser to automatically delete all history, you may be investigating someone who has something to hide. While this is not always the case, it may be productive to look for other signs that someone is hiding or cleansing evidence.

Evidence that you can use in court must be in pristine condition. It must be in the same state it was in when you collected it. Any action that changes evidence will likely make the evidence inadmissible and useless in court. Evidence that was changed in the process of acquisition or analysis is forensically unsound. Live forensic acquisition poses more dangers to the soundness of evidence than dead forensic acquisition. Any action, such as examining the central processing unit (CPU) registers, can actually cause the CPU registers, RAM, or even hard drive contents to change values. Any change that is a result of acquisition activities violates the soundness of the evidence. Because today's operating systems use virtual memory, a portion of any program is likely to be swapped, or paged, out to the disk drive at some point during its lifetime. Even the use of write blockers will not protect your disk drive from modifications due to swapping and paging. This common operating system behavior can ruin evidence. It is important that you understand how the live forensic acquisition process works and how to protect evidence from accidental changes.

Another issue that is a common problem with live analysis is slurred images. A slurred image is similar to a photograph of a moving object. A slurred image, in the context of live forensic acquisition, is the result of acquiring a file as it is being updated. Even a small file modification can cause a problem because the operating system reads the metadata section of the hard disk before accessing any file. If a file or metadata folder in the file system changes after the operating system has read the metadata but before it acquires the data, the metadata and data sectors may not totally agree.

Anytime you use live forensic acquisition, recognize that external influences may affect your investigation. Part of your collection process should be to ensure the authenticity and reliability of evidence, especially when acquiring evidence remotely using a network connection. Advances in technology have made anti-forensic devices and software available to a determined person. Suspects can use a number of tools to interfere with or even totally invalidate your evidence collection efforts. One of the simplest methods they use is to monitor a computer for forensic activity and then destroy all evidence before you can collect it. Other programs make it easy to clean up evidence before being detected or just hide it from prying eyes. The following are some programs that remove or hide evidence of activity:

To study the consistency problem, you need to understand the basic structure of memory. When a program is loaded into memory, it is basically divided into segments. The structure may not be the same for all hardware and operating systems, but the concept of memory division is consistent. Windows, for example, has four segments (see Figure 12-1):

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 either related to 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 because the memory segment contains only code and functions of the program.

The global, static, heap, and stack data can be partitioned within a running process. For example, D_i, H_i, and S_i (where i =1, 2, 3, ...) can exist in different segments. In an ideal case, when a snapshot is taken of a process at time t, the memory dump is consistent with respect to that point in time. In reality, however, it is impossible to obtain a memory snapshot. Memory dumping takes time. The dumping process spans a time interval.

For a very fast memory dump, the data in C should be consistent, and data in D may be consistent, depending on the program usage. The data in H is likely to be inconsistent because the segment may grow when the program calls it. The data in S is highly likely to be changing due to its dynamic data structure. Variables for the process functions are continually used and reused in this segment. This causes inconsistency in part of the dumped data collected.

The data in C is relatively static and remains consistent in a memory dump. The global and static data in D are less volatile and may remain consistent. Due to the special functionality of heap and stack, the data stored within those segments are more dynamic and may be inconsistent.

Each memory process has its own allocated space in system memory. This space may include both physical and virtual addresses. Locating the heap and stack segments of memory within a logical process dump can help you achieve maximum data validity.

To locate the heap segment, use the system call sbrk to reveal the address space of a process. When you invoke sbrk with 0 as the parameter, it returns a pointer to the current end of the heap segment. The system command pmap displays information about the address space of a process, as well as the size and address of the heap and/or stack segment.

One technique for approaching a compromised system is live response. In live response, you survey the crime scene, collect evidence, and at the same time probe for suspicious activity. In a live response, you first establish a trusted command shell. In addition, you establish a method for transmitting and storing the information on a data collection system. One option is to redirect the output of the commands on the compromised system to the data collection system. A popular tool for this is Netcat, a network debugging and investigation tool that transmits data across network connections. Another approach is to insert a USB drive and write all query results to that external drive. Finally, attempt to bolster the credibility of the tool output in court.

During a live interrogation of a system, the state of the running machine is not static. You could run the same query multiple times and produce different results, based on when you run it. Therefore, hashing the memory is not effective. Instead, compute a cryptographic checksum of the tool outputs and make a note of the hash value in the log. This would help dispel any notion that the results were altered after the fact. For example, HELIX is a live response tool from a Linux bootable CD. Use this tool to establish a trusted command shell.

When the data collection setup is complete, begin to collect evidence from the compromised system. The tools used in this exercise are PsList, ListDLLs, Handle, Netstat, FPort, Userdump, Strings, and PSLoggedOn. This is not meant to be an exhaustive list. Rather, these are representative of the types of tools available. The common thread for the tools used here is that each relies on native API calls to some degree. Thus the results are filtered through the operating system.

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.

The following sections discuss the capabilities of two memory analysis tools applied on the memory image example we've been discussing. These tools, The Volatility Framework and PTFinder, are relatively recent additions to the excellent array of open source resources available to digital investigators.

python volatility ident -f WinXP_victim.vmem

python volatility datetime -f WinXP_victim.vmem

The preceding sections discuss two different incident response approaches. The first approach is the well-known live response, in which you survey the crime scene and simultaneously collect evidence and probe for suspicious activity. The second approach is the relatively new field of volatile memory analysis, in which you collect a memory dump and perform analysis in an isolated environment. Each of these approaches gives you different insight into the environment you're investigating.

Several issues with live response hinder effective analysis of a digital crime scene. The purpose of live response is to collect relevant evidence from the system to confirm whether an incident occurred. This process has some significant drawbacks, including the following:

Volatile memory analysis shows promise in that the only source of evidence is the physical memory dump. Moreover, investigators now collect physical memory more commonly. An investigator can build a case by analyzing a memory dump in an isolated environment that is unobtrusive to the evidence. Thus, volatile memory analysis addresses the drawbacks facing live response as follows:

One of the greatest drawbacks with volatile memory analysis is that the support for these tools has not matured. With every release of a new operating system, the physical memory structure changes. Development of memory analysis tools has been gaining velocity recently, but kinks remain. Memory analysis tools must be available in parallel with an operating system for maximum utility.

The development of live forensic acquisition in general presents a remedy for some of the problems introduced by traditional forensic acquisition. With current technologies, however, the most effective analytic approach is a hybrid based on situational awareness and triage techniques. Instead of being used to gather exhaustive amounts of data, live response should move to a triage approach, collecting enough information to determine the next appropriate step. In some situations, greater understanding of the running state of the machine is critical to resolving a case. In such cases, use full memory analysis—and the requisite memory acquisition—to augment and supplement traditional digital forensic examination.