As the methods that attackers use to compromise credentials and data continue to evolve, it is increasingly important to monitor critical systems such as Active Directory (AD) for signs of malicious activities. Most customers turn to security information and event management (SIEM) products to provide this monitoring. While these solutions may be extremely powerful, they ultimately depend on the Windows event logs that are populated by Active Directory. Event logs can be very complicated to work with, and ultimately do not provide the information needed to monitor several key attack vectors within AD. By relying on event logs, customers face several challenges which prevent them from truly securing their organization. This blog will be the first in a five-part series that will explore five of those challenges.
Challenge 1 – Group Membership Changes
Active Directory security groups are the primary way users are granted privileges and access to information across servers, workstations, and applications. Groups such as Domain Admins, Enterprise Admins, and Schema Admins give members extensive privilege within an Active Directory environment. In addition to these groups, a typical organization will have a significant number of other security groups that provide privileged access across subsets of their environment.
Attackers will target these groups and their members to gain elevated privileges. Therefore, it is important to monitor changes to these groups. While Active Directory does track changes to security groups within the event log, key information is missing.
For example, if you add a user to the Domain Admins group, AD will generate an event such as the one pictured above. This event contains valuable information such as:
- The ID of the user who performed the change.
- The DN and class of the object that was changed (in this case indicating the Domain Admins group).
- The change details indicating a member was added/removed.
While this may seem like a complete set of details, some key information is missing.
Where Did the Change Come From?
The event logs give no indication of the source of the change. A change to the Domain Admins group from a jump server or domain controller may be normal within an organization. A change from a non-administrative workstation or another internet-facing machine may be a telltale sign of an attack. It is critical to know the source of the change and alert on changes being made from abnormal locations.
Effective Group Membership Changes
Active Directory only logs changes to the direct membership of a group. However, groups can contain other groups as members. Therefore, to successfully monitor changes to any group, you must monitor the group itself, and every group nested within it. To add to that complexity, those relationships can change frequently. Active Directory does not support the ability to monitor changes to the “effective membership” of a group, and therefore most organizations are not truly monitoring groups for membership changes.
Inconsistencies with Event Logs
Depending on how groups are changed within Active Directory, the events that are generated will look differently. This can cause confusion and misinformation within SIEM products. For example, if a user is added to a group using Active Directory Service Interfaces (ADSI), the event log will show one remove event for every existing group member, followed by an event adding back every group member, followed by an event adding the new user. Therefore adding a user to a group with 50 members will generate 101 event log entries to represent a single user being added. If changes are made using LDAP, the object GUID may appear rather than the distinguished name of the object. These types of inconsistencies make it extremely frustrating to build rules within SIEM and take action on the data collected.
In the next post, we’ll reveal another challenge of monitoring your company’s critical systems.