Detecting Shadow Admin accounts

1) What is a “shadow admin” in AD?

A shadow admin is any user, group, or service principal that can achieve admin outcomes—such as modifying privileged group membership, controlling GPOs, resetting admin credentials, or replicating directory secrets—without being a direct member of obvious privileged groups.

Why they’re hard to spot

• They hide in structure: nested groups, dynamic membership rules, or legacy “helpdesk” groups.
• They hide in permissions: delegated OU rights, object-level ACLs, or control of GPO links.
• They hide in “control plane” objects: domain root, AdminSDHolder, Domain Controllers OU, key GPOs.

If your AD has ever been delegated “carefully” and then evolved for years, you should assume shadow admins exist until proven otherwise. Permission sprawl is the usual root cause—see Excess Permissions: Lessons from Legacy Setups.

2) Where shadow admin power typically comes from

A) Group nesting paths

A user can look harmless while being a transitive member of a privileged group through nested groups. This is common when teams create “role groups” and nest them into admin groups. Use a path-aware approach described in Auditing Nested Group Memberships.

B) Delegated OU permissions and object ACLs

Delegation is legitimate—but it can silently grant rights like Reset Password, Write members, WriteDACL, GenericAll, or AllExtendedRights in the wrong places. If you delegate, do it intentionally and minimally (see How to delegate OU permissions with minimal risk).

C) GPO control paths

Anyone who can edit a GPO that applies to Domain Controllers (or Tier 0 servers) can become an admin quickly. The risk increases when GPO security filtering is misunderstood or becomes inconsistent over time.

D) Replication and directory “secrets” access (DCSync-style permissions)

AD replication permissions on the domain root can allow extraction of credential material without “traditional admin membership.” You don’t need to think offensively to detect it—you just need to audit who holds the relevant extended rights.

E) Privileged account hygiene gaps

Shadow admin paths become catastrophic when privileged accounts are poorly protected. Review your privileged identity posture in Securing administrator accounts in Active Directory.

3) Build a privilege inventory baseline

The goal is to create a baseline that answers: who can change what, where, and how? Start with Tier 0 (“control plane”) assets:

• Domain root naming context (e.g., DC=corp,DC=example,DC=com)
• AdminSDHolder (protected objects control)
• Domain Controllers OU
• Group Policy Objects (especially those linked to Domain Controllers / Tier 0)
• Privileged groups (Domain Admins, Enterprise Admins, Administrators, Schema Admins, etc.)

If you’re refreshing fundamentals on how permissions work (inheritance, explicit ACEs, effective rights), keep Active Directory Permissions Explained open while you build your inventory.

4) Core detection checks (the practical checklist)

# PowerShell (RSAT ActiveDirectory module)
Import-Module ActiveDirectory

$privGroups = @(
"Domain Admins","Enterprise Admins","Administrators","Schema Admins",
"Account Operators","Server Operators","Backup Operators","Print Operators"
)

foreach ($g in $privGroups) {
try {
Get-ADGroupMember -Identity $g -Recursive |
Select-Object @{n="PrivGroup";e={$g}}, Name, SamAccountName, objectClass |
Export-Csv -NoTypeInformation -Append ".\PrivGroup_TransitiveMembers.csv"
} catch {
Write-Warning "Could not read group: $g"
}
}

# PowerShell (requires AD: drive)
Import-Module ActiveDirectory
Set-Location AD:

Replace with your domain DN
$domainDN = (Get-ADDomain).DistinguishedName

Collect ACEs on the domain root
$acl = Get-Acl ("AD:" + $domainDN)

Flag potentially dangerous rights (coarse first pass; refine for your environment)
$dangerRights = @("GenericAll","WriteDacl","WriteOwner","GenericWrite","AllExtendedRights")

$acl.Access |
Where-Object {
($dangerRights -contains $.ActiveDirectoryRights.ToString()) -or
($.ActiveDirectoryRights.ToString() -match "WriteDacl|WriteOwner|GenericAll|AllExtendedRights")
} |
Select-Object IdentityReference, ActiveDirectoryRights, AccessControlType, ObjectType, InheritanceType |
Export-Csv -NoTypeInformation ".\Tier0_DomainRoot_DangerousAces.csv"

# Find protected users/groups (adminCount=1)
Get-ADObject -LDAPFilter "(adminCount=1)" -SearchBase (Get-ADDomain).DistinguishedName -Properties adminCount |
Select-Object Name, ObjectClass, DistinguishedName |
Export-Csv -NoTypeInformation ".\AdminCount1_Objects.csv"

# Requires GroupPolicy module (on management machine / server with GPMC)
Import-Module GroupPolicy

Example: export permissions for all GPOs (review & filter by high-impact ones)
Get-GPO -All | ForEach-Object {
$gpo = $_
Get-GPPermission -Guid $gpo.Id -All |
Select-Object @{n="GPO";e={$gpo.DisplayName}}, Trustee, TrusteeType, Permission |
Export-Csv -NoTypeInformation -Append ".\GPO_Permissions_All.csv"
}

5) Logging & alerting that actually catches shadow admin creation

Detection isn’t only inventory—it’s also change monitoring. Alert on the actions that create or extend shadow-admin power:

High-signal event categories to monitor

• Privileged group membership changes (adds/removes in admin groups, including nested groups)
• Directory object permission changes (ACL edits on Tier 0 objects)
• GPO changes and permissions (edit rights changes; modifications to high-impact GPO settings)
• Replication-related permission changes (extended rights on domain root)

Practical guidance

• Enable and forward Directory Service change auditing and Group Policy change auditing to your SIEM. Focus on where the change occurred (domain root, AdminSDHolder, privileged groups, DC OU).
• Baseline first: alerting without a baseline produces noise and gets ignored.
• Build “watch lists” of Tier 0 objects and alert on any permission delta.

Tip: treat ACL changes like code changes—export, diff, review, approve. If you can’t diff your Tier 0 permissions, you don’t really control them.

6) Remediation: remove shadow admin paths safely

Start with the highest-risk removals

1. Remove unexpected principals from Tier 0 ACLs (domain root, AdminSDHolder, DC OU).
2. Break dangerous nesting: remove business-role groups nested into privileged groups.
3. Lock down GPO editing on Tier 0-linked policies; restrict link rights as well.
4. Fix delegation scope: reduce OU delegation to task-specific rights and smallest OU scope.
5. Harden privileged accounts: separate admin accounts, MFA where applicable, PAWs, strong monitoring.

Prevent recurrence

• Adopt least privilege as an enforced engineering rule, not a suggestion. Permission sprawl returns unless you continuously govern it (see Excess Permissions: Lessons from Legacy Setups).
• Document a “delegation catalog” (what tasks exist, what rights they need, where they apply).
• Require change control for Tier 0 permissions and Tier 0 GPOs.

7) Operational runbook for ongoing shadow admin detection

Weekly

• Export transitive membership of privileged groups; diff vs last week.
• Export GPO permissions; diff Tier 0 policies and their trustees.

Monthly

• Re-scan Tier 0 ACLs (domain root, AdminSDHolder, DC OU); review all deltas.
• Review delegation on high-risk OUs and confirm it still matches the delegation catalog.

Quarterly

• Run a privilege-path assessment (graph-based if possible) and validate that “expected admins” match reality.
• Review privileged account controls and emergency access procedures.

Definition of done

You’re in a strong place when you can answer—quickly and confidently:

• Who can become an admin?
• Through which path?
• What log/alert will fire when that path is created or used?
• How fast can we revoke it?