A shadow admin is an account that has admin-level control without being in any of the groups you'd normally check. A lot of teams clean up Domain Admins, get their count down to a handful of people, and then a risk assessment turns up several other accounts that can still take over the domain. Here are four ways to find them and keep new ones from showing up.
What's inside
Most shadow admins come from permissions set directly on Active Directory objects instead of through group membership.
These accounts never appear in a group report, because the rights are attached to the object itself. A few common ones are worth checking first.
Password reset on Domain Admins
An account with "Reset Password" rights on members of Domain Admins can reset a domain admin's password and log in as them.
Replication rights (DCSync)
An account with replication rights on the domain, which is the permission behind a DCSync attack that pulls password hashes straight from a domain controller.
GPO edit on Domain Controllers
An account that can edit a Group Policy Object linked to the Domain Controllers OU.
Operator groups
Members of Backup Operators, Server Operators, or Account Operators all have known paths to domain admin. A Backup Operator can back up the AD database from a domain controller and pull the hashes out of it.
Entra ID app registrations
In Entra ID, an app registration holding RoleManagement.ReadWrite.Directory can assign Global Administrator to any account, including its own service principal.
A group membership report won't catch any of the examples above.
You need a tool that reads the permissions on AD objects and maps out attack paths, like BloodHound, Insight Recon, or CyberArk's free ACLight tool. When I run one of these, I'm looking for every account with a path to Tier 0, even if it takes three or four hops to get there.
Every account with a path to Tier 0, even if it takes three or four hops to get there.
These map out attack paths rather than group membership, which is why they surface the accounts a standard report misses.
If you remove a shadow admin without finding the cause, you'll most likely continue to see more and more pop up over time.
If you have directory change auditing turned on (event 5136), look at who set the permission and when.
A lot of the time it comes down to an outage where someone needed rights in a hurry, a vendor installer that asked for more than it needed, or an old delegation for a help desk team that's since been reorganized.
Whatever you find, the fix usually comes down to who can set permissions on a Tier 0 object in the first place. Those rights should sit with a small handful of accounts that live in the vault, so the next time someone needs rights in a hurry they're checking out an account to do it, and you've got a record of who changed what.
Write DACL
The ability to change who is allowed to do what on an object
Modify Permissions
The right to grant or revoke access on Tier 0 objects
Take ownership
The right to seize an object, which effectively grants full control
A scan only gives you a snapshot of your environment at the time it was run, so pair it with alerts that catch the changes in between scans.
Forward these Windows events to your SIEM so a new member of a privileged group shows up the moment it's added.
This is the same event you use to trace the cause in step 3. Alert when a change touches a Tier 0 object.
Then schedule your discovery scan to run regularly, so anything that might not be noisy enough to trigger an alert still shows up in a report and gets onboarded or removed.
Shadow admins aren't a one-time cleanup. They're a symptom of permissions being granted outside a controlled process.
If shadow admins keep turning up in your environment, please reach out; we can help you find them and fix the process that keeps creating them.