Detecting and Identifying Hidden Processes (MemProcFs Edition)
Stealthy mechanisms can cause headaches for security researchers and malware analysts, especially during incident response and when investigating memory samples whether live or offline. These stealth techniques often bypass traditional detection methods. For example, tools like the Volatility framework and Rekall, using plugins such as pslist and psview, often fail to detect hidden processes that manipulate kernel objects. Similarly, tools like Process Explorer and Process Hacker running on a live machine also cannot see these hidden processes.
I have also tested Windows Kernel Explorer, but it proved ineffective when malware manipulates kernel objects. This type of malware simply unlinks itself from the EPROCESS structure, also known as the process environment block (PEB).
In such cases, we can use another tool called memprocfs. It is a memory forensics tool similar to Rekall and Volatility. Memprocfs offers several options, but we mainly use the general options to unmount or create a virtual drive inside the computer. This drive shows the data memprocfs has collected, organized into folders and text files containing information such as processes, system details, and other forensic data.
To be honest with my readers, traditional commands like pid and pslist are not effective for detecting these hidden processes. However, memprocfs creates a folder called "pid" that contains detailed information about processes, including those unlinked from the EPROCESS structure.
You can download Dokan and memprocfs from the links below. The memory dump image used in this example is available from our previous article or can be downloaded directly here:
-
Memprocfs: https://github.com/ufrisk/MemProcFS/releases/tag/v5.15
-
Prolaco memory dump: https://github.com/ganboing/malwarecookbook/blob/master/15/6/prolaco.vmem.zip
To mount the memory image using memprocfs, run the following command: memprocfs.exe -device prolaco.vmem -forensic 0. This command tells memprocfs to load the specified memory dump file (prolaco.vmem) in forensic mode. Once executed, memprocfs will mount the memory image as a virtual drive, allowing you to explore the collected data through organized folders and files. You should then see the mounted drive and the corresponding output indicating the successful loading of the memory image.
After mounting the memory image, you can open This PC or simply press Ctrl + E to launch Windows Explorer. In the left sidebar under This PC, you will see the mounted memprocfs virtual drive. The contents of this drive will display the organized folders and files representing the data extracted from the memory image. Below is an example of what you should see in the sidebar.
You will see a comprehensive and well-structured set of results, including folders such as:
-
registry
-
name
-
sys
-
forensics
-
pid
Our primary focus is the pid folder because it contains information about processes, including those unlinked from the process environment block (PEB). Below, you can see an example of the results found in the pid folder.
Actually, we have both a list of running processes and a process tree view available. You can find them at the following paths, as shown in the picture below:
I have opened the proc.txt and proc_v.txt files. You can see the contents of the proc.txt file in the screenshot below. The file is well-structured; however, it does not clearly show the unlinked processes from the EPROCESS structure.
You can merge the analysis results from psscan in Volatility or Rekall to help identify suspicious unlinked processes from the process environment block (PEB). Below, I will share my recent psscan results from Rekall and demonstrate how to correlate them with the corresponding folders inside the pid folder mentioned earlier in this article.
According to the Rekall results, the unlinked process has a PID of 1136. Now, let’s search for this PID within our memprocfs results to determine if it can be found.
After opening the directory for PID 1136, you will see the results shown below:
You can conduct your own investigation and incident response using this memory image. One thing that caught my attention is the win_cmdline file, which appears similar to the output from the cmdscan plugin in Volatility. You can see the results below:
Comments
Post a Comment