DET0130: Detect Unauthorized Access to Cloud Secrets Management Stores
This detection strategy matters because cloud secrets managers often hold the credentials, API keys, and other secret material that applications and cloud...
Analyst context for executives and security teams
This detection strategy matters because cloud secrets managers often hold the credentials, API keys, and other secret material that applications and cloud services rely on. Unauthorized access to those stores can turn an identity or cloud control-plane issue into broader business risk. The ATT&CK object itself has no official detection text, but its relationship to T1555.006 makes the defensive focus clear: validate whether access to cloud-native secrets management services is visible, governed, and reviewable.
Executive priority
Treat this as a cloud identity and resilience control question: who can read secrets, how is that access approved, and can the organization prove when access is unusual or unauthorized? Security leaders should prioritize evidence that secrets manager access is logged, monitored, and tied to accountable identities, because these events may be central to incident scoping, compliance evidence, and containment decisions after credential-access activity.
Technical view
DET0130 detects T1555.006, Cloud Secrets Management Stores, under credential access for IaaS environments. SOC and cloud security teams should validate telemetry for access to services such as AWS Secrets Manager, GCP Secret Manager, Azure Key Vault, and Terraform Vault where present. Focus on read, list, export, policy-change, permission-change, and failed-access patterns around secrets stores, mapped to users, roles, workloads, service principals, and source locations. Because the ATT&CK object provides no official detection logic, local baselining and cloud-specific audit semantics are required.
Likely telemetry
- Cloud control-plane audit logs for secrets manager API activity
- Identity and access management logs for users, roles, service principals, and workload identities
- Secrets manager access logs or diagnostic logs where available
- Authorization and policy change events affecting secret read/list permissions
- Cloud workload logs that show secret retrieval by applications or automation
Detection direction
- Validate that secrets manager read/list/access events are collected and retained for all relevant IaaS accounts, projects, subscriptions, or tenants.
- Tune alerts for unusual secret access by identity, workload, time, source location, volume, or newly granted permission rather than relying only on single-event matching.
- Correlate secret access with IAM changes, new role assumptions, failed access attempts, and subsequent use of credentials where telemetry exists.
- Account for expected automation and application behavior to reduce false positives; service accounts and CI/CD systems may legitimately retrieve secrets at high volume.
- Review blind spots around unmanaged cloud accounts, disabled diagnostic logging, short retention, cross-account access, and secrets managers outside central governance.
Mitigation priorities
- Inventory cloud secrets management stores and identify which identities can read, list, modify, or administer secrets.
- Apply least privilege to human, service, and workload identities that access secrets.
- Ensure audit logging and diagnostic logging are enabled and retained for secrets manager and IAM activity.
- Require change control and review for policy updates that expand access to secrets.
- Use incident response playbooks that define when to rotate secrets, revoke sessions, disable identities, and preserve cloud audit evidence.
Analyst notes and limits
The strongest decision value is not whether a generic alert exists, but whether the organization can reconstruct who accessed which cloud secrets, under what identity context, and whether that access was expected. This detection strategy is especially relevant for managed detection, cloud security monitoring, IAM governance, and incident response scoping in IaaS environments using cloud-native or centralized secrets stores.
The supplied ATT&CK detection strategy has no official description, no official detection text, no tactics, and no platforms specified on the strategy object itself. The practical guidance is derived from its relationship to T1555.006, which identifies IaaS cloud secrets management stores as a credential-access technique. Local cloud providers, logging configuration, identity model, retention, and application behavior determine actual detection feasibility.
Detect Unauthorized Access to Cloud Secrets Management Stores
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 | T1555.006 | Cloud Secrets Management Stores Sub-technique | This object detects Cloud Secrets Management Stores. |
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 | 2d9fa9077af9… |
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 DET0130Open 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.