Bug in Entra ID maakte overname van volledige adminomgeving mogelijk

De Nederlandse beveiligingsonderzoeker Dirk-Jan Mollema heeft een ernstige kwetsbaarheid gevonden in authenticatieservice Entra ID, waarmee het mogelijk was toegang te krijgen tot iedere Entra ID-omgeving en alle informatie daarbinnen. De bug is inmiddels gerepareerd.

Dirk-Jan Mollema, een Nederlandse beveiligingsonderzoeker die zich specialiseert in Active Directory, beschrijft hoe hij een ernstige bug vond in Entra ID. Dat is een authenticatieomgeving waarin bedrijven toegang tot bijvoorbeeld Microsoft 365, e-mail of bestandsopslag kunnen regelen. Mollema ontdekte een bug die het mogelijk maakte om een token aan te maken in een eigen Entra ID-omgeving, waarmee het vervolgens mogelijk was om admintoegang te krijgen tot iedere andere Entra ID-omgeving. Entra ID was vroeger Azure AD en is wereldwijd de meestgebruikte toegangs- en identiteitsbeheeromgeving.

De bug bestaat volgens Mollema uit twee delen. De eerste draait om zogenaamde Actor-tokens die Exchange Online aanmaakt voor communicatie met andere diensten zoals SharePoint, maar ook met de Azure Active Directory Graph-api. Dat is een wat oudere api waarmee Entra ID kan worden beheerd.

Mollema ontdekte dat de api bepaalde toegangstokens accepteerde, zelfs als daarbij de Entra ID-omgevingen niet overeenkwamen. Vervolgens kon hij een token namaken dat overeenkwam met het netId van een gebruiker in een andere Entra ID-omgeving, waarna de Azure AD Graph-api informatie gaf over die gebruiker. Zo is het mogelijk ook de informatie van een Global Admin te bemachtigen en daarmee een hele Entra ID-omgeving over te nemen als een beheerder.

Mollema gaf zijn bevindingen door aan Microsoft. Dat bedrijf repareerde de kwetsbaarheid deze maand tijdens Patch Tuesday. De bug staat geregistreerd als CVE-2025-55241 en krijgt van Microsoft een Kritieke CVSS-score van 9.0.

Update, 15.21 uur – In het artikel stond aanvankelijk dat Entra ID vroeger Active Directory was, maar dat moet Azure AD zijn.

Reacties (30)

[freespeech_nl]

Kan iemand me uitleggen hoe dit geen 10 is? Wat is daar voor nodig, een bug die je automatisch het ww van de global admin stuurt en koffie regelt?!?

Ongelofelijk dat dit zo slecht geprogrammeerd is en niet opgemarkt. Sterker: ik zou dit bijna als een bewuste backdoor gaan zien.

[BytePhantomX]

Het is inmiddels 10 geworden: https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-55241

[johanl79]

Nou ja, je moet wel zelf Global Admin zijn in een tenant, ik gok dat de gemiddelde hacker en zeker die van overheden, dat niet heeft. Dus enige moeite moet je er wel insteken, denk aan gestolen credit card informatie e.d.

[redtoller]

Global admin zijn in een tenant is echt geen moeite. Je krijgt gewoon een gratis tenant van Microsoft als je die wil.

[xbeam]

Klopt Entra id is Gratis

[maevian]

Je kan gewoon gratis een test tenant opstellen, heb je geen gestolen credit card voor nodig.

[Rmaxx]

downplayen ..vooral downplayen en hopen dat het niet teveel nieuws wordt:)

Heb zelf laatste week ook wel e.a. gezien dat bij MS/Office nogal buggy lijkt.. Moet je eens naar je oultook gaan met een telefoon, en daarna 2fa aanzetten via je desktop... dan nog eens op je telefoon kijken.. refreshen.. no problem.. of ww wijzigen, als je een open venster (incognito) hebt hoef je hooguit nog de 2fa voorbij - ww sla je meteen over... ik zal het wel niet snappen, maar het lijkt houtje-touwtje allemaal..
Overal uitloggen via je MS account > duurt 24u.. ALS het al werkt en je de optie kunt vinden :)

