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.