Re: Steps on how to handle an infected computers ( in forensicsperspective)

[John Morrison <john.morrison101 () gmail com>]

As a first point try a search using the terms
        computer forensics first steps

This should throw up some useful results. For example, I found
Computer Forensics A Short Introductory Guide
(www.sapphire.net/downloads/ForensicsWhitePaper.pdf)

On 27 July 2010 21:40, Sacks, Cailan C <Cailan.Sacks () standardbank co za> wrote:
> Well I guess this depends on your role and the desired outcome from the investigation.
>
> Pulling the power chord, or removing a network connection is deemed changing the state of the machine in any court of 
> law you wish to present any acquired evidence to, however, this does not mean that removing the network cable or 
> power cord is not the best step at this stage.
>
> As long as you have a sufficient chain of evidence, and a properly document process of the manner in which the 
> malware was isolated, and analyzed without being directly tampered, you will not have any issues in court.
>
> Acquiring network images, performing logins, or even waking a machine up from power save, is a change in state. You 
> just have to prove that your change in state did not directly affect the evidence presented.
>
> My advice with regard to malware is to capture the contents of the RAM to a separate destination(that you have signed 
> as sanitized in your chain of evidence), and then pull the power chord. Most of your evidence will exist in the 
> windows page file as at some stage RAM will be paged to disk (hence the pull power, not shutdown).
>
> Analyzing the malware thoroughly seems a no brainer, but pay some attention to the rest of the log files ensuring 
> that you can prove that the malware was not placed there by user "X" pretending to be user "Y". Also, spend some time 
> putting together a forensic report that will suite the purpose. Your IT Manager will want to know the technical bits, 
> however your CEO wont. On the same token your lawyer will want to know everything, and the defense lawyer will 
> challenge everything. If your report covers all bases, you leave the defense lawyer with very little to use as 
> "reasonable doubt" in court.
>
> I.E.
> Bad report:
>        Malware "X" was uploaded by user "a123" at 12:00am
> Good report:
>        Malware "X" was uploaded by user "a123" at 12:00am. There were 2 active connections at the time of the event 
> (appendix "A"), 1 by the domain network script running commands "Y" (see appendix e), and the other by IP address "Z" 
> which was owned by user "a123" (Appendix B - Logs from network owner/ISP/etc). IP Address "Z" was traced to machine 
> "C" which had "P" evidence....blah blah blah. Conclusion is user "a123" should have his hands chopped off in a public 
> forum while his defense attorney tries to enter a plea bargain on his behalf.
>
> Malware analysis is a very specialized field. Capture the disk, and work of a copy of the original image. Monitor 
> network traffic on an imaged machine. Enlist the help of AV if the malware is undocumented, and if documented, they 
> usually share some info if you ask nice enough.
>
> -----Original Message-----
> From: listbounce () securityfocus com [mailto:listbounce () securityfocus com] On Behalf Of Rivest, Philippe
> Sent: Tuesday, July 27, 2010 9:19 PM
> To: Ansgar Wiechers; security-basics () securityfocus com
> Subject: RE: Steps on how to handle an infected computers ( in forensicsperspective)
>
> My expertise in forensic is really limited, but i believe that pulling the
> power cord at that step is unwise as you will basically be throwing out the
> window a lot of data and information's.
>
> Shouldn't he get access to the memory b4 flushing the power cord?
>
> Also, I get that unpluggin the system from the network is wise to protect
> both the system & the network. But wont you effectively change the state of a
> machine when you want to capture the machine in the "bad state". Shouldn't he
> pull the power cord b4 the network cable?
>
>
> My reading of the TCT is a way back, so please forgive me if I'm wrong here.
>
> Btw - My first step would be to call an expert & read on my corporate policy
> & procedure ;)
>
>
>
> Philippe Rivest - CISSP, CISA, CEH, Network+, Server+, A+
> TransForce Inc.
> Internal auditor - Information security
> Vérificateur interne - Sécurité de l'information
>
> 8585 Trans-Canada Highway, Suite 300
> Saint-Laurent (Quebec) H4S 1Z6
> Tel.: 514-331-4417
> Fax: 514-856-7541
>
> > > Web Site
>
>
>
>
>
> -----Original Message-----
> From: listbounce () securityfocus com [mailto:listbounce () securityfocus com] On
> Behalf Of Ansgar Wiechers
> Sent: 27 juillet 2010 13:40
> To: security-basics () securityfocus com
> Subject: Re: Steps on how to handle an infected computers ( in
> forensicsperspective)
>
> On 2010-07-27 Raja wrote:
> > Can anybody provide me good practicable steps on handling a malware
> > infected computer?
>
> First and foremost: remove the computer from the net immediately.
>
> After doing that you have to decide if you want to do a first analysis
> from within the running system, or directly switch it off. Analyzing the
> running system has the advantage that you may gather information about
> the infected system (running processes, open ports, established
> connections, ...), but also has the disadvantage that malware may detect
> your activities and start wiping its tracks or counter your analysis.
>
> Regardless of whether or not you do a live analysis, your next step is
> to switch off (as in "unplug the power cord") the computer. That is to
> prevent the malware from altering the system during shutdown.
>
> After that you image the hard disk(s), and do any further analysis on
> compies of that image, so the original data will remain unchanged. It's
> advisable to create an isolated lab environment for this kind of
> analysis.
>
> The actual analysis (i.e. which tools to use, where to look, and what to
> look for) will depend on what operating system the infected system is
> running and what symptoms it was showing.
>
> Regards
> Ansgar Wiechers
> --
> "All vulnerabilities deserve a public fear period prior to patches
> becoming available."
> --Jason Coombs on Bugtraq
>
> ------------------------------------------------------------------------
> Securing Apache Web Server with thawte Digital Certificate
> In this guide we examine the importance of Apache-SSL and who needs an SSL
> certificate.  We look at how SSL works, how it benefits your company and how
> your customers can tell if a site is secure. You will find out how to test,
> purchase, install and use a thawte Digital Certificate on your Apache web
> server. Throughout, best practices for set-up are highlighted to help you
> ensure efficient ongoing management of your encryption keys and digital
> certificates.
>
> http://www.dinclinx.com/Redirect.aspx?36;4175;25;1371;0;5;946;e13b6be442f727d
> 1
> ------------------------------------------------------------------------
>
>
> ------------------------------------------------------------------------
> Securing Apache Web Server with thawte Digital Certificate
> In this guide we examine the importance of Apache-SSL and who needs an SSL certificate.  We look at how SSL works, 
> how it benefits your company and how your customers can tell if a site is secure. You will find out how to test, 
> purchase, install and use a thawte Digital Certificate on your Apache web server. Throughout, best practices for 
> set-up are highlighted to help you ensure efficient ongoing management of your encryption keys and digital 
> certificates.
>
> http://www.dinclinx.com/Redirect.aspx?36;4175;25;1371;0;5;946;e13b6be442f727d1
> ------------------------------------------------------------------------
>
> Standard Bank email disclaimer and confidentiality note
> Please go to http://www.standardbank.co.za/site/homepage/emaildisclaimer.html to read our email disclaimer and 
> confidentiality note. Kindly email disclaimer () standardbank co za (no content or subject line necessary) if you 
> cannot view that page and we will email our email disclaimer and confidentiality note to you.
>
> ------------------------------------------------------------------------
> Securing Apache Web Server with thawte Digital Certificate
> In this guide we examine the importance of Apache-SSL and who needs an SSL certificate.  We look at how SSL works, 
> how it benefits your company and how your customers can tell if a site is secure. You will find out how to test, 
> purchase, install and use a thawte Digital Certificate on your Apache web server. Throughout, best practices for 
> set-up are highlighted to help you ensure efficient ongoing management of your encryption keys and digital 
> certificates.
>
> http://www.dinclinx.com/Redirect.aspx?36;4175;25;1371;0;5;946;e13b6be442f727d1
> ------------------------------------------------------------------------

------------------------------------------------------------------------
Securing Apache Web Server with thawte Digital Certificate
In this guide we examine the importance of Apache-SSL and who needs an SSL certificate.  We look at how SSL works, how 
it benefits your company and how your customers can tell if a site is secure. You will find out how to test, purchase, 
install and use a thawte Digital Certificate on your Apache web server. Throughout, best practices for set-up are 
highlighted to help you ensure efficient ongoing management of your encryption keys and digital certificates.

http://www.dinclinx.com/Redirect.aspx?36;4175;25;1371;0;5;946;e13b6be442f727d1
------------------------------------------------------------------------