On the viability of memory forensics in compromised environments

Viability of Memory Forensics

A pretty cool paper was written up in 2015 regarding the viability of memory forensics in compromised environments - aptly titled: On the Viability of Memory Forensics in Compromised Environments. You can find the paper at https://pdfs.semanticscholar.org/6d26/be83b674231a301e7bed762895f14e613f66.pdf

Fundamentally, this comes down to can you trust an owned box - I put forward that you probably can under some circumstances, and not at all when an attacker is competent. Luckily for me, this paper gives me some (formal) backing, rather than intuiting that an attacker controlled machine is no longer your machine, and the integrity of code on the machine is no longer certain.

Or less formally, it’s not your machine when someone else owns it - it’s running whatever they want, and your splunk agent probably isn’t reporting back what you’d want it to.

The paper

There’s probably some fashion in how someone cites academia, I’ve got no clue, but it looks like it’s written as a thesis paper by Johannes Stuettgen - That’ll have to do. If it appeals to anyones authority - he thanks the Google Incident Response Team for their working environment, so the guns over there probably provided some insight at the least.

The abstract describes:

• We tested 12 memory forensics tools
• All of them were vulnerable to anti-forensics (i.e. Malware hooking API calls)
• This happens because you’re trusting the operating system to provide functions to read memory
• We avoid this entirely by interacting with hardware via PCI

Quoting Chapter 5, section 1:

To become more resilient against anti-forensic attacks, memory acquisition software must stop relying on the potentially subverted OS to perform its task.

Johannes nails it here - you’re trusting a box running unknown code to tell you it’s running unknown code, but comes up with this idea around mapping memory without asking the OS to do it.

I didn’t consider the approach in Chapter 5 previously - it comes down to the difference of asking the kernel to map memory for you and mapping the memory yourself via interacting with PCI. Apparently this is harder to hook, and isn’t a thing people are looking for, so it’s probably hard for an attacker to figure out it’s happening.

This technique has been put in winpmem since 2014, thanks to the author.

The author does note however, that this relies on loading a driver - perhaps this is a thing an attacker should be aware of.

I don’t know what the solution is - hardware based acquisition (cited but not explored here), is hard to roll out. I’ve managed to hot-plug PCIe devices into my desktop, but I don’t know if that works everywhere, or if its even a good idea; so you’re still up a proverbial creek when it comes to doing this at scale. I did learn that if you communicate straight to the PCI bus, you’re gonna have a better time than trusting the OS, but I’m still unsure of how much you can trust the machine.

Again, go check out the paper - https://pdfs.semanticscholar.org/6d26/be83b674231a301e7bed762895f14e613f66.pdf