[wigwam]

precies

[Audiodude]

Waarschijnlijk omdat het eerder opgehaalde token nog geldig is.

Zou hetzelfde proberen maar dan een paar uur later, afhankelijk wat de geldigheidsduur van het token is.

En als het een app token is dan gaat MFA daar niets aan veranderen.

[Rmaxx]

Klopt maar ook na ww wijzigen zouden alle tokens automatisch moeten vervallen, (staat in de mail die je daarna krijgt), maar dat blijkt niet (direct) te gebeuren.

[SPee]

Vervolgens kon hij een token namaken dat overeenkwam met het netId van een gebruiker in een andere Entra ID-omgeving, waarna de Azure AD Graph-api informatie gaf over die gebruiker.

Je moet dus die netId van een gebruiker zien te achterhalen. Dus het is niet zonder meer mogelijk. Aangezien het een lange, unieke id is, is het moeilijk met brute-force te achterhalen.

[freespeech_nl]

Ik zou echt even het blog van de ontdekker lezen: https://dirkjanm.io/obtaining-global-admin-in-every-entra-id-tenant-with-actor-tokens/

Hij legt daar precies uit hoe je makkelijk de netID kunt achterhalen, zelfs via een soort daisy chain waarbij je van de ene naar de andere tenant gaat (kan zonder admin rechten). Ook legt hij uit dat de netId best makkelijk te brute-forcen is omdat deze oplopend is. Het is geen random nummer, elke volgende user krijgt een hogere netID over de verschillende tenants.

Heel interresant om te lezen. En vooral een openbaring over de onderliggende infra van MS: met zo'n bug er in moet er nog veel meer houtje touwtje aan elkaar zijn geknoopt, kan niet anders. Tenzij dit een bewuste backdoor was voor bijvoorbeeld overheden, maar dat maakt het er niet beter op.

Sterker: als ik lees hoe dit werkt dan ben ik er nu van overtuigd dat op het allerhoogste niveau (technisch) MS gewoon toegang heeft tot alle tenants. Ook al pas je je eigen encryptie keys toe op je tenant: via dit soort "bugs" kun je dat gewoon omzeilen. En blijkbaar heeft MS een soort hoofd tenant waar alle andere onder vallen, anders was het onmogelijk om met een (eigenlijk random) ticket uit een andere tenant ook maar iets te doen. Erg verontrustend.

[SuperKneus]

Hij is ondertussen aangepast naar een 10

Niet goed gelezen, stond er al.

[Reactie gewijzigd door SuperKneus op 19 september 2025 21:59]

[Jerrythafast]

Zoals anderen al aangeven is het inmiddels geüpdatet naar een 10.0.
Op Security.nl staat uitleg waarom het eerst een 9.0 was:

Op 17 september publiceerde Mollema de details van het probleem. Een dag later stelde Microsoft dat het de complexiteit van de aanval verkeerde had ingeschaald. In plaats van hoog is die aangepast naar laag. Via het Common Vulnerability Scoring System (CVSS) wordt de impact van kwetsbaarheden berekend. In het geval van het Entra ID-lek zorgde de aanpassing ervoor dat de oorspronkelijke impactscore van 9.0 werd veranderd naar de maximale score van 10.0.

Ze hadden dus "Hoog" ingevuld bij complexiteit, maar dat moest "Laag" zijn. Oepsie?

[Reactie gewijzigd door Jerrythafast op 19 september 2025 22:26]

[MoonRaven]

Ik vraag mij vooral af of beheerders hier een melding van krijgen als dit misbruikt is of in ieder geval een melding dat de global admin group moet worden nagekeken...

