12.1 Volatile Memory Acquisition: RAM Capture, Crash Dumps, Hiberfil.sys & Pagefile.sys

12.1 Volatile Memory Acquisition: RAM Capture, Crash Dumps, Hiberfil.sys & Pagefile.sys

Quick Answer: Under RFC 3227 (Order of Volatility), physical RAM is the most volatile and perishable digital evidence on a running system. Live acquisition tools must load a signed Ring 0 kernel driver (e.g., WinPmem, DumpIt, or LiME) to bypass memory protections and map physical RAM. Because the host OS continues running during acquisition, physical memory capture exhibits memory smearing (page smearing), meaning pages captured at the beginning of the dump reflect a slightly different point in time than pages captured at the end. Non-volatile physical memory artifacts include hiberfil.sys (compressed via LZNT1 or Xpress Huffman algorithms and decompressed via Volatility imagecopy or hibr2bin), pagefile.sys (storing paged-out 4 KB virtual memory frames containing cleartext credentials and terminated process fragments), and crash dumps (MEMORY.DMP) spanning Complete, Kernel, and Minidump formats.

---

The Order of Volatility & Live Memory Significance

In contemporary incident response and digital forensics, physical Random Access Memory (RAM) represents the ultimate source of operational ground truth. While traditional disk forensics captures dormant files, file metadata, and unallocated cluster remnants, volatile memory forensics exposes the live state of an executing system.

According to RFC 3227 (Guidelines for Evidence Collection and Archiving), evidence must be collected in order of decreasing volatility to minimize data destruction caused by routine operating system functions, hardware power loss, or deliberate anti-forensics triggers.

+-------------------------------------------------------------------------+
|                    RFC 3227 ORDER OF VOLATILITY                         |
+-------------------------------------------------------------------------+
| Priority 1 (Most Perishable): CPU Registers, CPU On-Die Cache (L1/L2/L3)|
| Priority 2: Routing Tables, ARP Cache, Process Table, Kernel Statistics |
| Priority 3: Volatile System Physical Memory (RAM)                       |
| Priority 4: Temporary File Systems / Swap Space / Paging Files          |
| Priority 5: Persistent Storage Disks (HDD, SSD, NVMe, USB)              |
| Priority 6: Remote Logging, Network Topology, Physical Cabling          |
| Priority 7 (Least Perishable): Archival Media (Backup Tapes, Optical)   |
+-------------------------------------------------------------------------+

Critical Artifacts Residing Solely in Volatile RAM

Modern malware families—specifically fileless loaders, reflective dynamic link libraries (DLLs), Cobalt Strike Beacon payloads, and in-memory shellcode—deliberately avoid writing operational binaries to persistent disk storage. Seizing or powering off a suspect machine destroys:

• Decrypted Cryptographic Keys: BitLocker full-volume encryption keys (FVEK), VeraCrypt keys, TLS session master keys, and private asymmetric RSA/ECC keys residing in process memory.
• Ephemeral Network Connections: Active and half-closed TCP/UDP sockets, listening daemon ports, remote C2 IP endpoints, and DNS resolution caches.
• Injected Code & Unlinked DLLs: Memory regions allocated via VirtualAllocEx with PAGE_EXECUTE_READWRITE permissions hosting unpacked shellcode or Cobalt Strike reflective loaders.
• Cleartext Credentials & Keystrokes: Plaintext passwords held in the memory space of lsass.exe (Local Security Authority Subsystem Service), web browsers, SSH clients, or password management utilities.
• Process & Thread Structures: Kernel objects, Parent-Child Process IDs (PPID/PID), command-line arguments, process start timestamps, and Direct Kernel Object Manipulation (DKOM) modifications.

---

Physical Memory Acquisition Challenges & Kernel Internals

Capturing the physical memory of an energized computing endpoint introduces substantial technical, architectural, and forensic challenges.

Suspect System (Ring 0 Kernel)
+-------------------------------------------------------------+
| Physical RAM Addresses (0x00000000 - 0x3FFFFFFFF [16 GB])   |
+-------------------------------------------------------------+
       |                                      ▲
       | Sequential Reading Pass              | Host OS Modifying
       ▼ (Starts at T=0 sec)                  | Running Pages
+---------------------------+                 | (At T=15 sec)
| Linear Capture Engine     |                 |
| (DumpIt / WinPmem / LiME) | ----------------+
+---------------------------+
       | Writes Output Stream
       ▼
+-------------------------------------------------------------+
| Raw Memory Image (*.raw / *.lime)                           |
| --> Exhibiting Memory Smearing Across Page Boundaries        |
+-------------------------------------------------------------+

