Data Collection

CREATING A RESPONSE TOOLKIT

• For an initial response, you need to plan your approach to obtain all the information without
affecting any potential evidence. Because you will be issuing commands with administrator
rights on the victim system, you need to be particularly careful not to destroy or alter the
evidence. The best way to meet this goal is to prepare a complete response toolkit.
• Do not underestimate the importance of the monotonous and laborious step of creating a
response toolkit. By spending the time to collect the trusted files and burn them onto a CD-
ROM (or store them on floppies), you are much better equipped to respond quickly,
professionally, and successfully. A live investigation is not the time to create or test your
toolkit for the first time!
Gathering the Tools
In all incident responses, regardless of the type of incident, it is critical to use trusted
commands. For responding to Windows, we maintain a CD or two floppy disks that contain a
minimum of the tools
• In Windows, there are two types of applications: those based on a graphical user
in_x0002_terface (GUI) and those based on a console user interface (CUI). Since
GUI programs cre_x0002_ate windows, have pull-down menus, and generally do
“behind-the-scenes” interaction,
• we advise against using them for an investigation. All of the tools listed in Table 5-
1 are CUI or command-line tools
• Preparing the Toolkit
• You need to ensure that your toolkit will function exactly as intended and not
alter the
• target system. We take several steps to prepare our toolkits for initial response:
• ▼ Label the response toolkit media A first step in evidence collection is to
document the collection itself. Your response toolkit CD-ROM or floppy disks
should be labeled to identify this part of your investigation. For example, for our
response floppies and CDs, we make a specialized label that has the following
information on it:
• ■Case number
• ■ Time and date
• ■ Name of the investigator who created the response media
• ■ Name of the investigator using the response media
• ■ Whether or not the response media (usually a floppy disk) contains
• output files or evidence from the victim system
• Check for dependencies with Filemon It is important to determine which
• DLLs and files your response tools depend on. We use Filemon to determine
• all the files accessed and affected by each of the utilities in our toolkit. It is
• good to know which tools change access times on files on the target system.
• When we can, we avoid using “loud” tools that alter a lot of the target
system.
• Create a checksum for the response toolkit One of the files on our response
kit floppy (and CD and USB drive) is a text file with a checksum of all the
commands on it. Figure 5-1 shows the md5sum command line used to create
the text file (named commandsums.txt).
• Write-protect any toolkit floppies If you use floppy disks, be sure to write
protect the floppy after it is created. If you store evidentiary files on the
response floppy during an incident, you need to write-protect it after you
accumulate data and begin the chain of custody. The chain of custody tags
should be filled out for each response floppy or CD, whether or not it
contains evidence files.
• STORING INFORMATION OBTAINED DURING THE INITIAL RESPONSE
• During your initial response, you will gather a lot of information from the live
system.
• We use the term live to refer to a system that is relevant to an investigation, whether
it is the attacking system or the victim, and is currently powered on. Think of it as
the crime scene before photos are taken and bodies are removed. You are operating
in an untrusted environment, where the unexpected should be anticipated.
• You have four options when retrieving information from a live system:
• ■ Save the data you retrieve on the hard drive of the target system.
• ■ Record the data you retrieve by hand in a notebook.
• ■ Save the data you retrieve onto the response floppy disk or other
• removable media.
• ■ Save the data you retrieve on a remote “forensic system” using netcat or cryptcat.
• Saving data to the hard drive is undesirable because it modifies the system.
Record_x0002_ing data by hand is not practical due to the volume of information.
Floppy drives are usu_x0002_ally not a great choice because the data will not fit on
the floppy. Other removable, writable media with a larger capacity than a floppy
would be ideal, but the victim systemmay not have a drive for such media
• Despite the proliferation of USB ports, you still need to be able to save data across a
network. We often choose netcat to transfer the information from the target system to
a remote forensic workstation.
• Transferring Data with netcat
• netcat is a freely available tool that creates a channel of communication between
hosts.
• We use it during initial response to create a reliable, TCP connection between the
target
• system and the forensic workstation used for analysis. All that you need to use netcat
• is an IP address on the target network and a laptop system with enough storage space
to retain the information you gather.
• Using netcat allows you to transfer all the relevant system information and
files you require to confirm whether or not an incident occurred. This
technique of information gathering promotes two sound practices:
• ▲It lets you get on and off the target system quickly.
• ▲ It allows you to perform an offline review of the information attained.
• To use netcat, you initiate a netcat listener on the forensic workstation and
redirect all incoming data to a file.
• Figure 5-3 illustrates the forensic workstation listening
• for incoming connections on port 2222. It will write the information received
on that port to a file called pslist.
• On the target system, netcat is used to funnel the output to your response
commands to the forensic workstation.
• The command line in Figure 5-4 runs pslist, sending the output of the
command to the forensic workstation, at IP address 192.168.0.20.
• When transferring files in this manner, netcat does not know when the data
transfer is complete. You will need to break the connection after the data
transfer is complete by pressing CTRL-C on the forensic workstation.
Figure 5-2. Using netcat during initial response to incidents
Figure 5-3. Setting up the netcat listener on the forensic workstation
• Encrypting Data with cryptcat
• The drawback of transferring data across a network is that the data may be
visible to network eavesdroppers. Consider encrypting the traffic using
cryptcat. An alternative is to use a crossover cable to directly connect the
victim system and the forensics workstation.
• cryptcat has the same syntax and functions as the netcat command, but the
data transferred is encrypted. There are two compelling arguments for
encrypting your traffic when sending files from a target system:
• ▼ An attacker’s sniffer cannot compromise the information you obtain.
• ▲ Encrypting the data nearly eliminates the risk of contamination or
injection of data.
Figure 5-4. Sending the output of pslist to the forensic workstation
• OBTAINING VOLATILE DATA
• Now that you have a forensic toolkit and a methodology, you need to
determine exactly which data to collect. At this point, you want to obtain the
volatile data from the Windows NT/2000 system prior to turning off that
system. At a minimum, we collect the fol_x0002_lowing volatile data prior to
forensic duplication:
• ▼ System date and time
• ■ A list of the users who are currently logged on
• ■ Time/date stamps for the entire file system
• ■ A list of currently running processes
• ■ A list of currently open sockets
• ■ The applications listening on open sockets
• ▲ A list of the systems that have current or had recent connections to the
system
• If you know that your investigation is unlikely to require forensic duplication,
you may want to collect more data. For example, you may want to dump
RAM, obtain some information from the Registry, or perform other actions
on the target system, pending the totality of the circumstances.
• Organizing and Documenting Your Investigation
• It’s one thing to have the technical skills required for proper incident
response; it is quite another to implement a complete, unbiased,
professional process. You need to have a methodology that is both organized
and documented.
• There are two reasons for diligently documenting your actions when
responding at the console of a victim system:
• ▼ To gather information that may become evidence against an individual
• ▲ To protect your own organization
• Before you begin collecting data, you should have an MD5 sum file with the
checksums of each tool you will use. If you need to use untrusted binaries
during a response, be sure to record the full pathnames of those binaries.
• Collecting Volatile Data
• Now that you know what to collect and how to document your response, you
are ready to retrieve the volatile data. We have created a “top-ten” list of the
steps to use for data collection:
• 1. Execute a trusted cmd.exe.
• 2. Record the system time and date.
• 3. Determine who is logged in to the system (and remote-access users,
• if applicable).
• 4. Record modification, creation, and access times of all files.
• 5. Determine open ports.
• 6. List applications associated with open ports.
• 7. List all running processes.
• 8. List current and recent connections.
• 9. Record the system time and date.
• 10. Document the commands used during initial response.
• The following sections describe how to perform each of these steps.
Remember that you may need to collect more data than what we show in
this list.
• Recording the System Time and Date
• After executing the trusted command shell, it is a good idea to capture the
local system date and time settings. This is important to correlate the system
logs, as well as to mark the times at which you performed your response. The
time and date commands are a part of the
• cmd.exe application. Figure 5-6 illustrates the execution of the date
command, redirecting the output to a file called date.txt on the floppy drive.
The second command in the figure uses the append operator (>>) to add the
output to the time command to the date.txt file.
• When you execute the date and time commands, you must press the ENTER key to indicate that you do not
want to change the settings.
• Determining Who Is Logged in to the System and Remote-Access Users
• The next step is to determine which user accounts have active connections to the system.
• You want to know whose service you may be interrupting should you decide to terminate the network
connections to the victim system. Mark Russinovich created PsLoggedOn, a utility that shows all users
connected locally and remotely
• Notice the null session connection from a remote system in Figure 5-7.
• Figure 5-7. Using PsLoggedOn to list users currently logged in to a system
• If you are responding to a system that offers remote access via modem lines,
you need to determine which user accounts have remote-access privileges on
the target system. If none do, you know that the modem is for outgoing
connections (or at least not Remote Access Service, or RAS). If several
accounts can access the system via RAS, you need to decide whether or not
you want to pull the telephone lines from the system during the response
• You may not want to allow any access to the target system while you are
responding. The command-line tool to enumerate the users who can log in to
a system via RAS is called rasusers.
• Recording Modification, Creation, and Access Times of All Files
• Use the dir command to get a directory listing of all the files on the target system,
recording their size, access, modification, and creation times. This is often the
most important and critical step to incident response!
• If you can identify the relevant timeframe when an incident occurred, the
time/date stamps become the evidence of which files an attacker touched,
uploaded, downloaded, and executed. Windows performs this task extremely
quickly. Here are examples of using dir to obtain access (a), modification (w), and
creation (c) times:
• dir /t:a /a /s /o:d c:\ Provides a recursive directory listing of all the
• access times on the C: drive
• dir /t:w /a /s /o:d d:\ Provides a recursive directory listing of all the
• modification times on the D: drive
• dir /t:c /a /s /o:d e:\ Provides a recursive directory listing of all the
• creation times on the E: drive
• Determining Open Ports
• To determine which ports are open, use netstat, a standard Windows command that
enumerates all listening ports and all current connections to those ports. netstat is useful for
recording volatile data such as current connections and connections that have just terminated.

