Capturing information from live systems

I'm sure that over time, I'll have plenty of opportunity to discuss various tools that can be used in the course of incident response activities...what they do, how they can be used, etc.

What I'd like to talk about now is various ways of getting the information off of systems. There are a variety of ways you can go about collecting information and sending it off of your systems...the one you choose to use depends on the situation,your policies, etc.

One way to collect the information is to run your tools, and have the output of each tool written to a file in a specific directory you've created on the system. Many times, even the most basic information won't fit on a 1.44MB diskette along with your tools, so you'll put the tools on a diskette, CD, or a shared drive, and run them. Once the tools are done, you can launch the FTP client that ships with Windows systems to transport the information off of the system. Of course, you can also archive the data you've collected first before sending it off the system. This is a good method to use in an environment that doesn't make use of domains, where you'd have mapped drives available for copying data to for storage.

If you're a domain admin, and/or you have remote access to a system for administrative purposes, you can use a combination of remotely-run and locally-run (can run them remotely via psexec.exe) tools to collect information and save it locally to your system.

Another method is to set up a netcat listener, and then use netcat in client mode on the "victim" system to pipe the output of the command to the listener. The listener would be set up on the server in this manner:

c:\netcat>nc -L -d -p 5150 > myfile.txt

The above command line starts netcat in detached mode, listening on port 5150 (yes, this is a Van Halen reference, in case you were wondering). Anything that the listener receives on this port is then redirected to 'myfile.txt'.

Then, on the "victim" system, you'd run netcat in this manner:

c:\> nc 5150

For a listing of the various switches used by netcat, look here.

If you're concerned about encryption, then take a look at cryptcat from farm9. Cryptcat is netcat with TwoFish encryption.

The problem with using this method is that now you have to parse apart "myfile.txt" into it's separate component files, as the listener command dumps everything into one file. The way around this is to create a new listener for each command you're going to run, either by retyping the command or creating a separate listener on a separate port.For example, if you know how many commands you're going to run, you can use a batch file to create separate listeners on sequential ports. Then, when you run your client-sidebatch file, simply pipe the output of each command to a different port.

My personal favorite (for obvious reasons) is to use the Forensic Server Project (FSP). The FSP is a framework for getting data off of a system. The tools (the FSP itself, and the client component, called the First Responder Utility, or FRU) are written in Perl, but provided as standalone executables (accompanied by Perl source). The FSP works like this...you start the server component (in this case, FSPC.exe) on the system you're using as a forensic server. You can choose the default settings for listening port, directory to store files (i.e., case management), etc. Then, you put your CD with your tools and the FRU (FRUC.exe) in the "victim"system, and enter the appropriate command line options. The FRU reads the fruc.ini file for the commands to run (executables for each command must be on the CD), as well as which Registry keysto query. The FRU sends all of this information over to the FSP automatically, where the data is stored, checksummed, and all activity is logged with timestamps.

There is also a file copying client available, though it was not included on the CD along with the book. This client gets a list of files to copy from the first responder via the GUI, and for each file, it gathers metadata, calculates a checksum, and copies the file bit-by-bit to the server. Once the file is copied, the server component will calculate a checksum for the newly-copied file, and verify the integrity of the file. Let me know if you want a copy of this file.

Because all of the data is stored in flat text files, scripting languages (batch files, Perl, Python, VBScript) can be used to implement an analysis suite on the forensic server, to quickly and easily parse the data and provide some level of data reduction (remember "artifical ignorance" from previous posts?) and analysis.

I designed the Forensic Server tools to be extensible. Not only is the Perl source included for both tools, but the design of the FRU allows you to add any tools you like to the fruc.ini file. For example, grab the DriveInfo tool from my Tools page, and run that on a system. Then, add it to the fruc.ini file. Very cool.

If you happen to be using the FSP, how about posting the fruc.ini file you use? Don't want to post it into a comment here? Got some interesting tools that you use in the fruc.ini file? Drop me a line and let me know.

One of the things on my rather extensive to-do list is to write a version of the FRU that writes to a mapped drive, or a USB-connected thumb drive. If you're interested in something like this, let me know.

A whole other area that needs to be addressed and discussed is the analysis of informationcollected, but that's best left to blogs yet to come...