Re: NKADM rootkit - Something new?

[Harlan Carvey <keydet89 () yahoo com>]

> You mean overwriting deleted but not erased files?
> Probably, but how
> relevant is that for the given case of determining
> whether (and how) a system was compromised?

Good point.  But using that same logic, what's the
point of doing a memory dump at all?  Why not examine
volatile data and audit log information instead?  Why
go through the entire process of forcing a memory dump
at all?

> Agreed. OTOH there is the problem of a rootkit
> manipulating the data
> requested by tools running on the compromised system
> itself (or at least
> requesting data from it). Harlan described how one
> could use tools or
> scripts to log the data to a remote host, but how
> trustworthy would that data be?

Well, it depends.  How many rootkits have you worked
with and studied, particularly on Windows systems? 
I've taken a look at some, and found so far that by
using a methodology in collecting data, most of that
information can be trusted. 

For example when I was looking at AFX Rootkit 2003, I
used both pslist.exe (SysInternals) and tlist.exe
(from the MS Debugger tools) to dump process info, and
I also used openports.exe.  The rootkit was found by
one process enumeration tool and not by the other. 
Openports did find the backdoor installed w/ the
rootkit.

The issue I see is that too many people are playing
and pretending in the security field.  It's very easy
to sit back and say "well, what if a rootkit does
this", or "what if a rootkit does that".  What we
really need is more people to document a testing
methodology (for peer review) and then actually
perform the testing.  I've started some of this and
would be more than happy to discuss testing
methodologies off-line w/ interested parties.

The other thing that needs to be done is that people
handling incidents and seeing actual manipulation of
DLL files need to speak up.  DLL injection aside, if
attackers are actually replacing DLL files on systems
and actively circumventing protections like WFP, then
the security community at large should hear about it.

Again, it's easy to sit back and speculate at what
could be done.  Ultimately, such things only lead to
inactivity, b/c eventually, anything you could do with
regards to incident response and forensics will be
overcome by a "well, a hacker could..."