Introduction

More and more, investigators are faced with situations in which the traditional, accepted computer forensics methodology of unplugging the power from a computer and then acquiring a bit-stream image of the system hard drive is, quite simply, not a viable option. Investigators and incident responders are also seeing instances in which the questions they have (or are asked) cannot be answered using the contents of an imaged hard drive alone. For example, I've spoken with law enforcement officers regarding how best to handle situations involving missing children who were lured from their homes or school via instant messages (IMs).

These questions are not limited to law enforcement. In many cases, the best source of information or evidence is available in computer memory (network connections, contents of the IM client window, memory used by the IM client process, and so on), since an IM client does not automatically create a log of the conversation, for example. In other cases, investigators are asked if there was a Trojan or some other malware active on the system and whether sensitive information was copied off the system. First responders and investigators are being asked questions about what activity was going on while the system was live. Members of IT staffs are finding anomalous or troubling traffic in their firewall and IDS logs and are shutting off the system from which the traffic is originating before determining which process was responsible for the traffic. Situations like these require that the investigator perform live response—collecting data from a system while it is still running. This in itself raises some issues, which we will address throughout this chapter.

Live Response

There are a number of issues facing investigators today where unplugging a system (or several systems) and acquiring an image of the hard drive(s) might not be an option. As the use of e-commerce continues to grow, system downtime is measured in hundreds or thousands of dollars per minute, based on lost transactions. Therefore, taking a system down to acquire a hard drive image has a serious effect on the bottom line. Also, some companies have service-level agreements (SLAs) guaranteeing "five nines" of uptime—that is, the company guarantees to its customers that the systems will be up and operational 99.999 percent of the time (outside of maintenance windows, of course). Taking a system with a single hard drive offline to perform imaging can take several hours, depending on the configuration of the system.

The Information Superhighway is no longer just a place for joy riders and pranksters. A great deal of serious crime takes place in cyberspace, and criminal activities are becoming more and more sophisticated. There are software programs that can get into your computer system and steal your personal information (passwords, personal files, income tax returns, and the like), yet the code for some of these programs is never written to the hard drive; the programs exist only in memory. When the system is shut down, all evidence of the program disappears.

In April 2006, Seagate introduced the first 750GB hard drives. (For more information go to www.seagate.com/cda/newsinfo/newsroom/releases/ article/0,1121,3153,00.html.) Imagine a RAID system with five or eight such hard drives, topping out at 6 terabytes (TB) of storage. How long would it take you to image those hard drives? With certain configurations, it can take investigators four or more hours to acquire and verify a single 80GB hard drive. And would you need to image the entire system if you were interested in only the activities of a single process and not in the thousands of files resident on the system?

In some cases, before stepping off into a more traditional computer forensics investigation, we might want to collect some information about the live system before shutting it down and acquiring a bit-stream image of the hard drive or drives. The information you would be most interested in is volatile in nature, meaning that it ceases to exist when power is removed from the system. This volatile information usually exists in physical memory, or RAM, and consists of such things as information about processes, network connections, the contents of the clipboard, and so on. This information describes the state of the system at the time you are standing in front of it or sitting at the console. As an investigator, you could be faced with a situation in which you must quickly capture and analyze data (covered in the next chapter) to make a determination of the nature and scope of the incident. When power is removed from the system in preparation for imaging the hard drive in the traditional manner, this information simply disappears.

We do have options available to us—tools and techniques we can use to collect this volatile information from a live system, giving us a better overall picture of the state of the system as well as providing us with a greater scope of information. This is what "live response" entails: accessing a live, running system and collecting volatile (and in some cases, nonvolatile) information.

There is another term you might hear that is often confused with live response: live acquisition. Live response deals with collecting volatile information from a system; live acquisition describes acquiring the hard drive while the system is still running and creating an image of that hard drive. In this chapter, we start by discussing tools, techniques, and methodologies for performing live response. When we talk about performing live response, we need to understand what information we want to collect from the system and how we should go about collecting it. In this chapter, we will walk through the what and how of collecting volatile information from a system; in the next chapter, we will discuss how to analyze this data. Following that, we will examine some solutions for performing a live acquisition. Analysis of the image collected during live acquisition will be covered in the remaining chapters of this book.

