Enumerating Privileged Groups

ActiveDirectoryDiscoverybeginnerT1069.00212 min

Enumerating privileged groups is a concrete discovery technique that identifies which accounts have elevated control over an Active Directory environment. This lesson explains what the attacker is looking for, which groups matter and why, what group membership reveals about paths to domain compromise, and how to communicate findings clearly in interviews, reports, and stakeholder conversations.

This lesson builds on

Theory

Why It Matters

Privileged group membership is one of the most direct indicators of where power sits in an AD environment. Knowing who belongs to Domain Admins, Enterprise Admins, and other high-value groups is often the difference between aimless enumeration and targeted attack planning. This is also a common interview question: interviewers expect candidates to know which groups matter, why they matter, and how to turn that knowledge into actionable findings rather than just listing group names.

Preconditions

Enumerating privileged group memberships requires an authenticated domain user account at any privilege level. Active Directory stores group membership data in the directory and makes it readable by any authenticated user via LDAP. No elevated privileges are needed to query which users, service accounts, or computer accounts belong to any group in the domain, including the most sensitive administrative groups.

The attacker needs either a domain-joined host or network access to a domain controller with valid credentials.

Key Concepts

  • Domain Admins — the most commonly targeted group; members have full administrative control over every object in the domain; even one unnecessary member expands the attack surface significantly
  • Enterprise Admins — exists only in the forest root domain; members have administrative control over every domain in the forest; compromising one Enterprise Admin account means full forest compromise
  • Server Operators and Backup Operators — often overlooked groups that grant significant privileges; Server Operators can log into domain controllers and manage services; Backup Operators can read any file on the DC including the AD database
  • Nested group membership — a user who is a member of Group A, which is a member of Domain Admins, is effectively a Domain Admin; nested memberships create indirect privilege paths that administrators often miss during access reviews
  • Service accounts in privileged groups — service accounts placed in Domain Admins or similar groups for convenience are high-value targets because they often have weak, static passwords and are Kerberoastable
  • Account Operators and DnsAdmins — groups with enough privilege to escalate to domain compromise through specific abuse paths; Account Operators can modify non-protected accounts; DnsAdmins can load arbitrary DLLs on the DC

Why It Works

Active Directory stores group membership as attributes on both the group object (the member attribute) and the user object (the memberOf attribute), and these attributes are readable by any authenticated user via LDAP by default. This accessibility exists by design: applications, services, and workstations need to resolve group memberships to enforce access control.

An attacker exploits this same accessibility to enumerate every member of every privileged group in the domain using standard LDAP queries. The directory does not distinguish between a legitimate service resolving group membership and an attacker mapping administrative control.

What the Attacker Gains

The attacker gains a precise map of who controls the domain. They learn which user accounts are Domain Admins, which service accounts have been placed in privileged groups (often unnecessarily), whether nested group memberships create indirect paths to administrative access, and how many accounts hold each privilege level.

This information directly shapes every subsequent attack. Kerberoastable service accounts in privileged groups become priority targets. Accounts with weak password hygiene in administrative groups become spray targets, and the total count of privileged accounts reveals whether the environment follows least-privilege principles or has privilege sprawl.

Where It Fits in the Attack Chain

Privileged group enumeration is one of the first discovery steps after gaining any domain user credentials. It sits early in the attack chain because the results inform almost every subsequent technique: which accounts to target with Kerberoasting, which accounts to prioritize for password spraying, which BloodHound paths are worth pursuing, and where lateral movement should aim.

In a realistic engagement, the attacker enumerates privileged groups within minutes of obtaining domain access, long before executing any credential access or privilege escalation technique.

Tools & Examples

  • net group "Domain Admins" /domain — Windows built-in command that lists members of a specific domain group
  • PowerView Get-DomainGroupMember -Identity "Domain Admins" -Recurse — enumerates direct and nested members of a group recursively
  • BloodHound — visualizes group memberships and identifies indirect privilege paths through nested groups and ACL relationships
  • ldapsearch — LDAP query for the member attribute of privileged group objects; works from any platform with domain credentials
  • CrackMapExec smb --groups — enumerates domain groups and their members over SMB

