UNIT-I

✓Initial Response and forensic duplication,

✓Initial Response & Volatile Data Collection from Windows
system.
✓Initial Response & Volatile Data Collection from Unix system.
1. Initial Response and forensic duplication:
INITIAL RESPONSE:
•One of the first steps of any preliminary investigation is to obtain enough
information to determine an appropriate response.
•The goal of an initial response is twofold: Confirm there is an incident, and
then retrieve the system’s volatile data that will no longer be there after you
power off the system.
• Initial response is an investigative as well as a technical process!
FORENSIC DUPLICATION
✓A forensic duplication is an accurate copy of data that is created with the goal
of being admissible as evidence in legal proceedings.

✓we also define forensic duplication as an image of every accessible bit from the
source medium.
2. Initial Response & Volatile Data Collection from Windows
system:
✓In this topic we are discussing what are steps to take when performing the
initial response to a Windows NT/2000/XP system.

1. 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.
2.1.2 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 listed in Table

✓. All of the tools listed in table are CUI or command-line tools.

2.1.3 Preparing the Toolkit:
We 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:

1. Label the response toolkit media

2. Check for dependencies with Filemon
3. Create a checksum for the response toolkit
4. Write-protect any toolkit floppies
5. 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.

2. 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
3. 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 shows the md5sum command line used to create the text file (named
commandsums.txt).
4. 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.
2. 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:
1. Save the data you retrieve on the hard drive of the target system.
2. Record the data you retrieve by hand in a notebook.
3.Save the data you retrieve onto the response floppy disk or other removable
media.
4.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.

✓Recording data by hand is not practical due to the volume of information.

✓Floppy drives are not a great choice because the data will not fit on the floppy.

✓Instead if you use removable USB drive , it provide fantastic storage capabilities
and can be used to store your toolkit as well as the collected data.

✓These devices have drivers built in, so they will work with any computer that
sports a USB port and Windows software

✓We choose netcat to transfer the information from the target system to a remote
forensic
2.2.1 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.
Fig illustrates the process of using netcat during initial response.

Figure: Using netcat during initial response to incidents

✓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.

✓But, 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.

✓You will know data transfer is complete when the floppy or CD-ROM stops
spinning on the target system or when the file size is no longer growing on the
forensic workstation.
2.2.2 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:

1. An attacker’s sniffer cannot compromise the information you obtain.

2.Encrypting the data nearly eliminates the risk of contamination or injection
of data.
3. OBTAINING VOLATILE DATA
✓If we 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 following 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
2.3.1 Organizing and Documenting Your Investigation:
✓You need to have a methodology that is both organized and documented.

✓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.

✓We recommend that you use a form to plan and document your response.

✓For our investigations, we record the start time of the command executed and the
command line entered.

✓We document whether we ran a trusted or untrusted binary. Then we generate an MD5
sum of the data obtained by each command and add any relevant comments.
Here is an example of such a form:
 2.4. Collecting Volatile Data
We have to 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.
1. Executing a Trusted Cmd.exe
✓ Investigators need to be careful of tripwires or booby traps that attackers put in place
to prevent incident response.

✓ The solution is to execute a trusted version of cmd.exe from your own toolkit.

✓ Figure 5-5 illustrates using the Start | Run command on a Windows system to open a
trusted cmd.exe on the floppy drive.

Figure: Running a trusted version of cmd.exe

2. 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.

Fig: Obtaining the system time and date

3. 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.

✓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
✓If several accounts can access the system via RAS(Remote Access Service), 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.
✓Notice the null session connection from a remote system in Figure.

Figure: Using PsLoggedOn to list users currently logged in to a system

4. 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:
5. 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. Figure 5-8 shows netstat being executed on an NT Server machine.

✓netstat will almost always show connections between applications on the localhost 127.0.0.1.
6. 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.

✓Figure 5-9 shows the syntax for Fport and the corresponding output.
✓If Fport reveals a rogue process listening for connections, and netstat shows current
connections to that process,

✓you may want to terminate the process to protect your system from potentially
malicious actions taken by unauthorized intruders.

