Memory Forensics: What RAM Reveals That Disk Never Shows

Prerequisites

• DFA-K002: Forensic Imaging
• DFA-K003: NTFS Forensics

Why This Lesson Matters

Some of the most valuable evidence in a compromise never touches the disk. Fileless malware, decrypted credentials, active network connections, and injected shellcode all live exclusively in RAM. If you do not acquire memory, you are investigating with one eye closed. This lesson teaches you to open the other one.

1. What RAM Contains That Disk Does Not

RAM at the moment of incident:

Running processes             → who is executing right now?
Loaded DLLs                   → what libraries are in use?
Decrypted credentials         → passwords, NTLM hashes, Kerberos tickets
Network socket state          → active C2 connections (even if already closed)
Injected code                 → shellcode inside legitimate processes
Clipboard contents            → what was copied/pasted?
Encryption keys               → symmetric keys for encrypted files
Browser session tokens        → cookies, JWT tokens in browser memory
Process command lines         → full arguments including encoded payloads

Analogy: RAM is the investigator's interview with the suspect while they are still talking. Disk is the crime scene after everyone has left. Both matter; neither is sufficient alone.

2. Memory Acquisition

# Linux: LiME (Loadable Kernel Module)
sudo insmod lime.ko "path=/media/usb/memory.lime format=lime"
sha256sum /media/usb/memory.lime > /media/usb/memory.lime.sha256

# Windows: winpmem (open source)
winpmem_mini_x64_rc2.exe /tmp/memory.raw
# or DumpIt (GUI)

# Virtual Machine: suspend the VM → the .vmem file IS the memory image
# VMware: <vm_name>.vmem + <vm_name>.vmsn
# VirtualBox: VBoxManage debugvm <name> dumpvmcore --filename memory.elf

3. Volatility 3: The Core Workflow

Volatility 3 is the standard memory forensics framework. It works on Linux, Windows, and macOS memory dumps.

# Step 1: Identify the OS and architecture
vol3 -f memory.raw windows.info
# Output: NtBuildLab, Major/MinorVersion, MachineType

# Step 2: List running processes
vol3 -f memory.raw windows.pslist
# Shows: PID, PPID, name, start time
# Key: look for processes with suspicious names or unexpected parents

# Step 3: Detect hidden processes (rootkits)
vol3 -f memory.raw windows.psscan
# Scans raw memory for EPROCESS structures
# Compare with pslist: processes in psscan but NOT pslist = hidden (rootkit indicator)

# Step 4: Full command lines
vol3 -f memory.raw windows.cmdline
# Reveals -EncodedCommand payloads, download cradle URLs, etc.

# Step 5: DLL injection detection
vol3 -f memory.raw windows.dlllist --pid 1337
# Lists every DLL loaded into process 1337
# A DLL in Temp or AppData loaded into a system process = injection

# Step 6: Network connections
vol3 -f memory.raw windows.netstat
# Active and recently closed TCP/UDP connections with owning PID
# Shows connections that may no longer appear in ss/netstat

