It Bears Repeating

There are just somethings that you can't say often enough. For example, tell the ones you love that you love them. Also, tell them that when they suspect an incident, do NOT shut the system off!

Think of Brad Pitt and Ed Norton (no, not that way!!) in Fight Club, but paraphrase..."the first rule of incident response is...don't panic. The second rule of incident response is...DO NOT PANIC!!"

Okay, let's go back to the beginning...well, maybe not that far. Let's go back to an InformationWeek article published in Aug, 2006, in which Kevin Mandia was quoted...here's one interesting quote:

One of the worst things users can do if they think their systems have been compromised by a hacker is to shut off their PCs, because doing so prevents an investigator from analyzing the contents of the machine's RAM, which often contains useful forensic evidence, Mandia said.

So, what do you think? Is he right? Don't say, "well, yeah, he must be...he's Kevin Mandia!" Think about it. While you're doing that, let me give you a scenario...you're an admin, and you detect anomalous traffic on your network. First, you see entries in firewall or IDS logs. You may even turn on a sniffer to capture network traffic information. So let's say that at that point, you determine that a specific system is connecting to a server on the Internet on an extremely high port, and the traffic appears to be IRC traffic. What do you do? More importantly, what do you want to know?

The usual scenario continues like this...the system is taken offline and shutdown, and stored in an office someplace. An outside third party may be contacted to provide assistance. At this point, once the incident is reported to management, the questions become...what is our risk or exposure? Was sensitive information taken? Were other machines affected? If so, how many?

This is where panic ensues, because not only do most organizations not know the answers to the questions, but they don't know how to get the answers themselves, either. Here's another quote from the article:

...Mandia said rumors of a kernel level rootkits always arise within the company that's being analyzed.

You'll see this in the public lists a lot..."I don't know what this issue is, and I really haven't done any sort of investigation...it's just easier to assume that it's a rootkit, because at the very least, that says the attacker is a lot smarter than me." Just the term rootkit implies a certain sexiness to the incident, doesn't it? After all, it implies that you've got something someone else wants, and an incredibly sophisticated attacker, a cyberninja, is coming after you. In some cases, it ends up being just a rumor.

The point of all this is that many times, the questions that management has about an incident cannot be answered, at least not definitively, if the first step is to shut down the system. At the very least, if you have detected anomalous traffic on your network, and traced it back to a specific system, rather than shutting the system off, take that additional step to collect process and process-to-port mapping info (for a list of tools, see chapter 5 of my first book) from the system. That way, you've closed the loop...you've not only tied the traffic to a system, but you've also tied it to a specific process on the system.

Of course, if you're going to go that far, you might was well use something like the Forensic Server Project to gather even more information.

FSP/FRU File Copy Client posted

I posted the File Copy Client (FCli) that was mentioned in Windows Forensics and Incident Recovery. After getting enough questions about it, I thought that it was about time that I uploaded it to the SourceForge site.

The FCli is a GUI client that the investigator can use to select files to be copied from the 'victim' system, over to the FSP server. Here's how you use it (I am going to create webinar/movie files for this stuff for the book)...download the archive from the SF site, and keep all of the files (EXE and associated DLLs) together in the same directory. For initial testing, you may want to have them separate from other tools and files. Launch FCli, and choose File -> Config...enter the IP address and port of the FSP server. Then choose File -> Open and use the dialog to select the files that you want to copy (web server log files, etc.). Once you've selected the files that you want, click OK to close the dialog and the file names will be added to the FCli ListView (you can go back and open the File -> Open dialog again, if you wish).

Once you have selected the files you want to copy, click "OK" in the main FCli window. The status bar on the bottom of the window will show you your progress...it may go fairly quickly. Once all the files are copied over, simply close the window.

What FCli does is first collect metadata about the file...size, MAC times, and MD5/SHA-1 hashes. This data is sent to the FSP server and archived. The file itself is then copied over to the server, at which point the server verifies the hashes. Here's an extract from the case log file:

Mon Oct 2 21:26:14 2006;DATA command received: bho2.dat
Mon Oct 2 21:26:14 2006;HASH bho2.dat:885f60ff031496a3fe37aa15454c6a46:bf402abbbe76e417105d18ad9193436315dd7343
Mon Oct 2 21:26:14 2006;FILE command received: bho2.pl
Mon Oct 2 21:26:14 2006;bho2.pl created and opened.
Mon Oct 2 21:26:14 2006;bho2.pl closed. Size 1522
Mon Oct 2 21:26:14 2006;MD5 hashes confirmed for bho2.pl.
Mon Oct 2 21:26:14 2006;SHA-1 hashes confirmed for bho2.pl.

First, the metadata is sent to the server and saved in a file with the .dat extension (next version needs to change this, in case of a conflict with a file with a .dat extension), and the hashes are pulled out of the file and logged. Then the file is copied over and the size of the file on the server, after it's been written, is logged (you can verify this later with the size recorded in the metadata). Then the file hashes are computed for the file that is now on the server, and confirmed against the metadata.

The archive you want from the SF site is fcli_20061003.zip. This archive contains the executable file and all supporting DLLs, as well as the Perl source code for the FCli.

Thanks, and enjoy!

Addendum: It seems that WinRAR-compressed files don't always play well with other compression utilities, so I updated the archive and uploaded it...look for fcli_20061003a.zip