Memory Forensics

RAM contains the live state of a compromised system — decrypted data, running processes, network connections, injected code, and credentials. It is the only place fileless malware and process injection artifacts can be found.

    Core exam principle: Memory is volatile — captured once, gone on reboot. Always acquire RAM before rebooting. Fileless malware exists only in memory and cannot be detected from disk alone. Process injection leaves traces in memory (VAD, malfind) that are invisible in the file system.
  

Why Memory Analysis Is Critical

🦠

Fileless Malware

Lives entirely in RAM — no file on disk. Only detectable through memory analysis. Examples: PowerShell Empire, Cobalt Strike in-memory payloads.

💉

Process Injection

Malicious code injected into legitimate processes. Disk shows only clean executables; memory reveals the injected shellcode or DLL.

🔑

Credential Exposure

LSASS holds NTLM hashes, Kerberos tickets, and (on older Windows) cleartext passwords. Encryption keys for BitLocker, VeraCrypt may be in RAM.

🔓

Decrypted Data

Encrypted files are decrypted in memory before use. Documents, C2 traffic, ransomware keys, and TLS session keys may be recoverable from RAM.

🌐

Live Network State

Active and recently closed connections, listening ports, and C2 IP addresses captured at the moment of acquisition — lost after reboot.

👻

Hidden Processes

DKOM rootkits unlink processes from the OS process list. Memory scanning (psscan) finds them even when they're invisible to the OS and task manager.

Volatility 2 vs Volatility 3 — Key Differences

Feature	Volatility 2	Volatility 3
OS identification	`imageinfo` plugin suggests profiles	Automatic symbol detection; no profile needed
Profile flag	`--profile=Win10x64_19041` required	No `--profile` flag
Plugin naming	`pslist`, `netscan`	`windows.pslist`, `windows.netscan`
Symbol tables	Profiles bundled with tool	Downloads ISF symbol tables automatically
Python version	Python 2 (legacy)	Python 3 (current)
GCFA exam focus	Likely tested (FOR508 curriculum)	Increasingly included

Key Volatility Plugins at a Glance

🔍 Process & System

pslist

Lists processes from EPROCESS doubly-linked list — fast but can be defeated by DKOM

psscan

Scans raw physical memory for EPROCESS pool tags — finds hidden/unlinked processes

pstree

Shows parent-child process relationships — essential for detecting masquerading

cmdline

Shows command line arguments used to launch each process

dlllist

Lists DLLs loaded into each process — missing expected DLLs or unexpected ones are suspicious

handles

Lists open handles per process (files, registry keys, events, mutexes, threads)

🧬 Injection Detection

malfind

Finds VAD regions with RWX protection + MZ header not backed by file on disk — primary injection detector

vadinfo

Shows Virtual Address Descriptor tree entries — protection flags, type, file backing

procdump

Dumps the executable image of a process to disk for further analysis

memdump

Dumps the entire virtual address space of a process — use for string/YARA analysis

🌐 Network & Registry

netscan

Finds active and recently closed network connections — reveals C2 IP:port with owning PID

filescan

Scans for FILE_OBJECT structures — finds open files even for hidden processes

hivelist

Lists registry hive objects in memory — prerequisite for printkey and hashdump

hashdump

Extracts NTLM password hashes from SAM and SYSTEM hives in memory

Memory Acquisition & Image Formats

Acquiring a memory image is a time-sensitive step — RAM content changes continuously and is lost on shutdown. Tool selection and method depend on the OS, environment, and whether the system is live or virtual.

    Acquisition anti-forensics awareness: Some rootkits hook memory acquisition APIs to exclude their pages from the dump. Kernel-level acquisition tools (WinPmem, LiME) that bypass the Windows API are more reliable. Always hash the memory image immediately after acquisition.
  

Acquisition Tools by Platform

Windows

WinPmem

Open-source, kernel-level driver; outputs raw or AFF4 format. Reads physical memory via driver, bypassing user-mode API hooks.

Usage: winpmem.exe <output.raw>

Windows

Magnet RAM Capture

Free GUI tool from Magnet Forensics; captures physical memory to a raw file. Minimal footprint; runs from USB without installation.

Free download; outputs .mem (raw) format

Windows

FTK Imager (Memory Capture)

Commercial tool with memory acquisition module. Also captures pagefile.sys and hiberfil.sys in same workflow. Widely used in enterprise forensics.

File → Capture Memory in FTK Imager GUI

Windows

DumpIt

Single executable; double-click to dump memory. Minimal interaction required — good for non-technical first responders. Output in raw format.

MoonSols DumpIt — outputs to current directory

Linux

LiME (Linux Memory Extractor)

