Memory Acquisition and Analysis in Incident Response

RFC 3227, published in 2002, formalised a collection order that most IR frameworks have since adopted: acquire evidence from the most volatile source first. In practice this means: CPU registers and cache (sub-second lifespan), RAM (lost on shutdown or reboot), swap and hibernation files (persistent but OS-managed), running process and network state (lost on reboot), disk images (persistent), and finally optical media or archival storage (persistent indefinitely).

In a live incident, the responder's first action on reaching a running system should be to verify the system is still running and then begin memory acquisition before any other collection step. This principle conflicts with two common impulses: the impulse to isolate the machine from the network immediately (containment) and the impulse to take a disk image first (because disk imaging is more familiar). Both of those impulses are wrong in an environment where fileless malware or an active attacker shell may be present. Network isolation can wait the ten to thirty minutes that memory acquisition takes on a typical server. Disk imaging can follow.

Memory acquisition also has a timing dimension: it is a snapshot of a specific instant. Active processes continue to change state during acquisition, which can produce minor inconsistencies in the image (a process list entry written halfway through acquisition). This is unavoidable and is accounted for in analysis. Longer acquisition times mean more potential inconsistency, so faster acquisition tools are preferred for large-RAM systems.

The three tools most commonly encountered in IR toolkits cover the two dominant operating-system families. All three produce a raw physical memory image or a compatible format that analysis frameworks can parse.

Magnet RAM Capture is a single executable dropped onto the target system from a USB drive or a network share. It installs and removes its own kernel driver, runs the acquisition, and writes a .mem file to a specified output path. Its GUI makes it accessible to responders who are not comfortable with command-line tools. WinPmem is preferred in environments that use KAPE or Velociraptor for remote live-response collection because it integrates cleanly with those platforms and supports the AFF4 container format, which preserves hash values and acquisition metadata alongside the image.

LiME on Linux requires planning ahead of time. The kernel module must be compiled against the exact kernel version running on the target: a module compiled for kernel 5.15 will not load on a system running 5.19. IR teams that cover Linux environments should maintain a library of pre-compiled LiME modules for the kernel versions deployed in their environment, stored in the forensic readiness toolkit. At acquisition time, the responder loads the module with insmod and specifies either a local output path or a remote TCP address to stream the image off the system without touching the local filesystem.

Memory analysis using Volatility or Rekall reconstructs OS data structures from raw bytes by applying kernel symbol information. The framework does not ask the OS what is running; it reads the linked lists and data structures that the OS uses internally. This means it can find processes, drivers, and network connections that the OS has been instructed to hide from its own reporting APIs.

• Running process list: Volatility's pslist, pstree, and psscan plugins reconstruct the process list from EPROCESS kernel structures. psscan walks physical memory looking for the signature of EPROCESS objects, which catches processes that have unlinked themselves from the standard doubly linked list to hide from pslist. Discrepancies between the two outputs indicate a hidden process.
• Injected code detection: The malfind plugin scans process virtual address spaces for regions marked as executable, readable, and writable that contain code-like content but have no backing file on disk. This is the memory signature of shellcode injected via CreateRemoteThread or reflective DLL loading. The plugin dumps the suspected region for manual review.
• Loaded drivers and kernel modules: The modules and driverscan plugins list loaded kernel-mode code. A rootkit that loads as a driver will appear in driverscan even if it has removed itself from the standard modules list. Cross-referencing the two outputs, and comparing against known-good baselines, surfaces unsigned or anomalous drivers.
• Network connections: The netscan plugin extracts TCP and UDP socket structures from memory, including connections that were already closed at acquisition time but whose structures had not yet been freed. This can reveal command-and-control connections to attacker infrastructure that are no longer visible in netstat output.
• Encryption keys: Key material for symmetric encryption (AES, ChaCha20) used by ransomware is held in RAM before and during encryption. Specialised plugins and carving tools (such as bulk_extractor) can scan memory images for RSA private keys, TLS session keys, Bitcoin wallet keys, and AES key schedules based on their known byte patterns. Recovering ransomware keys from a memory image is the fastest path to decrypting data without paying a ransom.
• Credentials in LSASS: On Windows systems where Credential Guard is not enabled, the Local Security Authority Subsystem Service (LSASS) holds NTLM hashes and, in some configurations, plaintext credentials in memory. The pypykatz Python library (a Mimikatz reimplementation for offline use) can extract these from a memory image without running any tool on the live system.

Memory analysis also recovers command history from terminal emulators (cmd.exe, PowerShell, bash), clipboard contents, and recently accessed registry keys that have been loaded into memory. In investigations involving insider threats or social engineering, these artefacts can establish what commands an attacker ran and in what order, filling gaps left by cleared log files.

