DC0023: Cloud Storage Modification
Cloud Storage Modification involves tracking changes made to cloud storage infrastructure, including updates to settings, permissions, or stored data. Examples include modifying object access control lists (ACLs), uploading new objects, or updating bucket policies. Examples:
AWS S3: An object is uploaded or its ACL is modified. - Azure Blob Storage: A blob's metadata or permissions are updated. - Google Cloud Storage: An object's lifecycle policy is updated, or a bucket policy is changed. - OpenStack Swift: Modifications to container settings or uploading of new objects.
Analyst context for executives and security teams
Cloud Storage Modification is the evidence trail for changes to cloud storage settings, permissions, policies, metadata, and stored objects. For leaders, this matters because cloud storage often holds business-critical data, audit records, customer information, backups, and application content. If teams cannot prove who changed storage access or uploaded/modified objects, incident responders and auditors may struggle to determine whether data exposure, tampering, or operational disruption occurred.
Executive priority
Prioritize this data component as a cloud security and incident readiness control point. The key business question is whether the organization can reconstruct material changes to cloud storage quickly enough to support breach assessment, compliance evidence, and operational recovery. Budget and control decisions should focus on logging coverage, retention, access governance, and alerting for high-risk storage changes such as permission updates, bucket or container policy changes, object ACL changes, and unexpected object uploads.
Technical view
SOC, cloud security, and IR teams should validate that cloud storage change events are collected and retained for the cloud storage services in use. The supplied ATT&CK description names examples such as AWS S3 object uploads or ACL modification, Azure Blob metadata or permission updates, Google Cloud Storage lifecycle or bucket policy changes, and OpenStack Swift container setting changes or object uploads. Because ATT&CK provides no official detection logic, teams should build local detections around administrative and data-plane modification events, especially changes to access control, bucket/container policy, lifecycle behavior, metadata, and new or replaced objects.
Likely telemetry
- Cloud storage control-plane audit logs for bucket, container, policy, ACL, metadata, and lifecycle configuration changes
- Cloud storage data-plane logs for object upload, overwrite, or modification events where available
- Identity and access logs showing the user, role, service account, or application principal that performed the change
- Cloud provider activity logs that include source IP, user agent, API action, resource name, timestamp, and request outcome
- Configuration history or cloud security posture records showing before-and-after storage settings
Detection direction
- Validate that logging is enabled for both administrative storage changes and object-level changes where supported; many blind spots occur when only account-level activity is collected.
- Tune alerts around high-risk modifications: public or broader access changes, policy updates, ACL changes, lifecycle rule changes, metadata or permission updates, and unusual object uploads to sensitive storage locations.
- Correlate modification events with identity context, change-management records, and expected automation to reduce false positives from backup jobs, deployment pipelines, data transfers, and approved administrators.
- Establish baselines for normal storage modification patterns by workload, service account, and business process; investigate changes outside expected time windows, identities, or resource scopes.
- Because no ATT&CK detection text or relationships were supplied, detection engineering should be validated against local cloud architecture and audit requirements rather than assumed ATT&CK coverage.
Mitigation priorities
- Ensure cloud storage modification logging is enabled and retained for investigation and audit needs.
- Apply least-privilege access to storage administration and object modification rights, including service accounts and automation identities.
- Use change control for storage policy, ACL, lifecycle, metadata, and permission changes on sensitive repositories.
- Review storage permissions and policies regularly to identify unintended exposure or excessive modification rights.
- Protect and monitor logs so storage modification evidence remains available during incident response and compliance review.
Analyst notes and limits
This object is a data component, not a technique, and no tactics, platforms, detection text, or relationship context were supplied. Its value is as an evidence source for cloud storage change visibility. The official description supports examples across common cloud storage services, but local implementation details determine which logs exist, what fields are available, and how reliably object-level activity can be captured.
ATT&CK did not provide official detection guidance for this object, and no relationships to techniques, groups, software, or mitigations were supplied. This take therefore does not infer adversary behavior, active exploitation, impact, or guaranteed detection coverage. Organizations must validate telemetry availability, retention, and alert quality in their own cloud environments.
Cloud Storage Modification
Cloud Storage Modification involves tracking changes made to cloud storage infrastructure, including updates to settings, permissions, or stored data. Examples include modifying object access control lists (ACLs), uploading new objects, or updating bucket policies. Examples:
AWS S3: An object is uploaded or its ACL is modified. - Azure Blob Storage: A blob's metadata or permissions are updated. - Google Cloud Storage: An object's lifecycle policy is updated, or a bucket policy is changed. - OpenStack Swift: Modifications to container settings or uploading of new objects.
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 | 6cf74f9e3876… |
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 DC0023Open 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.