ATT&CK Credential Access Tactic (TA0006) Guide: Detecting Theft of Passwords, Tokens and Keys

Stolen credentials let an attacker stop looking like an attacker, and the Credential Access tactic (TA0006) in MITRE ATT&CK covers every way they get them. ATT&CK v20 describes the tactic as the adversary "trying to steal account names and passwords", but its 18 techniques reach well beyond passwords: Kerberos tickets, session cookies, OAuth tokens, certificates, cloud secrets and the instance metadata service all appear. This page is the hub for that tactic. It groups the techniques by what is stolen, shows the v20 detection strategies and log sources that catch them, and sets out the hardening that removes whole technique families. It links out to the deeper technique guides rather than repeating them, and is written for SOC analysts, identity engineers and detection teams.

Key takeaways

• Credential Access is an identity problem with an endpoint component. Half of the techniques target identity systems directly (Kerberos, MFA, SSO tokens, certificates, cloud secrets) rather than the host.
• Keylogging and browser stores dominate the procedure data. In the v20 dataset Keylogging (T1056.001) has 155 recorded uses, Credentials from Web Browsers (T1555.003) 93 and LSASS Memory (T1003.001) 79.
• Machine credentials are first-class targets. T1552 Unsecured Credentials, T1555.006 Cloud Secrets Management Stores, T1552.005 Cloud Instance Metadata API and T1528 Steal Application Access Token are about non-human identities.
• Platform controls remove whole families. Credential Guard, LSA protection, phishing-resistant MFA and short-lived tokens defeat techniques that detection alone only spots after the fact.
• Assume theft and shorten the value. Rotation, token binding, conditional access and fast revocation limit what a stolen secret is worth.

How the attack works

Credential theft usually follows execution and often precedes lateral movement and privilege escalation. The adversary harvests whatever material is reachable from the current foothold, then uses it through T1078 Valid Accounts or T1550 Use Alternate Authentication Material. The 18 techniques fall into five groups.

For the detail on each family use the technique guides: the Credential Dumping Guide, MITRE ATT&CK T1552 Unsecured Credentials Guide, T1555 Credentials from Password Stores Defensive Guide, MITRE ATT&CK T1528 Steal Application Access Token Guide, MITRE ATT&CK T1556 Modify Authentication Process Guide and MITRE ATT&CK T1606 Forge Web Credentials Guide.

Where it shows up

• Infostealers on unmanaged devices: malware on personal or contractor machines harvests browser passwords and cookies (T1555.003, T1539), which are sold and reused against corporate SaaS. See the Infostealer Threat Guide.
• Active Directory intrusions: LSASS dumping, Kerberoasting of service accounts with weak passwords, DCSync and NTDS extraction once domain admin is reached. See the Kerberos Security Guide.
• Identity provider attacks: password spraying against cloud sign-in, MFA push bombing and adversary-in-the-middle phishing kits that capture session cookies after MFA. See the MFA Fatigue and Bypass Guide.
• Cloud and DevOps: access keys in repositories and CI logs, secrets bulk-read from AWS Secrets Manager or Azure Key Vault, and role credentials taken from the instance metadata service through a server-side request forgery.
• Certificate services: misconfigured AD CS templates let a low-privileged user request a certificate that authenticates as someone else (T1649). See the AD CS Security Guide.

Impact

Valid credentials convert a noisy intrusion into authorised activity. With them the adversary can sign in over VPN and SaaS without malware, move laterally with administrative rights, persist after the original foothold is cleaned, and reach data and backups. Credentials from domain controllers (NTDS, the KRBTGT key) or federation signing keys compromise every account in the domain or tenant, and recovery means resetting secrets at scale. Stolen machine credentials are especially durable: API keys and service account passwords are often unrotated for years, so one leak can stay usable long after the incident.

Detection

Each v20 technique carries a detection strategy with platform analytics. The most useful for this tactic are summarised below.

Additional analytics worth building

• Kerberoasting: Security Event ID 4769 service ticket requests with encryption type 0x17 (RC4) for accounts with SPNs, especially many SPNs requested by one user in a short window.
• DCSync: directory replication requests (Event ID 4662 with replication rights) from hosts that are not domain controllers.
• Honey credentials: decoy accounts and fake keys planted in scripts or memory, alerting on any use (D3FEND D3-DUC Decoy User Credential).
• Secrets in code: secret scanning on commits, CI logs and ticket systems, treating every hit as a potential exposure.

