Computer security incidents (usually security breaches) are a fact of life that many systems administrators must deal with at some point. Whether threats originate from malicious intruders, self-propagating worms, or trusted insiders, the need to quickly assess and appropriately respond is vital. In addition, performing an in-depth analysis (i.e., computer forensics) of the compromised machine later is crucial. This series, which is broken into two parts, covers both types of analyses. Part 1 and Part 2 of "Building and Using an Incident Response Toolkit" discuss how to build and use an incident response toolkit so that you can quickly collect data about that incident. Then, in upcoming issues, Part 1 and Part 2 of "Performing Forensic Analyses" will discuss how to perform a thorough analysis of a compromised machine, with an emphasis on possibly bringing evidence to court.
Whether you're using an incident response tool or performing an in-depth analysis, you need to keep in mind two basic principles. First, if the incident ultimately results in criminal proceedings, demonstrating that you haven't changed the evidence in any way is important. Changing the system as little as possible and hashing acquired data is standard practice. In addition, you should document all your steps and preferably have at least one other set of eyes to vouch for the validity of your collected data. If you don't take these precautions, proving that the intruder caused the damage to the system is difficult.
Every file opened, process run, or segment of memory accessed changes the state of the machine and can impede your analysis. How to minimize change is a topic constantly under debate, and no single right answer exists. Based on the situation, the smartest move might be to immediately shut down the machine (i.e., a clean shutdown), literally pull the plug (i.e., a dirty shutdown), disconnect the machine from the network, or do nothing at all. In all cases, you lose some crucial information.
The best action is one that preserves the most information while minimizing risk. Typically, that action is to unplug the computer from the network, image the volatile memory, then shut down the machine. Your organization might have guidelines specifying what to do. The US Department of Defense (DoD) guidelines, for example, tell you to immediately pull the plug on the machine. For the purpose of this article, I'm going to discuss how to perform analyses on a live machine.
Second, you must never trust the machine. If an intruder has broken in and achieved Administrator rights, there's no limit to what might be booby-trapped or corrupted.
Because you can't trust a compromised machine, you should prepare an incident response toolkit that contains trusted copies of necessary analysis tools. You need one set of tools, which I cover in this article, to quickly analyze the compromised machine. You need a second set of tools, which I'll cover in "Building and Using an Incident Response Toolkit, Part 2," to quickly analyze the file system behind the compromised machine. Creating this toolkit before a problem occurs will save you a lot of time and headaches later.
Assemble the Toolkit
The incident response toolkit contains numerous tools from many sources. All the tools are either free downloads or come prepackaged with the Windows OS. The entire collection of tools will easily fit on a CD-ROM (business card or regular sized) or other removable disk. (A regular 3.5" disk likely won't have enough room, but if you do burn these files to a 3.5" disk, be sure that you set the write-protect setting on your medium.) You should place all the tools in the CD-ROM's root directory. To assemble the toolkit, follow these steps:
1. Dig out a trusted version of Windows. Many of the tools you'll need come prepackaged with Windows, but having separate copies of these tools is essential to protect against corrupted binaries. Therefore, dig out your installation media (or access a well-trusted system), go to the %windowsroot%\system32 directory, and copy the following binaries: arp.exe, at.exe, cmd.exe, dir.exe, doskey.exe, edit.exe, find.exe, findstr.exe, hostname.exe, ipconfig.exe, nbtstat.exe, net.exe, netstat.exe, nslookup.exe, notepad.exe, ping.exe, regedt32.exe, route.exe, share.exe, and tracert.exe.
All these tools are standard diagnostic tools on a Windows machine. I won't cover them all in this article, but because they're standard Windows tools, you're likely already familiar with them. Their presence in your toolkit ensures that you can collect accurate data, whether that involves following the procedures I outline here, looking through the registry, or investigating DNS names.