Acquiring Amcache.hve from live and dead systems

The fastest way to ruin an Amcache investigation is to acquire the hive badly. I have inherited cases where the collector grabbed Amcache.hve with xcopy, missed the .LOG1 / .LOG2 pair, and handed the analyst a hive that opens with warnings and is missing the most recent week of inventory. The hive was right there. The acquisition method threw it away.

This post is the version of "how to grab the file correctly" that I wish every IR runbook had.

The file is locked, and that is the whole problem#

C:\Windows\AppCompat\Programs\Amcache.hve is opened by the kernel as a hive. The handle is kept open while Windows is running. On a live host:

• A normal user-mode CopyFile against the live path fails with sharing violation.
• xcopy / robocopy against the live path fail the same way, or worse, silently produce a zero-byte file on some Windows builds when run from a privileged shell with certain switches.
• reg save HKLM\... Amcache.hve does not work because the Amcache is a standalone hive, not mounted under HKLM by default. You can load it with reg load HKLM\Amcache C:\Windows\AppCompat\Programs\Amcache.hve only if it is not currently open by another process, which on a live system it is.

There are four legitimate ways to read the file: snapshot the volume and read from the snapshot, use a raw NTFS reader that bypasses the lock, use a tool that knows how to handle the hive specifically, or shut the host down and image the disk.

The first three apply on a live host. The fourth applies when the host is already powered off.

Live acquisition that actually works#

Volume Shadow Copy#

The most boring and most reliable method. Create a shadow copy, mount it, copy the file out.

vssadmin create shadow /for=C:

vssadmin returns the shadow copy path, usually something like \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1. You cannot cd into that path because Win32 path normalisation hates it. The trick is to create a symbolic link or use a tool that consumes raw paths directly. mklink /D C:\shadow \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1\ and then copy C:\shadow\Windows\AppCompat\Programs\Amcache.hve* C:\out\ will work.

Two practical notes. Make sure you grab the wildcard so you get Amcache.hve, Amcache.hve.LOG1, and Amcache.hve.LOG2. And clean up the shadow copy when you are done unless you have a reason to keep it; uncollected shadow copies are how a workstation runs out of disk space at the worst possible moment.

Velociraptor#

If you have Velociraptor deployed (and on most enterprise IR engagements you should), this is a one-liner:

SELECT * FROM Artifact.Windows.Forensics.Amcache()

The artifact handles the file lock by reading through ntfs.sys's raw NTFS access, replays the transaction logs, and returns parsed rows. If you want the raw hive instead of parsed output, Windows.KapeFiles.Targets with _AmcacheHive as the target gives you the file and the logs in a zip.

For sweeps across many hosts, this is the workflow. Hunt across the estate, pull every hive, post-process centrally.

KAPE#

Eric Zimmerman's KAPE handles the Amcache target out of the box. kape.exe --tsource C: --target Amcache --tdest .\out\ collects the hive plus logs, using its built-in raw NTFS reader. It does the right thing with locks.

KAPE is also the right tool when you need to collect the Amcache alongside everything else for a triage package. The BasicCollection target plus targeted modules will get you Amcache, Prefetch, MFT, Event Logs, USN journal, Registry hives, and the rest of the standard kit in one pass.

FTK Imager#

If you only have FTK Imager (because the responder is on-site with a USB stick and no other tooling), it works. Add Evidence Item > Physical Drive > navigate to \Windows\AppCompat\Programs\ > right-click > Export Files. FTK Imager uses raw disk reads, so the lock is irrelevant.

This is the method I default to when I am sitting in front of an executive's laptop with limited time and limited deployment freedom.

reg save with a prior reg load#

Mentioned because people try it. It does not work on the live hive because the hive is already open. It can work on an extracted copy: copy the hive out via one of the methods above, load it as a hive locally with reg load HKLM\AmcacheTemp C:\path\to\Amcache.hve, query, then reg unload. This is for analysis, not acquisition.

The LOG1 / LOG2 issue#

Amcache.hve.LOG1 and Amcache.hve.LOG2 are the dirty-page transaction logs the kernel writes to keep the hive consistent. They are critical for two reasons.

First, if the hive was being written when you captured it, the primary file is inconsistent and the logs hold the missing pages. Without them, parsers will either refuse to open the hive or open it with stale data. Always check the parser output for "log replay" messages or "primary sequence != secondary" warnings.

