Hogfly,
One of the most lacking areas regarding forensic incident response is a tool that provides correlation of discovered data from a live system. Anyone have ideas on that subject?
Check out my book. I include a Perl script that correlates collected information, displaying everything in PID-delimited format. This sort of thing is something I haven't seen done anywhere else.
Harlan
harlan,
Oh I agree with you completely. Your script is great and works extremely well with FSP.
Thank you everyone for your valuable input. I like the term forensic IR, but does this term includes forensic analysis as well? The reason I asked is that my paper is all about evidence collection. I don't want to get into analysis on my paper. So I want to make sure if it is suitable for me to use this term.
I agree with many of you saying that dd, nc are the primary tools that I need for collecting evidence. There are tons of paper about such kind of evidence collection but many of them require to take the system offline. I would like to perform such operations when the system is up and running (I need to bring some new ideas on this paper so that's why I want to emphasis the investigation is done on a live system). Any new ideas that can make my paper more interesting will be great.
On a side note, if a firm has a RAID 5 system with four 50GB HD, will you recommend to use dd to get an image? It is cheap to get a 200GB HD these days. However, it will take a long time to transfer data over.
As I have mentioned before, I am a newbie here… pardon me if I ask stupid questions here.
Thank you very much.
Ella
You can run WinHex Forensic edition from a CD ROM on a live system without taking it down. WinHex also has a built in feature called "Assemble Raid System".
Ella,
To come back to your original message, if you can come up with a methodology for conducting Forensic IR on a Linux machine then it would be well received. You can see from this forum that most automated tools are designed for Windows - a similar process for Linux (ie execute a server on the target system to open communication channels in the least intrusive way possible, and then execute commands to capture live data using a tool on the investigation machine). Once again at the risk of being flamed for needing automated tools, most investigators don't have the time or depth of knowledge to do otherwise.
Good luck
Paul
I'd suggest taking a look at the Forensic Server Project (FSP)
http//
While the project was written *on* Windows, it is not specific *to* Windows. The server portion can be run on Linux, and platform-specific clients (ie, First Responder Utility, or FRU) can be written for any platform, using any language.
Harlan
Harlan,
I don't mean to be negative about your work, as you are doing some great things & it has helped me learn alot about this subject. However, I think the use of perl was summed up quite accurately by one contributor in another thread - Click here to view
For real world investigations, what I am looking for is essentially ProDiscover - pop in the server CD & connect to it with the investigation box using a nice intuitive GUI - no complex pre-installations. This works beautifully for us in Windows, but still struggling in Linux. Right now we are up to our eyeballs in Windows cases so it is not on my urgent list, but I will no doubt be speaking to Technology Pathways soon to try & resolve it.
Please don't take this the wrong way - I am open to be convinced if you provide me with a simple and fast methodology on a par with ProDiscover?
Thanks
Paul
Paul,
At this point, I don't think I'll be able to convince you.
ProDiscover is a great tool, without question.
The FSP is simply another tool. The purpose of it is to allow for the rapid collection of volatile data from a system, minimizing the interaction required by the first responder. Drop the CD containing the FRU (compiled into a standalone EXE…which is provided in the download from my site) into the CD tray of the victim system, fire up the FRU, select the server IP and port, and the .ini file to parse, and that's it. Everything else is handled by the tools, to include detailed logging/timestamping of activity.
The FRU can run any third party CLI tool and send the output off to the server for timestamping and archiving. This includes dumping the contents of the clipboard and protected storage, etc., etc.
Based on your comments, and especially those regarding Perl, it's clear that the issue is more one of zero-knowledge response. My concern is that there are presentations going on a conferences such as Blackhat and DefCon that specify anti-forensics techniques to be used against the analyst, rather than the forensic analysis tools themselves.
Finally, you state that you're looking for something with "no complex pre-installations". The FSP and the FRU ship with their source (ie, Perl scripts) and compiled/tested standalone EXEs. The "installation" is no more complex than what is required with ProDiscover.
Harlan
Harlan,
Based on your comments, and especially those regarding Perl, it's clear that the issue is more one of zero-knowledge response. My concern is that there are presentations going on a conferences such as Blackhat and DefCon that specify anti-forensics techniques to be used against the analyst, rather than the forensic analysis tools themselves
Yeah… I know what you are saying and it goes against my own personal opinions to have to defend the need for simplicity. But…we have a large caseload and I'm afraid that levels of knowledge vary widely among the investigators. The Live IR (see… not using the word *forensics* nowD) that we are doing at the moment is primarily aimed at analysing malware. essentially the investigators are simply collecting the information for later analysis back in the office by specialists. By and large, all we need is a netstat, fport, brief traffic capture (ethereal) and a copy of the system drive. Mostly we are using Helix (as it is free) & we will use ProDiscoverIR for the cases that are more important.
Anyway, please don't get the idea that I am set in my ways against using FSP. I can tell you that we won't be using it on Windows systems as we have established procedures using Helix & ProDiscover. However, I will be testing it's functionality when examining Linux systems as soon as I have some time…
Cheers
Paul
> essentially the investigators are simply collecting the information for
> later analysis back in the office by specialists.
This is rather easy to do with the FSP, and is also highly customizable. Create your own .ini file for use with the FRU, and you've got an easy to use tool. You do updates when you need to, not when some commercial developer feels that it's necessary.
> By and large, all we need is a netstat, fport…
This is what the FRU/FSP framework was designed for.
It's easy…put the fruc.exe file and associated DLL on a CD, along with tools (ie, fport.exe, openports.exe, netstat.exe, tlist.exe, etc.) and an .ini file that contains the necessary commands to run the tools. To make things even easier, include a batch file that launches the fruc.exe file…the only interaction required by the first responder is to type in the name of the batch file, followed by the IP address of the server (and the port, if you're not using a standardized one that can be added to a batch file).
The FRU/FSP automates all of this and minimizes interaction required by the user.
Harlan