Loadable kernel module (LKM) for Linux and Android. Acquires memory over network or to file. Only kernel-level Linux acquisition tool.

insmod lime.ko "path=/tmp/mem.lime format=lime"

Linux

AVML (Azure VM Memory Library)

Microsoft open-source tool; single statically-linked binary for Linux. Works without kernel module — reads /proc/kcore or /dev/mem. Used in cloud forensics.

avml --compress output.lime

Virtual

VMware Snapshot (.vmem / .vmss)

Suspending a VMware VM creates a .vmem (raw memory) and .vmss (VM state) file. Ideal — no installation needed, bit-perfect copy. Also .vmsn for named snapshots.

Analyze .vmem directly with Volatility

Any

Hibernation File (hiberfil.sys)

Windows compresses and writes full RAM to hiberfil.sys on hibernation. Historical memory snapshot — not live but valuable. Located at C:\hiberfil.sys (hidden, system file).

Volatility: use --profile with hiberfil directly; or convert with Hibr2Bin

Memory Image Formats

Raw / DD

.raw, .mem, .bin, .img

Flat binary — physical memory pages in sequential order. Most widely supported format. No metadata. Most Volatility analysis uses raw.

hiberfil.sys

C:\hiberfil.sys

Compressed Windows hibernation image. Contains full RAM state at hibernation time. Volatility supports direct analysis. Convert with Hibr2Bin if needed.

VMware Snapshot

.vmem, .vmss, .vmsn

VMware virtual machine memory file from suspend/snapshot. Can be analyzed directly by Volatility. Paired with .vmss for full state.

Crash Dump

.dmp — C:\Windows\MEMORY.DMP

Windows kernel crash dump. Full dump contains all RAM. May be generated intentionally (NotMyFault tool) or by actual BSOD. Volatility supports crash dump analysis.

LiME Format

.lime

Linux Memory Extractor native format. Includes header with address ranges. Volatility supports LiME directly. Preferred for Linux acquisition integrity.

AFF4

.aff4

Advanced Forensic Format 4. Container format with compression, hashing, and metadata. WinPmem supports AFF4. Rekall forensic tool native format.

pagefile.sys vs hiberfil.sys — Key Differences

	pagefile.sys	hiberfil.sys
Purpose	Virtual memory (swap) — pages swapped out of RAM	Full RAM snapshot — written on hibernation
Location	C:\pagefile.sys	C:\hiberfil.sys
Volatility analysis	❌ Cannot analyze directly	✅ Direct analysis supported
Forensic use	String search for fragments, passwords, documents	Full process list, injections, network state
Content	Random swapped pages — not complete processes	Complete RAM at time of hibernation
Format	Raw binary pages (no structure)	Compressed with Xpress algorithm

Process Analysis & DKOM Detection

Knowing what a legitimate Windows process looks like — its parent, count, path, and user — is the foundation of memory forensics. Deviations are your indicators of compromise.

    Golden rule — pslist vs psscan: Use pslist for the standard process list. Use psscan to find processes hidden by DKOM rootkits. Compare the two outputs — processes in psscan but not pslist are almost certainly malicious.
  

Legitimate Windows Process Characteristics

System

PID: 4 | Parent: None (PPID 0)

Always PID 4. No parent. Runs no user-mode threads. Spawns smss.exe. Single instance.

⚠ Any other PID, or having a parent process = malicious

smss.exe

Parent: System (4) | Path: \Windows\System32\smss.exe

Session Manager — first user-mode process. Spawns csrss.exe and wininit.exe/winlogon.exe. Only 1 master instance; child instances exit after session init.

⚠ Multiple persistent instances, wrong parent, wrong path = suspicious

csrss.exe

Parent: smss.exe | Path: \Windows\System32\csrss.exe

Client/Server Runtime SubSystem — manages Win32 API. One instance per session (Session 0 for system, one per user logon). Runs as SYSTEM.

⚠ Wrong path, wrong parent (should be smss.exe), interactive session = suspicious

wininit.exe

Parent: smss.exe | Path: \Windows\System32\wininit.exe

Launches services.exe, lsass.exe, and lsm.exe. Single instance. Runs in Session 0. Critical process — if killed, system BSODs.

⚠ More than one instance, or unexpected children = suspicious

services.exe

Parent: wininit.exe | Path: \Windows\System32\services.exe

Service Control Manager — manages all Windows services. Single instance. Parent of svchost.exe instances. Runs as SYSTEM.

⚠ Wrong parent (must be wininit.exe), multiple instances = suspicious

svchost.exe

Parent: services.exe | Path: \Windows\System32\svchost.exe

Service Host — runs Windows services as DLLs. Multiple instances are normal. Must be launched with -k flag followed by service group name. Parent must always be services.exe.

