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.
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.