Skip to content
Reverse Engineering
Anti-Forensicadvanced

Amcache & Shimcache Tampering

Attackers delete or forge Amcache and Shimcache entries to erase execution evidence, but the two artifacts and their backups rarely agree.

Amcache (Amcache.hve) and Shimcache (the AppCompatCache registry value) are two of the most valuable execution-evidence artifacts on Windows: they can prove a binary existed and ran even after the file itself is deleted. Amcache records SHA-1 hashes, full paths, and first-execution metadata for binaries; Shimcache records path, size, and last-modified time for executables the Application Compatibility engine evaluated. Because they survive file deletion, a careful actor who wants to erase proof of a dropped tool will try to scrub the corresponding cache entries.

Tampering takes two forms: deletion of specific records, and forgery of plausible-looking entries. Both are far harder than they appear, because each artifact is written, flushed, and backed up on its own schedule. The attacker rarely controls all of those copies at once, and the surviving copies disagree — which is exactly what the analyst exploits.

How it works

Shimcache lives entirely in memory under HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\AppCompatCache\AppCompatCache and is only serialized to the registry hive on a clean shutdown. Amcache is a standalone hive flushed periodically by a scheduled task. An actor with SYSTEM may delete a specific Amcache entry or overwrite the binary AppCompatCache blob to drop a path:

# Conceptual: load the Amcache hive offline and remove the
# InventoryApplicationFile key for the payload, then reload it.
reg load HKLM\Tmp C:\Windows\AppCompat\Programs\Amcache.hve
# (delete the offending InventoryApplicationFile\<id> subkey)
reg unload HKLM\Tmp

Forging is harder still: Shimcache's blob is a packed structure with a header and per-entry length fields, so a hand-edited entry that miscounts bytes corrupts the whole cache and is itself an indicator. Few tools touch these artifacts correctly, which makes tampering noisy.

Detection & analysis

Static analysis:

  • Parse both artifacts and cross-correlate them. Tools: AmcacheParser and AppCompatCacheParser (Eric Zimmerman), RegRipper. A binary present in Shimcache but absent from Amcache (or vice versa) for a recently-active path is suspicious — the two are populated by different mechanisms but normally overlap heavily for executed files.
  • Validate the AppCompatCache blob structure: check the header magic for the OS version and confirm entry-count and per-entry length fields are internally consistent. A truncated, miscounted, or signature-mismatched blob indicates direct manipulation rather than normal OS serialization.
  • Recover prior versions of Amcache.hve and the SYSTEM hive from Volume Shadow Copies, the RegBack folder, and winsxs/backup locations. An entry deleted from the live hive frequently survives in a shadow copy with its original SHA-1 and timestamp intact.

Dynamic analysis:

  • Watch for offline hive manipulation: reg load/reg unload against Amcache.hve, or processes opening AppCompat\Programs\*.hve for write outside the CompatTelRunner.exe scheduled task. Sysmon Event ID 13 (registry value set) on the AppCompatCache value from a non-system process is a strong signal.
  • Correlate against independent execution evidence that the attacker did not touch: Prefetch (.pf), SRUM (SRUDB.dat), UserAssist, BAM/DAM registry keys, and Sysmon Event ID 1. If five sources show a binary ran and Amcache alone is silent, Amcache was likely scrubbed.

Detection rule hint: Alert when the AppCompatCache value is written by any process other than the legitimate shutdown serialization, and when an Amcache.hve InventoryApplicationFile entry present in a shadow copy is missing from the live hive. Always rebuild the execution timeline from Prefetch, SRUM, and BAM in parallel — recovering the deleted Amcache SHA-1 from a shadow copy is often what re-identifies the wiped payload.

Votes

Comments(0)