⚠ Parent other than services.exe, missing -k flag, path outside System32 = malicious masquerading

lsass.exe

Parent: wininit.exe | Path: \Windows\System32\lsass.exe

Local Security Authority SubSystem — handles authentication, stores credentials (NTLM hashes, Kerberos tickets). Single instance. Prime Mimikatz target.

⚠ Multiple instances, wrong parent, wrong path, or memory access from unusual process = credential theft attempt

explorer.exe

Parent: userinit.exe (exits after launch) | Path: \Windows\explorer.exe

Windows shell. One instance per interactive user session. Parent appears as no parent (userinit.exe exits). Users may have multiple if relaunched.

⚠ Wrong path, or unusual child spawning cmd.exe/powershell.exe = lateral movement or macro execution

DKOM — Direct Kernel Object Manipulation

Aspect	Details
What it is	Rootkit technique that unlinks a process's EPROCESS structure from the doubly-linked ActiveProcessLinks list
Effect	Process disappears from Task Manager, pslist, and any tool that walks the linked list
Detection	`psscan` — scans physical memory for EPROCESS pool tag signatures regardless of list linkage
Tell	Process appears in psscan output but NOT in pslist output
Other indicators	filescan may show file handles owned by the hidden process; netscan may show connections
EPROCESS tag	Pool tag `Proc` (0x636F7250) searched by psscan in physical memory

Process Injection & Malware in Memory

Process injection lets attackers run malicious code inside legitimate processes — evading process-level detection. Understanding each technique's mechanism and forensic signature is core GCFA knowledge.

    Universal detection approach: Run malfind first — it flags VAD regions with PAGE_EXECUTE_READWRITE protection and an MZ header (0x4D 0x5A) not backed by a file on disk. Follow up with dlllist, vadinfo, and cmdline to build the full picture.
  

Process Injection Techniques

Technique 1

Classic DLL Injection

OpenProcess → VirtualAllocEx (allocate memory in target) → WriteProcessMemory (write DLL path) → CreateRemoteThread with LoadLibrary as start address → target loads the DLL

🔍 Detection: dlllist shows unexpected DLL; malfind if DLL is reflectively loaded; handles shows thread in target process

Technique 2

Process Hollowing (RunPE)

CreateProcess (suspended) → NtUnmapViewOfSection (hollow out code) → VirtualAllocEx → WriteProcessMemory (write malicious PE) → SetThreadContext → ResumeThread

🔍 Detection: malfind shows MZ header with no file backing; vadinfo shows anonymous executable section where PE image expected; process image path and VAD don't match

Technique 3

Reflective DLL Injection

Shellcode / loader writes a DLL into target process memory → DLL contains its own loader routine that maps itself into memory without calling LoadLibrary → DLL resolves imports manually

🔍 Detection: malfind (no file backing); dlllist will NOT show it (bypasses Windows loader); unusual RWX memory region with PE header in vadinfo/malfind

Technique 4

Process Doppelgänging

Create NTFS transaction → write malicious code to transacted file → map as image section (NtCreateSection) → create process from section → rollback transaction (file never persists to disk)

🔍 Detection: process image backed by deleted/transacted file; inconsistency between process image path and actual file; limited Volatility support — use pstree + vadinfo

Technique 5

APC Injection

OpenProcess → VirtualAllocEx → WriteProcessMemory (shellcode) → QueueUserAPC (queue APC pointing to shellcode in target thread) → thread executes APC when it enters alertable wait state

🔍 Detection: malfind for shellcode region; thread analysis; unusual APC queues visible via kernel debugger; harder to detect passively from memory image

Technique 6

Thread Execution Hijacking

OpenThread (target thread) → SuspendThread → GetThreadContext → VirtualAllocEx → WriteProcessMemory (shellcode) → SetThreadContext (RIP/EIP → shellcode) → ResumeThread

🔍 Detection: malfind for shellcode; thread context pointing to unusual memory region; suspended/resumed thread events in process timeline

Technique 7

Atom Bombing

Write shellcode to Global Atom Table → use APC and NtSetContextThread to force target process to call GlobalGetAtomName (copies shellcode from atom table into target memory) → execute via APC

🔍 Detection: atom table analysis; unusual GlobalGetAtomName calls; malfind for resulting shellcode in target process memory

VAD (Virtual Address Descriptor) Analysis

The VAD tree describes every virtual memory region in a process — its address range, protection flags, and whether it's backed by a file. malfind uses VAD to find injections.

PAGE_EXECUTE_READ (RX)

Normal for legitimate code sections (.text). Executable but not writable. Expected for DLLs and executables backed by files.

PAGE_READWRITE (RW)

