Dangerous Group Nesting: Hidden Paths to Domain Admin

What Is Dangerous Group Nesting?

Dangerous group nesting happens when Active Directory group membership chains create effective privilege that reviewers did not intend to grant. A user, service account, or operational group may not be a direct member of Domain Admins, Enterprise Admins, Schema Admins, or another sensitive group. But if it is nested through one or more intermediate groups, the account can still inherit the resulting authorization context.

Active Directory security groups are authorization objects. They can be placed on access control lists, assigned rights, and added to other groups. That nesting is useful for administration, but it also makes privilege review harder. Direct membership answers only one question: who is explicitly in this group? Effective membership answers the more important question: who receives this privilege after all nested memberships are resolved?

The problem is common in long-lived domains. Groups survive migrations, reorganizations, mergers, application rebuilds, emergency changes, and ownership changes. A group that was created for server administration in 2016 can still be nested into a protected path in 2026 even though nobody on the current team remembers why.

How Group Nesting Creates Hidden Privilege

When Group A is a member of Group B, members of Group A inherit Group B's effective permissions. If Group B is a member of a Tier 0 group, Group A's members now have a Tier 0 path even if none of those accounts appear as direct members of the final privileged group.

That is the core risk: nested paths hide privilege in the middle of the chain. A direct review of Domain Admins may show only one or two groups. But each of those groups can contain other groups, service accounts, stale users, or shared operational identities.

Microsoft documents protected accounts and groups in Active Directory, including groups such as Domain Admins, Enterprise Admins, Schema Admins, Administrators, Account Operators, Backup Operators, Server Operators, Print Operators, and others. Those groups deserve special review because membership can grant powerful administrative capability or trigger protected-account behavior through AdminSDHolder.

Direct Membership vs Effective Membership

A useful review separates three views:

Only the third view gives a remediation plan. If a helpdesk user resolves into Domain Admins through five groups, removing the user from the final group is not the fix because the user is not directly there. You need to remove or redesign the group edge that creates the path.

Where Hidden Tier 0 Paths Usually Hide

Dangerous nesting problems usually come from predictable patterns:

• migration groups that were kept after a directory consolidation
• server administration groups nested upward for temporary troubleshooting
• backup, deployment, or monitoring accounts granted broad access during an outage
• shared operational groups used by multiple teams with no current owner
• application support groups that inherited rights from legacy admin groups
• groups created for one region or business unit and later reused elsewhere
• old project groups that still contain former employees or service accounts

A practical review starts from the top of the privilege boundary and walks downward. Start with Tier 0 groups and prove who can reach them transitively. Reviewing every group alphabetically wastes time and usually misses the path that matters.

The Attack Chain

Step 1 - Find the Nested Path

The attacker or assessor maps recursive membership from privileged groups. The goal is to find an account that is easier to compromise than a direct Domain Admin but still resolves into a privileged path.

Get-ADGroupMember -Identity 'Domain Admins' -Recursive |
  Select-Object SamAccountName, ObjectClass, DistinguishedName

Step 2 - Identify the Weakest Link

The weakest link is often not a named administrator. It may be a service account with an SPN, a stale user account, a shared operator account, or a large support group. The nested path turns that weaker identity into a meaningful escalation target.

Get-ADGroupMember -Identity 'Domain Admins' -Recursive |
  Where-Object {$_.objectClass -eq 'user'} |
  Get-ADUser -Properties Enabled, PasswordLastSet, ServicePrincipalName, LastLogonDate |
  Select-Object SamAccountName, Enabled, PasswordLastSet, LastLogonDate, ServicePrincipalName

Step 3 - Use Existing Authorization

If the compromised identity already inherits the required rights, the attacker does not need a new vulnerability in Active Directory. The directory already grants the access. That is why dangerous nesting is an attack-path issue, not only a hygiene issue.

Detection

Windows Event IDs

Monitor security group changes on domain controllers. Microsoft documents the key event families under Audit Security Group Management, and Microsoft Defender for Identity event collection also calls out these group-management events.

