> No need for the disclaimer - you know that evidence > dynamics is one of my favorite issues. I know how much trust and reputation/credibility mean in this industry, so I didn't want someone saying, "Carv said that Eoghan said..."... But I'm glad the subject caught your attention. > Our brief discussion includes > recommendations for dealing with media damaged in > flood, fire, etc. and > media that carries other forms of evidence on it > (e.g. blood). I find this whole subject fascinating largely b/c it doesn't seem to be discussed to a large extend in forums such as the Forensics list. In our earlier correspondance, I mentioned to you the case of the AF OSI case in '91 (in the Philippines) in which a 5 1/4 floppy was cut into 24 pieces with pinking shears, and the evidence was still recovered and the guilty party convicted (I'm still looking for a reference for you on that one). In that case, you've got mutilated media, but evidence was still collected. > I agree that there is value in examining a live host > in some situations. > As was mentioned, this may alter the system but this > does not > automatically make all evidence collected from the > machine inadmissible. One way to minimize this is to collect the data and transport it off of the victim system to a 'nearby' forensics workstation. Most of the articles I've read on the subject are specific to Solaris and Linux, but similar techniques are available for NT/2K. However, piping the output of a command (such as netstat) through netcat or cryptcat to a remote Forensics workstation b/c of how the pipe is handled...when the command terminates the pipe seems to prevent the command prompt from returning. This is the reason why I've been working on the Forensics Server Project. > The main question to consider when presenting > problems in training is, > what do you want the students to learn? My sense is > that acid filled > shot glasses and computers wired with explosive > deserve mention but do > not need to be demonstrated to convey the lesson. Agreed. A demonstration of these is a little much, particularly if you're trying to teach procedure. > More important is the > ability to deal with more common situations such as > rootkits, Trojans, > encryption, etc. Again, this is within reason - at > the moment most > investigators will not encounter Rubberhose > (http://www.rubberhose.org/) > or Knark. And, of course, there are other issues to deal with when faced w/ NT/2K, such as... > One suggestion is to present investigators with a > Windows machine with > EFS. The machine is on and open when investigators > first encounter it > but shutting the system down will make data recovery > very difficult. Here's some really good info on the topic...part I, anyway... http://www.winntmag.com/Articles/Index.cfm?ArticleID=5387&Key=Internals > Warren Kruse's Computer Forensics book has a nice > overview of this issue, Yes, the book (Jay Heiser as co-author, some guy named "Harlan Carvey" or some such was a technical editor) does give some good info on the topic, as well. Your suggestions for exercises were excellent...I'd like to see what Darren's final list looks like... __________________________________________________ Do You Yahoo!? Yahoo! GeoCities - quick and easy web site hosting, just $8.95/month. http://geocities.yahoo.com/ps/info1 ----------------------------------------------------------------- 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 : Fri Nov 30 2001 - 17:34:53 PST