An attacker holding a cloud identity that is allowed to read secrets does not need an exploit to empty your secrets manager: the retrieval API returns every value that identity is permitted to see, and the only trace is a read event that many organisations never collect. MITRE ATT&CK tracks this as T1555.006 Cloud Secrets Management Stores, a sub-technique of T1555 Credentials from Password Stores in the Credential Access tactic (TA0006). This guide goes deeper than the parent technique page and the general secrets manager guide: which read events each service records and which are off by default, how to baseline who reads which secret so a new reader stands out, the access designs that limit what one stolen identity can read, and how to respond when secrets may have been read. It covers AWS Secrets Manager, Azure Key Vault, Google Cloud Secret Manager and HashiCorp Vault, listed alphabetically. It is for detection engineers, cloud platform teams and incident responders, and it contains no attack procedures. See the T1555 Credentials from Password Stores Defensive Guide and the Cloud Secrets Managers Guide.
Key takeaways
- This is authorised use by the wrong identity. The call succeeds because the stolen identity has the permission, so prevention is about which identities can read which secrets, and detection is about who is reading.
- Read logging is not always on. Google Cloud Data Access audit logs, which record AccessSecretVersion, are disabled by default; Azure Key Vault needs a diagnostic setting before AuditEvent logs exist; HashiCorp Vault needs an audit device enabled.
- Baseline per secret, not per account. Most secrets have one or two legitimate readers. A first-seen reader, a listing followed by many reads, or a read from an unexpected network is a strong signal.
- Supply chain malware now targets these APIs. ATT&CK links the Shai-Hulud and TeamPCP malware families to T1555.006: a compromised developer or CI identity becomes a secrets reader.
- A read cannot be undone. Response means rotating every secret the identity could have read in the window, not just disabling the identity.
What T1555.006 covers
ATT&CK v20 describes the sub-technique as acquiring credentials from cloud-native secret management services such as AWS Secrets Manager, Google Cloud Secret Manager and Azure Key Vault, and from HashiCorp's Vault, once the adversary has sufficient privileges, for example by obtaining a high-privileged T1078.004 Cloud Accounts credential or compromising a service that is allowed to retrieve secrets. MITRE notes it is distinct from T1552.005 Cloud Instance Metadata API: here the credentials are requested from the secrets manager directly, not through the metadata endpoint. In practice the two often follow each other: a workload credential taken from metadata is then used against the secrets manager.
The procedure examples in ATT&CK v20 cover three patterns defenders should plan for:
- Hybrid lateral movement: HAFNIUM moved from on-premises environments to steal passwords from Azure key vaults. Microsoft's March 2025 Silk Typhoon report recommends preventing on-premises service accounts from holding direct rights to cloud resources.
- Developer and CI malware: Shai-Hulud gathered secrets from AWS Secrets Manager and Google Cloud Secret Manager, and TeamPCP, its cloud stealer and CanisterWorm collected credentials across AWS, Google Cloud and Azure. On the Shai-Hulud npm Worm page, the second-wave payload bundled official cloud SDKs to read all three providers' secrets services.
- Post-exploitation frameworks: ATT&CK lists Pacu and TruffleHog as tools able to retrieve secrets from these services; legitimate security tooling looks the same in the logs, so allowlist your own scanners explicitly.
Detection: the read events per service
MITRE's detection strategy DET0130 looks for secrets read by unusual identities, from unexpected regions, out of hours or at high volume, correlated with the preceding authentication and role assumption. Its only named log source is CloudTrail GetSecretValue. The table gives the equivalent signal for each service and what must be switched on first.
| Service | Value read event | Discovery and change events | Logging prerequisite |
|---|---|---|---|
| AWS Secrets Manager | GetSecretValue, which AWS documents as generated by both the GetSecretValue and BatchGetSecretValue operations; BatchGetSecretValue also has its own event | ListSecrets, DescribeSecret, GetResourcePolicy, PutResourcePolicy, DeleteResourcePolicy | Recorded by CloudTrail by default; the console Event history covers 90 days, so create a trail for an ongoing record. Filter on eventSource secretsmanager.amazonaws.com |
| Azure Key Vault | SecretGet in the AuditEvent log; the identity field holds the user, service principal or user plus appId from the token | Secret listing operations, SecretListVersions, VaultPut and access policy change events | Off until a diagnostic setting sends the AuditEvent category to a Log Analytics workspace or storage account; Microsoft states logs are available within 10 minutes. In Log Analytics, query AzureDiagnostics where ResourceProvider is MICROSOFT.KEYVAULT |
| Google Cloud Secret Manager | AccessSecretVersion, logged as DATA_READ in Data Access audit logs | GetSecret, GetSecretVersion, GetIamPolicy, ListSecrets, ListSecretVersions (ADMIN_READ, Data Access); SetIamPolicy (Admin Activity) | Data Access audit logs are disabled by default for all services except some BigQuery services. Enable DATA_READ and ADMIN_READ for Secret Manager at organisation or folder level so projects inherit it |
| HashiCorp Vault | Read requests and responses on secrets engine paths in the audit log | List operations on secret paths; policy and auth method changes | Enable an audit device (file, syslog or socket). HashiCorp advises enabling at least two, because Vault stops serving requests when no enabled audit device can write |
Notes for each service:
- AWS: because BatchGetSecretValue can return many secrets in one call, alert on that event name in its own right and on GetSecretValue volume per identity. Pair reads with the caller's preceding AssumeRole or sign-in to find the original identity behind a role session.
- Azure: Microsoft's Silk Typhoon report lists a Microsoft Sentinel query named "Keyvault mass secret retrieval" and a Defender for Cloud alert "Unusual user accessed a key vault" as relevant detections. Remember that AzureDiagnostics holds logs for many services, so always filter on the resource provider.
- Google Cloud: Data Access logs add log volume and cost; Google notes that enabling them can result in charges. Scope the enablement to Secret Manager rather than all services, and do not add exempted principals for workload identities, or their reads disappear from the record.
- HashiCorp Vault: by default Vault writes a keyed HMAC-SHA256 of most string values to the audit log, so secret values are not exposed in the log, but the request path, client token accessor and entity are usable for baselining. See the How to audit HashiCorp Vault tokens, policies and auth methods guide.
Baselining who reads which secret
DET0130's mutable elements are the tuning knobs: the set of identities allowed to retrieve secrets, the time window for correlation, the expected frequency and volume per identity, and the regions in which access is expected. Build them from your own logs.
- Collect 30 days of read events per service and group them by secret and reader (role, service principal, service account or Vault entity).
- Record the normal reader set for each secret. A database password read only by one application role and one rotation function has a reader set of two.
- Record the normal context: source network or VPC endpoint, region, user agent (SDK or CLI) and hourly volume.
- Flag the readers that should not exist: human users reading production secrets outside break-glass, CI identities reading secrets of unrelated applications, and any identity with read rights across all secrets.
- Refresh the baseline from deployment metadata, so a new application release adds its reader before the alert fires.
| Rule | Logic | Typical precision |
|---|---|---|
| First-seen reader | Identity reads a secret it has never read in the baseline period | High once deployment metadata feeds the baseline |
| Enumerate then read | Listing call followed within minutes by reads of many different secrets by one identity | High; applications rarely list secrets |
| Bulk retrieval | BatchGetSecretValue, or reads of more than N distinct secrets per hour by one identity | High for workloads, medium for rotation and backup tooling (allowlist them) |
| Human read of workload secret | A user or federated human session reads a production secret outside the break-glass process | High |
| Context break | Known reader, new source network, region or user agent, such as a CLI call from a laptop for a secret normally read by an SDK in a VPC | Medium; strongest when joined with a risky sign-in |
| Failed reads | Bursts of access denied responses on secret reads | Medium; shows an identity probing beyond its rights |
Prevention: limiting what one identity can read
ATT&CK maps M1026 Privileged Account Management to this sub-technique: limit the accounts and services that may query the secrets manager, and limit each to the secrets it needs. The Cloud Secrets Managers Guide covers each service's permission model; the controls below are the ones that decide the blast radius of a stolen identity.
- Per-secret grants: grant read on named secrets or paths, never on all secrets in an account, vault, project or mount. A wildcard reader is the single identity that turns T1555.006 into a full credential dump.
- Separate administration from reading: identities that create, rotate and set policy on secrets should not hold read on their values unless rotation needs it.
- Network conditions: in AWS, resource policies can deny GetSecretValue unless the request comes through a named VPC endpoint (
aws:sourceVpce) or VPC (aws:sourceVpc), so a credential stolen and replayed from outside your network fails. Apply resource policies with the BlockPublicPolicy parameter so Secrets Manager rejects a policy that grants broad access, and check identity policies and KMS key policies too, as AWS advises. - No direct cloud rights for on-premises accounts: Microsoft's Silk Typhoon guidance, aimed at exactly the hybrid path HAFNIUM used.
- Short-lived or dynamic credentials: where the service supports it, issue database and cloud credentials on demand with a short lease, so a stolen value expires. See the HashiCorp Vault Guide and the Azure Key Vault Security Guide.
- Keep developer and CI identities away from production secrets: the supply chain malware in ATT&CK's examples runs where developers and pipelines run. Scope CI roles per repository and environment. See the Secrets Management Guide.
Choosing where to start
| If you have | Do first | Then |
|---|---|---|
| No read logging on one or more services | Enable Key Vault diagnostic settings, Secret Manager Data Access logs and Vault audit devices | Route to the SIEM and confirm one test read appears per service |
| Logging but no baseline | Build reader sets for the 20 most sensitive secrets | Deploy first-seen reader and enumerate-then-read rules in report-only mode |
| Wildcard readers | Use the read logs to find each wildcard reader's real secrets and replace the grant | Add a policy check in IaC that rejects wildcard secret read grants |
| A small estate with one cloud | Provider logging plus the provider's built-in threat detection for the vault | Per-secret grants for production |
Rollout and testing
- Enable logging in a pilot account, subscription or project and measure volume and cost for two weeks before enabling organisation-wide.
- Run the baseline rules in report-only mode for two to four weeks; allowlist rotation functions, backup jobs and your own secret scanners by identity and source.
- Tighten grants per application, starting with production. Replace wildcard reads with named secrets using the observed reader sets, and keep the previous policy version for rollback if an application fails to start.
- Add network conditions on high-value secrets once workloads reach them only through private endpoints; test from inside and outside the network before enforcing.
- Promote high-precision rules to paging and link each alert to the response runbook below.
Responding to suspected secret reads
- Contain the identity: disable or remove read rights from the reading identity and revoke its sessions and tokens; for a workload role, block the role's trust or rotate its credential rather than deleting it, so evidence remains.
- List what was read: from the read events, list every secret and version the identity retrieved in the window. If read logging was off, assume every secret the identity was permitted to read has been read.
- Rotate in priority order: cloud credentials and signing keys first, then database and third-party API credentials. Rotating in the secrets manager is not enough if the downstream system still accepts the old value: revoke it there too.
- Check for use of the stolen values: look for sign-ins and API calls by the downstream identities from new sources after the read time.
- Find the original foothold: trace the reading identity back to its sign-in, role assumption, CI job or host; check for added credentials and roles (T1098.001, T1098.003) so access is not regained.
- Preserve evidence before cleanup: the read events, the identity's policy at the time and any CI or host artefacts.
Measuring whether it works
- Read logging coverage: share of vaults, projects and Vault clusters with value read events reaching the SIEM (target 100 per cent).
- Wildcard readers: number of identities able to read all secrets in an account, vault, project or mount, trending to break-glass only.
- Baseline coverage: share of production secrets with a recorded reader set.
- Time to rotate: median time from a confirmed unauthorised read to rotation and downstream revocation.
- Human reads: production secret reads by human identities outside break-glass, per month.
Common failure patterns
- Logging changes but not reads: Google Cloud Admin Activity logs are always on, which gives a false sense of coverage; AccessSecretVersion lives in Data Access logs that are off by default.
- A vault without diagnostic settings: new Key Vaults created outside the standard template have no AuditEvent log; enforce the setting with policy.
- Exempting the noisy readers: excluding workload identities from Data Access logging to save cost removes exactly the identities an attacker will use.
- Disabling the identity, not rotating the secrets: the values already read stay valid until they are changed at the source.
- One CI role reading everything: a pipeline identity with read on all secrets is the identity supply chain malware reaches first.
- Single Vault audit device: when it fails, Vault stops serving requests; teams then disable auditing to restore service and lose the record.
Framework mapping
| Framework | Relevant items |
|---|---|
| MITRE ATT&CK v20 | T1555.006 Cloud Secrets Management Stores; DET0130; mitigation M1026; related T1078.004 Cloud Accounts, T1552.005 Cloud Instance Metadata API, T1526 Cloud Service Discovery |
| NIST SP 800-53 Rev. 5 | AC-6 Least Privilege; AC-6(9) Log Use of Privileged Functions; AU-12 Audit Record Generation; AU-6 Audit Record Review, Analysis, and Reporting; IA-5 Authenticator Management; SC-12 Cryptographic Key Establishment and Management; SI-4 System Monitoring |
| NIST CSF 2.0 | PR.AA-05 access permissions managed and reviewed; PR.DS-01 data at rest protected; DE.CM-03 technology usage monitored; DE.AE-02 adverse events analysed |
| ISO/IEC 27001:2022 Annex A | 5.17 Authentication information; 8.2 Privileged access rights; 8.15 Logging; 8.16 Monitoring activities |
| CIS Controls v8.1 | Control 3 Data Protection; Control 6 Access Control Management; Control 8 Audit Log Management |
Practitioner checklist
- Confirm value read events are collected for every service: CloudTrail trail, Key Vault AuditEvent diagnostic setting, Secret Manager Data Access logs, at least two Vault audit devices.
- Enforce read logging on new vaults and projects through policy, not manual setup.
- Record a reader set for each production secret and alert on first-seen readers.
- Alert on BatchGetSecretValue, listing followed by many reads, and human reads of workload secrets.
- Replace wildcard secret read grants with named secrets, using the read logs to find real readers.
- Add VPC endpoint or network conditions to high-value secrets where workloads reach them privately.
- Keep CI and developer identities away from production secrets.
- Make "rotate everything the identity could read" a fixed step in the incident runbook.
Standards and references
- MITRE ATT&CK: Credentials from Password Stores: Cloud Secrets Management Stores (T1555.006)
- AWS Documentation: AWS Secrets Manager CloudTrail entries
- AWS Documentation: Resource-based policies for AWS Secrets Manager
- Microsoft Learn: Azure Key Vault logging
- Google Cloud: Secret Manager audit logging
- Google Cloud: Enable Data Access audit logs
- HashiCorp: Vault audit devices
- Microsoft Threat Intelligence: Silk Typhoon targeting IT supply chain
Related NHI Mgmt Group resources: Cloud Secrets Managers Guide · T1555 Credentials from Password Stores Defensive Guide · Cloud Logging and Audit Trail Guide · Oracle Cloud Infrastructure Security Guide · MITRE ATT&CK T1098.003 Account Manipulation