Normal for data regions — heap, stack, data sections. Not executable. Standard and expected in most processes.

PAGE_EXECUTE_READWRITE (RWX)

⚠ Suspicious — legitimate code is rarely RWX. JIT compilers (Java, .NET, browsers) are exceptions. Injected shellcode is almost always RWX to self-modify and execute.

RWX + No File Backing

🚨 High confidence injection. Memory region is executable, writable, and not linked to any file on disk. malfind specifically looks for this pattern + MZ header.

VAD Type	Meaning	Forensic Significance
VadS (private)	Private anonymous memory — heap, stack	Injected shellcode typically lives in VadS regions
Vad (mapped)	Memory-mapped file or section	Legitimate DLLs and EXEs appear here with file backing
VadF (large page)	Large page allocation	Rare; may indicate unusual memory manipulation
No FileObject	Memory not backed by any file	Combined with execute permission = strong injection indicator

Credential Extraction from Memory

LSASS Process

Primary Target for Credential Theft

Stores NTLM hashes, Kerberos TGTs and service tickets
WDigest (Win7/older): stores cleartext passwords in memory
Mimikatz command: sekurlsa::logonpasswords
PPL (Protected Process Light) on Win8.1+ defends LSASS
LSASS dump: Task Manager → Create Dump File (or procdump -ma lsass.exe)
Volatility: lsadump or hashdump plugins

SAM Database in Memory

Local Account Hashes

SAM hive holds local user NTLM hashes
Encrypted with SYSKEY from SYSTEM hive
Both hives must be present for decryption
Volatility hashdump: extracts and decrypts hashes from memory
Outputs: username:RID:LM hash:NTLM hash
NTLM hashes can be passed (Pass-the-Hash) or cracked offline

Kerberos Tickets

Domain Authentication Tokens

TGT (Ticket Granting Ticket) + Service Tickets stored in LSASS
Golden Ticket: forged TGT using KRBTGT hash — valid for 10 years
Silver Ticket: forged service ticket using service account hash
Pass-the-Ticket: export ticket from one machine, import on another
Mimikatz: kerberos::list /export
Volatility: mimikatz plugin (Vol2) for ticket extraction

Encryption Keys in Memory

Disk & Transport Keys

BitLocker FVEK (Full Volume Encryption Key) may be in RAM
VeraCrypt / TrueCrypt master keys recoverable from RAM
TLS session keys — decrypt HTTPS traffic captured in parallel
Tools: bulk_extractor (finds crypto keys), AESKeyFinder
Requirement: memory image must be from an unlocked/running system
Volatility: bitlocker plugin for BitLocker FVEK extraction

Process Hollowing — Step-by-Step Detection

Run pstree — check parent-child relationships

Hollowed processes often have unusual parents (e.g., Word spawning svchost) or spawn unexpected children. The legitimate-looking process name hides the malicious content.

Run malfind — look for MZ header in anonymous memory

malfind dumps regions with RWX protection and an MZ (4D 5A) header. A hollowed process will show its injected PE in this output, not backed by a file.

Run vadinfo — compare VAD file backing to process image

A hollowed process has its main VAD region (where the PE image should be) as anonymous (VadS) instead of file-backed (Vad with FileObject). The image path in EPROCESS doesn't match what's actually executing.

Run procdump — dump the process image

Dump the process's virtual address space and analyze the PE header. The dumped image will be the malicious payload, not the original legitimate executable.

Hash the dumped image and submit to VirusTotal / YARA scan

The extracted payload can be hashed (SHA-256) and compared against threat intelligence. YARA rules for known malware families (Cobalt Strike, Metasploit, etc.) can confirm the payload.

Practice Quiz

Ten GCFA-style questions on memory forensics. Select your answers and submit to see your score.

Question 1 of 10

Which Volatility plugin scans raw physical memory for EPROCESS pool tag signatures and can detect processes hidden via DKOM?

pslist

pstree

psscan

cmdline

psscan scans physical memory for the EPROCESS pool tag (Proc) signature, finding processes regardless of whether they appear in the ActiveProcessLinks doubly-linked list. DKOM rootkits unlink a process from that list (defeating pslist) but cannot remove the EPROCESS structure from physical memory (where psscan looks).

Question 2 of 10

A memory analyst finds a VAD entry with PAGE_EXECUTE_READWRITE protection and no file backing in a svchost.exe process. This is most consistent with:

A legitimate Windows DLL loaded from System32

Process injection or shellcode residing in memory

A memory-mapped database file

A standard heap allocation

RWX (Read-Write-Execute) protection with no file backing is the primary signature of injected code. Legitimate DLLs are file-backed and typically PAGE_EXECUTE_READ. Heaps are PAGE_READWRITE (not executable). This is exactly what malfind searches for, and finding it in svchost.exe (a common injection target) is a strong IOC.

