Chapter 22 — Key Takeaways

The big idea

Memory is the most fragile evidence there is and, increasingly, the most decisive — because RAM holds the live state of the machine, and the live state is where encryption keys, running processes, network connections, and fileless code actually exist. A perfectly imaged disk can be a wall of ciphertext you cannot read, while the key that opens it sits in the RAM of the machine in front of you; an advanced intrusion may leave nothing on disk because the implant runs from memory and exfiltrates over an encrypted channel. The skill of memory forensics is therefore two skills bolted together: an acquisition discipline (capture before power-off, to external media, hashed immediately, on the one evidence you can never re-acquire) and an analysis discipline (build the model, scan as well as list, and corroborate a finding across independent structures before you call it). Every action still leaves a trace — and in RAM, as on disk, the data outlives the pointer.

Acquire before you power off

  • Order of volatility (RFC 3227): RAM sits near the top. If a system is live and lawfully accessible, acquire memory before power-off — the decision is irreversible, because a drive can be re-imaged but RAM is captured exactly once.
  • Write to external, removable media, never the system's own disk; hash immediately and log the tool, version, times, size, and SHA-256.
  • What the hash proves: integrity since capture — not that the image is a perfect atomic snapshot. State both halves; a running system smears.
  • Memory also lands on disk: hiberfil.sys (compressed snapshot), pagefile.sys/swap (evicted pages), crash dumps (.dmp), and VM .vmem (closest to atomic — pause and copy). Analyze these from your verified disk image when the live moment has passed.
Platform Tools Note
Windows FTK Imager, WinPmem, DumpIt, Magnet/Belkasoft Include the pagefile
Linux LiME (kernel module), AVML (userland static binary) AVML when you can't match kernel headers; record uname -a + symbols
VM Copy .vmem/.vmss/.vmsn; Hyper-V checkpoint The hypervisor is your write-blocker

Build the model, then list and scan

  • Memory is pages; each process has a virtual address space rooted at its DTB (the CR3 value). No DTB, no translation — and a missing pagefile means paged-out regions silently fail to resolve.
  • Processes are _EPROCESS structures in a doubly-linked list (FLINK/BLINK) anchored at PsActiveProcessHead. Pool allocations carry a four-byte pool tag (Proc = 50 72 6F 63, TcpE, etc.).
  • pslist walks the list; psscan sweeps for the pool tag. A DKOM rootkit unlinks itself from the list but cannot remove its tagged structure — so the diff between pslist and psscan is the hidden process.

Detect code that touched no disk

Plugin Finds Signature
malfind Injected code / shellcode private + RWX + 4D 5A (MZ) — a lead, not a verdict
ldrmodules Reflective DLL injection False/False/False across the 3 PEB lists, no path
pstree+cmdline Process hollowing wrong parent, wrong path, no -k; in-memory image ≠ on-disk binary
modules vs modscan Kernel rootkit scan finds a driver the list omits

Corroborate across parentage, protection bits, loader lists, network ownership, and on-disk hash comparison — correlation is what survives cross-examination. netscan attributes a live connection to a process; cmdscan/consoles recover the attacker's typed commands (and output); printkey/hashdump reach registry and credentials within authority. Extract with pslist --dump/memmap --dump/dumpfiles, and recover FDE keys with bulk_extractor/aeskeyfind.

You can now…

  • ☐ Explain why memory is essential evidence and place RAM correctly in the order of volatility, capturing it before power-off.
  • ☐ Acquire memory with the right tool per platform — to external media, hashed immediately, with a defensible chain of custody — and source it from hiberfil/pagefile/crash dumps/VM .vmem when no live capture exists.
  • ☐ Drive Volatility 2 and 3 to enumerate processes, network connections, DLLs, handles, registry, credentials, and console history.
  • ☐ Detect in-memory malware — injected RWX-MZ code, reflective DLLs, process hollowing, and kernel rootkits — by scanning as well as listing and corroborating across structures.
  • ☐ Recover keys, executables, and data from memory, feed a timeliner bodyfile into your master timeline, and state every finding's limits honestly.

Looking ahead

Chapter 23 — Network Forensics. Follow the C2 connection you found in memory out onto the wire: packet captures, flow records, protocol analysis, and the artifacts of communication — proving not just what ran on a host but what it said to the world. Technology changes; principles don't.

One sentence to carry forward: Pull the plug and the disk waits for you forever, but the memory — the keys, the live connections, the code that never touched storage — is gone in seconds, so you capture it first, hash it once, and report exactly what it proves.