Live Active security incident? Get immediate response
MITRE ATT&CK® Data Component

DC0026: Image Deletion

Removal of a virtual machine image in a cloud infrastructure (ex: Azure Compute Service Images DELETE) Examples:

- Azure Compute Service Image Deletion - Example: Deleting a virtual machine image using Azure CLI: `az image delete --name MyImage --resource-group MyResourceGroup` - AWS EC2 AMI (Amazon Machine Image) Deletion - Example: Deregistering an AMI in AWS: `aws ec2 deregister-image --image-id ami-1234567890abcdef0` - Google Cloud Compute Engine Image Deletion - Example: Deleting a custom image in Google Cloud: `gcloud compute images delete my-custom-image` - VMware vSphere - Example: Deleting a VM image/template from a vSphere environment:

This data component can be collected through the following measures:

Enable Cloud Platform Logging

- Azure: Enable "Activity Logs" to capture DELETE requests to `Microsoft.Compute/images`. - AWS: Use AWS CloudTrail to monitor `DeregisterImage` or `DeleteSnapshot` API calls. - Google Cloud: Enable "Cloud Audit Logs" to track image deletion events under `compute.googleapis.com/images`.

API Monitoring

- Monitor API activity to track the deletion of images using: - AWS SDK/CLI `DeregisterImage` or `DeleteSnapshot`. - Azure REST API DELETE operations for images. - Google Cloud Compute Engine APIs for image deletion.

Cloud SIEM Integration

- Ingest logs into a centralized SIEM platform for monitoring and alerting:

Event Correlation

- Correlate image deletion events with unusual account activity or concurrent unauthorized operations.

EnterpriseDC0026Data ComponentObject v2.0 Modified
Glexia's Take

Analyst context for executives and security teams

Analyst confidence Medium

Image Deletion is a cloud evidence and resilience concern: it records when virtual machine images or templates are removed from environments such as Azure, AWS, Google Cloud, or vSphere. For leaders, the practical issue is whether the organization can see and explain deletion of build artifacts that may be needed for recovery, rebuilds, investigations, compliance evidence, or change control.

Executive priority

Treat VM image deletion visibility as part of cloud operational resilience and audit readiness. Security and infrastructure leaders should ask whether image deletion is logged centrally, tied to an accountable identity, correlated with change approvals, and reviewed alongside unusual account activity. Missing coverage can weaken incident response and recovery confidence because teams may not be able to prove who removed an image, when it happened, or whether related snapshots/templates were affected.

Technical view

This ATT&CK data component focuses on telemetry for removal of virtual machine images in cloud infrastructure. The supplied description identifies Azure Activity Logs for DELETE requests to Microsoft.Compute/images, AWS CloudTrail events such as DeregisterImage or DeleteSnapshot, Google Cloud Audit Logs for compute.googleapis.com image deletion events, API monitoring, centralized SIEM ingestion, and correlation with unusual account activity or concurrent unauthorized operations. No ATT&CK tactics, platforms, relationships, or official detection logic are supplied, so defenders should validate collection and correlation rather than assume analytic coverage.

Likely telemetry

  • Cloud control-plane audit logs for image deletion operations
  • Azure Activity Logs showing DELETE requests to Microsoft.Compute/images
  • AWS CloudTrail events such as DeregisterImage and DeleteSnapshot
  • Google Cloud Audit Logs for compute.googleapis.com image deletion events
  • Cloud API activity from CLI, SDK, REST, or console-driven actions

Detection direction

  • Confirm that cloud platform logging is enabled for image deletion events in each relevant environment.
  • Validate that image deletion events are ingested into a centralized SIEM with identity, resource, and cloud account/project/subscription context preserved.
  • Correlate deletion events with unusual account activity, unexpected administrative actions, or concurrent unauthorized operations, as suggested by the ATT&CK description.
  • Tune alerts against approved image lifecycle processes to reduce false positives from routine cleanup, deprecation, or migration work.
  • Review blind spots where images, snapshots, or templates may be deleted outside the primary cloud logging path, including API-driven activity and vSphere-managed templates where applicable.

Mitigation priorities

  • Enable and retain cloud platform audit logging for image and snapshot deletion operations before relying on SIEM analytics.
  • Restrict image deletion privileges to appropriate administrative roles and ensure actions are attributable to named identities or controlled service accounts.
  • Use change-control expectations to distinguish approved cleanup from unexpected deletion of recovery or build images.
  • Centralize logs and correlate them with identity activity, other resource changes, and incident timelines.
  • Validate backup, snapshot, template, and rebuild processes so deletion of a VM image does not create an avoidable recovery gap.
Analyst notes and limits

This is a data component, not a technique. Its value is evidentiary: it helps determine whether defenders can observe and investigate removal of VM images across cloud infrastructure. The strongest use cases are cloud security monitoring, incident response timeline reconstruction, change assurance, and recovery readiness.

The supplied ATT&CK object has no tactics, platforms, relationships, or official detection text beyond collection guidance in the description. Environment-specific cloud services, log schemas, retention periods, IAM models, and approved image lifecycle processes must be assessed locally before making coverage or risk conclusions.

Official MITRE ATT&CK definition

Image Deletion

Removal of a virtual machine image in a cloud infrastructure (ex: Azure Compute Service Images DELETE) Examples:

- Azure Compute Service Image Deletion - Example: Deleting a virtual machine image using Azure CLI: `az image delete --name MyImage --resource-group MyResourceGroup` - AWS EC2 AMI (Amazon Machine Image) Deletion - Example: Deregistering an AMI in AWS: `aws ec2 deregister-image --image-id ami-1234567890abcdef0` - Google Cloud Compute Engine Image Deletion - Example: Deleting a custom image in Google Cloud: `gcloud compute images delete my-custom-image` - VMware vSphere - Example: Deleting a VM image/template from a vSphere environment:

This data component can be collected through the following measures:

Enable Cloud Platform Logging

- Azure: Enable "Activity Logs" to capture DELETE requests to `Microsoft.Compute/images`. - AWS: Use AWS CloudTrail to monitor `DeregisterImage` or `DeleteSnapshot` API calls. - Google Cloud: Enable "Cloud Audit Logs" to track image deletion events under `compute.googleapis.com/images`.

API Monitoring

- Monitor API activity to track the deletion of images using: - AWS SDK/CLI `DeregisterImage` or `DeleteSnapshot`. - Azure REST API DELETE operations for images. - Google Cloud Compute Engine APIs for image deletion.

Cloud SIEM Integration

- Ingest logs into a centralized SIEM platform for monitoring and alerting:

Event Correlation

- Correlate image deletion events with unusual account activity or concurrent unauthorized operations.

View the same entry on attack.mitre.org (MITRE-hosted reference; in-page links above use the Glexia ATT&CK library.)

Glexia analysis

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.

Relationship explorer

All related ATT&CK context

No relationships are available in the current normalized data for this object.

Change history

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 .

ATT&CK release
19.1
Object version
2.0
Created
Modified
Raw hash
56db867ce6d34041...
Imported snapshots across ATT&CK releases (1)
Release Bundle imported Object version Modified Status Raw hash
19.1 2.0 Current bundle 56db867ce6d3…
Raw source

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.

Source references

External references and citations

MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.

  1. [1]
    mitre-attack DC0026
    Open source URL
Source and licensing

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.