Most credential theft does not need clever tooling: passwords, keys and tokens are already lying in files, registry values, shell history, metadata services, container APIs and chat channels, waiting to be read. MITRE ATT&CK tracks this as T1552 Unsecured Credentials in the Credential Access tactic (TA0006), across Windows, Linux, macOS, containers, network devices, IaaS, SaaS, Office suites and identity providers. This guide covers all eight sub-techniques in ATT&CK v20, the detection strategies and log sources MITRE maps to them, and the eleven mitigations. It is for security engineers, platform and cloud teams, detection engineers and anyone who owns secrets.
Key takeaways
- The fix is mostly hygiene, not detection. Every T1552 sub-technique depends on a credential stored somewhere it should not be; removing it, moving it to a secrets manager or making it short-lived beats any alert.
- Non-human credentials dominate. API keys, cloud access keys, private keys, service account tokens and connection strings are the material T1552 finds, and they rarely have MFA behind them.
- Eight places to look. Files, the Windows Registry, shell history, private keys, cloud instance metadata, Group Policy Preferences, container APIs and chat messages each have a specific scan and a specific hardening step.
- Scan continuously, block at the source. Secret scanning in repositories, pipelines, images, file shares and collaboration tools, with push protection where available, finds exposure before an attacker does.
- Assume a found secret is a used secret. Rotation and usage review, not deletion of the file, is the remediation.
How the attack works
ATT&CK describes T1552 as adversaries searching compromised systems to find and obtain insecurely stored credentials, in plaintext files, operating system or application repositories, and specialised artefacts such as private keys. It follows an initial foothold, and from a defender's view three conditions make it succeed:
- Storage: a credential is written in cleartext or in reversibly protected form where a process or user can read it.
- Reach: the attacker's foothold can read that location, because file, share, API or channel permissions are broader than needed.
- Value: the credential is long-lived and over-privileged, so finding it once is enough.
Breaking any one of the three defeats the technique. The v20 technique page (version 1.5) lists these sub-techniques:
| ID | Name (ATT&CK v20) | Typical exposed credential | Platforms |
|---|---|---|---|
| T1552.001 | Credentials In Files | Passwords and keys in config files, .env files, scripts, source code, backups | Containers, IaaS, Linux, macOS, Windows |
| T1552.002 | Credentials in Registry | Autologon and application passwords stored in registry values | Windows |
| T1552.003 | Shell History | Passwords and tokens typed on command lines, kept in ~/.bash_history, ~/.zsh_history or PowerShell history | Linux, macOS, Windows |
| T1552.004 | Private Keys | SSH keys, .pem, .pfx, .p12, .key files, exportable device keys | Linux, macOS, Network Devices, Windows |
| T1552.005 | Cloud Instance Metadata API | Temporary role credentials and user data scripts served at 169.254.169.254 | IaaS |
| T1552.006 | Group Policy Preferences | Passwords in GPP XML files in SYSVOL, decryptable with a published key | Windows |
| T1552.007 | Container API | Secrets and credentials returned by the Docker API or Kubernetes API, including container logs | Containers |
| T1552.008 | Chat Messages | Passwords, API keys and tokens pasted into email, Slack, Teams, Jira or similar | SaaS, Office Suite |
Where it shows up
- Code and build systems: hardcoded keys in repositories, CI variables echoed into logs, secrets baked into container image layers. See the Git Secret Scanning Guide.
- Web servers and file shares: configuration and
.envfiles served publicly or readable on broad shares. In the 230 Million AWS Cloud Environments Campaign, exposed.envfiles yielded 1,185 AWS access keys among other tokens, which were then used to enter and extort cloud accounts. - Cloud workloads: instance metadata services hand role credentials to anything on the instance that can make an HTTP request, including a vulnerable application. In the Capital One breach, a misconfigured web application firewall exposed its role's temporary credentials from the metadata service, and the over-broad role allowed bulk reads from S3.
- Windows estates: autologon passwords in the registry and legacy GPP files in SYSVOL that any domain user can read. See the Local Administrator Password Solution (LAPS) Guide for the supported way to manage local admin passwords.
- Kubernetes and Docker: service account tokens mounted into pods, Secrets readable through broad RBAC, unauthenticated Docker daemons. See the Kubernetes Service Account Token Guide.
- Collaboration tools: credentials shared in chat or tickets, then readable by anyone in the channel or by any integration with message-read scopes.
Impact
- Lateral movement without exploits: a found credential is a valid login, so activity blends with normal use and often falls under MITRE ATT&CK T1078 Valid Accounts.
- Cloud account takeover: cloud access keys and role credentials give direct API access to storage, compute and identity services, often enough to add further persistence (see the MITRE ATT&CK T1098 Account Manipulation Guide).
- Domain compromise: GPP and registry passwords frequently belong to local administrator or service accounts reused across many hosts.
Detection
ATT&CK v20 maps a detection strategy to the parent and every sub-technique. Two kinds of signal matter: access to a credential store by an unexpected process or identity, and use of a credential from an unexpected place shortly afterwards.
| Technique | ATT&CK detection strategy | Events and log sources to collect |
|---|---|---|
| T1552 | DET0412 Detect Access or Search for Unsecured Credentials Across Platforms | Sysmon 11, 13, 14; Security 4688; auditd reads of history, /etc/shadow and key directories; macOS reads of ~/Library/Keychains; CloudTrail GetSecretValue; reads of /run/secrets by non-entrypoint processes; network device config dumps |
| T1552.001 | DET0307 Detect Access to Unsecured Credential Files | Sysmon 1 and 11, then Security 4624 or 4648 using the found account; auditd reads of config files followed by SSH authentication; reads of ~/.aws/credentials followed by role assumption |
| T1552.002 | DET0250 Credential Discovery via Windows Registry Enumeration | Sysmon 1 (command lines querying HKLM or HKCU for "password", "cred" or "logon"), Sysmon 13 and 14; EDR registry rules |
| T1552.003 | DET0385 Access and Parsing of .bash_history Files | auditd watches on history files, especially reads by non-shell processes after su or sudo; macOS Endpoint Security open events |
| T1552.004 | DET0549 Suspicious Access to Private Key Files and Export Attempts | Sysmon 1 and 11, Security 5145 (share access); auditd openat on key paths; macOS reads of id_rsa, *.pem, *.p12; network device syslog for key export commands |
| T1552.005 | DET0001 Detect Access to Cloud Instance Metadata API | VPC flow logs to 169.254.169.254; eBPF syscall telemetry from containers; CloudTrail for the instance's role being used from outside its own network |
| T1552.006 | DET0381 Access and Decryption of GPP Credentials in SYSVOL | Security 5145 on SYSVOL XML files; Sysmon 1 and 11; PowerShell script block logging for XML parsing and AES decryption logic |
| T1552.007 | DET0198 Abuse of Container APIs for Credential Access | Kubernetes API server audit for get, list or watch on secrets and serviceaccounts, exec into pods followed by secret reads; Docker API log and inspect calls by non-admin users |
| T1552.008 | DET0111 Detect Unsecured Credentials Shared in Chat Messages | Microsoft 365 unified audit message and attachment events matching credential patterns; Slack message and file events; OAuth apps requesting message-read scopes |
Detection engineering notes:
- Use canaries: plant decoy credentials in config files, the registry or a wiki; any use is a high-fidelity alert.
- Watch credential use, not only access: alert when a workload role's credentials are used from an IP outside the workload's network, or when a key that has sat idle becomes active.
- Coverage of the exposure itself: secret scanners are a detection control for the precondition. See the Secrets Scanning Buyer's Guide and the Secret Sprawl Measurement Guide.
Metrics that show it is working:
- Open secret-scanning findings by location (repositories, images, shares, chat) and median time to rotate a confirmed live secret.
- Percentage of cloud instances that accept only token-based metadata requests.
- Count of GPP files with a password attribute in SYSVOL (target zero) and of hosts with autologon passwords in the registry.
- Proportion of workloads using short-lived or federated credentials instead of static keys.
- Push protection bypasses per month and the share reviewed within one working day.
Prevention and hardening
ATT&CK lists eleven mitigations for T1552. The table maps them to sub-techniques and concrete actions.
| Mitigation | Applies to | Concrete action |
|---|---|---|
| M1047 Audit | .001, .002, .004, .006, .008 | Proactively search files, the registry, SYSVOL, key locations and chat for credentials and remediate; MITRE suggests patterns such as "password=" for chat |
| M1027 Password Policies | .001, .002, .004 | Policy that prohibits storing passwords in files or the registry; strong passphrases on private keys |
| M1022 Restrict File and Directory Permissions | .001, .004 | Limit shares to needed directories and users; tight permissions on key folders; set nonexportable when generating RSA keys on Cisco devices |
| M1041 Encrypt Sensitive Information | .004 | Keep keys in hardware: TPM-backed keys on Windows, HSMs or cloud KMS for signing and service keys |
| M1035 Limit Access to Resource Over Network | .005, .007 | Host firewall rules limiting which processes or containers reach the metadata API; Docker and Kubernetes APIs only over TLS with authentication, via Unix sockets or restricted IP ranges |
| M1037 Filter Network Traffic | .005 | WAF rules against server-side request forgery to the metadata endpoint |
| M1042 Disable or Remove Feature or Program | .005 | Disable unused metadata services and insecure versions of them |
| M1026 Privileged Account Management | .002, .007 | Least privilege for accounts whose credentials must be stored; disable Kubernetes service account tokens where a pod does not call the API |
| M1018 User Account Management | .007 | RBAC on container APIs; no wildcard permissions or system:masters; RoleBindings rather than ClusterRoleBindings |
| M1015 Active Directory Configuration / M1051 Update Software | .006 | Apply MS14-025 (KB2962486) and remove existing GPP passwords |
| M1028 Operating System Configuration | .003 | Shell configuration that keeps secrets out of history files |
| M1017 User Training | .001, .008 | Teach developers and admins why plaintext secrets in configs and chat are dangerous and where the approved store is |
Sub-technique specifics
- Cloud metadata (T1552.005): on AWS, IMDSv2 requires a session token obtained by a PUT request, and the PUT response has an IP hop limit of 1 by default, which blocks token retrieval through an extra network hop such as a container bridge. Configure instances to require IMDSv2 so token-less requests fail, and set the account default for new instances.
- Group Policy Preferences (T1552.006): Microsoft's MS14-025 bulletin (CVE-2014-1812) removes the ability to set passwords in GPP extensions such as local users and groups, mapped drives, services, scheduled tasks and data sources, but states it does not remove existing GPOs. Search SYSVOL for XML files containing a
cpasswordattribute, delete them and rotate the affected accounts, then use Windows LAPS. - Containers (T1552.007): never expose the Docker daemon on an unauthenticated TCP port; set
automountServiceAccountToken: falsefor workloads that do not need the API; grant Secret access by name withgetonly. See the Kubernetes RBAC Guide. - Files and code (T1552.001): move secrets to a vault or cloud secrets manager and inject them at runtime; prefer workload identity federation over static keys. In Google Cloud, enforce
iam.managed.disableServiceAccountKeyCreation. See the Secrets Management Guide. - Source control: GitHub push protection blocks pushes that contain detected secrets from the command line, web UI, uploads and API; bypasses with a reason create an alert and an audit log entry, and admins can restrict bypass to named reviewers.
- Chat (T1552.008): enable data loss prevention or secret detection on collaboration tools, review OAuth apps with message-read scopes, and give people a sanctioned one-time sharing method.
Rollout order
- Baseline: run scanners in report-only mode across repositories (full history), container registries, file shares, SYSVOL, endpoint registry and chat exports. Classify findings as live or dead by validating against the issuer where the scanner supports it.
- Rotate live secrets first: rotate, then remove from the source, then review the credential's usage logs for the exposure window. See the Secrets Rotation Runbook Template.
- Close the structural gaps: require IMDSv2, remove GPP passwords, disable unneeded token automounting, restrict Docker sockets. Pilot each on one account, OU or cluster, and roll back by reverting the setting if an application breaks.
- Block new exposure: turn on push protection and pipeline scanning in blocking mode, with a reviewed bypass path.
- Detect what remains: deploy the access and use detections in the table and plant canary credentials.
Choosing where to start
If you run mostly cloud workloads, start with metadata hardening, static key elimination and repository scanning; those carry the highest blast radius. If you run a large Active Directory estate, the SYSVOL and registry sweep is quick and often finds domain-wide passwords. Small organisations get most value from push protection, a secrets manager and a one-off sweep; large ones need continuous scanning of all eight locations with an owner per finding.
Lessons from incidents
- Servable config files: the 230 Million AWS Cloud Environments Campaign came down to
.envfiles served by web applications and long-lived, over-privileged keys inside them. Deny web access to dotfiles and replace static keys. - Metadata plus over-privilege: the Capital One breach combined metadata credential exposure with a role that had far more data access than a firewall needed. Token-based metadata access and least-privilege roles each would have reduced the impact.
- Deleting the file but not the secret: a key removed from the latest commit stays in history and clones; rotate it.
Framework mapping
| Framework | Relevant items |
|---|---|
| NIST SP 800-53 Rev. 5 | IA-5 Authenticator Management and IA-5(7) No Embedded Unencrypted Static Authenticators; SC-28 Protection of Information at Rest; SC-12 Cryptographic Key Establishment and Management; AC-6 Least Privilege; SI-4 System Monitoring |
| NIST CSF 2.0 | PR.AA-01 identities and credentials managed; PR.DS-01 data at rest protected; DE.CM-01 networks monitored; DE.CM-03 technology usage monitored |
| ISO/IEC 27001:2022 Annex A | 5.17 Authentication information; 8.24 Use of cryptography; 8.15 Logging; 8.16 Monitoring activities |
| CIS Controls v8.1 | Control 3 Data Protection; Control 5 Account Management; Control 16 Application Software Security |
| OWASP Non-Human Identities Top 10 2025 | NHI2:2025 Secret Leakage; see the OWASP NHI Top 10 NHI2 Secret Leakage Guide |
Practitioner checklist
- Scan repositories with full history, container images, file shares, wikis and chat for secrets, and validate which are live.
- Rotate every live exposed secret and review its usage for the exposure window.
- Enable push protection and pipeline scanning in blocking mode with reviewed bypasses.
- Require token-based instance metadata access and least-privilege workload roles.
- Remove all GPP passwords from SYSVOL and registry autologon passwords; manage local admin passwords with LAPS.
- Disable Kubernetes service account token automounting where unused and restrict Secret list and watch.
- Store private keys in TPMs, HSMs or KMS and protect remaining key files with strict permissions.
- Deploy the ATT&CK v20 access detections and plant canary credentials in likely search locations.
Standards and references
- MITRE ATT&CK: Unsecured Credentials (T1552)
- MITRE ATT&CK: Cloud Instance Metadata API (T1552.005)
- OWASP: Non-Human Identities Top 10 2025, NHI2 Secret Leakage
- AWS: Use the Instance Metadata Service to access instance metadata
- Microsoft: Security Bulletin MS14-025, Vulnerability in Group Policy Preferences
- GitHub Docs: About push protection
- Google Cloud: Restricting service account usage
- NIST: SP 800-53 Rev. 5
Related NHI Mgmt Group resources: Git Secret Scanning Guide · ITDR Guide · OWASP NHI Top 10 NHI2 Secret Leakage Guide · MITRE ATT&CK T1098 Account Manipulation Guide · Secrets Management Guide