# Step 7: Dump a suspicious process
vol3 -f memory.raw windows.dumpfiles --pid 1337 --dump-dir /cases/IR-001/dumps/
sha256sum /cases/IR-001/dumps/*

4. String Extraction: The Low-Tech Powerhouse

Before reaching for Volatility, strings is often the fastest way to find something useful.

# ASCII strings (default minimum 4 chars)
strings memory.raw | grep -iE "password|pass=|apikey|flag|ctf"

# Windows uses UTF-16LE (wide strings) — CRITICAL and commonly forgotten
strings -e l memory.raw | grep -iE "password|http|flag|ctf"
#      ^^^
#      -e l = little-endian UTF-16 (Windows default string encoding)

# Search for URLs (C2 addresses)
strings -e l memory.raw | grep -iE "http://|https://" | sort -u

# Search for IPs
strings memory.raw | grep -oE '[0-9]{1,3}.[0-9]{1,3}.[0-9]{1,3}.[0-9]{1,3}' | sort -u

The -e l flag is the most commonly missed technique. Most Windows artefacts — registry values, file paths, URLs — are stored as UTF-16LE. Plain strings only finds ASCII and will miss them entirely.

5. Detecting Malware in Memory

5.1 Process Injection Signatures

Process injection hides malware inside legitimate processes. Look for:

# Memory regions that are executable but not backed by a file on disk
vol3 -f memory.raw windows.malfind
# Scans for: executable private memory (not mapped from a file) = injected shellcode

# Output example:
# PID 4872   explorer.exe   0x1a2b3c00   MZ header found in private memory
# The MZ header means an entire PE was injected into explorer.exe

5.2 Parent Process Anomalies

vol3 -f memory.raw windows.pstree
# Visualises parent-child relationships
# Red flags:
# explorer.exe → cmd.exe (normal)
# svchost.exe  → cmd.exe (unusual — investigate)
# winword.exe  → powershell.exe (phishing macro delivery)

5.3 Credential Extraction (for context — not to misuse)

# Dump LSA secrets and NTLM hashes (requires SYSTEM privileges on live system)
vol3 -f memory.raw windows.hashdump
# Output: username:RID:LM_hash:NTLM_hash

# Kerberos tickets in memory
vol3 -f memory.raw windows.sessions

6. Linux Memory Forensics

# Linux process list
vol3 -f linux.lime linux.pslist

# Bash history from memory (even if file was cleared)
vol3 -f linux.lime linux.bash
# Extracts bash history that was in RAM — survives history -c

# Network connections
vol3 -f linux.lime linux.netstat

# Kernel modules (rootkit detection)
vol3 -f linux.lime linux.lsmod
vol3 -f linux.lime linux.check_modules
# check_modules: detects hidden kernel modules by comparing linked list vs memory scan

7. Common Mistakes

Mistake 1: Ignoring -e l in strings. UTF-16LE is the native string encoding for Windows. Skipping -e l means missing most file paths, registry values, and URLs.

Mistake 2: Only using pslist and missing hidden processes. Rootkits unlink their process from the EPROCESS list that pslist reads. Always cross-reference with psscan, which scans raw memory for EPROCESS structures.

Mistake 3: Not hashing the memory image immediately after acquisition. Like a disk image, a memory image must be hashed at acquisition time. The hash proves the image was not modified before analysis.

8. Practice Exercises

1. strings -e l memory.raw | grep http returns several URLs. One is: http://185.220.101.5/update.ps1. What do you do next to investigate the process that owned this string?

2. windows.psscan shows a process svchost.exe PID 9999 that does NOT appear in windows.pslist. What does this indicate? What Volatility plugin do you run next?

3. windows.malfind reports an MZ header inside explorer.exe at address 0x1a2b3c00. Explain what this means and how you extract the injected PE for further analysis.

9. Lab

Assessment mode: flag

challenge_spec_id: 326 — Wide-string memory leak

You are given a raw memory dump (memory.bin).

Task: 1. Run strings -e l memory.bin to extract UTF-16LE strings 2. Search the output for a string matching PREFIX{...} 3. Submit the flag

10. Framework Alignment

11. Further Reading

• Volatility 3 documentation — https://volatility3.readthedocs.io
• "The Art of Memory Forensics" — Ligh, Case, Levy, Walters — The definitive memory forensics textbook
• LiME GitHub — https://github.com/504ensicsLabs/LiME

["Describe five categories of evidence found in RAM that are absent from disk, and explain why fileless malware is only detectable through memory forensics", "Use Volatility 3 to list processes (pslist), detect hidden processes (psscan), extract command lines (cmdline), and identify injected code (malfind) from a Windows memory image", "Use strings -e l to extract UTF-16LE strings from a memory dump and identify a suspicious URL or flag string that would be missed by plain strings output"]

Prerequisites → Why this matters (investigator interview analogy) → What RAM contains vs disk → Memory acquisition (LiME, winpmem, VM) → Volatility 3 core workflow (info, pslist, psscan, cmdline, dlllist, netstat, dumpfiles) → String extraction (ASCII and critical -e l UTF-16LE) → Detecting malware: injection, parent anomalies, credential extraction → Linux memory forensics → Common mistakes → Practice exercises → Lab (flag, spec 326) → Framework alignment → Further reading