KB2871997 and Wdigest - Part 2

 

If you got here inadvertently glance at Part 1 as well.  https://blogs.technet.com/b/srd/archive/2014/06/05/an-overview-of-kb2871997.aspx has a great section on this already and discusses how to identify Wdigest use by looking at DC Security Event logs to see if you have any events that show Wdigest usage.  If you are fortunate enough to have a SIEM solution in your environment that is capturing ALL Domain Controller security event logs it should be rather simple to search through those on your SIEM solution and parse out Event ID 4776.  If however you need another method you can use the following method to perform selected event forwarding from DC’s or Servers to a centralized server.

First of all the Event ID 4264 is the event that occurs on the IIS server.  Gathering this event means that you need to ensure that all servers in your environment will forward this event.  Below is one of these events showing that a domain user logged into this server using Wdigest from a specific client IP address.  Truthfully we don’t really care a lot about the user/client but are more interested in the fact that this server is accepting Wdigest auth for some resource and that is what would need to be investigated and changed.

Gathering these events from all servers in an org though is less feasible than gathering the events from an authentication perspective from the Domain Controllers in a forest.  For each of the events that occurs above there will also be a correlating authentication event that occurs in your Domain Controller event logs that looks like the following.

One thing to note here is that for these to show up in your Domain Controller Event logs you need to be sure that you have the following Auditing set in your GPO’s applying to your DC’s  Computer Configuration>Windows Settings>Security Settings>Advanced Audit Policy Configuration>Audit Policies>Account Logon>Audit Credential Validation>Success (you could do failures as well but really we want to know about actual working WDigest auth in an environment before disabling it)

In order to determine if WDigest is being used in your environment you can use a WEF setup to monitor these events on your DC’s.  While there are various details that can complicate a WEF setup I’m going to try to keep this as simple as possible and let you know you need two configurations:

• • Subscription configured on the subscription server that lets the DC’s know which event(s) to forward
  • GPO configuring your DC’s and pointing them to a subscription server

On the subscription server side open up event viewer and right click Subscriptions and Create Subscription

Give it a name, description, leave Forwarded Events as the event log the events will be dropped into on this server.  Ensure you select Source Computer Initiated as this means the clients are responsible for sending vs the server having to reach into the clients and parse things out and pull back. Select Computer Groups and put in a group of computers that are allowed to pull this subscription, in this scenario we will use the existing Domain Controllers group (if you have a multi-domain forest you would need other groups possibly).

Next up is to Select Events that we want clients to forward .. first up click on the XML tab up top as we need to get more complicated than just putting in an event ID. Check the box to “Edit query manually” and input the following

<QueryList>
  <Query Id="0" Path="Security">
    <Select Path="Security">*[System[(EventID=4776)]] and *[EventData[Data[@Name='PackageName'] and (Data='WDigest')]]</Select>
  </Query>
</QueryList>

We are basically using Xpath filtering on event log XML data to say we only want EventId’s 4776 but more specifically we want that Event ID only if it has an XML Field of PackageName with a value of Wdigest. If you wanted you could also take it a step further and put something like this

<QueryList>
  <Query Id="0" Path="Security">
    <Select Path="Security">*[System[(EventID=4776)]] and *[EventData[Data[@Name='PackageName'] and (Data='WDigest')]] and *[EventData[Data[@Name='Status'] and (Data='0x0')]]</Select>
  </Query>
</QueryList>

Which more tightly constrains to just WDigest auth events with a status code of 0x0 (i.e. it worked/successful logon)

Note: if you get errors copy it to notepad first before pasting in there as sometimes it picks up things when copying from a browser/word etc.

This should get you something looking like this:

Click OK and Ok out of the subscription setup.  At this point you should have a new subscription now on your subscription server

Now for the client side (the Domain Controllers) we need to configure a GPO telling them where the subscription server is.  In a new GPO linked to your DC’s you want to set the following setting Computer Configuration > Policies > Admin Templates > Windows Components > Event Forwarding > Configure target Subscription Manager.  Fill it out according the help and as listed below inserting your subscription server name.  I’m using HTTP and not HTTPS as WS-MAN is already Kerberos encrypted by default and setting up HTTPS adds more complexity.

If you have ever used WEF before you may have found that by default WEF cannot forward Security Event log entries.  This occurs because the service that WEF runs under on the clients uses the Network Service account which does not have rights to “read” from the Security Event Log.  You can check the current permissions on your Security event logs on a DC by running “wevtutil gl security”.

The channelAccess property has in SDDL format which security principals have rights to the Security Event log.  By default this includes SY=System, BA=Builtin Admins, and S-1-5-32-573=Event Log Readers. Network Service is not in any of those groups.  So there are a number of different ways to work around this issue.

• Add NT Authority\Network Service to Event Log Readers group (I’m not a big fan of this especially when doing it for DC’s as technically you are doing this for a wider constraint than just DC’s by adding this to a domain group and I’m not sure where else this is relaxing permissions at)
• Change the WinRM/Event Collector service to run under System (again not a great fix from a security perspective)
• Modify the ACL / channelAccess on your Security Event logs on DC’s to allow the Network Service account read access to them (my preferred fix)

If you are going to modify the channelAccess for the Security Event logs on DC’s you will want to first dump out the existing ACE or permissions being used on a DC by running the wevtutil gl security.  Copy the  line starting after channelAccess: so you should end up with something like O:BAG:SYD:(A;;0xf0005;;;SY)(A;;0x5;;;BA)(A;;0x1;;;S-1-5-32-573) if you haven’t already modified their permissions in any way. We are going to append (A;;0x1;;;NS) which will give the Network Service the same level of rights as the Event Log Readers to the Security event log.  We can modify this permission either manually on a server via the wevtutil command or for multiple servers we will use the following GPO setting>

Computer Configuration>Administrative Templates>Windows Components>Event Log Service>Security>Configure log access

Paste in the full SDDL string O:BAG:SYD:(A;;0xf0005;;;SY)(A;;0x5;;;BA)(A;;0x1;;;S-1-5-32-573)(A;;0x1;;;NS) and apply that to your DC’s which should then allow WEF to forward events from your Security logs as well.

At this point once your DC’s pick up the modified permissions on the Security Event Log and the pointer to a subscription server they will pull the subscription and begin forwarding events with regards to WDigest auth to this subscription server.

In a perfect world you hopefully will not get anything here as preferably there is no WDigest in use which will make it easier to disable in your organization.  You might want to try setting up an IIS box with just WDigest auth enabled and testing a few logons just to generate events and ensure your WEF setup is properly working.  If you do have events then correlate a list of those servers accepting WDigest and determine some course of action to switch them to windows integrated/Kerberos authentication instead.

Comments

• Anonymous
  December 08, 2015
  Small typo, you've stated Event ID 4264, but the screenshot shows Event ID 4624.