Harlan, No need for the disclaimer - you know that evidence dynamics is one of my favorite issues. We cover this in the Handbook of Computer Crime Investigation's introduction (the Intro is available in PDF at http://www.disclosedigital.com/). 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). However, the remainder of the book focuses on technical aspects of forensic analysis of computer systems, networks and embedded systems (e.g. PDAs, mobile phones). This is mainly useful to individuals who already have experience dealing with computers, networks, and embedded systems as a source of evidence and are seeking more advanced information. 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. Most investigations involving networked computers involve the collection of volatile data. It is true, however, that we need to minimize the changes that we make to a system when collecting this evidence. Ultimately, this comes down to a judgment call - if I am not sure that a server is compromised and simply want to determine this basic fact, I might log into that system and use trusted binaries to look for signs of compromise. However, if Knark is installed, my trusted binaries no longer give trustworthy results and I must take this into consideration (e.g. use alamo/carbonite and compare network traffic to and from the machine with what I am seeing through the operating system). 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. 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. 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. Warren Kruse's Computer Forensics book has a nice overview of this issue, recommending a few steps before shutting the computer down. This is a new enough area that your students could have some fun exploring alternate ways to obtain the private keys after shutting the system down prematurely. A second suggestion is to present a Unix system that has a rootkit installed and some encrypted files. I really like the idea of a file mounted using an encrypted loopback device. Of course, you could drop them in at the deep end and modify the system to wipe the hard drive when certain commands are executed (to teach them to use trusted tools) or install something like Knark that modifies the kernel since we may see more of these as the tools become more popular. Another interesting scenario is how to examine a system while the suspect is logged in. You either need to remain inconspicuous or be very fast and very lucky. In one case, we used an intruder's rootkit to hide ourselves while we gathered evidence of his activities. I spoke with one investigator in Europe who used SubSeven to gather information, including passwords, from the suspect's computer. Eoghan Casey Information Security Office Yale University H Carvey wrote: > > In-Reply-To: <9993DAE9D49BD411AB180008C7B1FF20053B52EEat_private> > > >>Excellent point. There is a lot of volatile data > >>that disappears when a system is powered > >>down...and would be extremely useful in a case. > > > >The alternative though is troublesome. If you > don't create the chain of > >evidence and establish your control over that > evidence instantly then any > >forensic work you perform won't stand up in court. > > Eoghan Casey's book discusses evidence dynamics, > and Rob Lee (http://www.incident-response.org) has > an excellent analogy, that of a murder > investigation, which I'll paraphrase: > > Assume you walk into a store, and you notice > someone lying on the floor. Assume you approach > the person and try to see if they're all right. > You roll them over and see a pool of blood under > them. You call 911 and the paramedics arrive. > They attempt to revive the person and then get > them into the ambulance and take them to the > hospital. In the doctor's care, the victim dies. > However, the police can still investigate the > crime, and even prosecute the guilty party. > > I think the important thing to take away from this > is that if you have a sound methodology, you can > collect a significant amount of very valuable > volatile data from a system prior to taking it > down to make a bit-image copy of the drive. > > Consider what the bit-image copy gives you, in the > case of a trojan infection (simply as an example). > Say the employee comes to work on Monday and > boots up his system, after it had been off all > weekend...but the system was infected, say, a > month prior. So the employee boots up, the Run > key is read and the trojan launches. Suspicious > activity isn't noticed right away, say, until > Thursday. > > At this point, a bit-image copy of the drive will > reveal: > > a. The fact that the trojan files exist. > > b. Possibly the means of infection (ie, email). > > c. The file's filetimes...w/ the last access time > being on Monday, when the system was booted. > > d. The LastWrite time of the Run key in the > Registry...but this is inconclusive, as other > software may have written values. > > However, the bit-image copy of the drive doesn't > show that the trojan was running at the time that > the system was taken down, and it doesn't show who > (if anyone) was connected to the trojan at that > time. > > Many articles have been written with regards to > retrieving volatile data from Solaris and Linux > systems, and I've taught an incident response > course that shows how to do this on NT/2K. > > My point is that the proper methodology, with the > associated documentation, can be used to retrieve > volatile information from a system as part of an > investigation. > > ----------------------------------------------------------------- > 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 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 - 13:28:28 PST