RE: Simple Windows incident response methodology

["sunzi" <sunzi () mod-x com>]

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

> -----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.