How to detect and halt credential theft via Windows WDigest

Once attackers get into a system, they often want to elevate privileges or do credential harvesting. One way they do this is by finding a WDigest legacy authentication protocol left forgotten and open on servers. On Windows Server prior to Server 2012 R2, WDigest credential caching is enabled by default. When it is enabled, Lsass.exe retains a copy of the user’s plaintext password in memory, where it can be at risk of theft. Microsoft recommends disabling WDigest authentication unless it is needed.

Setting the UseLogonCredential value to 0 tells WDigest not to store credentials in memory. This value is not by default set up on a Server 2008 R2 system. To add it, scroll down to HKEY local machine to the value noted, right-click on “New,” then “Add a Dword 32-bit value,” and add the UseLogonCredential.

Adding this registry key clears passwords from memory:

HKEY_LOCAL_MACHINESystemCurrentControlSetControlSecurityProvidersWDigestLogonCredential

Add a REG_DWORD of 0

Disabling credential caching not enough

Recently, attackers have been stealthily re-enabling WDigest even on newer platforms. If attackers attain local administrator rights on a system through any means, they can access the registry entry and enable the WDigest credential.

Mitre points out several techniques that can be used to dump the credentials. The attackers using the bank Trojan Trickbot went one better. They got into systems using various means and enabled WDigest support in the registry. Then TrickBot enabled its screenlocker module, triggering the user to re-log into his or her account. Because WDigest support was re-enabled, and the user was tricked into logging out and then logging back in, the user’s credentials were cached in LSA memory where the attacker could then scan and retrieve the details. The screenlocker module was only enabled on Windows 8/Server 2012 R2 or later as those machines, by default, do not enable WDigest.

How to spot Trickbot-type credential theft

You have a couple of techniques to monitor attackers using this technique against you and your servers. First, monitor changes to registry keys, specifically to the WDigest key. Next, check audit logs for when WDigest is used.

Look in domain controllers for Event ID 4776, Authentication package: WDigest. In Windows Servers, look for Event ID: 4624, Authentication package: WDigest. Your security logs will be chatty and filled with Kerberos authentication, so you will need a logging solution to store these files in a way that allows you to review them in depth. Look for the authentication package of WDigest in the detailed authentication information.

Even on Server 2012 R2 and newer that by default do not enable WDigest, it’s wise to disable the setting as noted on the ADSecurity blog. Update KB2871997 must first be installed to disable WDigest authentication using this setting in Windows 7, Windows 8, Windows Server 2008 R2 and Windows Server 2012. For more information, see this Microsoft security advisory.

Susan Bradley

Finally, you can perform a registry query to see if the WDigest key exists and that it’s not set to the value of 1. Perform this using the following query as noted in the Stealthbits blog:

HKLMSYSTEMCurrentControlSetControlSecurityProvidersWDigest /v

UseLogonCredential

Attackers want to gain access to passwords as easily as they can. Your goal is to make it harder for them to do so. Take the time to proactively block one easy path for them to harvest credentials.

Don’t forget to sign up for TechTalk from IDG the new YouTube channel for tech news of the day.