A password in a file is a password anyone who can read the file can use. MITRE tracks the hunt for these as T1552.001, Credentials In Files, a Credential Access technique under Unsecured Credentials. The platforms are Containers, IaaS, Linux, macOS and Windows.
How attackers use it
Adversaries search local file systems and remote file shares for files that hold insecurely stored credentials. MITRE lists the kinds of files involved.
- Files users made to keep their own credentials.
- Shared credential stores for a group of people.
- Configuration files containing passwords for a system or service.
- Source code or binary files with embedded passwords.
Passwords can also come out of backups or saved virtual machines, through OS Credential Dumping, and out of Group Policy Preferences stored on a Windows domain controller.
Cloud and container environments add their own places. Authenticated user and service account credentials are often kept in local configuration and credential files, and they may also appear as parameters to deployment commands in container logs. In some cases the files can be copied and reused on another machine, or the contents read and used to authenticate with no copying at all.
If your pipeline or deployment tooling writes a secret into a log, a config or an image layer, you have created the file this technique looks for.
How to detect it
MITRE's detection strategy has an analytic per platform.
- Windows: access to insecure credential files, such as
.envfiles, XML and PowerShell scripts, followed by suspicious process execution or authentication with the retrieved credentials. The data comes from Sysmon and Windows Security logs. - Linux: reads or process executions that involve credential-bearing config files by non-root or unusual users, followed by SSH authentication attempts.
- macOS: terminal-based grep or open of plist or configuration files that hold credentials, correlated with Keychain or system login attempts.
- Containers: container processes reading mounted secrets or configuration paths, such as
/run/secretsor/mnt/config, followed by network access or credential use. - Cloud: access to local credential or config files, such as
~/.aws/credentials, followed by metadata API calls or cloud role assumptions.
The pattern across all five: a read of a credential file, then a use of a credential. Join the two events and you have a signal that single events lack.
How to reduce the risk
MITRE lists four mitigations.
- Audit: preemptively search for files that contain passwords and reduce the exposure when you find them.
- Password Policies: set an organizational policy that prohibits storing passwords in files.
- Restrict File and Directory Permissions: limit file shares to specific directories, with access only for users who need them.
- User Training: make sure developers and system administrators know the risk of plaintext passwords in configuration files left on endpoints or servers.
A policy only works with a tool behind it. Add secret scanning to commits and builds, so a credential is caught before it is committed, and to container images and shares so old ones are found too. When a secret turns up, rotate it. Deleting the file does not undo the exposure.
Check your own environment
Read-only checks. On Linux or macOS, look at the permissions of a typical credential file.
ls -l ~/.aws/credentials
ls -ld ~/.aws ~/.ssh
On a Linux host with containers, list which secrets a running container sees.
docker inspect --format '{{json .Mounts}}' <container>
Also ask these.
- Which file shares allow broad read access, and what is on them?
- Do build logs ever print environment variables?
- Do
.envfiles appear in your repositories or image layers?
Secrets scanning checks those places on a schedule. The interactive demo walks through a scan and how findings are triaged.
Click through it at your own pace, or open it full screen.
Quick check
Where besides config files might container credentials appear?
In container logs, as parameters to deployment commands, and in local credential files for cloud and service accounts.
Why is deleting a file with a password in it not enough?
Anyone who read it earlier still has the credential. It has to be rotated.
Sources
- MITRE ATT&CK, Unsecured Credentials: Credentials In Files: https://attack.mitre.org/techniques/T1552/001
