Shadow Admins in Active Directory: Hidden Privilege Paths Attackers Exploit
How FireMon Evaluates Firewall Changes Before Deployment
What Are Shadow Admins in AD?
A common problem we encounter within many customer AD environments are accounts that, at first glance, may appear innocuous, but that actually have hidden administrative privileges equivalent to those of a domain administrator account. We call these accounts shadow admins. They represent one of the most persistent shadow admin risks in enterprise cybersecurity today.
A “shadow admin” is any user account that holds sensitive privileges or admin permissions without being a member of a traditional admin group like the “Domain Admins” or “Enterprise Admins” groups. These shadow admin accounts don’t show up when you run the net group command. They won’t appear in your PAM solution’s reports. But a malicious actor who finds one has effectively won the domain. Unlike a traditional admin who is visible in privileged groups, a shadow admin account becomes a blind spot. Identity and access management tools often miss these indirect privilege paths.
Over the past several years, the problem has gotten significantly worse as organizations undergo digital transformation. Workloads are migrating to AWS and Azure, identity is being federated to the cloud via ADFS, and domain controllers are running as virtual machines on ESXi. The blast radius of a single compromised account now extends well beyond the traditional AD boundary. A “shadow” admin path in 2016 might have been a service account with an overly permissive access control entry. In 2026, it’s an ADFS server running on a hypervisor managed by a VMware operator who doesn’t even know they’re one hop from full domain compromise, and two hops from your entire AWS environment.
In this post, we’ll walk through several real-world examples we routinely discover during engagements and show how Praetorian Guard’s continuous attack path mapping surfaces them before an adversary does.
ADFS Servers and Identity Security Risks
If your organization federates identity to cloud providers using AD Federation Services (ADFS), you’ve almost certainly heard of the Golden SAML technique that was exploited in the SolarWinds (Solorigate) attack. The ADFS server holds the token-signing certificate. The private key used to generate SAML assertions that cloud providers accept as proof of identity. If a threat actor compromises that server, they can forge tokens for any federated user, including cloud administrator accounts.
You may be wondering: why does this matter for a discussion about AD shadow admins? The answer is that it creates shadow admins in both directions. On-prem compromise of the ADFS server, acting as an identity provider, gives an adversary access to your entire AWS Organization, Azure subscriptions, and GCP projects. Conversely, if that ADFS server itself runs as an EC2 instance or Azure VM, or is managed through a cloud-hosted configuration pipeline, then a cloud-level compromise gives an attacker a path back into on-prem AD.
The practical result is that anyone with admin access to the ADFS server, or to the infrastructure it runs on, is effectively a shadow admin for your cloud environment and potentially for your on-premises domain as well. This often includes the server admin team, the backup operators, and (as we’ll see in the next section) the virtualization team. These are admin users who hold sensitive privileges without any explicit membership in a privileged AD group.
Remediation: Treat ADFS servers as Tier 0 assets equivalent to domain controllers. Where possible, migrate to cloud-native authentication (Seamless SSO or Pass-through Authentication) to eliminate the on-premises token-signing key entirely.
Hypervisor Admins: Shadow Admin Privilege Paths Through VMware
Most organizations virtualize their domain controllers. This makes operational sense, but if you’ve ever thought about it from an attacker’s perspective, the implications are significant: if your domain controllers run as VMs on ESXi, then anyone with administrative access to the hypervisor has implicit access to the DC guest. A VMware admin can snapshot a DC and extract the NTDS.dit offline, access the virtual console, attach a boot disk, or clone the entire VM for offline credential extraction. These privileges can include direct access to sensitive data such as password hashes for every account in the domain.
A natural question is: what if you don’t have full VM admin access, but you do have ESXi console access (VMRC)? In practice, this is often enough. An operator with VMRC access can interact with the Windows login screen directly, authenticate as any domain user, and then attempt local privilege escalation.
This same logic applies to every Tier 0 asset that has been virtualized. That includes ADFS servers, PKI certificate authorities, Azure AD Connect servers. If your ADFS server from the previous section is running on ESXi, the hypervisor admin can compromise it, extract the token-signing certificate, and forge SAML tokens into your cloud environment — all without ever connecting to AD directly. That’s a shadow admin chain spanning three distinct administrative domains (VMware, AD, AWS), and none of the three teams involved would typically have visibility into the full path.
Remediation: If a hypervisor hosts a Tier 0 VM, the hypervisor is Tier 0. Dedicate specific ESXi hosts exclusively to Tier 0 workloads. Restrict VMRC access to Tier 0 administrators only.
Helpdesk Permission Abuse and ACLs
In a typical delegation model, helpdesk administrators are granted write permission to computer account objects in AD. This seems completely benign. Helpdesk staff need to reset machine passwords, update descriptions, and manage attributes during reimaging. But when permissions granted to each account are not carefully scoped, a helpdesk delegate can become a shadow admin without anyone realizing it.
The problem is that write access to a computer account object includes the ability to modify the msDS-AllowedToActOnBehalfOfOtherIdentity attribute, which controls Resource-Based Constrained Delegation (RBCD). An attacker who compromises a helpdesk admin account can configure any writable computer object to trust an attacker-controlled account for delegation, then use S4U2Self and S4U2Proxy to impersonate a privileged user on that machine. If the writable computer object is a domain controller, the domain is compromised. This is a textbook example of how a user account becomes a shadow admin through excessive permissions alone.
We frequently see this pattern amplified by ACL drift. On a recent engagement, Guard’s Ownership Drift analysis revealed delegation groups with GenericAll on service accounts that had AddMember on admin groups, alongside other groups with WriteAccountRestrictions on privileged accounts. Each hop looked reasonable in isolation. Chained together, they created a path from a low-privilege delegation group to full domain compromise.
Remediation: Remove write permission to DC computer objects from all non-Tier 0 groups. Restrict helpdesk delegation to OUs that don’t contain Tier 0 or Tier 1 machine accounts.
Azure AD Connect: Shadow Admin Accounts in Microsoft Active Directory
If you’ve set up Azure AD Connect for directory synchronization, you’ve almost certainly seen the MSOL_ prefixed sync accounts that it provisions. These accounts require DCSync rights by design — the exact permission needed to replicate every password hash in the domain.
On a recent engagement, Guard’s DCSync rights review flagged [email protected] with its password set to never expire, protected via AdminSDHolder, and with GenericWrite and GenericAll on multiple delegation groups. It had been sitting untouched for years. This is a prime example of accounts that have sensitive privileges that go unmanaged.
What makes this especially concerning is that the Azure AD Connect server is often treated as a mid-tier application server rather than a Tier 0 asset. It frequently runs on a shared hypervisor, is managed by a team that also manages general-purpose infrastructure, and is backed up by the same solution that handles everything else. Any of those adjacent systems provides an indirect path to DCSync and full domain compromise.
Remediation: Treat the Azure AD Connect server as Tier 0. Consider migrating to Azure AD Cloud Sync, which avoids provisioning a domain-level DCSync account.
Understanding Shadow Admin Levels and Detection
Not all shadow admins are created equal. In security research, a direct shadow admin — sometimes called a level 1 shadow admin — is an account that has strong privileges over an existing admin account or the domain admin group, such as the ability to reset a DA’s password or modify group membership in the Domain Admins group. A level 2 shadow admin holds privileges over a level 1 shadow, creating a transitive chain. In practice, many shadow admins in large environments are level 2 or deeper, making shadow admin detection significantly harder because no single team sees the full chain.
Consider a scenario: Larry, a level 2 shadow admin, has GenericAll permission on a service desk account. That service desk account, in turn, has WriteOwner on a member of the domain’s privileged groups. Neither Larry nor the service desk team realizes they are members of a privileged chain that reaches domain admin privileges. This is how an otherwise ordinary user account becomes a shadow admin. It happens through nested groups, inherited ACLs, and accumulated access control entries that no one reviews holistically.
Shadow admin detection requires continuously auditing all accounts and groups in the domain, examining not just direct group membership but the full transitive closure of permissions. Traditional admin visibility tools only check whether an account is a member of the Domain Admins group or other administrative groups. They miss privileged accounts in the domain that hold admin rights through delegation, ownership, or other access control paths. Effective privileged access management demands that AD administrators map every identity — including machine accounts, nested groups, and shadow IT services — against the full set of privileged roles in the environment.
How to Identify and Mitigate Shadow Admin Risks
The common thread across these examples is that shadow admin paths increasingly cross the boundaries between administrative domains. Your VMware team, your helpdesk, your cloud operations team, and your identity team are all managing shadow admin risks across separate slices of an interconnected system, and none of them has full visibility into how their permissions compose with everyone else’s.
These are just a subset of examples from recent engagements. This issue extends beyond AD as well. In a previous post, we showed how vulnerability scanner accounts configured with root privileges and password-based SSH access can be intercepted on a compromised host, turning your own security tooling into a lateral movement vector.
Recommended Mitigations
In the real world, it is very difficult to cleanly segment privilege between different tiers of users and groups. This includes developers, helpdesk staff, mid-level admins, VMware operators, cloud engineers. Human error in permission assignment is inevitable. Additional security controls add friction to development and engineering processes. But the risk posed by each control, or the absence of one, must be carefully understood. Without continuous monitoring, any user can grant themselves or others unauthorized access to tasks that require domain admin privilege — and no one will notice until it’s too late.
To mitigate shadow admin risks effectively, organizations should:
Treat any identity with a transitive path to domain-level privilege as a shadow admin, regardless of what team manages it.Audit built-in groups — not just the “Domain Admins” and “Enterprise Admins” groups, but all administrative groups and privileged roles.Any system hosting or managing a Tier 0 asset is itself Tier 0: hypervisors, ADFS servers, AD Connect servers.Federation infrastructure is the bridge between your on-prem domain and your cloud. Secure it accordingly as part of your identity security strategy.ACL drift is continuous. Point-in-time reviews aren’t enough. Invest in privileged access management and ongoing access management to catch unauthorized changes as they happen.
Praetorian Guard’s continuous attack path mapping helps surface these paths as they emerge rather than six months later during your next pentest. If you’re running AD, you have shadow admins. The question is whether you find them first, or a malicious actor does.
Want to see what shadow admin paths exist in your environment? Request a Guard demo and we’ll show you.
The post Shadow Admins in Active Directory: Hidden Privilege Paths Attackers Exploit appeared first on Praetorian.
*** This is a Security Bloggers Network syndicated blog from Offensive Security Blog: Latest Trends in Hacking | Praetorian authored by Michelle Rhodes. Read the original post at: https://www.praetorian.com/blog/shadow-admins-active-directory/
About Author
