Building and Using an Incident Response Toolkit, Part 2

In today's corporate environment, computer security incidents are commonplace, and quickly and appropriately responding to a security incident is vital. In "Building and Using an Incident Response Toolkit, Part 1," April 2004, InstantDoc ID 41900, I showed you how to build an incident response toolkit and how to use it to collect basic data from a compromised machine. In this article, I show you how to use the toolkit to quickly collect data about the compromised machine's file system.

Gathering File-System Data
At this point, you're ready to use the incident response toolkit to gather information about the file system. Ideally, you should duplicate the compromised machine's hard disk, hash the hard disk's contents, analyze the contents at a different workstation, then hash the contents again after getting whatever information is possible. Alternatively, you could use an IDE or SCSI write blocker on the compromised machine. (A write blocker is a device that lets you use your computer to access and investigate the compromised hard disk but prevents your computer from writing to that disk.) However, duplication or a write blocker might not be viable because of time and budget constraints. So, instead, I cover the toolkit utilities that you can use on a live system for a quick-and-dirty analysis. The utilities make their best effort to avoid writing to the compromised hard disk, but the risk of doing so is still present, as you'll later see.

You can gather data about the compromised machine's file system in four steps:

When you perform these steps, you should run the utilities from your toolkit CD-ROM, as you did in Part 1. You should also continue to store the utilities' output on a secure medium. Once again, for the sake of brevity, most of the commands in the following steps don't include the code that writes the output to the secure medium. When you enter these commands in the command-shell window (cmd.exe), you must include this code.

Step 1: Search for ADS Files
NTFS supports multiple data streams in files. The data stream with which most people are familiar is called the visible unnamed stream. You can, however, create hidden named streams. You can hide many types of files—including executables that contain viruses or worms—in the hidden named streams in files or directories. No matter the size of the ADS file, it doesn't show up in a directory listing. For example, a 1-byte text file can have a hidden named stream that contains a 10MB ADS file—and that ADS file doesn't appear in Windows Explorer or in a Dir command's output. If you'd like more information about hidden named streams, check out "FAQ: Alternate Data Streams in NTFS" at http://www.heysoft.de/Frames/f_faq_ads_en.htm or "The Dark Side of NTFS (Microsoft's Scarlet Letter)" at http://patriot.net/~carvdawg/docs/dark_side.html.

If the compromised machine is using NTFS, you need to search for ADS files. Although Microsoft doesn't have any native software for finding ADS files, you can use Frank Heyne Software's LADS or Foundstone's SFind, which is part of its Forensic Toolkit. I've found SFind to be more accurate than LADS, but the general consensus is the reverse. Cautious administrators might want to run both. The command for running LADS is

lads.exe C: /s

The /s switch lets you recursively search all subdirectories. If you don't want to search the subdirectories, you can leave out the /s switch. The command for running SFind is

sfind.exe C:

SFind recursively searches all subdirectories by default. If you don't want to search the subdirectories, you can include the /ns switch.

If you find an ADS text file, you can view that file in Notepad. Use a command that follows the syntax

notepad.exe VisFile:ADSFile

where VisFile is the full pathname of the file that contains the hidden named stream and ADSFile is the filename of the ADS file. For example, if SFind discovers an ADS file called gotchya.txt in a hidden named stream in the file C:winntmylog.txt, you'd use the command

notepad.exeC:winntmylog.txt:gotchya.txt

(Although this command appears on two lines here, you'd enter it on one line in cmd.exe. The same holds true for the other multiline commands in this article.) Besides viewing an ADS file, you can copy that file to a visible file. For example, to copy the gotchya.txt file into a visible file on a USB disk in the J drive, you'd use the command

more  J:gotchya.txt

You must be careful when copying the ADS file to a visible unnamed stream. For example, if you forget to add J: to the second instance of gotchya.txt in the command just given, you'd be writing that ADS file to a visible unnamed stream on the compromised hard disk—a faux pas because you should avoid writing to that disk.

Step 2: Search for Hidden Files
No matter whether the file system is NTFS, FAT32, or FAT, you need to search for hidden files and determine the most recent access time for those files. Unlike ADS files, hidden files are marked as such in the file system and aren't hidden in the same way as ADS files are. To search the file system for hidden files, you can use the Forensic Toolkit's HFind utility. Run the command

hfind.exe C:

To determine the most recent access time for the hidden files that HFind discovers, you can use the Forensic Toolkit's FileStat tool. FileStat provides a complete list of the file and security attributes for the file you specify. The command syntax is

filestat.exe HidFile

where HidFile is the name of the hidden file for which you want to list the attributes. Knowing the most recent access time can help you pinpoint the source and damage of the intrusion.

Step 3: Search for Suspect Regular Files
You can further analyze the compromised file system by looking at the most recent modification time, most recent access time, and creation time of its regular files. Arne Vidstrom's MACMatch is an extraordinarily useful tool that lets you search for files by their most recent modification time, most recent access time, or creation time within a certain time frame. For example, if you know approximately when a security incident occurred because of the logs or other evidence you garnered, you can list all the files that were created during that time. Suppose you know that the security incident occurred between 2:00 p.m. on January 6, 2004, and 2:45 a.m. on January 7, 2004. You can run the command

macmatch C: -c   2004-01-06:14.00   2004-01-07:02.45

to obtain a list of all files created during that time period. The -c switch tells the utility to look at the creation time. The other two switches you can use are the -m switch, which tells the utility to look for the most recent modification time, and the -a switch, which tells the utility to look for the most recent access time. Reviewing the files that have changed or been accessed (i.e., read) in a time period will undoubtedly take longer but might be valuable for diagnosing how the security incident occurred.

Step 4: Obtain Access Rights
Obtaining the access rights for files and registry keys is possible with Sysinternals' AccessEnum tool. AccessEnum lists the Read, Write, and Deny access rights for the files contained in the directory or registry key you specify. Double-clicking the accessenum.exe file launches the GUI, which Figure 1 shows.

Sorting through the returned data can be tedious. Fortunately, you can export the data in a tab-delimited format for easy importation into a spreadsheet. You should look for non-administrative users with Read or Write access to system-critical files. You should also look for nonauthorized users who have access to data that's crucial to your organization. In the latter case, you need to be familiar with your access policies.

After you complete these four steps, you should create a list of all the commands you've run as well as create a hash for each of the output files you've created, following the instructions I gave in Part 1. Remember to store these hashes in a separate file. In addition, you need to print a copy of the file so that you can later verify that the evidence you collected wasn't tampered with.

You've now collected a wealth of data about the compromised machine and its file system. You should have enough information to make a decision about the computer's status and understand how to fix the problems you found. If you suspect that the analysis hasn't caught a problem or if you're dealing with a different type of security incident (e.g., a suspected insider as opposed to an outside intruder wreaking havoc), you'll want to read my next two-part series about this subject, which will show you how to perform a more detailed forensic examination of the compromised machine.

Careful preparation is key to responding to security incidents. Building the toolkit, testing the tools, and being familiar with the usual attributes of your systems are essential. Correct usage of the tools will help you quickly pinpoint the location of the intrusion and let you return to business as usual much sooner.