Most intrusions need credentials at some point, and many systems leave them lying around. MITRE tracks the search for them as T1552, Unsecured Credentials, a Credential Access technique. The platform list shows how widespread the problem is: Windows, SaaS, IaaS, Linux, macOS, Containers, Network Devices, Office Suite and Identity Provider.
How attackers use it
MITRE's description is short. Adversaries search compromised systems for insecurely stored credentials. Those can be stored or misplaced in many places: plaintext files (for example shell history), operating system or application repositories (for example the Registry), or specialized files and artifacts (for example private keys).
The sub-techniques split along those lines, and each has its own post in this series.
- Credentials in Files (T1552.001).
- Credentials in Registry (T1552.002).
- Shell History (T1552.003).
- Private Keys (T1552.004).
- Cloud Instance Metadata API (T1552.005).
- Group Policy Preferences (T1552.006).
The common feature is that none of these need an exploit. The adversary reads something that was already there.
How to detect it
MITRE's detection strategy has an analytic for each platform and context.
- Windows: unusual access to bash history, registry credential paths or private key files by unauthorized users or scripting tools, with correlated file and process activity.
- Linux: reads of sensitive files such as
.bash_history,/etc/shadowor private key directories by unauthorized users or unusual processes. - macOS: unusual access to
~/Library/Keychains,~/.bash_historyor Terminal command history by unauthorized processes or users. - SaaS: unusual web access or API scraping of password managers, single sign-on sessions or credential sync services, through browser automation or anomalous API tokens.
- IaaS: unauthorized API or console calls to retrieve or reset password credentials, download key material or change SSO settings.
- Containers: access to image layers or mounted secrets, such as Docker secrets, by processes that are not tied to the entrypoint or orchestration context.
- Network devices: use of configuration backup tools or CLI access to dump plaintext passwords, local user hashes or SNMP strings.
This is a lot of ground, so start from what you already collect. File access auditing on a short list of sensitive paths covers a surprising share of it.
How to reduce the risk
MITRE lists a dozen mitigations. Grouped, they come down to this.
- Find it first. Audit: preemptively search for files containing passwords or other credentials and reduce the exposure when found.
- Do not store it. Password Policies: do not store credentials in the Registry, and set an organizational policy that prohibits password storage in files. Use strong passphrases for private keys.
- Store it somewhere safer. Encrypt Sensitive Information: when possible, keep keys on separate cryptographic hardware instead of the local system.
- Shrink who can read it. Restrict File and Directory Permissions: limit file shares to specific directories and the users who need them. Privileged Account Management: if software must store credentials in the Registry, give those accounts limited permissions.
- Close known holes. Active Directory Configuration: remove vulnerable Group Policy Preferences. Update Software: apply patch KB2962486, which prevents credentials from being stored in GPPs.
- Limit the metadata service. Filter Network Traffic and Limit Access to Resource Over Network: restrict access to the Instance Metadata API, and use a properly configured WAF to help block SSRF against it.
- Keep history clean. Operating System Configuration: methods exist to prevent command history from being written to
.bash_history. - Train people. User Training: make sure developers and administrators understand the risk of plaintext passwords in configuration files left on endpoints and servers.
Check your own environment
- Do you scan source repositories, container images and file shares for secrets on a schedule, not once?
- Where do your builds and deployments keep credentials, and could any end up in logs?
- Can you list every private key on your servers and say who owns it?
- Is the metadata service restricted on your cloud instances?
Secrets scanning is the technical control that matches this technique best, because it looks in the same places an adversary would. The interactive demo shows how findings are surfaced and triaged.
Click through it at your own pace, or open it full screen.
Quick check
Why does this technique need no exploit?
The adversary reads credentials that were stored insecurely and are already on the system, so ordinary file or registry access is enough.
Which single habit removes the most exposure?
Searching for stored credentials before an attacker does, and removing or relocating what you find. MITRE lists this as the Audit mitigation.
Sources
- MITRE ATT&CK, Unsecured Credentials: https://attack.mitre.org/techniques/T1552
