In this module
MF1.5 Pagefile and Swap as Memory-Adjacent Evidence
From MF1.1-1.4 you know how to capture live RAM from Windows, Linux, and the hypervisor. But RAM isn't the only place memory evidence lives. When the OS runs low on physical memory, it evicts pages to disk — pagefile.sys on Windows, swap on Linux. Those evicted pages may contain the exact evidence your RAM capture is missing: credentials paged out hours ago, process data from a terminated attacker process, cleartext buffers the application freed but the OS wrote to disk before reclaiming. This sub covers what's in those files and how to collect them.
The memory image you captured in MF1.2-1.4 contains what was in RAM at capture time. It does not contain what the OS paged out before you arrived. On a system that's been running for days under memory pressure, significant portions of process memory — including credential material, decrypted buffers, and attacker process data — may have been evicted to pagefile or swap and never paged back in. Your RAM capture is blind to that data. The pagefile and swap partition are where the rest of the story lives.
Practitioners who treat memory forensics as "capture RAM, analyse RAM" miss evidence that's sitting on disk in a memory-formatted container. Practitioners who know about the pagefile but don't collect it miss it for a different reason: by the time they think to collect it, the system has been rebooted and the pagefile has been overwritten or cleared by policy. The collection window for pagefile and swap is the same as the collection window for RAM — before the system is rebooted or reimaged.
This sub covers what pagefile.sys, hiberfil.sys, and Linux swap contain, why each matters forensically, how to collect them alongside your RAM capture, and how to feed them into Volatility 3 so the analysis tools can resolve pages that were "not present" in the RAM image. By the end, your acquisition procedure captures not just RAM but the memory-adjacent evidence that completes the picture.
Deliverable: Understanding of what pagefile.sys, hiberfil.sys, and Linux swap contain forensically, the collection procedure for each, how to supply the pagefile to Volatility 3 for page-resolution during analysis, and the policy settings that destroy this evidence on reboot.
Pagefile.sys — where evicted memory pages go on Windows
This section explains what the pagefile contains and why it matters forensically. The pagefile is evidence most practitioners know about but don't collect.
When Windows runs low on physical memory, the Virtual Memory Manager selects pages to evict from RAM and writes them to C:\pagefile.sys. The evicted pages are marked "not present" in the process's page table, and the PTE (page table entry) is updated with the pagefile offset where the data now lives. If the process accesses that virtual address again, a page fault fires, the OS reads the page back from the pagefile into RAM, and execution continues. From the process's perspective, nothing happened — the latency spike is the only visible effect.
Forensically, the pagefile matters because eviction is not deletion. A page evicted to the pagefile at 14:00 may still be there at 18:00 if the system never needed the pagefile slot back.
Credentials cached in LSASS memory, cleartext email bodies in Outlook's working set, decrypted file buffers in an application's heap — any of these can be evicted under memory pressure and sit in the pagefile indefinitely. When you capture RAM at 18:00, the plugin that looks for credentials finds whatever is in RAM at that moment. The credential that was evicted at 14:00 is invisible to the RAM analysis — it's in the pagefile.
Volatility 3 can resolve pagefile-backed pages if you supply the pagefile alongside the memory image. The --swap flag points Volatility 3 at the pagefile:
vol -f image.raw --swap pagefile.sys windows.pslistWhen a plugin encounters a "not present" PTE during analysis, it checks the pagefile at the recorded offset and retrieves the data. Without the pagefile, the plugin returns "unable to read" for those addresses. With the pagefile, the plugin returns the evicted data as if it were still in RAM.
The difference in analysis coverage can be significant on systems that have been running under memory pressure.
Collecting the pagefile from a live system
This section is the procedure. The pagefile is locked by Windows — you can't just copy it. Two methods work.
Windows locks pagefile.sys with exclusive access while the OS is running. A standard copy or robocopy command fails with "The process cannot access the file because it is being used by another process." Two methods bypass the lock.
Method 1 — Volume Shadow Copy. Create a VSS snapshot of the C: drive, then copy the pagefile from the snapshot:
# Create the shadow copy
vssadmin create shadow /for=C:
# Note the Shadow Copy Volume name from the output, then copy
copy \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1\pagefile.sys C:\evidence\pagefile.sysThe snapshot is a point-in-time copy of the volume, so the pagefile you get is consistent with the volume state at snapshot creation.
Method 2 — KAPE or forensic collection tools. KAPE's $Pagefile target collects pagefile.sys using raw disk access that bypasses the file-system lock. If you're already running KAPE for triage collection, the pagefile is a target you add to your collection profile. Other forensic collection tools (Velociraptor, CyLR) can also collect locked files via raw NTFS reads.
The collection must happen before reboot. Many organisations configure a Group Policy setting that clears the pagefile on shutdown:
Computer Configuration > Windows Settings > Security Settings >
Local Policies > Security Options >
"Shutdown: Clear virtual memory pagefile"When this policy is enabled, the pagefile is zeroed during shutdown and the evicted pages are gone. If your environment uses this policy, pagefile collection is even more time-sensitive than RAM collection — you must collect while the system is running, because the pagefile will be destroyed at the next shutdown.
Hiberfil.sys — a compressed historical memory snapshot
This section covers the hibernation file, which is not current memory but historical memory — a crucial distinction for reporting.
When a Windows system hibernates, the OS compresses the contents of RAM and writes them to C:\hiberfil.sys. The system then powers off. On the next boot, the OS reads hiberfil.sys, decompresses it into RAM, and resumes from the exact state at hibernation time. The hibernation file is a full memory snapshot — but of a specific past moment, not the current moment.
Forensically, hiberfil.sys is valuable when the system has been rebooted since the incident. If the attacker was active at 14:00, the user hibernated the laptop at 17:00, and the laptop was powered on again at 09:00 the next day, the hiberfil.sys from the 17:00 hibernation contains a memory snapshot from three hours after the attack. It won't show the attack in progress (that was 14:00, not 17:00), but it may show the aftermath — persistence mechanisms installed, registry modifications made, files created. If the system was rebooted rather than resumed from hibernation, the hiberfil.sys is stale and represents the last hibernation before the reboot, not the current session.
Volatility 3 can analyse hiberfil.sys directly — the windows.hibernation layer handles decompression automatically:
vol -f hiberfil.sys windows.infoThe only difference in the output is the SystemTime — it shows the hibernation timestamp, not the current time. This distinction matters for reporting: "the hibernation file shows the system state at 17:00 on 15 March" is a defensible claim; "the memory shows the system state at the time of investigation" is not.
The collection is simpler than the pagefile — hiberfil.sys is not locked while the system is running:
copy C:\hiberfil.sys C:\evidence\hiberfil.sysOn systems where hibernation is disabled (powercfg /h off), the file doesn't exist.
Linux swap — the pagefile equivalent
This section covers the Linux equivalent. Swap is structurally different from Windows pagefile but forensically equivalent.
Linux uses swap space the same way Windows uses pagefile: when the kernel needs to free physical RAM, it evicts pages to swap and records the swap offset in the page table entry. Swap can be a dedicated partition (/dev/sda2 type 82) or a swap file (/swapfile). The forensic value is the same: evicted credential material, process data from terminated processes, freed buffers that were swapped out before being zeroed.
Collecting swap from a live Linux system is straightforward — swap partitions and files aren't locked the way Windows pagefile is:
# Swap partition
sudo dd if=/dev/sda2 of=/evidence/swap.img bs=4M
# Swap file
sudo cp /swapfile /evidence/swapfileHash immediately after collection.
Volatility 3's Linux swap support is less mature than its Windows pagefile support. As of 2026, Linux swap resolution requires manual configuration and is not as seamless as the --swap flag for Windows. Practical impact: on Linux, your RAM capture is the primary evidence, and swap is supplementary — useful for string searches and carving but not for plugin-level page resolution the way Windows pagefile is. This may improve in future Volatility 3 releases.
This procedure extends the MF1.2 WinPmem capture by adding pagefile collection. By the end, you have both the RAM image and the pagefile ready for combined analysis.
The situation. You've captured RAM from a Northgate Engineering workstation during an active investigation. The SOC lead asks whether you also need the pagefile. The workstation has been running for six days under normal office load. The pagefile is 8 GB. You have time for one more collection step before the business reimages the machine.
The choice. Collect the pagefile (adds 10-15 minutes for shadow copy creation, copy, and hash) or skip it and proceed to analysis with the RAM image only.
The correct call. Collect the pagefile. Six days of uptime under office load means significant paging activity — LSASS credentials, browser session data, email client buffers, and application heap pages will have been evicted and may not have been paged back in. Your RAM capture is missing whatever was paged out. The 10-15 minute collection cost is low relative to the evidence you gain. Skip the pagefile only if the system is about to be reimaged in the next five minutes and you genuinely can't fit the collection — but even then, the pagefile collection is faster than you think (VSS snapshot is instant, copy is disk-speed limited).
The operational lesson. Make pagefile collection part of the standard acquisition procedure, not an afterthought. The question "do we need the pagefile?" should be answered "yes, unless the system has been running for less than an hour" — and even on a fresh boot, collecting it is cheap insurance. The investigations where the pagefile matters most are the ones where you didn't know in advance that it would matter.
The myth. The pagefile is where the OS dumps pages it doesn't need anymore. The pages are random, fragmented, and unstructured — you can't reconstruct anything meaningful from them. Pagefile analysis is a theoretical exercise that doesn't produce actionable findings in real investigations.
The reality. The pagefile contains whatever the OS decided to evict under memory pressure. That decision is based on page age and access frequency, not forensic relevance. LSASS credential material, decrypted TLS session keys, cleartext email bodies, and application heap data are all eviction candidates when they haven't been accessed recently. On a system that's been running for days, the pagefile can contain credential material that was cached hours or days ago and hasn't been accessed since — exactly the timeframe an investigation cares about.
The pages aren't structured in the pagefile the way they're structured in RAM — they're stored by pagefile offset, not by virtual address. Volatility 3's --swap flag handles the mapping: it reads the PTE to find the pagefile offset and retrieves the page. The analyst doesn't need to parse the pagefile manually. The analysis workflow is identical to RAM-only analysis; the coverage is broader.
The investigations where pagefile matters most are long-running compromises on systems with limited RAM. A finance workstation with 8 GB RAM running Outlook, Chrome, the ERP client, and an attacker's C2 agent has been under continuous memory pressure for days. The attacker's credential-harvesting activity from three days ago was paged out two days ago. Without the pagefile, that evidence doesn't exist in your analysis. With it, Volatility 3 can resolve the paged-out LSASS regions and surface the cached credentials. That's the difference between a finding and a gap in the investigation.
Try it — Collect pagefile from Target-Win and test Volatility 3's swap resolution
Setup. Your Target-Win VM from MF1.2, still running. The RAM baseline image from MF1.2 already on the analysis workstation. An elevated Command Prompt on Target-Win.
Task. Execute the Guided Procedure above: verify pagefile exists, create a VSS shadow copy, copy the pagefile from the shadow, hash it, transfer to the analysis workstation, re-hash, and run Volatility 3 with --swap. Compare vol -f image.raw windows.pslist output with and without the --swap flag.
Expected result. Both runs produce process listings. On a clean lab VM with 4 GB RAM and low utilisation, the difference between the two runs is likely minimal (most pages are in RAM, not paged out). The critical verification is that the --swap run completes without errors — this confirms the pagefile is structurally valid and the analysis pipeline works for combined RAM+pagefile analysis.
If your result doesn't match. If the VSS shadow copy fails, VSS may be disabled on the VM — enable it via services.msc → Volume Shadow Copy → Start. If the pagefile is unexpectedly small (under 100 MB), Windows may have a custom pagefile configuration — check wmic pagefile list. If Volatility 3 ignores the --swap flag, ensure the file is named pagefile.sys and was collected from the same system the RAM image came from.
You should be able to do the following without referring back to this sub. If you can't, the sections to re-read are noted.
You've set up the lab and captured your first clean baselines.
MF0 built the three-VM lab and established the memory forensics landscape. MF1 taught acquisition with WinPmem and LiME, integrity verification, and chain of custody. From here, you execute attacks and investigate what they leave behind.
- 8 attack modules (MF2–MF9) — process injection, credential theft, fileless malware, persistence, kernel drivers, Linux rootkits, timeline construction, and a multi-stage capstone
- You run every attack yourself — from Kali against your target VMs, then capture memory and investigate your own attack's artifacts with Volatility 3
- MF9 Capstone — multi-stage chain (initial access → privilege escalation → credential theft → persistence → data staging), three checkpoint captures, complete investigation report
- The lab pack — PoC kernel driver and LKM rootkit source code, setup scripts, 21 exercises, 7 verification scripts, investigation report templates
- Cross-platform coverage — Windows and Linux memory analysis in one course, with the timeline module integrating evidence from both
Cancel anytime