Credential Harvesting

What Credential Harvesting Means in Practice

Credential harvesting is dangerous because the stolen material is often already trusted by systems, cloud platforms, and security tooling. Once secrets, tokens, keys, or certificates are taken from a workload, an attacker may be able to impersonate that workload, reach adjacent services, or pivot into higher-value environments without needing to break cryptography first.

In containerised and cloud-native environments, harvesting commonly succeeds because workloads expose identity material in predictable places: environment variables, mounted files, projected tokens, application config, and metadata endpoints. The core issue is not just theft, but reuse, a captured secret often unlocks more than one resource until it is revoked or expires.

Where Credential Harvesting Usually Happens

The most exposed locations are the ones that are convenient for applications and automation. That includes filesystem paths used to mount secrets, runtime environment variables, in-pod tokens, and access paths to cloud instance metadata or workload identity endpoints. A compromise at the container, pod, or node layer can therefore become an identity compromise even when the original application was not the target.

Harvesting also appears in incidents where attackers exploit remote code execution, SSRF, or misconfigured host access to read identity material directly from memory, disk, or local services. NHIMG’s SSRF Prevention Guide is relevant because metadata-service abuse is a common route from application weakness to credential exposure.

Why Stolen Secrets Are So Valuable

Harvested secrets are attractive because they often bypass interactive controls, phishing resistance, and normal user friction. A service token, API key, or certificate can be used from a different host, a different geography, or an automated workflow, which makes abuse faster and harder to distinguish from legitimate traffic.

Where credentials are long-lived or broadly scoped, one theft can create persistent access and a wide blast radius. That is why lifecycle controls matter as much as storage controls: rotation, expiry, scoping, and revocation determine how long a harvested secret remains useful to an attacker. The OWASP Non-Human Identity Top 10 helps frame why secret leakage, overprivilege, and long-lived credentials are recurring identity-security risks.

How Organisations Reduce Exposure and Detect Abuse

Exposure checks should start with inventory. Teams need to know which workloads hold secrets, where those secrets are mounted or injected, which metadata services are reachable, and which credentials are actually reusable outside the original workload boundary. That visibility is often the difference between a contained compromise and a broader identity breach.

Prevention usually combines secret minimisation, short-lived credentials, strong workload authentication, and egress restrictions that limit access to local metadata or vault endpoints. Detection should look for unusual secret access, unexpected calls to metadata services, token use from new network locations, and post-exfiltration activity such as privilege escalation or lateral movement. The OWASP Cheat Sheet Series provides broader implementation guidance for authentication and secret handling, while the OAuth 2.0 Authorization Framework is a useful reference when the harvested material is an access token or client credential.

Response After Suspected Harvesting

Once harvesting is suspected, response should focus on invalidating what was stolen and checking what it already unlocked. That means rotating the affected secrets, revoking sessions or tokens where possible, reviewing audit logs for use of the stolen material, and confirming whether any higher-privilege credentials were reached through the same compromise path.

For container and cloud workloads, post-incident review should also ask whether the credential source itself was overexposed. If a metadata endpoint, mounted secret, or API key store was accessible from a compromised workload, the remediation should include both the stolen credential and the access path that made the theft possible.

Related resources from NHI Mgmt Group

• Why do AI agents create new risk for credential harvesting and intrusion workflows?
• How should security teams defend npm supply chains against credential-harvesting worms that spread through compromised maintainer access?
• Why do identity based phishing attacks create more risk than traditional credential harvesting pages in cloud and SaaS environments?
• What happens when attackers combine credential harvesting with lateral movement and data exfiltration?