Unsecured credentials are passwords, API keys, and tokens stored in plain, readable places rather than a secure vault: config files, scripts, environment variables, command history, CI/CD variables, cloud metadata, and infrastructure-as-code. After landing on a host, attackers simply search the filesystem for them, no dumping or cracking required. It is one of the most common and reliable ways to escalate or move laterally, which is why secrets management and scanning matter so much. It maps to MITRE T1552.
What unsecured credentials are
Not every credential is locked in a hive or vault. Many sit in plaintext wherever a developer or admin found it convenient: a database password in a web app config file, an API key in a script or environment variable, a token in ~/.bash_history, secrets in CI/CD variables or IaC files, or cloud keys reachable from the instance metadata endpoint.
Unsecured credentials are exactly these, and finding them is just searching, not attacking cryptography.
Where attackers look and payload
On any foothold, the attacker greps for secrets:
- Config and code:
grep -rinE "password|secret|api[_-]?key|token" /var/www /opt /home - History and env:
cat ~/.bash_history,env,cat ~/.aws/credentials,~/.ssh/ - Cloud metadata (from a server): query the instance metadata endpoint for temporary cloud keys.
- CI/CD and IaC: pipeline variables,
.env, Terraform state, Kubernetes manifests.
Whatever turns up is used directly, no cracking. Documented for defensive context.
How to defend
- Use a secrets manager / vault and inject secrets at runtime, never hardcode them in code, configs, or images.
- Scan repositories, images, and pipelines for secrets in CI and pre-commit.
- Use short-lived, scoped credentials (cloud roles, workload identity) so any leaked secret expires fast.
- Protect cloud metadata (enforce IMDSv2, restrict access) so server-side requests cannot harvest keys.
- Rotate exposed secrets immediately and audit history/env for leftovers.