Three weeks of domain hardening, forty minutes to Global Admin
The IT team presents a clean tiering model, LAPS on every client, a long minimum password length for admin accounts, SMB signing enforced everywhere, and alerting on suspicious Kerberos tickets. The on-prem Active Directory is in a state that takes most companies two years to reach. After a day and a half on the internal network, there is exactly zero usable escalation.
So the test shifts layers and targets the tenant, where the identities actually live. The Entra ID attack path a pentest uncovers today rarely starts with a password and almost always starts with an object nobody manages anymore. Enumeration runs through Microsoft Graph and the Azure REST APIs, collected with AzureHound and imported into BloodHound to visualize roles, ownership, and permission chains as a graph.
The hit is called RPA-Rechnungsimport-TEST, created in 2021 by an external contractor who left in 2023. The client secret has expired. The permissions have not. The owner of the associated service principal is an accounting account without any admin role, which had already been taken over earlier in the test through a phishing simulation. This exact path is covered in a detailed write-up: owning a privileged service principal is enough to assume its identity simply by adding a new client secret.
The rest is legwork. Create a new secret, authenticate as the service principal, inherit its permissions, issue a Temporary Access Pass for a Global Admin account, sign in to the Azure portal. Total time from the compromised accounting account: roughly forty minutes. No hashes, no cracking, no Kerberoasting.
The entire chain ran without a single cracked password. It ran on object ownership and API permissions.
Entra ID is not Active Directory with a web UI
In Entra ID, credentials are just one of several currencies. Alongside them are consent grants, client secrets, certificates, role assignments on workload identities, and ownership. All of it is reachable via API, and all of it survives a password reset.
Compromised credentials were the initial vector, and Microsoft justifies mandatory MFA registration in Security Defaults by pointing out that MFA blocks more than 99.2% of identity-based attacks. Even so, starting in May 2023, Storm-0558 accessed the email accounts of around 25 organizations, including government agencies, using forged tokens rather than passwords. The sheer breadth of the issue is also reflected in the sample of the Penetration Testing Intelligence Report 2026: 531,770 vulnerabilities from 4,970 pentests.
On top of that comes time pressure from Redmond. Starting February 1, 2026, Microsoft enforces MFA for administrative roles, and for new tenants, legacy authentication protocols are already switched off as of January 15, 2026. Anyone who doesn't validate their Conditional Access policies beforehand risks a false sense of security. On the regulatory side, NIS2 pulls in the same direction: under Section 30(2), sentence 2, no. 9 of the German BSI Act (BSIG), important and essential entities must document concepts for access control and the management of ICT systems. An access control concept that doesn't mention app registrations is incomplete as NIS2 evidence.
The Entra ID attack path in a pentest: five steps without a single password
Step 1 is the most inconspicuous. In a so-called illicit consent grant, the attacker tricks the victim into granting a malicious OAuth app access to their data, after which the app gains account-wide access without ever asking for an organizational account password. To the user, it looks like any other Microsoft sign-in prompt. To the SIEM, it looks like a successful login.
Step 5 is the one that frustrates defenders the most. In many organizations, Conditional Access is considered the final control, yet it can be bypassed via Nested App Authentication using the brk_client_id and brk_redirect_uri parameters in an otherwise unremarkable token request. The request poses as the broker flow of a trusted host app toward login.microsoftonline.com.
User.ReadWrite.All or Directory.ReadWrite.All. Through this leftover, they created a new user account and granted themselves additional consents in the tenant. The permission had been valid for years and was never revoked.Unmanaged app registrations are persistent access paths that keep authenticating long after the team and the business purpose behind them are gone.
Three things you hear over and over again
- Addresses credential theft, not object ownership
- Consent grants sit outside the tier model
- Service principals have no password that could expire
- An expired secret doesn't mean revoked permissions
- Any owner can create a new secret
- This exact path hit Microsoft itself
- Broker flows look like legitimate requests
- App tokens don't care about device compliance
- Policies are rarely tested against current bypasses
A finding from this year shows that even Microsoft has to keep patching in this area: a vulnerability in the "Agent ID Administrator" role allowed full takeover of arbitrary service principals by letting the attacker assume ownership and add their own credentials. Microsoft has since restricted the role to agent-related objects.
The pattern stays the same. Whoever owns the objects owns the identities.
That's why, in hybrid environments, the federation infrastructure belongs in the same test scope as the domain controllers. CISA has published the SCuBA Hybrid Identity Solutions Guidance for exactly this interface.
What you should check in your tenant
The good news: almost all of this is inventory and process work, not a product purchase.
The bad news: nobody feels responsible, because app registrations fall between IT operations, development, and the business units.
- Consent and owner inventory: List all OAuth permissions and all owners of service principals. Standard users who own objects with directory permissions are a particular red flag.
- Lifecycle for app registrations: Mandatory owners, expiry monitoring for secrets, automatic revocation when unused. Otherwise, unmanaged registrations remain as persistent access paths.
- Admin consent workflow: Disable end-user consent for permissions on directory data and route requests through an approval process, so that an illicit consent grant doesn't come down to a single click.
- Test Conditional Access instead of assuming it works: Check whether your policies hold up against known bypasses such as Nested App Authentication.
- MFA and Security Defaults: Enforce them for every privileged role. Microsoft puts the impact at more than 99.2% of identity-based attacks blocked.
- Federation as Tier 0: Treat AD FS servers like domain controllers and rotate token-signing certificates.
A single well-maintained report on owners and consents would have broken the entire chain in the test described at the start. Give it a fixed slot in your calendar: every quarter.
Questions CISOs ask about Entra ID pentests
Can Conditional Access in Entra ID be bypassed?
Yes, it's documented and doesn't require an exploit in the classic sense. Nested App Authentication allows a token exchange using the brk_client_id and brk_redirect_uri parameters that looks like a normal request from a trusted host app. Conditional Access is therefore a layer of protection, but not the last line of defense.
What is an illicit consent grant?
An attack in which a user is tricked into allowing a malicious OAuth application to access their data. The app then gains account-wide access without needing an organizational account password. MFA doesn't help, because the user signs in normally and grants consent deliberately.
Is MFA enough to secure Entra ID?
MFA is the single most effective measure and, according to Microsoft, blocks more than 99.2% of identity-based attacks. However, it does nothing against compromised service principals, granted consents, or forged tokens, since none of these paths involve an interactive user sign-in. Both need to be controlled in parallel.
Object ownership is the new password
The pentest from the introduction ended with a report that didn't contain a single cracked hash. For IT leadership, that was the most uncomfortable takeaway. Three years of work on Active Directory had been the right call and still didn't block the path to Global Admin, because that path ran through a tenant that, formally, nobody felt responsible for.
The major incidents follow the same pattern. With Midnight Blizzard, it was a test application with Graph permissions that were never revoked; with Storm-0558, it was a signing key that ended up in a crash dump. In both cases, it started with an overlooked object, not a password.
- Expand the scope: If you only test on-prem, you get a clean report on the wrong half of your organization's identities.
- Ownership is privilege: Every ownership of a service principal belongs in the same risk class as an admin role.
- Set a date: Review consents and apps quarterly, not just when something happens.
- From phishing email to Domain Admin: the classic on-prem counterpart to this attack path
- MFA bypass techniques: why a second factor alone doesn't protect a sign-in
- Orphaned accounts as a persistent risk: the same problem, one level deeper in offboarding
Do you know who owns your service principals?
When passwords are no longer the weak spot, identities, over-privileged service principals, and dormant permissions in Entra ID move into focus. We uncover your hidden attack paths before someone else does.
Request an initial consultation →
