DC0095: Volume Enumeration
An extracted list of available volumes within a cloud environment (ex: AWS describe-volumes)
Analyst context for executives and security teams
Volume Enumeration is evidence that someone or something has listed available storage volumes in a cloud environment. For leaders, this matters because storage inventory often reveals where sensitive systems, backups, snapshots, or high-value workloads may exist. Even without an ATT&CK tactic or detection guidance attached, this data component is useful for validating whether cloud monitoring can show who enumerated volumes, when it happened, and whether it was expected administration or suspicious discovery activity.
Executive priority
Prioritize this as a cloud visibility and governance question: can the organization prove, during an incident or audit, which identities enumerated storage volumes and whether that access was appropriate? The business risk is not the enumeration alone, but the possibility that weak logging, broad permissions, or unmanaged cloud assets prevent teams from distinguishing normal operations from suspicious reconnaissance against critical data stores.
Technical view
SOC, cloud security, and IR teams should validate collection of cloud control-plane activity that records volume-listing actions, with sufficient identity, time, source, account/project, region, and target metadata. Because ATT&CK provides no official detection logic or relationships for this data component, detection engineering should treat it as supporting telemetry: correlate volume enumeration with unusual identity use, unexpected source locations, recently changed permissions, access to sensitive accounts, or follow-on storage actions where local telemetry supports that analysis.
Likely telemetry
- Cloud control-plane/API audit logs showing volume enumeration or describe/list volume activity
- Identity and access metadata for the principal performing the enumeration
- Cloud account, project, subscription, region, and resource identifiers associated with the query
- Source context such as IP address, user agent, session, or automation role where available
- Change-management or administrative activity records to distinguish expected inventory jobs from unusual access
Detection direction
- Confirm that cloud API audit logging is enabled and retained for storage volume enumeration events across relevant cloud environments.
- Baseline expected administrative, inventory, backup, and asset-management enumeration patterns to reduce false positives.
- Alert or hunt for enumeration by unexpected identities, newly provisioned credentials, unusual sessions, or accounts with no operational reason to list volumes.
- Use this data component as context rather than a standalone verdict, since MITRE provides no official detection text or tactic mapping for this object.
- Validate blind spots such as regions/accounts/projects not onboarded to centralized logging or logs that omit identity/source context needed for investigation.
Mitigation priorities
- Ensure least-privilege access to cloud storage inventory APIs so only approved roles can enumerate volumes.
- Centralize and retain cloud audit logs that capture volume listing activity for incident response and compliance evidence.
- Review cloud asset inventory processes so sanctioned enumeration is documented and distinguishable from anomalous activity.
- Periodically test whether SOC and IR teams can answer who listed volumes, from where, and whether the action was authorized.
- Close coverage gaps in unmanaged accounts, regions, or projects before relying on enumeration telemetry for investigations.
Analyst notes and limits
This take is based only on the ATT&CK data component definition: an extracted list of available volumes within a cloud environment, with AWS describe-volumes provided as an example. No tactics, platforms, official detection guidance, or relationship context were supplied, so recommendations focus on defensive validation of cloud telemetry and access governance rather than specific adversary behavior.
The object does not specify platforms, tactics, techniques, mitigations, detections, or relationships. Local cloud architecture, logging configuration, IAM model, and asset-management practices are required to determine risk, expected behavior, and actionable detection logic.
Volume Enumeration
An extracted list of available volumes within a cloud environment (ex: AWS describe-volumes)
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 | 2.0 | Current bundle | c24d3e2995ea… |
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 DC0095Open 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.