One of our customers that had recently suffered a brutal cyber attack tasked us with a method to protect elevated groups from being queried for membership by their domain users.

I said, “That’s very specific.” My customer just looked at me and began to describe their situation.

In a nutshell, the attacker had delivered a payload to one of their users via email. With this payload, the attacker was able to execute commands and install software on the infected computer. As a “Domain User” the attacker was able to query the “Domain Admins” group for its members. This information was used to monitor or ‘sniff’ for authentication traffic and those credentials. The attacker was then able to capture a ‘Password Hash’ which was used in multiple ‘man-in-the-middle’ attacks on their environment.

This customer was already working on remediating the legacy systems that were preventing them from enabling Secure LDAP (LDAPS) and eliminating NTLM authentication (look for future blog posts on those subjects). As luck would have it, they got attacked before they were ready…

The master list of permissions for objects that are members of privileged groups is located in the AdminSDHolder container in Active Directory

The AdminSDHolder container is only visible in Active Directory Users and Computers (ADUC) after enabling Advanced Features.

Editing security properties on this object is the same as any other object.

By default inheritance is enabled and objects are applied based upon permissions higher in the forest. We must disable inheritance and remove any accounts or groups that do not need access by default. A good rule of thumb for identifying access is:

“..If the account or group looks like it was created by Microsoft it should probably be there.” Dont use this as the rule. We will talk about Elevated groups in detail in another post.

Once the non-standard accounts/groups (that don’t require elevated access) have been removed the last groups to remove are:

• Authenticated Users
• Domain Users
• Pre-Windows 2000 Compatible Access

This essentially will deny access to all users from ‘reading’ elevated group membership unless they are added to the ACL on the AdminSDHolder container.

It is recommended that a security group be created that has members or groups that are allowed to view the AdminSDHolder container. To do this, create a Security Group and apply it to the container with the following permissions:

• List Contents – Allow – This Object Only
• Read All Properties – Allow – This Object Only
• Read Permissions – Allow – This Object Only

The Bottom Line…

This method effectively removes domain users ability to read members in the elevated groups known as “Domain Admins” and all the other ‘Admins’ and Operators built-in groups in AD. It then gives that read permission to a security group.

I told my customer that what this procedure does is give an organization more time to identify the attacker in their environment. If the attacker is able to determine the group with read access, this method fails. Two of the best routes for companies to prevent an attack like this from occurring in their environment is to eliminate NTLM authentication and/or deploy secure LDAP (LDAPS) to encrypt Active Directory communications. You could then use (or also use) Local Administrator Password Solution LAPS to manage access to servers on-Prem.