Question 3 of 10

Which process injection technique creates a legitimate process in a suspended state, unmaps its executable code from memory, and replaces it with malicious code before resuming execution?

Classic DLL Injection

Reflective DLL Injection

Process Hollowing (RunPE)

APC Injection

Process Hollowing (also called RunPE) creates a legitimate process (like svchost.exe) in a SUSPENDED state, then calls NtUnmapViewOfSection to remove the original code, writes malicious PE code into the now-empty process space, adjusts the entry point via SetThreadContext, and resumes the thread. The process appears legitimate by name while executing malicious code.

Question 4 of 10

The Volatility malfind plugin identifies suspicious memory by searching for:

Processes with no parent PID in the process list

Network connections to known malicious IP addresses

VAD regions with RWX protection containing executable content not backed by a file on disk

Registry keys modified after system boot time

malfind specifically looks for VAD entries with PAGE_EXECUTE_READWRITE (RWX) protection where the memory region is not backed by a file on disk, and the region begins with an MZ header (0x4D 0x5A) indicating a PE file. This pattern — anonymous executable memory with a PE header — is the hallmark of injected code (DLL injection, process hollowing, reflective DLL injection).

Question 5 of 10

DKOM can hide a malicious process from pslist but NOT from psscan. What is the fundamental reason for this difference?

pslist requires administrator privileges while psscan does not

pslist traverses the EPROCESS linked list which DKOM can manipulate; psscan scans raw physical memory for EPROCESS pool tag signatures

psscan uses a higher processor privilege ring that DKOM cannot intercept

pslist only shows 32-bit processes; psscan shows all architectures

pslist walks the ActiveProcessLinks doubly-linked list in the kernel. DKOM manipulates this list by relinking the previous and next pointers to skip the hidden process — making it invisible to anyone walking the list. psscan bypasses the list entirely by scanning raw physical memory for the EPROCESS pool tag "Proc" (0x636F7250), which DKOM cannot remove without crashing the system.

Question 6 of 10

Which Windows file contains a compressed snapshot of physical RAM created when the system hibernates, and can be analyzed directly by Volatility?

C:\pagefile.sys

C:\Windows\MEMORY.DMP

C:\hiberfil.sys

C:\Windows\Minidump\

hiberfil.sys is written when Windows hibernates — it contains the full, compressed RAM state. Volatility supports direct analysis of hiberfil.sys with the appropriate profile. pagefile.sys contains virtual memory swap pages and cannot be analyzed by Volatility as a memory image. MEMORY.DMP is a crash dump (not hibernation). Minidump\ contains small crash dumps with limited process info.

Question 7 of 10

During memory analysis, Mimikatz and credential theft tools most commonly target which process to extract authentication material?

services.exe

csrss.exe

winlogon.exe

lsass.exe

lsass.exe (Local Security Authority SubSystem Service) is the primary credential store in Windows memory. It holds NTLM hashes, Kerberos tickets, and on older Windows with WDigest enabled, cleartext passwords. Mimikatz uses sekurlsa::logonpasswords to extract this data. Windows 8.1+ added PPL (Protected Process Light) to defend lsass.exe from unauthorized memory access.

Question 8 of 10

A memory dump shows svchost.exe with explorer.exe as its parent process. Why is this suspicious?

svchost.exe should not have any parent process on Windows 10

svchost.exe should always be the parent of explorer.exe, not the other way around

svchost.exe's legitimate parent must be services.exe — any other parent indicates masquerading or injection

svchost.exe cannot run while explorer.exe is active in the same session

Every legitimate svchost.exe instance must have services.exe as its parent — this is a hard rule. Malware frequently names itself svchost.exe (or a slight variation) to blend in, but spawning from explorer.exe, cmd.exe, or any non-services.exe parent immediately reveals the masquerade. The pstree Volatility plugin makes parent-child relationships clearly visible.

Question 9 of 10

Which Volatility plugin would you use to extract NTLM password hashes from a Windows memory image?

dlllist

malfind

hashdump

netscan

The hashdump plugin extracts NTLM hashes from the SAM and SYSTEM registry hives as they exist in memory. It locates the hive objects (using hivelist first), reads the SAM database, and decrypts the hashes using the SYSKEY from the SYSTEM hive. Output format is username:RID:LM_hash:NTLM_hash. These hashes can then be passed (PtH) or cracked offline.

Question 10 of 10

Reflective DLL injection differs from classic DLL injection primarily because:

It can only be used against 64-bit processes

The injected DLL maps itself into memory without using LoadLibrary, so it does not appear in the process's loaded module list