The Memory Smearing Phenomenon

Unlike static storage media, which can be write-blocked and imaged with complete byte-for-byte immutability across repeated passes, physical RAM cannot be frozen instantaneously during live software acquisition:

• Memory capture tools execute sequentially from the lowest physical memory address (e.g., 0x00000000) to the highest installed RAM address.
• On a workstation with 64 GB of RAM, dumping physical memory across a USB 3.0 bus or network socket requires several minutes.
• While the imaging utility is reading page N, active CPU cores continue executing kernel interrupts, scheduling background threads, handling network packets, and modifying page N+500,000.
• Memory Smearing (Page Smearing) refers to the temporal inconsistency across memory pages within a single dump file. Pages captured at second 1 represent the system state at second 1, while pages captured at second 180 represent the system state at second 180.
• Forensic Implication: While cross-page references (e.g., a process linked list pointing to a structure that was deallocated during capture) may occasionally show minor pointer desynchronization, kernel objects within individual 4 KB pages generally maintain structural integrity.

Ring 0 Kernel Driver Requirements

Modern operating systems strictly enforce hardware-enforced memory isolation:

• Deprecation of PhysicalMemory Handle: Prior to Windows Server 2003 SP1, user-mode applications with Administrator privileges could open a handle to \\Device\\PhysicalMemory to read arbitrary physical addresses. Microsoft permanently restricted user-space access to this device object to mitigate kernel-level exploitation.
• Signed Kernel Drivers: To read physical memory in Windows Vista through Windows 11 and Windows Server 2022, acquisition tools must dynamically install and start a cryptographically signed kernel-mode driver (Ring 0). The driver invokes low-level kernel APIs (such as MmMapIoSpace or ZwMapViewOfSection) to map physical address ranges into the driver's system virtual address space before transferring the data buffers back to the acquisition engine.
• Address Translation & CR3 Register: In x86/x64 systems, virtual memory addresses are translated to physical RAM addresses via page tables. The hardware CPU register CR3 (Control Register 3), also known as the Directory Table Base (DTB), holds the physical base address of the top-level page directory (PML4 in 64-bit Windows) for each process. Memory acquisition tools capture raw physical memory; forensic frameworks (such as Volatility) reconstruct virtual process spaces by reading the CR3 register stored in each process's _KPROCESS structure.

---

Enterprise RAM Acquisition Toolsets

Forensic examiners must select acquisition utilities that maximize physical RAM extraction completeness while minimizing the tool's footprint on the target endpoint.

Practical Command-Line Implementations

1. Live Windows Acquisition with WinPmem

To acquire volatile RAM on an enterprise Windows 11 endpoint without installing third-party software, examiners execute WinPmem from an external write-blocked or read-only storage device:

:: WinPmem command-line execution for raw linear capture
E:\Tools\winpmem.exe -o D:\Cases\CASE-2026-12\RAM_SUSPECT01.raw --volume_mode 2

:: Capturing into an AFF4 container preserving page-map metadata
E:\Tools\winpmem.exe -o D:\Cases\CASE-2026-12\RAM_SUSPECT01.aff4 --format aff4

2. Live Linux Acquisition with LiME

Because Linux lacks a unified, binary-compatible kernel driver across all distributions, LiME must be compiled against the specific running kernel version of the target system (or compiled on an identical forensic staging workstation running matching kernel headers):

# Check kernel release on target Linux host
uname -r
# Output: 5.15.0-72-generic

# Insert LiME kernel module to dump RAM directly to local forensic mount
insmod lime-5.15.0-72-generic.ko "path=/mnt/forensic_usb/linux_ram.lime format=raw"

# Alternatively: Stream physical RAM across the network over an encrypted or raw socket
# On Forensic Workstation (Receiver):
nc -l -p 4444 > /cases/CASE-2026/linux_ram.raw

# On Target Suspect Host (Sender):
insmod lime-5.15.0-72-generic.ko "path=tcp:192.168.10.50:4444 format=raw"

# Remove kernel module immediately after capture completion to restore stability
rmmod lime

[!WARNING] Executing any binary on a live system alters volatile RAM state. The operating system must load the acquisition executable into memory, allocate heap and stack space, modify NTFS $MFT and $UsnJrnl records, create process execution tracking artifacts (Prefetch, Shimcache), and overwrite unallocated RAM blocks. Examiners must record the exact tool size, file path, command line, and execution timestamp in their contemporaneous notes to account for tool-induced memory changes.

---

Non-Volatile Memory Containers: Hiberfil.sys & Pagefile.sys

Physical RAM is not the only source of memory artifacts. Operating systems frequently persist volatile memory contents to magnetic or solid-state storage to support power management and virtual memory pagination.