Hmm, de CVE geeft aan "This vulnerability has already been fully mitigated by Microsoft. There is no action for users of this service to take. The purpose of this CVE is to provide further transparency.". Mogelijk dus niet nodig. Maar goed, controleren is beter.

[Reactie gewijzigd door MoonRaven op 18 september 2025 14:41]

[BytePhantomX]

Quote uit de blog post:

Based on Microsoft’s internal telemetry, they did not detect any abuse of this vulnerability.

Daarnaast staat er nog een detection query om zelf te zoeken of er misbruik van is gemaakt.

In dit soort gevallen is het ook handig om na te denken welke partijen dit zouden kunnen vinden in misbruiken. Dat zijn waarschijnlijk statelijke actoren, waarmee de kans bijzonder klein is dat de gemiddelde klant zich hier druk om moet maken en forensisch onderzoek moet gaan doen.

Is dit echt bijzonder slecht ontworpen door Microsoft? Jazeker. Te bizar voor worden dat ze een access token hebben die overal bij kan, niet controleert op TenantID properties en nul logging achterlaat.

Ps, het is sowieos al wel slim om alerts in te stellen op het toevoegen van Global Admins aan je tenant. Kun je met Microsoft tooling zelf doen, of er zijn mooi producten van derde partijen die dit tegen acceptabele kosten monitoren.

[Reactie gewijzigd door BytePhantomX op 18 september 2025 14:44]

[PolarBear]

Is dit echt bijzonder slecht ontworpen door Microsoft? Jazeker. Te bizar voor worden dat ze een access token hebben die overal bij kan, niet controleert op TenantID properties en nul logging achterlaat.

Het zal ongetwijfeld niet zo ontworpen zijn.

[Keyb]

Ik weet eigenlijk niet welke van de twee erger zou zijn.

[MoonRaven]

Ah top, ik had deze informatie eigenlijk in de CVE verwacht.

[NoTechSupport]

Een statelijke actor most je hiervoor niet per se zijn. Het is eigenlijk een redelijk eenvoudig lek.

Als Microsoft ziet dat het niet misbruikt is dan kan je ervan uitgaan dat niemand dit misbruikt heeft (behalve eventueel de Amerikaanse geheime diensten).

[Standeman]

Aan de andere kant zou ik Microsoft niet op hun mooie blauwe ogen vertrouwen in een dergelijke uitspraak. Al dan niet op last van de Amerikaanse geheime diensten.

[ForReal]

Als Microsoft ziet dat het niet misbruikt is

Daar ben ik wel benieuwd naar. Doet Microsoft daar ergens melding over?

De vulnerability is gemeld en inmiddels gefixt. Maar in hoeverre zou een minder ethical hacker dezelfde vulnerability gevonden kunnen hebben en gebruikt kunnen hebben? Sluit Microsoft dat ergens uit?

[BytePhantomX]

Je hoeft geen statelijke actor te zijn om het te misbruiken, maar wel om het te vinden.

En ik vertrouw Microsoft niet helemaal. Of ze zijn misschien niet eerlijk, of ze hebben de logging niet.

[supersnathan94]

Ik denk het niet aangezien de "global admin group" niet wordt aangepast.

Er wordt geen valdiatie gedaan of de user waarmee het request wordt gedaan wel bij de tenant hoort. met een S2S token (service account token dus eigenlijk) ben je automatisch admin op alles.

These tokens allowed full access to the Azure AD Graph API in any tenant. Requesting Actor tokens does not generate logs. Even if it did they would be generated in my tenant instead of in the victim tenant, which means there is no record of the existence of these tokens.

Tenant gaat helemaal 0 komma niks hiervan merken.

[Sangre]

Dirk-Jan, bedankt. Vanavond toosten we op jouw

[supersnathan94]

Azure Active Directory Graph-api

Ik heb redelijk recent ruim 2 jaar geleden voor een klant met die API wat dingen zitten doen, maar de documentatie is ook echt een ontzettende berg met shit die niet klopt. Ik vraag me echt af hoe die API intern eruit ziet.

