DET0084: Detection Strategy for Modify Cloud Compute Infrastructure: Delete Cloud Instance
DET0084 is a detection strategy placeholder for ATT&CK technique T1578.003, Delete Cloud Instance. The practical issue is that cloud instance deletion can...
Analyst context for executives and security teams
DET0084 is a detection strategy placeholder for ATT&CK technique T1578.003, Delete Cloud Instance. The practical issue is that cloud instance deletion can erase or reduce access to forensic evidence after malicious activity. For leaders, this makes cloud audit logging, retention, and incident response readiness important business controls, not just technical settings.
Executive priority
Prioritize this as a resilience and evidence-preservation concern for IaaS environments. Security leaders should ask whether cloud instance deletion events are logged, retained outside the affected instance, reviewed in context, and usable during an incident. The key business decision is whether the organization can still investigate suspicious cloud activity after compute resources are terminated.
Technical view
The supplied ATT&CK object has no official detection text and no platform listed on the detection strategy itself. Its relationship states that it detects T1578.003, Delete Cloud Instance, which is associated with defense impairment on IaaS. SOC and IR teams should validate visibility into cloud control-plane activity for instance or virtual machine termination, correlate deletion with prior suspicious activity, and confirm that forensic-relevant logs and snapshots are not solely dependent on the deleted instance.
Likely telemetry
- Cloud control-plane audit logs for instance or virtual machine deletion events
- Identity and access records showing the principal, role, user, or service account that initiated deletion
- Cloud resource inventory or asset lifecycle records showing creation, modification, and termination timing
- Incident response evidence stores such as centralized logs, retained snapshots, or exported forensic artifacts where available
- Alerts or case context for suspicious activity preceding deletion of the same instance
Detection direction
- Validate that instance deletion events are captured from IaaS control-plane logs and retained centrally.
- Correlate deletion events with recent instance creation, privilege changes, unusual access, or suspicious activity involving the same cloud resource or identity.
- Tune for legitimate administrative activity such as autoscaling, maintenance, decommissioning, or infrastructure-as-code workflows to reduce false positives.
- Pay special attention to deletions by unexpected identities, newly used credentials, or accounts not normally responsible for compute lifecycle management.
- Identify blind spots where logs, forensic artifacts, or workload evidence disappear when the instance is deleted.
Mitigation priorities
- Ensure cloud audit logs are enabled and retained outside the compute instance lifecycle.
- Restrict cloud instance deletion permissions to approved roles and workflows.
- Maintain asset inventory and lifecycle tracking for IaaS compute resources.
- Define incident response procedures for preserving evidence before or immediately after cloud resource termination when feasible.
- Review retention and compliance requirements to ensure deletion of infrastructure does not eliminate required security evidence.
Analyst notes and limits
This take is based on the detection strategy object DET0084 and its relationship to T1578.003 Delete Cloud Instance. Because the official detection strategy description and detection guidance are not provided, the recommendations focus on defensible validation questions derived from the related ATT&CK technique: deletion of cloud instances may remove forensic artifacts and evidence.
The detection strategy object does not specify platforms, tactics, description, or detection logic. IaaS and defense-impairment context come from the related technique only. Local cloud architecture, logging configuration, retention policy, and administrative workflows are required to determine actual coverage and alerting value.
Detection Strategy for Modify Cloud Compute Infrastructure: Delete Cloud Instance
No official description is available in the imported ATT&CK source object.
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.
Techniques used
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.003 | Delete Cloud Instance Sub-technique | This object detects Delete Cloud Instance. |
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 | 1.0 | Current bundle | cc88a4c1bd5e… |
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 DET0084Open 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.