DC0024: Cloud Storage Creation
Cloud Storage Creation refers to the initial creation of a new cloud storage resource, such as buckets, containers, or directories, within a cloud environment. This action is critical to track as it might indicate the legitimate provisioning of resources or unauthorized actions taken by adversaries to stage, store, or exfiltrate data. Examples:
- AWS S3 Bucket Creation: An AWS user creates a new S3 bucket using the `CreateBucket` API call. - Azure Blob Storage Container Creation: A user creates a new container in Azure Blob Storage using the `Create Container` operation. - Google Cloud Storage Bucket Creation: A Google Cloud user creates a new bucket using `storage.buckets.create`. - OpenStack Swift Container Creation: A user creates a new container in OpenStack Swift using the `PUT` method.
Analyst context for executives and security teams
Cloud Storage Creation is the creation of new cloud storage resources such as buckets, containers, or directories. For security leaders, this matters because newly created storage can be routine business provisioning or an early sign of unauthorized staging, data collection, or data movement preparation. The decision value is knowing whether the organization can quickly distinguish approved storage creation from suspicious or policy-breaking activity across cloud environments.
Executive priority
Prioritize this as a cloud governance and incident readiness signal. Leaders should ask whether new storage resources are inventoried, tied to an accountable identity or workload, reviewed against data handling policy, and available as audit evidence. This data component can support budget and control decisions around cloud logging, identity governance, storage guardrails, and SOC workflows, especially where unapproved storage could affect confidentiality, compliance readiness, or operational resilience.
Technical view
SOC, cloud security, and IR teams should validate that cloud control-plane events for storage creation are collected and normalized. The official examples include AWS S3 CreateBucket, Azure Blob Storage Create Container, Google Cloud storage.buckets.create, and OpenStack Swift container creation via PUT. Since ATT&CK provides no tactic, platform list, detection text, or relationship context for this object, teams should use local cloud architecture, approved provisioning paths, and identity context to define what is expected versus suspicious.
Likely telemetry
- Cloud control-plane audit logs for storage resource creation
- API event records for bucket, container, or directory creation
- Identity and access records for the user, role, service account, or workload that performed the action
- Cloud asset inventory or configuration management records showing newly created storage
- Change management, infrastructure-as-code, or provisioning pipeline records for expected creations
Detection direction
- Validate that storage creation events are collected from every relevant cloud environment and retained long enough for investigation and compliance evidence.
- Correlate creation events with approved change records, infrastructure-as-code activity, and expected provisioning identities to reduce false positives.
- Review creations by unusual identities, outside normal provisioning workflows, in unexpected accounts/projects/subscriptions, or without required ownership metadata.
- Tune detections for business context: developer and automation activity may be legitimate, while unmanaged manual creation or missing tags may require review.
- Account for blind spots where cloud audit logging is disabled, not centralized, inconsistently parsed, or missing service-account context.
Mitigation priorities
- Establish approved provisioning paths for cloud storage resources and require ownership, purpose, and classification metadata where feasible.
- Limit who and what can create storage resources through identity and access management controls appropriate to the environment.
- Centralize cloud audit logging and asset inventory so new storage resources can be detected and investigated promptly.
- Use change management or infrastructure-as-code records as the baseline for expected creation activity.
- Periodically review newly created storage resources for policy alignment, accountability, and compliance evidence.
Analyst notes and limits
This is a data component, not a technique. Its main value is as telemetry for cloud security monitoring, governance, and incident response triage. The supplied ATT&CK object includes examples across AWS, Azure, Google Cloud, and OpenStack Swift, but it does not provide tactics, platform metadata, detections, or related techniques. Local environment baselines are necessary to determine whether a specific creation event is benign or suspicious.
No official detection guidance, tactics, platforms, or relationship context were supplied. This take does not infer active exploitation, attribution, impact, or guaranteed detection coverage. Storage creation alone is not inherently malicious and requires identity, change, and asset context for interpretation.
Cloud Storage Creation
Cloud Storage Creation refers to the initial creation of a new cloud storage resource, such as buckets, containers, or directories, within a cloud environment. This action is critical to track as it might indicate the legitimate provisioning of resources or unauthorized actions taken by adversaries to stage, store, or exfiltrate data. Examples:
- AWS S3 Bucket Creation: An AWS user creates a new S3 bucket using the `CreateBucket` API call. - Azure Blob Storage Container Creation: A user creates a new container in Azure Blob Storage using the `Create Container` operation. - Google Cloud Storage Bucket Creation: A Google Cloud user creates a new bucket using `storage.buckets.create`. - OpenStack Swift Container Creation: A user creates a new container in OpenStack Swift using the `PUT` method.
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 | e54866d84f65… |
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 DC0024Open 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.