D3-CCSA Credential Compromise Scope Analysis: Scoping Which Credentials an Attacker Exposed

When an attacker dumps credentials on one host, the hard question is not "was this machine compromised?" but "whose credentials are now in the attacker's hands?". D3-CCSA Credential Compromise Scope Analysis is the MITRE D3FEND countermeasure that answers it: D3FEND defines it as "determining which credentials may have been compromised by analyzing the user logon history of a particular system." It sits in the Detect tactic, under the parent technique User Behavior Analysis, and analyses the Credential artefact. This card explains the mechanism, the ATT&CK techniques D3FEND relates it to, how to build and verify it, and where it falls short. It is written for detection engineers, incident responders and identity teams who have to turn "mimikatz ran on SRV-APP-07" into a precise list of accounts, service identities and tokens to reset.

Key takeaways

• It is a scoping analytic, not an alarm. D3-CCSA runs after a credential theft signal and produces the list of identities whose secrets were exposed on that system.
• Logon type decides exposure. On Windows, interactive, RemoteInteractive, NewCredentials, Batch and Service logons leave reusable credentials in LSASS memory; plain network logons generally do not.
• Look beyond memory. Cached domain logons, LSA secrets for services and scheduled tasks, the SAM hive, NTDS.dit on domain controllers and /etc/shadow on Linux all widen the blast radius.
• Service accounts are usually the biggest find. Batch and service logons store the password as an LSA secret on disk, so non-human identities on a compromised server should be presumed exposed.
• The output drives containment. The scoped list feeds password resets, token and session revocation and heightened monitoring for later use of those identities elsewhere.

D3-CCSA at a glance

For the wider family of behaviour analytics this belongs to, see D3FEND's parent technique User Behavior Analysis, and for the framework itself the MITRE D3FEND Guide.

How it works

D3FEND's knowledge base article for D3-CCSA describes two places credentials sit on a host, and the analytic reasons about both.

Credentials in memory

On Windows, the Local Security Authority Subsystem Service (lsass.exe) holds credential material for logon sessions. The D3FEND article puts it plainly: once a dumper reads lsass.exe memory, "the credentials of every account logged on since boot are potentially compromised." MITRE's Cyber Analytics Repository encodes the same idea as CAR-2015-07-001, All Logins Since Last Boot. Its pseudocode takes a target host and an event time, finds the most recent boot before that time, keeps login events on that host between boot and the event, and outputs the unique users. CAR flags one caveat worth carrying into your own version: the first and last login times bracket activity that may be intermittent, so they "should not be considered a duration".

Not every logon leaves reusable material behind. Microsoft's reference on administrative tools and logon types states that whether credentials are exposed on the target "depends primarily on the windows logon type used by the connection method", and defines reusable credentials as LM and NT hashes, Kerberos TGTs and, where applicable, plaintext passwords held in LSASS on the destination.

PsExec with explicit credentials creates both network and interactive sessions and is listed by Microsoft as exposing credentials. The source computer of any remote administration always holds the administrator's credentials, which is why the scope must include the workstations admins connected from, not only the server they connected to.

Credentials on disk

The second half of the D3FEND article covers secrets that survive reboots and so are outside "since last boot" logic:

• Cached domain logons: held under HKEY_LOCAL_MACHINE\SECURITY\Cache so users can log on when no domain controller is reachable. Microsoft's policy "Interactive logon: Number of previous logons to cache (in case domain controller is not available)" accepts 0 to 50, and the effective default on member servers and client computers is 10 logons. Any of those cached users is in scope if the hive was read.
• Local accounts: the SAM hive (%systemroot%\System32\Config\SAM) holds local account hashes, including any shared local administrator password.
• Domain controllers: %systemroot%\ntds\ntds.dit holds every domain account. If it was read, scope is the entire domain, including krbtgt.
• Linux: D3FEND names /etc/shadow and reads of process memory through /proc as the equivalents.

Where identity fits

D3-CCSA is an identity control as much as a forensic one, and non-human identities often dominate the result. Services and scheduled tasks log on as Batch or Service, so their passwords sit in LSASS and as LSA secrets on disk: every service account configured on a dumped server should be treated as exposed even if no human logged on since boot. Shared local administrator passwords put every machine with the same password in scope. On hosts that run automation, the analysis should also list API keys, cloud access keys and tokens readable on that system, since ATT&CK T1552 Unsecured Credentials covers secrets in files that no logon event will show. The containment step that follows is credential rotation at scale; see Credential Rotation at Scale and the Identity Incident Response Playbook.

ATT&CK techniques D3FEND relates to D3-CCSA

Relationship type: inferred only. D3FEND lists no direct ATT&CK mapping for D3-CCSA; every row below is inferred through a shared digital artefact (checked November 2026).

D3FEND does not hand-map D3-CCSA to ATT&CK. Every row below is an inferred relationship that D3FEND derives through a shared digital artefact: D3-CCSA analyzes Credential, so ATT&CK techniques that act on a Credential, or on one of its sub-artefacts such as Password or Access Token, are related to it. The relation column shows which. D3FEND also lists Keychain under an ID that ATT&CK has since revoked; its ATT&CK v20 successor is T1555.001. Each ID was checked against ATT&CK v20. D3-CCSA does not prevent any of these techniques: it scopes the damage once one is detected, and the scoped list then constrains what the attacker can do with the material.

