Listen to this Post
Introduction:
Memory forensics is the art of capturing and analyzing volatile data residing in a system’s RAM, which often contains invaluable evidence of ongoing attacks, malware injection, and process manipulation. Using the Volatility Framework (versions 2.6 and 3), DFIR analysts can reconstruct a system’s state at the time of memory acquisition — including running processes, network connections, and even hidden malicious code. In this article, we walk through a real-world memory analysis challenge issued to a SOC team, where they successfully identified OS version, virtual environment artifacts, process anomalies, and user activity from a single memory dump.
Learning Objectives:
- Identify the operating system version and architecture from a memory image using Volatility.
- Differentiate between physical and virtual machines by detecting hypervisor-specific processes (e.g., VBoxService.exe).
- Detect hidden or unlinked processes and suspicious memory regions using plugins like
psscan,malfind, andnetscan.
You Should Know:
- Capturing Memory Dumps from Host and Virtual Machines
Memory acquisition is the critical first step. In the challenge, analysts captured two copies: one from the physical host and one from a virtual machine (VM). For Windows systems, common tools include:
– FTK Imager (GUI): `File → Capture Memory → Select destination`
– DumpIt or WinPmem (command‑line)
– LiME for Linux (Loadable Kernel Module)
For a VirtualBox VM: Pause the VM and use `VBoxManage debugvm “VM Name” dumpguestcore –filename memory.dump` or take a snapshot and extract the saved state.
Step‑by‑step using FTK Imager (Windows):
1. Run FTK Imager as Administrator.
2. Click `File` → `Capture Memory`.
3. Set destination path and filename (e.g., `memory.raw`).
4. Optionally include pagefile; click `Capture`.
5. After completion, verify the hash for integrity.
Linux command (using LiME):
sudo insmod lime.ko "path=./memdump.raw format=raw" sudo rmmod lime
2. Identifying OS Version and Architecture with Volatility
Before any analysis, determine the correct profile (Volatility 2) or use Volatility 3’s auto‑detection. The challenge revealed `Win10x64_19041` – a Windows 10 64‑bit build 19041.
Volatility 2 commands:
List available profiles vol.py -f memory.raw imageinfo Use suggested profile vol.py -f memory.raw --profile=Win10x64_19041 pslist
Volatility 3 (no profiles needed):
vol -f memory.raw windows.info
This output includes kernel base, DTB, and OS version. Always verify against known builds – the reported `2026-05-10 20:06:17 UTC+00:00` matches the dump capture time found in windows.info.
3. Determining Physical vs. Virtual Environment
Forensic analysts can distinguish a VM by looking for hypervisor processes, drivers, or MAC addresses. In the challenge, `VBoxService.exe` (VirtualBox Guest Additions) was present, proving a virtual machine.
Step‑by‑step VM detection:
1. List all processes:
Volatility 2 vol.py -f memory.raw --profile=Win10x64_19041 pslist Volatility 3 vol -f memory.raw windows.pslist
2. Search for known VM artifacts:
`VBoxService.exe`, `VBoxTray.exe` (VirtualBox)
`vmtoolsd.exe` (VMware)
`xenserver.exe` (Xen)
3. Check network adapter MAC prefixes:
vol -f memory.raw windows.netscan | grep -i "08:00:27" VirtualBox vol -f memory.raw windows.netscan | grep -i "00:50:56" VMware
4. Examine registry (Volatility 2 `hivelist` + printkey) for `HKEY_LOCAL_MACHINE\HARDWARE\DESCRIPTION\System\SystemBiosVersion` containing “VirtualBox”.
- Process Analysis: pslist vs. psscan – Detecting Hidden Processes
The challenge compared `pslist` (walking the active process list) with `psscan` (scanning memory for EPROCESS structures). Differences reveal hidden or terminated processes.
Command examples:
Active processes vol -f memory.raw windows.pslist > pslist.txt Scanned processes (includes terminated/unlinked) vol -f memory.raw windows.psscan > psscan.txt
What the red/yellow highlights mean:
- Red entries appear in `psscan` but not in `pslist` → either terminated processes (normal) or hidden processes (malicious rootkit).
- Yellow indicates unordered timestamps in `psscan` because it scans memory blocks without respecting execution order.
In this case, no hidden processes were found – a sign of a clean but well‑configured system. To double‑check, use `malfind` for injected code:
vol -f memory.raw windows.malfind
No output (or only legitimate VAD regions) confirms absence of process injection.
5. Investigating Suspicious Parent‑Child Relationships and Command History
The challenge found no `cmd.exe` or `powershell.exe` processes, nor any command history. This is unusual for a live system but possible if the capture occurred during idle time. Analysts should still extract command history using:
For PowerShell:
Volatility 3 vol -f memory.raw windows.cmdline vol -f memory.raw windows.powershell_pshistory
For CMD:
Search console history buffers vol -f memory.raw windows.consoles
Step‑by‑step to verify no malicious parent‑child relationships:
1. List process tree:
vol -f memory.raw windows.pstree
2. Look for anomalous spawning (e.g., `winword.exe` spawning cmd.exe).
3. The challenge reported `explorer.exe` (PID 5480) spawning only `VBoxTray.exe` and `SecurityHealth.exe` – both legitimate.
4. Use `netscan` to verify no C2 callbacks:
vol -f memory.raw windows.netscan
No external suspicious connections = no active beaconing.
6. Recovering User Activity: Browsers, Office, and Tools
Even without command shells, user activity leaves traces. The challenge identified:
– Microsoft Edge → browsing history in `webhist` plugin (Volatility 2)
– OneDrive.exe → cloud synchronization
– Skype.exe → communication
– FTK Imager.exe → forensic tool usage
Extracting browser history (Volatility 2):
vol.py -f memory.raw --profile=Win10x64_19041 iehistory vol.py -f memory.raw --profile=Win10x64_19041 chromehistory
For Edge/Chrome on Windows, artifacts also live in %LocalAppData%\Microsoft\Edge\User Data. Using `filescan` + `dumpfiles` can extract these files from memory:
vol -f memory.raw windows.filescan | grep -i "history" vol -f memory.raw windows.dumpfiles --virtaddr < address>
- Step‑by‑Step Memory Analysis Workflow (Based on the Challenge)
1. Verify memory dump integrity – compute SHA256.
- Determine OS & architecture – `windows.info` or
imageinfo. - Capture capture time – from `windows.info` or system timestamps.
- Detect VM – processes (
VBoxService), MAC addresses, registry. - List processes –
pslist,pstree. Identify oldest/newest using `CreateTime` (e.g.,pslist -t). - Scan for hidden processes – `psscan` compare to
pslist.
7. Check for code injection – `malfind`, `ldrmodules`.
8. Enumerate network connections – `netscan`.
- Recover command line & history –
cmdline,consoles,powershell_pshistory. - Extract user activity –
iehistory, `filescan` for Office/PDFs.
11. Generate timeline – combine `timeliner` plugin.
Example command to combine all for a report:
vol -f memory.raw windows.timeliner > timeline.csv
What Undercode Say:
- Key Takeaway 1: Comparing `pslist` and `psscan` is essential – any discrepancy (red entries) demands deeper investigation, but always consider terminated processes as benign first.
- Key Takeaway 2: Virtual environment detection is often overlooked; hypervisor processes like `VBoxService.exe` are straightforward indicators that change the threat model (guest vs. host compromise).
Analysis: This exercise demonstrates that methodical memory forensics – even without obvious malware – builds a baseline for “normal” behavior. The team’s ability to rule out C2, hidden processes, and command execution shows strong DFIR discipline. However, the absence of PowerShell or CMD activity in a Windows VM might indicate either a very clean image or the attacker cleaning logs before memory capture. Future iterations should include `amcache` or `shimcache` analysis to identify executed programs that exited before the dump. The use of both Volatility 2 and 3 highlights the need for tool redundancy – some plugins (like psscan) behave slightly differently across versions.
Prediction:
Memory forensics will increasingly integrate AI‑driven anomaly detection to automatically flag hidden processes and injected code across thousands of endpoints. As cloud workloads and containerized environments (e.g., AWS Nitro, Docker) adopt memory encryption, tools like Volatility will evolve to acquire and parse encrypted memory regions. Within the next two years, we expect SOC teams to leverage real‑time memory analysis as an EDR supplement – not just after an incident, but continuously, using minimal‑overhead memory sampling to detect fileless malware before it executes. The challenge’s success proves that hands‑on memory drills remain irreplaceable for training next‑generation DFIR analysts.
▶️ Related Video (78% Match):
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Ahmed El – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
