How would an attacker clean Amcache?

Three options. Delete Amcache.hve and the .LOG files outright (loud, the appraiser recreates an empty hive on next pass). Edit individual InventoryApplicationFile sub-keys after loading the hive offline (subtle, but transaction logs and shadows usually preserve the originals). Or disable the Compatibility Appraiser task to freeze the hive (sneakiest, but a frozen hive is itself a tell).

How do I detect tampering?

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

Do attackers actually do this?

Rarely. Most commodity malware and even most APT toolkits do not touch Amcache. The artefact isn't well-known among general malware authors and cleaning it correctly takes Windows-internals knowledge most actors don't have. When you do see signs of Amcache tampering, treat it as a sophistication signal.

What's the subtlest attack against Amcache?

Disabling the Compatibility Appraiser via GPO (AllowTelemetry=0) or task disablement. The hive isn't deleted, it just stops updating. A defender who doesn't think to check the appraiser's last run time will miss it entirely.

Can Amcache evidence be permanently destroyed?

Not reliably. Live-hive editing still leaves traces in shadow copies. VSS deletion still leaves traces in forensic file recovery and SSD wear-levelling artefacts. Microsoft-Windows-Application-Experience event logs sometimes preserve appraiser activity independently of the hive itself.

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

Yes, with administrative rights. No, not invisibly. An attacker can delete the hive, edit specific entries inside it, or disable the Compatibility Appraiser scheduled task. All three options leave a tell. Volume Shadow Copies usually retain recent snapshots of the original hive. The transaction logs may hold writes that never made it to the live file. A freshly-recreated hive after deletion has a KeyLastWriteTimestamp distribution that starts abruptly and reaches back nowhere. 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, with admin rights, an attacker can delete Amcache.hve, edit it, or stop the Compatibility Appraiser from writing to it. No, none of those options are quiet. Three independent sources usually preserve the prior state:

Volume Shadow Copies, which take point-in-time volume snapshots and each carry their own copy of Amcache.hve. Retention varies from days to weeks.
Registry transaction logs (Amcache.hve.LOG1 and Amcache.hve.LOG2) that may hold recent writes the attacker did not think to remove.
Recreation-time signatures. A hive that was deleted and rebuilt by the next appraiser pass has a KeyLastWriteTimestamp distribution that starts abruptly at the recreation date and reaches back nowhere, which on a long-running host is a dead giveaway.

Recovering ~30% of "deleted" entries from .LOG1 and .LOG2 is normal on cases where the attacker deleted keys but did not clear the logs. Recovering more from shadow copies is also normal.

The three approaches, in increasing subtlety#

Wholesale deletion#

The blunt instrument. The attacker kills compattelrunner.exe and the registry process (or queues a Pending File Rename), then removes the file. The next appraiser pass recreates the hive empty. Trivial to detect on any host where the hive should be substantial.

Targeted key deletion#

Load the hive offline (or in place if you can hold the lock), reg delete the specific InventoryApplicationFile\<id> sub-keys you want gone. More subtle. But:

The parent key's LastWrite advances. So the row above moves while the row itself disappears, which on a sorted dump looks odd.
The transaction logs frequently still hold the original record. Replay them and you get the entry back.
Volume Shadow Copies hold yesterday's hive untouched. Diff against it.

Disable the appraiser#

The sneakiest option. The hive isn't modified. New entries just stop arriving. You can:

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

Or disable \Microsoft\Windows\Application Experience\Microsoft Compatibility Appraiser in Task Scheduler. The hive freezes. A defender who doesn't specifically check the appraiser's LastRunTime and the KeyLastWriteTimestamp distribution may completely miss it.

How to detect it#

Parse the live Amcache.hve and capture the KeyLastWriteTimestamp distribution. Earliest, latest, density per week.
Enumerate Volume Shadow Copies (vssadmin list shadows) and parse each shadow's copy of the hive. Diff against live.
Check the scheduled task: Get-ScheduledTask, look at LastRunTime, State, history in Microsoft-Windows-TaskScheduler%4Operational.evtx (your EVTX parser of choice).
Check GPO and HKLM\SOFTWARE\Policies\Microsoft\Windows\DataCollection\AllowTelemetry.

A live hive whose KeyLastWriteTimestamp distribution dies on a Tuesday a few months ago, on a host you know has been busy since, is a strong tampering signal. Diff against shadows to confirm what is missing.

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

How often does this come up#

Rarely. Commodity malware never bothers. Most APT operators don't either, because the artefact is unfamiliar and cleaning it correctly takes more Windows-internals knowledge than most have. When you do see signs of Amcache tampering, treat it as a sophistication signal and pay closer attention to neighbouring artefacts (Shimcache, Sysmon, EDR) for similar moves.