OS Credential Dumping (T1003) sits in the credential access tactic. Adversaries try to obtain account login material, usually a hash or a clear text password, from operating system caches, memory or data structures. MITRE lists Windows, Linux and macOS.
Once they hold credentials, adversaries can move laterally and reach restricted information. MITRE also points out that several of the tools involved are used by professional security testers too, and that custom tools likely exist, so you cannot rely on a short list of bad program names.
How attackers use it
The parent technique covers many places credentials live. On Windows these include LSASS process memory, the SAM database, the NTDS database on domain controllers, LSA secrets, cached domain credentials, and DCSync, which abuses domain replication. On Linux they include the proc filesystem and the passwd and shadow files, and cached domain credentials from software such as SSSD. On macOS, MITRE's analytics mention Keychain and sensitive memory regions.
Each has its own guide in this series. The common idea is that the credential is already on the machine, and the adversary needs privileges to read it.
How to detect it
MITRE's detection strategy correlates sensitive memory and registry access:
- On Windows, processes accessing LSASS memory or the SAM registry hives outside trusted security tools, often followed by file creation or lateral movement.
- On Linux, processes opening proc memory or maps files of credential-handling services such as sshd or login, often with debugging tools like gcore or gdb and a jump in privilege.
- On macOS, unsigned processes accessing sensitive memory or launching known credential scraping behavior to reach the Keychain.
Process access logging on Windows endpoints, process creation events, file creation events and registry auditing are the main sources. Linux auditing of memory and file access plays the same role there.
Do not alert on every access. Build an allowlist of your endpoint security agent and backup tools, then investigate everything else.
How to reduce the risk
The mitigations MITRE lists, in plain steps:
- Secure Domain Controller backups, since they hold the same data as the live database.
- On Windows 10, enable Attack Surface Reduction rules that protect LSASS.
- Give every local administrator account a complex password that is unique per system.
- Train users and administrators not to reuse passwords across accounts.
- Do not place user or admin domain accounts in local administrator groups across systems unless tightly controlled. Use administrative tiers to limit where privileged accounts log on.
Building the detection in layers
Credential dumping has no single signal, so build three layers and let them back each other up.
The first layer is prevention on the endpoint: attack surface reduction rules, protected LSA and Credential Guard on Windows. If a dump is blocked, the attempt still creates a log entry, and that entry is an early warning.
The second layer is access logging for the sensitive objects. On Windows that means process access events for LSASS, registry auditing on the SAM and SECURITY hives, and file auditing on the NTDS folder of domain controllers. On Linux, it means audit rules for the shadow file and for proc memory access by non-debugger processes.
The third layer is behavior after the fact. Credentials taken from one host are used elsewhere. A burst of new logons from one account to hosts it never touched before, or a service account logging on interactively, is the shadow a dump casts. This layer catches the cases where the first two missed.
Prioritizing the sub-techniques
Not every environment faces every variant equally. A reasonable order:
- Windows domains: start with LSASS memory, then DCSync and NTDS, since these reach the most accounts.
- Mixed fleets: add cached domain credentials and the Linux files, so the Linux estate is not a blind spot.
- Hosts with many local administrators: fix local administrator password reuse first, because it multiplies the damage of every other variant.
Response if you find a dump
Assume the credentials in the dumped location are exposed. For an LSASS dump on a workstation, that means every account that logged on recently. Reset those passwords, check where they were used and review the host. For a domain controller database, the scope is every account in the domain, and the response is a coordinated reset plan. Prepare that plan in advance, with names and steps, so the first time you read it is not during an incident.
Check your own environment
Read-only questions to ask this week:
- Do any two machines share a local administrator password?
- Which domain accounts sit in local administrator groups on workstations?
- Are Domain Controller backups stored with the same access as the DC itself?
- Do you log process access to LSASS, and does anyone review it?
On Windows, you can see whether LSA protection is set with this read-only registry query (Windows, reg.exe):
reg query HKLM\SYSTEM\CurrentControlSet\Control\Lsa /v RunAsPPL
A value of 1 means it is enabled. If the value is missing, it is not configured.
Quick check
Why are Domain Controller backups part of this technique's mitigations?
They contain the same credential data as the live directory. MITRE advises making sure they are properly secured so they are not an easier route to the same hashes.
Why not just block known credential tools?
MITRE notes the tools are used by both adversaries and professional testers, and custom tools probably exist. Detecting the behavior, such as unusual access to sensitive memory, is more durable than a name list.
