WDigest Enabled: Why Cleartext Credentials Reappear in LSASS

What Is WDigest Enabled?

WDigest enabled means the operating system is configured to store reusable credential material for WDigest in LSASS on a host where defenders should be reducing credential exposure, not bringing it back. Microsoft’s credential protection guidance around Security Advisory 2871997 was aimed at reducing credential theft on domain-joined Windows systems, and one of the most practical hardening points from that guidance is to prevent WDigest from storing credentials in memory through the UseLogonCredential setting.

The risk matters because WDigest is not just an old protocol footnote. Microsoft’s protocol documentation explains that the supplementalCredentials structure can contain Primary:WDigest, described as cryptographic hashes of the cleartext password for the Digest authentication protocol. When defenders deliberately re-enable WDigest credential storage on a system, they increase the chance that a local compromise will expose reusable credentials that should not have been available in LSASS memory.

That is why WDigest enabled usually belongs in the same remediation conversation as Active Directory Password Security: Misconfigurations That Matter, Passwords in AD Description Fields: Detection and Cleanup, and Stale Privileged Accounts: Hidden Risk in Active Directory. In all three cases, the real problem is not only a weak setting. It is that reusable credential material is easier to steal, reuse, or retain than the organization expects.

How It Works

Microsoft documents UseLogonCredential under the WDigest registry path as the control used to prevent WDigest credentials from being stored in memory. On systems where the setting is re-enabled, credential material becomes available again to code that reaches LSASS with sufficient privilege.

The practical hardening logic is straightforward:

• if WDigest credential storage is disabled, an attacker who compromises a host still has work to do to find reusable secrets
• if WDigest credential storage is enabled, the host is offering a more attractive credential target than necessary

Microsoft’s 2871997 advisory also explains a related defensive concept: the Protected Users group. Members of Protected Users cannot authenticate with NTLM, Digest Authentication, or CredSSP, and their passwords are not cached in the same way on supported systems. That does not replace disabling WDigest, but it reinforces the same goal: reduce the amount of reusable credential material available to an attacker after local compromise.

The Attack Chain

Step 1 - Gain local admin or SYSTEM on one Windows host

WDigest enabled is not usually the initial intrusion vector. It becomes dangerous after the attacker already holds local admin, SYSTEM, or equivalent code execution on a machine. At that point, the difference between a hardened host and a weak host is whether the memory-resident credential surface is as small as possible.

That is why the issue often appears alongside Kerberoasting: How Attackers Crack Service Account Passwords and AS-REP Roasting: Harvesting Hashes Without Credentials. Attackers chain credential opportunities. If one host yields reusable secrets, the rest of the attack gets cheaper.

Step 2 - Dump LSASS and recover reusable credentials

Once the setting is enabled, the attacker does not need the environment to be fully broken. They only need one machine where the host-level compromise can be turned into credential access.

# Defender-side validation of the setting
Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest' -Name UseLogonCredential

From a blue-team perspective, the important point is not the dumping tool. It is the fact that a host was configured to keep more credential material than necessary in LSASS.

Step 3 - Reuse the harvested credential on adjacent systems

If the stolen credential belongs to a privileged admin, a helpdesk operator, or a service account with broad access, the attacker can move immediately into adjacent systems or identity paths. That is why WDigest enabled is rarely an isolated finding. It increases the blast radius of every other access control mistake in the environment.

The same reasoning appears in Active Directory Attack Paths to Domain Admin: any setting that turns one compromised host into reusable privilege material shortens the attacker’s path to something more important.

Detection

You do not need guesswork to detect WDigest exposure. Microsoft’s guidance already gives you the key control point: the UseLogonCredential registry value. A serious review should also verify whether privileged admins are still outside Protected Users and whether your telemetry would surface registry changes or suspicious LSASS access quickly enough.

# Fleet-side spot check for WDigest on a host
reg query HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest /v UseLogonCredential

# Review whether a privileged account is protected by the Protected Users group
Get-ADGroupMember 'Protected Users'

