When it comes to modern cyber threats, attackers are getting craftier with their code injection techniques. The old-school methods are still around, but more sophisticated attackers are now directly manipulating memory structures to blend in and avoid detection. These techniques include modifying memory permissions, hijacking execution pointers, and even patching legitimate code. While this might sound scary, the good news is that we can still detect these attacks—though it requires a deeper dive into how processes manage memory.
--------------------------------------------------------------------------------------------------------
Power of Volatility for Detection
We can still catch these manipulations using memory forensics tools like Volatility. By comparing multiple memory structures, we can spot inconsistencies that indicate something fishy is going on.
A great example of this is the ldrmodules plugin in Volatility. This tool examines the different ways Windows tracks loaded DLLs and cross-references them with memory-mapped files.
Here's what it looks at:
Process ID (PID) and Process Name
Base Address of the DLL in memory
Lists from the PEB tracking loaded DLLs
Mapped Path of the DLL from the VAD tree
A legitimate DLL will appear in all these lists and have a valid disk path. If any of these are missing or mismatched, it could indicate code injection.
-------------------------------------------------------------------------------------------------------------
Real-World Red Flags
Lets take an real world example:
We took a closer look at a potentially infected process,
powershell.exe (PID: 5352), using ldrmodules in our forensic analysis.
Right away, we found entries with no MappedPath information.
What does that mean?
Well, normally, when a program loads a DLL, it gets mapped from disk into memory through standard Windows APIs. But in this case, there was no mapped path to a file on disk—which strongly suggests that the DLLs were injected directly into memory instead of being loaded the usual way.
Why is that a red flag?
Because malware often avoids writing files to disk to evade antivirus detection and forensic analysis. If security tools can’t scan files on disk, they have a harder time catching the malware.
-------------------------------------------------------------------------------------------------------------
The Process Environment Block (PEB) and More Suspicious Clues
Digging deeper, we checked the Process Environment Block (PEB)—which keeps track of all loaded DLLs in a process.
Normally, every DLL should show up in these linked lists, but one particular section (0x6c10000) wasn’t in any of the usual lists.
Another section (0x7ff78357000) was present in most lists except one called InInit.
That missing entry in InInit might seem normal at first (because the main process executable isn’t listed there by design).
However, the real concern is that it also lacks a MappedPath to disk. For example, the legitimate msiexec.exe file should have been mapped from C:\WINDOWS\system32\ or C:\Windows\SysWOW64\ but instead, it wasn’t pointing to anything on disk.
That’s a seems to be a key sign of process hollowing.
-------------------------------------------------------------------------------------------------------------
What is Process Hollowing?
Process hollowing is when malware starts a legitimate process, then removes its original code and replaces it with its own malicious code—all without touching the disk. Since the process still looks legitimate from the outside, it can easily evade security tools that focus on scanning files instead of memory.
How Do We Confirm This?
Using forensic tools like malfind (which detects injected memory sections) and ldrmodules (which identifies suspicious DLLs), we can spot these anomalies.
Here’s how:
Compare memory addresses – If the base addresses reported by ldrmodules don’t match what dlllist reports, something’s fishy.
Look for missing mapped paths – If a DLL is running in memory but has no corresponding file on disk, it’s likely injected.
Use automated detection tools – Volatility’s HollowFind plugin (created by Monnappa K A) is specifically designed to detect process hollowing techniques like this.
----------------------------------------------------------------------------------------------------------------
MemProcFS’s FindEvil plugin is a game-changer. It goes beyond traditional scanning methods by digging deep into memory structures to uncover signs of manipulation.
Key Plugins in FindEvil
PEB_MASQ: Spotting Process Name Spoofing
Attackers love to hide in plain sight, and one way they do that is by altering the Process Environment Block (PEB) to fake a process name or file path.
PEB_MASQ detects this trick by cross-checking the PEB details with the Virtual Address Descriptor (VAD) tree. If something doesn’t match up, you know you’ve got a problem.
PE_NOLINK: Detecting Hidden DLLs
Ever heard of DLL injection?
This technique lets malware run inside legitimate processes, making detection difficult. PE_NOLINK works similarly to Volatility’s ldrmodules plugin but takes it a step further. It identifies DLLs with PE headers that exist in memory but are missing from the PEB lists. Be mindful, though—false positives happen, especially if memory paging or PEB corruption is in play.
PE_PATCHED: Finding Tampered Code
Modern malware doesn’t just inject code—it modifies legitimate executable pages to stay hidden. This technique is often used for evading Windows Defender’s AMSI scans. PE_PATCHED detects these changes by analyzing Page Table Entries (PTEs), specifically prototype PTEs that track modified memory pages. While effective, expect a lot of noise—especially from SysWOW64 processes and .NET applications like PowerShell.
Beyond These Three: More Cross-Referencing Plugins
MemProcFS includes other powerful plugins such as:
PE_INJECT: Finds reflectively loaded PE files in private memory.
PRIVATE_RWX/RX & NOIMAGE_RWX/RX: Flags suspicious memory permissions that could indicate injected shellcode.
FindEvil offers a more thorough analysis of injected code. However, Volatility users can supplement their toolkit with the ptemalfind plugin by Frank Block, which also relies on PTE data to detect advanced injections.
Understanding FindEvil’s Output
FindEvil pulls data from multiple sources, so its output columns can look overwhelming at first. Here are the most useful ones:
PID & Process: Identifies the affected process.
Type & Virtual Address: Shows where the suspicious memory section is located.
VadName: Helps correlate the memory section with known files or structures.
PTE Flags & VadFlagsType: Useful for detecting unexpected permission changes.
Adding YARA Scanning for Better Detection
One of the coolest upgrades to MemProcFS is its built-in YARA scanning. This allows you to automatically scan memory against known malware signatures.
When enabled, YARA matches appear at the top of the FindEvil output, helping you quickly pinpoint malicious processes.
-------------------------------------------------------------------------------------------------------------
If you want to learn more about MemProcFS and MemProcFS Analyzer, i have created an complete article with indepth overview which will help you get started link below do check it out
-------------------------------------------------------------------------------------------------------------
Next Steps After Finding Suspicious Memory Sections
So, you’ve spotted something shady—what now?
Take notes: Document process names, virtual addresses, and anything odd in the VAD.
Extract the memory sections: MemProcFS reconstructs files found in memory, storing them in the files and vmemd folders for further analysis.
Use a hex editor or malware analysis tools: Open extracted memory sections to confirm whether they contain malicious code.
Conclusion
MemProcFS FindEvil is an incredibly powerful tool for detecting hidden malware and process manipulation. By cross-referencing memory structures and leveraging YARA rules, it provides an in-depth look at suspicious activity that many traditional security tools might miss. If you’re serious about memory forensics, this tool should be in your arsenal!
----------------------------------------------Deam--------------------------------------------------------
Comments