8:42 p.m.
Hi George, and everyone else on the list.
I don't know if you watched/skimmed through the presentation or the talk,
but I want to emphasize that I really like Volatility and that my work is
not a research against Volatility (or any other tool in particular) in any
way.
Volatility is my primary choice when doing memory analysis both because of
speed, abundance of features and plugins and openness of the tool.
I do however mention Volatility in couple of places, for example, I suggest
creating a plugin for scanning handle table allocations (Obtb) as an
alternative to currently used method.
It is nice to see someone looking critically at the
subject matter, even
if in an over-simplistic manner. The gist of the article is that you
can easily scrub evidence from a memory dump as it is being written (in
plain text) to disk or to the net. Duh!
Thanks for your support.
Although I agree some things were over-simplified, I don't agree that my
research in whole is over-simplistic.
The idea is simple and well known enough, still, it is not that commonly
being taken into consideration when performing forensic analysis, at least
from my experience.
A few comments on the author's conclusions:
Too bad you pulled out the conclusions since this slide is by far the
weakest in the whole presentation;)
1. Acquisition tools should utilize drivers correctly!
Duh!
I didn't quite understand if you meant that ironically or not. However,
almost all tested acquisition tools utilize drivers incorrectly, meaning
that they transfer the pages back to UM and then write them to dump (usually
with completely inadequate permissions).
2. Use hardware acquisition tools, e.g. firewire.
However, hardware-based acquisition also can be
defeated. At a minimum
you can program an upper limit on the memory address that the firewire
is allowed to access and then place your rootkit above that address.
Most new computer systems have more than 4 GiB of memory nowadays.
I didn't say that hardware acquisition methods are infallible. You're
absolutely right regarding the 4 GB limit. But from an attacker's
perspective, this method cannot be used for hiding arbitrary object, and it
might be difficult to "relocate" the driver, allocations and all resources
above the specified limit.
I'm evaluating some additional weaknesses of the firewire acquisition and
methods of hiding arbitrary objects, but so far, my research showed no
progress...
And yes, I am definitely aware of other alternatives (cold boot etc.), but I
think they are highly impractical so I didn't mention them in my
presentation.
3. Use crash dumps (native!) instead of raw dumps.
Should maybe introduce the author to all those
rootkits (e.g. Sinowal)
that remove themselves from crashdump as it is being written.
I thought that I have a very good knowledge of rootkits and low level
malware, but I don't recall Torpig/Sinowal doing anything about removing
itself from the crash-dump.
In fact, I cannot remember any rootkit or malware removing its artifacts
from the crash-dump, so please introduce me to all such rootkits:)
There are some KeBugCheckEx() tampering "malware" variants, but they are
mostly related to PatchGuard bypass.
Crash dump mechanism is fairly complex, involves couple of checksums and
does not use the underlying file system - it writes the dump to raw disk
sectors.
The weakest link in this process from my perspective is the process of
booting the machine and calling of SmpCheckForCrashDump() function - this is
the point when malware can finally see the resulting crash dump and remove
the artifacts from it.
This is far from being trivial, however.
4. Perform anti-rootkit scanning before acquisition?
Easier said than done. Just ask A/V industry.
This is a stupid conclusion on my side. No, really, I said that during the
talk:)
5. Live forensic is inherently insecure!
Duh! Real question is not whether or not you can
cheat memory
acquisition software. It is whether you can cheat memory acquisition
software and have no one know about it. Knowing that a system is
infected is 90% of the battle even if you don't know how. Once I know
that a system is infected I will find the rootkit.
My talk was all about cheating the memory acquisition software and have no
one know about it:)
It's not that my tool is invisible - the truth is actually totally opposite
ON PURPOSE.
I didn't want to add advanced self-hiding features, because I'm not trying
to create a tool that bad guys can use in the wild. I just wanted to raise
awareness and present my research.
And again, it depends on what you are trying to find:) If you're trying to
find _traces_ of malware (mostly orphaned or invalid resources, such as
locks, mutants etc.), you will most certainly succeed in this, because by
theory it is impossible to hide everything (the malware executes, therefore
it is present and visible).
If your goal is to find some more valuable artifacts (processes, memory
allocations, files, etc.), you might fail even if you are certain in rootkit
existance, simply because the rootkit (or my tool in this case) has deleted
such artifacts from the dump.
In the end, I really don't want to be perceived as a guy wearing a wrong
hat. My research is not aimed against any particular product, or the memory
forensics field in general. My research is not a revolutionary new
anti-forensic method. It's an implementation of well known anti-forensic
techniques and proof of concept for removing arbitrary artifacts from the
memory dump with the intention of raising the awareness and creating better
memory forensics software.
Best regards,
Luka
--
Luka Milković
Information security consultant
e-mail: luka.milkovic(a)infigo.hr
INFIGO IS d.o.o.
Horvatovac 20, 10000 Zagreb
www: http://www.infigo.hr