Skip to main content

Group Membership

The most Privileged Account, or Group, is not always the best to use for Persistence. Privileged Groups are Monitored more closely for changes than others. Any Group that classifies as a Protected Group, such as Domain Admins or Enterprise Admins, receive additional Security Scrutiny.

  • The IT Support Group can be used to gain Privileges such as Force Changing User Passwords. Although, in most cases, we won't be able to reset the Passwords of Privileged Users, having the ability to Reset even Low-Privileged Users can allow us to spread to Workstations.
  • Groups that provide Local Administrator rights are often not Monitored as closely as Protected Groups. With Local Administrator rights to the correct Hosts through Group Membership of a Network Support Group, we may have good Persistence that can be used to compromise the Domain.
  • It is not always about Direct Privileges. Sometimes Groups with Indirect Privileges, such as ownership over Group Policy Objects (GPOs), can be just as Good for Persistence.

Nested Groups​

In most Organizations, there are a significant amount of Recursive Groups. A Recursive Group is a Group that is a Member of another Group. Group Nesting is used to create a more Organized structure in AD.

For example the IT Support is very Generic. So perhaps there are subgroups like Helpdesk, Access Card Managers, and Network Managers underneath this Group. We can add all of these Groups as Members to the IT Support Group, which gives all Users in these Subgroups the Permissions and Privileges associated with the IT Support Group, but we can then assign more granular Permissions and Privileges for each of the Subgroups.

While Group Nesting helps to organize AD, it does Reduce the Visibility of Effective Access. Take our IT Support example again. If we query AD for Membership of the IT Support Group, it would respond with a count of Three. However, this count is not really true since it is Three Groups. To get an idea for Effective Access, we would now have to Enumerate those Subgroups as well. But those Subgroups can also have Subgroups.

This also becomes a Monitoring Problem. Let's say, for Instance, we have an Alert that fires off when a new Member is added to the Domain Admins Group. That is a good Alert to have, but it won't fire off if a user is added to a Subgroup within the Domain Admins Group. This is a very common problem since AD is managed by the AD Team, and Alerting and Monitoring are managed by the InfoSec Team. All we need is a little bit of Miscommunication, and the Alert is no longer valid since Subgroups are used.

As an Attacker, we can leverage this reduced visibility to perform Persistence. Instead of targeting the Privileged Groups that would provide us with access to the Environment, we focus our attention on the Subgroups instead. Rather than adding ourselves to a Privileged Group that would raise an alert, we add ourselves to a Subgroup that is not being Monitored.