GCFA · Domain 2
Memory Forensics
About 25% of the exam
Why memory first
- Encryption keys live only in RAM
- Injected code never touches the disk
- Network state dies at shutdown
- Unpacked malware is decrypted in memory
- Command history survives in process memory
- Rootkits hide from the running operating system
Memory answers what was running; disk answers what was installed. Most intrusions need both
Acquisition methods
- Software agent
- fast, but the host cooperates
- Hardware capture
- bypasses a subverted operating system
- Hypervisor snapshot
- guest memory captured from outside
- Crash dump
- kernel dump with a run map
- Hibernation file
- compressed RAM copy on disk
- Page file
- evicted pages, not full memory
- Cold boot
- rare, chilled DRAM remanence
Acquisition pitfalls
- The capture tool changes the memory it reads
- Smearing occurs while the system keeps running
- Wrong architecture misparses every structure
- A rootkit can lie to a software agent
- Record the tool, version and format
- Hash the capture the moment it lands
- Collect the page file alongside the image
Formats and profiles
- Raw
- flat physical memory, no metadata
- Crash dump
- header describes physical run map
- AFF4
- compression plus rich container metadata
- Windows symbols
- debug symbols fetched per build
- Linux symbol table
- built from that exact kernel
- Bitness
- pointer size changes every structure
Plugin families
Process view
- List walking shows the linked processes
- Pool scanning finds unlinked survivors
- Tree view exposes impossible parentage
- Command line and environment per process
- Handles, tokens and loaded modules
Kernel view
- Module list versus module scan
- Driver objects and their dispatch tables
- Registered notification callbacks
- System call and inline hooks
- Service records recovered from memory
Data recovery
- Registry hives mapped into memory
- Network endpoints with owning process
- Dump a process image for static work
- Extract files from the cache
- Scan the image with signature rules
Scanning finds what list walking hides, so run both and treat the difference as a finding
Process anomalies
- System binary running from a user path
- Misspelled or doubled system process names
- Wrong parent for a service host
- Office application spawning a shell
- No command line on a running process
- Session or user does not fit
- Started long after the boot burst
Injection techniques
- Classic injection
- allocate, write, create remote thread
- Process hollowing
- image unmapped and replaced wholesale
- Reflective loading
- module maps itself, no loader
- Module stomping
- legitimate module overwritten in place
- Section mapping
- shared section instead of direct writes
- Hooking
- installed hook pulls code inside
- Doppelganging
- transacted file backs the image
Finding injected code
- Private committed pages marked executable
- Region with no backing file
- Memory image differs from the disk image
- Mismatched base address after hollowing
- Headers stripped from a mapped module
- Confirm the protection flags before calling it
- Just in time compilers cause false positives
Rootkit and stealth hunting
- Compare two enumeration methods, trust neither
- Unlinked drivers appear only to scanners
- Dispatch table entries pointing outside the driver
- Unsigned driver loaded from a writable path
- Callbacks registered for stealthy execution
- Hidden connections owned by dead processes
From memory to conclusion
- Verify image and profile
- Process and parent review
- Injection and module scan
- Network and handle pivot
- Dump and analyze suspects
- Corroborate on disk
Pivot points
- Suspicious process to its loaded modules
- Module to its on-disk path
- Endpoint to the owning process
- Mutex or pipe name to the family
Corroboration on disk
- Prefetch and Amcache confirm execution
- Service and task records confirm persistence
- Journal entries date the dropped file
- Event logs place the logon in time
A memory finding becomes evidence when a disk or log artifact agrees with it independently
Beyond Windows
- Linux needs symbols for that kernel build
- Check loaded modules against the on-disk list
- Look for hidden processes in the task list
- Bash history may survive in memory
- macOS captures need matching kernel structures
- Containers share the host kernel memory
Secrets in memory
- Credential material
- hashes and tickets in process memory
- Cached domain logons
- recovered from mapped security hives
- Volume keys
- full disk encryption keys resident
- Clipboard
- recently copied text and paths
- Console buffers
- typed commands and their output
- Certificates
- private keys held by processes
Capture memory before the machine sleeps or locks, or the volume keys go with it
Key artifacts
- Process structure
- name, parent, times, token
- Address descriptors
- region protection and backing file
- Process environment block
- image path, command line, modules
- Pool tags
- signatures that make scanning possible
- hiberfil.sys
- compressed memory image on disk
- pagefile.sys
- evicted pages, strings and keys
- Kernel callbacks
- notification routines abused for stealth
Know the order
- Document the running state
- Capture memory
- Capture the page file
- Hash and verify
- Analyze a copy
- Corroborate on disk
Never analyze the only capture you have; work from a verified copy and keep the original sealed
Reference strip: memory analysis
Acquisition sources
- Live agent capture
- Hypervisor or hardware capture
- Hibernation file and crash dump
- Page file and swap
Plugin families
- Process listing and scanning
- Module and driver enumeration
- Network endpoint recovery
- Injection and hook detection
- Registry, files and timelines
Injection names
- Hollowing and module stomping
- Reflective and manual mapping
- Section and atom based injection
- Hook and callback abuse
Red flags
- Executable private memory, no file
- Unsigned driver from a temporary path
- Connection owned by a missing process
- System name running from user space
Corroborating artifacts
- Prefetch and Amcache
- Service install and scheduled task
- Change journal and file times
- Proxy, firewall and DNS logs
Quick exam traps
- Trap: A clean process list proves nothing is hidden
- Trap: Memory capture leaves the system untouched
- Trap: Executable private memory always means malware
- Trap: The hibernation file is a full live memory capture
- Trap: One symbol profile fits every Linux kernel
- Trap: Process hollowing and DLL injection look the same in memory
- Trap: Terminated connections cannot appear in a capture
cybercertprep.com · original revision sheet written from the public body of knowledge