There is an old adage: "you've got to use the right tool for the right job." Responders must have the right tools in anticipation of the most common set of circumstances, so they are not looking around for their tools when precious time is wasting and profitability is declining.
Tools in the Tool Bag
In Windows operating system environment, there are two basic types of utility applications, those based on a Graphical User Interface (GUI) and those that are based on command line interface (CLI).
Following is a list of tools that are available at www.sysinternals.com:
-
PsTools v1.56: The PsTools suite includes command-line utilities for listing the processes running on local or remote computers, running processes remotely, rebooting computers, dumping event logs, and more.
-
Tokenmon v1.01: View security-related activity, including logon, logoff, privilege usage, and impersonation with this monitoring tool.
-
Filemon v4.34: This monitoring tool lets you see all file system activity in realtime. It works on all versions of WinNT/2K, Windows 9x/Me, Windows XP 64-bit Edition, and Linux.
-
PSLoggedon: An applet that displays both the locally logged on users and users logged on via resources for either the local computer or a remote one.
-
TCPView v2.22: See all open TCP and UDP endpoints on Windows NT, 2000, and XP. TCPView displays the name of the process that owns each endpoint. Full source to the command-line version of this tool, netstat, is included.
-
NTFSDOS Professional v4.0: Full read/write access to NTFS drives from DOS.
If investigators are going to use floppy disks or CDs, they must be rendered write-protected after writing.
There are several schools of thought concerning the use of tools in responding to critical incidents. Some responders have experienced vigorous cross examinations at the hands of knowledgeable attorneys where they did not keep copies of their programs and tools so these they could be examined by the opposing side's experts. Because this seems to be a current trend in qualifying witnesses, you must be sensitive to this tactic and ensure the versions of your tools are logged as part of your investigation. Investigators should maintain versions of all relevant tools so these tools can be produced when necessary.
Storing the Data
During the course of the response, there will be a lot of information gathered from the system. Consider the area where the incident has occurred as a crime scene because if investigators take the most restrictive posture when they respond, then should the matter proceed to court, their evidence should be introduced.
All media intended to be used to duplicate evidence must be cleansed using software intended for that exact purpose. This cleansing process includes all blank CDs, zip disks, jazz disks, tapes, floppies, hard drives, etc.
Experience Note | Arriving on the scene is not the time to begin your preparations. Do you really want to take the stand and testify to your lack of professional diligence? |
To Turn Off or not to Turn Off
If responders arrive at the scene before the system has been turned off, they might consider efforts to collect valuable evidence that could be lost otherwise. It is a matter of priorities. They should be included in the decision to be made by senior managers as part of the response posture. The balance is this one, if turning off the system will stop the progress of any further damage and whether turning off the system will likely result in the loss of evidence. Response postures should be certain to error on the side of caution and turn off relevant systems containing spreading damage. Following the firefighter model, it is a matter of business sense to contain the damage before worrying about evidence.
If the decision to keep the victim-system online, here is a list of items that should be considered as volatile and might disappear when the system is turned off:
-
List of users logged onto the system
-
List of currently running processes
-
List of currently open ports
-
List of currently listening services on their respective ports
-
List of systems currently connected to the target system
When investigators approach the target system, they should have a plan outlining their general activities. Before anything actually takes place, an activity log should be initiated and maintained documenting all steps and their results. Log entries should include any and all tools deployed, system and application commands, who performed the action, the date/time/place, etc.
Essentially there are two reasons for maintaining an activity log, to gather information that will permit the reconstruction of the response-activities at a later date and protect the organization by demonstrating the responders exercised professional due diligence. More than once, logs have effectively answered legal and policy-compliance challenges.
System Users
If the response posture requires that an investigation proceed while the system is still active and the attacker is online, using the program, Psloggedon, written by Mark Russinovich, www.sysinternals.com, shows all users connected locally and remotely. If the system offers dial-up remote access, the investigators should determine the user accounts having remote-access privileges on the target system at the time of the incident. Depending on the number of logged on accounts, investigators may wish to remove the telephone lines, disconnecting online activity.
There is a command line tool, as part of the Remote Access Service, RAS, called rasusers that can be used to determine the users that have remote access to the target system. Rasusers is available at http://wettberg.home.texas.net/rasusers.htm.
Open Ports and Listening Services
The next step may provide one of the most significant steps in the real-time investigation. Determine what are the open ports and listening services. A handy tool, fport, is available from the Foundstone Web site at www.foundstone.com. This tool will show all listening processes.
The display format for fport is:
-
Process identification
-
Process name
-
Port, Protocol
-
Path