Re: Simple Windows incident response methodology

[Matthew Pope <mpope () teksavvy com>]

sunzi wrote:

> All,
>
> I had previously released a very simple batch script for a security group
> using the most common analysis tools used by the community. It's a very
> simple script that simply runs a series of commands and dumps them to text
> files for someone else to analyze. It was written with non-techies in mind,
> so they can simply turn a floppy full of info into there support people for
> analysis.
>
> Since then the group/website has changed many times, so I am reposting the
> tool here: http://jjhicks.com/. There is a link right on the main page.
>
> There are changes to be made, but it hasn't been my priority for a long
> time, so before someone says they'd like to pump the info to a
> netcat/forensic server, it's in the ToDo list :)
>
> Also, the tools take a great deal of space on the floppy, so this setup is
> probably best for desktops scenarios, not servers. For use on a server, I'd
> suggest burning to CD leaving an entire floppy for log files.
>
> The beauty of using a solution like this before serious forensics is that
> you get to see what was actually happening on the system before you tell the
> client to pull their network cable/turn the box off.
>
> As always, comments and suggestions for mods/improvements are welcome.
>
> cheers,
> sunzi
>  
I'm not sure if it was in this thread, or another, but someone mentioned 
the INSERT CD (open source) for forensics recently.  I'd like to second 
that mention, and let folks know I and my colleagues have successfully 
used this KNOPPIX based distribution which includes the list of 
applications mentioned here:  
http://www.inside-security.de/applicationlist.html

Their is a binary giving the ability to CHANGE ADMINISTRATOR PASSWORD on 
an NTFS SAM file. This is also a particularily useful feature to gain 
entry to Win2K, WinXP system if you say lock yourself out.

A hyped feature useful to some is that the INSERT CD entire 50 MB ISO 
fits on a credit card sized CD you can keep in your wallet.  Sounds a 
little James Bond-ish.  Anyway, the well designed system has almost 
every binary you might want, and since it uses a RAM disk, the hard disk 
on the system being investigated can remain untouched.
Matthew

>  
>
> > -----Original Message-----
> > From: Harlan Carvey [mailto:keydet89 () yahoo com]
> > Sent: Friday, June 11, 2004 10:31 AM
> > To: incidents () securityfocus com
> > Subject: RE: Simple Windows incident response methodology
> >
> >
> >
> >    
> >
> > > 1)  I'd also like to hear from people who have more
> > > extensive experience
> > > with NT rootkits - will the methodology I gave find
> > > most of them?  What
> > > are exceptions?   What tools *should* be used in
> > > that instance?
> > >      
> > I did some testing with AFX Rootkit 2003 for my book,
> > and I'm planning more extensive tests on other
> > available rootkits in the near future.  From my
> > experience, no, your methodology will not detect the
> > presence of rootkits.  What you should have is
> > multiple disparate tools to collect information
> > (pslist AND tlist AND handle AND listdlls AND
> > openports, etc) from a system, and then do some sort
> > of anomoly-based detection (ie, w/ AFX, the PID for
> > the 'hidden' process was visible in one tool, and not
> > another).
> >
> > I think the biggest thing is that while your
> > methodology is very good for most things, it's all
> > about data collection...nothing is really mentioned
> > with regards to analysis.
> >
> >    
> >
> > > 2)  I'd also like to hear from people on expanding
> > > out the "analysis"
> > > phase - for example, comparing results from fport to
> > > netstat,
> > >      
> > That's easy.  Perl.  Parse the output files, dumping
> > the contents into data structures.  When comparing the
> > process lists retrieved by pslist and WMI, I dump
> > everything into hashes of hashes, w/ the PIDs as the
> > primary keys.
> >
> >    
> >
> > > how do you
> > > examine listdll output and know if there are kernel
> > > hooks that shouldn't
> > > be there, etc.  I know how to do it informally but
> > > haven't written it down.
> > >      
> > Well, the first step is to write it down.  This one is
> > kind of fun, too, b/c it's easy.  Create a flat file
> > containing "known good" entries from "clean" systems.
> > Use these as the exceptions.  Write a script that
> > pulls the module information from the Explorer.exe
> > process (for example), and parse out the exceptions
> > while suppressing the known goods.
> >
> >
> >
> >    
>
>
>  



---------------------------------------------------------------------------
Free 30-day trial: firewall with virus/spam protection, URL filtering, VPN,
wireless security

Protect your network against hackers, viruses, spam and other risks with Astaro
Security Linux, the comprehensive security solution that combines six
applications in one software solution for ease of use and lower total cost of
ownership.

Download your free trial at
http://www.securityfocus.com/sponsor/Astaro_incidents_040614
----------------------------------------------------------------------------