DC0025: Cloud Storage Access

Cloud storage access refers to the retrieval or interaction with data stored in cloud infrastructure. This data component includes activities such as reading, downloading, or accessing files and objects within cloud storage systems. Common examples include API calls like GetObject in AWS S3, which retrieves objects from cloud buckets. Examples:

- AWS S3 Access: An adversary uses the `GetObject` API to retrieve sensitive data from an AWS S3 bucket. - Azure Blob Storage Access: A user accesses a blob in Azure Storage using `Get Blob` or `Get Blob Properties`. - Google Cloud Storage Access: An adversary uses `storage.objects.get` to download objects from - OpenStack Swift Storage Access: A user retrieves an object from OpenStack Swift using the `GET` method.

EnterpriseDC0025Data ComponentObject v2.0 Modified Nov 12, 2025, 22:03 UTC (UTC+00:00)

Cloud Storage Access is the evidence trail for who or what reads, downloads, or otherwise interacts with data in cloud storage. For leaders, this matters because sensitive business data may be exposed through ordinary-looking storage access rather than malware. The practical question is whether the organization can prove which identities, services, and workloads accessed important cloud objects when an incident, audit request, or data exposure investigation occurs.

Executive priority

Prioritize this data component where cloud storage holds regulated, sensitive, customer, operational, or intellectual-property data. It supports incident scoping, compliance evidence, and cloud security assurance by helping answer: what data was accessed, by whom, when, and through which cloud storage interface. Because ATT&CK provides no detection guidance or tactic mapping for this object, executives should treat it as a coverage-validation item: confirm that cloud storage access logs are enabled, retained, searchable, and tied to identity and asset context before they are needed during an investigation.

Technical view

SOC, cloud security, and IR teams should validate collection and analysis of cloud storage read/access events, including examples named by MITRE such as AWS S3 GetObject, Azure Blob Get Blob or Get Blob Properties, Google Cloud Storage storage.objects.get, and OpenStack Swift GET activity. Since no ATT&CK detection text or relationships are supplied, detection engineering should focus on local risk models: access to sensitive buckets or containers, unusual download volume, access by unexpected identities, access from unusual locations or services, and access patterns inconsistent with normal workload behavior. Correlation with identity, authorization, object classification, and network context will usually determine whether this telemetry is actionable.

Likely telemetry

Cloud storage object access logs showing read, download, or object retrieval activity
Cloud provider API activity for storage access events, such as GetObject, Get Blob, storage.objects.get, or Swift GET where applicable
Identity and principal context associated with storage access, including user, role, service account, or workload identity
Resource context for buckets, containers, blobs, files, or objects accessed
Timestamps, source network context, request metadata, and response status for storage retrieval activity

Detection direction

Verify that cloud storage access logging is enabled for business-critical and sensitive storage locations, not just management-plane activity.
Test whether analysts can search object-level access events and join them to identity, resource, and data classification context.
Tune detections around locally abnormal access patterns, such as unusual object retrieval volume, access to sensitive stores by unexpected principals, or access outside established workload behavior.
Account for false positives from backup jobs, analytics pipelines, data replication, application reads, and administrative testing.
Identify blind spots where object-level reads are not logged, logs are not retained long enough, or storage access is performed by shared or poorly attributed service identities.

Mitigation priorities

Classify cloud storage locations by business sensitivity so access telemetry can be prioritized during alerting and investigations.
Enable and retain storage access logs for sensitive or business-critical cloud storage systems.
Use least-privilege access design for users, roles, service accounts, and workloads that can read cloud storage objects.
Review permissions and access paths for storage containing regulated, customer, operational, or high-value business data.
Ensure incident response runbooks include procedures for scoping cloud object access and preserving relevant logs.

Analyst notes and limits

This object is a data component, not a technique. It describes the telemetry category for access to cloud-stored data. The supplied ATT&CK fields include examples across AWS S3, Azure Blob Storage, Google Cloud Storage, and OpenStack Swift, but do not provide ATT&CK tactics, platforms, detection guidance, or relationship context. Use this as a control and telemetry validation anchor for cloud storage investigations rather than as a standalone behavioral analytic.

No official detection text, tactics, platforms, or relationships were supplied. Any detection thresholds, risk scoring, or assumptions about maliciousness must come from local environment baselines, data sensitivity, identity model, and cloud architecture. This summary does not claim active exploitation, attribution, impact, or existing coverage.

Official MITRE ATT&CK definition

Cloud Storage Access

View the same entry on attack.mitre.org (MITRE-hosted reference; in-page links above use the Glexia ATT&CK library.)

Glexia analysis

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.

Relationship explorer

All related ATT&CK context

No relationships are available in the current normalized data for this object.

Change history

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 .

ATT&CK release: 19.1
Object version: 2.0
Created: Oct 20, 2021, 15:05 UTC (UTC+00:00)
Modified: Nov 12, 2025, 22:03 UTC (UTC+00:00)
Raw hash: 33e17801145748ea...

Imported snapshots across ATT&CK releases (1)

Release	Bundle imported	Object version	Modified	Status	Raw hash
19.1	May 18, 2026, 07:08 UTC (UTC+00:00)	2.0	Nov 12, 2025, 22:03 UTC (UTC+00:00)	Current bundle	`33e178011457…`

Raw source

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.

Open mirrored raw JSON Open MITRE-hosted copy

Source references

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 DC0025
Open source URL

Source and licensing

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.

Official MITRE ATT&CK site Official STIX data repository MITRE ATT&CK terms of use