DET0423: Detection Strategy for Modify Cloud Compute Infrastructure: Create Snapshot
DET0423 is a MITRE detection strategy entry for detecting the cloud behavior Create Snapshot (T1578.001). The ATT&CK object itself has no official descript...
Analyst context for executives and security teams
DET0423 is a MITRE detection strategy entry for detecting the cloud behavior Create Snapshot (T1578.001). The ATT&CK object itself has no official description or detection text, but its relationship is important: in IaaS environments, unauthorized or unexpected creation of VM, virtual disk, volume, or backup snapshots can let an adversary work around direct access restrictions and weaken defenses. For leaders, the practical question is whether cloud teams can prove who created snapshots, from where, under what authorization, and whether the action matched approved operational activity.
Executive priority
Prioritize this as a cloud control-plane visibility and governance issue. Snapshot creation can affect incident containment, data exposure analysis, and audit evidence because it may create new copies of compute assets outside normal operating paths. Executives and risk owners should ask whether snapshot permissions are tightly governed, whether snapshot activity is logged and reviewed, and whether incident responders can quickly distinguish approved backup/administration from suspicious defense-impairment activity.
Technical view
Because the detection strategy object does not provide official detection logic, SOC and cloud security teams should build validation around the related technique T1578.001, Create Snapshot, in IaaS environments under the defense-impairment tactic. Validate that cloud control-plane events for snapshot or backup creation are collected, normalized, retained, and correlated with identity, source context, affected compute resources, and change-management records. Detection engineering should focus on snapshot creation by unusual identities, outside expected administrative workflows, against sensitive compute resources, or following other suspicious cloud account activity, while tuning for legitimate backup, disaster recovery, migration, and maintenance operations.
Likely telemetry
- Cloud control-plane audit logs showing snapshot, backup, volume, disk, VM, or image creation events
- Identity and access management logs showing the principal, role, permission path, and authentication context used for snapshot creation
- Cloud compute and storage metadata identifying the source VM, volume, virtual hard drive, or other component copied
- Network/source context associated with the API, CLI, SDK, or console action when available
- Administrative change records, backup schedules, and maintenance tickets used to separate approved activity from anomalies
Detection direction
- Confirm that snapshot creation events are logged for all relevant IaaS accounts, regions, projects, and subscriptions; missing regions or accounts are a major blind spot.
- Correlate snapshot creation with the initiating identity and permissions, especially newly granted roles, unusual service accounts, or activity inconsistent with normal administrative duties.
- Baseline legitimate snapshot activity such as scheduled backups, disaster recovery, migrations, and maintenance to reduce false positives.
- Alert on snapshot creation involving sensitive compute assets, unusual timing, unexpected source locations, or identities not normally associated with backup or infrastructure administration.
- During investigations, treat snapshot creation as potentially relevant to defense impairment and access-bypass analysis, but do not assume malicious intent without local context.
Mitigation priorities
- Apply least-privilege access to snapshot and backup creation permissions for cloud compute and storage resources.
- Require accountable administrative workflows for snapshot creation, including approval or change records for high-value systems where appropriate.
- Ensure cloud audit logging is enabled, centralized, protected from tampering, and retained long enough to support incident response and compliance review.
- Regularly review identities and roles that can create snapshots, especially privileged users, automation accounts, and cross-account access paths.
- Include snapshot discovery and ownership review in cloud incident response playbooks.
Analyst notes and limits
The official ATT&CK detection strategy entry is sparse: no official description, detection text, tactics, or platforms are provided on the DET0423 object itself. The useful context comes from its relationship to T1578.001, Create Snapshot, which is described for IaaS and mapped to defense impairment. Local cloud architecture, identity model, backup processes, and logging configuration are required to turn this into reliable detections.
This take does not claim active exploitation, attribution, or existing detection coverage. It is limited to the supplied STIX fields, the MITRE external reference, and the relationship to T1578.001. Vendor-specific event names, exact APIs, and platform-specific controls are not asserted because they were not supplied.
Detection Strategy for Modify Cloud Compute Infrastructure: Create Snapshot
No official description is available in the imported ATT&CK source object.
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.
Techniques used
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Enterprise | T1578.001 | Create Snapshot Sub-technique | This object detects Create Snapshot. |
All related ATT&CK context
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 | 1.0 | Current bundle | a8facca3a0a0… |
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 DET0423Open 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.