AN0234: Analytic 0234
Defenders can detect suspicious cloud instance deletions by correlating events across authentication, instance lifecycle, and account activity. From a defender’s perspective, behaviors of interest include instances deleted shortly after creation, deletions initiated by new or rarely used accounts, deletions following snapshot creation, and deletions originating from anomalous geolocations or access keys. These may indicate adversarial attempts to destroy forensic evidence or evade detection.
Analyst context for executives and security teams
AN0234 focuses on suspicious deletion of cloud compute instances in IaaS environments. For leaders, the practical issue is not only asset loss; instance deletion can remove forensic evidence, interrupt services, or hide earlier activity. The behavior is material when cloud operations, incident response, and audit teams cannot reliably answer who deleted an instance, from where, using which credential, and what happened immediately before deletion.
Executive priority
Prioritize this analytic where IaaS workloads support business-critical services or regulated evidence retention. Security and cloud leaders should confirm that instance lifecycle events, identity activity, access key usage, geolocation context, and snapshot events are retained and correlated. The business decision value is incident readiness: during a cloud event, teams need fast evidence to distinguish normal operations from possible evidence destruction or detection evasion.
Technical view
SOC and detection teams should validate correlation across authentication, instance lifecycle, and account activity for IaaS. Behaviors of interest from the ATT&CK description include instances deleted shortly after creation, deletions by new or rarely used accounts, deletions after snapshot creation, and deletions from anomalous geolocations or access keys. Because no official detection logic is provided, teams should implement environment-specific baselines for normal deletion workflows, cloud automation accounts, and expected administrative locations.
Likely telemetry
- IaaS instance lifecycle events, especially create and delete actions
- Cloud authentication and authorization logs
- Cloud account activity and administrative API audit logs
- Access key or credential usage records
- Source geolocation or network origin metadata for cloud API activity
Detection direction
- Correlate instance creation, snapshot creation, and instance deletion timelines rather than alerting on deletion alone.
- Prioritize deletions by new, rarely used, or unusual identities, including access keys not normally associated with instance administration.
- Compare source geolocation or network origin against normal administrative patterns to reduce noise and identify anomalous deletion activity.
- Tune for known automation, autoscaling, lifecycle management, and approved cleanup processes to manage false positives.
- Confirm retention and searchability of cloud audit logs before an incident; this analytic depends on cross-event correlation rather than a single event.
Mitigation priorities
- Ensure cloud audit logging is enabled and retained for authentication, account activity, instance lifecycle, access key usage, and snapshot events.
- Restrict instance deletion permissions to approved roles and workflows, with review of rarely used or newly created accounts that can delete infrastructure.
- Require strong governance for access keys and administrative identities, including visibility into where and how they are used.
- Document legitimate instance deletion processes so SOC and IR teams can distinguish routine cleanup from suspicious activity.
- Validate incident response procedures for deleted cloud resources, including preservation of relevant logs and snapshot history where available.
Analyst notes and limits
This is a detection analytic for IaaS cloud environments, not a technique entry. The strongest defensive value is in validating whether the organization can correlate cloud control-plane events around deletion activity. The supplied description specifically frames suspicious deletion as potentially related to destruction of forensic evidence or evasion of detection, so response playbooks should treat such alerts as evidence-preservation priorities.
The object provides no official detection logic, no tactic mapping, and no relationship context. It does not identify a specific cloud provider, adversary, campaign, or active exploitation pattern. Local baselines, cloud architecture, automation practices, and log retention determine whether this analytic is practical and how noisy it will be.
Analytic 0234
Defenders can detect suspicious cloud instance deletions by correlating events across authentication, instance lifecycle, and account activity. From a defender’s perspective, behaviors of interest include instances deleted shortly after creation, deletions initiated by new or rarely used accounts, deletions following snapshot creation, and deletions originating from anomalous geolocations or access keys. These may indicate adversarial attempts to destroy forensic evidence or evade detection.
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 | 1.0 | Current bundle | 56e4f8cd2f03… |
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 AN0234Open 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.