Amcache Forensic Analysis: SHA1 Hashes, Deleted Binaries, AmcacheParser

Amcache is the only execution-related artifact that records a file hash. When the attacker deletes a binary after running it, Amcache may be the only source that identifies what the tool was.

Amcache is a registry hive (C:\Windows\AppCompat\Programs\Amcache.hve) that records metadata about executables the Application Compatibility subsystem evaluated. Each entry includes the file path, SHA1 hash, file size, publisher metadata, and a timestamp. The hive persists on disk and is not affected by Prefetch capacity limits or event log rotation. Even after the attacker deletes the binary, the Amcache entry remains.

Estimated time: 35 minutes.

Evidence location and availability

Amcache is present on Windows 7 and later. Unlike Prefetch, it is available on Windows Server editions. Unlike event logs, it does not rotate based on size. Amcache entries persist until the hive is explicitly cleared or the entry is overwritten by a newer evaluation of the same application path.

Parsing with AmcacheParser

# Parse Amcache hive to CSV
AmcacheParser.exe -f "E:\Collection\C\Windows\AppCompat\Programs\Amcache.hve" --csv "C:\Forensics\Processed\case-001" --csvf "amcache.csv"

AmcacheParser produces multiple CSV files. The primary one for execution analysis is amcache_UnassociatedFileEntries.csv (or amcache_InventoryApplicationFile.csv on newer Windows builds). The schema changed between Windows 10 versions. AmcacheParser handles both.

Amcache hive structure

The Amcache hive contains multiple registry keys. The two most forensically relevant:

InventoryApplicationFile. Present on Windows 10 1607 and later. Contains entries with SHA1 hash, file path, publisher, product name, version, file size, and a LinkDate (PE compile timestamp). This is the primary source for attacker tool identification. Each entry has a FileId subkey containing the SHA1 hash.

InventoryApplication. Contains entries for installed applications (MSI packages, APPX packages). These entries represent installed software rather than individual executables. Less useful for attacker tool identification but valuable for establishing what software was installed on the system.

On older Windows 10 builds (pre-1607) and Windows 7/8, the structure uses Root\File\{Volume GUID}\ keys instead of InventoryApplicationFile. The data fields are similar but the key paths differ. AmcacheParser normalizes both schemas into the same CSV output format, so you do not need to handle the version differences manually.

When Amcache entries are missing

Not every executed binary produces an Amcache entry. The Application Compatibility subsystem evaluates binaries asynchronously. A binary that executes and terminates within a few seconds may not be evaluated before it exits. Specifically:

Short-lived processes (tools that run and exit in under 2-3 seconds) may not generate entries. The Prefetch subsystem is faster and more likely to capture these. .NET assemblies loaded via Assembly.Load() or PowerShell's Add-Type execute within an existing process and do not create separate Amcache entries. Scripts (PowerShell .ps1, batch .bat, VBScript .vbs) do not have their own Amcache entries; the interpreter (powershell.exe, cmd.exe, cscript.exe) has the entry instead.

When you expect an Amcache entry based on Prefetch evidence but find none, check whether the binary was a script, a .NET assembly, or a very short-lived process. The absence does not mean the binary did not execute. It means the compatibility subsystem did not evaluate it before it was gone.

Reading AmcacheParser output

Annotated entry for update.exe from the investigation evidence.

SHA1:           da39a3ee5e6b4b0d3255bfef95601890afd80709  The hash. Submit to VT.
FullPath:       C:\Users\Public\update.exe                   Where it lived before deletion.
FileSize:       1245184                                       ~1.2 MB
Publisher:      (empty)                                       No digital signature. Unsigned binary.
ProductName:    (empty)                                       No product metadata.
BinaryVersion:  (empty)                                       No version info.
FileKeyLastWriteTimestamp: 2026-03-15 03:17:22               Approximates first evaluation.
LinkDate:       2026-01-08 14:33:00                          PE compile timestamp.

SHA1 hash. This is the primary forensic value of Amcache. The hash identifies the binary's contents regardless of what it was named. Submit it to VirusTotal, your internal threat intelligence platform, or compare it against known-bad hash lists. If the hash matches Mimikatz v2.2.0, you know exactly what update.exe was, even though the file no longer exists on the filesystem.

# Quick VirusTotal lookup (requires VT API key)
$hash = "da39a3ee5e6b4b0d3255bfef95601890afd80709"
$vtUrl = "https://www.virustotal.com/gui/file/$hash"
Write-Host "VirusTotal lookup: $vtUrl"