It requires kernel-mode execution rights to perform the injection

It can only inject into SYSTEM-level privileged processes

In Reflective DLL injection, the DLL contains its own loader routine that maps it into memory, resolves imports, and calls DllMain — all without touching the Windows loader or calling LoadLibrary. Because the Windows loader never processes it, the DLL does not appear in the PEB's loaded module list (which dlllist reads). Detection requires malfind or scanning raw process memory rather than querying the module list.

out of 10 correct

Review the explanations above for any questions you missed.

Memory Hooks

High-yield mnemonics and patterns for GCFA memory forensics questions.

🔍

pslist vs psscan

pslist walks the linked list — DKOM can unlink a process and hide it. psscan carves physical memory for EPROCESS pool tags — DKOM cannot erase this. Process in psscan but NOT pslist = DKOM-hidden rootkit process.

"psscan Sees what DKOM hides — it reads memory, not the list"

🔴

RWX = Red Flag

PAGE_EXECUTE_READWRITE is the memory protection of injected shellcode and unpacked malware. Legitimate code is RX (read + execute). Legitimate data is RW (read + write). RWX combines all three — required for self-modifying shellcode and most injection techniques.

"Legitimate code: RX only. RWX = attacker's playground"

🪄

malfind's Three Criteria

malfind flags a region when ALL three are true: (1) RWX or execute protection, (2) no file backing (anonymous / VadS), (3) starts with MZ header (0x4D 0x5A). One or two alone may be benign (JIT compilers, heap). All three together = very high confidence injection.

"MZ + RWX + no file = malfind gold"

🎭

Process Hollowing Tells

Three memory indicators of hollowing: (1) process image path in EPROCESS doesn't match VAD file backing, (2) main VAD region is VadS (anonymous) instead of file-backed, (3) malfind shows MZ header in process's base address. Also: unusual parent for the process name.

"Hollow = path says notepad.exe but VAD says anonymous"

🗝️

lsass = Credential Goldmine

lsass.exe holds: NTLM hashes (hashdump), Kerberos TGTs + service tickets, and on WDigest-enabled systems, cleartext passwords. Its parent must be wininit.exe. Single instance. If another process reads lsass memory → credential theft. PPL protects lsass on Win8.1+.

"lsass = the vault; Mimikatz is the safecracker"

👨‍👧

svchost Parent Rule

svchost.exe MUST have services.exe as parent. MUST run from C:\Windows\System32\. MUST have -k flag in command line. Any deviation = masquerading malware. Multiple instances are fine. No -k flag, wrong parent, or wrong path = immediate IOC.

"svchost without services.exe parent = faker"

High-Yield Facts for GCFA — Memory Forensics

Concept	Key Fact	Detection / Tool
DKOM	Unlinks EPROCESS from ActiveProcessLinks — hides from pslist	psscan finds hidden processes via pool tag scan
malfind	Finds RWX + no file backing + MZ header = injected PE	Volatility malfind plugin
Process Hollowing	Legitimate process shell, malicious PE inside; VAD shows no file backing at image base	malfind + vadinfo + procdump
Reflective DLL	Does NOT appear in dlllist — bypasses Windows loader entirely	malfind + memdump + YARA scan
hiberfil.sys	Full RAM snapshot from hibernation — Volatility can analyze directly	--profile with hiberfil.sys path
pagefile.sys	Swap file — NOT analyzable by Volatility; string search only	strings / bulk_extractor
lsass dump	Credential extraction target; procdump -ma lsass.exe or Task Manager	Volatility hashdump + lsadump
svchost rule	Parent must be services.exe; must have -k flag; from System32	pstree + cmdline
LiME	Only kernel-level Linux memory acquisition tool (loadable kernel module)	insmod lime.ko
WDigest	Legacy protocol; stores cleartext passwords in lsass on Win7/2008R2	Mimikatz sekurlsa::wdigest

Ready for More Practice?

Test yourself with full-length GCFA practice exams on FlashGenius.

Unlock Full Practice Tests on FlashGenius →

Flashcards

Click any card to flip it and reveal the answer.

Volatility Core Plugins

What is the difference between pslist and psscan, and when do you use each?

Click to flip

Answer

pslist: walks ActiveProcessLinks doubly-linked list — fast, but DKOM can unlink processes to hide them. psscan: scans physical memory for EPROCESS pool tag "Proc" — slower, but finds hidden processes. Compare both: process in psscan but not pslist = DKOM rootkit hiding it.

Process Hollowing

What are the 5 steps of Process Hollowing and how does malfind detect it?

Click to flip

Answer

