Detect hidden (unlinked) processes in memory

One of the many things that can be done with Volatility memory analysis framework is detecting hidden processes from physical memory dumps.

In Windows, there are two frequently used methods to hide a process, utilized by malicious attackers to hide key-loggers, rootkits, spy-ware, back-doors, etc. Each process is represented by an executive process block (EPROCESS) opaque structure, which is a process object existing in system address space. It contains a set of resources necessary to execute the program, like image base address, heap information, quotas.

Method 1:

Hooking the native system call NtQuerySystemProcess() used by most user-land processes to enumerate processes. Then, the desired process to be hidden can be filtered out and will not show for example in Task Manager or tasklist/pslist.

Method 2:

A lower level and more advanced technique is to manipulate the EPROCESS structure in kernel and unlink the desired process. Basically it works as follows: each process in the active processes list has two links, one forward to the next one and one backward to the previous one. Unlinking means modifying those, such that the process is excluded from the list.

pEProcess->ActiveProcessLinks.Blink->Flink = pEProcess->ActiveProcessLinks.Flink;
pEProcess->ActiveProcessLinks.Flink->Blink = pEProcess->ActiveProcessLinks.Blink;

The method was developed and presented initially by Jamie Butler (co-author of the book “Rootkits: Subverting the Windows Kernel” ) in 2004 [DKOM]. Since then, this technique was refined ("Raising the bar for rootkit detection") and other methods of evading detection are also tested. This same technique can be applied applied to Linux systems also, by manipulating the task_struct structure, which is similar to EPROCESS in Windows. An example of a Windows driver that implements this second method is available. 

Using this implementation, we will test the pslist and psscan commands from Volatility. 

The TestDriverApp.exe process is started (after the driver TestDriver.sys is loaded with OSR Loader). In a second terminal, we check its presence:

c:\>pslist | grep -i testdriverapp
TestDriverApp 284 8 1 8 208 0:00:00.031 0:00:04.999

It’s there. Now back to the first terminal where it was started, we continue execution by calling an IOCTL to the driver in kernel to hide itself. Then check again:

c:\>pslist | grep -i testdriverapp

Nothing. Now it’s invisible to the task manager and pslist. We make a copy of the memory using win32dd port of dd tool for Windows, from Moonsols Windows Memory Kit:

> win32dd /r /m 1 /s 3 /f win32dd_mem_dump240612.bin
Processing....Done.
Acquisition finished at: [2012-06-24 (YYYY-MM-DD) 16:11:07 (UTC)]
Time elapsed: 1:48 minutes:seconds (108 secs)
Created file size: 2950234112 bytes ( 2813 Mb)
SHA-256: 2012984E7CFD7725115...

The /r option creates a raw memory dump file. If /d would have been used instead, we would have obtained a WinDbg compliant crash dump file. The /m switch specifies the memory mapping method as \\Device\\PhysicalMemory (still possible in Windows XP) and the /s selects SHA-256 as the hashing method to use. This utility can function as a client or as a server: when in client mode it can send the data over the network and when in server mode (/t flag) it listens to receive the dump.
Now we can use the 2 process scanning options from Volatility:

> volatility.exe -f win32dd_mem_dump250612.bin –profile=WinXPSP3x86 pslist |
grep -i test

> volatility.exe -f win32dd_mem_dump250612.bin –profile=WinXPSP3x86 psscan
| grep -i test
0x09c20620 TestDriverApp.e 284 464 0x0b380560 2012-06-25 11:22:54

We see that the first command - pslist, didn’t find it (because this command just walks the active processes list), but it is revealed by the psscan command (which searches for a signature for the process data structure). The first column represents it’s physical offset in memory. It is needed for further investigation with other commands (handles command to list its handles to other resources or dlldump to list the used libraries). Advanced detection for processes that modify the signatures must take into account other fields that are harder to fake (Robust process scanner).