[Vol-users] 29c3 defeating windows memory forensics
milkovic.luka at gmail.com
Tue Jan 8 14:07:41 CST 2013
first of all, thanks for your support:)
> For example, I have done a workshop at the open source
> digital forensic conference demonstrating among other things how
> Volatility can be easily defeated on a live system. For educational
> purposes, I have added write support to the winpmem memory acquisition
> tool which allows volatility itself to write to arbitrary physical
> memory. Since Volatility is really good at finding the artifacts,
> turns out its also really good at manipulating these artifacts :-).
Very cool, I already saw that some time ago and it's a very nice intro
and walkthrough for Volatility.
> On 7 January 2013 20:52, Luka Milkovic <milkovic.luka at gmail.com> wrote:
> > KM/KM paradigm used ONLY by win32dd is better in many ways:
> > 1. Buffer never leaves the kernel space - attacker cannot attack it
> > from the user-mode
> It is true that the image is written from kernel mode, but a kernel
> mode rootkit can easily intercept the kernel functions just like in
> usermode. Usermode hooking can still be used to intercept the IO
> control which triggers acquisition (for example some acquisition modes
> are easier to subvert and a user mode tool can still force these to be
> used by hooking the io control command).
The only thing that currently really puts both paradigms in more or
less equal positions from an attacker's perspective is that you need
admin privileges for UM injection/hooking, because the acquisition app
itself needs admin privs.
But there are other techniques available in UM that could subvert the
correctness of the process and attack acquisition applications from a
less privileged account.
For example, I made some quick test for binary planting
vulnerabilities and almost all acquisition tools that I tested are
vulnerable to binary planting. Winpmem is actually the only tested
tool which is not vulnerable to binary planting, while Memoryze and
OSForensics have large number of such vulnerabilities.
I don't consider BP such a big issue here (although it is not
something that should be completely ignored), but it further supports
"KM is better" theory I'm advocating.
Of course KM is not a complete solution, but the attack surface is
As a side note - Volatility on Windows is also searching for DLLs and
Python code in the current directory first. I wonder if someone made a
> > 2. Buffer never leaves the kernel space - no performance overhead of
> > communicating with the driver, copying the memory back to user-space
> > (or not, depending on the method used, but then you have additional
> > probes of UM buffer etc.)
> Our measurements show that buffering between kernel and user space
> does not have a very significant impact. In particular, the linux pmem
> driver does support direct mmap implementation (bascially its an mmap
> into physical memory), but in practice there is no measurable
> performance difference. I believe that on windows it is also possible
> to set up direct MDL mappings into userspace which simply avoid any
> copying between kernel and user space. I never spent the time to
> investigate this since I am not seeing significant performance gains
> when comparing winpmem to win32dd.
My measurements using the same buffer sizes (when applicable, I cannot
use arbitrary buffer length for all tools) show that the difference is
around 5% , which I agree is not noticable and definitely not a
significant performance gain.
What makes a bigger difference is the size of the buffer itself. Many
tools are using PAGE_SIZE as the buffer size, win32dd and winpmem are
one of the rare tools that are using big buffers by default (and I
think that's a good thing). Difference can then be even up to 100%.
I have not proved this assumption, because some other variables could
influence the speed of the acquisition and I didn't reverse engineer
every single driver to see which transfer methods and acquisition
methods are being used.
> > 3. Logging and/or encryption methods done in KM-only are again much
> > safer than doing it in user-mode (you mention it later in your answer)
> That depends on your frame of reference. Safer is only a relative
> term. To an attacker which already owns kernel space it is the same
> amount of work to hook a kernel module or a user space program.
I agree, but as I said, to an attacker who "owns" the acquisition tool
in user space (via binary planting or some other methods), access to
kernel space might be much harder.
> > It does not solve the problem, as I have demonstrated, but I think it
> > is simply unnecessary and worse approach to transfer the buffer back
> > to user-mode and then write it to dump.
> I disagree. Passing the buffer back to userspace makes user mode
> processing much simpler and more reliable since you do not need to do
> much processing in kernel space. For example, it is possible to run
> Volatility directly on the live system without taking an image first,
> for a quick triage of the system - this is faster and more efficient
> than taking a full image if all we want is to search for specific
I agree with you completely regarding reliability and simplicity, but
I'm still not so convinced about the security. At least you make it
one bit harder for an attacker (who also has the same reliability and
simplicity issues in his driver:) ).
> In practice it is trivial to encrypt/obfuscate the data between kernel
> and user space which makes manipulating these buffers from userspace
> by Dementia more difficult without intimate knowledge of how the
> specific acquisition tool works.
> The real challenge for Dementia the way I see it is to be able to
> identify the DFIR tool in order to interfere with it.
It worries me that many infosec specialists (not necessarily forensic
experts) use acquisition tools without even minimal precautions - they
download the tool, put it on the USB stick and run the tool as-is,
without even renaming it. Detecting the acquisition application by its
name is one of the first filters used by Dementia and it is as dumb as
There are plenty of ways to detect DFIR tool, you mentioned some of
them and George gave a link on Peter Kleissner's whitepaper. I'm
thinking about implementing some of them, but don't have the time at
It's heuristics in the end, and you're dead right that some commercial
applications are much less flexible here.
> For example, by breaking the
> system in such a way that any acquisition tool fails to work at all -
> this can get the responder to be pretty sure the system is owned, but
> they still can not acquire the image or evidence. Coupled with a
> really good persistence mechanism (so its hard to locate the malware
> on disk) and most responders will just rebuild the box and move on.
:) When I was thinking about writing tool like Dementia, a friend of
mine told me it's completely useless to create such tool:) His opinion
is that a tool which detects an installation of DFIR app driver or
launch of DFIR application and immediately crashes the machine or
reboots it (via HalReturnToFirmware or smth) is even more effective
then Dementia-like tools:)
This should not be suspicious to analyst, because he would think that
the application itself is causing the reboot.
> We must consider the possibility that our own tools and techniques are
> used against us - those artifacts that you are finding using
> Volatility (and other tools) can also be found by the bad guys and
> cleaned up just as easily. It is an arms race :-).
Actually, I was thinking about utilizing Volatility to work for me in
Dementia's hiding job - Volatility would detect the artifacts and I
would just need to remove them from the dump.
I abandoned this idea since I would need to sanitize the buffers on
the fly and would need to hack Volatility significantly. I'm not a
good Pyhton developer, so that would take some time:)
> Anyway, thanks Luka for an interesting talk and a nice discussion.
Thanks to you also Michael, it was an interesting discussion:)
More information about the Vol-users