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:
- If the compromised machine is using NTFS, search for files in alternate data streams (ADS), which are also called hidden named streams.
- Search for hidden files.
- Search for suspect regular files by their most recent modification time, most recent access time, and creation time.
- Obtain the access rights for files and registry keys.
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:\winnt\mylog.txt, you'd use the command
notepad.exe
C:\winnt\mylog.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.