I agree with Matthew. One thing you may want to try, if you repeat this excercise, is to image the machine before you attack it so have some benchmarking capability and can do a cluster to cluster comparisson. Then you can see, if its not there, what was saved in its place. Of course . . . you may get slightly different results. File deletion and recovery in Windows is not an exact science. DB -----Original Message----- From: Matthew.Brownat_private To: 'forensicsat_private' Sent: 3/12/02 1:54 PM Subject: Re: Encase and data recovery Brandon You came up with the most probable answer. Your test actually may have been a part of the problem. Because this wasn't a production system that had been up and running for normal use, all the files may have been at the very beginning (inside tracks) of the HDD (Hard drive). NTFS put the deleted clusters in it's available list for future use and any new cluster (minimum allocation unit) requests would have immediately been allocated. Some, if not all, of the recently available clusters would have been reallocated and overwritten. On a production system that had been up and running for several months, depending on the file system activity, move evidence might have been left unallocated in clusters away from the inside tracks. Finding some evidence in such a scenario was actually a good sign and indicates that the temporary tool installs exceeded the minimal cluster/track spaces of your minimal OS and web implementation. Matthew Brown, CISSP Security Consultant "Young, Brandon" <Brandon.Youngat_private> 03/12/2002 09:53 AM To: "'forensicsat_private'" <forensicsat_private> cc: Subject: Encase and data recovery All, My colleague and I setup a default installation of IIS web server 5.0 on Windows 2000 Server using NTFS. We put together a mock incident response scenario where one of us broke into the machine dropped tools on it, edited web server logs to cover tracks, deleted event logs to cover up auditing tracks and then deleted all of the tools off. During the incident response phase we used Encase to investigate what actually was done to the box, since from the investigator's point of view, the logs had obviously been edited and therefore couldn't be relied upon. When he looked through the evidence files there was no remnants left of the original logs, as well as only a partial listing of the tools that were dropped on during the break in. The question we have is why weren't we able to recover the original logs? What I did when I broke into the server was stop the w3svc and tftp the IIS logs up and edited them, deleted the old logs and replaced them with the edited versions. In addition to this Encase only saw about three of the six or so tools I used while I was in the server. Why was Encase only able to recover some of tools used in the incident? One answer we came up with was that the OS used the unallocated space where the tools previous existed and therefore were overwritten. But this seems unlikely since there wasn't any legitimate activity on the machine. This box was only used for this scenario. Any ideas? Thanks, Brandon Young CISSP, CCSA, CCSE, CCNA, MCSE Information Security Engineer Honeywell International Global IT Security & Systems Assurance Email: brandon.youngat_private Voice: 480.592.3988 Intranet: http://itg.honeywell.com/secarch ----------------------------------------------------------------- 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 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 Mar 13 2002 - 12:06:53 PST