Privileged access and shadow admin analysis

Who can become a domain administrator

Your real domain administrators are rarely just the accounts listed in Domain Admins. MagenX names every identity that can reach the top of your Active Directory, whether the rights were granted, inherited, delegated or carried over from an older directory. You get a list of people, service accounts and computers, each with the object and the right that puts it there, and each drawn as a step on the routes an attacker could take.

Reviewing the members of your privileged groups misses the accounts that can add themselves to those groups whenever they like. Those accounts are what this analysis finds.

Where indirect privilege comes from

Hidden privilege builds up in the same few places in almost every directory. MagenX covers each of them and reports what it finds as one finding with its evidence.

Rights on the domain, on AdminSDHolder and on organisational units. A right on AdminSDHolder spreads to every protected account within the hour, so GenericAll or WriteDACL there makes a domain administrator that no group lists
SID history that carries a privileged identity. An account given the identifier of Domain Admins signs in with those rights while every membership report looks clean
Shadow admins and privileged access: every privileged group resolved through every level of nesting, plus the operator groups, DnsAdmins and directory sync accounts that reach Domain Admin without being in it
Your Tier 0 inventory, from domain controllers and certificate authorities to federation and sync servers, hosts trusted for unconstrained delegation and privileged accounts, with the protection each one is missing
Delegation: unconstrained delegation that captures every ticket sent to a host, constrained delegation and its targets, and resource-based delegation set on the target
Certificate templates that let a requester become anyone in the domain
LAPS readers: who can read local administrator passwords, and where an account of a lower tier can read the passwords of a higher one
Trusts and other domains: a trust without SID filtering, a privileged group that holds a foreign account, and the routes that cross from one domain into another
Exposed credentials: passwords and secrets left where any reader can find them, in account attributes and in Group Policy scripts

Grouped by who holds the right

A rights review with one row per object produces thousands of rows and no answer. MagenX groups every right by the account or group that holds it: one row per principal, with every object it controls beneath it. Your question is "who can do this", and the table answers it directly.

Membership is resolved by identity. A group called SQL Administrators stays separate from Administrators, and every custom administrative group your organisation has created shows up as itself. In a multi-domain forest, each account is tied to the right domain, so a principal from one domain never hides inside another.

Privilege, drawn as a route

Every privileged identity sits in one graph with the groups it belongs to, the delegations it holds and the machines it has rights over. Pick a foothold, a workstation, a service account or a contractor's laptop, and attack simulation draws the routes that start there, with the shortest one from each starting point. It ranks the choke points by how many routes each one cuts, and checks every network step against the firewall rule that governs it.

Crown jewels works in the other direction. Name the asset you cannot lose, and MagenX shows every principal with rights over it, every subnet that can reach it, and where those two meet. That overlap is the path an attacker would use, and it is where you fix first.

The cloud side of the same people

A hybrid account that holds Global Administrator in Microsoft Entra ID and a weak password on premises is one problem, and MagenX reports it as one. Entra ID roles sit beside the on-premises accounts they belong to, standing roles are shown apart from roles activated on demand, and the accounts that synchronise your directory to the cloud are reported as the privileged accounts they are.

When an administrator appears between scans

Scheduled scans build a change history. A new member of Domain Admins between two scans becomes an event in it, with the window in which it happened and, where the directory recorded it, the person who made the change. Mark a change as reviewed once and it stays reviewed, scan after scan.

What it does not do

It never uses a privilege to prove it. MagenX requests no tickets, replicates nothing, sprays no passwords and opens no sessions as any account, so you can run the full analysis on an estate that forbids offensive tooling, during business hours, with nothing to clean up afterwards.

FAQ

What is a shadow administrator?

An account that can obtain domain administrator rights without belonging to any group that says so. The rights usually arrive through a permission on a privileged object, through delegation, through a certificate template, or through an identifier carried over from an older directory in SID history.

Does it cover cloud identities as well as on-premises accounts?

Yes. Microsoft Entra ID roles sit beside the on-premises accounts they belong to, so a privileged cloud role held by a weakly protected identity is one finding. Roles held permanently are shown apart from roles activated through Privileged Identity Management.

How is a privileged group's membership resolved?

Through every level of nesting, by identity rather than by name, across every domain in the forest. When a membership cannot be confirmed, the finding tells you so, and you never see an empty group that is really full.

Can it tell me the one change that removes the most routes?

Yes. Attack simulation ranks the steps whose removal breaks the most routes. Often the top one is a single stale delegation, or one group's rights that dozens of routes share.

Is the analysis different on a multi-domain forest?

Each domain is assessed and scored on its own tab, and routes that cross a trust are drawn across domains. A trust without SID filtering, and a privileged group in one domain that holds an account from another, appear as their own findings.