Om namelijk een token op te halen voor een service account, moet je een API aanspreken, maar in de documentatie staat niet vermeld dat je dan ook authenticatie headers moet toevoegen met daarin het token voor het account.

Dat je echt denkt .... Ten eerste ZEG DAT DAN, en dan daarna: maar die héb ik dus ook nog helemaal niet. Dat is precies wat ik probeer op te halen. En met een ander account kun je uiteraard niet het token ophalen (want geen rechten voor dat account). Het was ontzettend verwarrend om met die API dingen voor elkaar te krijgen en bij overdracht naar een collega kwamen we er ook achter dat hij dan weer bepaalde dingen kon doen (zoals token opvragen) met een account van een hele andere organisatie.

Mollema ontdekte een bug die het mogelijk maakte om een token aan te maken in een eigen Entra ID-omgeving, waarmee het vervolgens mogelijk was om admintoegang te kunnen krijgen tot iedere andere Entra ID-omgeving.

Ik denk dat wij dan dus tegen exact dit aan zijn gelopen, maar dan anders? Ik vind het in ieder geval ook niet zo verbazend dat authenticatie en autorisatie niet goed geregeld is met die API.

edit:
The vulnerability consisted of two components: undocumented impersonation tokens, called “Actor tokens”, that Microsoft uses in their backend for service-to-service (S2S) communication. Additionally, there was a critical flaw in the (legacy) Azure AD Graph API that failed to properly validate the originating tenant, allowing these tokens to be used for cross-tenant access. Effectively this means that with a token I requested in my lab tenant I could authenticate as any user, including Global Admins, in any other tenant. Because of the nature of these Actor tokens, they are not subject to security policies like Conditional Access, which means there was no setting that could have mitigated this for specific hardened tenants. Since the Azure AD Graph API is an older API for managing the core Azure AD / Entra ID service, access to this API could have been used to make any modification in the tenant that Global Admins can do, including taking over or creating new identities and granting them any permission in the tenant.


Ja, dat lijkt dus exact op wat er gebeurde. met het token van die andere user (die we dus per ongeluk op een school account hadden gemaakt) kon je dus wel een token refresh doen voor een user in een hele andere tenant.


had ik dat nou maar gemeld toen XD. had ik rijk van kunnen worden haha.

[Reactie gewijzigd door supersnathan94 op 18 september 2025 14:57]

[.net]

Ik gebruik hem zelf veel en deel die mening niet.
Ik weet niet zeker of we hier over dezelfde API spreken maar de huidige Entra Graph API is voor de .net SDK gewoon generated met Kiota. Documentatie is verder ook prima en richt zich vooral op uitzonderingen i.p.v. standaard gedrag (wat niet gek is aangezien het allemaal generated is met Kiota).
De API zelf is enorm en volgt vooral veel conventie en consistentie.

[Reactie gewijzigd door .net op 18 september 2025 15:38]

[supersnathan94]

Ging niet om de .net SDK, maar om de daadwerkelijke onderliggende API. We moesten namelijk zelf wat setup code maken voor CI/CD pipeline.

maar goed. In je happyflow niet eens aangeven dat er authtenticatie nodig is en waar je dat kn vinden (en dat je voor je authenticatie ook weer authenticatie nodig hebt) vond ik echt een gemiste kans.

[Matthijs Hoekstra]

Elke MS API heeft toch een access token in de header nodig?

[supersnathan94]

Ja. Maar de API om een access token op te halen dus ook, maar dat stond er iig 2 jaar geleden niet expliciet bij. Maar. Als je dus een access token wil waar begin je dan als je een token nodig hebt om een token te krijgen?

Uiteindelijk moet je dus een personal access token maken met een account wat bij het andere account dingen mag aanmaken en opvragen en daarmee dus een access token maken voor dat andere account.