What Is Mimikatz? Credential Dumping and How to Stop It

Once an attacker has a foothold on one Windows machine, their next goal is usually credentials. Not the credentials of that one machine, but the accounts that will let them reach the rest of the network. Mimikatz is the tool that made this step famous. It reaches into Windows and pulls out passwords, password hashes, and authentication tickets, turning a single compromised host into a set of keys for many others.

For a defender, Mimikatz is worth understanding because its techniques are everywhere. The original tool is only the reference implementation. Its methods are copied, embedded, and rewritten into countless malware families and frameworks, so the behaviour it pioneered is what you actually defend against.

What Mimikatz targets

Windows needs to keep some authentication secrets available in memory so users do not have to retype a password for every network resource. The process that holds them is the Local Security Authority Subsystem Service, or LSASS. It is a normal, essential part of Windows. It is also a vault sitting in memory, and that is what makes it a target.

Mimikatz reads the memory of LSASS and extracts what it finds there, which can include password hashes, Kerberos tickets, and in some configurations plaintext or reversibly stored credentials for users who are logged on. On MITRE ATT&CK this is OS Credential Dumping (T1003), and the LSASS-specific method is LSASS Memory (T1003.001).

Beyond live LSASS memory, the same class of technique reaches other credential stores: cached domain credentials, the SAM database of local accounts, and, against a domain controller, replication of account secrets from Active Directory itself. That last method, DCSync, asks a domain controller for password data as though the attacker were another domain controller, which is why it is so damaging.

What sits in LSASS depends on how the machine is configured and who has logged on. Each interactive logon can leave authentication material behind for the lifetime of that session, so a shared server where many people sign in accumulates many sets of secrets in one place. Older or misconfigured systems may retain reversibly stored credentials that yield plaintext passwords directly. Modern, hardened Windows stores far less and protects what remains, which is exactly why configuration is the difference between a dump that hands over a domain and one that returns little of use.

What the stolen credentials unlock

Extracting the secret is only step one. The reason credential dumping matters is what those secrets allow next.

The theme is impersonation. With the right hash or ticket, the attacker becomes a legitimate user in the eyes of the network and moves laterally without tripping password-based defenses. A single dump of a privileged account on one machine can cascade into control of a whole domain.

This is what makes credential dumping a turning point in an intrusion rather than just another step. Up to this moment the attacker is confined to the machines they have exploited. After a successful dump of the right account, they hold valid credentials and can authenticate the way a real employee does, which is far quieter than exploiting each new system. The intrusion shifts from breaking in to logging in, and logging in leaves a very different, much fainter trail. That shift is why defenders treat any credential-access event on a sensitive host as a priority to contain fast.

Why chasing the binary does not work

It is tempting to treat Mimikatz as a file to block. In practice the tool is one of the most modified pieces of offensive code in existence. Its source is public, so operators recompile it, rename it, obfuscate it, run it only in memory, and fold its functions into larger frameworks and malware. Blocking one binary or one hash catches the laziest cases and misses the rest.

The stable thing is the behaviour. Whatever the wrapper, the technique still has to open LSASS and read its memory, or still has to request replication from a domain controller. Those actions are where detection holds up, and this is where our Threat Groups directory helps by tracking which actors lean on credential-dumping and lateral movement, so you know whose playbook you are likely seeing.

It also helps to know that dumping is only one way to reach LSASS secrets, and defenders should not narrow their attention to a single method. Some operators avoid touching the process live and instead capture a memory image of LSASS with a legitimate administrative utility, then extract the credentials offline on their own machine, where no security product is watching. Others pull secrets from a captured copy of the registry hives, or harvest Kerberos tickets already cached on the host. The common thread is that each path ends in credentials the attacker did not have before, so the detections worth building focus on access to the sources of those secrets rather than on any one tool or command.

How to detect and defend

Defense splits into two efforts: make the credentials harder to reach, and detect the act of reaching for them.

1. Enable Credential Guard. On supported Windows, Credential Guard uses virtualization-based security to isolate LSASS secrets so that even code running with high privilege on the host cannot read them directly. It is one of the strongest mitigations available.

2. Protect the LSASS process. Run LSASS as a protected process (Protected Process Light) and enable the attack-surface-reduction rule that blocks credential theft from LSASS. Both raise the bar for reading its memory.

3. Practice least privilege and tiering. Keep domain and other high-privilege accounts off ordinary workstations. Use administrative tiering so that credentials capable of domain-wide impact never sit in the memory of an easily compromised machine.