1) CreateProcess (suspended) 2) NtUnmapViewOfSection (hollow out) 3) VirtualAllocEx + WriteProcessMemory (write malicious PE) 4) SetThreadContext (redirect entry point) 5) ResumeThread. Detection: malfind shows MZ header in anonymous (no file backing) VAD region at the process base address.

malfind Criteria

What three conditions does malfind require to flag a memory region as suspicious?

Click to flip

Answer

All three must be present: 1) RWX or execute memory protection (PAGE_EXECUTE_READWRITE), 2) No file backing — anonymous (VadS) region not linked to any file on disk, 3) MZ header (0x4D 0x5A) at the start of the region indicating an embedded PE file. Missing any one reduces confidence significantly.

LSASS Credentials

What credential types does lsass.exe store, and what protects it on modern Windows?

Click to flip

Answer

Stores: NTLM hashes, Kerberos TGTs and service tickets, WDigest cleartext passwords (Win7/older), cached domain credentials. Protection: PPL (Protected Process Light) on Win8.1+ prevents unauthorized process memory reads. Parent must be wininit.exe; single instance from System32. Mimikatz sekurlsa::logonpasswords extracts all stored creds.

Reflective DLL Injection

Why doesn't Reflective DLL injection appear in dlllist, and how do you detect it?

Click to flip

Answer

Reflective DLL injection bypasses the Windows loader — the DLL contains its own loader routine and maps itself without calling LoadLibrary. Since the Windows loader never processes it, it never appears in the PEB loaded module list (which dlllist reads). Detection: malfind (RWX + MZ + no file backing), followed by memdump of the process and YARA scanning the raw memory.

Legitimate Process Parents

What are the required parents for: svchost.exe, lsass.exe, csrss.exe, and explorer.exe?

Click to flip

Answer

svchost.exe → services.exe (+ must have -k flag, run from System32). lsass.exe → wininit.exe (single instance). csrss.exe → smss.exe (one per session, from System32\csrss.exe). explorer.exe → userinit.exe (which exits after launch, so appears parentless). Any deviation from these rules = masquerading or injection.

Memory Image Types

Which memory image types can Volatility analyze directly, and which cannot be analyzed by Volatility?

Click to flip

Answer

Volatility CAN analyze: Raw/DD dumps (.raw, .mem), hiberfil.sys (hibernation), VMware snapshots (.vmem), crash dumps (.dmp / MEMORY.DMP), LiME format (.lime), AFF4. Volatility CANNOT analyze: pagefile.sys (swap file — use strings/bulk_extractor instead). Always hash the image after acquisition for integrity.

DKOM Detection

What is DKOM and how does an analyst detect a process hidden by it?

Click to flip

Answer

DKOM (Direct Kernel Object Manipulation) removes a process from the ActiveProcessLinks doubly-linked list — hiding it from Task Manager, pslist, and any OS API traversing the list. Detection: run both pslist and psscan; any process appearing in psscan output but absent from pslist output has been unlinked by DKOM. Further investigate with handles, filescan, and netscan for the hidden PID.

Study Advisor

Choose a category for targeted guidance.

📌 Exam Strategy

⚠️ Common Mistakes

⚡ Quick Review

🔬 Deep Dive

🎯 Practice Tips

Exam Strategy — Memory Forensics

Always start with pstree: GCFA scenario questions frequently hinge on identifying suspicious parent-child relationships. Know the expected parent for each critical Windows process cold.
pslist vs psscan distinction: This is a favorite exam topic. Know that DKOM defeats pslist but not psscan, and that the comparison between the two outputs is how you detect hidden processes.
malfind's three criteria: Many questions about injection detection come down to malfind. Memorize: RWX + no file backing + MZ header = injection. Two out of three can have innocent explanations (JIT compilers, heap).
Injection technique identification: Questions may describe an attack and ask you to identify the technique. Key differentiators: process hollowing = suspended process + unmap; reflective DLL = not in dlllist; APC = alertable wait state.
hiberfil vs pagefile: Know that hiberfil.sys is Volatility-analyzable (full RAM snapshot) and pagefile.sys is not (swap fragments only). This distinction appears directly on exams.

Common Mistakes — Memory Forensics

Trusting pslist alone: Never conclude a process isn't present just because it doesn't appear in pslist. DKOM rootkits specifically target this. Always run psscan as well.
Assuming RWX = definite injection: JIT compilers in browsers, Java, and .NET legitimately use RWX memory. malfind's strength is combining RWX + no file backing + MZ header — all three together, not just RWX alone.
Expecting reflective DLL in dlllist: Reflective injection bypasses LoadLibrary and the PEB. dlllist will show nothing unusual. You must use malfind or raw memory scanning to detect it.
Confusing hiberfil and pagefile: pagefile.sys is swap, not a memory snapshot — you cannot use Volatility on it. hiberfil.sys IS a memory snapshot from hibernation. These are frequently confused under exam pressure.
Missing process masquerading: Malware named "svchost.exe" running from C:\Windows\ (not System32\) or with explorer.exe as parent is a classic trick. Path and parent are the two checks — run both cmdline and pstree.
Forgetting Volatility 2 profile vs Volatility 3: Vol2 requires --profile flag; Vol3 does not. If exam questions give you a Volatility command, check for the presence or absence of --profile to determine which version is being used.

