Memory Forensics Guide: Capturing and Analysing Volatile Evidence

The evidence that explains a modern intrusion often exists only in RAM, and it disappears the moment a responder reboots, isolates carelessly or reimages the host. Fileless implants, injected code, decrypted command and control configuration, live network connections and the credentials and tokens an attacker harvested all sit in volatile memory, not on disk. This guide covers when to capture memory, how to acquire it on Windows, Linux, virtual machines and containers without destroying it, how to analyse it with Volatility 3, and how to keep the evidence defensible. It is written for incident responders, DFIR analysts and SOC leads who need a repeatable, tested memory capability rather than an improvised one during a crisis.

Key takeaways

• Capture before you contain, where you safely can. RFC 3227 places memory near the top of the order of volatility and warns against shutting a system down before collection is complete.
• Acquisition is a prepared capability, not a download. Tested tools on trusted media, symbol tables staged in advance and an agreed upload path decide whether a capture succeeds at 3 a.m.
• Memory answers questions disk cannot. Injected code, hidden processes, live sockets, command lines and loaded drivers are visible in RAM even when the attacker left little on disk.
• Memory images are sensitive data. They contain passwords, session tokens, API keys and personal data, so store, transfer and destroy them like the most sensitive secrets you hold.
• Cross-check, never trust a single plugin. Comparing list-walking and scanning views (for example process lists against pool scans) is how rootkits and unlinked objects are found.

What memory forensics answers and when to use it

NIST SP 800-86 describes the forensic process in four phases (collection, examination, analysis and reporting) and states that acquiring volatile data should in many cases be given priority over non-volatile data. Memory forensics is the part of that process that deals with a snapshot of physical memory, or of a single process or container, taken while the system runs.

RFC 3227 sets out the order of volatility that responders still use: registers and cache; then routing table, ARP cache, process table, kernel statistics and memory; then temporary file systems; then disk; then remote logging and monitoring data; then physical configuration and network topology; and finally archival media. The practical consequence is that memory is collected before disk imaging and before any action that changes system state.

