DC0098: Volume Deletion

The removal of a cloud-based or on-premise block storage volume. This action permanently deletes the allocated storage and may result in data loss if not backed up.

*Data Collection Measures:*

- Cloud Logging & APIs - AWS CloudTrail Logs - `eventName: DeleteVolume` (tracks volume deletions) - Azure Monitor Logs - `operationName: Microsoft.Compute/disks/delete` - `status: Success | Failure` (flag unauthorized delete attempts) - Google Cloud Audit Logs - `protoPayload.methodName: "v1.compute.disks.delete"` - `authenticationInfo.principalEmail` (identifies the user deleting the volume) - System & Host-Based Logging - Linux & macOS Logs: - `/var/log/syslog` or `/var/log/messages` for volume detach/deletion actions - Windows Event Logs: - Event ID 98 (Storage Class Memory) - Event ID 225 (Volume Removal Detected) - Event ID 12 (Disk Removal Notification)

EnterpriseDC0098Data ComponentObject v2.0 Modified Nov 12, 2025, 22:03 UTC (UTC+00:00)

Volume Deletion is a data source for seeing when cloud or on-premise block storage is removed. Its business significance is straightforward: deleting a volume can permanently remove allocated storage and may cause data loss if backups are missing or incomplete. For leaders, this is less about a single log event and more about proving the organization can identify who deleted storage, whether the action was authorized, and whether recovery evidence exists.

Executive priority

Prioritize this as a resilience and accountability control point. Security, cloud, infrastructure, and audit teams should be able to answer: which storage deletions are permitted, who approved them, whether failed or unauthorized attempts are visible, and whether deleted data can be recovered from backup. This evidence supports incident decision-making, compliance readiness, and business continuity planning, especially where cloud storage or critical on-premise volumes support production operations.

Technical view

ATT&CK provides this as a data component, not a technique, and no official detection logic or relationship context is supplied. SOC and IR teams should validate collection from cloud control-plane logs and host/system storage logs. Relevant examples in the object include AWS CloudTrail `eventName: DeleteVolume`, Azure Monitor `operationName: Microsoft.Compute/disks/delete` with `status: Success | Failure`, Google Cloud Audit Logs `protoPayload.methodName: "v1.compute.disks.delete"` and `authenticationInfo.principalEmail`, Linux/macOS `/var/log/syslog` or `/var/log/messages`, and Windows Event IDs 98, 225, and 12. Detection engineering should focus on authorization context, actor identity, affected asset, success/failure status, timing, and correlation with backup or change-management records.

Likely telemetry

AWS CloudTrail logs for `DeleteVolume` events
Azure Monitor logs for `Microsoft.Compute/disks/delete` operations and success or failure status
Google Cloud Audit Logs for `v1.compute.disks.delete` and deleting principal identity
Linux and macOS system logs such as `/var/log/syslog` or `/var/log/messages` for volume detach or deletion activity
Windows Event Logs including Event ID 98, Event ID 225, and Event ID 12

Detection direction

Confirm that cloud control-plane logging is enabled, retained, and searchable for volume or disk deletion operations across relevant accounts, subscriptions, and projects.
Alert or review successful deletions of important volumes, deletions by unexpected identities, and failed deletion attempts that may indicate unauthorized activity.
Correlate deletion events with change tickets, maintenance windows, asset criticality, and backup status to reduce false positives from legitimate administration.
Validate identity fields such as principal email or user/account context so responders can determine who initiated the action.
Check for blind spots where host logs exist but cloud API logs are missing, or where logs are retained for less time than incident response or audit requirements need.

Mitigation priorities

Define and document who is authorized to delete storage volumes and under what approval process.
Ensure cloud and host logging for volume deletion is enabled before relying on detections or audit evidence.
Apply least-privilege access to storage administration roles and review permissions that allow destructive storage actions.
Maintain tested backups or recovery procedures for volumes that support important business services.
Use change-management and asset criticality data to prioritize review of deletions affecting production or regulated workloads.

Analyst notes and limits

Because this object is a data component, its main value is coverage validation: can the organization observe and investigate storage deletion activity? The supplied ATT&CK fields do not map this component to a specific tactic, platform list, technique, adversary, or active campaign. Treat it as a required telemetry and governance checkpoint for cloud security, incident response, managed detection, and compliance evidence.

No official detection is provided, and no relationships are supplied. Platforms are not specified in the object, though the description and collection measures reference cloud, Linux/macOS, and Windows log sources. Local environment details are required to decide severity, normal administrative baselines, and whether a deletion is suspicious or approved.

Official MITRE ATT&CK definition

Volume Deletion

The removal of a cloud-based or on-premise block storage volume. This action permanently deletes the allocated storage and may result in data loss if not backed up.

*Data Collection Measures:*

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: Oct 20, 2021, 15:05 UTC (UTC+00:00)
Modified: Nov 12, 2025, 22:03 UTC (UTC+00:00)
Raw hash: 0e16b5c26b582d8b...

Imported snapshots across ATT&CK releases (1)

Release	Bundle imported	Object version	Modified	Status	Raw hash
19.1	May 18, 2026, 07:08 UTC (UTC+00:00)	2.0	Nov 12, 2025, 22:03 UTC (UTC+00:00)	Current bundle	`0e16b5c26b58…`

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.

Open mirrored raw JSON Open MITRE-hosted copy

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]
mitre-attack DC0098
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.

Official MITRE ATT&CK site Official STIX data repository MITRE ATT&CK terms of use