DC0057: Snapshot Creation
The process of taking a point-in-time copy of a cloud storage volume (files, settings, configurations, etc.), virtual machine (VM), or database that can be created and deployed in cloud environments.
Analyst context for executives and security teams
Snapshot creation is the cloud activity of making a point-in-time copy of a storage volume, virtual machine, or database. For leaders, this matters because snapshots can contain sensitive files, configurations, system state, and recoverability-critical data. Even though this ATT&CK data component does not specify a tactic or platform, the behavior is important for cloud security governance, incident response scoping, and audit evidence: organizations should know who can create snapshots, where those snapshots are stored, and whether snapshot activity is logged well enough to distinguish approved operations from unexpected data-copying or recovery-related activity.
Executive priority
Treat snapshot visibility as a cloud control and evidence question: can the organization prove when critical cloud assets were copied, by whom, and under what authorization? This supports business continuity, data protection, access governance, and incident decision-making. Priority should go to cloud environments hosting sensitive databases, virtual machines, or storage volumes, especially where snapshot creation could affect data exposure, recovery posture, or compliance evidence.
Technical view
Because ATT&CK provides no detection guidance, platforms, tactics, or relationships for this data component, SOC and cloud security teams should validate basic observability rather than assume coverage. Confirm that cloud control-plane or management-plane logs capture snapshot creation events for storage volumes, VMs, and databases; that events include actor identity, target resource, timestamp, source context where available, and resulting snapshot identifier; and that logs are retained and searchable for incident response. Detection engineering should focus on baselining expected administrative, backup, and automation-driven snapshot creation, then identifying activity outside approved patterns.
Likely telemetry
- Cloud control-plane or management-plane audit logs recording snapshot creation
- Identity and access events for the principal creating the snapshot
- Resource metadata for the source volume, VM, or database
- Snapshot metadata such as snapshot identifier, creation time, region or account/project context where available
- Change-management, backup, or automation records used to validate expected snapshot activity
Detection direction
- Validate that snapshot creation events are actually collected for all relevant cloud resources; do not rely on workload logs alone.
- Correlate snapshot creation with the actor identity, permissions used, source resource sensitivity, and approved backup or maintenance windows.
- Tune detections to reduce false positives from scheduled backups, disaster recovery workflows, and infrastructure automation.
- Look for gaps where snapshots can be created in accounts, projects, regions, or services not covered by centralized logging.
- Preserve enough log retention to support incident response questions about historical copying of cloud volumes, VMs, or databases.
Mitigation priorities
- Inventory which cloud resources support snapshot creation and which teams or roles are authorized to use it.
- Restrict snapshot creation permissions to approved administrative, backup, and recovery workflows using least privilege.
- Require change-management or automation traceability for routine snapshot creation on sensitive resources.
- Review snapshot governance as part of cloud security, identity access management, backup, and compliance readiness programs.
- Test whether incident responders can rapidly identify recent snapshot activity for critical storage volumes, VMs, and databases.
Analyst notes and limits
This is a data component, not an adversary technique. Its value is in defining an evidence class defenders should collect and operationalize. In practice, snapshot creation is often legitimate, so context from identity, asset sensitivity, backup schedules, and change records is necessary before treating an event as suspicious.
The supplied ATT&CK object provides only a description and no official detection text, platforms, tactics, or relationship context. Any environment-specific detection logic, platform coverage, risk ranking, or assumptions about malicious use require local cloud architecture, logging configuration, and identity data.
Snapshot Creation
The process of taking a point-in-time copy of a cloud storage volume (files, settings, configurations, etc.), virtual machine (VM), or database that can be created and deployed in cloud environments.
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 | ad794d89a285… |
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 DC0057Open 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.