What Is Credential Dumping? Techniques and Defenses

An attacker has administrator rights on one machine. They run a tool that reads the memory of lsass.exe, the Windows process that holds the credentials of everyone currently logged in, and out comes a list: NTLM password hashes, and a Kerberos ticket for a domain administrator who logged in earlier that day. The attacker never cracked a password. They simply lifted the credentials the operating system was already holding, and now they can authenticate as that domain admin anywhere on the network. A few hours later they run the same idea against the domain controller and walk away with the password hash of every account in the company.

That is credential dumping: extracting stored account credentials from a compromised system so they can be reused. It is one of the most important techniques in an intruder's playbook, because credentials are the keys to the kingdom. Stealing them turns a single compromised host into access across the whole environment, which is why credential dumping sits at the center of nearly every serious intrusion.

This guide covers what credential dumping is, where credentials live and how attackers extract them, the common tools, why it is so dangerous, and how to detect and prevent it. It is written for blue teamers who have to catch credential theft before it becomes a domain takeover.

What is credential dumping?

Credential dumping is the technique of extracting account credentials, usually password hashes, Kerberos tickets, or plaintext passwords, from the places an operating system stores them. MITRE ATT&CK catalogs it as OS Credential Dumping (T1003), defined as adversaries dumping credential material from OS caches, memory, or on-disk structures so it can be reused.

It sits in the credential-access phase of an intrusion, after an attacker has gained a foothold and some level of privilege, and it is the fuel for what comes next. Most lateral movement runs on stolen credentials, so credential dumping and lateral movement are a pair: dump credentials on one host, use them to move to the next, dump again, repeat toward the objective.

The reason it is so powerful is that it sidesteps the whole problem of cracking passwords. The attacker does not guess or brute-force anything; they take the credential material the system already holds in memory or on disk. With a stolen hash or ticket, they authenticate as the victim using techniques like pass-the-hash, no plaintext password required. Credential dumping is how a foothold becomes a master key.

Where credentials live: the targets

Effective defense starts with knowing what the attacker is reaching for. Windows stores credential material in several places, each a distinct ATT&CK sub-technique.

LSASS memory is the most common target. The Local Security Authority Subsystem Service keeps the credentials of logged-on users in memory so they do not have to re-authenticate constantly, which makes its memory a treasure chest. The SAM holds local account hashes on each machine. NTDS.dit is the prize: the Active Directory database on a domain controller, containing every domain account's hash. DCSync is especially dangerous because it does not require touching the domain controller's disk at all; the attacker abuses the legitimate replication protocol to ask a domain controller to hand over password data, as if they were another domain controller.

LSA secrets hold the passwords of service accounts, scheduled tasks, and some applications, often privileged, stored on disk and recoverable with SYSTEM rights. Cached domain credentials let domain users log in when no domain controller is reachable; they cannot be passed directly but can be cracked offline. Each store is a separate opportunity, so an attacker on a host typically checks several rather than relying on one.

How credential dumping works

The mechanics follow a consistent pattern.

1. Gain sufficient privilege. Most credential dumping requires local administrator or SYSTEM rights, because the credential stores are protected. This is why privilege escalation usually precedes it.
2. Access the store. The attacker reads LSASS memory, copies the SAM or NTDS.dit file (often via a volume shadow copy to bypass file locks), or invokes replication for DCSync.
3. Extract the material. They parse out the hashes, tickets, or secrets from what they accessed.
4. Reuse or crack. They use the credentials directly with pass-the-hash or pass-the-ticket, or crack the hashes offline to recover plaintext passwords for systems that require them.

The defining trait, again, is that much of this abuses legitimate functionality. Reading process memory, copying a file, and replicating directory data are all normal operations. The malice is in the context, not the action.

Two details shape the defense. First, the privilege requirement is a chokepoint: because dumping needs administrator or SYSTEM rights, stopping privilege escalation also stops most credential theft. Second, the payoff depends on presence, a credential can only be stolen from a machine where it has actually been used, so controlling where privileged accounts log in controls where their credentials can be dumped. Both points become concrete controls below.

Common credential dumping tools

A handful of tools show up across the vast majority of intrusions:

• Mimikatz. The best-known credential-dumping tool, able to pull plaintext passwords, hashes, and Kerberos tickets straight from LSASS, and to perform pass-the-hash, pass-the-ticket, and DCSync.
• comsvcs.dll. A built-in Windows DLL that can dump LSASS memory when invoked through rundll32, a living-off-the-land method that uses no external tool at all.
• ProcDump. A legitimate Microsoft Sysinternals utility, often abused to dump LSASS memory for offline parsing elsewhere.
• Impacket secretsdump. A widely used script that remotely extracts hashes from the SAM, LSA secrets, and NTDS.dit, and can perform DCSync.

The presence of built-in and legitimate tools on this list is the point: an attacker does not need to bring malware to steal credentials when Windows ships with the means to do it. Older utilities like gsecdump and Windows Credential Editor still appear too, but the technique outlives any single tool, which is why detection focuses on the behavior rather than on blocking named programs.

Why credential dumping is so dangerous