Metrics that show it is working

• Protection coverage: percentage of Windows endpoints with Credential Guard and LSA protection running (WinInit Event ID 12 confirms LSASS started as a protected process).
• Phishing-resistant MFA coverage: share of workforce and administrator sign-ins using FIDO2 or certificate-based authentication.
• Service account hygiene: count of SPN accounts with RC4 enabled or passwords older than 12 months.
• Secret exposure dwell time: median time from a detected leaked secret to its revocation.
• Detection test pass rate: share of credential access atomic tests that raise an alert within 15 minutes.

Prevention and hardening

Phased rollout

1. Inventory: list privileged accounts, service accounts with SPNs, cloud access keys and where secrets live in code and pipelines.
2. Audit mode: enable LSA protection audit and the attack surface reduction rule "Block credential stealing from the Windows local security authority subsystem" in audit; review CodeIntegrity and ASR events with application owners.
3. Pilot: enforce Credential Guard, LSA protection and phishing-resistant MFA on IT and administrator devices first.
4. Broad enforcement: extend in rings; convert service accounts to gMSA, rotate KRBTGT twice on a planned schedule, replace static cloud keys.
5. Rollback: keep a tested path to disable each control for one ring (Credential Guard default enablement is applied without UEFI lock, so it can be turned off remotely; a UEFI-locked LSA protection setting cannot be reverted by registry). Choose the lock deliberately.

Decision guidance

• Prevention versus detection: invest in prevention first for credential dumping and phishing (Credential Guard, FIDO2), because by the time dumping is detected the secrets may already be gone.
• Small organisations: cloud identity with phishing-resistant MFA, LAPS and a password manager cover most of the risk with little infrastructure.
• Large organisations: prioritise tier 0 (domain controllers, AD CS, federation servers, IdP admin roles) and the non-human identities that hold standing access.

Framework mapping

Lessons from incidents

• Infostealer credentials without MFA: in the Snowflake customer breaches (2024), Mandiant found at least 79.7 per cent of the accounts used had prior exposure in infostealer logs, some from infections dating to 2020; the accounts had no MFA, credentials had not been rotated and there were no network allow lists. About 165 organisations were notified.
• Synced browser passwords and push fatigue: in the Cisco breach (May 2022), a corporate password saved in a browser and synced to a personal Google account was taken over, then repeated vishing calls and MFA pushes produced an approval. The attacker enrolled new MFA devices and later attempted to dump NTDS.

Common failure patterns

• MFA everywhere except where it matters: legacy protocols, service accounts and data platforms left on single-factor authentication.
• Push MFA without number matching: fatigue attacks only need one tired approval.
• Kerberoastable service accounts: human-chosen passwords on accounts with SPNs, still accepting RC4.
• Personal browser sync on corporate credentials: credentials leave managed control entirely.
• Revocation that misses tokens: resetting a password while refresh tokens, sessions and API keys stay valid.

Practitioner checklist

• Confirm Credential Guard and LSA protection are running across the Windows fleet and track exceptions.
• Alert on non-standard processes accessing LSASS (Sysmon Event ID 10) and on DCSync from non-DC hosts.
• Hunt for RC4 service tickets (Event ID 4769, type 0x17) and move SPN accounts to gMSA with AES.
• Roll out phishing-resistant MFA to administrators, then all staff; enable number matching for remaining push.
• Block corporate credential sync to personal browser profiles and limit access from unmanaged devices.
• Scan code, CI logs and chat for secrets and revoke every exposed secret, not just delete it.
• Replace static cloud keys with workload identity and alert on bulk GetSecretValue calls.
• Plant decoy credentials and alert on any use.
• Include token and session revocation in the credential compromise playbook.

Standards and references

• MITRE ATT&CK: Credential Access (TA0006)
• MITRE ATT&CK: OS Credential Dumping (T1003)
• MITRE ATT&CK: Steal or Forge Kerberos Tickets (T1558)
• Microsoft Learn: Credential Guard overview
• Microsoft Learn: Configure added LSA protection
• Microsoft Learn: Attack surface reduction rules reference
• NIST: SP 800-53 Rev. 5
• NIST: Cybersecurity Framework 2.0

Related NHI Mgmt Group resources: Credential Dumping Guide · MITRE ATT&CK T1078 Valid Accounts Guide · Session Hijacking and Cookie Theft Guide · Password Spraying and Credential Stuffing Defence Guide · ATT&CK Execution Tactic Guide