Using SCOM to Detect WDigest Enumeration

Disclaimer: Due to changes in the MSFT corporate blogging policy, I’m moving all of my content to the following location. Please reference all future content from that location. Thanks.

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.