Security Monitoring: Detecting Wdigest Authentication

One of the noisier items in the Security Monitoring Management Pack is the monitor that triggers against all Windows 2008 R2 and below systems if the proper WDigest post patch configurations have not been applied. WDigest is another older protocol that was addressed with KB 2871997. Prior to 2008R2, Wdigest credentials remained in the LSA of the Operating System in an unencrypted state, allowing a tool such as Mimikatz to enumerate the password of all logged on accounts in clear text. While KB2871997 allowed for a fix in the vulnerability, this still required setting a registry key in order to turn off WDigest.

The main reason for this is the risk of what would break if this authentication mechanism was disabled. As with many legacy protocols, legacy applications that have not been updated are vulnerable, as such, this protocol remains on by default. Ultimately, this poses a significant risk to the organization. If they leave it on, they are at risk to an attacker. If it’s shut off, they could potentially break a critical application.

Fortunately, this is a traceable event. Kurt Falde lists the details here.

As such, the security monitoring MP will now have a collection rule looking for WDigest events. This will not work out of the box, however.

Step 1:  Enable the “Audit Credential Validation” advanced audit policy. In this case, look for successes.

Step 2: Create a collection rule targeted at Domain Controllers looking for event 4776 in the security log. Parameter 1 must also contain WDigest.

I would note that the next release of the security monitoring MP (currently slated for early 2018) will have the rule setup for Step 2 along with a pre-canned report. Once that is out, only Step 1 will be needed.

Feel free to add comments or reach out to me on LinkedIn, especially if you are interested in evaluating the next release.

Using SCOM to Detect WDigest Enumeration

In a recent conversation with fellow colleague Jessica Payne, it was noted that one of the most common forms of credential theft presently involves using exposed Wdigest credentials.  Wdigest, while not commonly used today, is still enabled by default in large part because of legacy applications that use it. While this was fine back in the 2000/2003 days, it is one of many protocols that is often tied to legacy applications and is no longer a secure protocol by today’s standards.

Exposing WDigest credentials is rather easy.  Kurt Falde wrote a nice article showing how simple this attack can be; and in my own lab, I observed the same behavior. Older operating systems will show clear text passwords.  If you can expose a clear text password, there’s no need to do PtH, PtT, or really any other attack. Fixing this involves a hotfix (KB2871997) along with a registry key.  The value “UseLogonCredential” must be created and set to 0 in the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest key. This effectively turns off the ability to expose WDigest credentials in clear text, but doing so can also break legacy applications. It goes without saying that before you do this, you should probably test it and ideally fix any older applications.

Now that said, this is where SCOM comes in.  Because of the nature of this type of authentication, that registry key is very important. Fortunately, registry monitoring is something that SCOM can do natively.  An attacker could potentially change the value of this key or delete it all together. As such, two SCOM monitors are needed.  The first would be to monitor for the existence of said key.  Kevin Holman detailed how to do that here.  If the registry key is not present, your server will show unhealthy.

The second would be to monitor the value of the same registry key.  Again, Kevin has shown us how to do that.  An attacker could potentially change the value of said key to allow them to expose WDigest credentials.

As for logging it, unfortunately, I wasn’t able to find any sort of bread crumb left behind when testing.  That unfortunately means that we cannot use SCOM to detect WDigest enumeration when it occurs. We can however, use a GPO to set these keys and have SCOM monitor them for changes.

I’m working on a management pack that contains these monitors along with additional security rules along with other security related items that SCOM can provide. My only test environment is my lab, which is hardly a production grade environment. I do welcome feedback. While I cannot support this management pack, I can provide it if this is something you are interested in trying it out. My main goal is to keep the noise down to a minimum so that each alert is actionable. While that is not always easy to do, trying this out in other environments will go along way to getting it to that point.  If this is something you are interested in testing, please hit me up on linked in.