✓When necessary, use the kill command to terminate rogue processes.

Note: Rogue.exe is not essential for the Windows OS and causes relatively few
problems. The rogue.exe file is located in a not unambiguous folder. The file size on
Windows is 0 bytes.
7. Listing All Running Processes
✓Before you power off a target system, it is important to record all of the
processes currently running on that system.
✓We get the information ,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.

✓You can use Mark Russinovich’s PsList utility to enumerate all running
processes on the target system.

✓Figure 5-11 shows an example of running PsList.

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
8. 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 policies 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.

1.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.
2. 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.

3. nbtstat:
✓This utility is used to access the remote NetBIOS name cache, listing the
recent NetBIOS connections for approximately the last ten minutes.
Figure 5-12 shows an example of using nbtstat to list current and recent
NetBIOS connections.
9. Recording the System Time and Date
✓Issue the date and time commands again (repeat step 2) to record the time and
date that you completed the live data collection.

✓This ensures that you have a record of when you were on the system, so that if
anything is changed on the system outside this timeframe, you will know that you
are not responsible for the alteration.

10. Documenting the Commands Used during Initial Response

✓Use the doskey /history command to display the command history of the
current command shell on a system (if the situation warrants).

✓We also use doskey /history to keeptrack of the commands executed on the
system during a response, as shown in Figure.
Figure: Using doskey to record the steps taken during incident response
3. Initial Response & Volatile Data Collection from Unix system:
✓The initial response to prospective incidents on Unix systems is similar to the
initial response for incidents on Windows systems.

✓Your goal is to obtain the volatile system data before forensic duplication. You
can expand the scope of your initial response to obtain log files, configuration
files, system files, and relevant files (such as hacker tools and suspicious
programs) to rapidly confirm whether or not an incident occurred.

✓One difference between working with Windows and Unix systems is the
difficulty of recovering deleted files on some Unix variants.

✓In the Windows environment ,When you execute a process, you cannot delete
the file corresponding to the running process from the hard drive.
However, the Unix operating system allows you to delete a program after it has been
executed—the process is running, yet the program’s file has been deleted from the hard drive.

1. CREATING A RESPONSE TOOLKIT

✓Preparing your trusted toolkit is more difficult and time-consuming ,because
practically every variant of Unix requires a unique toolkit.

✓Since many of the tools are not included with the standard release of all Unix
operating systems, you must compile the source code on your own.
✓For example, if the victim machine is a Sparc server running Solaris 2.8, you
need to compile your tools on a clean copy of Solaris 2.8 on a system with the same
architecture.

✓Many Unix versions are not backward or forward compatible. For example,
programs compiled to run on a Solaris 2.6 system may not work correctly on Solaris 2.7,
and vice versa.
✓All these issues increase the amount of resources and time required for creating your
Therefore, it is essential to create the response toolkits prior to an incident. But
You may not have the time to create one after an incident occurs.

✓Regardless of the type of incident, it is critical that you use trusted commands.

✓For responding to Unix systems, we maintain a number of CDs and floppy disks
with the following tools:
3.2 STORING INFORMATION OBTAINED DURING THE INITIAL RESPONSE
✓When you respond to an incident, you must choose where to store information retrieved
during the initial response.

✓You have the following storage options:

❑ Store the data on the local hard drive.
❑ Store the data to remote media such as floppy disks, USB drives, or tape drives.
❑ Record the information by hand.
❑Use netcat (or cryptcat) to transfer the retrieved data to a forensic workstation
over the network

✓Storing data on the local hard drive should be avoided whenever possible, because the data
you store on the local hard drive will overwrite deleted data that was in unallocated space
that may be of investigative and/or evidentiary value.

✓ Since only newer versions of Linux support USB drives, they are not as useful for data
collection by direct physical connection.
✓However, you can overcome this limitation by using netcat to transfer the data over the
network to a forensic workstation equipped with a USB drive or other adequate storage

✓We use netcat to transfer the information across the network, and “pipe” the netcat

stream through des to encrypt the transfer. The cryptcat command offers an encrypted
TCP channel in a single step.