Credential dumping is a force multiplier. A single successful dump rarely yields one credential; it yields every credential present on that machine, including any privileged account that has logged in. One dump on the right server can hand an attacker the keys to dozens of systems at once.

This is not theoretical. Credential dumping, and Mimikatz in particular, has been a fixture of major intrusions for over a decade: the NotPetya outbreak harvested credentials from memory to spread across whole networks in minutes, and modern ransomware crews routinely dump domain administrator credentials before they encrypt. Attacker dwell time is measured in weeks, with Mandiant's M-Trends 2026 reporting a 14-day global median, and credential theft is what lets an intruder use that time, quietly expanding access while authenticating as legitimate users.

It is also the bridge to total compromise. The path from a single workstation to full domain control almost always runs through credential dumping: dump a local admin hash, move to a server, dump a domain admin's credentials from memory, then run DCSync against the domain controller to extract every hash in the domain. At that point the attacker can forge tickets and persist indefinitely, which is why credential theft is a precursor to the worst outcomes, from ransomware deployed domain-wide to long-term espionage. The relationship between NTLM and Kerberos authentication is worth understanding here, because the stolen material is exactly what those protocols rely on, and related attacks like Kerberoasting target the same credential layer from a different angle.

The worst case is persistence that outlives password resets. With the domain's master key material, the KRBTGT account hash pulled from NTDS, an attacker can forge Kerberos "golden tickets" that grant access as any user, indefinitely. Evicting that requires resetting the KRBTGT account twice, not simply changing user passwords, which is why credential dumping at the domain-controller level is among the most expensive incidents to fully contain.

How to detect credential dumping

Because the techniques abuse legitimate functions, detection focuses on the unusual access patterns they create.

• Suspicious access to LSASS. The strongest signal. Watch for any process opening a handle to lsass.exe with read access, recorded by EDR or Sysmon Event ID 10. A non-system process reading LSASS memory is rarely benign.
• LOLBin abuse. rundll32 invoking comsvcs.dll with the MiniDump function, or procdump targeting lsass, are high-fidelity indicators of an LSASS dump.
• SAM and NTDS access. Registry saves of the SAM hive, and use of ntdsutil or volume shadow copies to grab NTDS.dit, are signs of on-disk credential theft.
• DCSync detection. A replication request (directory replication traffic) coming from a host that is not a domain controller is a classic DCSync tell, visible in domain controller logs.
• Correlate in the SIEM. Centralize these signals in a SIEM so an LSASS access on one host and an unusual logon elsewhere connect into one story, and hunt for them proactively through threat hunting.

The access mask is what separates a dump from benign activity: a handle to lsass.exe requesting memory-read rights, GrantedAccess values such as 0x1010 or 0x1410 in Sysmon Event ID 10, is the fingerprint of a credential dump rather than ordinary monitoring. Baselining which processes legitimately touch LSASS in your own environment is what keeps the signal high-fidelity instead of drowning analysts in false positives.

How to prevent credential dumping

You cannot make credentials disappear, but you can make them far harder to steal and far less useful when stolen.

• Protect LSASS. Enable Credential Guard, which uses virtualization to isolate LSASS secrets from the rest of the OS, and run LSASS as a protected process (RunAsPPL) so ordinary processes cannot read its memory.
• Disable plaintext caching. Turn off WDigest so plaintext passwords are not held in LSASS memory, and limit credential caching where you can.
• Randomize local admin passwords. A solution like LAPS gives every machine a unique local administrator password, so dumping one SAM does not unlock others.
• Enforce least privilege and tiered administration. Most dumping needs admin rights, and its value comes from privileged accounts being present. Keep domain admin credentials off ordinary workstations so they are never in memory to steal.
• Require MFA and monitor privileged accounts. Multi-factor authentication limits what a stolen password alone can do, and close monitoring of privileged accounts shortens the time a stolen credential goes unnoticed.

Layered, these turn credential dumping from a quiet, reliable step into a noisy, low-yield gamble.

Getting started with detecting credential dumping

If you are building the skill, work from the artifacts the techniques leave.

1. Understand the credential stores. Learn what LSASS, the SAM, NTDS.dit, and LSA secrets hold and why each matters.
2. Run the tools in a lab. Detonate Mimikatz and an LSASS dump in an isolated environment and watch what telemetry they generate.
3. Learn the detections. Study the Sysmon and EDR signals for LSASS access and the log signature of DCSync.
4. Investigate a real case. Trace an intrusion where credential dumping enabled lateral movement, end to end.

The bottom line

Credential dumping is how an attacker turns one compromised machine into access across a network: by extracting the password hashes, tickets, and secrets the operating system stores, then reusing them to authenticate as someone else. It is the credential-access engine behind lateral movement and domain takeover, and because it abuses legitimate functions like reading process memory and replicating directory data, it hides in normal activity.

The defense is layered: make the credential stores hard to reach with Credential Guard and LSASS protection, make stolen credentials less useful with least privilege and randomized passwords, and catch the theft by watching who touches LSASS, the SAM, and the domain controller. The constant is the analyst who recognizes the one process reading LSASS that should not be.