Five Challenges with Monitoring Active Directory Security Using Event Logs: Part 4

The last post, we discussed monitoring directory reads. One of the limitations of Active Directory is it offers no easy way to monitor suspicious read events, which can help you detect reconnaissance activity and stop an attack before it happens. Now let’s look at the next challenge, tracking authentication events.

Challenge Four – Tracking Authentication Events

With the recent surge of credential-based attacks, monitoring authentication patterns is critical to identify compromised accounts, signs of pass-the-hash and pass-the-ticket attacks, forged Kerberos tickets, or other exploits used to gain privileges and access to sensitive data. Active Directory captures events to monitor user logon and authentication activity on domain controllers, member servers, and workstations. Figure 4 identifies some of the events that may need to be collected to monitor user authentication and logon traffic across the domain.  

While there is certainly some useful information logged to help monitor for authentication-based attacks, the number of events produced can be overwhelming and prevent any meaningful analysis. In addition, there are some shortcomings of authentication logs that make this challenge even more significant.

Too Much Noise

While many authentication and logon events are user-initiated, many are also just background noise.  One common example is the application of Group Policies.  When a user logs into a member server that is joined to an Active Directory domain, the server will initiate a connection to a domain controller to retrieve Group Policy information.  This results in logon/logoff events appearing in the event log of the domain controller.  This process is repeated on an interval such as every 90 minutes, so these events continue to be created while a user is logged into a machine.  This results in events being created from every user who logs into any computer, which is a tremendous amount of activity in most organizations.   There is no way to disable these log records without also ignoring other valuable logon activity to the domain controllers.

Missing Information

While there may be an overabundance of events logged to track authentication and logon activity, these logs are missing certain key information that limits their usefulness.  For example, on domain controllers, you cannot track the logon type for a logon event.  This means there is no way to differentiate between users logging in through Remote Desktop, as opposed to a network logon through a mapped network drive.  This context is invaluable in determining if accounts are being used in the appropriate way.  The only way to gather this information is by collecting logs from every member server and attempting to correlate those with the logs from the domain controller.  

Additional protocol-specific information is missing from authentication logs as well.  For instance, Kerberos authentication events do not contain valuable information about the Kerberos tickets such as the ticket life and renewal life timestamps.  These are valuable indicators of forged tickets and without them, there is no way to detect attacks that take advantage of those features, such as the Golden Ticket exploit.  NTLM logs do not specify the NTLM version that was used, which is valuable when trying to determine how prevalent the use of different NTLM versions may be before disabling them in favor of more secure protocols.

Other blogs in the series:

• Five Challenges with Monitoring Active Directory Security Using Event Logs: Part 1
• Five Challenges with Monitoring Active Directory Security Using Event Logs: Part 2
• Five Challenges with Monitoring Active Directory Security Using Event Logs: Part 3

Click here to learn how STEALTHbits tackles Active Directory Management and Security.