Attacks on credential storage
Techniques that target where secrets rest rather than how they are used: infostealer malware, secrets left in source repositories and CI logs, and key extraction from the vaults meant to protect them.
Why this control fails
Credentials that sit still are easier to steal than credentials in motion. Infostealer malware harvests browser-saved passwords, session cookies, and API keys from a single compromised endpoint in one pass. Source repositories and CI pipeline logs leak long-lived static secrets routinely, because a secret committed once and later removed from the file usually still exists in git history. Secrets managers themselves are not exempt: an authenticator bug or an over-permissioned policy engine on a vault turns "we store secrets securely" into "we handed out every secret the vault held," which is a worse outcome than the sprawl the vault was bought to fix.
What security people should do
- Scan repositories and CI logs for committed secrets continuously, and treat a found secret as compromised, not just as a finding to close.
- Replace long-lived static API keys with short-lived, automatically rotated credentials wherever the platform supports it.
- Patch secrets manager software on the same cadence as any other identity provider, and restrict who can edit authenticator configuration or policy engine templates.
- Rotate every secret a vault or credential store held if its authenticator was reachable while a known vulnerability was unpatched.
Techniques in this category
Any authenticated domain user can request a Kerberos service ticket for any service principal, and that ticket is encrypted with the service account's own password hash, offline and unrateable to test.
A passkey or Windows Hello key is supposed to stay locked to its device. Code running on an already-compromised endpoint can pull the key material out of the process that holds it, or drive it without the fresh check meant to gate its use.
Commodity malware on an endpoint reads whatever the browser and OS have stored in the clear or under a key the same machine already holds, then ships it to a marketplace where the credentials outlive the machine they came from.
A credential committed to a config file or pasted into a pipeline variable travels with every clone, fork, and log line, and it keeps working for as long as nobody notices it left the vault.
A static API key has no expiry, no built-in scope beyond what was granted at creation, and no way to tell whether the caller presenting it is the workflow it was issued to or whoever found it in a public commit.