Do not alert only on direct additions to Domain Admins. Alert on changes to groups one or two hops below Tier 0, because that is where hidden paths are often created.

Practical Review Checks

Use recurring checks rather than one-time cleanup:

• export recursive membership for protected groups
• compare direct membership with effective membership
• flag service accounts, shared accounts, disabled users, and stale users in recursive paths
• identify groups with no owner, no description, or no recent review date
• verify whether group changes were approved and expected
• monitor for the same group edge being recreated after cleanup

Remediation

The goal is not to flatten every group. The goal is to remove hidden Tier 0 inheritance and make remaining privileged paths explicit, owned, and reviewable.

1. Audit Recursive Membership From Tier 0 Down

Start with the groups that define the privilege boundary.

$tier0Groups = @('Domain Admins','Enterprise Admins','Schema Admins','Administrators','Backup Operators')
$results = foreach ($group in $tier0Groups) {
  Get-ADGroupMember -Identity $group -Recursive | ForEach-Object {
    [PSCustomObject]@{
      RootGroup = $group
      Account = $_.SamAccountName
      Type = $_.ObjectClass
      DistinguishedName = $_.DistinguishedName
    }
  }
}
$results | Export-Csv tier0-recursive-membership.csv -NoTypeInformation

2. Find the Group Edge That Creates the Path

Removing a user from the wrong group does not fix the model. Find the intermediate group relationship that grants the privilege and decide whether it is still needed. If a server-admin group is nested into a domain-admin path, redesign the administrative model instead of making user-by-user exceptions.

3. Rebuild Tier Boundaries Explicitly

The point is to stop low-tier groups from inheriting higher-tier rights through convenience nesting. A helpdesk group should not become privileged because it was nested into a server admin group that was later nested upward.

4. Assign Ownership and Review Cadence

Every group near Tier 0 should have an owner, a purpose, and a review cadence. If nobody can explain why a group is nested into a privileged path, remove it or quarantine it until the dependency is proven. Document exceptions as exceptions, not as normal architecture.

What Not to Do

Do not remediate dangerous nesting by deleting groups blindly. Some groups may still support application administration, backup jobs, or operational workflows. The correct sequence is to identify the exact path, confirm ownership, remove unnecessary edges, and test the dependent workflow. Also avoid replacing nested privilege with direct user membership in the same protected group. That may make the path more visible, but it does not reduce the privilege. The goal is to reduce effective privilege and improve accountability, not merely make the group list shorter.

Validation After Cleanup

After remediation, prove that the path is gone:

• re-run recursive membership exports for protected groups
• confirm no shared account, service account, disabled account, or stale user still resolves into Tier 0
• review 4728, 4732, 4756, 4735, 4737, and 4755 events during and after remediation
• confirm remaining nested groups have an owner and documented purpose
• verify monitoring alerts on changes to groups beneath the privileged boundary
• compare graph results before and after cleanup so the removed path is clear

The validation target is simple: the environment should not depend on hidden privilege inheritance that only a graph query can explain after the fact.

How EtcSec Detects This

EtcSec maps the effective group graph rather than relying only on direct membership. That makes the finding useful for two reasons: it shows the full privilege path, and it helps reviewers identify which object in the chain is easiest for an attacker to compromise.

Related Reading

Review dangerous group nesting alongside Active Directory Attack Paths to Domain Admin, ACL Abuse and DCSync: The Silent Paths to Domain Admin, Active Directory Trust Attacks: From Child Domain to Forest Root, GPO Misconfigurations: How Group Policy Becomes an Attack Vector, and Stale Privileged Accounts: Hidden Risk in Active Directory. Nested privilege usually matters because it connects to another attack path.

Primary References

• Active Directory Security Groups
• Protected accounts and groups in Active Directory
• Audit Security Group Management
• 4732: A member was added to a security-enabled local group
• Defender for Identity event collection overview