An explanation of the FSPC and the FRUC

Okay, so I posted my updates of the FRUC yesterday, and I'm glad I got that out of the way. But I probably need to give an explanation of the FRUC, and talk about why I wrote it in the first place.

When performing incident response activities, it's generally considered a GOOD THING to get the data you're collecting off of the victim system. In some cases, writing files to the hard drive of the victim system may overwrite important data that's in slack space, but just getting the data off of the system so that it can be analyzed quickly is important. You may simply want to determine quickly whether you have a real incident or not.

Well, on way of doing this is to write the files to the drive, archive them using a zipping utility, and then FTP/TFTP the archive to a waiting server. Hhhhmmm...lots of steps, creates files on the drive...okay, that may work sometimes, but what else have you got?

Another option is to use netcat to get the data off of the system. The way it works is this...you open netcat as a listener on your forensic server and head on over to the victim system. Once there, you run the commands you would use to gather data...command line tools that will display their output at the console, or STDOUT...and rather than viewing the output of the commands on the screen in front of you, you "pipe" the output through netcat, sending the data to the waiting server. For the sake of brevity, the specifics of this are covered in my book, as well as in online resources like this one from Keith Jones.

Okay, so what we've got here is a way to get data off of the system. When you're all done, it ends up on your forensic server in one big file, which you have to parse apart before you analyze it. Also, you've had to maintain a notebook detailing everything you've done...commands you ran, when you ran them, etc. Just typing in all those commands can be pretty tedious, even if you have them written down...right? Say that you have multiple boxes you're looking at...what then? You've got to retype all of those commands...and maintain the notebook.

There must be an easier way...and there is!

Let's start with the server component first...the FSPC. This is the component that sits on your forensic server, waiting for connections. The FSPC basically handles data management...when a connection is received, the FSPC puts the files that it's sent into a directory, and keeps a timestamped log of everything that goes on. When data is sent to the FSPC, it generates a hash for the file that it creates. If a file is copied to the FSPC, it will verify the hashes of the file when it writes it to the hard drive.

The FRUC is the "First Responder Utility (Commandline)"...this means that there's no GUI, no buttons to push. The FRUC runs from a preconfigured .ini file, or via arguments entered at the commandline. Basically, the investigator or first responder copies the FRUC files (.exe files, supporting DLL, .ini file) and any third-party utilities that the FRUC will run to some media...a CD, a USB-connected thumb drive, etc. Once done, she carries it with her, or deploys it for someone else to use. Once the media is inserted into the machine, a single command is run, and all of the data that the investigator wants to collect is sent to the forensic server for storage.

Pretty simple, eh? Powerful tools, automated (to minimize mistakes and reduce the amount of time necessary to collect data), and minimal interaction required by the user.

The framework seems to be pretty complete for data collection at this point. As I've said before, data collection is easy...and from looking at the FSP, I hope you see that, too. It's the data analysis that's tough. One way to deploy this is to have multiple .ini files on the media. The user will insert the media and run the first .ini file, which collects certain data...say, process and network connection information, etc. On the server side, the investigator can run quick analysis tools/scripts, and determine whether a more detailed look is necessary. For larger investigations involving multiple machines, the investigator can open multiple FSPC listeners on the server, each on a different port, and instruct first responders to run the FRUC with the necessary commandline switch to change the port used in the .ini file.

There are other toolkits for pulling information from Windows systems, most notably IRCRv2 and WFT. However, I prefer the FSP framework...not just because I wrote it, but because I think that by removing some of the interaction that the first responder will have with the tools, it's easier to deploy and use, particularly in larger environments.

Also, while the FSPC and FRUC are deployed as executables, their Perl source is also provided (ie, the tools are compiled into executables using Perl2Exe). This makes the tools very extensible...using the Perl source, you can easily make your own modifications to the code, and extend the tools for your own use, in your own environment.