Defensive detail for the techniques themselves lives in the T1003 OS Credential Dumping, MITRE ATT&CK T1558 Steal or Forge Kerberos Tickets Guide, MITRE ATT&CK T1550 Use Alternate Authentication Material Guide, MITRE ATT&CK T1134 Access Token Manipulation and MITRE ATT&CK T1098.001 Account Manipulation pages.

Where it is implemented

D3-CCSA is an analysis step rather than a product feature. It is usually built as a SIEM query or notebook over centralised logon events, run from an EDR investigation console, added as a SOAR enrichment step, or provided by identity threat detection and response (ITDR) tooling. The data sources are listed in the at a glance table above.

Implementation steps

1. Centralise the inputs. Collect Windows Security event 4624 (with LogonType, TargetUserName, TargetUserSid, TargetLogonId, IpAddress, WorkstationName, ProcessName), boot or startup events, Linux login records and identity provider sign-in logs into the SIEM with consistent host and time fields. Without boot times you cannot bound "since last boot".
2. Build the core query. Implement the CAR-2015-07-001 logic: given host and event time, find the last boot before that time, select logons on that host in between, filter to LogonTypes that leave reusable credentials (2, 4, 5, 8, 9 and 10 in Microsoft's table) and return unique accounts with first and last seen times. Make sure the host filter is applied to the output, which the published CAR pseudocode gets wrong.
3. Add the persistent stores. Join the result with: configured service and scheduled task accounts on the host (from configuration management or the CMDB), the cached logon count and recent cached users, local accounts, and whether the host is a domain controller. Flag NTDS exposure as "entire domain".
4. Add upstream sources. For every RemoteInteractive or explicit-credential logon, record the source workstation; if that source is also suspect, recurse one hop.
5. Enrich and rank. Mark privileged accounts (domain admins, tier 0 service accounts, cloud admins), non-human identities and accounts with access to other sensitive systems. Rank resets by privilege and by evidence of later use.
6. Automate the trigger. Run the query as a SOAR step whenever a credential dumping detection fires (LSASS access, SAM or SECURITY hive export, ntds.dit copy, /etc/shadow reads), and attach the output to the case.
7. Feed containment and monitoring. Hand the list to identity operations for resets and revocation, and add the scoped accounts to a watchlist for new logons from unusual hosts during the incident window.

For the containment actions themselves, Microsoft's guidance for hybrid identities is to disable the account and reset the password twice when compromise is assumed, then in Entra ID revoke sessions (Revoke-MgUserSignInSession) so refresh tokens can no longer mint access tokens. Access tokens already issued stay valid until expiry (one hour by default) unless the application supports Continuous Access Evaluation, and Entra ID cannot revoke application session cookies directly: the application has to end them. Build those gaps into the scope report.

How to verify it works

• Controlled test: on a lab host, log on interactively with account A, over RDP with account B, over SMB with account C, and run a scheduled task as service account D. Trigger a benign test event standing in for a dumping alert. The output should list A, B and D, and not C.
• Boot boundary test: reboot the host, log on with account E only, trigger again. A, B and C should drop out of the memory scope; D should stay because its secret is stored on disk; cached users should appear in the disk scope.
• Domain controller test: run the trigger against a DC in a test domain and confirm the report states "entire domain, including krbtgt".
• Replay a past incident: run the analytic against logs from a closed case and compare with the accounts responders actually reset.

Limits, bypasses and failure patterns

• Long uptimes inflate scope: a server up for months may list hundreds of accounts. Reduce the problem upstream with tiered administration and by keeping privileged interactive logons off ordinary servers.
• Missing or cleared logs: if an attacker cleared the Security log before you collected it, the host view is incomplete. Rely on forwarded events and on authentication logs from domain controllers and identity providers.
• Secrets that are not logons: credentials in files, browser stores, shell history and tool configuration never appear in 4624. Pair the analytic with a secrets inventory for the host.
• Treating network logons as safe blindly: Microsoft notes some management tools and scanners may use non-network logons; take the logon type from the event, not from assumptions about the tool.
• Forgetting the source workstation: remote administration always exposes credentials on the source, so the admin's own device belongs in scope.
• Resetting without revoking: a password reset alone leaves refresh tokens and app sessions working; scope output must include token revocation steps.

Framework mapping

Related countermeasures

• User Behavior Analysis (parent): the family of analytics that model account activity.
• Credential Eviction: the Evict-tactic follow-up that removes the scoped credentials.
• Credential Hardening: reduces what a dump yields in the first place.

Practitioner checklist

• Forward event 4624 with LogonType, plus boot events, from every server and admin workstation.
• Build the since-last-boot logon query and filter to credential-leaving logon types.
• Join service, scheduled task, cached and local accounts for the host into the result.
• Treat any ntds.dit exposure as domain-wide, including krbtgt.
• Include source workstations of remote admin sessions.
• Trigger the analytic automatically from credential dumping detections.
• Pair password resets with session and token revocation and with checks for newly added keys.
• Test with a lab host and replay a past incident at least yearly.

Standards and references

• MITRE D3FEND: Credential Compromise Scope Analysis (D3-CCSA)
• MITRE CAR: CAR-2015-07-001 All Logins Since Last Boot
• Microsoft Learn: Administrative tools and logon types
• Microsoft Learn: 4624 An account was successfully logged on
• Microsoft Learn: Interactive logon: Number of previous logons to cache
• Microsoft Learn: Revoke user access in an emergency in Microsoft Entra ID
• MITRE ATT&CK: T1003 OS Credential Dumping

Related NHI Mgmt Group resources: Credential Dumping Guide · Identity Incident Response Playbook · Credential Rotation at Scale