RE: NKADM rootkit - Something new?

• Previous message: Harlan Carvey: "Changing file times, was -> Re: Trojan of somesort - Update"
• In reply to: Don Wolf: "RE: NKADM rootkit - Something new?"
• Next in thread: Gadi Evron: "Re: NKADM rootkit - Something new?"
• Reply: Gadi Evron: "Re: NKADM rootkit - Something new?"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

Date: Fri, 28 May 2004 04:36:17 -0700 (PDT)
To: incidents@securityfocus.com

Don,

> " Linux distros are... useless on Windows systems
> for gathering volatile data"
>
> Harlan, you're absolutely right. Anyone with enough
> forensic, IR or even
> data recovery experience knows maintaining state is
> critical. If you change
> the state (e.g. reboot) than you've effectively lost
> any chance of
> recovering meaningful information. This more so in
> the context or tracking
> hacks than recovering client data.

You're quite right. Aside from the fact that many
files are 'touched' during a reboot, you effectively
loose the contents of physical memory. If you have a
RAT (remote access Trojan, or backdoor) installed w/
someone actually connected to it, the reboot forces a
disconnect. This won't necessarily be the case w/ a
'bot (that makes outbound connections to an IRC
channel), but again, you're loosing other
things...running processes, etc, etc. This data needs
to be recovered prior to the system being shut down.

On a side/tangential note, I've had discussions
regarding the collection of the contents of physical
memory. While I've heard that it's been desired or
recommended, I fail to see the value of using a tool
such as dd.exe to dump the entire contents of
RAM...how would you then parse it apart into anything
usable. My recommendation would be to use tools such
as pmdump.exe to dump the memory contents of specific
processes to a USB-connected thumb drive...that way,
any information found via 'strings' could be easily
associated w/ a particular process.

> An option - Virtual sessions of Linux (Knoppix,
> Insert, etc) may be possible
> on a Windows platform. Without any extensive
> knowledge of those bootable CD
> OSes, I cannot say that it would work, but it would
> certainly be of more use
> in forensic data recovery or incident response on
> Windows platforms.

Perhaps...if you could get it to work. I think that
there're enough Windows tools available to do what
needs to be done on Windows systems.
 
> The approach of using a handful of tried and true
> tools is arguably the most
> logical and productive method. If having all the
> tools on-hand in a nice
> neat package is a concern (seems to be in this
> thread), burn them all to CD
> and create some non-intrusive scripts to run them.
> I've consolidated a
> number of tools in my time that I've put to CD's and
> flash. Furthermore
> I've been working for the last few months to
> determine what method of
> running these tools would yield the best results
> with the least impact.
> This has led to a number of both complex scripts and
> rudimentary scripts.
 
I've been working on the same thing, which led me to
come up with the Forensic Server Project, which is
detailed on Chapter 8 of my upcoming book ("Windows
Forensics and Incident Recovery", from
Addison-Wesley).

A lot of the literature having to do w/ the collection
of volatile data from live systems involves
*nix/Solaris platforms, and the use of 'netcat' as a
vehicle for piping the output of command line tools
off of the "victim" system, through a socket, and onto
a waiting forensic system. This is an excellent
method for minimizing the impact on the "victim"
system, as with scripting, a great deal of information
can be collected very quickly.

The only drawback to this method is documentation.
Most of the sources (ie, Mandia/Prosise, etc)
recommend maintaining a notebook, in which the
commands you issue are written down and verified
before launching by a second person.

The Forensic Server Project is an open source (Perl)
framework for automating the collection of volatile
(and non-volatile) data from systems. This FSP breaks
the process down into two separate steps...data
collection, and data correlation/analysis. The client
components of the FSP, such as the First Responder
Utility (FRU), are burned to CD along w/ the Perl
distro and necessary third-party tools (note: Due to
problems faced by others in getting permission to
redistribute the third party tools, none of them are
included on the CD accompanying my book - links are
provided to all of the tools). The first responder
places the CD containing the FRU into the CD drive of
the system, opens the appropriate copy of cmd.exe from
the CD, and launches the FRU. All the first responder
has to do is enter the IP address and port of the FSP
server, and hit "GO"...the rest is handled
automatically, removing the first responder from
having to remember and retype commands (highly
repetitive, and subject to error). The FRU notifies
the first responder when it has completed it's
task...at which point the first responder kills the
process and removes the CD.

On the server side, the investigator simply launches
the FSP server and waits. Some information regarding
the investigator's name is entered into the GUI and is
added to the case log file. As the FSP server
receives data from the FRU, it logs it to the case
log, and generates hashes for each file it creates.
The tools used by the FRU are all command line tools,
meaning that the information they collect would
usually appear via the command prompt...so this info
is piped out over a socket (nothing is written to the
drive) to the server, where it is stored.

If the first responder chooses to use another client
to collect files from the "victim" system, the FSP can
be used to completely automate the entire process:
collect MAC times, etc, and generate hashes; copy the
file; compare/verify hashes on the server.

Again, all of the activity is logged and time stamped
on the server.

Finally, the investigator can use a variety of scripts
to correlate and analyze the data collected. For
example, multiple tools are used to retrieve process
information from the victim system. This process
information can then be correlated and any disparities
identified...this has been shown to detect the
presence of the AFX Rootkit 2003.

The client utilities such as the FRU are quick and
efficient. Of course, there is always work that can
be done, but I believe that this framework is a good
start. I've been working on other tools
(anomoly-based rootkit detection, etc), which will be
appearing on the web site for the book:
http://www.windows-ir.com

Comments regarding anything I've written here are very
much appreciated. I think the best way we can go
about improving what we do is through discussion.

Thanks,

Harlan

• Previous message: Harlan Carvey: "Changing file times, was -> Re: Trojan of somesort - Update"
• In reply to: Don Wolf: "RE: NKADM rootkit - Something new?"
• Next in thread: Gadi Evron: "Re: NKADM rootkit - Something new?"
• Reply: Gadi Evron: "Re: NKADM rootkit - Something new?"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]