by Nilaa Maharjan, Security Research
Internal penetration testing often requires security specialists to attempt to extract passwords from the memory of infected machines. If the acquired credentials are hashed, the tester can use the pass-the-hash approach to travel laterally within the network to accomplish their goals. This technique was frequently used in the past and is still a valid threat vector in non-updated machines.
However, suppose the tester is able to extract cleartext credentials from memory or crack the collected hashes, they will be able to authenticate across additional network resources and services such as Outlook, business-critical web applications, and device portals, amongst many others.
In this article, we’ll go through what WDigest is, how it is used to extract cleartext credentials from memory, and how an analyst can use Logpoint to detect, mitigate and respond to any WDigest-related attack attempt.
But first, a little backstory.
What is WDigest?
WDigest Authentication is a challenge/response protocol that was primarily used for LDAP and web-based authentication in Windows Server 2003. It was introduced for the first time in Windows XP and was enabled by default on Windows systems. It allows clients to communicate cleartext credentials to Hypertext Transfer Protocol (HTTP) and Simple Authentication Security Layer (SASL) applications.
Microsoft cached the cleartext credentials in Windows RAM when users logged in to their workstations to make the authentication procedure more convenient for end users. Workstations used these cached credentials to authenticate HTTP and SASL services without requiring users to enter their credentials over and over again. The cleartext credentials authenticate via HTTP and SASL exchanges.
For example, a client requests access, the authenticating server challenges the client, and the client answers by encrypting its response with a key derived from the password. To ascertain if the user has the right password, the encrypted response is compared to a previously stored response on the authenticating server. This is where the crux of the problem resides.
Microsoft has a much more detailed explanation of WDigest, how it works, and some of its applications here.
Why does it matter?
Everyone should prioritize Windows security auditing. Understanding how your endpoints are set up and what doors they may be exposing to unwanted users is critical to defending any system. This is where WDigest comes in. One thing to keep in mind about WDigest is that it keeps passwords in cleartext and in memory. If a malicious person gains access to an endpoint and is able to run a program like Mimikatz, they will be able to obtain not just the hashes currently stored in memory, but also the cleartext passwords for the accounts.
It is not only a baseline red team testing practice but also a tactic often used by adversaries like KNOTWEED or PHOSPHORUS ransomware campaigns.
This is and should be a concern because adversaries can now not only employ an attack like pass-the-hash, but they also have the username and password to try to log on to things like Exchange, internal websites, and so on.
A typical attack scenario
Mimikatz has been used in the wild to steal credentials from memory during the last few years. As a result, several antivirus solutions have created signatures to prevent this utility from executing on PCs. However, there are several ways to avoid these antivirus signatures, including executing the program in memory or obfuscating the utility.
Once the attacker has gained access to an internal system within an organization, Mimikatz can be used to retrieve credentials from memory. These retrieved credentials can be in hashed, cleartext, or both formats.
If the attacker is lucky enough to obtain these credentials in cleartext, cracking hashes is not necessary and will allow direct access to internal resources, bringing attackers closer to achieving their objectives.
However, it’s important to note that before the command can be run, the attacker must have administrative rights.
Here is an example of what an attacker would see when dumping credentials in memory with a tool like Mimikatz. The user “HanSolo” used a remote desktop to log onto the machine, and because the specific configuration around WDigest is configured in an insecure manner, not only are they seeing an NTLM hash for the account, but the cleartext password “Password99!” as well.
Example of an attacker’s view when dumping credentials in memory. For more information, read the quick guide on using Mimikatz by adsecurity.
Understanding the WDigest registry is helpful for offensive and defensive analysts.
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\WDigest
- If the UseLogonCredential value is set to 0, WDigest will not store credentials in memory.
- If the UseLogonCredential value is set to 1, WDigest will store credentials in memory.
As was the case with the DEV-0270’s PHOSPHOROUS ransomware campaign, after the threat actors had compromised the device and gained admin privileges, DEV-0270 used LOLBINs to conduct their credential theft, as this removes the need to drop common credential theft tools more likely to be detected and blocked by antivirus and endpoint detection and response (EDR) solutions. One of these processes starts by enabling WDigest in the registry, which results in passwords stored in cleartext on the device and saves the actor time by not having to crack a password hash.
We have noticed two variations of this command being used, both of which eventually sets the registry value of UseLogonCredential to 1.
In systems where the WDigest registry is missing or removed.
"Set-ItemProperty -Force
-Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest'
-Name "UseLogonCredential"
-Value '1'"In systems where the WDigest registry is set to not store clear passwords.
"reg" add
HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest /v
UseLogonCredential /t REG_DWORD /d 1 /fThe actor then uses rundll32.exe and comsvcs.dll with its built-in MiniDump function to dump passwords from LSASS into a dump file. The command to accomplish this often specifies the output to save the passwords from LSASS. The file name is also reversed to evade detections (ssasl.dmp):
powershell.exe" /c Remove-Item -Path C:\windows\temp\ssasl.pmd
-Force -ErrorAction Ignore;
rundll32.exe C:\windows\System32\comsvcs.dll,
MiniDump (Get-Process lsass).id C:\windows\temp\ssasl.pmd full | out-host;
Compress-Archive C:\windows\temp\ssasl.pmd C:\windows\temp\[name].zipIdentifying WDigest use
As for the defensive side, monitoring the change in the registry path should provide a telltale sign that something nefarious is on the way. Even with a sysmon, you have to set a monitoring path for it to start logging changes in the registry.
WDigest use can be identified in two places: your domain controller logs, or your server logs (every server must be checked).
With Logpoint, we provide a custom sysmon configuration file and Nxlog sample. This line in particular targets WDigest.
\Control\SecurityProviders\WDigestOnce the path or the sysmon file is configured in the system, an out-of-the-box alert rule LP_Wdigest Registry Modification can be used to monitor the changes made to the registry path.
norm_id=WindowsSysmon event_id=13
target_object="*WDigest\UseLogonCredential" -user IN EXCLUDED_USERS
A pre-configured alert rule monitors the changes to the registry path.
As for the process dump, LP_Process Dump via Rundll32 and Comsvcs will trigger when the attacker or the tester tries to dump the passwords from LSASS into a dump file.
label="Process" label=Create
"process"="*\rundll32.exe"
command IN ["*comsvcs.dll*#24*", "*comsvcs.dll*MiniDump*" ] -user IN EXCLUDED_USERSAll new updated and existing rules can be downloaded from the Logpoint Service Desk.
NOTE: By default in Windows 8.1 and Windows Server 2012 R2 and later versions, caching credentials in memory for WDigest is disabled (the UseLogonCredential value defaults to 0 when the registry entry is not present).
The observed change in behavior when the UseLogonCredential value is set to 0 is that you may notice that credentials are required more frequently when you use WDigest.
Since this has been a long-running issue and a very old one at that, Microsoft released a patch back in 2014 that effectively disabled WDigest passwords from being stored in memory
Also, an excerpt from Microsoft addressing the issue, recommends users eliminate cleartext passwords from memory.
Removal of cleartext credentials from LSASS
This update prevents every Microsoft SSP in LSASS, besides WDigest, from storing the user’s cleartext password. WDigest still stores the user’s cleartext password because it cannot function without the user’s password (Microsoft does not want to break existing customer setups by shipping an update to disable this). Microsoft recommends users look through their domain controller logs for WDigest authentication logins (instructions provided below); if WDigest authentication is not being used, customers can apply the FixIt found on the KB article to disable WDigest. Doing this will eliminate all cleartext credentials from LSASS memory.
It’s important to realize that while cleartext credentials will no longer be stored, the NT hash and Kerberos TGT/Session key will still be stored and are considered credentials (without credential equivalents stored in memory, single sign-on would be impossible). Additionally, even though the cleartext credentials are no longer stored in memory, an attacker can use other techniques such as key loggers to recover cleartext passwords. Eliminating cleartext passwords from memory is useful and reduces risk, but it is not guaranteed to stop attackers.
For Windows 7, 8, Server 2008 R2, and Server 2012, you must install the aforementioned security update and then you’ll want to set the following registry key to 0.
Setting the registry key to 0 helps reduce risk from WDigest.
Path: HKEY_LOCAL_MACHINESystemCurrentControlSetControlSecurityProvidersWDigestUseLogonCredential
The easiest way to do this would be through group policy, but a quick script also works:
reg add
HKLMSYSTEMCurrentControlSetControlSecurityProvidersWDigest /v
UseLogonCredential /t REG_DWORD /d 0Once you’ve pushed the security update, and the registry key update to all of your servers, you can ensure you’ve done it successfully by querying the registry to see that it exists and is not set to 1.
reg query
HKLMSYSTEMCurrentControlSetControlSecurityProvidersWDigest /v
UseLogonCredentialNOTE: Both of the above changes will also trigger the alert as a change is being made to the specified path.
By default, later versions of Windows (8.1+ and 2012 R2+) do not require the security update, or setting the value to 0, as the default is 0 when not present. However, you should ensure that there haven’t been any manual modifications that set it back to 1.
Use the chart to help determine if you need to take action on your endpoints.
Remediation with Logpoint SOAR playbooks
Upon detecting traces of exploitation, analysts should isolate the host where the attack is taking place via a playbook and initiate an incident response playbook.
Detecting exploitation is simple and seamless because Logpoint is a unified SIEM+SOAR solution that uses an alert (SIEM event) to automatically trigger a SOAR playbook. You can set a playbook to run when a change has been made to the WDigest registry path. The playbook removes the user from Active Directory and changes the user password using a random password generator.
The playbook triggers when a change has been made to the WDigest registry path, automatically initiating a set of actions to investigate and respond to the change.
The playbook initiates a response that disables the user and resets the password.
Based on the organization’s policy and the incident response team procedures, an investigation playbook will collect as much data as possible and generate a report.
You can also generate reports from the playbook to document the steps of the investigation.
Conclusion
A configuration related to WDigest could hinder the security of your environment, specifically on the endpoint, by allowing an attacker to steal cleartext credentials from memory. There are measures you can take to remediate this and ensure that your endpoints and credentials are more secure. Microsoft’s security update (KB2871997) addresses the issue on older versions of Windows, whereas newer versions should be secured by default. Checking the registry on all of your Windows endpoints for the WDigest setting should be a priority, as the loss of credentials could lead to the loss of sensitive information. One way to do this is through command-line queries against all your hosts, but a quicker way is to automate this type of auditing against your endpoint and have the data presented to you in an easy-to-consume report.