+-------------------------------------------------------------------------+
|               NON-VOLATILE MEMORY CONTAINERS ON DISK                    |
+-------------------------------------------------------------------------+
| Container Path  | OS Purpose             | Compression / Architecture   |
|-----------------|------------------------|------------------------------|
| hiberfil.sys    | Preserves RAM for      | Compressed:                  |
| (Root of OS,    | ACPI S4 Hibernate      | • Win 7/8: LZNT1 algorithm   |
|  typically C:\) | state during shutdown  | • Win 10/11: Xpress Huffman  |
|-----------------|------------------------|------------------------------|
| pagefile.sys    | Swaps inactive virtual | Uncompressed raw 4 KB        |
| (Root of OS,    | memory pages to disk   | virtual memory pages;        |
|  typically C:\) | to free physical RAM   | unindexed heap/stack blocks  |
|-----------------|------------------------|------------------------------|
| swapfile.sys    | Swaps Universal Win    | Paged UWP application frames;|
| (Root of OS)    | Platform (UWP) apps    | introduced in Windows 8      |
|-----------------|------------------------|------------------------------|
| MEMORY.DMP      | Post-kernel crash dump | Complete, Kernel, Minidump,  |
| (%SystemRoot%)  | (BSOD / Bug Check)     | or Active Dump structures    |
+-------------------------------------------------------------------------+

1. Windows Hibernation File (hiberfil.sys)

When a Windows system enters the ACPI S4 hibernation state, the operating system suspends execution and writes the entire contents of active physical memory to C:\\hiberfil.sys. This enables the workstation to power down completely and restore open applications upon reboot.

Internal Structure & Compression

• Header Signatures: The file begins with a PO_MEMORY_IMAGE structure. In Windows 7, the signature bytes reflect HIBR (0x52424948). In modern Windows 10 and 11 builds, the signature displays WAKE (0x454B4157).
• Compression Mechanics: Hibernation files are never raw physical memory dumps. Writing uncompressed RAM to disk would incur excessive disk write latency. Windows 7 and 8 utilize Microsoft's proprietary LZNT1 (Lempel-Ziv) compression algorithm. Windows 10 and 11 utilize Xpress (MS-XPRESS) Huffman compression.
• Decompression to Raw DD Images: Forensic analysis frameworks cannot analyze compressed hibernation files directly without decompression. Examiners convert hiberfil.sys into an uncompressed, analyzable raw memory image using utilities such as hibr2bin.exe or Volatility's imagecopy plugin:

# Decompressing hiberfil.sys into an analyzable raw physical memory image via Volatility
python3 vol.py -f /evidence/hiberfil.sys imagecopy.ImageCopy --output-file /evidence/decompressed_hiberfil.raw

2. Windows Paging & Swap Files (pagefile.sys & swapfile.sys)

The Windows Virtual Memory Manager (VMM) presents each process with a flat 32-bit (4 GB) or 64-bit (128 TB) virtual address space divided into 4 KB memory pages. When physical RAM demand exceeds available capacity, the VMM executes pagination, evicting inactive or low-priority virtual memory pages from physical RAM to C:\\pagefile.sys.

Forensic Evidentiary Value of Paging Files

• Historical Breadth: While a live RAM capture only reflects memory pages active at the exact moment of acquisition, pagefile.sys functions as a temporal archive containing residual memory blocks spanning days, weeks, or months of system activity.
• Cleartext Extraction: Paged-out memory is written to disk without encryption (unless BitLocker is active or the administrator explicitly enabled ClearPageFileAtShutdown under HKLM\\SYSTEM\\CurrentControlSet\\Control\\Session Manager\\Memory Management).
• Artifacts Recoverable from pagefile.sys:
  • Decrypted BitLocker recovery passwords (48-digit numerical passwords).
  • Master encryption keys from third-party disk encryption containers.
  • Terminated malware command-line arguments, process names, and injected strings.
  • Browser web page DOM structures, submitted web form credentials, and session cookies.
  • Unsaved Microsoft Word/Excel documents and cleartext chat transcripts.

Extraction Techniques: Strings & Bulk Extraction

Forensic examiners carve pagefile.sys using regular expressions, string parsing, and automated carvers:

# Extract all ASCII and 16-bit Little-Endian Unicode strings with byte offsets
strings -a -o -e l /evidence/pagefile.sys > /cases/pagefile_unicode_strings.txt
strings -a -o /evidence/pagefile.sys > /cases/pagefile_ascii_strings.txt

# Carve network packets, credit card numbers, URLs, and emails using bulk_extractor
bulk_extractor -o /cases/pagefile_carved_out/ /evidence/pagefile.sys

