Shadow admin accounts hold delegated permissions that let them reset passwords, modify Group Policy, or take over other accounts — without ever showing up in the Domain Admins or Enterprise Admins group. Most Active Directory environments carry a handful of these accounts by 2026, and standard group-membership audits never catch them.
- Detect shadow admin accounts in Active Directory by auditing ACLs, not just Domain Admins group membership.
- BloodHound and PingCastle map attack paths but miss drift without repeat scans on a schedule.
- Nested group chains hide most shadow admins; trace membership recursively, not just direct assignment.
- Stale service accounts with forgotten admin rights are the most common shadow admin pattern in 2026 audits.
Why this matters
A shadow admin doesn't need to be in a privileged group to act like one. An account with GenericAll, WriteDacl, WriteOwner, or ForceChangePassword rights on a privileged object can reset that object's password or rewrite its permissions directly — effectively becoming Domain Admin without membership ever changing.
Attackers who compromise a low-privilege account go looking for exactly this. It's how a phished help desk login turns into full domain control in a single lateral hop, and it's the reason detecting stale and orphaned privileged accounts has to run alongside shadow admin detection rather than after it — the two problems overlap in most environments.
How to detect shadow admin accounts in Active Directory: the audit checklist
Detection means auditing access control entries (ACEs) across every AD object, not scanning group membership lists. Run these steps in order:
- Map ACLs on every user, group, and OU object — not just the objects you assume are sensitive. Shadow admin rights often sit on OUs that contain privileged accounts, not on the accounts themselves.
- Query for dangerous ACE types: GenericAll, GenericWrite, WriteDacl, WriteOwner, WriteProperty on member attributes, ForceChangePassword, and AllExtendedRights. Any of these on a privileged object is an effective admin path.
- Trace nested group chains recursively. An account two or three groups deep that eventually lands in Domain Admins is functionally a Domain Admin, even though a direct-membership check shows nothing.
- Cross-reference service accounts and inactive logins against elevated ACE grants. Forgotten service accounts with broad rights are the single most common shadow admin pattern.
- Run BloodHound, SharpHound, PingCastle, or Purple Knight against the domain on a repeating schedule, not once. ACL drift happens every time a help desk ticket grants a one-off permission.
- Validate results against a known-good baseline of who is supposed to hold administrative rights, so new grants stand out immediately instead of blending into noise.
| Method | What it catches | Limitation |
|---|---|---|
| Native AD tools (dsacls, ADUC) | Direct ACE grants on a single object | No recursive chain analysis, manual per-object review |
| BloodHound / SharpHound | Full attack-path graph including nested groups and ACL abuse | Point-in-time snapshot; needs a rerun to catch new drift |
| PingCastle / Purple Knight | Scored risk indicators against known misconfigurations | Rule-based, misses novel ACE combinations |
| Continuous privileged access monitoring | Alerts on new ACE grants and group changes | Requires deployment and a tuned baseline |
Verdict: a single BloodHound scan finds today's shadow admins; only a repeating audit plus continuous monitoring catches the ones created next month.
“If an account can reset the password on a privileged object, it is a shadow admin regardless of which group it sits in.”
Why shadow admin accounts keep appearing
These accounts aren't usually created deliberately — they accumulate as side effects of normal IT operations. The recurring causes:
- Delegated OU permissions granted for a one-off task (a migration, a password reset campaign) and never revoked afterward.
- Nested group chains that obscure indirect membership from anyone doing a quick group-membership check.
- Service accounts granted local or domain admin rights to get an integration working, then forgotten once the project ships.
- Help desk tooling that requires broad ACL rights to function, applied at the OU level instead of scoped to individual objects.
- M&A account migrations that copy ACLs wholesale from the acquired domain without review.
- Break-glass emergency accounts left permanently enabled with standing rights instead of activated only when needed — see how to secure break-glass emergency access accounts for the containment pattern.
Each of these is a small, reasonable decision at the time. Stacked across a domain that is five or ten years old, they add up to dozens of undocumented paths to Domain Admin.
Eliminate standing privileged access
Remove the paths shadow admin audits keep finding.
Related questions
What's the difference between shadow admins and standing privileged access?
A shadow admin is an account with undocumented administrative rights granted through ACLs or nested groups rather than official membership. Standing privileged access is a known, documented admin account that stays permanently enabled instead of activating only when needed — both create attack paths, but shadow admins are harder to find because nobody is tracking them.
Can BloodHound alone detect shadow admin accounts?
BloodHound alone catches shadow admins that exist at the moment of the scan, but it produces a point-in-time snapshot, not continuous coverage. New ACE grants and group changes made the day after a scan stay invisible until the next run, which is why a repeating schedule matters more than the tool choice.
How often should you audit Active Directory for shadow admins?
Run a full ACL and nested-group audit at least quarterly in 2026, with a lighter automated check after any bulk provisioning change, help desk delegation, or acquisition. Environments under active attack-surface pressure — financial services, healthcare, critical infrastructure — benefit from monthly cycles instead.
Once shadow admins are found, the fix isn't a one-time cleanup. It is removing the conditions that let indirect admin paths form at all. That is the problem identity microsegmentation for Active Directory environments is built to solve: it contains what a compromised identity can reach, so a shadow admin discovered next quarter carries a smaller blast radius than one discovered this quarter.
FAQ
What is a shadow admin account in Active Directory?
A shadow admin account holds administrative rights through ACLs or nested group membership rather than direct membership in Domain Admins or Enterprise Admins. It gives an attacker or insider the same reach as a documented admin account without appearing on a standard privileged-group review.
How do you find shadow admin accounts in Active Directory?
Find shadow admin accounts by auditing ACEs on every AD object for GenericAll, WriteDacl, WriteOwner, and ForceChangePassword rights, then tracing nested group chains recursively. Tools like BloodHound, PingCastle, and Purple Knight automate the graph analysis; native AD tools require manual per-object checks.
Is BloodHound enough to detect shadow admins in 2026?
BloodHound detects shadow admins that exist at scan time but produces a point-in-time snapshot, not ongoing coverage. Pair it with continuous privileged access monitoring or a repeating quarterly audit to catch ACE grants added after the last scan.
What ACE permissions indicate a shadow admin?
GenericAll, GenericWrite, WriteDacl, WriteOwner, WriteProperty on group membership attributes, ForceChangePassword, and AllExtendedRights all indicate a shadow admin path. Any of these on a privileged user, group, or OU object gives the holder effective control over that object.
Why do shadow admin accounts go undetected for years?
Shadow admin accounts go undetected because standard security reviews check group membership, not ACLs, and nested group chains obscure indirect admin rights from a quick lookup. Service accounts granted admin rights for a single integration and then forgotten are the most common long-lived example.
Do service accounts count as shadow admins?
Yes, a service account with unreviewed local or domain admin rights is one of the most common shadow admin patterns found in 2026 audits. These accounts rarely get revisited once the integration they were built for ships.
How does identity microsegmentation reduce shadow admin risk?
Identity microsegmentation limits what a compromised or shadow admin identity can reach across the network, containing lateral movement even if the account is not caught immediately. It shrinks the blast radius between the moment an audit finds a shadow admin and the moment it is remediated.
One last thing
The shadow admin accounts that cause the most damage are rarely the ones with the most obvious rights. They are the forgotten service account with a single WriteDacl grant on an OU nobody has touched in years. Audit for the account nobody remembers before you audit for the account with the most permissions; in 2026 domains, that is where attackers look first because it is where defenders look last.
Related guides
- Eliminate standing privileged access in Active Directory
- Secure service accounts from credential theft
