So far in this series, we’ve learned that changes to groups with extensive privilege within an Active Directory (AD) environment are the target for many hackers. We then looked at how Active Directory isn’t able to log the changes made to Group Policy settings, which can lead to an attack or production outage.
Challenge 3 – Monitoring Directory Reads
Another aspect of detecting Active Directory attacks is understanding how users are reading and enumerating AD objects. When attackers are looking to gain a foothold within your organization, they will initially perform reconnaissance and look to enumerate critical accounts, groups, and servers. This provides information necessary to discover attack paths that lead to escalated privileges and credentials, and ultimately to sensitive data. By monitoring for suspicious read events you can detect reconnaissance activity and stop an attack before it is too late. Unfortunately, Active Directory offers no easy way to monitor these types of events. Some of the limitations include:
Too Much Noise
Microsoft is capable of logging read events in order to see who is exploring Active Directory, however doing so creates so much noise in the event log it is nearly impossible to find any valuable information. For example, if a user were to look at the Domain Admins group it could generate more than 200 events in the event log. This includes events such as the one pictured above, indicating a property of Domain Admins was read. Dozens of these events will be generated regardless of what the user was looking at, in addition to other events such as listing the contents of OUs and reading information about the group members.
With hundreds of events appearing for a single instance of a user looking at a group, it becomes extremely challenging to separate the meaningful information from the extraneous.
Where Did the Read Come From?
Even if it were somehow possible to make sense out of the events generated for reading domain objects, there is no way to identify where the read event originated from. In the image above you can clearly see which user was involved in the read of Domain Admins, but you do not know which computer this read came from. This is crucial information if you are looking to determine a harmless read from a malicious act of reconnaissance.
Monitoring Access Denied Events
One common reason for monitoring directory access events is to identify where users are trying to read information they do not have the rights to see. Valuable information can be stored within Active Directory attributes that could be queried and ultimately exploited by attackers. For instance, by leveraging the Local Administrator Password Solution (LAPS), Active Directory will store clear-text passwords for administrative accounts in user attributes. If the logs were to show users trying to read these attributes, it may be indicative of a user trying to compromise these privileged credentials. Unfortunately, every user who views a user object for any purpose will generate access failure events for any attributes they do not have rights to read, even if they were not intending to read those attributes. Because of this, monitoring for failed access events as a sign of attack is not a viable option using event logs.
Monitoring LDAP Queries
LDAP queries are commonly used to explore Active Directory to discover users, groups, and computers. Microsoft provides no easy way to monitor LDAP queries to see the query that was issued and where it came from. Even turning on diagnostic level LDAP monitoring provides little value and is not advised by Microsoft, as it will generate a tremendous amount of noise in the event logs.
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