---

Windows Crash Dumps (MEMORY.DMP)

When the Windows operating system encounters an unrecoverable kernel-level fault, the kernel executes a Bug Check (Stop Error / Blue Screen of Death - BSOD) and invokes the crash dump subsystem to write memory state to disk for root-cause diagnosis. Crash dumps are configured under HKLM\\SYSTEM\\CurrentControlSet\\Control\\CrashControl.

+-------------------------------------------------------------------------+
|                    WINDOWS CRASH DUMP ARCHITECTURES                     |
+-------------------------------------------------------------------------+
| Dump Type           | Typical Location       | Contents & Size          |
|---------------------|------------------------|--------------------------|
| **Complete Memory** | %SystemRoot%\          | Entire physical RAM;     |
| **Dump**            | MEMORY.DMP             | Size = Installed RAM     |
|                     |                        | + dump header (1 MB)     |
|---------------------|------------------------|--------------------------|
| **Kernel Memory**   | %SystemRoot%\          | Kernel-mode allocations, |
| **Dump** (Default)  | MEMORY.DMP             | HAL, drivers; user-mode  |
|                     |                        | pages excluded (~800 MB) |
|---------------------|------------------------|--------------------------|
| **Small Memory**    | %SystemRoot%\          | Stop code, parameters,   |
| **Dump (Minidump)** | Minidump\*.dmp         | loaded driver list, active|
|                     |                        | process context (64–256K)|
|---------------------|------------------------|--------------------------|
| **Active Memory**   | %SystemRoot%\          | Active host & guest kernel|
| **Dump** (Win 10+)  | MEMORY.DMP             | + user space; omits free |
|                     |                        | memory and VM hypervisors|
+-------------------------------------------------------------------------+

1. Complete Memory Dump

Captures the entirety of physical RAM present in the system at the moment of the crash. It includes all kernel objects, user-mode processes, unallocated memory buffers, and active malware payloads. Complete dumps are identical in analytical fidelity to live RAM captures, though they lack data generated after the crash point.

2. Kernel Memory Dump

The enterprise default configuration for Windows Server. To optimize disk space, the kernel crash handler captures kernel-mode memory, hardware abstraction layer (HAL) tables, and loaded kernel drivers while excluding user-mode process spaces and unallocated memory. While sufficient for driver debugging, it severely limits malware investigations if the malicious payload operated strictly in user mode.

3. Small Memory Dump (Minidump)

Recorded to %SystemRoot%\\Minidump\\Mini[Date]-[Index].dmp. Ranging between 64 KB and 256 KB, it contains only the Bug Check code, the four stop parameters, the processor execution context (_CONTEXT), and the list of loaded kernel modules (_KLDR_DATA_TABLE_ENTRY). It contains no process heaps, user memory, or code segments.

4. Active Memory Dump

Introduced in Windows 10 and Windows Server 2016 to support systems with terabytes of physical RAM running Hyper-V. It captures host kernel space and active user-mode memory but aggressively purges hypervisor allocations, file cache pages, and free/zeroed memory pages, reducing dump size by up to 75% compared to Complete dumps.

---

Practical Forensic Case Scenario: Memory Triage in Ransomware Response

The Incident

At 03:15 UTC, an automated endpoint detection system flags an enterprise domain controller exhibiting rapid file modification. The incident response team connects remotely via an out-of-band management console.

Investigative Actions & Findings

1. Live Acquisition Decision: Rather than immediately issuing a hard power-down (which would wipe physical RAM and trigger potential bit-rot in partially encrypted volumes), the lead investigator executes winpmem.exe from a network share mapped to a secure write-protected repository, acquiring 32 GB of physical RAM.
2. Hibernation File Extraction: The forensic team reviews the root volume and identifies C:\\hiberfil.sys timestamped 48 hours prior, when the server was hibernated for scheduled maintenance. The investigator converts the compressed image via hibr2bin.exe.
3. Pagefile Analysis: The attacker attempted to cover their tracks by executing a batch script that stopped the Volume Shadow Copy service (vssadmin delete shadows /all /quiet) and deleted local event logs (wevtutil cl Security). However, examiners carve pagefile.sys using strings and uncover the original PowerShell command line containing an encoded base64 string that decrypted to a Cobalt Strike stager connecting to hxxp://185.220.101[.]45:8080/submit.php.
4. Outcome: Memory analysis of the live RAM capture recovers the plaintext AES-256 decryption key dynamically generated by the ransomware binary prior to thread termination, allowing the victim organization to decrypt enterprise file shares without paying the extortion demand.