-
Introduction
-
Preparing A Toolkit
-
Responding To An Incident
-
Removing Data From The PC
1. Introduction
In my work environment, when an incident occurs it's quite likely that upon discovery the first response will be to protect the network. Following that, to understand the incident and to perform a Root Cause Analysis (RCA) to discover the cause, implement safeguards to prevent further incidents of the same kind. Even though in most organisations legal action is not common it is beneficial to preserve as much evidence as possible, as until the incident is understood legal action cannot be ruled out.
The following blog entry describes the steps I perform to protect the network, whilst gathering the volatile data to help perform the RCA whilst preserving the data for further forensics if necessary. The guide below assumes that you have administrative control over the victim PC, network connectivity to a PC for the collection of data, network connectivity to a remote share or access to remote storage such as a USB device.
2. Preparing A Toolkit
To prevent any programs writing to the PC the following tools should be copied to a form of read-only media such as a CD-ROM or run from a read-only network share. Copying data to a comprimised PC may overwrite data on the victim PC and comprimise any legal procedings if they were to occur.
Command, Netstat, Psloglist, Netcat, Pslist, Netusers, Net (user, session), Pulist, ListDLLs, Handle, Tlist, Tasklist, PS, IPConfig, NBTStat, Fport, Openports, DOSKEY, GPList, Time, Date, Route
Many of the tools above collect similar information. However, they often have subtle differences and may provide information that the others lack. What is important is that tools come from good sources, so in the case of tools such as Command, Netstat and other Windows native tools this means taken from a fresh install of Windows. This is to prevent using tools that may be infected or that may have been altered. A disk with these tools on should always be kept safe and MD5Sums should be calculated and saved along with the tools. As important as this is familiarity of the tools. Become an expert at using them and learn there nuances. The switches with commands such as time /t are essential when piping commands to as listener.
To make the process of collecting volatile data easier it is useful to create a batch file to run the tools. Once the switches have been correctly identified and are entered into the batch file the command will be executed the same way each time, this will help save time and has the additional benefit of making the logging task slightly easier too.
3. Responding To An Incident
Firstly, the incident must be discovered. This may be through log monitoring, traffic analysis, alerts or just by stumbling across something that shouldn't be there such as a program, process or registry entry.
Once the incident has been discovered usually the first reaction is to pull the plug to protect the network. Although this does have the desired effect of isolating the PC from the network it also destroys critical volatile data. If the PC remains on and connected to the network this important data can be taken from the PC for further analysis. Also the system in question may be a critical business system that cannot be taken down without monitory loss.
4. Removing Data from the PC
After assembling the toolkit and testing the tools/batch files in a test environment you are ready to respond to an incident.
Data on the PC needs to be removed without altering the state of the PC as much as possible, as until the incident is understood it will not be known if any authorities are notified. This is done by using tools and scripts that can be run from the command-line and piped out to a netcat listener. This gets the volatile data off the PC so it can be disconnected from the network and powered down if necessary. If a listener is not available then every effort should be made to save the captured data on either a network share or some other form of removable media such as an attached USB drive, but be aware that connecting a USB device will write an entry to the registry so the make, model and serial no must be included in the log.
Log File
It is important that a log is kept of every action taken on the victim PC including the following:
- Time
- Tools Used (& versions)
- Commands Used
Setting up a listener
To capture the data across a network connection a netcat listener can be set up on a remote PC using the following command:
c:>nc -L -p 4455 > victimPC_date.log
This will capture any data sent to port 4455 and log it to a file called victimPC_date.log.
From The Victim PC
Log onto the victim PC and run the commands or the prepared batch file from your toolkit and pipe the results out to the netcat listener, the USB device or the network share.
Below are examples of the commands that can be run.
Running each of the commands individually would look something like below:
date /t | nc -w 1 IP_ADDRESS_OF_LISTENER 4455
time /t | nc -w 1 IP_ADDRESS_OF_LISTENER 4455
netstat -anovb | nc -w 1 IP_ADDRESS_OF_LISTENER 4455
fport | nc -w 1 IP_ADDRESS_OF_LISTENER 4455
........Thats quite a lot of work if you get the picture. If you was to create a batch file file with entries such as the following in you could just pipe the batch file out to the listener or to a log file on a share or USB.
The batch file could contain the following:
date /t
time /t
ifconfig /all
netstat -anovb
net session
net user
.................and many more from the toolkit can be added. One thing to note is to make sure none of the commands require user input to continue. For example, time if used without the /t switch will hang as will date. This reiterates the point of becoming familier with the tools and testing them before an incident.
Supposing the batch file is called Volatile.bat you could execute the following command:
volatile.bat | nc -w 2 IP_ADDRESS_OF_LISTENER 4455
Or if F: is the USB or network share:
volatile.bat > F:\>Victim_PC_Name.log
You then have the envious task of going through the logs to find the cause of the incident. Once the data has been lifted from the PC it can be disconnected from the network by disconnecting the network cable if necessary.
If you require further information of the collection of volatile data or any aspects of forensics then the following books are an excellent resources.
- Windows Forensics and Incident Recovery from Harlan Carvey.
- Incident Response by Kevin Mandia & Chris Prosise
A computer crime and forensics podcast can be found by googling CyberSpeak.
