Re: Encase and data recovery

From: Matthew.Brownat_private
Date: Tue Mar 12 2002 - 10:54:50 PST

  • Next message: Andrew Falanga: "Re: Keylogger Needed Quick!"

    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 archive was generated by hypermail 2b30 : Tue Mar 12 2002 - 11:49:17 PST