DET0578: Detection Strategy for Cloud Storage Object Discovery
DET0578 is a MITRE ATT&CK detection strategy tied to Cloud Storage Object Discovery (T1619): adversaries enumerating objects in cloud storage after identif...
Analyst context for executives and security teams
DET0578 is a MITRE ATT&CK detection strategy tied to Cloud Storage Object Discovery (T1619): adversaries enumerating objects in cloud storage after identifying storage services. For leaders, the practical issue is not just “someone listed files”; it is whether cloud storage activity is visible enough to prove who discovered sensitive objects, when it happened, and whether discovery could enable later access or exfiltration decisions.
Executive priority
Prioritize this as a cloud security and incident-readiness validation item. If the organization depends on IaaS cloud storage for regulated data, backups, customer content, or operational records, leadership should ask whether storage enumeration is logged, retained, attributable to identities, and reviewable during an incident or audit. The supplied ATT&CK object does not provide a specific detection analytic, so the business decision is to confirm coverage and ownership rather than assume a named detection exists.
Technical view
This detection strategy has no official ATT&CK detection text and no explicit platforms listed, but it detects T1619, which is a Discovery technique on IaaS. SOC, cloud security, and IR teams should validate visibility into cloud storage object listing/enumeration events, the identity or role performing them, source context, target storage resources, and whether activity followed broader cloud infrastructure discovery. Detection engineering should focus on baselining expected object discovery patterns and identifying unusual enumeration by identities, roles, automation, or locations that do not normally inspect those storage resources.
Likely telemetry
- Cloud storage data-plane and management-plane audit logs showing object or bucket/container listing activity
- Cloud identity and access logs for users, roles, service principals, temporary credentials, and assumed roles
- Cloud infrastructure inventory or configuration logs that show storage services and permissions
- Network or API access metadata such as source IP, user agent, session context, and request volume where available
- SIEM/cloud security platform alerts and audit trails correlating storage enumeration with prior cloud infrastructure discovery
Detection direction
- Confirm that object enumeration events are actually collected and retained for the relevant IaaS storage services; absence of an official DET0578 analytic means local log validation is essential.
- Correlate storage object discovery with T1619 context: identities listing many objects, accessing unfamiliar storage locations, or enumerating shortly after cloud infrastructure discovery activity.
- Tune against expected administrative, backup, indexing, data processing, and security scanning workflows to reduce false positives.
- Pay attention to identity context: a valid cloud role or service account can make discovery appear legitimate unless behavior is compared with normal scope, timing, and resource access patterns.
- Validate whether logs capture both successful and denied enumeration attempts; denied attempts can be important early evidence of reconnaissance or mis-scoped credentials.
Mitigation priorities
- Establish least-privilege access to cloud storage so identities only enumerate storage objects required for their role.
- Enable and retain cloud storage and identity audit logging before relying on detection content.
- Review permissions for high-value storage locations, especially broad list/read permissions assigned to users, roles, service accounts, or automation.
- Document normal administrative and application enumeration patterns so SOC teams can distinguish expected operations from suspicious discovery.
- Include cloud storage discovery evidence in incident response playbooks, audit evidence packages, and cloud control reviews.
Analyst notes and limits
The supplied object is a detection strategy record for DET0578 and is only linked to T1619 Cloud Storage Object Discovery. The take therefore emphasizes validation of telemetry, identity context, and detection engineering direction rather than a specific MITRE-provided analytic. Relationship context supports IaaS and Discovery framing via T1619.
Official description and official detection are not provided for DET0578, and the detection strategy itself lists no platforms or tactics. Any concrete analytic thresholds, cloud-provider-specific event names, or claims of coverage require local environment data and are not supplied by the ATT&CK fields here.
Detection Strategy for Cloud Storage Object Discovery
No official description is available in the imported ATT&CK source object.
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.
Techniques used
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Enterprise | T1619 | Cloud Storage Object Discovery | This object detects Cloud Storage Object Discovery. |
All related ATT&CK context
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 | 8cebe5e61bce… |
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 DET0578Open 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.