The registry check is the fastest validation, but it should not be your only one. During an incident review, confirm whether the setting was present on privileged workstations, jump servers, or server administration tiers. A single exception on the wrong host can negate a lot of otherwise solid credential-hardening work.

Remediation

💡 Quick Win: If a host has no justified dependency on WDigest credential storage, disable it and confirm the setting is not reintroduced through a legacy baseline, gold image, or troubleshooting script.

A clean remediation path is usually short:

1. Inventory where UseLogonCredential is enabled. Check privileged workstations, admin jump hosts, and servers first.
2. Remove or disable the setting. On supported systems, prevent WDigest from storing credentials in memory by setting UseLogonCredential to 0 or returning the host to the modern default state used by your baseline.
3. Review legacy dependencies. If a team claims a dependency on WDigest, require a concrete application path and a retirement plan, not a permanent exception.
4. Protect high-value identities. Use the Protected Users group where operationally appropriate for privileged identities that should not authenticate with NTLM, Digest, or CredSSP.
5. Watch for drift. Alert on registry changes to the WDigest path and on suspicious LSASS access behavior in your endpoint telemetry.

# Example remediation on a Windows host
New-Item -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest' -Force | Out-Null
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest' -Name UseLogonCredential -Type DWord -Value 0

If your environment still has old baseline scripts or post-build hardening templates, review them carefully. WDigest sometimes gets reintroduced not by design, but by a forgotten script that someone copied years ago to “fix” an application problem. That is why the registry state, the build baseline, and the actual production dependency all need to be checked together.

Validate the Change Before Closing It

The safest validation sequence is simple: confirm the registry state on representative systems, confirm the risky application path still works if a real business dependency exists, and confirm your detection stack will raise a signal if someone re-enables UseLogonCredential later. This is the kind of control that looks trivial until an incident proves it was silently undone six months earlier.

It is also worth validating the identity side. If your privileged admins are still logging onto broad admin surfaces and are not scoped into stronger protections, a single WDigest exception can matter more than teams expect. That is why the finding belongs in a broader privileged-access review, not only in a workstation hardening checklist.

Why WDigest Exceptions Drift Back Into the Estate

WDigest rarely comes back because a team deliberately wants a weaker credential posture. More often, it returns through troubleshooting habits: an engineer copies an old registry workaround, a gold image keeps a stale value, or a support script is reused without anyone revalidating whether the original application dependency still exists. That operational pattern matters because it changes how you should review the issue. The question is not only “is the key set?” but also “which build standard, automation, or owner keeps putting it back?”

In mature environments, that review should include representative admin workstations, jump hosts, and any server tier where privileged admins sign in interactively. If the registry state is clean on ordinary workstations but still weak on the systems that hold the highest-value credentials, the residual risk is still large. That is also why How to Audit Active Directory Security: Practical Checklist for Internal Teams and Active Directory Monitoring: Security Event IDs That Matter are useful companion reads: they help tie a local registry weakness back to the broader question of where privileged credentials really live.

How EtcSec Detects This

EtcSec maps this issue directly to WDIGEST_ENABLED. The useful question is not whether the registry key exists somewhere in the estate; it is whether the hosts that matter most are still keeping reusable credential material in LSASS and whether the exception has a real owner.

ℹ️ Note: EtcSec automatically flags WDigest credential storage during Active Directory reviews so teams can prioritize the hosts where local compromise would expose the highest-value credentials.

Official References

• Microsoft Security Advisory 2871997: Update to Improve Credentials Protection and Management
• Microsoft Support article for the UseLogonCredential policy and WDigest credential storage behavior
• Microsoft protocol documentation for supplementalCredentials and Primary:WDigest

Related Reading

Review this issue together with Active Directory Password Security: Misconfigurations That Matter, Passwords in AD Description Fields: Detection and Cleanup, Stale Privileged Accounts: Hidden Risk in Active Directory, How to Audit Active Directory Security: Practical Checklist for Internal Teams, and Active Directory Monitoring: Security Event IDs That Matter. Those adjacent topics help separate a local registry setting from the larger question of where reusable credentials still exist in the environment.