> > Second, no one really wants to do all the repetitive > > documenting of their actions...they'd rather just > > get on with it. > > BAD idea. I am no forensics expert, but I would say > documenting the actions of the examiner should be key > so it can be shown that the examiner did not alter the > system. Like I said...no one wants to do this, even though most of the available forensics methodologies state that this should be done. Agreed, it *is* a bad idea not to do this, but I've seen many self-proclaimed "experts" conduct an "investigation" without a shred of documentation. > How about keeping a ledger of all commands used and > using a few tools from read-only media to gather state > info and pipe the output to floppy. Here's what I had in mind: Kevin Mandia wrote an article that appeared in a short-lived magazine (a single issue) that addressed using netcat to pipe information off of the "victim" system, and storing it on a forensics workstation. The commands used are similar to what was mentioned earlier in the thread (using tools burned to a CD): [forensics workstation] c:\>nc -L -p 7070 > mydata.log [victim system] d:\>fport | nc 192.168.0.1 7070 Now...there are a couple of problems with this. First, the command prompt on the victim system doesn't automatically return...you have to hit Control C after few seconds. What happens if you're using a command that takes longer than a second or two...like a 'dir' command with '/s'? Another obstacle is documenting all this as you go along. While trained forensics analysts are paid to do this sort of thing, most admins simply do NOT want to. I met an admin that imaged almost every drive he came across...I'm not kidding...but didn't have a shred of documentation about the original drives. Not even the command he used or software version for making the image. So then I thought...what if there were a software app that allowed the admin/incident handler to get info off of the "victim" system and onto a forensics workstation via a socket, but did everything automatically? The app wouldn't be fully automatic, of course...the admin would have to select the files he wanted to copy, for example. But once he did, the app would handle documenting the entire process. Say the admin wanted to copy two or three dozen files from the system for examination. Instead of having to document and type the commands for computing hashes, copying files, and then verifying hashes...the app could handle all that. The app would even collect MAC times, owner, permissions/ACLs, etc, prior to copying the file. Once the file was copied, hashes would be verified and documented. Say the admin wanted to run a series of external, third party tools (pslist, handle, fport, etc) or even native tools that she'd copied to the CD (netstat). She could create a list of those programs in the GUI, and the app would then document and execute each command, sending the output to the forensics workstation for storage, and later analysis. This is exactly the project I'm working on. http://patriot.net/~carvdawg/fsproj.html I've got some of the base code completed, and I'm currently adding functionality. I've already completed and distributed tools that can be used on the server (procdmp) as well as on the client (or 'victim' system): http://patriot.net/~carvdawg/perl.html I'm focusing on Win32 systems, and others have expressed an interest in Linux/*nix systems. Carv __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com ----------------------------------------------------------------- This list is provided by the SecurityFocus ARIS analyzer service. For more information on this free incident handling, management and tracking system please see: http://aris.securityfocus.com
This archive was generated by hypermail 2b30 : Wed Jun 19 2002 - 08:16:01 PDT