Defender's Perspective

  • Audit privileged group memberships regularly. Every member of Domain Admins, Enterprise Admins, Server Operators, Backup Operators, and Account Operators should have a documented business justification.
  • Remove service accounts from privileged groups. If a service requires specific permissions, delegate those permissions directly rather than granting full administrative access through group membership.
  • Flatten unnecessary group nesting. Nested memberships create indirect privilege paths that are difficult to audit manually and are trivially discovered by attackers with BloodHound.
  • Monitor changes to sensitive group memberships. Alert on any addition to Domain Admins, Enterprise Admins, and other Tier 0 groups through real-time event log monitoring (Event ID 4728, 4732, 4756).
  • Implement a tiered access model that limits the number of accounts with domain-wide administrative privileges.

Communication

How to Explain It in an Interview

Enumerating privileged groups is one of the first things I do after obtaining domain credentials because it tells me exactly where administrative control sits in the environment and which accounts are worth targeting. Any domain user can query group memberships via LDAP, so I enumerate Domain Admins, Enterprise Admins, Server Operators, Backup Operators, and other high-value groups to build a picture of who controls the domain. I pay close attention to nested memberships, because a user who is a member of a group that is nested into Domain Admins is effectively a Domain Admin even though they do not appear in the direct member list. I also look for service accounts in privileged groups, because those are often Kerberoastable with weak passwords.

The goal is not just to list names — it is to identify which accounts represent the shortest path to domain compromise and which ones are likely to have exploitable weaknesses.

How to Explain It to a Stakeholder

Privileged group enumeration is when an attacker with any employee-level account reads your directory to find out which accounts have administrative control over the entire domain.

The risk is that any compromised account can see this information, and it tells the attacker exactly which accounts to target next. If service accounts or unnecessary users are in administrative groups, the attacker knows those are high-value targets. The fix is reducing the number of accounts in privileged groups to the absolute minimum required, removing service accounts that do not need full administrative access, and monitoring for unauthorized changes to these groups.

How It Might Appear in a Report

Finding: Excessive Privileged Group Membership. During the assessment, the operator enumerated domain group memberships and identified 14 accounts in the Domain Admins group, including three service accounts (svc_sqlprod, svc_backup, svc_monitoring) and two accounts that had not authenticated in over 90 days. The svc_sqlprod service account was subsequently Kerberoasted due to its registered SPN and weak password. Nested group membership analysis revealed an additional six accounts with indirect Domain Admin access through nested group chains.

Severity: High.

Recommendation: Reduce Domain Admins membership to the minimum required accounts. Remove all service accounts from Domain Admins and delegate only the specific permissions they require. Disable or remove stale accounts that have not authenticated recently. Flatten unnecessary group nesting.

Common Weak Answers

  • Listing 'Domain Admins' as the only group that matters. Privileged groups also include Enterprise Admins, Server Operators, Backup Operators, Account Operators, DnsAdmins, and any group with delegated control over sensitive objects.
  • Saying 'I enumerate groups' without explaining what specific information is gained and how it shapes the next steps in the engagement.
  • Not mentioning nested group memberships. Direct membership queries miss indirect privilege paths, which are common in real environments and are a frequent source of unreviewed administrative access.
  • Treating the enumeration as a checklist item rather than an analytical step. The value is not in running the command — it is in identifying which specific accounts represent exploitable paths to domain compromise.
  • Ignoring service accounts in privileged groups. Service accounts with weak passwords and SPNs in Domain Admins are among the highest-value Kerberoasting targets in any environment.

Likely Follow-Up Questions

  • Beyond Domain Admins, which groups would you enumerate and why?
  • How does nested group membership create privilege paths that are not visible in a direct membership query?
  • If you found a service account in Domain Admins with a registered SPN, what would your next step be and why?
  • How would you explain to a client why having 14 Domain Admins is a finding, even if all of them are legitimate employees?
  • What is the difference between enumerating group memberships and using BloodHound for privilege path analysis?

Further Reading