Memory and volatility
In this article series, we will learn about how processes reside in memory and various ways to find and enumerate them. I will be using Volatility plugins to find processes in memory. Once we know how to find processes within memory, in Part 2 we will see how to enumerate through them.
Note: The scope of this article is only limited to show how the process can be found & enumerated within memory. I will not cover any investigation/hunting of malicious processes in this article. Bonus points to you if you figure out suspicious processes from screenshots.
Process in memory
Processes are represented in memory using the structure names _EPROCESS and each process has its own private virtual memory space that contains all the components needed to run the process like process executable, DLLs, stack, heap, etc. This is how it looks in Windows 7 32bit.
Now as we can see, there are lots of properties that constitute a process. Below are some of the important ones and will be handy to know during investigations
- _EPROCESS structure will always reside in non-paged memory.
- CreateTime and ExitTime show UTC timestamp of the process being fist started and Exit.
- ImageFileName: it stores the first 16 ASCII characters of the process executable name.
- ActiveProcessLink: This is a doubly linked list that actually links all the running process in memory. There is a forward and back pointer which links all the processes. Later in this article, we will see how some popular plugins like pslist rely on enumerating this list and can be defeated by attackers.
- ActiveThreads: It shows a number of threads running in this processing context.
- PCB & PEB: Process Control Block (PCB) is at the base of the _EPROCESS and Process of Environment Block(PEB) points to DLLs, environment variables, heaps, command line arguments, etc.
- VadRoot: It is the root node of the VAD tree and shows allocated memory segments for this process.
Ways to find processes in memory using volatility
As we see below, we give the profile type selection while running Volatility plugins because it tells the code running in the background to look at specific offsets and then start following pointers to get all the objects like Process. To enumerate process, Volatility first locates Kernel Debugger data block to find out PsActiveProcessHead which itself points to _EPROCESS list.
Following are different ways to enumerate process in memory that Volatility gives us I form of plugins:
This plugin will walk the linked list that is pointed by PsActiveProcessHead and is run by ActiveProcessLink. The _EPROCESS structure contains this _LIST_ENTRY structure named ActiveProcessLink. This doubly linked list is like below
Below is an example of the pslist in action:
Take a look at the number of processes which were running in memory when the image was acquired. This plugin is useful to know which processes were there in the linked list and initial level triaging can be done here to look out for nay new unknown process or even a known process with a slightly different name like scvhost.exe and if possible try to map the parent of the child process though we have a better plugin for that pstree which we will discuss shortly.
Like stated above, pslist can be defeated if the process can be unlinked from doubly linked list. This can be achieved using techniques like Direct Kernel Object Manipulation(DKOM). This can be done by loading a malicious driver which will full access to kernel objects or with API function called ZWSystemDebugControl. Below is an output of psscan plugin. As you can already see that the number of processes being listed are more than pslist since psscan walked the complete memory to extract what’s related to Process object. Let’s take a look at it.
This plugin is used to give an overall picture of the process so that cross reference can be done for various aspects to discover malicious processes. Below is an output of psxview
Let’s examine the output now:
- Offset, Name, pslist, psscan are simple enough to guess by now I think.
- It’s good to map with the threads for the process. Hreads can be enumerated individually for _ETHREAD structure and can be mapped to processes from there.
- PspCid: This is a special table in memory that stores reference for all active and threads objects. This table can be manipulated to remove any process, thread reference.
- Csrss: Client-server Runtime subsystem plays a critical role in the creation of processes and threads. Note that this holds true only for a process created by itself.(system, smss.exe,csrss.exe)
- Session and Desktop: Session will attach all the process to a particular user session, and desktop will find each thread attached to the desktop which can be mapped to its owning process.
- Using –apply-rules with psxview can automatically take care of the exceptions listed above. It will show ‘Okay’ when it is reporting false, but it is a false positive and is Okay to ignore.
- Exit times will show when a process is exited however this can be easily manipulated so cross check to see if a process contain Exit Time, what does another column like thread(if it actually exited there should be 0 threads) say about it.
This plugin takes the output of pslist and actually present them in child-parent relationship. Very useful plugin when the process listing is huge within the memory to see any suspicious relationship between child-parent. For example in the output below of pstree, we can see the relationship with extending .‘s defines the relation structure.
Note that this gives mapping of pslist output only so you can still miss the output knowledge from psscan in this. What are your thoughts on cmd.exe process here?
So in this article, we have seen how processes can be found within memory, and their output can be transformed using Volatility plugins. In part 2 of this article series we will see how to enumerate the processes memory found in this article.