Memory Forensics for Hunters — Volatility 3, malfind, and MemProcFS

Memory is the one place where attackers cannot hide: whatever code is executing must be in RAM. A process can delete its binary from disk, overwrite its registry key, and clear event logs — but as long as it’s running, its code, network connections, and module list are in memory. Memory forensics is the hunter’s truth oracle.

Memory Analysis Workflow

Memory Image (raw dump or live memory)
         │
         ▼ Step 1: Process enumeration
    pslist + psscan (find all processes, catch DKOM)
         │
         ▼ Step 2: Network state
    netscan (active + recently closed connections)
         │
         ▼ Step 3: Target suspicious PIDs
    cmdline → what was the process started with?
    dlllist → what DLLs are loaded?
    ldrmodules → any unlinked modules (reflective injection)?
         │
         ▼ Step 4: Injection detection
    malfind → executable private memory (shellcode / injected code)
         │
         ▼ Step 5: Extract artifacts
    procdump → dump executable from memory
    dumpfiles → dump open file handles
    hashdump → extract NTLM hashes (if credential dump suspected)

Core Volatility 3 Commands

Process Enumeration

# List processes via EPROCESS linked list
vol.py -f memory.raw windows.pslist.PsList

# Scan for EPROCESS pool tags (catches DKOM-hidden procs)
vol.py -f memory.raw windows.psscan.PsScan

# Process tree with parent-child visualization
vol.py -f memory.raw windows.pstree.PsTree

# Command lines of all processes
vol.py -f memory.raw windows.cmdline.CmdLine

What to look for:

pslist output:
PID   PPID  Name             Offset      Threads Handles SessionId
3872  644   svchost.exe      0xe0018340  12      423     0
8844  3444  svchost.exe      0xe0054a80  6       89      1  ← PPID 3444 = powershell.exe (not services.exe)

Anomaly: svchost.exe with PPID pointing to powershell.exe = injection target

Network State

# Active and recently terminated connections
vol.py -f memory.raw windows.netscan.NetScan

# Output includes: Proto, LocalAddr:Port, ForeignAddr:Port, State, PID, Owner

Proto  Local            Foreign          State    PID   Owner
TCPv4  10.1.2.33:50111  185.220.101.9:443 ESTABLISHED  8844  svchost.exe

A svchost.exe PID making outbound ESTABLISHED connections to external IPs is a finding — legitimate svchost instances don’t establish outbound TCP to external hosts.

Injection Detection

# Find executable private memory (shellcode / injected PE)
vol.py -f memory.raw windows.malfind.Malfind

# Limit to specific process for speed
vol.py -f memory.raw windows.malfind.Malfind --pid 8844

Process: svchost.exe  PID: 8844  Address: 0x1a0000
Vad Tag: VadS
Protection: PAGE_EXECUTE_READWRITE
Flags: CommitCharge: 24, PrivateMemory: 1, Protection: 6

4d 5a 90 00 03 00 00 00  MZ......  ← PE header in private memory
04 00 00 00 ff ff 00 00  ........

MZ header in a private (non-file-backed), executable region of svchost.exe = injected PE (reflective DLL or process hollowing). This is the highest-confidence injection indicator.

Module Analysis

# DLLs loaded by a process (via PEB)
vol.py -f memory.raw windows.dlllist.DllList --pid 8844

# Compare PEB lists vs VAD tree (catch reflective injection)
vol.py -f memory.raw windows.ldrmodules.LdrModules --pid 8844

ldrmodules output to look for:

Pid   Process      Base           InLoad InMem InInit MappedPath
8844  svchost.exe  0x7ffd1a000000 True   True  True   C:\Windows\System32\ntdll.dll
8844  svchost.exe  0x1a0000       False  False False   (no mapped file)  ← INJECTED

A memory region at 0x1a0000 with False/False/False in all three PEB lists but present in the VAD tree as executable = not loaded via the Windows loader = reflective injection.

Artifact Extraction

# Dump an executable from memory (use when binary deleted from disk)
vol.py -f memory.raw windows.procdump.ProcDump --pid 8844

# Extract from malfind region (dump the injected code)
vol.py -f memory.raw windows.dumpfiles.DumpFiles --pid 8844 --virtaddr 0x1a0000

# Credential hash extraction
vol.py -f memory.raw windows.hashdump.Hashdump

MemProcFS: Rapid Triage

When you don’t know which PID to target yet, MemProcFS provides instant browsable access to the full memory image:

# Mount the memory image as a filesystem
./memprocfs -device memory.raw -mount /mnt/mem

# Browse like a normal filesystem
ls /mnt/mem/proc/
# → [pid_list]

ls /mnt/mem/proc/8844_svchost.exe/
# → cmdline.txt  dlls/  files/  handles/  net/  pe/  threads/

cat /mnt/mem/proc/8844_svchost.exe/cmdline.txt
# → C:\Windows\system32\svchost.exe -k netsvcs

cat /mnt/mem/proc/8844_svchost.exe/net/netconn.txt
# → TCP 10.1.2.33:50111 → 185.220.101.9:443 ESTABLISHED

