Recovering deleted-binary evidence from Amcache

The single most underrated feature of Amcache.hve is that it outlives the binaries it records. An attacker can delete a tool the moment they no longer need it; Amcache's snapshot of that binary's path, hash, publisher, version, and inventory time typically persists in the hive for weeks or months afterwards.

This page is the practical workflow for using Amcache when the binary itself is gone.

For the broader artefact reference, see the Amcache complete reference; for the canonical comparison, see Amcache vs Prefetch and Amcache vs ShimCache.

Why Amcache outlives the binary#

The Compatibility Appraiser, the scheduled task that populates Amcache, writes the inventory snapshot once per scan. Once an entry is in Root\InventoryApplicationFile, it stays in the hive until:

• A later appraiser pass actively removes it (which is the exception, not the rule), or
• The hive itself is deleted or aged out.

In practice, on a typical Windows 11 workstation, entries persist for months even after the underlying binary is gone. On a long-lived workstation, multi-year-old entries are routine.

This makes Amcache the most reliable post-deletion artefact for PE files on Windows.

What you recover#

When a binary is deleted, you typically lose:

• The binary itself.
• File-system timestamps (the MFT entry may also be wiped or overwritten).
• The ability to verify the binary's hash directly.

What you keep in Amcache:

That set of recovered fields is enough to:

• Submit the hash to VirusTotal / TI feeds — see Amcache FileId explained.
• Pivot on ProgramId across other hosts — see Lateral movement and Amcache ProgramId pivoting.
• Time-bound the drop event using KeyLastWriteTimestamp — see Amcache timestamps explained.
• Reconstruct the binary's identity even though its bytes are gone.

The post-deletion workflow#

A repeatable workflow for "we think they dropped a tool here, then wiped it":

1. Collect the hive plus transaction logs#

Copy-Item 'C:\Windows\AppCompat\Programs\Amcache.hve'      'C:\Triage\' -Force
Copy-Item 'C:\Windows\AppCompat\Programs\Amcache.hve.LOG1' 'C:\Triage\' -Force
Copy-Item 'C:\Windows\AppCompat\Programs\Amcache.hve.LOG2' 'C:\Triage\' -Force

If you suspect the attacker also deleted or modified the live hive, enumerate Volume Shadow Copies and grab each shadow's copy of the hive too — see Where Amcache.hve is on disk. On a workstation, two or three shadow copies typically span the last week or two; each is a separate parse target.

2. Parse with multi-pass#

AmcacheParser.exe `
  -f 'C:\Triage\Amcache.hve' `
  --csv 'C:\Triage\Parsed' `
  --csvf 'HOST01_amcache.csv' `
  --mp

The --mp flag is critical here: it recovers orphaned entries that the appraiser deassociated but did not fully delete. Some of those are exactly the kind of "just deleted" rows you are looking for.

3. Filter for suspicious unsigned PEs in user-writable paths#

This is the standard triage filter, with one modification: drop any filter on FullPath existing on disk because the file no longer does.

Import-Csv 'C:\Triage\Parsed\HOST01_amcache_UnassociatedFileEntries.csv' |
  Where-Object {
    $_.IsPeFile -eq 'True' -and
    -not $_.Publisher    -and
    $_.FullPath -match '\\Users\\|\\ProgramData\\|\\AppData\\|\\Temp\\'
  } |
  Select-Object KeyLastWriteTimestamp, FullPath, Hash, Size, LinkDate |
  Sort-Object KeyLastWriteTimestamp

This list is what the attacker dropped (and likely deleted), as the appraiser saw it.

4. Cross-reference against the file system#

For each row, check whether the file still exists on disk:

$rows = Import-Csv ... | Where-Object { ... }
$rows | ForEach-Object {
    $exists = Test-Path -LiteralPath $_.FullPath
    [pscustomobject]@{
        Path     = $_.FullPath
        Hash     = $_.Hash
        SeenAt   = $_.KeyLastWriteTimestamp
        OnDisk   = $exists
    }
} | Where-Object { -not $_.OnDisk }

Rows where OnDisk = False are the deleted-binary candidates.

5. Enrich with VirusTotal#

