The privilege escalation your tenant-wide role review never sees
An Administrative Unit scoped role looks harmless until a privileged account lands inside that unit. Then a regional helpdesk operator can reset a Tier-0 password, invisibly.
Administrative Units let you delegate admin over a slice of the directory. The danger is that an AU-scoped grant is invisible to anyone reviewing tenant-wide roles, and a privileged account that drifts into that unit becomes reachable.
How the attack works
A regional operator is given an AU-scoped role, for example User Administrator, over a unit such as a regional grouping. A dynamic membership rule plus a manual add quietly pull two accounts that hold privileged directory roles into the same unit. The operator now resets one of those privileged accounts, registers MFA on it, and signs in. Because reviewers look at tenant-wide role assignments, the operator’s reach into Tier-0 never appears in the usual audit. This maps to T1078, Valid Accounts, and T1098, Account Manipulation.
Why it works
An AU-scoped assignment carries a directory scope that points at the unit, not the tenant, so a tenant-wide role review never surfaces it. The reach comes from two things working together: the scoped role and the AU membership that captured a privileged account.
How to fix it
Containment must cut both the access and the reach. Remove the operator’s AU-scoped role assignment, remove the privileged accounts from the unit, and revoke the sessions of the account already reset. Hunting the Global Admin list is the wrong place to look, because the grant is not tenant-wide. The lasting fix is to keep Tier-0 accounts out of every delegated unit, audit AU membership and AU-scoped assignments as first-class objects, and constrain dynamic rules so they cannot match privileged accounts.
Practice it
We built this as a GraphLattice Range scenario so administrators can rehearse spotting a scoped escalation that hides where no one audits.