# Or use the VT API
Invoke-RestMethod -Uri "https://www.virustotal.com/api/v3/files/$hash" `
  -Headers @{ "x-apikey" = $env:VT_API_KEY } |
  Select-Object -ExpandProperty data |
  Select-Object -ExpandProperty attributes |
  Select-Object meaningful_name, type_description, reputation,
    @{N='Detections';E={$_.last_analysis_stats.malicious}}

Empty publisher and product metadata. Legitimate software almost always has publisher information, a product name, and a version number embedded in the PE header. Attacker tools compiled from source or packed/modified binaries frequently lack this metadata. An unsigned binary with no product name in a user-writable directory is worth investigating even before the hash result comes back.

LinkDate (compile timestamp). The PE header compile timestamp. This can be forged by the attacker, but many tools are compiled from source without modifying the timestamp. A compile date of January 2026 on a binary first seen on March 15 suggests the attacker built or downloaded the tool months before deploying it.

FileKeyLastWriteTimestamp. This approximates when the system first evaluated the binary. For attacker tools dropped and executed during an intrusion, this is close to the actual execution time. Compare it with the Prefetch LastRun timestamp from Section 2.2 for corroboration.

Cross-referencing Amcache with the Prefetch shortlist

The Prefetch triage from Section 2.2 produced a shortlist of five suspect executables. For each one, search the Amcache CSV for the matching file path:

# Load Amcache CSV and search for suspects
$amcache = Import-Csv "C:\Forensics\Processed\case-001\amcache.csv"

$suspects = @(
    "C:\Users\Public\svchost.exe",
    "C:\Users\Public\update.exe",
    "C:\Users\Public\procdump64.exe",
    "C:\Users\Public\7za.exe",
    "C:\Users\Public\rclone.exe"
)

foreach ($path in $suspects) {
    $match = $amcache | Where-Object { $_.FullPath -eq $path }
    if ($match) {
        Write-Host "$path"
        Write-Host "  SHA1: $($match.SHA1)"
        Write-Host "  Size: $($match.FileSize)"
        Write-Host "  First seen: $($match.FileKeyLastWriteTimestamp)"
        Write-Host "  Publisher: $(if ($match.Publisher) { $match.Publisher } else { '(none)' })"
    } else {
        Write-Host "$path - NO AMCACHE ENTRY"
    }
}

For each suspect with an Amcache entry, you now have the SHA1 hash. Submit each hash to VirusTotal. The result converts your shortlist from "five unknown executables" to "Mimikatz, Cobalt Strike beacon, procdump, 7-Zip, and rclone." That identification changes the investigation from "something suspicious happened" to "credential theft and data exfiltration using specific tools."

For suspects without an Amcache entry: the binary may have executed too briefly for the compatibility subsystem to evaluate it, or the Amcache hive may have been cleaned. Note the gap and rely on other sources (DLL profiles from Prefetch, command lines from event logs) for identification.

The execution question: does Amcache prove execution?

Amcache entries can be created without the binary executing. The Application Compatibility subsystem may evaluate a binary during installation, file copy, or directory browsing. This means an Amcache entry alone does not prove execution to the same standard as Prefetch or Event 4688.

In practice, for attacker tools dropped into staging directories during an intrusion, the distinction rarely matters. The attacker dropped update.exe into C:\Users\Public\ and the system evaluated it within seconds of the drop. Whether the evaluation happened because the binary executed or because the system detected a new executable in the directory, the result is the same: the tool was present, the hash is recorded, and the timestamp is close to the actual execution.

The distinction matters for installed software and system utilities. An application that appears in Amcache because it was installed via MSI but never launched is present on the system but did not execute. For your shortlist of attacker tools dropped during an active intrusion, treat the Amcache entry as strong corroboration of the Prefetch execution evidence, not as standalone proof.

Before moving on, verify your understanding: parse the Amcache hive from your KAPE collection with AmcacheParser. Search the output for entries with paths in user-writable directories (Users\Public, ProgramData, Windows\Temp). For any entries you find, submit the SHA1 hash to VirusTotal and record the result. Note which entries have empty Publisher fields.

Next: Section 2.4 covers Shimcache, BAM, and SRUM. Three sources that provide execution context where Prefetch and Amcache are absent or incomplete.