('binary' encoding is not supported, stored as-is) 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 archive was generated by hypermail 2b30 : Fri Nov 30 2001 - 08:23:50 PST