Moving secrets out of config files and into a secrets manager is good practice. It also puts the most valuable material behind one set of permissions. MITRE ATT&CK technique T1555.006, Cloud Secrets Management Stores, covers adversaries who read from those managers. The tactic is credential access and the platform is IaaS.
How attackers use it
MITRE names AWS Secrets Manager, GCP Secret Manager, Azure Key Vault and Terraform Vault. These services support secure centralized management of passwords, API keys and other credential material. Where they are in use, cloud services can acquire credentials dynamically through API requests, instead of reading them from plain text files or environment variables.
The attack needs privileges. An adversary who obtains credentials for a high privileged cloud account, or who compromises a service with permission to retrieve secrets, can ask the secrets manager for them. MITRE shows the kind of commands involved: get-secret-value in AWS, gcloud secrets describe in GCP and az key vault secret show in Azure.
MITRE also draws a line with the Cloud Instance Metadata API technique (T1552.005). Here the credentials are requested straight from the secrets manager, not through the instance metadata service.
How to detect it
MITRE lists no data sources for this page. The services themselves record access, so use their logs:
- Retrieval events in your cloud audit trail for secret reads, such as the secret value reads in AWS CloudTrail, Secret Manager data access logs in GCP and Key Vault diagnostic logs in Azure. Confirm these are enabled, since some are off by default.
- Reads by an identity that has never read secrets, or reads at unusual hours.
- A sudden burst of reads across many secrets from one identity.
- Reads that come from an IP address or region outside your normal pattern.
Alert on the first two at minimum. A baseline of which workloads read which secrets makes both easy.
How to reduce the risk
MITRE lists one mitigation: privileged account management. Limit the number of cloud accounts and services allowed to query the secrets manager to those that need to, and make sure each can reach only the secrets it requires. In practice that means one scoped permission per workload, no wildcard read policies, and no human users with standing read access to production secrets.
Also reduce how much is stored in the first place. Secrets that are short lived, or generated on demand, are worth less to an attacker.
The demo shows how automated secrets scanning finds credentials in code before they reach a vault or a repository.
Click through it at your own pace, or open it full screen.
Check your own environment
- List which identities can read secrets, and compare against which workloads actually do.
- Search policies for wildcard resource access on secret read actions.
- Confirm secret access logging is on in every account and project.
- Check that alerts exist for secret reads from new identities.
Read-only commands that list secret names without reading values:
# AWS CLI: list secret names and metadata (no values)
aws secretsmanager list-secrets
# Google Cloud CLI: list secrets (no values)
gcloud secrets list
# Azure CLI: list secrets in a vault (names only)
az keyvault secret list --vault-name VAULT_NAME
Quick check
What is the difference between this technique and the Cloud Instance Metadata API technique?
Here the credentials are requested directly from the secrets manager. In the metadata API technique they are obtained through the instance metadata service.
What is the single mitigation MITRE lists?
Privileged account management: limit which accounts and services can query the secrets manager, and limit them to the secrets they need.
