Volatility and Amcache: extracting the hive from memory images

AmcacheParser.exe reads the on-disk Amcache.hve. What if you only have a memory image and no disk capture?

The answer is Volatility, with its registry-hive plugins, used to extract the live in-memory copy of Amcache and dump it where AmcacheParser can read it. This page is the practical guide.

For the broader Amcache reference, see the Amcache complete reference. For the parser side, see the AmcacheParser complete guide.

When you need this#

The disk hive is usually the right source. Memory-side is for cases where you cannot get the disk:

• Memory-only acquisition. A live-response capture pulled a RAM dump and triage selected artefacts, but no full disk image is available.
• Volatile-evidence-first protocols. Some IR procedures dictate RAM capture before disk, and the disk capture is delayed by hours or days.
• Suspected tampering of the disk hive and you want the in-memory copy as a check.
• Encrypted disk, decrypted memory. BitLocker scenarios where the disk image isn't decryptable but the RAM dump has decrypted hive contents.

For normal live-host or post-incident disk forensics, prefer the disk-side workflow in Where Amcache.hve is on disk.

What Volatility extracts#

Windows keeps every loaded registry hive - SYSTEM, SOFTWARE, SAM, per-user NTUSER.DAT, and Amcache.hve if loaded - in kernel memory in a structure called the hive list. The appraiser typically loads Amcache.hve during inventory passes and keeps it loaded for some time after. A memory image captured during or shortly after an inventory pass contains the full hive in-memory.

Volatility's registry plugins walk the hive list and extract individual hives.

Same workflow across versions, syntax differs.

Step 1: enumerate loaded hives#

First, see what's loaded. Volatility 3:

vol -f memory.dmp windows.registry.hivelist

Volatility 2:

vol.py -f memory.dmp --profile=Win10x64_19041 hivelist

You should see a row for each loaded hive with a virtual address and the hive's file path. If Amcache was loaded:

Offset (V)    FileFullPath
0xfffff8a0...   \??\C:\Windows\AppCompat\Programs\Amcache.hve

If Amcache is not in the hive list, the appraiser was not holding it open at capture time. Move to disk-side acquisition or recovery. Memory-only Amcache is not available for this image.

Step 2: dump the hive to disk#

Once you have the virtual address:

# Volatility 3 - replace 0xfffff8a0... with the real offset from hivelist
vol -f memory.dmp windows.registry.dumphive --offset 0xfffff8a0... > Amcache.hve

Volatility 2:

vol.py -f memory.dmp --profile=Win10x64_19041 dumpregistry \
    --offset 0xfffff8a0... --dump-dir ./dumped

The output is a binary blob that AmcacheParser can read. Note:

• No transaction logs. The in-memory hive does not carry .LOG1 / .LOG2. AmcacheParser will warn about missing logs. Expected.
• Point-in-time snapshot. Reflects whatever the appraiser had written through to the in-memory hive structure at capture.

Step 3: parse with AmcacheParser#

Hand the dumped hive to AmcacheParser as usual:

AmcacheParser.exe `
 -f .\Amcache.hve `
 --csv .\out `
 --csvf MEMORY_amcache.csv `
 --mp

Same per-category CSV set as a disk-side parse. AssociatedFileEntries.csv, UnassociatedFileEntries.csv, and so on. Triage and pivot as in the malware investigation playbook.

Caveats specific to memory-side recovery#

A few things to be aware of when working from a memory-dumped hive.

Transaction-log data is lost#

The in-memory representation does not include uncommitted writes that were still in .LOG1 / .LOG2 at capture. For a hive being actively written when memory was acquired, you may be missing the very latest entries. Disk-side recovery of .LOG1 and .LOG2 would catch them.

Coverage depends on what was loaded#

Some Windows builds and configurations unload Amcache after each appraiser pass. Others keep it loaded. If you find no Amcache in the hive list, it does not mean Amcache is absent on the host. It means it was not loaded at capture time.

Schema interpretation may need the right Volatility profile#

Volatility 2's profile must match the captured OS for the registry-walking code to work cleanly. Get the wrong profile and the dumped hive may be incomplete or corrupted. Volatility 3 auto-detects and is much more forgiving, but a wrong-profile dump is still possible.

Parses may emit warnings#

AmcacheParser may warn about missing transaction logs, truncated cells, or unexpected schema. Expected when dumping from memory. Doesn't necessarily mean the data is bad. Treat anomalies with extra care and cross-reference with disk if possible.

Comparing memory and disk hives#

If you have both a memory dump and a disk image of the same host (taken at close times), parse both and diff:

$disk  = Import-Csv .\HOST01_disk_amcache_UnassociatedFileEntries.csv |
      Select Hash, FullPath, KeyLastWriteTimestamp
$memory = Import-Csv .\HOST01_memory_amcache_UnassociatedFileEntries.csv |
      Select Hash, FullPath, KeyLastWriteTimestamp
 
# In memory but not on disk
$memory | Where-Object { $h = $_.Hash; -not ($disk | Where-Object { $_.Hash -eq $h }) }
 
# On disk but not in memory
$disk | Where-Object { $h = $_.Hash; -not ($memory | Where-Object { $_.Hash -eq $h }) }

What each delta means:

• In memory only: the appraiser wrote it to the in-memory hive but the change had not flushed to disk yet (and would have on a clean shutdown). Often the freshest signal you have.
• On disk only: the entry was in the disk hive but the in-memory hive had it unloaded or aged out at capture. Disk is authoritative.

If the disk hive has been tampered with, the memory copy often preserves the original entries. This makes the memory-side workflow also useful as an anti-forensics countermeasure.

When this is the wrong workflow#

Three cases where you should not bother with memory-side Amcache recovery.

You have the disk#

The disk workflow gives you hive + transaction logs + Volume Shadow Copies. Memory gives you a single snapshot. Always prefer disk if available.

The acquisition is old#

If the memory dump is days old and you are after current state, the on-disk hive (updated since the dump) is more useful. Memory dumps are point-in-time.

The hive was not loaded at capture#

If hivelist does not show Amcache, no plugin will magic it into existence. Move to disk or to per-entry recovery from process memory of the appraiser (rare, advanced, beyond the scope of most engagements).

Further reading#

• The Volatility 3 documentation for the windows.registry.* plugin family.
• Andrew Case and the Volatility team's posts on hive list internals.

Related#

• Amcache complete reference
• AmcacheParser complete guide
• Where Amcache.hve is on disk
• RegRipper amcache plugin
• Recovering deleted-binary evidence from Amcache