It's pretty well known, in memory forensics circles, that there are two common ways of finding processes in memory images:
list-walking, which traverses the kernel's linked list of process data structures, and
scanning, which does a sweep over memory, looking for byte patterns that match the data found in a process data structure.
Having two different ways of finding processes can be very handy, especially when we suspect that someone may be trying to hide processes. One common way of hiding processes in Windows is called
DKOM (Direct Kernel Object Manipulation); this technique works by just unlinking the process you want to hide from the kernel's list, like so:

This makes it invisible from programs such as the task manager, as well as memory forensic tools that use list-walking (including Volatility's pslist). However, such hidden processes can still be found by scanning memory using a signature for the process data structure; this is what psscan2 does.
Unfortunately, it's been known since at least 2007 (as mentioned in
AAron Walters and Nick Petroni's Blackhat DC talk, and more recently in a
presentation by Jesse Kornblum) that even signature scans can be evaded by crafty attackers. Signatures typically rely on "magic" values found in the process data structure. For example, in Windows XP, process data structures always begin with "
\x03\x00\x1b\x00", which makes it pretty easy to find them in memory images.
But is that magic value really essential to the correct functioning of a process in Windows? What if an attacker just overwrites those four bytes with zeroes? As it turns out, Windows will be perfectly happy to keep running the process! At the same time, it will be completely hidden from existing forensic tools. What's more, as I demonstrated in my paper for CCS 2009 (
Robust Signatures for Kernel Data Structures), around 51 fields in the process data structure can be manipulated by attackers in this way – including nearly all of the fields currently used to find processes.
So what's a forensic analyst to do? Luckily, there are some parts of the process data structure that are hard for an attacker to mess with without causing one of these:
So if we can build a signature based on these fields, we can find processes that existing signature scanners might miss.
And that's just what I've done. Here, for your consideration and consumption, is the creatively-named
psscan3 (just drop it into the memory_plugins directory of Volatility 1.3.2). It uses a only fields that have been identified as "robust" to locate processes in Windows memory. It's a bit slower than the existing scanners, right now, because it's checking for more things.
If you want to try it out, you might also want to download this
sample memory image, which has a hidden process at offset 0x01a4bc20. In Volatility, pslist, psscan, and psscan2 all miss the process, but psscan3 detects it, as shown in this exciting screenshot (click to enlarge; the windows show, from left to right, psscan, psscan2, and psscan3) [EDIT: Blogger is for some reason refusing to link to the larger size; click
here to view it]:

If you'd like a copy of the rootkit that hid this process (which is based on the
FU Rootkit), send me an
e-mail (but be warned that I probably won't be able to dig up the source until this fall).
So that's it! If you want to find out more about what went into this plugin, you're encouraged to check out my
paper, or browse the
slides from the talk at
CCS 2009.