DC0081: Instance Deletion
Removal of a virtual machine (VM) or compute instance within a cloud infrastructure. This activity results in the termination and deletion of the allocated resources (e.g., CPU, memory, storage), making the instance unavailable for future use. Examples:
- AWS: instance deletion involves the `TerminateInstances` API call, which is recorded in CloudTrail logs. - Azure: VM deletion can be monitored via Azure Activity Logs, showing the `Microsoft.Compute/virtualMachines/delete` operation. - GCP: instance deletion is logged as an instance.delete operation within GCP Audit Logs.
Analyst context for executives and security teams
Instance Deletion is the cloud-control-plane event where a VM or compute instance is terminated and removed. For leaders, this matters because loss of compute capacity can directly affect service availability, incident recovery, forensic preservation, and evidence needed for audit or insurance review. Even when deletion is legitimate, organizations need to know who approved it, whether it was expected, and whether logs and backups are sufficient to explain and recover from it.
Executive priority
Prioritize this as a cloud resilience and accountability control. Security and IT leaders should ask whether instance deletion events are centrally logged across cloud accounts/projects/subscriptions, reviewed against change-management expectations, and retained long enough to support incident response and compliance evidence. The business decision value is not simply detecting deletion, but proving whether a deletion was authorized, recoverable, and non-disruptive.
Technical view
ATT&CK defines this data component as removal of a VM or compute instance in cloud infrastructure. The supplied examples identify AWS CloudTrail `TerminateInstances`, Azure Activity Logs `Microsoft.Compute/virtualMachines/delete`, and GCP Audit Logs `instance.delete` as relevant evidence. SOC and IR teams should validate that these control-plane events are collected, normalized, time-synchronized, attributable to an identity or service principal where available, and correlated with change tickets or approved automation. No ATT&CK detection guidance or technique relationships were supplied, so local detection logic must be based on environment baselines and business-critical asset context.
Likely telemetry
- AWS CloudTrail events for `TerminateInstances`
- Azure Activity Logs containing `Microsoft.Compute/virtualMachines/delete`
- GCP Audit Logs containing `instance.delete`
- Cloud identity context associated with the deletion request, where available in logs
- Asset inventory or CMDB records showing the deleted instance and its business owner
Detection direction
- Confirm ingestion and retention of cloud control-plane audit logs for all relevant accounts, subscriptions, and projects.
- Alert or review deletion of production, internet-facing, regulated, or otherwise business-critical instances when not matched to an approved change or automation workflow.
- Tune for expected autoscaling, lifecycle management, infrastructure-as-code, and decommissioning activity to reduce false positives.
- Correlate deletion events with identity, source context, asset criticality, and timing, especially after unusual administrative activity.
- Validate that deleted-instance records remain searchable after the resource is gone; a common blind spot is relying only on live asset inventory.
Mitigation priorities
- Define which users, roles, service principals, and automation pipelines are permitted to delete compute instances.
- Require change approval or compensating review for deletion of critical workloads.
- Ensure cloud audit logging is enabled, centrally collected, protected from tampering, and retained for IR and compliance needs.
- Maintain recoverability through backups, images, infrastructure-as-code, or rebuild procedures appropriate to the workload.
- Periodically test whether incident responders can identify who deleted an instance, when it occurred, what was affected, and how to restore service.
Analyst notes and limits
This object is a data component, not a technique, and no tactics, platforms field, official detection text, or relationship context were supplied. The official description does include cloud-provider examples for AWS, Azure, and GCP logging, which supports cloud telemetry guidance. Use local asset criticality, change records, and identity context to decide what is suspicious versus normal operations.
This take is limited to the supplied ATT&CK fields and references. It does not establish adversary use, impact, attribution, or guaranteed detection. Because no official detection guidance or relationships were provided, detection recommendations are conservative validation directions rather than MITRE-specified analytics.
Instance Deletion
Removal of a virtual machine (VM) or compute instance within a cloud infrastructure. This activity results in the termination and deletion of the allocated resources (e.g., CPU, memory, storage), making the instance unavailable for future use. Examples:
- AWS: instance deletion involves the `TerminateInstances` API call, which is recorded in CloudTrail logs. - Azure: VM deletion can be monitored via Azure Activity Logs, showing the `Microsoft.Compute/virtualMachines/delete` operation. - GCP: instance deletion is logged as an instance.delete operation within GCP Audit Logs.
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.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
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 | 5970877dfb25… |
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]
mitre-attack DC0081Open 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.