4. Detect LSASS access. Instrument for suspicious processes opening a handle to LSASS with read access, and for tools reading its memory. On modern Windows this is directly observable, and unexpected LSASS access from a non-system process is a high-value alert. Map your detections to T1003.001.

5. Watch for DCSync. Monitor domain controllers for replication requests coming from hosts that are not domain controllers. A workstation asking for account secrets is a clear sign of the DCSync technique.

6. Reduce credential lifetime and exposure. Limit cached credentials where practical, rotate and protect the KRBTGT account on a schedule, and use privileged access workstations for administrative work so those sessions never touch general-purpose machines.

Mimikatz earned its reputation by making credential theft on Windows simple and repeatable, and the network defends against it long after the original tool has been renamed a thousand times. Take the secrets out of easy reach with Credential Guard and privilege tiering, watch anything that touches LSASS, and treat a dumped domain admin as a domain-wide incident, because that is what it is.

The modules and what each one reaches

The original tool is organised into command groups, and knowing the names helps a defender read alerts, incident reports, and threat intelligence that reference them. The same functions appear, sometimes renamed, inside the frameworks that copy the code, so the vocabulary is durable even when the binary is not.

Two families stand out. The sekurlsa group is the classic live-memory read of LSASS, the behaviour most detections aim at. The lsadump group works against registry and directory data, which lets an operator harvest secrets from an offline copy where no live process is being touched. That offline path is why capturing hives or a memory image and carrying it away is a recurring evasion: the extraction step then happens somewhere no endpoint sensor is running.

A walkthrough of a credential-dumping step

It helps to trace the conceptual sequence a dumping step follows on a host the attacker already controls with administrative rights. No real intrusion is invented here, only the mechanical order of operations that any variant has to perform.

1. Acquire the privilege to read another process. Reading LSASS memory requires the debug privilege or equivalent local administrative rights. The operator first enables that privilege in the current token, which is itself an observable action.
2. Open a handle to LSASS. The code calls the Windows API to open the LSASS process with read access. This handle request is the single most reliable detection point, because legitimate callers that open LSASS for read are few and known.
3. Locate the secrets in memory. LSASS keeps authentication material in structures managed by its security packages. The tool walks those structures to find hashes, keys, and cached tickets. The exact layout shifts between Windows versions, which is why credential tools ship version-specific offsets.
4. Decrypt what is protected. Some of the material in LSASS is encrypted with keys also held in the process. The tool reads those keys and decrypts the credentials, which is why simply encrypting secrets inside LSASS is insufficient on its own.
5. Present the results. Hashes, keys, and tickets are printed or written out, ready to feed into pass-the-hash or pass-the-ticket. From here the intrusion moves from the compromised host to the accounts it exposed.

Every step in that chain is a candidate for detection or prevention. Credential Guard breaks step three and four by moving the secrets into an isolated memory space the host operating system cannot read. Protected Process Light raises the bar on step two by refusing read handles from processes that lack the matching protection level. Least-privilege administration attacks step one, because an operator without administrative rights never reaches the privilege the whole sequence depends on.

Detection signals worth building

The durable detections watch the actions the technique cannot avoid. These are concrete signals to instrument rather than a single rule, and layering several of them raises confidence.

• Read handles to LSASS from unexpected processes. Windows can log a process requesting access to LSASS. A request for read or memory-read access from anything outside the small set of legitimate system components deserves an alert. Map this to LSASS Memory (T1003.001).
• The debug privilege being enabled. Interactive code enabling the debug privilege is uncommon on a workstation and often precedes a read of another process.
• LSASS as a source of process memory reads. Endpoint tooling that can see cross-process memory reads should treat LSASS as a high-value target and flag readers that are not on an allowlist.
• Creation of an LSASS memory image. A legitimate administrative utility writing a full dump of LSASS to disk is a strong signal when it is not part of a sanctioned troubleshooting task. The output file is often large and lands in a temporary path.
• Registry hive access to SAM and SECURITY. Copying or reading these hives outside of backup and imaging workflows points at the lsadump path.
• Replication requests from non-domain-controllers. A directory replication request arriving from a host that is not a domain controller is the fingerprint of DCSync and should be treated as an emergency.
• Anomalous ticket activity. Tickets with unusual lifetimes, encryption types, or accounts that never normally request them can indicate forged Golden or Silver tickets in use.

Common misconceptions

"We block the Mimikatz binary, so we are covered." Blocking one file catches unmodified copies and nothing else. The code is public and routinely recompiled, obfuscated, run only in memory, or reimplemented inside other tooling. The capability is what reaches your network, and the capability survives a filename change.

