Memory acquisition traps
Last Updated: 2013-01-03 09:39:29 UTC
by Bojan Zdrnja (Version: 1)
Last week at the CCC conference in Hamburg, my colleague Luka Milkovic presented his work on memory acquisition tools. The presentation’s PPT is available at http://events.ccc.de/congress/2012/Fahrplan/events/5301.en.html
Since memory acquisition is becoming increasingly popular in any incident forensics, I think it is very important for every incident handler to be aware of deficiencies in this process.
So how does the memory acquisition process work? Once executed, all memory acquisition tools (see slide 17 on the presentation) install a driver to get kernel access through it and then start reading memory and either dumping it to a file or over the network.
Now, the above mentioned slide 17 shows another interesting thing – you can notice that all memory acquisition tools (except Win32DD) create buffers in user space. In other words, it is relatively simple for an attacker to inject into these tools and mess up with their output! Further, apart from Win32DD (which can also be attacked, but it is a bit more difficult) all other well known memory acquisition tools are doing it wrong.
There have already been other presentations about attacks on memory acquisition tools, so Luka created a PoC tool (should be released soon) called Dementia that allows one to hide any currently active process. The tool monitors buffers containing memory addresses to be written and if a memory address of a process that is to be hidden is detected, the tool simply overwrites that memory space with zeroes.
The Dementia tool runs completely from user mode and requires no kernel drivers – this allows it to subvert all those most popular memory acquisition tools that store buffers in user mode (FTK Imager, MDD, Memoryze, Winen ...) – the only requirement are admin rights since the tools need them as well. Keep in mind that Win32DD can be attacked as well, but it requires a kernel driver since the attacker needs to be able to modify kernel buffers.
So what can we do? Not much unfortunately. As the first step the tools mentioned above should be fixed to utilize drivers correctly (i.e. all buffers in kernel mode, and not user mode). We could also use other acquisition methods such as memory dumps over Firewire, but that might be difficult with servers since they normally do not have Firewire interfaces. As Luka also mentioned, we could rely on crash dumps since they are much more difficult to tamper with (but not impossible).
And of course – if nothing else, just be aware that we cannot (completely) trust acquired memory images.
For a kernel level rootkit it is always possible to show the examiner a completely different memory image than what is actually there, except maybe if you freeze the RAM and read it out on another device. And I'm not even talking about a hypervisor / blue pill style rootkit but "ordinary" ring0 rootkits.
But it was a great talk, well done, Luka!
Jan 3rd 2013
1 decade ago