| Windows Live Response for Collecting and Analyzing Forensically Sound Evidence * By Richard Bejtlich, Keith Jones, Curtis W. Rose * Nov 11, 2005 * Sample Chapter is provided courtesy of Addison Wesley Professional |
Sometimes your victim cannot afford to remove the system or the only evidence of
the incident may currently be in memory. Either way, a standard forensic
duplication is impossible. This chapter will address a technique for collecting and
analyzing forensically sound evidence from what is known as the Live Incident
Response Process.
the incident may currently be in memory. Either way, a standard forensic
duplication is impossible. This chapter will address a technique for collecting and
analyzing forensically sound evidence from what is known as the Live Incident
Response Process.
When a Microsoft Windows machine is involved in an incident, we have several choices of how to proceed in our investigation.
The overall scenario usually dictates the next steps an investigator takes. Sometimes your victim cannot afford to remove the
system from the network because a proper backup server cannot be swapped in its place. Therefore, a traditional forensic
duplication cannot be acquired. Other times, the data currently in memory may be the only evidence of the incident. This
chapter will address a technique for collecting and analyzing forensically sound evidence from what is known as the Live
Incident Response Process.
In short, a live response collects all of the relevant data from the system that will be used to confirm whether an incident
occurred. The data collected during a live response consists of two main subsets: volatile and nonvolatile data. The volatile
data is information we would lose if we walked up to a machine and yanked out the power cord. This data would not be
present if we were to rely on the traditional analysis methods of forensic duplications. A live response process contains
information such as the current network connections, running processes, and open files. On the other hand, the nonvolatile
data we collect during the live response is information that would be "nice to have." We would collect non-volatile data such
as the system event logs in an easily readable format, for instance, instead of the raw binary files in which Microsoft Windows
saves them. Of course, this data would exist in a forensic duplication, but it would be more difficult to output it in a nice format
after the machine has been powered off.
The live response data is collected by running a series of commands. Each command produces data that under normal
circumstances would be sent to the console. Because we must save the data for further analysis, we want to transmit the
data to our forensic workstation (a machine that the forensic investigator considers trusted) instead of the local victim's hard
drive. If we were to save the data locally to the victim's hard drive, there would be a significant chance that we would be
overwriting evidence if we chose to acquire a forensic duplication at a later date. Therefore, that effect is undesirable.
There are two main ways that we can transmit the data to the forensic workstation. The first way is to use the "swiss army
knife" of network administrators called netcat. netcat simply creates TCP channels. netcat can be executed in a listening
mode, like a telnet server; or in a connection mode, like the telnet client. We can start a netcat server on our forensic
workstation with the following command:
nc –v –l –p 2222 > command.txt
The -v switch places netcat in verbose mode. The -l switch places netcat in listening mode (like a telnet server). The -p switch
tells netcat on which TCP port to listen for data. By using this command, any data sent to TCP port 2,222 on our forensic
workstation will be saved to command.txt. On the victim computer, you will want to run a command to collect live response
data. The output of the command is sent over our TCP channel on port 2,222 and saved on the forensic workstation instead
of the victim's hard drive.
The data can be sent from the victim computer with the following command:
command | nc forensic_workstation_ip_address 2222
Of course, you will want to rename the italicized keywords such as command with the command you run to collect the live
response data. More relevant commands that make up our Live Incident Response Process will be discussed shortly.
Moreover, you will want to substitute the IP address of your forensic workstation where it says
forensic_workstation_ip_address. After these commands have completed, you will press CTRL-C (^C) to break the netcat
session, and the resulting file command.txt will contain all of the data from the command we executed. A simple MD5
checksum of command.txt can be calculated so that you may prove its authenticity at a later date with the following command:
md5sum –b command.txt > command.md5
The -b option tells md5sum to calculate the MD5 hash of the contents of the command.txt file in binary mode. You will always
want to use the -b command-line switch. md5sum is available in the Cygwin utilities from http://www.cygwin.com. You may
also use the md5sum from UnxUtils located at unxutils.sourceforge.net. UnxUtils are native Windows binaries, so you will not
need additional dynamically linked libraries (DLL) installed on your system like Cygwin requires. This will become important
when we create a response toolkit. We will discuss the methods of creating a response toolkit in Chapter 16, "Building the
Ultimate Response CD."
In most circumstances, you will want to use a variant of netcat, named cryptcat (http://sourceforge.net/projects/cryptcat),
because it encrypts all of the data across the TCP channel. cryptcat uses all of the same command-line switches as netcat.
cryptcat offers two advantages: secrecy and authentication. Because the data is encrypted, intruders will not be able to see
what you are collecting. Due to the encryption, any bit manipulation by an intruder will be detectable because it will be
unencrypted on the forensic workstation. If the bits are altered when traversing the network, your output will be garbled. You
can choose the password used in the encryption algorithm by issuing the -k command-line flag provided to cryptcat. You must
have the same encryption password on both sides of the connection for this process to work.
The rest of this chapter will assume you are collecting data through the TCP channel we described earlier. When we discuss a
new command, assume it will be transferred to the forensic workstation through this "Poor Man's FTP." We have postponed
the discussion of how to create the toolkit that will contain these commands until Chapter 16, when we discuss how the
response toolkits are created. For the remainder of this chapter, we will analyze the data acquired during the "JBR Bank's
Intrusion" live response scenario that you may reference at the beginning of this book.
Analyzing Volatile Data
When we chose to run a live response on a victim system, the web server named JBRWWW in our current scenario, most of
the important data we acquired was in volatile data. The volatile data of a victim computer usually contains significant
information that helps us determine the "who," "how," and possibly "why" of the incident. To help answer these questions,
we collected data from the following areas on the victim machine:
* The System Date and Time
* Current Network Connections
* Open TCP or UDP Ports
* Which Executables Are Opening TCP or UDP Ports
* Cached NetBIOS Name Table
* Users Currently Logged On
* The Internal Routing Table
* Running Processes
* Running Services
* Scheduled Jobs
*Open Files
*Process Memory Dumps
We will address each of these vital areas in their respective sections and analyze the data we acquired from JBRWWW.
The System Date and Time
This is probably the easiest information to collect and understand, yet it is one of the most important pieces of information to
the investigator and is easily missed. Without the current time and date, it would be difficult to correlate the information
between victim machines if multiple machines were affected. Although in our scenario we are examining a single system, your
intrusions may involve tens or hundreds of systems. Keeping the system time and noting the offset from a trusted source
(such as a reliable NTP server) is paramount when examining log files or other time-based evidence from multiple servers.
The time and date are simply collected by issuing the time and date commands at the prompt. The time and date for JBRWWW
were found to be as follows:
The current date is: Wed 10/01/2003
The current time is: 21:58:19.29
This is indeed the time we started our live response on JBRWWW. We will also note that this time is in EDT because we are
collecting it on the east coast of the United States.
Current Network Connections
It is entirely possible that we could be executing our live response process while the attacker is connected to the server. It
could also be possible that the attacker is running a brute force mechanism against other machines on the Internet from this
server. Scenarios similar to the ones we mentioned earlier would be detected if we examined the current network
connections.
We view a machine’s network connections by issuing the netstat command. Specifically, we need to specify the -an flags with
netstat to retrieve all of the network connections and see the raw IP addresses instead of the Fully Qualified Domain Names
(FQDN):
netstat –an
When we executed the netstat command on JBRWWW, we received the following information:
Active Connections
Proto Local Address Foreign Address State
TCP 0.0.0.0:7 0.0.0.0:0 LISTENING
TCP 0.0.0.0:9 0.0.0.0:0 LISTENING
TCP 0.0.0.0:13 0.0.0.0:0 LISTENING
TCP 0.0.0.0:17 0.0.0.0:0 LISTENING
TCP 0.0.0.0:19 0.0.0.0:0 LISTENING
TCP 0.0.0.0:21 0.0.0.0:0 LISTENING
TCP 0.0.0.0:25 0.0.0.0:0 LISTENING
TCP 0.0.0.0:80 0.0.0.0:0 LISTENING
TCP 0.0.0.0:135 0.0.0.0:0 LISTENING
TCP 0.0.0.0:443 0.0.0.0:0 LISTENING
TCP 0.0.0.0:445 0.0.0.0:0 LISTENING
TCP 0.0.0.0:515 0.0.0.0:0 LISTENING
TCP 0.0.0.0:1025 0.0.0.0:0 LISTENING
TCP 0.0.0.0:1027 0.0.0.0:0 LISTENING
TCP 0.0.0.0:1030 0.0.0.0:0 LISTENING
TCP 0.0.0.0:1031 0.0.0.0:0 LISTENING
TCP 0.0.0.0:1033 0.0.0.0:0 LISTENING
TCP 0.0.0.0:1174 0.0.0.0:0 LISTENING
TCP 0.0.0.0:1465 0.0.0.0:0 LISTENING
TCP 0.0.0.0:1801 0.0.0.0:0 LISTENING
TCP 0.0.0.0:3372 0.0.0.0:0 LISTENING
TCP 0.0.0.0:4151 0.0.0.0:0 LISTENING
TCP 0.0.0.0:60906 0.0.0.0:0 LISTENING
TCP 103.98.91.41:139 0.0.0.0:0 LISTENING
TCP 103.98.91.41:445 95.208.123.64:3762 ESTABLISHED
TCP 103.98.91.41:1033 95.208.123.64:21 CLOSE_WAIT
TCP 103.98.91.41:1174 95.145.128.17:6667 ESTABLISHED
TCP 103.98.91.41:1465 95.208.123.64:3753 ESTABLISHED
TCP 103.98.91.41:3992 95.208.123.64:445 TIME_WAIT
TCP 103.98.91.41:4151 103.98.91.200:2222 ESTABLISHED
TCP 103.98.91.41:60906 95.16.3.23:1048 ESTABLISHED
TCP 127.0.0.1:1029 0.0.0.0:0 LISTENING
TCP 127.0.0.1:2103 0.0.0.0:0 LISTENING
TCP 127.0.0.1:2105 0.0.0.0:0 LISTENING
TCP 127.0.0.1:2107 0.0.0.0:0 LISTENING
TCP 127.0.0.1:4150 0.0.0.0:0 LISTENING
UDP 0.0.0.0:7 *:*
UDP 0.0.0.0:9 *:*
UDP 0.0.0.0:13 *:*
UDP 0.0.0.0:17 *:*
UDP 0.0.0.0:19 *:*
UDP 0.0.0.0:135 *:*
UDP 0.0.0.0:161 *:*
UDP 0.0.0.0:162 *:*
UDP 0.0.0.0:445 *:*
UDP 0.0.0.0:1026 *:*
UDP 0.0.0.0:1028 *:*
UDP 0.0.0.0:1032 *:*
UDP 0.0.0.0:3456 *:*
UDP 0.0.0.0:3527 *:*
UDP 103.98.91.41:137 *:*
UDP 103.98.91.41:138 *:*
UDP 103.98.91.41:500 *:*
UDP 103.98.91.41:520 *:* continued>............page (2)
The overall scenario usually dictates the next steps an investigator takes. Sometimes your victim cannot afford to remove the
system from the network because a proper backup server cannot be swapped in its place. Therefore, a traditional forensic
duplication cannot be acquired. Other times, the data currently in memory may be the only evidence of the incident. This
chapter will address a technique for collecting and analyzing forensically sound evidence from what is known as the Live
Incident Response Process.
In short, a live response collects all of the relevant data from the system that will be used to confirm whether an incident
occurred. The data collected during a live response consists of two main subsets: volatile and nonvolatile data. The volatile
data is information we would lose if we walked up to a machine and yanked out the power cord. This data would not be
present if we were to rely on the traditional analysis methods of forensic duplications. A live response process contains
information such as the current network connections, running processes, and open files. On the other hand, the nonvolatile
data we collect during the live response is information that would be "nice to have." We would collect non-volatile data such
as the system event logs in an easily readable format, for instance, instead of the raw binary files in which Microsoft Windows
saves them. Of course, this data would exist in a forensic duplication, but it would be more difficult to output it in a nice format
after the machine has been powered off.
The live response data is collected by running a series of commands. Each command produces data that under normal
circumstances would be sent to the console. Because we must save the data for further analysis, we want to transmit the
data to our forensic workstation (a machine that the forensic investigator considers trusted) instead of the local victim's hard
drive. If we were to save the data locally to the victim's hard drive, there would be a significant chance that we would be
overwriting evidence if we chose to acquire a forensic duplication at a later date. Therefore, that effect is undesirable.
There are two main ways that we can transmit the data to the forensic workstation. The first way is to use the "swiss army
knife" of network administrators called netcat. netcat simply creates TCP channels. netcat can be executed in a listening
mode, like a telnet server; or in a connection mode, like the telnet client. We can start a netcat server on our forensic
workstation with the following command:
nc –v –l –p 2222 > command.txt
The -v switch places netcat in verbose mode. The -l switch places netcat in listening mode (like a telnet server). The -p switch
tells netcat on which TCP port to listen for data. By using this command, any data sent to TCP port 2,222 on our forensic
workstation will be saved to command.txt. On the victim computer, you will want to run a command to collect live response
data. The output of the command is sent over our TCP channel on port 2,222 and saved on the forensic workstation instead
of the victim's hard drive.
The data can be sent from the victim computer with the following command:
command | nc forensic_workstation_ip_address 2222
Of course, you will want to rename the italicized keywords such as command with the command you run to collect the live
response data. More relevant commands that make up our Live Incident Response Process will be discussed shortly.
Moreover, you will want to substitute the IP address of your forensic workstation where it says
forensic_workstation_ip_address. After these commands have completed, you will press CTRL-C (^C) to break the netcat
session, and the resulting file command.txt will contain all of the data from the command we executed. A simple MD5
checksum of command.txt can be calculated so that you may prove its authenticity at a later date with the following command:
md5sum –b command.txt > command.md5
The -b option tells md5sum to calculate the MD5 hash of the contents of the command.txt file in binary mode. You will always
want to use the -b command-line switch. md5sum is available in the Cygwin utilities from http://www.cygwin.com. You may
also use the md5sum from UnxUtils located at unxutils.sourceforge.net. UnxUtils are native Windows binaries, so you will not
need additional dynamically linked libraries (DLL) installed on your system like Cygwin requires. This will become important
when we create a response toolkit. We will discuss the methods of creating a response toolkit in Chapter 16, "Building the
Ultimate Response CD."
In most circumstances, you will want to use a variant of netcat, named cryptcat (http://sourceforge.net/projects/cryptcat),
because it encrypts all of the data across the TCP channel. cryptcat uses all of the same command-line switches as netcat.
cryptcat offers two advantages: secrecy and authentication. Because the data is encrypted, intruders will not be able to see
what you are collecting. Due to the encryption, any bit manipulation by an intruder will be detectable because it will be
unencrypted on the forensic workstation. If the bits are altered when traversing the network, your output will be garbled. You
can choose the password used in the encryption algorithm by issuing the -k command-line flag provided to cryptcat. You must
have the same encryption password on both sides of the connection for this process to work.
The rest of this chapter will assume you are collecting data through the TCP channel we described earlier. When we discuss a
new command, assume it will be transferred to the forensic workstation through this "Poor Man's FTP." We have postponed
the discussion of how to create the toolkit that will contain these commands until Chapter 16, when we discuss how the
response toolkits are created. For the remainder of this chapter, we will analyze the data acquired during the "JBR Bank's
Intrusion" live response scenario that you may reference at the beginning of this book.
Analyzing Volatile Data
When we chose to run a live response on a victim system, the web server named JBRWWW in our current scenario, most of
the important data we acquired was in volatile data. The volatile data of a victim computer usually contains significant
information that helps us determine the "who," "how," and possibly "why" of the incident. To help answer these questions,
we collected data from the following areas on the victim machine:
* The System Date and Time
* Current Network Connections
* Open TCP or UDP Ports
* Which Executables Are Opening TCP or UDP Ports
* Cached NetBIOS Name Table
* Users Currently Logged On
* The Internal Routing Table
* Running Processes
* Running Services
* Scheduled Jobs
*Open Files
*Process Memory Dumps
We will address each of these vital areas in their respective sections and analyze the data we acquired from JBRWWW.
The System Date and Time
This is probably the easiest information to collect and understand, yet it is one of the most important pieces of information to
the investigator and is easily missed. Without the current time and date, it would be difficult to correlate the information
between victim machines if multiple machines were affected. Although in our scenario we are examining a single system, your
intrusions may involve tens or hundreds of systems. Keeping the system time and noting the offset from a trusted source
(such as a reliable NTP server) is paramount when examining log files or other time-based evidence from multiple servers.
The time and date are simply collected by issuing the time and date commands at the prompt. The time and date for JBRWWW
were found to be as follows:
The current date is: Wed 10/01/2003
The current time is: 21:58:19.29
This is indeed the time we started our live response on JBRWWW. We will also note that this time is in EDT because we are
collecting it on the east coast of the United States.
Current Network Connections
It is entirely possible that we could be executing our live response process while the attacker is connected to the server. It
could also be possible that the attacker is running a brute force mechanism against other machines on the Internet from this
server. Scenarios similar to the ones we mentioned earlier would be detected if we examined the current network
connections.
We view a machine’s network connections by issuing the netstat command. Specifically, we need to specify the -an flags with
netstat to retrieve all of the network connections and see the raw IP addresses instead of the Fully Qualified Domain Names
(FQDN):
netstat –an
When we executed the netstat command on JBRWWW, we received the following information:
Active Connections
Proto Local Address Foreign Address State
TCP 0.0.0.0:7 0.0.0.0:0 LISTENING
TCP 0.0.0.0:9 0.0.0.0:0 LISTENING
TCP 0.0.0.0:13 0.0.0.0:0 LISTENING
TCP 0.0.0.0:17 0.0.0.0:0 LISTENING
TCP 0.0.0.0:19 0.0.0.0:0 LISTENING
TCP 0.0.0.0:21 0.0.0.0:0 LISTENING
TCP 0.0.0.0:25 0.0.0.0:0 LISTENING
TCP 0.0.0.0:80 0.0.0.0:0 LISTENING
TCP 0.0.0.0:135 0.0.0.0:0 LISTENING
TCP 0.0.0.0:443 0.0.0.0:0 LISTENING
TCP 0.0.0.0:445 0.0.0.0:0 LISTENING
TCP 0.0.0.0:515 0.0.0.0:0 LISTENING
TCP 0.0.0.0:1025 0.0.0.0:0 LISTENING
TCP 0.0.0.0:1027 0.0.0.0:0 LISTENING
TCP 0.0.0.0:1030 0.0.0.0:0 LISTENING
TCP 0.0.0.0:1031 0.0.0.0:0 LISTENING
TCP 0.0.0.0:1033 0.0.0.0:0 LISTENING
TCP 0.0.0.0:1174 0.0.0.0:0 LISTENING
TCP 0.0.0.0:1465 0.0.0.0:0 LISTENING
TCP 0.0.0.0:1801 0.0.0.0:0 LISTENING
TCP 0.0.0.0:3372 0.0.0.0:0 LISTENING
TCP 0.0.0.0:4151 0.0.0.0:0 LISTENING
TCP 0.0.0.0:60906 0.0.0.0:0 LISTENING
TCP 103.98.91.41:139 0.0.0.0:0 LISTENING
TCP 103.98.91.41:445 95.208.123.64:3762 ESTABLISHED
TCP 103.98.91.41:1033 95.208.123.64:21 CLOSE_WAIT
TCP 103.98.91.41:1174 95.145.128.17:6667 ESTABLISHED
TCP 103.98.91.41:1465 95.208.123.64:3753 ESTABLISHED
TCP 103.98.91.41:3992 95.208.123.64:445 TIME_WAIT
TCP 103.98.91.41:4151 103.98.91.200:2222 ESTABLISHED
TCP 103.98.91.41:60906 95.16.3.23:1048 ESTABLISHED
TCP 127.0.0.1:1029 0.0.0.0:0 LISTENING
TCP 127.0.0.1:2103 0.0.0.0:0 LISTENING
TCP 127.0.0.1:2105 0.0.0.0:0 LISTENING
TCP 127.0.0.1:2107 0.0.0.0:0 LISTENING
TCP 127.0.0.1:4150 0.0.0.0:0 LISTENING
UDP 0.0.0.0:7 *:*
UDP 0.0.0.0:9 *:*
UDP 0.0.0.0:13 *:*
UDP 0.0.0.0:17 *:*
UDP 0.0.0.0:19 *:*
UDP 0.0.0.0:135 *:*
UDP 0.0.0.0:161 *:*
UDP 0.0.0.0:162 *:*
UDP 0.0.0.0:445 *:*
UDP 0.0.0.0:1026 *:*
UDP 0.0.0.0:1028 *:*
UDP 0.0.0.0:1032 *:*
UDP 0.0.0.0:3456 *:*
UDP 0.0.0.0:3527 *:*
UDP 103.98.91.41:137 *:*
UDP 103.98.91.41:138 *:*
UDP 103.98.91.41:500 *:*
UDP 103.98.91.41:520 *:* continued>............page (2)
 | |  | |  | |  | |  | |  | |  |
| Computer Forensic Services - TR LOGIC, Inc. |