Before we start discussing live response tools and activities, we need to address two important topics: Locard's Exchange Principle and the order of volatility. These concepts are the cornerstones of this chapter and live response in general, and we will discuss them in detail.

Locard's Exchange Principle

In performing live response, investigators and first responders need to keep a very important principle in mind. When we interact with a live system, whether as a user or as an investigator, changes will occur on that system. On a live system, changes will occur simply due to the passage of time, as processes work, as data is saved and deleted, as network connections time out or are created, and so on. Some changes happen when the system just sits there and runs. Changes also occur as the investigator runs programs on the system to collect information, volatile or otherwise. Running a program causes information to be loaded into physical memory, and in doing so, physical memory used by other, already running processes may be written to the page file. As the investigator collects information and sends it off the system, new network connections will be created. All these changes can be collectively explained by Locard's Exchange Principle.

In the early 20th century, Dr. Edmond Locard's work in the area of forensic science and crime scene reconstruction became known as Locard's Exchange Principle. This principle states, in essence, that when two objects come into contact, material is exchanged or transferred between them. If you watch the popular CSI crime show on TV, you'll invariably hear one of the crime scene investigators refer to possible transfer. This usually occurs after a car hits something or when an investigator examines a body and locates material that seems out of place.

This same principle applies to the digital realm. For example, when two computers communicate via a network, information is exchanged between them. Information about one computer will appear in process memory and/or log files on the other (see the "Locard and Netcat" sidebar for a really cool demonstration of this concept). When a peripheral such as removable storage device (a thumb drive, an iPod, or the like) is attached to a Windows computer system, information about the device will remain resident on the computer. When an investigator interacts with a live system, changes will occur to that system as programs are executed and data is copied from the system. These changes might be transient (process memory, network connections) or permanent (log files, Registry entries).

Programs that we use to collect information might have other effects on a live system. For example, a program might need to read several Registry keys, and the paths to those keys will be read into memory. Windows XP systems perform application prefetching, so if the investigator runs a program that the user has already run on the system, the last access and modification times of the prefetch file (as well as the contents of the file itself) for that application will be modified. If the program that the investigator runs hasn't been used before, a new prefetch file will be created in the Prefetch directory (assuming the contents of the Prefetch directory haven't reached their 128 .pf file limit ... but more on that later in the book).

Investigators not only need to understand that these changes will occur, they must also document those changes and be able to explain the effects their actions had on the system, to a reasonable extent. For example, as an investigator you should be able to determine which .pf files in the XP Prefetch directory are a result of your efforts and which are the result of user activities. The same is true for Registry values. As with the application prefetching capabilities of Windows XP, your actions will have an effect on the system Registry. Specifically, entries may appear in the Registry, and as such the LastWrite times of the Registry keys will be updated. Some of these changes might not be a direct result of your tools or actions but rather are made by the shell (i.e., Windows Explorer), due simply to the fact that the system is live and running.

By testing and understanding the tools you use, you will be able to document and explain what artifacts found on a system are the result of your efforts and which are the result of actions taken by a user or an attacker.

Order of Volatility

We know that volatile information exists in memory on a live system and that certain types of volatile information can be, well, more volatile than others. That is, some information on a live system has a much shorter shelf life than other information. For instance, network connections time out, sometimes within several minutes, if they aren't used. You can see this by browsing to a specific site or making some other network connection and viewing that connection via netstat.exe. Then shut down the client application you're using and the state of the network connection will change over time before it eventually disappears from the output of netstat.exe. The system time, however, changes much more quickly, while the contents of the clipboard will remain constant until either they are changed or power is removed from the system. Additionally, some processes, such as services (referred to as daemons in the UNIX realm) run for a long time, whereas other processes can be extremely short lived, performing their tasks quickly before disappearing from memory. This would indicate that we need to collect certain information first so that we can capture it before it changes, whereas other volatile data that happens to be more persistent can be collected later.

(Continues...)

---

Excerpted from Windows Forensic Analysis by Harlan Carvey Copyright © 2007 by Elsevier, Inc. . Excerpted by permission of Syngress. All rights reserved. No part of this excerpt may be reproduced or reprinted without permission in writing from the publisher.
Excerpts are provided by Dial-A-Book Inc. solely for the personal use of visitors to this web site.

---