Quick Review — Memory Forensics

pslist: Walks EPROCESS linked list — defeated by DKOM
psscan: Carves pool tags from physical memory — finds DKOM-hidden processes
malfind: RWX + no file backing + MZ header = injected PE
Process Hollowing: Suspended process → unmap → write malicious PE → resume
Reflective DLL: Self-loading DLL — NOT in dlllist; detect via malfind
APC Injection: Queue APC to thread in alertable wait state
DKOM: Unlinks EPROCESS from list; psscan is the counter-measure
lsass.exe parent: wininit.exe (single instance); credential store
svchost.exe parent: services.exe (must have -k flag; from System32)
hiberfil.sys: Full RAM from hibernation — Volatility-analyzable
pagefile.sys: Swap file — strings only, not Volatility-analyzable
hashdump: Extracts NTLM hashes from SAM + SYSTEM in memory
LiME: Linux kernel module — only true kernel-level Linux RAM acquisition

Deep Dive — Advanced Memory Concepts

EPROCESS structure internals: EPROCESS is the kernel data structure representing a process. Key fields: UniqueProcessId (PID), InheritedFromUniqueProcessId (PPID), ImageFileName (15 chars max — can be spoofed), ActiveProcessLinks (the list DKOM manipulates), Peb (pointer to user-mode Process Environment Block).
VAD tree structure: Each process has a VAD (Virtual Address Descriptor) binary tree in the kernel. Each node represents a virtual memory region with VPN start/end, protection, commit flags, and a FileObject pointer. vadinfo walks this tree. malfind queries it for suspicious protection + anonymous type combinations.
WDigest and cleartext passwords: Windows 7 and Server 2008R2 store cleartext credentials in lsass memory for WDigest (HTTP authentication protocol). WDigest can be disabled via registry: HKLM\SYSTEM\...\Control\SecurityProviders\WDigest UseLogonCredential = 0. Attackers sometimes re-enable it to harvest cleartext creds after gaining admin.
Golden Ticket attack: Attacker with KRBTGT hash can forge Kerberos TGTs for any user, valid for up to 10 years, even for disabled or non-existent accounts. Detected in memory: Kerberos tickets with anomalous lifetimes; non-standard encryption types; ticket for DC-level access from a workstation.
Process Doppelgänging (TxF): Uses Windows Transactional NTFS (TxF) to write malicious code within an NTFS transaction, map it as a section object, create a process from the section, then rollback the transaction — the file never persists to disk. Very few AV/EDR tools detect this. Volatility detection is limited; look for processes with transacted file handles.
Memory-only IOCs: Some C2 frameworks (Cobalt Strike, Metasploit Meterpreter) operate entirely in memory. IOCs include: beacon memory patterns (YARA rules for CS shellcode), unusual RWX regions in common processes, network connections from non-networking processes, and missing file backing for process image addresses.

Practice Tips — Memory Forensics

Build a Volatility command cheat sheet: List every plugin with its purpose and example output format. Drill these until you can map "detect hidden process" → psscan, "find injection" → malfind, "extract hashes" → hashdump, "network connections" → netscan instantly.
Practice with the SANS Memory Forensics course images: The FOR508 course includes sample memory images. Running actual Volatility commands against real images produces pattern recognition that reading alone cannot. Especially practice malfind output interpretation.
Process masquerading drill: Write out the expected parent, count, path, and flags for each of the 8 critical processes (System, smss, csrss, wininit, services, svchost, lsass, explorer). For each, write the deviation that indicates malware.
Injection identification scenarios: For each of the 7 injection techniques, practice identifying the technique from: the API sequence used, the Volatility plugin output that catches it, and the VAD characteristics. The GCFA often presents a scenario and asks which technique is described.
hiberfil vs pagefile practice questions: This distinction comes up repeatedly. Drill: "Can Volatility analyze X?" If pagefile → No. If hiberfil → Yes. If raw dump → Yes. If VMware .vmem → Yes.
MemLabs and DFIR.training CTFs: Free memory forensics CTF challenges (MemLabs on GitHub, DFIR.training) provide hands-on practice with real memory images and answers to verify against. These closely mirror GCFA scenario-based questions.