DC0047: Snapshot Enumeration
The process of listing or retrieving metadata about existing snapshots in a cloud environment.
*Data Collection Measures:*
- AWS CloudTrail - Logs API calls such as `DescribeSnapshots`, `ListSnapshots`, and `GetSnapshotAttributes`. - Azure Monitor Logs - Tracks snapshot enumeration via `Microsoft.Compute/snapshots/read`. - Google Cloud Logging - Detects snapshot listing through `compute.disks.listSnapshots`.
Analyst context for executives and security teams
Snapshot enumeration is a cloud visibility signal: someone or something is listing existing disk or volume snapshots and their metadata. For security leaders, this matters because snapshots often represent recoverability, sensitive data exposure paths, and cloud asset governance. Even without a supplied ATT&CK tactic or detection analytic, the data component is useful for confirming whether cloud logging can show who queried snapshot inventories across AWS, Azure, and Google Cloud.
Executive priority
Prioritize this as a control-evidence and readiness question rather than a standalone incident indicator. Leaders should ask whether cloud audit logs can prove which identities enumerate snapshots, whether that activity is expected for backup, recovery, administration, or compliance workflows, and whether unusual enumeration would be visible during an investigation. The business value is strongest for cloud security, incident response readiness, access governance, and audit evidence around sensitive backup or recovery assets.
Technical view
SOC and IR teams should validate collection and retention for snapshot enumeration events in the cloud audit sources named by ATT&CK: AWS CloudTrail events such as DescribeSnapshots, ListSnapshots, and GetSnapshotAttributes; Azure Monitor Logs operations such as Microsoft.Compute/snapshots/read; and Google Cloud Logging activity such as compute.disks.listSnapshots. Because ATT&CK provides no official detection logic and no relationship context, teams should build local baselines around approved backup, storage, administrator, and automation identities, then review deviations by identity, account/subscription/project, region, volume, and frequency.
Likely telemetry
- AWS CloudTrail API activity for DescribeSnapshots, ListSnapshots, and GetSnapshotAttributes
- Azure Monitor Logs records for Microsoft.Compute/snapshots/read
- Google Cloud Logging records for compute.disks.listSnapshots
- Cloud identity context associated with the request, such as user, role, service principal, or automation identity where available
- Cloud resource context such as account, subscription, project, region, snapshot identifier, and request time
Detection direction
- Confirm the named cloud audit sources are enabled, centralized, searchable, and retained long enough to support incident response and audit needs.
- Baseline normal snapshot enumeration by backup tools, disaster recovery processes, cloud administrators, and inventory scanners to reduce false positives.
- Tune for unusual identities, new source contexts, unexpected accounts/subscriptions/projects, abnormal frequency, or enumeration outside approved administrative windows.
- Correlate enumeration with nearby cloud identity, storage, snapshot attribute, and access-policy activity where available; do not treat enumeration alone as proof of compromise.
- Document visibility gaps where snapshot audit events are not collected, are filtered out, or lack sufficient identity/resource detail.
Mitigation priorities
- Ensure cloud audit logging is enabled for the services and accounts where snapshots exist.
- Limit snapshot visibility and management permissions to approved roles and service identities using least privilege.
- Review administrative, backup, and recovery workflows so legitimate enumeration is understood and attributable.
- Maintain retention and centralization of cloud logs for incident response and compliance evidence.
- Periodically test whether analysts can find snapshot enumeration events across AWS, Azure, and Google Cloud logging sources named in the ATT&CK data component.
Analyst notes and limits
This object is a data component, not a technique. Its decision value is in validating telemetry coverage for cloud snapshot inventory activity. With no ATT&CK tactics, platforms, relationships, or official detection analytic supplied, local cloud architecture, identity model, and backup tooling determine what is normal and what should be escalated.
The supplied ATT&CK fields do not provide associated techniques, threat actors, procedures, impact claims, or detection logic. The object lists cloud logging examples but does not specify ATT&CK platforms. Any assessment of risk, maliciousness, or coverage must be confirmed against the organization’s own cloud logs, permissions, and operational baselines.
Snapshot Enumeration
The process of listing or retrieving metadata about existing snapshots in a cloud environment.
*Data Collection Measures:*
- AWS CloudTrail - Logs API calls such as `DescribeSnapshots`, `ListSnapshots`, and `GetSnapshotAttributes`. - Azure Monitor Logs - Tracks snapshot enumeration via `Microsoft.Compute/snapshots/read`. - Google Cloud Logging - Detects snapshot listing through `compute.disks.listSnapshots`.
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 | 82fafe8263f4… |
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 DC0047Open 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.