Preface

As long as networks of Microsoft Windows systems are managed, administered, and used by people, security incidents will occur. Regardless of whether we're talking about hundreds of corporate Windows workstations and servers or home user systems running Windows XP on broadband connections to the Internet, Windows systems will be attacked, compromised, and used for malicious purposes. This is not to say that only Windows systems will be attacked; rather, Windows systems are highly pervasive throughout the entire computing infrastructure, from home and school systems to high-end e-commerce sites. In contrast to this pervasiveness, information regarding conducting effective incident response and forensic audit activities on Windows systems is limited, to say the least. Attacks may come from insiders who have legitimate physical access to systems and are authorized to use them or from faceless individuals hiding in the shapeless ether of the Internet. Knowing this, anyone who manages or administers Windows systems (including the home user) needs to know how to react when he suspects that an incident has occurred.

When it comes to investigating and resolving computer security incidents, Windows systems lag well behind Linux and *nix systems. This gap can be attributed to a variety of reasons. One reason is a lack of detailed technical knowledge regarding Windows systems themselves on the part of administrators. This lack of understanding may be due at least in part to Microsoft's use of graphical user interfaces (GUIs) to control everything from the installation process to all aspects of system administration. Attackers and malicious users take steps to ensure that their activities remain hidden from view, particularly from the system's GUI tools such as the Event Viewer and the Task Manager. For example, enabling an audit policy requires that the system administrator navigate through multiple layers of the GUI, while an attacker can easily disable (and then reenable, if necessary) that audit policy with a single command line tool (which, incidentally, is provided for free from Microsoft).

Other reasons for the “incident response gap” include a lack of understanding regarding how to use available native and third-party tools to retrieve data and how to interpret the data that is collected from potentially infected or compromised systems. Many useful and powerful tools that mirror the functionality used on Linux systems are not available through either the Microsoft operating system distributions or the Resource Kits. Sites that make these tools available are scattered across the Internet, with no central location cataloguing them. This book was written to aid anyone investigating incidents that occur on Windows systems by providing information regarding the tools and techniques used to respond to incidents and conduct forensic audits.

This book arose out of a need that I, and I am sure others, have seen in the Microsoft Windows system administration community. Microsoft's network operating systems, beginning with Windows NT, are designed to be easy to use and manage. These systems come with some very powerful tools. As useful as these tools are to the administrator, they are also very useful to an attacker or to a malicious user. Most system administrators and owners spend their time dealing with Windows operating systems through the GUI, and in doing so, miss many of the important aspects of the operating system that go on “under the hood.” For example, the Task Manager does not show the complete path to the executable image for each process, nor does it display the command line used to launch each process. This information is available using third-party tools, which most folks who work with Windows systems may not be familiar with. Therefore, it may be relatively simple to hide an errant process, such as a network backdoor, by renaming the file “svchost.exe” or something similarly innocuous.

Several years ago, I developed a hands-on course for teaching system administrators how to respond to security incidents on Windows 2000 systems. While teaching the course to system administrators at various organizations, I saw the same things that I saw on listservs and on forums on the Internet. During the first break on the first day of the course, I would go around the room and “infect” all of the systems with a “Trojan.” This “Trojan” was netcat, renamed to “inetinfo.exe,” listening on port 80. When the attendees returned to the room, I'd tell them that I “infected” their systems and challenged them to find it. The purpose of this exercise was not to find out who could find the “Trojan” first but to look at the steps that the attendees would go through in their incident response activities, to look at their “methodology.” Invariably, every attendee would examine the contents of the Event Log, comb through the Task Manager, and maybe run netstat –an from a command prompt. All of the systems were connected to the Internet, and the only instructions I would give to the class was that they could not use any of the tools from the course CD that I'd put together. As the course progressed through the rest of the two days, the attendees became familiar with the tools and techniques they could use to retrieve valuable data about a system, as well as how to interpret that data.

I've assembled a good deal of unique content for this book, information that I've developed because I haven't been able to locate it any place else and therefore had to do my own research. For example, when I first began researching NTFS alternate data streams, there wasn't much information available. Over time, research has revealed additional information, which is included in this book. I've included tools that I've developed (written in Perl) and information, results, and insights from my own research. This book also includes information from a variety of sources put together in a single location so that it can be easily referenced.

Unlike other books about incident response, this book is specific to Windows systems. Other books on the subject will present a great deal of information regarding Linux and Unix systems, and in some cases, leave it up to the reader to extrapolate the information to Windows. All of the tools and techniques presented in this book are specific to Windows (NT, 2000, XP, and 2003) systems.

The book is organized so that the reader progresses through an understanding of incidents, what they are and how they can (and do) occur. From there, the reader is guided through developing an understanding of what is required to prevent incidents and how to prepare for them, and then where to look for data and how to analyze that data, should an incident occur. Data hiding and tools used in incident response and live forensic audits are covered at great length, and all of the information presented is specific to Windows operating systems, file systems (i.e., NTFS), and applications (i.e., MS Word, etc.). This information is presented in a progression, each chapter taking the content of the previous chapter further. However, each chapter can also stand on its own, as a reference that the reader can return to time and time again.

The main premise of this book is really very simple. When incidents occur, an entire spectrum of incident response activities can be performed. The lower end of the spectrum involves...well...nothing. No activity. Basically, the incident goes completely unrecognized or is simply ignored. The opposite end of the spectrum consists of those activities that purists think of when they hear the word “forensics”: the system is shut down in a forensically sound manner and a bit-level image of the drive is made. All investigative activities are then conducted against that copy. This is usually accompanied by law enforcement involvement and may even lead to prosecution. However, many organizations do not wish to involve law enforcement when an incident occurs and generally conduct non-litigious investigations because they just want to get systems back online and in use. In other cases, potentially compromised systems may be part of an e-commerce infrastructure, in which downtime is measured in hundreds of dollars per minute. In such cases, an investigation will occur, but it will not involve law enforcement or legal prosecution, as the goal is determining what, if anything, happened. These steps may be required to gather information and facts in order to justify further action, such as taking the system down.

In addition, a great deal of extremely valuable information regarding the state of the system is lost when the system is shut down. This information is referred to as “volatile” information, and it includes such things as process information, network connections, clipboard contents, etc. This information can be retrieved, parsed, and analyzed in order to determine first whether an incident has even occurred, and then the extent of the incident. In some cases, enough information may have been collected to show that the incident is manageable, and the system does not have to be taken out of service to be “cleaned.” More importantly, the investigator will want to understand how the system was infected or compromised so that shortfalls in security policies can be rectified and other systems protected.

The Perl programming language is used to programmatically demonstrate many of the concepts addressed throughout the book. The underlying premise of the book is to get the reader “under the hood” within the Windows system, that is, to show the reader how to move beyond the simple GUI tools provided with the operating system in order to collect information about the state of the system. Many third-party tools are discussed, and several Perl scripts are provided in order to support this premise. Perl scripts are also used in this book to provide for customization and automation. By customization, we mean that Perl is used to correlate and “massage” the output of various third-party tools in order to present a more complete picture of the data. By automation, we mean that Perl is used in this book to implement a methodology so that the investigator does not have to perform the steps by hand, thereby avoiding mistakes and making the overall process more efficient.

This book guides the reader through information, tools, and techniques that are required to conduct incident response and live forensic audit activities. By providing the necessary background for understanding how incidents occur and how data can be hidden on compromised systems, the reader will have a better understanding of the “why's” and “how's” of incident response and forensic audit activities.