Limitations of pagefile.sys analysis

pagefile.sys is one of the highest-yield artifacts on a Windows host. It is also the one most likely to get oversold in an IR report. The same property that makes it useful, a raw dump of paged-out memory with no process attribution, is the source of every limit on what it can give you. This post is the honest list, so the report does not need a retraction.

No process attribution

A page in pagefile.sys cannot, on its own, be tied to a process. The mapping from a pagefile slot to a Process / VirtualAddress lives in page-table entries, which are in RAM. Without a paired RAM acquisition, you can read content. You cannot say who owned it.

This is why Volatility refuses to process a pagefile in isolation. It needs the PTEs from a RAM image to know which pagefile slot to read for a given virtual address. The Volatility + pagefile workflow covers the paired case.

No allocation reassembly

A single allocation larger than 4 KB (a PE section, a document buffer, a SQLite table page over 4K) was paged out as separate frames into whatever pagefile slots were free at the time. Two adjacent pages in the file almost certainly belong to different allocations. Carving recovers per-page hits. It rarely rebuilds a complete file. bulk_extractor will pull every PE header it finds; it cannot stitch the rest of the binary back together.

Windows 10+ memory compression

Starting with Windows 10, the Memory Manager added CompressionStoreManager. Cold pages get compressed in RAM before any disk I/O. The algorithm is Xpress-Huffman (COMPRESSION_FORMAT_XPRESS_HUFF, format code 4). When such a page is finally flushed to pagefile, the on-disk bytes are the compressed payload, not the original. A naked strings sweep will miss the content.

Decompressing requires parsing the Huffman code-length table at the start of each block. Doable; tedious. The Blackhat 2019 paper Paging All Windows Geeks: Finding Evil in Windows 10 Compressed Memory by Omar Sardar and Dimiter Andonov is the reference. The MS-XCA spec defines the format. This parser flags likely Xpress-Huffman pages (high entropy plus a plausible 256-byte code-length header) so analysts can spot what is hiding. Decompression in WebAssembly is on the roadmap.

Selective paging

Not everything paged out is in pagefile.sys. Windows has several paging backends:

pagefile.sys for anonymous memory.
swapfile.sys for UWP / Modern app working sets.
hiberfil.sys for the hibernation snapshot of full RAM.
Mapped files page back to their source files, not to pagefile.

If the data of interest never paged out (because RAM was sufficient), or it landed in swapfile.sys, hiberfil.sys, or its mapped source, it will not be in pagefile.sys. See the comparison post.

Volatile, fragile, partial

Even when data lands in pagefile, it gets overwritten on the next page-out cycle. The file is not append-only. What you captured is one moment in the host's life, biased toward whatever was cold at that moment. Older artifacts may already be gone. This is why I push so hard for acquisition timing.

Encrypted pagefile

fsutil behavior set EncryptPagingFile 1 makes the file effectively unrecoverable from an offline image. The bytes are AES output and the key died at shutdown. The encryption post covers detection and the pivots when it is set.

What it is still good for

Despite all of this, pagefile reliably surfaces:

Plaintext credentials that were in memory but never persisted intentionally.
URLs and IPs an attacker's C2 traffic touched.
Command lines of short-lived processes that left no trace in EVTX or Prefetch.
Registry hive fragments that have since been deleted from the live hive.
Document content the user was editing.
Browser history and form data that Incognito or InPrivate sessions did not persist.

For triage, that is usually enough. For attribution, pair it with a RAM dump, AmCache, Shimcache, EVTX, and the USN journal.