"Only domain controllers matter for this." Any host where a privileged account has logged on can hold that account's secrets in memory. An ordinary workstation that a domain administrator signed into becomes a path to the whole domain. The exposure follows the logon, not the server tier.

"Long, complex passwords stop credential dumping." Password strength helps against guessing and cracking. Dumping extracts the hash or ticket directly, and a hash works for pass-the-hash regardless of how strong the underlying password was. Complexity does not defend the material once it sits in memory.

"If plaintext credentials are gone, dumping is harmless." Removing reversibly stored plaintext credentials is worthwhile, and it still leaves hashes and Kerberos tickets, both of which enable impersonation. The goal is to protect all of that material, which is what Credential Guard sets out to do.

"Credential Guard makes us immune." Credential Guard substantially raises the cost of reading LSASS secrets, and it is one of the strongest single controls available. It does not cover every credential source. Cached data, tickets already in use, and directory replication remain relevant, so layered detection stays necessary.

How credential dumping evolved

Early Windows kept authentication material in memory in forms that could yield plaintext, because features like single sign-on needed to present credentials to network services on the user's behalf. That convenience left readable secrets in LSASS for anyone with administrative rights. The publication of a simple, reliable tool to extract them turned a known theoretical exposure into a routine step in intrusions, and credential dumping became the standard pivot from one host to a whole network.

Microsoft's response came in layers over several Windows releases. Reversibly stored plaintext credentials were curtailed. Protected Process Light was introduced so LSASS could refuse memory reads from unprotected callers. Credential Guard used virtualization-based security to move the secrets into an isolated space the normal operating system cannot reach. Attack-surface-reduction rules added a policy that blocks credential theft from LSASS outright on supported systems.

Operators adapted in turn. When live reads of LSASS grew risky, some shifted to capturing a memory image with a legitimate utility and extracting offline. When plaintext disappeared, they leaned harder on pass-the-hash and Kerberos ticket abuse, which never needed plaintext. When endpoint tools improved at spotting the classic read, they moved to registry hive theft and directory replication. The arms race is why a defender anchors on the credential sources rather than on any single tool version.

Frequently asked questions

Is Mimikatz malware? The tool itself is a security research and testing utility, and it is used legitimately by penetration testers and red teams under authorization. The same capabilities are used by criminals without permission. Finding it or its behaviour on a network calls for confirming whether an approved engagement is running before concluding either way.

Does antivirus stop it? Antivirus catches known, unmodified copies and common patterns. Because the code is public and heavily modified, obfuscated, and embedded in other tooling, signature-based blocking is only a partial control. Behavioural detection of LSASS access and directory replication is the more durable layer.

Can it run without administrative rights? The core memory-reading functions need administrative rights or the debug privilege on the target host, because reading another process's memory is a privileged action. This is exactly why least-privilege administration is a meaningful defense: an operator confined to a standard user context cannot perform the live LSASS read.

What is the single most effective mitigation? There is no one control that covers every path. Credential Guard is the strongest single technical mitigation for LSASS secrets on supported Windows, and it pairs with privilege tiering that keeps high-value accounts off ordinary machines. Together they remove both the secrets and the reason they would be present.

How does DCSync differ from reading LSASS? Reading LSASS extracts secrets already resident in one host's memory. DCSync asks a domain controller to replicate account password data as though the requester were another domain controller, so it pulls secrets straight from Active Directory without touching LSASS at all. It requires specific directory replication rights and is detected by watching for replication requests from hosts that are not domain controllers.

Why do stolen hashes work without the password? Windows authentication protocols can accept the hash or a derived ticket as proof of identity, so an attacker who holds the hash can authenticate through pass-the-hash without ever recovering the plaintext. This is why rotating a password matters after a suspected dump: it invalidates the stolen hash by changing the secret it represents.

Does this only affect Windows? The specific techniques here target Windows authentication internals, LSASS, the SAM and SECURITY hives, and Kerberos as implemented in Active Directory. Other platforms have their own credential-store risks, and the general lesson, that authentication secrets in memory are a prime target, applies broadly.

How should an incident responder react to a confirmed dump? Treat the exposed accounts as compromised and scope the blast radius by identity rather than by host. Rotate the passwords of every account that had a session on the affected machine, force re-authentication, and reset the KRBTGT account twice if there is any chance a Golden Ticket was forged. Then hunt for reuse of those credentials elsewhere, because the point of dumping is lateral movement and the stolen material may already be in use on other systems.

Related guides

• Pass-the-Hash Explained
• DCSync Attack Explained
• Windows Event IDs for Security
• Active Directory Security Basics