Definition
Determining which credentials may have been compromised by analyzing the user logon history of a particular system.
How it works
Memory
Credentials may be stored in memory for a variety of reasons; on Windows, they may be stored in lsass.exe. Once a credential dumper like mimikatz runs and dumps the memory of lsass.exe, the credentials of every account logged on since boot are potentially compromised. When such an event occurs, this analytic will give the forensic context to identify compromised users. Those users could potentially be used in later events for additional logons.
Hard disk
Operating System may cache a certain number of credentials onto the hard disk to use as a source of truth if it cannot contact the credential server. In many versions of Microsoft Windows, the 10 most recent are cached by default; this setting can be changed in the Microsoft Management Console's Local Security Policy: ```Computer Configuration -> Windows Settings -> Local Policy -> Security Options -> Interactive Logon: Number of previous logons to cache -> 0``` Here we are not concerned with the alteration of the credentials but the fact that they might be read. If the attacker has physical access to the machine they are unlikely to be stopped from reading files on the filesystem. "In the event that the domain controller is unavailable Windows will check the last password hashes that has been cached in order to authenticate the user with the system. These password hashes are cached in the following registry setting: HKEY_LOCAL_MACHINE\SECURITY\Cache Mimikatz can retrieve these hashes if the following command is executed: lsadump::cache" [1]
The Registry Hive, HKEY_LOCAL_MACHINE\SAM, which is stored in the supporting files %systemroot%\System32\Config\{Sam,sam.log,sam.sav}, contains the SAM file.
DC: This is stored in %systemroot%\ntds\ntds.dit. (https://www.ultimatewindowssecurity.com/blog/default.aspx?d=10/2017)
Sometimes memory, which contains credentials, could get on the hard disk. Like with hiberfil.sys in Windows. Equivalent on Linux
In Linux, an attacker could read the /etc/shadow file.
Reading from /proc directory: mimipenguin, many others.
Considerations
Effective implementation requires identifying any location that could end up containing credentials, and detecting an method of potential access to a source of credential data.
- https://medium.com/blue-team/preventing-mimikatz-attacks-ed283e7ebdd5
Implementation perspective
Credential Compromise Scope Analysis should be treated as a technical defensive capability rather than a product checkbox. In practice, teams should define the protected scope, the conditions under which the technique acts, and the observable evidence that demonstrates the intended behavior. For this technique, likely engineering context includes Credential.
Use the technique to identify suspicious, unauthorized, or abnormal activity through observable evidence and repeatable analysis.
Questions to ask
- Which events, states, or artifacts must be observed for the analysis to work?
- What analytic logic, threshold, comparison, or signature turns observations into a finding?
- How are expected false positives, blind spots, and environmental variations documented?
- Who receives the result, and what action is expected when the technique produces a finding?
Evidence and validation
- Telemetry and data-source configuration records
- Analytic logic, thresholds, signatures, and version history
- Test cases demonstrating expected positive and negative results
- Alert, triage, escalation, and tuning records
Common failure patterns
- Required telemetry is missing, delayed, or transformed in a way that invalidates the analysis.
- The technique produces alerts without an accountable triage and response process.
- Detection coverage is claimed from product deployment without testing the relevant analytic behavior.
This implementation perspective is original Bare Metal Cyber educational content. It does not replace the official D3FEND definition or establish that a specific product implements the technique.
Technique hierarchy
Top-level family
Parent techniques
Direct child techniques
None listed at this level.
Artifacts and ontology entities
These relationships describe how D3FEND connects a defensive technique to artifacts or other ontology entities. They describe graph semantics, not a product certification.
Explicit technique relationships
Show inferred artifact relationship paths (1)
Offensive-technique relationships
These relationships are generated from D3FEND graph paths and are explicitly experimental. They should be treated as hypotheses for defensive analysis—not as proof that the technique prevents, detects, or removes an offensive behavior.
ATT&CK Enterprise (20)
ATT&CK for ICS (3)
Authoritative sources
- Open this technique on the official D3FEND website ↗
- Open the official ontology resources ↗
- CAR-2015-07-001: All Logins Since Last Boot ↗MITRE · MITRE · ExternalKnowledgeBase
- Systems and methods for detecting credential theft ↗Symantec Corp · Adam Glick; Brian Schlatter; Feng Li; Akshata Krishnamoorthy Rao · PatentReference
Bare Metal Cyber is an independent educational publisher and is not affiliated with or endorsed by The MITRE Corporation. MITRE D3FEND™ and the D3FEND logo are trademarks of The MITRE Corporation. MITRE ATT&CK® and ATT&CK® are registered trademarks of The MITRE Corporation. Use of D3FEND source material is subject to the official Terms of Use.