Credential harvesting from home directories is the practice of searching a user’s local profile for secrets such as .npmrc, .netrc, SSH keys, cloud tokens, and Vault credentials. It is a high-value supply-chain objective because developer workstations and CI runners often store reusable access material in predictable locations.
What Credential Harvesting From Home Directories Looks Like
Attackers and internal red teams use home-directory harvesting to look for locally stored secrets in predictable user-profile paths. The target set usually includes configuration files and credential material that developers and operators rely on for convenience, which makes the directory a dense source of reusable access.
Because these files are often plain text or lightly protected, the technique is less about cracking security and more about discovering where trust has been left on disk. The value of the method is that one workstation, build host, or CI runner can reveal access to many downstream services.
Why This Technique Matters to Supply Chain Exposure
Home-directory harvesting is especially dangerous in software delivery environments because the secrets it exposes can reach package registries, source control, cloud control planes, and internal tooling. A single stolen token or SSH key can become a pivot into release pipelines, artifact stores, or production-adjacent systems.
That is why credential exposure in developer endpoints is treated as a supply-chain problem, not just an endpoint hygiene issue. NHIMG’s Guide to the Secret Sprawl Challenge is directly relevant because it shows how scattered secrets and exposed credentials create broad operational blast radius. The same risk pattern appears in The State of Secrets Sprawl 2026, which is useful for understanding how widespread secret exposure becomes when teams rely on ad hoc storage habits.
Common Files and Access Paths
Harvesting usually starts with a user’s profile and adjacent application state, where secrets are often stored for convenience rather than governance. Typical targets include shell history, cloud CLI profiles, SSH material, package-manager auth files, and application-specific credential caches.
The practical issue is not just the file type, but the reuse pattern behind it. A local secret may authenticate directly, unlock a vault, or reveal a longer-lived token chain that grants access beyond the original workstation. NHIMG’s Secrets Management Guide helps explain why centralization, rotation, and secretless designs reduce this exposure, while the Static vs Dynamic Secrets section is useful for understanding why long-lived credentials are so attractive to an attacker once found on disk.
How the Technique Becomes a Bigger Incident
credential harvesting from home directories often becomes a staging step for persistence, lateral movement, or supply-chain abuse. Once an attacker finds reusable material, they can impersonate the user, access build systems, or move into shared services that trust that identity.
That pattern is common in real-world credential theft and is also why defensive teams need to think in terms of discovery, exposure, and rapid revocation. NHIMG’s The 52 NHI Breaches Report provides incident grounding for how stolen secrets are used after discovery, and Anthropic GTG-1002 AI espionage campaign shows how credential harvesting can be industrialized when automation is used to search, test, and reuse access material at speed.
Risk and Threat Considerations
Home-directory harvesting is risky because it turns local convenience into remote compromise. The most damaging outcome is usually not the file itself, but the downstream access it unlocks, especially when secrets are reusable, shared across tools, or stored without clear ownership.
Failure mechanism: Attackers or malware enumerate predictable profile paths, extract tokens, keys, and configuration files, then replay those secrets against cloud services, registries, source control, or internal platforms.
Impact: A single exposed profile can enable account takeover, pipeline abuse, data theft, or privileged access to production-adjacent systems, especially when the credential is long-lived or broadly scoped.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK, OWASP Non-Human Identity Top 10 and OWASP API Security Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1552.001 — Unsecured Credentials: Credentials In Files | Covers credentials discovered in local files and profile paths. |
| T1555 — Credentials from Password Stores | Covers theft of stored credential material from user environments and applications. | |
| Recommendation — Hunt for credentials stored in home directories and remove exposed files from endpoints. Search for credential stores and password caches that can be harvested from user systems. | ||
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Directly addresses secrets exposed through local storage and sprawl. |
| NHI-07 — Long-Lived Secrets | Applies when home directories contain reusable credentials that persist too long. | |
| Recommendation — Scan local profiles for leaked secrets and revoke any credential material found. Replace persistent local secrets with shorter-lived credentials and faster rotation. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Directly covers credential lifecycle, storage, rotation, and revocation. |
| AC-6 — Least Privilege | Limits the damage when a harvested secret is reused for access. | |
| Recommendation — Manage credential issuance, storage, rotation, and revocation so secrets do not linger locally. Restrict each credential to the minimum access needed to reduce reuse impact. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | Relevant when harvested tokens or API keys are replayed against services. |
| Recommendation — Validate token handling and revoke exposed API credentials immediately after discovery. | ||
| OWASP ASVS | V14 — Data Protection | Covers secure handling of sensitive data such as stored secrets and tokens. |
| Recommendation — Keep secrets out of local storage unless they are encrypted, scoped, and tightly controlled. | ||
Practitioner Guidance
What to watch for: Treat local secret storage as a governance signal, not just a detection problem. If developers or CI runners need persistent material in home directories, that usually indicates a gap in secret delivery, rotation, or application design.
Practitioner note: The best response is to reduce the amount of reusable material that ever lands in a home directory, then make discovery and revocation fast when it does. NHIMG’s API Key Management Guide is a useful companion where API keys are part of the exposed material, and Guide to NHI Rotation Challenges reinforces why revocation and rotation become harder as secret sprawl grows.
Related resources from NHI Mgmt Group
- Why do compromised packages that reach into home directories and CI environments create broader risk than simple credential theft?
- 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?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 30, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
