One Token to Rule Them All – Obtaining Global Admin in Every Entra Id Tenant
Posted4 months agoActive4 months ago
dirkjanm.ioTechstoryHigh profile
heatednegative
Debate
80/100
Entra IdSecurity VulnerabilityMicrosoft Azure
Key topics
Entra Id
Security Vulnerability
Microsoft Azure
A security researcher discovered a vulnerability in Entra ID that allows obtaining Global Admin access to every tenant, sparking concerns about the design and security of Microsoft's identity platform.
Snapshot generated from the HN discussion
Discussion Activity
Very active discussionFirst comment
2h
Peak period
34
0-12h
Avg / period
8.5
Comment distribution51 data points
Loading chart...
Based on 51 loaded comments
Key moments
- 01Story posted
Sep 17, 2025 at 7:03 PM EDT
4 months ago
Step 01 - 02First comment
Sep 17, 2025 at 9:19 PM EDT
2h after posting
Step 02 - 03Peak activity
34 comments in 0-12h
Hottest window of the conversation
Step 03 - 04Latest activity
Sep 26, 2025 at 4:58 AM EDT
4 months ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
ID: 45282497Type: storyLast synced: 11/20/2025, 5:48:27 PM
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
One wonders whether those who designed all this ever considered what that field in the token is for.
The word "tenant" is also very telling --- you're just renting, and the "landlord" always has the keys.
I would expect these tokens to be like JWT or macaroons, carrying specific permissions within specific bounds / tenants. Alas.
I'm feeling sorry for those poor abused JWTs in this vulnerability.
But the systems that have been built around them are bad. Firstly in issuing these ‘root’ tokens at all, and secondly in not checking the claims properly.
A JWT is only as good as the systems it’s used by.
Literally every single "security" framework uses God-mode long-lived tokens for non-human identities.
(Except for SPIFFE, but that's a niche thing and used only for Kubernetes bullshit.)
The whole field of "security" is a farce staffed by clowns.
The only special permission that services (actually, the AWS accounts that they use) inside the AWS have is access to "service principals". The service roles inside customer accounts then use them to grant access.
AWS IAM is painful, but it shows that you can design a secure permission system.
You get to see that even with the regular public AWS/EC2. Instance roles are managed externally from the customers' points of view.
So, ultimately "keys to the castle" aka a long password?
But ultimately, any realistic design will eventually have systems that have to be trusted. It's just a question of isolating them.
browsers could make it easier to approve domains for spnego (chrome already makes it automatic for enterprise accounts). the market just doesn't want real security, it wants to login with its facebook profile.
https://techcommunity.microsoft.com/blog/askds/understanding...
It works great within a single organization hierarchy, but becomes pretty painful for anything we'd consider "SaaS"
Just creating a tenant is a PITA and you get a default tenant you can't change without paying for Microsoft 365? Then you have subscriptions, Microsoft partners, Enteprise vs individual accounts, etc. All mixed with legacy AD naming and renaming, documentation with outdated screenshots, Microsoft Partners bullshit.
What exactly ist a PITA when creating a tenant? It's straightforward.
And what do you mean by default tenant that you cannot change unless you pay? Nothing comes to mind where that would be the case.
Are you sure you're not just using it wrong?
I agree needing an account to create a tenant is not ideal. But that's nothing more than a minor inconvenience. If these are the big problems you make out with M365, then I think I can just shrug your opinion away.
And yes they have different types of accounts and methods of billing. Their customer base is probably in the hundreds of millions. People are going to want options. I don't really see the issue there.
This makes me wonder if Microsoft’s commitment to long-term support is part of the problem: instead of deprecating these ancient APIs they keep them on life-support, but forget some "regression-test" on how they interact with the shiny new surfaces.
Feels like P0’s Windows Registry talks, most of the vulns weren’t in the new code, they were in the how legacy behaviors interacted with newer features.
You see, most enterprise client with big enough contract can force to do this and MS need to support this customer until they migrate or if they ever be at all
I may argue for any big legacy enterprise software, its easier to rewrite the damn whole thing than to support the legacy code forever but they cant do that even if they have motivation/resource
> A successful attack depends on conditions beyond the attacker's control. That is, a successful attack cannot be accomplished at will, but requires the attacker to invest in some measurable amount of effort in preparation or execution against the vulnerable component before a successful attack can be expected. For example, a successful attack may require an attacker to: gather knowledge about the environment in which the vulnerable target/component exists; prepare the target environment to improve exploit reliability; or inject themselves into the logical network path between the target and the resource requested by the victim in order to read and/or modify network communications (e.g., a man in the middle attack).
But reading Dirk-jan's article, really all you need is basic admin knowledge of Entra ID etc., and the netId of any single user on the targetted environment, which can be found using brute force enumeration. The rest is public knowledge.
Strictly speaking the attacker would need to invest in some measurable amount of effort, but that seems like stretching the definition to make the CVE look less awkward.
> Yes, because any "basic user of Entra ID with basic knowledge of it" has found undocumented types of tokens, and stringed them with another Graph API vulnerability, to impersonate users...
Basic Entra ID users don't even know what an Entra ID token is exactly.
In this exploit, there are hardly any conditions beyond the attacker's control which must be satisfied.
https://msrc.microsoft.com/update-guide/vulnerability/CVE-20...
You are correct that the attack complexity probably shouldn't be high in this case. But presumably the person calculating the CVSS score thought it was too high if attack complexity wasn't set to high.
CVSS has other issues, like people trying to apply it to things that are not vulnerabilities. I would ignore most CVSS scores you see and just read what the issue is instead and make your own judgement call.
[0]: https://securitylabs.datadoghq.com/articles/i-spy-escalating... [1]: https://www.semperis.com/blog/unoauthorized-privilege-elevat...
That's because Microsoft's own fucking developers don't even understand how Entra authentication/authorization works, and that in some/most scenarios you'll need to check if a account is actually authorized to enter a protected resource post-login (which you need to do within the Oauth login flow in the resource being accessed, nobody will do it for you).
Something I already discovered by accident (and fixed, ofcourse!) in my own SaaS service at the time (with support for Entra B2B authentication) even before this researcher discovered the same at Microsoft:
https://research.eye.security/consent-and-compromise/
HN discussion thread: https://news.ycombinator.com/item?id=44850681
Great talk, by the way.