When to capture: an EDR alert for injection or credential access, a suspected implant on a server you cannot easily rebuild, a host that will be reimaged, any edge or appliance compromise where you can obtain a memory image from the vendor or hypervisor, and before you power off a ransomware-affected host that is still running (memory may hold key material or the operator's tooling). When it adds little: a host that has already rebooted, or a commodity infection fully explained by EDR telemetry, where disk and log evidence are enough.

Acquisition options by platform

Volatility 3 does not acquire memory itself; its documentation points analysts to separate acquisition tools and advises checking that a tool is maintained and compatible before use. Choose acquisition methods per platform in advance and test them on your current builds.

Choosing between methods

• Hypervisor over in-guest: where a workload is virtualised, a hypervisor capture is preferred because nothing runs inside the compromised guest and a rootkit has less opportunity to interfere. In public cloud the options depend on the provider; see the Cloud Forensics Guide.
• Static user-space tools over kernel modules on Linux: AVML needs no on-target compilation and no prior knowledge of the distribution, whereas LiME needs a module built for the exact kernel. Keep LiME for systems where /proc/kcore and /dev/crash are unavailable and you have built modules for your fleet in advance.
• Crash dumps as a fallback: a forced crash dump captures kernel state but reboots the host, loses anything not in the dump type configured and changes the system. Treat it as a last resort.
• EDR live response: many EDR platforms can run an approved acquisition tool remotely. This is the fastest route at scale, provided the binary, the driver signing and the upload destination have been tested. See the EDR Guide.

A defensible acquisition procedure

RFC 3227 asks responders to keep detailed, dated and signed notes, record whether timestamps are UTC or local time with any clock offset, change as little data as possible, avoid programs installed on the compromised system, and use tools from protected read-only media. The ordered procedure below turns that into practice.

1. Decide and record the reason. Note the incident reference, the host, who authorised capture and why memory is needed. Confirm legal hold or law enforcement involvement before acting.
2. Do not reboot, shut down or run clean-up. RFC 3227 warns that attackers may have altered startup or shutdown behaviour to destroy evidence, and that some systems wipe data when they detect they are offline. If containment is urgent, prefer network containment that keeps the host running and the acquisition channel open.
3. Record the system clock and identity. Note hostname, IP addresses, OS build or kernel version, uptime and the difference between the host clock and a trusted time source.
4. Run the acquisition tool from trusted media or a trusted EDR channel. Write the image to external storage or stream it off the host; never write it to the volume you may image next.
5. Hash the image immediately. Record a SHA-256 value at the point of collection and again after transfer. Where the tool supports streaming, hash on the receiving side.
6. Collect supporting volatile data. Pagefile and swap, hibernation files where present, and the EDR process and network telemetry for the same window give context the image alone may lack.
7. Then proceed down the order of volatility. Capture disk or targeted artefacts after memory. See the Windows Forensic Artefacts Guide.
8. Start the chain of custody record. RFC 3227 asks for where, when and by whom evidence was found, collected, handled and examined, who held it and for how long, how it was stored and how each transfer occurred.

Rollback and fallback: if an acquisition tool fails or the host becomes unstable, stop, record what happened and what was written to the system, and fall back to the next method in your platform matrix rather than retrying blindly. Acquisition always changes memory slightly; document the tool and version used so the change can be explained.

Analysing memory with Volatility 3

Volatility 3 is the open source framework most analysts use. Its documentation describes a context holding memory layers (data layers such as a LiME file stacked under translation layers such as Intel virtual memory), symbol tables that describe kernel structures, and plugins that return results through renderers including CLI tables, CSV, SQLite and JSON.

Symbol tables: the step that breaks most first captures

• Windows: Volatility reads the kernel's PDB GUID and age and looks for a matching table in its symbols directory. If none exists it downloads the PDB from the Microsoft Symbol Server and converts it. Analysis workstations that are offline need the symbol directory populated in advance (the documentation describes pdbconv.py for building tables manually).
• Linux and macOS: tables are built from a kernel with debug information using dwarf2json, and the banner in the JSON must match the banner in the image exactly. Run the banners plugin first. The Linux tutorial points to a community repository of pre-generated tables for some Debian, Ubuntu and AlmaLinux kernels; for custom or cloud kernels, keep debug kernels for every build you run.

Plugins that answer common questions

Plugin names change between releases (several Windows malware plugins now sit under windows.malware.*), so pin the Volatility version in your toolkit and record it in case notes. List what your version provides with vol -h rather than relying on old cheat sheets.

An analysis sequence that scales

1. Triage: confirm the image parses (windows.info or banners), then build a process tree with command lines and parent relationships. Look for unusual parents (an Office application spawning a shell), unexpected paths and processes running as SYSTEM that should not.
2. Cross-view: compare list-walking output with scanning output to find terminated, unlinked or hidden processes.
3. Code integrity: run injection plugins, then dump flagged regions and scan them with YARA rules from your threat intelligence. Expect false positives from JIT compilers and security products; verify each hit.
4. Network and credentials: map sockets to processes, and check which processes opened handles to LSASS or touched credential stores.
5. Pivot out: feed indicators (hashes, IPs, mutexes, command lines) into EDR and SIEM searches across the fleet. See the Threat Hunting Guide.

Container and cloud workload memory

Containers are short lived and frequently rescheduled, so container memory forensics depends on capturing state before the orchestrator replaces the pod. Kubernetes provides a kubelet checkpoint API, beta since v1.30 and enabled by default, which uses Checkpoint/Restore In Userspace (CRIU) through the container runtime to create a stateful copy of a running container. The Kubernetes documentation notes that the copy can be moved to another machine, restored to continue from exactly the same point, or inspected with suitable tools, and the original container is not aware it was checkpointed.

• Prepare the runtime: checkpointing needs a runtime and CRIU build that support it. Test it on each node pool image before you need it.
• Restrict the API: the checkpoint call goes to the kubelet, so only the incident response role should be able to reach it. A checkpoint archive holds the container's memory and therefore any secrets it had loaded.
• Restore only in isolation: restoring a compromised container recreates the attacker's process state, so do it in a sandboxed cluster with no egress.
• Node level alternative: when a whole node is suspected, capture node memory with AVML or a hypervisor snapshot, which includes every container process on that node. Process-level views then need mapping back to pods using namespaces and cgroup information.
• Pause before evicting: cordon the node and stop automated remediation that would delete the pod; label the pod so autoscaling does not replace it before capture.

See the Container Runtime Security Guide and the Cloud Incident Response Guide for runtime detection and containment.

Where identity fits

Memory is where identities are most exposed. Cached domain credentials, Kerberos tickets, OAuth access and refresh tokens, cloud CLI credentials, database connection strings and service account secrets all appear in process memory while in use. Two consequences follow.

• Scope the credential reset from memory evidence: if analysis shows an attacker accessed LSASS (T1003.001) or a process holding tokens, treat every identity that was logged on or cached on that host as compromised, including service accounts and machine identities, and rotate them. The Ivanti Connect Secure exploitation in 2024 shows the pattern: after compromising the gateway, attackers harvested credentials and dumped LSASS memory on internal systems. See the Identity Incident Response Playbook.
• Protect the image itself: a memory image is a credential store. Encrypt it at rest, restrict access to named analysts, never upload it to public analysis services, and record its destruction at case closure. The upload credential used by AVML or EDR live response (a SAS token or pre-signed URL) should be write-only, short lived and generated on a separate trusted host, as the AVML documentation recommends for pre-signed URLs.

Detection, measurement and readiness

A memory capability is only proven when it works on demand. Track readiness and use as part of the incident response programme.

• Acquisition success rate: percentage of attempted captures that produced a parseable image, by platform. A falling rate usually means a new OS build, kernel or driver blocklist change.
• Time to capture: median minutes from decision to verified, hashed image in evidence storage. Set a target per tier (for example under 30 minutes for critical servers) and test it in exercises.
• Symbol coverage: percentage of running OS builds and kernels for which symbol tables are pre-staged.
• Capture before change: share of high-severity incidents where memory was captured before reboot, isolation that broke access, or reimage.
• Findings yield: how often memory analysis produced an indicator or conclusion not available from EDR or disk. This justifies the effort and shows where to invest.
• Evidence handling: percentage of images with complete hash, custody and destruction records.

Watch for the adversary side too: attempts to load unknown kernel drivers, tampering with ETW (windows.etwpatch helps confirm it in memory) and unexpected handles to LSASS are detection opportunities that also trigger a memory capture. See the EDR Evasion and Defence Guide.

Framework mapping

Common failure patterns

• Rebooting or reimaging first: an infrastructure team "fixes" the host before IR is engaged, and the fileless implant and its configuration are lost. Put memory capture into the runbook before any rebuild step.
• Untested tools on new builds: a driver is blocked by a vulnerable-driver blocklist or kernel lockdown, or a LiME module does not match the patched kernel, and the first attempt fails during the incident.
• No symbols on an offline workstation: analysis stalls for hours because the air-gapped analysis host cannot download PDBs or the cloud kernel's debug package was never kept.
• Writing the image to the evidence disk: the capture overwrites unallocated space on the drive you later need to image.
• Images treated as ordinary files: memory images copied to shared drives or uploaded to a public sandbox expose the credentials they contain.
• Single-plugin conclusions: a clean pslist is reported as "no malware" without cross-view or injection checks, missing hidden or injected code.

Practitioner checklist

• Publish an acquisition matrix covering every OS, kernel family, hypervisor and container platform you run, with a primary and fallback method.
• Stage signed, version-pinned acquisition tools on trusted media and in the EDR live response library, and test them each quarter on current builds.
• Pre-configure Windows crash dump settings on critical servers where a dump fallback is acceptable.
• Pre-stage Volatility 3 symbol tables for all Windows builds and Linux kernels in use, and keep debug kernels for custom images.
• Add "capture memory before reboot, rebuild or isolation that blocks access" to incident and change runbooks.
• Hash every image at collection and after transfer, and keep a chain of custody record from the first minute.
• Store images encrypted with named-analyst access, and record destruction at case closure.
• Rotate every credential and token exposed on hosts where memory shows credential access.
• Test the kubelet checkpoint workflow and node-level capture for each Kubernetes node pool.
• Measure acquisition success rate, time to capture and symbol coverage, and review them after each incident.

Standards and references

• IETF: RFC 3227 Guidelines for Evidence Collection and Archiving
• NIST: SP 800-86 Guide to Integrating Forensic Techniques into Incident Response
• NIST: SP 800-61 Rev. 3 Incident Response Recommendations and Considerations for Cybersecurity Risk Management
• Volatility Foundation: Volatility 3 Symbol Tables
• Microsoft: AVML Acquire Volatile Memory for Linux
• 504ENSICS Labs: LiME Linux Memory Extractor
• Kubernetes: Kubelet Checkpoint API
• MITRE ATT&CK: Process Injection

Related NHI Mgmt Group resources: Digital Forensics (DFIR) Guide · Incident Response Guide · Network Forensics Guide · Linux Detection and Response Guide · Digital Forensics Tools Buyer's Guide