ls /mnt/mem/proc/8844_svchost.exe/dlls/
# → ntdll.dll  kernel32.dll  ... [injected.dll is NOT here — reflective injection]

MemProcFS forensic timeline (all processes combined):

cat /mnt/mem/forensic/timeline.csv | sort -t, -k1 | head -50
# TimeGenerated, Type, PID, Process, Info
# 2024-09-02 14:23:44, Net, 8844, svchost.exe, ESTABLISHED 185.220.101.9:443
# 2024-09-02 14:23:11, Proc, 3444, powershell.exe, Created
# 2024-09-02 14:21:07, Proc, 2188, cmd.exe, Created

Worked Example

Memory analysis: confirming process hollowing and extracting the payload

Context: Beacon hunt identified host 10.1.2.33 connecting to 185.220.101.9:443 with CV=0.031. Sysmon shows the connection comes from svchost.exe (PID 8844) spawned by powershell.exe (PID 3444). Memory image collected via Velociraptor memory acquisition artifact.

Step 1 — pslist vs psscan comparison

pslist: PID 8844 svchost.exe PPID 3444 ← visible
psscan: PID 8844 svchost.exe PPID 3444 ← same result
→ Not DKOM-hidden. Process is visible but suspicious lineage.

Step 2 — cmdline: what was the process started with?

vol.py -f 10.1.2.33.raw windows.cmdline --pid 8844
# → svchost.exe -k netsvcs
# Normal svchost command line — but spawned from powershell.exe (wrong)

Step 3 — netscan: confirm the connection

vol.py -f 10.1.2.33.raw windows.netscan | grep 8844
# TCPv4 10.1.2.33:50111 185.220.101.9:443 ESTABLISHED 8844 svchost.exe

Confirmed. The svchost.exe PID has an active connection to the C2 IP.

Step 4 — malfind: find the injected code

vol.py -f 10.1.2.33.raw windows.malfind --pid 8844

# Result:
# Address: 0x1a0000  Protection: PAGE_EXECUTE_READWRITE  Private: YES
# 4d 5a 90 00 03 00 00 00  MZ header
# → PE injected into svchost at 0x1a0000

Step 5 — Dump the injected PE

vol.py -f 10.1.2.33.raw windows.dumpfiles --pid 8844 --virtaddr 0x1a0000
# Output: pid.8844.0x1a0000.dmp

# Hash for threat intel lookup
sha256sum pid.8844.0x1a0000.dmp
# → 4a3f7e2c... → VT: 54/72 detect as CobaltStrike.Beacon.generic

Verdict: Process hollowing confirmed. The legitimate svchost.exe binary was created, its memory was replaced with a Cobalt Strike beacon, and it’s beaconing to 185.220.101.9:443.

Evidence package for IR:

svchost.exe PID 8844 injected with CS beacon
C2 IP: 185.220.101.9:443
Hollowing performed by powershell.exe PID 3444 (spawned by cmd.exe PID 2188, spawned by WINWORD.EXE PID 1644)
Full execution chain: WINWORD.EXE → cmd.exe → powershell.exe → hollow svchost.exe

Retrieval Practice

You run malfind on a host and find 47 results — many in chrome.exe and node.exe with PAGE_EXECUTE_READWRITE pages. Are these all malicious? How do you triage malfind output?

Reveal answer

No — most are almost certainly false positives from JIT compilers. Chrome's V8 JavaScript engine and Node.js generate machine code at runtime and store it in private executable memory pages, exactly what malfind flags. Triage approach: (1) Exclude known JIT compilers: filter out chrome.exe, firefox.exe, node.exe, msedge.exe, java.exe results unless they also contain a full MZ PE header (JIT code rarely starts with MZ). (2) Focus on non-browser system processes: svchost.exe, explorer.exe, lsass.exe, notepad.exe — these have no legitimate reason to contain private executable pages with PE headers. (3) Check the page content: a PE header (4d 5a / MZ at offset 0) followed by the DOS stub structure is injection; random opcode patterns are likely JIT. (4) Correlate with network: injected process making outbound connections = high confidence. Always combine malfind with context rather than treating every result as an IOC.

Retrieval Practice

A ldrmodules output for lsass.exe shows one memory region with InLoad=False, InMem=False, InInit=False but the region has EXECUTE permissions. What does this indicate about lsass.exe and what is the immediate response?

Reveal answer

This is a high-confidence credential dumping / LSASS injection indicator. A private executable memory region not in any PEB module list within lsass.exe means code was injected into LSASS without going through the Windows loader. This is the signature of: reflective DLL injection into LSASS for credential access (T1003.001), or a credential dumping tool that injected a shellcode stub to extract credentials from LSASS's memory. Immediate response: (1) Assume all credentials on this host are compromised — force password reset for all users logged on to this host in the past 30 days, including service accounts. (2) Dump the injected region for forensic analysis (procdump on lsass or the specific address). (3) Escalate to IR for host isolation — if LSASS was the target, credential reuse attacks may already be underway. (4) Look at the injecting process via Sysmon Event 10 (ProcessAccess targeting lsass.exe) to identify what process performed the injection.