Cloud credential harvesting is the collection of access keys, tokens, certificates, or role credentials from compromised infrastructure. Attackers may pull them from metadata services, environment variables, local files, or container settings, then reuse them to access cloud APIs and expand their reach beyond the original host.
How cloud credential harvesting works
Cloud credential harvesting is usually an opportunistic follow-on to a host compromise. Attackers look for secrets in places developers and automation commonly leave them, then extract whichever credential type is immediately usable for cloud API access, such as long-lived access keys, session tokens, certificates, or role material.
The important detail is that the attacker is not limited to one storage path. Environment variables, metadata services, mounted files, container definitions, build logs, and configuration artifacts can all become sources of usable cloud access if they are exposed after compromise. 230M AWS environment compromise shows how exposed configuration and environment variables can become a direct credential source.
Once harvested, the credential often becomes a portable identity-bearing access path into cloud control planes and downstream services. That is what makes this technique so dangerous: the original host may be only the starting point, while the real objective is cloud reach, persistence, and expansion.
Where attackers find cloud credentials
Harvested credentials often come from predictable operational seams. Common sources include instance metadata services, shell history, local dotfiles, CI/CD variables, secrets embedded in source, container environment settings, mounted service-account material, and developer workspaces copied into production images or logs.
These sources matter because they are frequently trusted by automation and rarely treated as sensitive until they are stolen. If a secret is present in a runtime environment, an attacker with code execution, container escape, or file-system access may be able to reuse it without needing to crack passwords or bypass MFA.
Secret sprawl is the underlying condition that makes harvesting scalable. NHIMG’s Guide to the Secret Sprawl Challenge is a useful companion for understanding how hardcoded credentials, CI/CD exposure, and leaked tokens widen the attack surface.
Why harvested cloud credentials are so valuable
Cloud credentials are attractive because they can convert a single foothold into API-level control across storage, compute, messaging, identity, and deployment services. A stolen token may be enough to enumerate assets, pull data, mint new access paths, or trigger destructive actions depending on its scope.
That reuse value is amplified when credentials are long-lived, overprivileged, or poorly scoped. The same material can often be replayed from a different host, region, or network location, which helps the attacker separate the stolen credential from the original compromise and makes attribution and containment harder.
The Ultimate Guide to NHIs, Static vs Dynamic Secrets explains why long-lived credentials create more durable attack opportunity than short-lived alternatives. NHIMG also reports that 95?%? Actually no stat; use one stat
NHIMG’s research notes that 97% of NHIs carry excessive privileges, which helps explain why harvested cloud credentials so often lead to broader access than defenders expect. In practice, the credential is rarely just an authentication artifact, it is an authorization shortcut.
Security implications and controls
Cloud credential harvesting sits at the intersection of host compromise, secrets exposure, and cloud account abuse. The main security implication is that the breach boundary moves from an endpoint or container to the cloud control plane, where a single credential may unlock multiple services, workloads, or tenants.
Defensive value comes from reducing where credentials can live, reducing how long they remain valid, and reducing what they can do if stolen. That means treating metadata access, secret storage, runtime injection, logging, and rotation as one connected control surface rather than isolated problems. The OWASP Non-Human Identity Top 10 is directly relevant because it frames secret sprawl, rotation, and overprivilege as core cloud credential risk patterns.
For cloud governance and control mapping, the CSA Cloud Controls Matrix and ISO/IEC 27001:2022 Information Security Management are useful because they both connect access control, privileged access, authentication, and cloud security into auditable control expectations.
Risk and Threat Considerations
Cloud credential harvesting is high impact because one stolen secret can bypass perimeter defenses and turn a local compromise into cloud-wide access. The risk increases sharply when the harvested material is long-lived, shared, or overprivileged, because attackers can reuse it quietly and move laterally without immediately triggering obvious host-based alarms.
Failure mechanism: secret exposure in runtime environments, metadata paths, code, logs, or container settings gives an attacker a ready-made cloud access path that survives the original host compromise.
Impact: the attacker can enumerate cloud assets, exfiltrate data, create persistence, abuse compute and storage, or pivot into adjacent accounts and services.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Secret Sprawl and Exposure | Cloud credential harvesting depends on exposed keys, tokens, and certificates. |
| NHI-02 — Credential Rotation and Lifecycle | Stolen cloud credentials remain useful until they are rotated or revoked. | |
| NHI-03 — Privilege and Scope Management | Harvested cloud credentials become more dangerous when they are overprivileged. | |
| Recommendation — Eliminate exposed secret paths and monitor for credential leakage in runtime and code. Shorten credential lifetime and revoke suspected secrets immediately after exposure. Apply least privilege to reduce the blast radius of any harvested cloud credential. | ||
| CIS Controls v8 | 6 — Access Control Management | Cloud credential harvesting is an access-control failure when exposed credentials are reused. |
| 16 — Application Software Security | Secrets embedded in code, build artifacts, and application settings create harvesting exposure. | |
| Recommendation — Remove unnecessary access paths and revoke credentials that are no longer needed. Scan code and build pipelines for embedded secrets before they reach production. | ||
| NIST CSF 2.0 | PR.AA — Identity Management, Authentication, and Access Control | Stolen cloud credentials exploit weak identity and access controls. |
| Recommendation — Strengthen authentication and access policy around cloud credentials and service roles. | ||
| MITRE ATT&CK | T1552 — Unsecured Credentials | Harvesting cloud credentials is direct collection of credentials from exposed storage locations. |
| T1528 — Steal Application Access Token | Cloud tokens and role material can be stolen and replayed for cloud API access. | |
| Recommendation — Hunt for exposed credentials in files, environment variables, and configuration artifacts. Detect token theft and investigate cloud API activity that follows unexpected token use. | ||
Practitioner Guidance
What to watch for: treat unexpected reads of metadata services, unusual secret access, and credential use from new hosts or regions as indicators of harvesting or replay. Cloud access that appears valid but does not match the normal workload location or execution pattern deserves immediate review.
Governance implication: ownership has to cover both the workload that uses the credential and the control that issues, stores, and rotates it. If no one is accountable for runtime secret placement and revocation, harvesting risk will persist even when the underlying workload is rebuilt.
Related resources from NHI Mgmt Group
- Why do identity based phishing attacks create more risk than traditional credential harvesting pages in cloud and SaaS environments?
- How can organisations reduce credential abuse in cloud environments?
- How do security teams know whether a policy engine can be abused for cloud credential theft?
- Who is accountable when a cloud credential is misused by an AI workflow?
