AN0414: Analytic 0414
Adversary deletes critical infrastructure: EC2 instances, S3 buckets, snapshots, or volumes using elevated IAM credentials. Frequently includes batch API calls with `Delete*` or `TerminateInstances`.
Analyst context for executives and security teams
This analytic points to a high-consequence cloud behavior: someone with elevated IAM credentials deleting or terminating core IaaS resources such as EC2 instances, S3 buckets, snapshots, or volumes. For leaders, the key issue is not just detection logic; it is whether the organization can quickly distinguish authorized decommissioning from destructive activity and prove it has enough cloud audit evidence to support incident response and recovery decisions.
Executive priority
Treat this as a business-continuity and cloud-governance priority. Destructive API activity against compute, storage, backups, or snapshots can directly affect service availability, recovery options, and audit confidence. Security leaders should ask whether privileged cloud actions are logged, reviewed, and recoverable; whether emergency response teams can identify which identity performed the action; and whether change-management evidence can separate legitimate infrastructure cleanup from suspicious bulk deletion.
Technical view
The supplied ATT&CK object is an IaaS detection analytic focused on elevated IAM credentials making destructive cloud API calls, especially batch calls using Delete* actions or TerminateInstances. SOC, detection engineering, and IR teams should validate visibility into cloud control-plane activity for EC2, S3, snapshots, and volumes; correlate destructive API calls with the IAM principal, source context, timing, and change records; and prioritize alerts where multiple critical resources are deleted or terminated in a short window.
Likely telemetry
- Cloud control-plane audit logs for IaaS API activity
- IAM principal and credential-use records tied to destructive actions
- EC2 instance termination events
- S3 bucket deletion events
- Snapshot and volume deletion events
Detection direction
- Validate that cloud audit logging captures destructive IaaS API calls across EC2, S3, snapshots, and volumes.
- Look for bursts or batches of Delete* and TerminateInstances activity, especially by elevated IAM principals.
- Correlate deletion activity with approved maintenance windows, change tickets, automation jobs, and infrastructure-as-code pipelines to reduce false positives.
- Tune for context: resource criticality, number of affected resources, identity privilege level, and whether the same principal normally performs these actions.
- Check blind spots around accounts, regions, or logging configurations where control-plane events may be incomplete or unavailable.
Mitigation priorities
- Enforce least privilege for IAM roles and users that can delete or terminate critical IaaS resources.
- Require strong change-control and approval paths for destructive actions against production infrastructure, storage, snapshots, and volumes.
- Protect recovery dependencies by limiting who can delete snapshots, volumes, and storage resources used for restoration.
- Ensure cloud audit logs are enabled, retained, and accessible to SOC and incident response teams.
- Test incident response procedures for rapid triage of destructive cloud API activity and identification of the responsible IAM principal.
Analyst notes and limits
This Glexia take is based only on the supplied ATT&CK analytic fields. The object provides a concise behavior description but no official detection logic, no mapped tactics, and no relationship context. Local cloud architecture, IAM design, logging coverage, and change-management practices are required to determine detection quality and operational priority.
No active exploitation, attribution, specific threat actor behavior, vendor control, or guaranteed detection coverage is provided by the supplied ATT&CK data. The scope is limited to the IaaS platform context and the described destructive API activity.
Analytic 0414
Adversary deletes critical infrastructure: EC2 instances, S3 buckets, snapshots, or volumes using elevated IAM credentials. Frequently includes batch API calls with `Delete*` or `TerminateInstances`.
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 | d246d1a1d8a4… |
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 AN0414Open 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.