Carving registry hive fragments from pagefile.sys

Registry hives are open for the life of a Windows boot. Every process opens hive handles on startup and Windows caches the active portions in non-paged pool. But the colder parts of large hives, SOFTWARE on a busy server, an idle user's NTUSER.DAT, the rarely-touched Tasks subtree, do get paged out. That is where pagefile carving earns its keep: you can reconstruct registry data that no longer exists in the live hive.

The bar to get something useful is lower than people assume. A single isolated hbin is enough to recover deleted Run keys, scrubbed service entries, or the last-written UserAssist value the attacker tried to clean up.

The two signatures that matter

Hives are made of two block types, both 4 KB aligned and trivially carvable from a 4 KB-paged file:

Signature	Hex	What it is
`regf`	`72 65 67 66`	Hive base block, the file header
`hbin`	`68 62 69 6E`	Hive bin, a 4 KB cell container

A complete hive on disk is one regf block followed by a run of hbin blocks. In a pagefile you almost never get the sequence intact. What you get is many isolated hbin blocks, each holding a 4 KB chunk of registry data that was paged out of RAM.

bulk_extractor carves these natively. photorec also picks them up if you whitelist the right signature. The parser on this site flags every regf/hbin page in the Page map tab with its absolute offset.

What survives in an isolated hbin

An hbin is a container for cells. Each cell is one of:

A key node (nk) with the key name, last-write FILETIME, parent reference, subkey count.
A value entry (vk) with the value name, type (REG_SZ, REG_DWORD, REG_BINARY, etc.), and a data offset or inline data.
A subkey list (lf, lh, li, ri).
A security descriptor (sk).
"Big data" cells (db) for values larger than the cell size.
The actual value bytes.

A single 4 KB bin typically holds a few dozen cells. Even a stranded one gives you the names and last-write times of keys that lived in it, the names and types of values, the inline data for short values (most REG_SZ and every REG_DWORD), and the contents of deleted cells.

That last item is the prize. When a key or value is removed, the cell is marked free by flipping the high bit of its size word. The content is not zeroed. Live-hive tooling skips free cells. Carvers do not. So a carved hbin will reveal a Run entry that an attacker reg delete'd an hour before acquisition, while a live RegRipper run on the on-disk hive will tell you everything looks clean.

Extracting cells from a carved hbin

You cannot load a lone hbin into Registry Explorer or hivexsh. They want a regf-prefixed file. The usual options:

Locate hbin pages in the pagefile, note absolute offsets (e.g. 0x12340000, 0x12341000).

Carve them out:

dd if=pagefile.sys of=hbin1.bin bs=1 skip=$((0x12340000)) count=4096

Pick one of:
- Manual parse against the libregf registry file format reference. Painful but deterministic.
- Prepend a synthetic regf base block with yarp. Maxim Suhanov's parser is the most tolerant of corruption I have used and it has helpers for exactly this case.
- Feed the raw bytes into regipy, which exposes lower-level cell APIs than RegRipper and will happily walk a bin in isolation.

For a stranded bin where the cell pointers refer to offsets outside the bin (most of them will), you read the cells you have inline. The pointers are dead.

What to look for in carved hives

The keys that pay back the time:

SAM\Domains\Account\Users\... for RIDs, NT hashes (encrypted with the SYSKEY but recoverable when paired with the SYSTEM hive), account flags.
SECURITY\Policy\Secrets\... for LSA secrets, machine account password, service-account credentials, DPAPI master-key material.
SOFTWARE\Microsoft\Windows\CurrentVersion\Run and RunOnce for persistence the attacker has since removed.
SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Tasks for scheduled-task GUIDs. Pair with the EVTX TaskScheduler/Operational channel.
SYSTEM\CurrentControlSet\Services\... for installed services. Lateral movement via PsExec or Impacket leaves traces here.
NTUSER.DAT\Software\Microsoft\Windows\CurrentVersion\Explorer\RunMRU for recently typed Run-dialog commands.
NTUSER.DAT\Software\Microsoft\Windows\CurrentVersion\Explorer\TypedPaths for Explorer address-bar history.
UsrClass.dat ShellBag subtrees for folders the user opened, including ones since deleted. Cross-reference with LNK files and jump lists.
SOFTWARE\Microsoft\Windows\CurrentVersion\Search\RecentApps and the AmCache-adjacent execution evidence under Root\InventoryApplicationFile (which is technically Amcache.hve rather than the main hives, but carves identically).

Any of these in a paged-out fragment is forensically meaningful even without surrounding hive context. The carved last-write times still anchor the entry, and the value bytes are intact.

Comparing with the live system

When you have both the pagefile and the on-disk SOFTWARE, SYSTEM, SAM, NTUSER.DAT hives:

Diff the carved fragments against the live hive. Anything in the carved data that is not in the live hive is the evidence.
yarp and regipy both emit unified value lists. Run them against both inputs and diff the output.

The diff is the report-ready output. The carved entries that survive are what the attacker thought they had cleaned up.

Limitations specific to registry carving

No transaction-log replay. The live hive system uses .LOG1 / .LOG2 files to commit writes durably. A paged-out fragment may be pre-commit state that the live hive has already overwritten with the durable version. The pre-commit state can still matter (it shows what was being written) but do not assert it as the final value.
Cell offsets are relative to the hive base. Pointers from one cell to another (subkey lists, value lists, big-data chains) are useless without the full regf block. You read the cells inline. You do not navigate.
Compressed pages. On Windows 10+ an hbin may be Xpress-Huffman compressed before being paged out. This site flags such pages but does not yet decompress them. The Blackhat 2019 paper Paging All Windows Geeks covers the algorithm. Manual decompression with the MS-XCA reference implementation is doable but tedious.

A pivot worth knowing

Once you have a SECURITY hive fragment with the LSA secrets cell intact, pair it with RecentFileCache, Prefetch, and the USN journal to time-anchor whatever the secret was used to do. A naked credential without a timeline is half a finding.