T1578.003: Delete Cloud Instance
An adversary may delete a cloud instance after they have performed malicious activities in an attempt to evade detection and remove evidence of their presence. Deleting an instance or virtual machine can remove valuable forensic artifacts and other evidence of suspicious behavior if the instance is not recoverable.
An adversary may also Create Cloud Instance and later terminate the instance after achieving their objectives.[1]
Analyst context for executives and security teams
Deleting an IaaS cloud instance can turn a security incident into an evidence problem. If an attacker terminates a virtual machine after using it, the organization may lose host artifacts, runtime context, and investigative leads unless cloud audit logs and recoverability controls are already in place.
Executive priority
Prioritize this as a cloud resilience and incident-readiness issue, not only a SOC alerting issue. Leaders should ask whether privileged users can delete compute instances without review, whether deletion activity is retained in audit records, and whether IR teams can still investigate when the instance itself is gone. This also matters for compliance evidence because the key proof may be in cloud control-plane logs rather than on the deleted host.
Technical view
For IaaS environments, validate monitoring around cloud compute infrastructure changes, specifically instance or virtual machine termination/deletion events. Because ATT&CK provides no official detection text for this sub-technique, use the related DET0084 detection strategy as a direction to review control-plane activity for Modify Cloud Compute Infrastructure behavior. Correlate deletion events with actor identity, account lifecycle state, privilege level, recent instance creation, and other suspicious activity. Treat the parent technique T1578 as context: deletion may follow adversary-created infrastructure or other compute modifications intended to impair defenses.
Likely telemetry
- Cloud control-plane audit logs for compute instance deletion or termination events
- Identity and access management logs showing the principal, role, session, or account used
- Cloud configuration or asset inventory records showing instance lifecycle state changes
- Incident response evidence from snapshots, backups, or retained disk artifacts if available
- Change-management or ticketing evidence to distinguish approved administrative deletion from suspicious activity
Detection direction
- Confirm that cloud audit logging is enabled, retained, and searchable for compute deletion events across IaaS accounts/projects/subscriptions.
- Tune detections to prioritize deletions by unusual principals, recently created or modified accounts, high-privilege roles, or activity outside expected change windows.
- Correlate Delete Cloud Instance activity with Create Cloud Instance or other Modify Cloud Compute Infrastructure events where available.
- Account for false positives from autoscaling, scheduled maintenance, decommissioning, and approved infrastructure-as-code workflows.
- Identify blind spots where logs are retained for less time than IR needs, where deleted instances remove host evidence, or where SOC visibility depends only on endpoint telemetry.
Mitigation priorities
- Apply User Account Management principles: limit who can delete cloud instances and ensure account creation, modification, and deactivation are governed.
- Enforce least privilege for compute administration so deletion rights are not broadly assigned.
- Maintain auditing for cloud administrative activity and systematically review instance lifecycle changes.
- Ensure audit records and relevant forensic artifacts are retained independently of the instance being deleted.
- Validate incident response procedures for recovering evidence when a cloud instance is no longer available.
Analyst notes and limits
ATT&CK maps this sub-technique to the defense-impairment tactic on IaaS platforms. The supplied relationships identify DET0084 as a detection strategy and M1018 User Account Management plus M1047 Audit as mitigations. ATT&CK also lists LAPSUS$ and Storm-0501 as groups that use this object; that is useful threat-intelligence context but should not be interpreted as evidence of current targeting in any specific environment.
The official ATT&CK detection field is not provided, so detection guidance must be validated against local cloud provider logs, administrative workflows, retention settings, and approved automation. The supplied data does not identify specific cloud vendors, APIs, log field names, active exploitation, or guaranteed detection coverage.
Delete Cloud Instance
An adversary may delete a cloud instance after they have performed malicious activities in an attempt to evade detection and remove evidence of their presence. Deleting an instance or virtual machine can remove valuable forensic artifacts and other evidence of suspicious behavior if the instance is not recoverable.
An adversary may also Create Cloud Instance and later terminate the instance after achieving their objectives.[1]
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. |
Groups, software, and campaigns
G1004: LAPSUS$
LAPSUS$ is cyber criminal threat group that has been active since at least mid-2021. LAPSUS$ specializes in large-scale social engineering and extortion operations, including destructive attacks without the use of ransomware. The group has targeted organizations globally, including in the government, manufacturing, higher education, energy, healthcare, technology, telecommunications, and media sectors.[1][2][3]
G1053: Storm-0501
Storm-0501 is a financially motivated cyber criminal group that uses commodity and open-source tools to conduct ransomware operations. Storm-0501 has been active since 2021 and has previously been affiliated with Sabbath Ransomware and other Ransomware-as-a-Service (RaaS) variants such as Hive, BlackCat, Hunters International, LockBit 3.0, and Embargo ransomware.[1][2][3][4]
All related ATT&CK context
Mitigation direction
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 | aa4b0faf9262… |
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]
Mandiant M-Trends 2020
Mandiant. (2020, February). M-Trends 2020. Retrieved November 17, 2024.
Open source URL -
[2]
mitre-attack T1578.003Open 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.