T1578.004: Revert Cloud Instance
An adversary may revert changes made to a cloud instance after they have performed malicious activities in attempt to evade detection and remove evidence of their presence. In highly virtualized environments, such as cloud-based infrastructure, this may be accomplished by restoring virtual machine (VM) or data storage snapshots through the cloud management dashboard or cloud APIs.
Another variation of this technique is to utilize temporary storage attached to the compute instance. Most cloud providers provide various types of storage including persistent, local, and/or ephemeral, with the ephemeral types often reset upon stop/restart of the VM.[1][2]
Analyst context for executives and security teams
Revert Cloud Instance matters because a cloud VM or attached storage can be rolled back after suspicious activity, potentially removing local evidence and weakening incident timelines. For leaders, this is a cloud control and logging assurance issue: if snapshot restores, VM restarts, and storage changes are not independently logged and retained, responders may lose the evidence needed to understand what happened.
Executive priority
Prioritize this where IaaS workloads support critical services or regulated data. The key business question is whether cloud administration actions that can erase or reset evidence are governed, logged, reviewed, and preserved outside the affected instance. This technique sits under Modify Cloud Compute Infrastructure and defense impairment, so it should influence cloud IAM review, change-management evidence, SOC monitoring scope, and incident response readiness.
Technical view
SOC and IR teams should validate visibility into cloud management dashboard and API actions involving VM or disk snapshot restore, instance stop/start or restart behavior, and use of persistent versus ephemeral storage. Because ATT&CK provides no official detection text for this sub-technique, teams should use the related DET0337 detection strategy as relationship context and confirm local cloud audit logs can distinguish approved recovery operations from suspicious infrastructure reversion after other malicious activity.
Likely telemetry
- Cloud control plane audit logs for compute instance and storage snapshot operations
- Cloud API activity logs tied to identities, roles, sessions, and source locations
- VM lifecycle events such as stop, start, restart, restore, or replacement
- Snapshot and disk restore/delete records
- Change-management records for authorized recovery or rollback activity
Detection direction
- Alert or review snapshot restore and instance reversion actions, especially when performed by unusual identities, outside expected maintenance windows, or near other suspicious cloud activity.
- Correlate restore activity with IAM context, API source, affected instance, storage object, and change ticket or approved recovery event.
- Tune for legitimate backup, disaster recovery, and maintenance workflows to reduce false positives while preserving high-fidelity review of unusual rollback behavior.
- Validate that logs are retained outside the reverted instance or ephemeral storage path; otherwise the act of reversion may remove the evidence needed for investigation.
- Use the related DET0337 detection strategy as a starting point, but confirm the exact cloud-provider events and fields available in the local environment.
Mitigation priorities
- Restrict and periodically review permissions that allow VM, disk, and snapshot restore or deletion in IaaS environments.
- Require administrative cloud actions to be attributable to named identities or controlled automation, with change approval for routine rollback activity.
- Retain cloud control plane logs and relevant workload logs outside the instance or storage that could be reverted.
- Include snapshot restore and ephemeral storage behavior in incident response playbooks and evidence-preservation procedures.
- Test whether SOC and IR teams can reconstruct a rollback event using cloud audit data after an instance or disk has been restored.
Analyst notes and limits
This is a sub-technique of T1578 Modify Cloud Compute Infrastructure and is mapped to the defense-impairment tactic for IaaS. The revoked T1536 object points to this technique, indicating continuity from the prior ATT&CK entry. The practical value is not simply detecting a restore, but proving whether rollback actions are authorized, attributable, and survivable from an evidence perspective.
The ATT&CK object does not provide official detection logic, procedure examples, mitigations, or vendor-specific event names. Assessment requires local cloud audit configuration, IAM design, workload logging architecture, and approved operational recovery patterns.
Revert Cloud Instance
An adversary may revert changes made to a cloud instance after they have performed malicious activities in attempt to evade detection and remove evidence of their presence. In highly virtualized environments, such as cloud-based infrastructure, this may be accomplished by restoring virtual machine (VM) or data storage snapshots through the cloud management dashboard or cloud APIs.
Another variation of this technique is to utilize temporary storage attached to the compute instance. Most cloud providers provide various types of storage including persistent, local, and/or ephemeral, with the ephemeral types often reset upon stop/restart of the VM.[1][2]
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
Related techniques
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Enterprise | T1578 | Modify Cloud Compute Infrastructure | This object subtechnique of Modify Cloud Compute Infrastructure. |
| Enterprise | T1536 | Revert Cloud Instance | Revert Cloud Instance revoked by this object. |
All related ATT&CK context
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 2.0 | Current bundle | 65fd6915f3f2… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
Tech Republic - Restore AWS Snapshots
Hardiman, N.. (2012, March 20). Backing up and restoring snapshots on Amazon EC2 machines. Retrieved October 8, 2019.
Open source URL -
[2]
Google - Restore Cloud Snapshot
Google. (2019, October 7). Restoring and deleting persistent disk snapshots. Retrieved October 8, 2019.
Open source URL -
[3]
mitre-attack T1578.004Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.