AN0937: Analytic 0937
Cloud API calls disabling snapshot scheduling, backup policies, versioning, followed by DeleteSnapshot/DeleteVolume operations
Analyst context for executives and security teams
This analytic is about spotting cloud control-plane activity that weakens recoverability before deleting storage assets: disabling snapshot schedules, backup policies, or versioning, followed by DeleteSnapshot or DeleteVolume operations. For leaders, the business issue is not just data deletion; it is loss of recovery options in IaaS environments, which can affect continuity, incident recovery timelines, and evidence preservation.
Executive priority
Prioritize this as a cloud resilience and incident-readiness validation item. Executives should ask whether IaaS backup, snapshot, and versioning changes are logged, reviewed, and protected from single-account failure, and whether the organization can prove recovery controls were not disabled before destructive storage operations. This is useful for budget and audit discussions around cloud logging, privileged access governance, backup administration, and recovery testing.
Technical view
SOC, cloud security, and IR teams should validate whether cloud API telemetry can correlate recovery-control changes with subsequent DeleteSnapshot or DeleteVolume events. The supplied ATT&CK object identifies IaaS platforms and a detection concept, but provides no official detection logic, tactics, or relationships. Detection engineering should therefore focus on local cloud audit logs, identity context, resource identifiers, timing windows, and administrative change baselines to distinguish approved lifecycle management from suspicious recovery degradation followed by deletion.
Likely telemetry
- IaaS cloud control-plane/API audit logs
- Events for disabling snapshot scheduling
- Events for modifying or disabling backup policies
- Events for disabling object or storage versioning where applicable
- DeleteSnapshot events
Detection direction
- Validate that cloud audit logging captures both recovery-control changes and storage deletion events, not only the final DeleteSnapshot or DeleteVolume action.
- Correlate disabling snapshot scheduling, backup policies, or versioning with subsequent snapshot or volume deletion against the same account, principal, resource, or resource group.
- Tune for legitimate backup lifecycle operations, decommissioning, retention-policy changes, and approved maintenance windows.
- Review privileged cloud identities separately, because authorized administrators may generate the same API patterns during normal operations or during harmful activity.
- Check for blind spots where logs are not centralized, are retained for too short a period, or do not include enough identity/session/resource context to connect the sequence.
Mitigation priorities
- Protect backup, snapshot, and versioning administration with least privilege and separation of duties.
- Require strong approval and monitoring for disabling recovery controls and deleting snapshots or volumes.
- Ensure cloud audit logs for IaaS control-plane activity are centralized, retained, and available to SOC and incident responders.
- Test recovery procedures to confirm that deletion or policy changes do not silently remove all viable recovery points.
- Use compliance evidence to show who can modify backup/versioning controls, who performed changes, and whether changes align with approved business processes.
Analyst notes and limits
The value of AN0937 is in the sequence: recovery safeguards are disabled, then storage recovery artifacts or volumes are deleted. That sequence is important for managed detection, cloud security, IAM review, incident response scoping, and resilience assurance. Because no ATT&CK relationships or detection implementation are supplied, local cloud provider event names, account structure, and backup architecture must drive the final analytic.
The official object provides a short description only. It lists IaaS as the platform but does not specify tactics, related techniques, data sources, detection logic, false-positive guidance, mitigations, groups, malware, or campaigns. This take does not claim active exploitation, attribution, impact, or existing detection coverage.
Analytic 0937
Cloud API calls disabling snapshot scheduling, backup policies, versioning, followed by DeleteSnapshot/DeleteVolume operations
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 | b0d44adbeae9… |
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 AN0937Open 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.