How would an attacker clean Amcache?

Three common approaches: outright delete Amcache.hve and its transaction logs (loud, recreated by the next appraiser pass); selectively edit individual InventoryApplicationFile sub-keys (subtle, requires Registry Editor-equivalent access while the hive is loaded); or disable the Compatibility Appraiser scheduled task to freeze the hive (sneaky, but the absence of new entries is itself a tell).

How do I detect Amcache tampering?

Enumerate Volume Shadow Copies with 'vssadmin list shadows' or vshadowmount, parse each shadow copy's Amcache.hve, and diff the entries against the live hive. Entries present in shadows but missing from live are evidence of deliberate cleanup. Also check the scheduled task's LastRunTime and the hive's KeyLastWriteTimestamp distribution.

Do attackers typically clean Amcache?

Rarely. Most commodity malware and even most APT toolkits do not bother cleaning Amcache — it is not a well-known artefact among general malware authors, and cleaning it requires specific Windows-internals knowledge. When you do see signs of Amcache tampering, treat it as a strong signal of a more sophisticated actor.

What's the most subtle attack against Amcache?

Disabling the Compatibility Appraiser via Group Policy (AllowTelemetry=0) or task disablement. The hive is not deleted — it just stops updating. A defender who does not specifically check the appraiser's last run time may miss this entirely.

Can Amcache evidence ever be definitively destroyed?

Not reliably. Even after live-hive editing, Volume Shadow Copies often preserve history. Even after VSS deletion, forensic file recovery and SSD wear-levelling can recover prior versions. And the legacy DfsTrace / SetupAct / Microsoft-Windows-Application-Experience event logs sometimes preserve appraiser activity independently.

Can Amcache.hve be cleared or modified by an attacker?

Yes, an attacker with administrative rights can delete Amcache.hve, edit specific entries inside it, or disable the Compatibility Appraiser scheduled task that maintains it. However, the cleanup is detectable through three mechanisms: Volume Shadow Copies typically preserve recent snapshots of the original hive, registry transaction logs may preserve recent writes, and a freshly-recreated hive after deletion has a 'KeyLastWriteTimestamp' distribution that starts abruptly at the recreation time rather than reaching back months. Combining those three sources, anti-forensic Amcache tampering is one of the more reliably detected attacker behaviours on Windows.

Can Amcache be cleared by attackers?

Yes — but cleanup is detectable. An attacker with administrative rights can delete Amcache.hve, edit specific entries inside it, or disable the Compatibility Appraiser scheduled task. None of these options are silent. Three independent forensic sources usually preserve the prior state:

Volume Shadow Copies — point-in-time snapshots of the volume taken by VSS, typically retained for one to several weeks. Each shadow has its own copy of Amcache.hve.
Registry transaction logs — Amcache.hve.LOG1 and Amcache.hve.LOG2 may preserve recent writes that an attacker did not think to delete.
Recreation-time signature — a freshly recreated hive after deletion has a KeyLastWriteTimestamp distribution that starts abruptly at the recreation time, with no entries reaching back months as you would expect on a long-lived host.

How attackers typically try#

Three approaches, in increasing subtlety:

1. Delete the hive and its logs#

# (Attacker action — not for defenders to run)
Remove-Item 'C:\Windows\AppCompat\Programs\Amcache.hve*' -Force

Loud. The next appraiser pass recreates the hive — empty except for whatever happens to be running now. The recreation signature is obvious to any defender who knows to look.

2. Edit specific entries#

The attacker loads the hive (e.g. as a sub-tree of HKLM) and deletes specific InventoryApplicationFile sub-keys corresponding to their tooling.

More subtle, but the registry transaction logs may still hold the original writes, and Volume Shadow Copies hold the pre-tampering hive.

3. Disable the appraiser#

HKLM\SOFTWARE\Policies\Microsoft\Windows\DataCollection
  AllowTelemetry = REG_DWORD 0

Or disable the scheduled task at \Microsoft\Windows\Application Experience\Microsoft Compatibility Appraiser.

The hive is not modified — it just stops updating. A defender who does not check the appraiser's LastRunTime may not notice.

How to detect tampering#

The defender workflow:

Parse the live Amcache.hve and capture the KeyLastWriteTimestamp distribution (earliest, latest, density per week).
Enumerate Volume Shadow Copies and parse each shadow's copy of the hive. Diff against the live hive.
Check the scheduled task — LastRunTime, State, history.
Check the GPO — AllowTelemetry, related DataCollection values.

A live hive with a KeyLastWriteTimestamp that stops abruptly some weeks ago, on a host that you know has been running and seeing new software, is suspicious. Diff against shadows to confirm what is missing.

For the full anti-forensics workflow, see Recovering deleted-binary evidence from Amcache.

How common is this?#

Rare. Commodity malware and most APT toolkits do not bother cleaning Amcache. The artefact is not widely known among general malware authors, and effective cleanup requires Windows-internals knowledge most actors do not have.

When you do see signs of Amcache tampering, treat it as a strong signal of a more sophisticated actor — and pay extra attention to neighbouring artefacts (ShimCache, Sysmon, EDR telemetry) for similar tampering.