Process injection is a technique where an attacker inserts and executes code inside the address space of a legitimate process, such as svchost.exe, explorer.exe, or a browser process. The injected code runs under the identity and privileges of the host process, making it invisible to process-level antivirus scans that look for malicious executable files. In memory, process injection leaves a characteristic signature: an executable memory region inside a process that has no corresponding file on disk.

The most common injection methods seen in real incidents are CreateRemoteThread (writes shellcode into another process's memory and creates a thread to execute it), APC (Asynchronous Procedure Call) injection (queues code execution to an existing thread, often used to abuse alertable wait states), and reflective DLL loading (a DLL that contains its own loader routine, allowing it to map itself into memory without calling the Windows LoadLibrary API). Cobalt Strike, the most widely deployed commercial red-team platform (and therefore the most widely abused attacker tool), uses all three techniques. Its default beacon runs as injected shellcode inside a sacrificial svchost.exe process.

Fileless malware extends the principle further. A PowerShell-based attack, for instance, may arrive as an email attachment that launches a macro, which executes a PowerShell one-liner, which downloads and runs a script entirely from memory without writing a file. The persistence mechanism may live in the registry (a Run key calling a PowerShell command), while the payload itself never touches disk. Memory forensics is the primary method for recovering the executed script content and the loaded modules the script imported.

A memory image is forensic evidence and must be handled with the same chain-of-custody discipline as a disk image. The moment acquisition completes, the responder should hash the image file (SHA-256 is the current standard; MD5 alone is no longer sufficient for court purposes) and record the hash alongside the acquisition time, the tool version used, the system identifier, and the name of the acquiring examiner. This information should be contemporaneously written, not reconstructed from memory later.

Admissibility requirements vary by jurisdiction but share a common structure. In the United States, the Federal Rules of Evidence (FRE) require that digital evidence be authenticated (shown to be what the proponent claims it is) and that its acquisition and handling be documented sufficiently to establish trustworthiness. In the United Kingdom, the Association of Chief Police Officers (ACPO) Good Practice Guide for Digital Evidence remains the reference standard: it requires that no action should change data on digital devices and that any person accessing digital evidence should be competent to do so and document their actions. India's Bharatiya Sakshya Adhiniyam 2023 (which replaced the Indian Evidence Act 1872) requires electronic records to be accompanied by a certificate from the examiner under Section 63, confirming the integrity of the collection process. The European Union's General Data Protection Regulation (GDPR) adds a parallel requirement: memory images taken from systems in EU jurisdictions may contain personal data of individuals, and the legal basis for processing that data must be documented.

The chain of custody document should record every person who accessed the image, the purpose of that access, and the date and time. Analysis tools that modify the image (rare, but possible with some older tools) should be avoided. Modern analysis frameworks operate on read-only copies or mount images read-only. When transferring an image to an analysis workstation or an external lab, a copy should be made, the original stored on write-protected media, and the transfer itself documented.

In cross-border incidents, where the compromised system is in one jurisdiction and the analysis team is in another, additional legal considerations apply. Mutual Legal Assistance Treaty (MLAT) processes may govern whether a memory image acquired in one country can be used as evidence in courts of another. IR teams conducting global response work should involve legal counsel at the point of acquisition, not after.

Memory acquisition and analysis do not stand alone: they feed into the broader IR workflow. The Detection Sources and Alert Pipelines topic covers how a SIEM alert or EDR detection triggers the response. Memory forensics is what a responder does after the triage decision has been made and a system has been confirmed as compromised. The findings from memory analysis feed back into containment decisions (which lateral movement paths did the attacker use?), eradication planning (which processes need to be terminated and which registry keys cleaned?), and the post-incident review.

In a SOC environment with endpoint detection and response (EDR) tooling deployed, the EDR agent often already acquires and transmits process memory telemetry continuously. Tools like CrowdStrike Falcon, Microsoft Defender for Endpoint, and SentinelOne maintain a rolling process tree with command-line arguments and injection alerts. This does not replace a full memory image: EDR telemetry is pre-filtered by the vendor's detection logic, while a raw memory image can be analysed with any tool and for any artefact class, including ones the EDR vendor did not anticipate. Both sources are valuable.

For organisations building forensic readiness, memory acquisition capability should be part of the pre-incident toolkit, not assembled after a breach is declared. This means: USB drives or network shares pre-loaded with acquisition tools for each supported OS, pre-compiled LiME modules for every Linux kernel version in the environment, a documented acquisition procedure included in the IR playbook, and periodic exercises where responders practice the acquisition workflow on non-production systems. NIST SP 800-61 r2 explicitly recommends that organisations develop and test their evidence collection procedures before an incident, not during one.

Memory forensics capabilities are also relevant to the cyber forensics and digital forensics disciplines more broadly, where the same Volatility-based analysis methods apply to images acquired from criminal investigations, civil litigation holds, and regulatory inquiries, not just IR engagements.