Config files, .env files and cloud credential files are common targets. The stolen secret is then used to sign in somewhere else. MITRE tracks it as T1552.001.
How it works
MITRE says adversaries may search local file systems and remote file shares for files with insecurely stored credentials. These can be files users made for their own passwords, shared credential stores, configuration files with passwords for a service, or source and binary files with embedded passwords.
MITRE adds that in cloud and container environments, user and service account credentials are often kept in local configuration and credential files. A researcher’s November 2026 writeup describes this pattern in a live product; see Home Assistant token secrets and why a password reset does not revoke them. They may also appear as parameters to deployment commands in container logs. In some cases the file can be copied to another machine, or its contents read and used to authenticate without copying anything.
A real example
MITRE lists the TeamPCP Cloud Stealer, which can check more than 50 file paths for credentials across CI/CD, cloud and container environments. It also lists Mini Shai-Hulud, which collects credentials from configuration files. On 21 October 2026 Socket mapped the malicious LiteLLM 1.107.0 release to this technique: its stealer read cloud, developer and AI tool credential files and .env files. See the LiteLLM 1.107.0 incident profile and our LiteLLM 1.107.0 response checklist.
Seen in incidents
How to detect
-
Reads of credential files, then use of the secret
MITRE's strategy DET0307 looks for access to insecure credential files such as .env, .xml or .ps1 files. It then looks for suspicious process execution or logins that use the retrieved credentials.
-
Config reads by unusual users
MITRE says to flag reads of config files with password fields by non-root or unusual users, followed by SSH login attempts.
-
Container access to mounted secrets
MITRE says to flag container processes that read mounted secrets or config paths such as /run/secrets, followed by network activity or credential use.
-
Cloud credential files, then metadata calls
MITRE says to flag access to local credential files such as ~/.aws/credentials, followed by metadata API calls or cloud role assumptions.
How to defend
-
Audit for files that hold passwords
MITRE mitigation M1047 (Audit) says to scan proactively for files that contain passwords and reduce exposure where they are found.
-
Ban password storage in files
MITRE mitigation M1027 (Password Policies) suggests an organizational rule against storing passwords in files.
-
Restrict file and share permissions
MITRE mitigation M1022 limits file shares to specific directories and gives access only to the users who need it.
-
Train developers and administrators
MITRE mitigation M1017 (User Training) says to make people aware that plaintext passwords in config files can persist on endpoints and servers.
-
Rotate after any host that ran untrusted code
After the LiteLLM 1.107.0 compromise, LiteLLM tells users to rotate every secret the host could reach, because it says a marker file confirms exfiltration but its absence proves nothing.
Frequently Asked Questions
What counts as a credential file?
MITRE names user-made password files, shared credential stores, configuration files with passwords and source or binary files with embedded passwords. In cloud and container setups it also names local credential and config files.
Is T1552.001 the same as credential dumping?
No. MITRE treats OS Credential Dumping as a separate technique, T1003. T1552.001 is about reading files that already hold secrets. MITRE notes that passwords can also be pulled from backups or saved virtual machines through dumping.
