DC0017: Cloud Storage Enumeration

Cloud Storage Enumeration involves retrieving a list of available cloud storage infrastructure, such as buckets, containers, or objects, within a cloud environment. This activity may be performed for legitimate administrative purposes or malicious reconnaissance by adversaries seeking to identify accessible storage resources.Examples:

- AWS S3 Bucket Enumeration: An AWS user lists all buckets using the `ListBuckets` API call. - Azure Blob Storage Container Enumeration: A user retrieves a list of all containers within a storage account using the Azure Storage SDK or API. - Google Cloud Storage Bucket Enumeration: A Google Cloud user lists all buckets within a project using the `storage.buckets.list` API. - OpenStack Swift Container Enumeration: A user retrieves a list of containers in OpenStack Swift using the `GET` method on the storage endpoint.

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

Cloud Storage Enumeration is the act of listing cloud storage resources such as buckets, containers, or objects. For leaders, the practical issue is visibility and authorization: if teams cannot tell who is enumerating storage and whether that activity is expected, they may miss early reconnaissance against sensitive data stores or struggle to prove storage governance during an incident or audit.

Executive priority

Prioritize this as a cloud security and incident-readiness control point. Enumeration can be normal administration, but it is also a useful signal when investigating possible discovery of exposed or over-permissioned storage. Executives should ask whether cloud storage listing activity is logged, retained, attributable to identities, and reviewable across the cloud environments the organization uses.

Technical view

SOC, cloud security, and IR teams should validate that cloud control-plane or storage API activity can show listing of storage infrastructure. The ATT&CK description cites examples such as AWS ListBuckets, Azure container listing via SDK/API, Google Cloud storage.buckets.list, and OpenStack Swift container listing via GET on the storage endpoint. Because no official detection logic or ATT&CK relationships are supplied, detection should be environment-specific and focused on identity, source, scope, frequency, and whether the enumeration aligns with expected administrative workflows.

Likely telemetry

Cloud audit/control-plane logs for storage listing APIs
Storage service access logs where available
Identity and access management logs tying enumeration to user, role, service account, or workload identity
API request metadata such as source IP, user agent, time, project/account/subscription, and request outcome
Administrative tool, SDK, or automation activity records where available

Detection direction

Baseline expected storage enumeration by administrators, automation, backup tools, and asset inventory systems before alerting aggressively.
Look for unusual identities listing storage resources, especially newly created, rarely used, or externally sourced identities.
Correlate enumeration with subsequent access to objects, containers, or buckets when local telemetry supports it.
Tune for false positives from legitimate inventory, compliance scanning, and cloud management workflows.
Validate blind spots caused by missing cloud audit logs, short retention, multi-account or multi-project fragmentation, and inability to map API activity back to accountable identities.

Mitigation priorities

Ensure least-privilege access so only authorized identities can list storage resources where business need exists.
Enable and retain relevant cloud audit and storage access logs for investigation and compliance evidence.
Maintain an inventory of storage resources and expected administrative identities to support baselining.
Review permissions for users, roles, service accounts, and automation that can enumerate storage.
Include cloud storage enumeration evidence requirements in incident response playbooks and audit readiness checks.

Analyst notes and limits

This data component is useful for evaluating whether an organization can observe cloud storage discovery activity. Its value is highest when combined with local identity context, storage sensitivity, permission reviews, and incident timelines. The supplied ATT&CK object provides examples across several cloud storage services, but does not provide platform metadata, tactics, detection analytics, or relationships.

Official detection is not provided, platforms and tactics are not specified, and no relationship context was supplied. This take does not imply active exploitation, attribution, impact, or existing detection coverage. Local cloud architecture, logging configuration, and identity model are required to determine practical coverage.

Official MITRE ATT&CK definition

Cloud Storage Enumeration

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: 52d6c4672d99b24b...

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	`52d6c4672d99…`

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 DC0017
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