Resetting a password or disabling an account does not remove the tickets, tokens and cached credentials that were issued before the change, and attackers who hold those copies keep their access. MITRE D3FEND names the countermeasure Authentication Cache Invalidation (D3-ANCI) and defines it as "Removing tokens or credentials from an authentication cache to prevent further user associated account accesses." It sits under the Evict tactic as a child of Credential Eviction (D3-CE), alongside Account Locking and Credential Revocation. This card explains where authentication caches live, which ATT&CK techniques D3FEND relates to D3-ANCI, how invalidation is done on Windows, in cloud identity providers and cloud IAM, and how to prove the caches are empty. It is written for incident responders and identity administrators running eviction after a credential compromise.
Key takeaways
- Caches outlive the change. Kerberos tickets, refresh tokens, cloud session credentials and cached logon verifiers stay usable after a password reset or account disable until they expire or are removed.
- D3FEND links it to credential theft and reuse. D3-ANCI deletes Credential, so D3FEND relates it to Unsecured Credentials (T1552), Forge Web Credentials (T1606), Additional Cloud Credentials (T1098.001) and, by inference, to credential dumping, token theft and replay; these relations are inferred.
- There are caches on both sides. D3FEND asks whether cached credentials are only on the local host or persisted to a remote server. Responders need to clear the client copy and invalidate the server-side record that accepts it.
- Each cache has its own command.
klist purgefor Kerberos, session revocation for an identity provider, a time-based deny for cloud role sessions; no single action clears them all. - Lifetimes are the backstop. Where a cache cannot be cleared directly, the token lifetime sets the worst-case exposure, so short lifetimes are part of this control.
D3-ANCI at a glance
| Attribute | Value |
|---|---|
| D3FEND ID | D3-ANCI (d3f:AuthenticationCacheInvalidation) |
| Tactic | Evict |
| Parent technique | Credential Eviction (D3-CE) |
| Digital artefact | Credential (D3FEND relation: deletes Credential) |
| Example D3FEND names | Windows Credential Management API |
| Caches in scope | Kerberos ticket caches, cached domain logon verifiers, identity provider refresh tokens and sessions, cloud CLI and SDK credential caches, application credential stores |
| What it does not do | Stop new sign-ins with a still-valid password, or remove attacker-created credentials such as added keys |
| Main limitation | Copies already exfiltrated to attacker machines can only be defeated server-side, by revocation or expiry |
How it works
D3FEND explains the mechanism in a sentence: applications can cache user authentication credentials for server connections, and if a cached credential exists the user is not usually prompted again. That convenience is what attackers exploit after theft, and what responders must undo. D3FEND cites two patents: Dell's on secure caching of server credentials and IMVU's on an actively invalidated client-side cache, which describes the server telling clients that cached entries are no longer valid.
In practice there are three forms of invalidation.
- Local purge: delete the cached item on the host, for example the Kerberos ticket cache of a logon session or a cloud CLI credential cache. Effective only for copies on hosts you control.
- Server-side invalidation: make the issuer reject everything issued before a point in time, for example revoking a user's refresh tokens or denying role sessions by issue time. Effective against copies on attacker machines.
- Prevention by policy: limit what is cached in the first place, for example the number of cached domain logons on a host, so there is less to steal and less to clear.
ATT&CK techniques D3FEND relates to D3-ANCI
Relationship type: inferred only. D3FEND derives each row through the Credential artefact or one of its sub-artefacts, and labels the mappings "inferred, experimental" (D3FEND 1.6.0, checked November 2026). D3FEND lists Keychain under an ID that ATT&CK has revoked; its ATT&CK v20 successor is T1555.001. Each ID was checked against ATT&CK v20.
| ATT&CK ID | Technique | What invalidation does to it |
|---|---|---|
| T1552 | Unsecured Credentials | Credentials found in files or caches stop working once the server-side record is invalidated |
| T1606, T1606.001 | Forge Web Credentials, Web Cookies | Server-side session invalidation rejects cookies issued or forged against the old session state |
| T1098.001 | Additional Cloud Credentials | Session invalidation ends current use; the added credential itself must be deleted separately |
| T1003.003, T1003.005, T1003.008 | NTDS, Cached Domain Credentials, /etc/passwd and /etc/shadow | Limiting and clearing cached logons reduces what dumping yields; reset passwords for anything already dumped |
| T1110.001, T1110.002, T1110.003 | Password Guessing, Password Cracking, Password Spraying | Cracked cached verifiers are worthless once the password and caches are changed |
| T1558.001 | Golden Ticket | Purging caches removes forged tickets on known hosts; the krbtgt reset is what invalidates them everywhere |
| T1539, T1528 | Steal Web Session Cookie, Steal Application Access Token | Revoking sessions and refresh tokens cuts off stolen copies |
| T1550.001, T1550.004 | Use Alternate Authentication Material: Application Access Token, Web Session Cookie | Replay fails once the token or session is invalidated server-side |
| T1134.001, T1134.002, T1134.003 | Token Impersonation/Theft, Create Process with Token, Make and Impersonate Token | Ending the logon sessions that hold stolen tokens removes them from the host |
| T1555.001 | Keychain | Entries cleared from the keychain cannot be extracted later |
Deeper treatment of the attacker side is in the MITRE ATT&CK T1552 Unsecured Credentials Guide, the MITRE ATT&CK T1550 Use Alternate Authentication Material Guide and the MITRE ATT&CK T1606 Forge Web Credentials Guide.
Where it is implemented
Platforms are listed alphabetically. Each row uses the platform's own documented action.
| Cache | Documented invalidation action | Scope and caveat |
|---|---|---|
| AWS IAM role sessions | Role Revoke active sessions, which attaches the inline policy AWSRevokeOlderSessions denying all actions to sessions issued before the revocation time (or a custom deny on aws:TokenIssueTime) | Server-side, so it defeats copies held elsewhere. Does not affect IAM user long-term keys. Legitimate users clear the AWS CLI cache (~/.aws/cli/cache) and obtain new credentials |
| Microsoft Entra ID sessions | Revoke sessions on the user, or Revoke-MgUserSignInSession | Revokes refresh tokens. Issued access tokens stay valid until expiry, one hour by default; continuous access evaluation shortens this for capable applications. Application session cookies are ended by each application |
| Windows cached domain logons | Policy "Interactive logon: Number of previous logons to cache (in case domain controller is not available)"; default 10, values 0 to 50 | Microsoft's guidance gives 0 as the countermeasure and suggests 2 for end-user computers; 0 prevents sign-in when no domain controller is reachable |
| Windows Credential Manager | Remove stored entries through the Windows Credential Management API, which D3FEND names as its example | Local to the user profile; stored entries for servers the attacker reached should be removed and the passwords changed |
| Windows Kerberos ticket cache | klist purge, with -li to target a logon session (for example klist purge -li 0x3e7); klist sessions lists logon sessions | Local only. Tickets already copied off the host remain valid until expiry; the default maximum user ticket lifetime is 10 hours |
Kerberos caches on Linux hosts, browser cookie stores and application-specific token stores follow the same pattern: find the local copy, clear it, and make sure the issuer no longer accepts it.
Where identity fits
Non-human identities are heavy users of authentication caches. CI runners keep cloud credentials between jobs, service hosts keep Kerberos tickets for service accounts, and developer machines keep CLI tokens for cloud and code platforms. After an NHI compromise, invalidate the issuer side first (role session revocation, token revocation) and then clear the caches on every runner and host that used the identity. See the Workload Identity Compromise Response Playbook and Credential Rotation at Scale.
Implementation steps
- List the caches. For each identity type (user, admin, service account, workload role), list where its credentials are cached: hosts, browsers, CLIs, CI runners, identity provider sessions and applications.
- Reduce caching in advance. Set cached domain logons low on servers and admin workstations, keep token and ticket lifetimes short for privileged identities, and enable continuous access evaluation where supported.
- Script the invalidation actions. Prepare and test, per platform, the server-side revocation and the local purge, including the admin rights each needs.
- In an incident, act server-side first. Change or disable the credential, revoke sessions and refresh tokens, deny old role sessions, then purge local caches on affected hosts. Record the time of each step.
- Handle forged material separately. If Golden Tickets or forged cookies are suspected, the signing secret (krbtgt, a token signing key) must be rotated; cache invalidation alone does not stop forgery. See the krbtgt account page.
- Warn the business. AWS notes that its role session deny applies to every user of the role and can lose unsaved work; schedule where the incident allows.
- Roll back. Revocation itself has no rollback: users and workloads re-authenticate. Remove a time-based deny only when the role's attacker sessions have expired and new credentials are in use.
How to verify it works
- Replay test: in a test tenant, capture a refresh token or role session for a test identity, run the invalidation, and confirm the captured credential is rejected.
- Post-invalidation activity search: search identity provider sign-in logs, cloud API logs and DC logs for activity by the identity after the invalidation time; activity beyond the access token or ticket lifetime means a cache was missed.
- Host check: on affected hosts, list remaining tickets and logon sessions (
klist,klist sessions) after the purge. - Policy check: confirm the cached logons setting and token lifetimes on servers and admin workstations match the standard.
| Metric | Example target (NHI Mgmt Group suggestion, not a standard) | Why it matters |
|---|---|---|
| Activity by evicted identities after maximum token lifetime | Zero | Direct proof the caches no longer work |
| Identity types with a scripted invalidation runbook | 100% of privileged and workload identities | No runbook means a slow, partial eviction |
| Admin workstations and servers with low cached logon counts | Rising to full coverage | Less material to dump and clear |
| Time from decision to server-side revocation | Under 15 minutes | Sets the exposure for stolen copies |
Limits, bypasses and failure patterns
- Purging only the local cache: copies already on the attacker's machine keep working; server-side revocation is the step that matters for them.
- Revoking refresh tokens and forgetting access tokens: issued access tokens stay valid for their lifetime unless the application supports continuous evaluation.
- Clearing caches but leaving the signing key: forged tickets and tokens are re-created at will until the signing secret is rotated.
- Missing long-term keys: session denies do not affect IAM user access keys or attacker-added credentials (T1098.001); delete those separately.
- Forgetting applications: applications that keep their own sessions after SSO sign-in must end them through their own controls. The Global Token Revocation Guide covers standards that propagate logout.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 Authenticator Management | Changing and invalidating authenticators after compromise |
| NIST SP 800-53 Rev 5 | AC-12 Session Termination, IR-4 Incident Handling | Ending sessions and containment |
| NIST CSF 2.0 | PR.AA-01, RS.MI-01 | Managing credentials; containing incidents |
| MITRE D3FEND | D3-CE, D3-ANCI | Parent and technique |
Related countermeasures
- Account Locking (D3-AL): stops new sign-ins, which cache invalidation complements by ending existing ones. See MITRE D3FEND Guide for the eviction family.
- Credential Revocation (D3-CR): the other Credential Eviction child. Password Rotation (D3-PR), a Credential Hardening technique in D3FEND, covers shared secrets.
- Session Termination (D3-ST): ends active sessions on hosts and applications.
- Token revocation standards: see the OAuth Token Introspection and Revocation Guide and CAEP and Continuous Access Evaluation.
Practitioner checklist
- List every authentication cache per identity type before an incident.
- Set low cached logon counts on servers and admin workstations.
- Keep ticket and token lifetimes short for privileged and workload identities.
- Revoke server-side first, then purge local caches.
- Rotate signing secrets when forged tickets or tokens are suspected.
- Delete attacker-added keys and credentials separately from cache invalidation.
- Search for activity after the invalidation time and keep the result as evidence.
- Clear CI runner and CLI caches for compromised workload identities.
Standards and references
- MITRE D3FEND: Authentication Cache Invalidation (D3-ANCI)
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls (IA-5, AC-12)
- Microsoft Learn: klist
- Microsoft Learn: Interactive logon, number of previous logons to cache
- Microsoft Learn: Maximum lifetime for user ticket
- Microsoft Learn: Revoke user access in an emergency in Microsoft Entra ID
- AWS: Revoke IAM role temporary security credentials
Related NHI Mgmt Group resources: Identity Incident Response Playbook · Global Token Revocation Guide · krbtgt account · T1003 OS Credential Dumping · MITRE D3FEND Guide