Hash everything, submit, capture results. Even a low-volume lookup against the public API turns up known-malicious matches on a typical infected host.

import csv, requests, time
 
API = 'https://www.virustotal.com/api/v3/files/'
HEADERS = {'x-apikey': '<your-key>'}
 
with open('deleted_candidates.csv', newline='') as f:
    for row in csv.DictReader(f):
        h = row['Hash']
        if not h:
            continue
        r = requests.get(API + h, headers=HEADERS)
        if r.status_code == 200:
            stats = r.json()['data']['attributes']['last_analysis_stats']
            if stats.get('malicious', 0) > 0:
                print(h, row['Path'], stats)
        time.sleep(15)

For files larger than 31 MiB, remember that Amcache's hash is a prefix hash, not a whole-file hash — see Amcache FileId explained for the nuance.

6. Time-bound the drop event#

For each confirmed-bad deleted binary, take its KeyLastWriteTimestamp ± 1 hour and pull from that window:

• All other Amcache rows (driver + device + other files inventoried in the same window — often the rest of the attacker's toolkit).
• Prefetch (PECmd output) — confirms execution.
• Security 4688 / Sysmon 1 — process creation with command line.
• Sysmon 11 (file create) — confirms when the file was written.
• MFT entries for \Users\bob\...\ — file-system level corroboration.

You typically reconstruct the entire drop + execute + cleanup sequence from these joins, even though the binary itself is gone.

Anti-forensics countermeasures#

A few specific techniques attackers use to hide binaries from Amcache, and how to detect them:

Drop and delete within an appraiser cycle#

If the attacker drops a binary, executes it, and deletes it all within a single appraiser interval (typically <24 h on workstations), the binary may never appear in Amcache at all.

Detection: cross-reference Prefetch (which records execution in real time, surviving binary deletion) and Sysmon 1 / 11 (real-time process and file create) against Amcache. Binaries present in Prefetch / Sysmon but absent from Amcache are "intra-appraiser" drops.

Direct hive modification#

A capable attacker with admin can edit Amcache.hve to remove specific entries. This is uncommon (mostly because it is fiddly and most attackers do not bother) but possible.

Detection: parse the live hive AND all Volume Shadow Copies' versions of the hive. Diff them. Entries present in shadows but absent from live are evidence of deliberate cleanup. Entries present in the live hive but at unexpected offsets are evidence of restructuring.

Appraiser sabotage#

Disabling or hobbling the Compatibility Appraiser scheduled task stops new Amcache writes entirely. Old entries remain (until they age out), but the hive becomes "frozen" at the time of sabotage.

Detection: check the appraiser's task history in the Task Scheduler event log (Microsoft-Windows-TaskScheduler/Operational). Look at the hive's KeyLastWriteTimestamp distribution — if it stops abruptly at some date and you would expect newer entries, suspect sabotage. Also check HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags for DisableInventory or similar disablement values.

Hive deletion#

Outright deletion of Amcache.hve is the bluntest option. Windows recreates the hive on the next appraiser run, but the prior contents are lost from the live system.

Detection: the recreated hive's earliest KeyLastWriteTimestamp will be much more recent than expected. Compare to Volume Shadow Copies and to forensic backups; recover the previous hive from shadows.

What Amcache cannot recover#

Despite its strengths as a post-deletion artefact, Amcache does not recover:

• The binary itself (you have a hash and metadata, not bytes).
• The binary's command line at execution (use Prefetch's file list and 4688 / Sysmon 1 instead).
• Network destinations the binary contacted (use SRUM, firewall logs, EDR network telemetry).
• The user context under which the binary ran (use 4688 / Sysmon 1).

Amcache is one artefact in the post-deletion toolkit. Pair with the other Windows execution-evidence sources for a full reconstruction.

See also#

• Amcache complete reference — the artefact in full.
• Amcache vs Prefetch — the canonical presence-vs-execution comparison.
• Amcache vs ShimCache — the other post-deletion artefact for PE files.
• Amcache FileId explained — the hash you recover from deleted binaries.
• Amcache for malware investigation — the broader intrusion-investigation playbook.

To explore your hive for deleted-binary candidates without installing anything, drop a file on the parser home page — it parses entirely in your browser.