✓You will also want to determine whether the target system must maintain network
connectivity or if you will pull the network cable to prevent users and attackers from
connecting to the system during your initial response.

✓When these issues have been resolved, you are prepared to respond at the console of the
target system.
4. Collecting the Data
At a minimum, you should collect the following information:
❑ 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 recent connections to the system
To collect the live data in this list, you can take these steps:
1. Execute a trusted shell.
2. Record the system time and date.
3. Determine who is logged on to the system.
4. Record modification, creation, and access times of all files.
5. Determine open ports.
6. List applications associated with open ports.
7. Determine the running processes.
8. List current and recent connections.
9. Record the system time.
10. Record the steps taken.
11. Record cryptographic checksums.
1. Executing a Trusted Shell
✓ When you respond to a target system running Unix, you will encounter one of two
scenarios:

1. The system is running in console mode.

2. The system is running X Windows, a GUI similar to the Windows desktop.
✓To avoid common X Windows-based vulnerabilities that allow the attacker to log
keystrokes, you should exit X Windows before you initiate your response.
✓If you are responding to a Linux system, you may be able to switch to another virtual
console by pressing ALT-F2.
✓Log on locally at the victim console to avoid generating network traffic, and be sure to log
on with root-level privileges. At this point, you need to mount your trusted toolkit and
respond with trusted tools.
✓The following is the command syntax to mount a floppy drive when responding to a Linux
system:

mount /dev/fd0 /mnt/floppy

✓This command mounts your trusted toolkit on the mount point /mnt/floppy. When you
change directories to /mnt/floppy, you will be able to access your trusted files
✓The first step in all response is to be certain you are executing a trusted command
shell.

✓The Unix shells can be trojaned by attackers to log all the commands executed or to
perform nefarious and evil operations invisible to the investigator.

✓Therefore, you will want to execute your own trusted shell (we use the Bourne
Again shell, called bash).

✓Once you have executed your trusted shell, set your PATH environment variable
equal to dot (.). This will decrease the chances of someone accidentally executing
untrusted commands that are in the target system’s PATH.
2. Recording the System Time and Date
✓The local date and time settings are important for later correlation of
time/date stamps, and they also show when you were on the system.

✓ To capture this information, use the date command:

[root@conan /root]# date

Tue Dec 17 16:12:43 UTC 2003

3. Determining Who Is Logged on to the System

✓Determining who is logged on is quite simple. Just execute the w (what)
command.

✓The w command displays the user IDs of logged-on users, what system
they logged on from, and what they are currently executing on the system.
✓The header line in the output indicates the current system time, how long the
system has been running, how many users are currently logged in, and the
system load averages for the past one, five, and fifteen minutes.
✓The USER field shows the username currently logged on to the system.
✓ The TTY field shows the control terminal assigned to the user’s session.
There are some important things to note about this column.

❑ A ttyn (where n is zero or a positive integer) signifies a logon at the

console (a user logging on to the system from the local console, or keyboard).
❑ A ptsn or ttypn may signify a connection over the network.

✓The FROM field contains the fully qualified domain name or numerical IP address
of the remote host. A hyphen (-) in this field corresponds to a local logon at console.

✓ The LOGIN@ field shows the local starting time of the connection.
✓ The IDLE field shows the length of time since the last process was run.

✓The JCPU field shows the time used by all processes attached to that console (tty)
or other connection (pts).
✓The PCPU field shows the processor time used by the current process under the
WHAT column.

✓ The WHAT column shows the process that the user is currently running.
✓In other words, if the user executed the command find / -name *.tgz, this
command will take quite a while to run. Thus, executing the w command will
show the syntax of the find command in the WHAT column
4. Recording File Modification, Access, and Inode Change Times

✓You will want to retrieve all the time/date stamps on the file system. As with Windows
systems, Unix systems have three time/date stamps to collect for each file and directory:
access time (atime), modification time (mtime), and the inode change time (ctime).

✓atime (access time) is the timestamp that indicates the time that a file has been accessed
✓mtime (modification time) indicates the time the contents of the file has been changed.
✓ctime (change time) is the timestamp of a file that indicates the time that it was changed

