Revert Cloud Instance (T1578.004) is a sub-technique of Modify Cloud Compute Infrastructure in the defense impairment tactic, for IaaS. The adversary reverts changes made to a cloud instance after their activity, to evade detection and remove evidence.
How attackers use it
In highly virtualized environments this can be done by restoring VM or storage snapshots through the cloud management dashboard or APIs. MITRE describes a second variation: using temporary storage attached to the instance. Providers offer persistent, local and ephemeral storage, and ephemeral types are often reset when the VM stops or restarts.
How to detect it
MITRE's analytic suggests watching for unusual snapshot restores, rollback actions or ephemeral storage resets outside normal administrative workflows. Chains that stand out:
- A snapshot restore triggered by a new or rarely used account
- Snapshot creation followed at once by a restore and an instance start
- Rollbacks from unusual geographic or network locations
MITRE notes these can mean attempts to remove forensic evidence or return to a clean execution state for persistence.
Since a revert removes on-host evidence, collect logs off the instance. Cloud audit logs record the restore, and centrally shipped host logs keep what happened before it.
How to reduce the risk
The MITRE record lists no specific mitigations for this sub-technique. The parent technique's controls apply: least privilege for compute changes, and routine audit of who holds those permissions. See the Modify Cloud Compute Infrastructure (T1578) post.
Check your own environment
- Which identities can restore snapshots or reset instance storage?
- Do any workloads depend on ephemeral storage for logs? Move logs off the instance.
- Do you alert on a snapshot, restore and start sequence from one identity?
Quick check
Why can ephemeral storage be used to remove evidence?
Ephemeral storage is often reset when the VM stops or restarts, so anything written there can disappear.