AN1187: Analytic 1187
Detection focuses on correlating snapshot creation events with subsequent instance creation and mounting activities. From a defender perspective, suspicious sequences include snapshot creation by unexpected or newly created IAM users, snapshots created from sensitive volumes without preceding change-control activity, or snapshots immediately followed by mounting to unauthorized instances. Cross-referencing with user behavior, IP geolocation, and automation context helps distinguish benign backup operations from adversary-driven snapshot exploitation.
Analyst context for executives and security teams
This analytic matters because cloud snapshots can expose sensitive workloads and data if they are created or mounted outside approved operational processes. For leaders, the practical question is whether the organization can distinguish routine backup/restore activity from unusual snapshot use by unexpected IAM users, new accounts, unfamiliar locations, or unauthorized instances in IaaS environments.
Executive priority
Treat this as a cloud control-validation and incident-readiness priority. Snapshot activity often sits at the intersection of data protection, privileged access, change management, and audit evidence. Executives should ask whether sensitive volumes are identified, whether snapshot creation and attachment are logged, whether change-control context is available to the SOC, and whether responders can quickly determine if a snapshot was legitimate backup automation or unauthorized access.
Technical view
For SOC, detection engineering, and IR teams, validate correlation across snapshot creation, subsequent instance creation, and mounting or attachment activity in IaaS telemetry. Prioritize sequences involving newly created or unexpected IAM users, snapshots from sensitive volumes without corresponding change-control evidence, and snapshots rapidly mounted to instances not authorized for that data. Enrich with user behavior, source IP/geolocation, and known automation context to reduce noise from legitimate backup, recovery, or infrastructure-as-code workflows.
Likely telemetry
- IaaS control-plane audit logs for snapshot creation events
- IaaS audit logs for instance creation and volume or snapshot mounting/attachment activity
- IAM user, role, and credential creation or usage records
- Change-management or ticketing records for approved backup, restore, and maintenance activity
- Asset or data classification context identifying sensitive volumes
Detection direction
- Build or validate correlation logic that links snapshot creation to later instance creation and mounting activity within an operationally relevant time window.
- Baseline expected backup, restore, and automation patterns so alerts focus on unexpected IAM principals, new users, unusual locations, or unauthorized target instances.
- Tune carefully for legitimate cloud operations, including disaster recovery tests, backup tooling, migrations, and infrastructure-as-code deployments.
- Use change-control evidence as a key discriminator: sensitive-volume snapshots without an approved change should receive higher scrutiny.
- Because no official detection logic is supplied, local cloud provider logging, naming conventions, IAM model, and asset classification will determine practical detection quality.
Mitigation priorities
- Ensure IaaS audit logging captures snapshot, instance, and mount/attachment events with IAM principal and source context.
- Limit snapshot creation, sharing, and mounting privileges to approved roles and automation identities using least privilege.
- Maintain an inventory or classification of sensitive volumes so detections can prioritize higher-risk snapshot activity.
- Require change-control or approved automation context for snapshot operations involving sensitive systems.
- Review incident response procedures for quickly validating snapshot legitimacy, involved IAM identities, source locations, and target instances.
Analyst notes and limits
This object is a MITRE detection analytic for IaaS snapshot-related activity. It provides useful behavioral pivots but no ATT&CK tactic, technique relationship, or official detection implementation. The most defensible use is as a validation checklist for cloud audit logging, IAM governance, backup process evidence, and SOC correlation coverage.
No relationship context, tactic mapping, vendor-specific log sources, or official detection query was supplied. The assessment cannot assert active exploitation, actor usage, impact, or existing detection coverage. Local environment context is required to define sensitive volumes, authorized instances, expected automation, and acceptable change-control evidence.
Analytic 1187
Detection focuses on correlating snapshot creation events with subsequent instance creation and mounting activities. From a defender perspective, suspicious sequences include snapshot creation by unexpected or newly created IAM users, snapshots created from sensitive volumes without preceding change-control activity, or snapshots immediately followed by mounting to unauthorized instances. Cross-referencing with user behavior, IP geolocation, and automation context helps distinguish benign backup operations from adversary-driven snapshot exploitation.
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 | 1.0 | Current bundle | 73b7d276b323… |
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 AN1187Open 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.