• Listing Applications Associated with Open Ports

• It is helpful to know which services listen on which specific ports. Otherwise, you will not be
able to discern rogue processes from proper mission-critical processes. Foundstone supplies a
free tool called Fport, which enumerates listening ports for all processes on a Windows
NT/2000 system.

• Listing All Running Processes

• Before you power off a target system, it is important to record all of the processes
cur_x0002_rently running on that system. You cannot obtain this information if you simply
unplug the power cord! When a process is executed on a Windows system, a kernel object and
an address space that contains the executable code are created. The kernel object created is
used by the operating system to manage the process and maintain statistical information about
the process.
• If you cannot tell the difference between Windows critical processes and
rogue processes, PsList will not be of much use to you. You need to recognize
normal processes so that you can identify those processes that may be out of
place or nefarious. For example, if PsList reveals that the EVENTVWR process is
running, this suggests that someone is looking at the logs. If you see USRMGR,
you might suspect that someone is trying to change the audit policies, add or
delete a user account, or change user account data (passwords).
• Table 5-2 lists some common NT system processes.
• Listing Current and Recent Connections
• netstat, arp, and nbtstat are useful utilities for determining who is connected
or has recently connected to a system. Many Windows NT/2000 workstations
have audit poli_x0002_cies that do not log successful or failed logons.
Therefore, these three utilities may be your only way to identify a remote
system connecting to a workstation.
• netstat Many computer security specialists use netstat to list the open ports
on a system. Since Fport lists the open ports and the application listening on
each port, we use netstat to determine current connections and the remote IP
addresses of those current connections, and to view recent connections.
• arp This utility is used to access the ARP cache, which maps the IP address to
the physical MAC address for the systems that the target system has been
communicating with in the last minute.