✓You can use a trusted ls command with the proper command-line arguments to obtain
these times for each file.
✓The following lines demonstrate how to obtain the time/date stamps and save the output on
a trusted floppy disk:

ls -alRu / > /floppy/atime

ls -alRc / > /floppy/ctime
ls -alR / > /floppy/mtime

✓The R option used in the ls command forces a recursive listing, which takes some time.
5. Determining Which Ports Are Open
✓The netstat command is king when it comes to enumerating the open ports on a Unix
system.

✓Use the netstat –an command to view all open ports.

✓The -n option tells netstat to not resolve hostnames, which reduces the impact on the
system and speeds the execution of the command.

✓The following is an excerpt from the output of netstat:

6. Listing Applications Associated with Open Ports
✓On Linux, the netstat command has a -p option that maps the name of the application and
its process ID (PID) to the open ports.

✓Here is an abbreviated example of the netstat -anp output (all numeric ports)
✓This output displays 7 open TCP sockets and 1 open UDP socket.

✓Line 9 indicates a raw socket is listening for ICMP(Internet Control Message

Protocol) , and

✓ line 10 reveals that the kernel is also listening for TCP packets.

✓If you examine line 2, you can see that the secure shell daemon, sshd, with a
PID of 395, is listening for connections on TCP port 22.

✓Lines 1, 3, 4, 5, 6, and 7 show that the inetd(Internet daemon), with a PID of 385,
is listening on TCP ports 143, 512, 513, 514, 23, and 21.

✓You now can distinguish which processes are responsible for opening the
specific Internet ports.
✓ Mapping an open port to the process listening on that port is a bit more
challenging on other flavors of Unix.

✓ So, Use list-of-open-files utility, which lists all running processes and the file
descriptors they have open.

✓ The lsof utility will show you all the regular files, directories, libraries, Unix
streams, and network files (such as NFS or Internet sockets) that are currently
opened and the corresponding process that opened them.

✓ To use lsof to list only the processes that have opened network sockets, use the
following command line:

lsof -i
7. Determining the Running Processes
✓It is critical to take a snapshot of all the running processes during the
initial response.
✓This can be accomplished by using the standard ps (process status)
command.

✓The output varies a bit among the different Unix flavors.

❑We use ps -eaf on Solaris systems, and
❑We use ps -aux on FreeBSD and Linux systems.

ps aux seems to conveniently list all processes and their status and resource usage
a = show processes for all users
u = display the process's user/owner
x = also show processes not attached to a terminal

The following illustrates the results of the ps command on a Linux system:

The following illustrates the results of the ps command on a Linux system:
✓Here, the average Unix system has many more processes running than
Windows servers. This makes it easier for attackers to hide rogue processes.

✓One of the most important fields in the ps command output is the START field,
which indicates when a process began.

✓This is extremely helpful when you isolate the time an attack occurred. You can
identify suspect processes merely by the time they were executed.
8. Listing Current and Recent Connections
✓The netstat command provides information about another aspect of live
response: current and recent connections.

9. Recording System Time

✓Use the date command again (repeat step 2) to record the current system
time.

✓The reason for another timestamp is so that you will know the exact time
window during which you manipulated the system. Thus, any changes that
take place outside this time window are not due to your investigation
10. Recording the Steps Taken
✓Finally, record all of the commands you have issued to the system.

✓There are several possibilities here: use script, history, or vi if you

performed your live response from the editor. Since you issued all commands
from a trusted shell, using the history command will record all of the
commands you’ve executed.

✓However, a better choice is the script command, which will record your
keystrokes and the output. If you choose to use the script command, you’ll
need to run this command before you perform the live response.

[root@conan /root]# script /mnt/floppy/command_log.txt

Script started, file is command_log.txt
11. Recording Cryptographic Checksums
✓Finally, record the cryptographic checksums of all recorded data.

✓ Simply run the md5sum program against all files In the data directory, as shown here:

[root@conan /root]# md5sum * > md5sums.txt