Memory acquisition captures the contents of RAM from a live system so analysts can inspect running processes, injected code, network sockets, decrypted material, and other transient artefacts. It must be done carefully because the capture process itself can change the system. Practitioners verify the image, document the method, and preserve chain of custody.
What memory acquisition is actually collecting
memory acquisition is the process of capturing volatile RAM from a live system so investigators can analyse whatever was resident at the moment of capture. That includes active processes, loaded modules, injected code, open network sockets, decrypted material, and other short-lived artefacts that may never reach disk. It is most useful when you need a point-in-time view of system state rather than a filesystem-only snapshot.
The practical value of the method is that it can expose execution context that disk forensics cannot see. A live image may show malware that is unpacked only in memory, credentials or tokens that are present briefly during use, or traces of lateral movement that vanish after reboot or process exit. For a broader workflow view, Digital Forensics (DFIR) Guide covers how memory acquisition fits into evidence handling, order of volatility, and follow-on analysis.
How the capture process works in practice
Acquisition normally starts by deciding whether the system can stay running long enough to be collected safely. On a workstation or server, practitioners typically use a trusted acquisition tool to read physical memory or kernel-exposed memory regions and write the result to a file or forensic target. In cloud or virtualised environments, the equivalent may be a hypervisor, snapshot, or provider-supported collection path rather than a local tool on the guest.
Because RAM changes constantly, the operator tries to minimise delay and avoid unnecessary interaction with the live host. The capture method should be documented so later reviewers can understand what was read, from where, and under what conditions. In environments where the same incident spans cloud and endpoint evidence, the Cloud Incident Response Guide is a useful companion for handling volatile evidence, snapshot forensics, and containment decisions.
What matters most is that the image is treated as evidence, not just a copy. Analysts generally preserve metadata about the tool, time, host state, and collection path, then verify the resulting file with hashes or other integrity checks before analysis begins. The goal is not only to get the bytes, but to be able to defend how they were obtained.
What analysts look for after acquisition
Once the memory image is collected, the analyst inspects it for signs of live execution and hidden activity. Common review targets include process trees, command lines, code injection, suspicious handles, sockets, decrypted secrets, in-memory configuration, and traces of malware that never touched persistent storage. Memory analysis can also help confirm whether a running process is genuine, hollowed, or hosting something injected into it.
Interpretation is usually strongest when memory findings are correlated with disk artefacts, logs, and network evidence. A memory image may explain how a machine was operating at a specific moment, but it rarely stands alone as a complete incident narrative. If the live system was altered during collection, that change has to be accounted for during analysis so the team does not mistake acquisition side effects for attacker behaviour.
Risk and Threat Considerations
Memory acquisition is inherently intrusive because the act of collecting volatile data can alter the system state you are trying to preserve. It also targets the richest live evidence on a compromised host, which means an active attacker may react to the collection, terminate processes, or trigger self-protection when the system is still online.
Failure mechanism: The collection tool, operator activity, or host response changes process timing, memory contents, or execution state, which can corrupt the evidentiary value of the image or miss short-lived artefacts entirely.
Impact: Investigators may lose transient evidence, misread the compromise timeline, or produce an acquisition record that is harder to defend in incident response, legal, or disciplinary review.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Memory acquisition can expose live secrets and sessions that require strict credential handling. |
| AU-9 — Protection of Audit Information | Forensic images and collection records must preserve evidentiary integrity and chain of custody. | |
| SI-4 — System Monitoring | Memory acquisition supports detection of injected code, live malware, and suspicious runtime behaviour. | |
| Recommendation — Rotate exposed credentials and limit reuse when volatile memory may have contained them. Protect acquisition logs and hashes so evidence integrity can be defended later. Collect volatile memory when monitoring suggests live compromise or runtime tampering. | ||
| CIS Controls v8 | CIS-8 — Audit Log Management | Memory acquisition is often used to corroborate live activity with other forensic records. |
| Recommendation — Preserve supporting logs so memory findings can be correlated and verified. | ||
| MITRE ATT&CK | T1003 — OS Credential Dumping | Live memory may contain decrypted credentials or tokens attackers can access. |
| Recommendation — Hunt for credential-dumping indicators when memory contains authentication material. | ||
Practitioner Guidance
What to verify: Confirm that the acquisition method matches the evidence goal. If the question is malware execution, injected code, or decrypted material, memory capture is usually the right first volatile artefact; if the goal is only attribution or persistence review, pair it with process, log, and disk evidence rather than relying on RAM alone.
Decision rule: If the system is still potentially active, prioritise fast, low-interaction capture and preserve the collection record before deeper triage. If the host is already unstable or likely to self-protect, document that condition and accept that the image may be incomplete rather than forcing repeated attempts that further change state.
Practitioner takeaway: The quality of memory acquisition is measured less by how much data you collect than by whether you can explain exactly how the live state changed, or did not change, during collection.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 18, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org