WDigest and Cleartext Credentials in LSASS

A single registry value can make Windows cache your plaintext password in memory - a Mimikatz favorite. Here's what WDigest UseLogonCredential does, why it keeps coming back, and how to audit it.

Ask most Windows admins how a password ends up in plaintext inside a running machine's memory and they'll assume it takes malware or a kernel exploit. The uncomfortable answer is that a single legacy authentication provider — WDigest — will happily do it for you, and one registry value decides whether it does. That value is UseLogonCredential, and it is one of the first things a credential-dumping tool checks.

What WDigest actually does

WDigest is the Digest Authentication security support provider that shipped with Windows XP and Server 2003 to support HTTP Digest and SASL. To answer an authentication challenge, WDigest needs the user's cleartext password — not a hash. So when it is active, the Local Security Authority Subsystem Service (lsass.exe) keeps a reversibly-encrypted copy of every interactive user's password in memory, and hands WDigest the plaintext on demand.

That design is exactly why Mimikatz's sekurlsa::wdigest module became infamous: on an affected host, a single command dumps the logged-on user's password in the clear. No hash cracking, no relay, no brute force — just the password, ready to reuse.

Microsoft already fixed this — in 2014

After Mimikatz made WDigest harvesting trivial, Microsoft shipped KB2871997 for Windows 7, 8, Server 2008 R2 and 2012, and made the safe behavior the default in Windows 8.1 / Server 2012 R2 and everything since. The control is a single DWORD:

HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest
    UseLogonCredential  (REG_DWORD)
        0  or absent  =  WDigest does NOT cache plaintext passwords  (safe)
        1             =  WDigest caches plaintext passwords in LSASS   (exposed)

On a modern, untouched install the value is either missing or 0, and there is nothing to worry about. The problem is that it does not always stay that way.

Why the exposure keeps coming back

An explicit UseLogonCredential = 1 is almost never an accident of the OS — something put it there. The usual suspects:

Attacker re-enablement. Setting this value is a classic post-exploitation move. An adversary with admin rights flips it to 1, forces the victim to re-authenticate (lock the screen, RDP reconnect), and then dumps a fresh plaintext password. It's persistence for credentials, mapped to MITRE ATT&CK T1003.001 (OS Credential Dumping: LSASS Memory).
Ancient troubleshooting advice. Some legacy line-of-business apps or old forum posts recommend enabling it to fix a Digest-auth issue. That "fix" quietly reintroduces the exposure for every user who logs on.
Copy-paste hardening baselines gone wrong. A misapplied or inverted GPO can set the value the wrong way across a whole fleet.

Because the default is safe, this setting rarely appears on anyone's radar — which is precisely what makes it a good hiding spot.

How to audit it

Checking one machine by hand is a two-line PowerShell query:

$p = 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest'
(Get-ItemProperty -Path $p -Name UseLogonCredential -ErrorAction SilentlyContinue).UseLogonCredential

A blank result or 0 is good; 1 means WDigest is caching plaintext credentials right now. To remediate, set it back to 0 (a logoff/logon or reboot clears the already-cached secrets):

Set-ItemProperty -Path $p -Name UseLogonCredential -Value 0 -Type DWord

Where WinSentinel fits

Reading a registry value is easy; remembering to read it, on every machine, every time something changes, is not. WinSentinel's Identity & Credential audit checks UseLogonCredential as part of a broader credential-hygiene sweep — alongside LSA Protection (RunAsPPL), Credential Guard, cached domain logon count, local admin sprawl, and LAPS posture. If WDigest plaintext caching is on, you get a clear Warning with the exact fix command, so it can never quietly sit at 1 in the background.

It's a single-machine check, free in the CLI and the desktop app:

dotnet tool install --global WinSentinel.Cli
winsentinel --audit --category Identity

WDigest is a fifteen-year-old authentication provider that most environments never use, yet leaving its plaintext cache one registry key away from "on" is a gift to anyone who lands admin on the box. Confirm it's 0, keep it that way, and make the check part of your regular audit rather than a thing you remember after an incident.