Second, recently-deleted subkeys often still exist as undeleted cells in the log pages. I have recovered entries from .LOG1 that were purged from the main hive by an attacker minutes before acquisition. If you grab only the .hve, you throw that recovery away.

The rule is: never collect the hive without the logs. Wildcard-match Amcache.hve* on every collection. Velociraptor and KAPE do this automatically; ad-hoc copy commands do not unless you make them.

A separate failure mode: collecting the logs but not replaying them. Some parsers replay automatically (AmcacheParser, yarp), some do not (older RegRipper builds). If you are not sure, check by opening the recovered hive in two parsers and comparing row counts. A meaningful gap means one of them did not replay.

Dead-disk acquisition#

When you have a disk image (E01, raw, VHDX) or a powered-off drive:

• Mount the image read-only with FTK Imager, Arsenal Image Mounter, or losetup plus ntfs-3g on Linux.
• Navigate to \Windows\AppCompat\Programs\ on the mounted filesystem.
• Copy Amcache.hve, Amcache.hve.LOG1, Amcache.hve.LOG2 out to the analysis machine.
• Parse normally.

There are no file-lock concerns on a dead image. The only thing to watch for is the volume shadow copies on the image, which may contain older Amcache hives. If the live hive has been tampered with, an older copy from \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopyN\Windows\AppCompat\Programs\Amcache.hve may carry the entries the attacker removed. Tools like vshadowmount (libvshadow) on Linux or ShadowExplorer on Windows expose those snapshots cleanly.

I recover historical Amcache rows from shadow copies on roughly one in five cases where the on-disk hive shows signs of pruning.

What good IR scripts look like#

A working IR collection script for Amcache, in rough pseudocode:

1. Create a VSS snapshot of C: (or use raw NTFS reads directly).
2. Read Amcache.hve, Amcache.hve.LOG1, Amcache.hve.LOG2 from the snapshot path.
3. Compute SHA-256 of each acquired file. Log into the chain-of-custody record.
4. Compress the three files together with a timestamped name (<hostname>_<UTC-timestamp>_amcache.zip).
5. Tear down the snapshot.
6. Ship to central storage.

If your script does not do all six steps, fix it. Specifically: if it does not hash the acquired files, you have no integrity story. If it does not collect the logs, you are missing data. If it leaves snapshots behind, you will eventually crash a production host.

Velociraptor's Windows.KapeFiles.Targets artifact does all of this and more. If you are writing your own from scratch, ask yourself why.

Pitfalls of xcopy and other ad-hoc methods#

xcopy "C:\Windows\AppCompat\Programs\Amcache.hve" "C:\out\" on a live host will fail with sharing violation in most cases. Some Windows builds, with some privilege combinations, will instead produce a zero-byte file. Either failure mode is loud if you check; both are silent if you do not.

copy has the same problem. robocopy /B (backup mode) sometimes works on the live hive because backup-mode opens use SeBackupPrivilege, but the results are inconsistent across Windows builds and I do not trust them. PowerShell's Copy-Item is just CopyFile underneath.

certutil -urlcache -split is not relevant here, no, but I have seen people try.

The only reliable rules: snapshot the volume, or use a tool with raw NTFS access, or shut the host down. Anything else is luck.

Verifying the acquisition#

Before you walk away from a host, verify the file you collected is parseable.

• Open with yarp-print (Maxim Suhanov's CLI). It will warn about sequence mismatches and unreplayed logs.
• Run AmcacheParser against the collected files. Confirm row counts under InventoryApplicationFile are non-zero.
• Spot-check that the most recent KeyLastWrite is close to "now" (within the Appraiser scan cadence, usually hours). If the most recent entry is days old on a host that was supposedly running normally, the Appraiser task may have been disabled, the hive may have been pruned, or your acquisition path was wrong.

If something looks wrong, re-collect before the host changes state. Verification on the wire saves a long flight back.

Further reading#

• Eric Zimmerman's KAPE documentation and the Amcache target source.
• Velociraptor's Windows.Forensics.Amcache artifact reference.
• Maxim Suhanov's yarp, particularly the transaction log replay code.
• Microsoft's Volume Shadow Copy Service documentation, for the VSS-based acquisition path.