T1555.006: Cloud Secrets Management Stores
Adversaries may acquire credentials from cloud-native secret management solutions such as AWS Secrets Manager, GCP Secret Manager, Azure Key Vault, and Terraform Vault.
Secrets managers support the secure centralized management of passwords, API keys, and other credential material. Where secrets managers are in use, cloud services can dynamically acquire credentials via API requests rather than accessing secrets insecurely stored in plain text files or environment variables.
If an adversary is able to gain sufficient privileges in a cloud environment – for example, by obtaining the credentials of high-privileged Cloud Accounts or compromising a service that has permission to retrieve secrets – they may be able to request secrets from the secrets manager. This can be accomplished via commands such as `get-secret-value` in AWS, `gcloud secrets describe` in GCP, and `az key vault secret show` in Azure.[1][2][3][4][5]
**Note:** this technique is distinct from Cloud Instance Metadata API in that the credentials are being directly requested from the cloud secrets manager, rather than through the medium of the instance metadata API.
Analyst context for executives and security teams
Cloud secrets managers are designed to reduce credential sprawl, but they also become high-value targets: if an adversary gains enough cloud privilege or compromises a service identity with secret-read permissions, they may directly request passwords, API keys, or other credential material from services such as AWS Secrets Manager, Google Cloud Secret Manager, Azure Key Vault, or Terraform Vault.
Executive priority
Treat access to cloud secrets stores as a business-continuity and incident-response priority, not only a cloud administration issue. Leaders should ask whether secret access is least-privileged, logged, reviewed, and quickly revocable, because a single over-permissioned cloud account or workload identity can expose credentials that support further compromise across applications, infrastructure, and third-party integrations.
Technical view
This is an IaaS credential-access sub-technique under Credentials from Password Stores. SOC and cloud security teams should validate visibility into cloud control-plane activity for secret listing, description, and retrieval operations, tied back to the calling principal, role/session, workload, source context, and target secret. ATT&CK provides a related detection strategy, DET0130: Detect Unauthorized Access to Cloud Secrets Management Stores. ATT&CK also maps mitigation M1026, Privileged Account Management, which is directly relevant because this behavior depends on sufficient permissions to retrieve secrets.
Likely telemetry
- Cloud provider audit/control-plane logs for secrets manager and key vault activity
- Secret read, list, describe, and retrieval events from AWS, GCP, Azure, or other supported secrets stores
- IAM user, role, service account, session, and workload identity activity
- Privileged account usage and permission changes affecting secret access
- Cloud service or application identity access to secrets
Detection direction
- Baseline normal secret access by principal, workload, application, and environment; alert on unusual secret retrieval patterns or access by identities that do not normally use those secrets.
- Correlate secret access with recent privilege changes, new role assumptions, compromised cloud accounts, or unusual service identity behavior.
- Validate that logs capture both successful and failed access attempts, because denied secret access can indicate probing or mis-scoped permissions.
- Tune detections carefully for automation-heavy environments where legitimate deployments and runtime services may retrieve secrets frequently.
- Account for blind spots where cloud audit logging is disabled, not centralized, retained for too short a period, or lacks linkage between workload identity and human administrator activity.
Mitigation priorities
- Prioritize privileged account management for cloud administrators, service accounts, and workload identities that can retrieve secrets.
- Apply least privilege and role-based access so identities can access only the specific secrets required for their function.
- Review and monitor privileged usage, secret-access permissions, and policy changes for accountability through logging and auditing.
- Separate duties between secret administration and secret consumption where feasible.
- Ensure incident response playbooks include rapid review, revocation, and rotation of secrets after suspected unauthorized access.
Analyst notes and limits
MITRE does not provide official detection text for this object, but it does include a related detection strategy, DET0130. The object is scoped to IaaS and credential access, and the official description specifically distinguishes direct secret manager access from Cloud Instance Metadata API access. ATT&CK also relates this technique to HAFNIUM, Storm-0501, Pacu, Shai-Hulud, and TruffleHog, which is useful for threat-informed detection planning but should not be interpreted as evidence of local activity.
This take is based only on the supplied ATT&CK fields, references, and relationships. Actual exposure depends on the organization’s cloud providers, enabled audit logs, IAM design, workload identities, secret store usage, and retention. No guaranteed detection coverage or active exploitation is implied.
Cloud Secrets Management Stores
Adversaries may acquire credentials from cloud-native secret management solutions such as AWS Secrets Manager, GCP Secret Manager, Azure Key Vault, and Terraform Vault.
Secrets managers support the secure centralized management of passwords, API keys, and other credential material. Where secrets managers are in use, cloud services can dynamically acquire credentials via API requests rather than accessing secrets insecurely stored in plain text files or environment variables.
If an adversary is able to gain sufficient privileges in a cloud environment – for example, by obtaining the credentials of high-privileged Cloud Accounts or compromising a service that has permission to retrieve secrets – they may be able to request secrets from the secrets manager. This can be accomplished via commands such as `get-secret-value` in AWS, `gcloud secrets describe` in GCP, and `az key vault secret show` in Azure.[1][2][3][4][5]
**Note:** this technique is distinct from Cloud Instance Metadata API in that the credentials are being directly requested from the cloud secrets manager, rather than through the medium of the instance metadata API.
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.
Related techniques
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 | Credentials from Password Stores | This object subtechnique of Credentials from Password Stores. |
Groups, software, and campaigns
G0125: HAFNIUM
HAFNIUM is a likely state-sponsored cyber espionage group operating out of China that has been active since at least January 2021. HAFNIUM primarily targets entities in the US across a number of industry sectors, including infectious disease researchers, law firms, higher education institutions, defense contractors, policy think tanks, and NGOs. HAFNIUM has targeted remote management tools and cloud software for intial access and has demonstrated an ability to quickly operationalize exploits for identified vulnerabilities in edge devices.[1][2][3]
G1053: Storm-0501
Storm-0501 is a financially motivated cyber criminal group that uses commodity and open-source tools to conduct ransomware operations. Storm-0501 has been active since 2021 and has previously been affiliated with Sabbath Ransomware and other Ransomware-as-a-Service (RaaS) variants such as Hive, BlackCat, Hunters International, LockBit 3.0, and Embargo ransomware.[1][2][3][4]
S9008: Shai-Hulud
Shai-Hulud is a supply chain worm, first reported in September 2025, that spreads through code repositories, including GitHub and NPM packages. It exploits CI/CD pipeline dependencies to propagate to victims and poisons the supply chain by publishing malicious packages. Once inside a victim environment, Shai-Hulud steals credentials and access tokens from compromised repository accounts and exfiltrates them to attacker-controlled servers via encoded GitHub Actions workflows.[1][2][3][4][5][6][7]
S9009: TruffleHog
TruffleHog is an open-source secrets-discovery tool that is used to search for credentials, API keys, and encryption keys across a variety of data sources and environments.[1][2] TruffleHog has the ability to discover credentials and secrets stored in code repositories, git history, CI/CD pipelines, among other common storage locations to include filesystems and cloud storage buckets.[1][3][2] TruffleHog was first released by its author in 2016.[2]
S1091: Pacu
Pacu is an open-source AWS exploitation framework. The tool is written in Python and publicly available on GitHub.[1]
All related ATT&CK context
Mitigation direction
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 | bcb8242e9a57… |
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]
Permiso Scattered Spider 2023
Ian Ahl. (2023, September 20). LUCR-3: SCATTERED SPIDER GETTING SAAS-Y IN THE CLOUD. Retrieved September 25, 2023.
Open source URL -
[2]
Sysdig ScarletEel 2.0 2023
Alessandro Brucato. (2023, July 11). SCARLETEEL 2.0: Fargate, Kubernetes, and Crypto. Retrieved September 25, 2023.
Open source URL -
[3]
AWS Secrets Manager
AWS. (n.d.). Retrieve secrets from AWS Secrets Manager. Retrieved September 25, 2023.
Open source URL -
[4]
Google Cloud Secrets
Google Cloud. (n.d.). List secrets and view secret details. Retrieved September 25, 2023.
Open source URL -
[5]
Microsoft Azure Key Vault
Microsoft. (2023, January 13). Quickstart: Set and retrieve a secret from Azure Key Vault using Azure CLI. Retrieved September 25, 2023.
Open source URL -
[6]
mitre-attack T1555.006Open 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.