Ben,
The only other thing I would like to mention is the
difficulty in
gathering a trustworthy image of physical memory. In
fact I would go so
far as saying that this is an impossibility so long
as the imaging
process relies on the host operating system. You
touch on this briefly
in Chapter 2, "Problems with memory acquisition
procedure", but fail to
note that the approaches you suggest (using dd or
the proof of concept
tools in idetect) can be circumvented by fairly
rudimentary kernel
space anti-forensics themselves.
You've hit the nail squarely on the head here, I
believe.
I contacted the author directly with regards to some
issues I saw, and though he thanked me for my
comments, he really didn't (and has yet to do so)
addressed those issues.
One of the issues in particular is that he starts off
by mentioning the FU rootkit and the SQL Slammer worm,
both of which are specific to Windows...and then
presents examples using only a Linux system. He
states in the paper that similar work can be done on
Windows systems, but never provided any information to
that effect.
Based on entries I made to my blog the other day, I
ended up having a conversation w/ someone from MS
about this very issue. The issue of using dd.exe to
image Physical Memory goes beyond the fact that there
don't seem to be any maps describing how physical
memory is used by Windows systems, and that memory
used by processes consists of both RAM and the
pagefile. Additional issues include, as you pointed
out, that while the imaging process is occurring, the
kernel memory (and even user-mode memory) is
changing...so what you end up with is a smear, for
want of a better term.
Even tools like pmdump.exe and LiveKD
(SysInternals.com) are not sufficient for collecting
user-mode memory, b/c they do not lock or suspend
memory.
The upshot is that in order to really capture a
snapshot of a Windows system, you need to cause a
crashdump. Properly configured, you can get a lot of
valuable information from this crashdump, as it will
contain the contents of kernel-mode memory. In
addition, the MS debuggers "understand" this
output...whereas the output of dd.exe is NOT
compatible with the debuggers.
This is not to take away from the rest of the
document which, overall,
is quite informative and probably applicable to the
vast majority of
Linux intrusions seen today, but I think this is an
important point to make nonetheless.
I fully agree...my intention is NOT to take away from
the author's efforts, but instead use them as a
starting point for additional work.
H. Carvey
"Windows Forensics and Incident Recovery"
http://www.windows-ir.com
http://windowsir.blogspot.com
------------------------------------------
Harlan Carvey, CISSP
"Windows Forensics and Incident Recovery"
http://www.windows-ir.com
http://windowsir.blogspot.com
------------------------------------------
