Buongiorno, di recente è stato rivelato un _enorme_ baco di sicurezza nei servizi cloud (pubblici) di Microsoft. Tranquili: tutt'apposto!!! B-) Piccola premessa: Microsoft Entra ID è il sistema di autenticazione per accedere ai servizi cloud (multi-tenant); dettagli qui: https://en.wikipedia.org/wiki/Microsoft_Entra_ID «One Token to rule them all - obtaining Global Admin in every Entra ID tenant via Actor tokens» September 17, 2025 https://dirkjanm.io/obtaining-global-admin-in-every-entra-id-tenant-with-act... --8<---------------cut here---------------start------------->8--- [...] This vulnerability could have allowed me to compromise every Entra ID tenant in the world (except probably those in national cloud deployments [1]). If you are an Entra ID admin reading this, yes that means complete access to your tenant. 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. With these compromised identities the access could also be extended to Microsoft 365 and Azure. I reported this vulnerability the same day to the Microsoft Security Response Center (MSRC). Microsoft fixed this vulnerability on their side within days of the report being submitted and has rolled out further mitigations that block applications from requesting these Actor tokens for the Azure AD Graph API. Microsoft also issued [CVE-2025-55241] for this vulnerability. [CVE-2025-55241] <https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-55241> [...] Practical abuse ──────────────── With this vulnerability it would be possible to compromise any Entra ID tenant. Starting with an Actor token from an attacker controlled tenant, the following steps would lead to full control over the victim tenant: 1. Find the tenant ID for the victim tenant, this can be done using public APIs based on the domain name. 2. Find a valid `netId' of a regular user in the tenant. Methods for this will be discussed below. 3. Craft an impersonation token with the Actor token from the attacker tenant, using the tenant ID and `netId' of the user in the victim tenant. 4. List all Global Admins in the tenant and their `netId'. 5. Craft an impersonation token for the Global Admin account. 6. Perform any read or write action over the Azure AD Graph API. [...] Compromising tenants by hopping over B2B trusts ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ I previously mentioned that a users `netId' is used to establish links between a user account in multiple tenants. This is something that I researched a few years ago when I gave a talk at [Black Hat USA 22] about external identities. [...] To abuse this, a threat actor could perform the following steps, given that they have access to at least one tenant with a guest user: 1. Query the guest users and their `alternativeSecurityIds' attribute which gives the `netId'. 2. Query the tenant ID of the guest users home tenant based on the domain name in their UPN. 3. Create an impersonation token, impersonating the victim in their home tenant. 4. Optionally list Global Admins and impersonate those to compromise the entire tenant. 5. Repeat step 1 for each tenant that was compromised. The steps above can be done in 2 API calls per tenant, which do not generate any logs. Most tenants will have guest users from multiple distinct other tenants. [...] Looking at the list of guest users in the tenants of some of my clients, this technique would be extremely powerful. I also observed that one of the first tenants you will likely compromise is Microsoft's own tenant, since Microsoft consultants often get invited to customer tenants. Many MSPs and Microsoft Partners will have a guest account in the Microsoft tenant, so from the Microsoft tenant a compromise of most major service provider tenants is one step away. [...] Conclusion ─────────── This blog discussed a critical token validation failure in the Azure AD Graph API. While the vulnerability itself was a bad oversight in the token handling, the whole concept of Actor tokens is a protocol that was designed to behave with all the properties mentioned in the paragraphs above. If it weren't for the complete lack of security measures in these tokens, I don't think such a big impact with such limited telemetry would have been possible. Thanks to the people at MSRC who immediately picked up the vulnerability report, searched for potential variants in other resources, and to the engineers who followed up with fixes for the Azure AD Graph and blocked Actor tokens for the Azure AD Graph API requested with credentials stored on Service Principals, essentially restricting the usage of these Actor tokens to only Microsoft internal services. Disclosure timeline ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ • July 14, 2025 - reported issue to MSRC. • July 14, 2025 - MSRC case opened. • July 15, 2025 - reported further details on the impact. • July 15, 2025 - MSRC requested to halt further testing of this vulnerability. • July 17, 2025 - Microsoft pushed a fix for the issue globally into production. • July 23, 2025 - Issue confirmed as resolved by MSRC. • August 6, 2025 - Further mitigations pushed out preventing Actor tokens being issued for the Azure AD Graph with SP credentials. • September 4, 2025 - [CVE-2025-55241] issued. • September 17, 2025 - Release of this blogpost. [CVE-2025-55241] <https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-55241> Footnotes ───────── [1] I do not have access to any tenants in a national cloud deployment, so I was not able to test whether the vulnerability existed there. Since national cloud deployments use their own token signing keys, it is unlikely that it would have been possible to execute this attack from a tenant in the public cloud to one of these national clouds. I do consider it likely that this attack would have worked across tenants in the same national cloud deployments, but that is speculation. --8<---------------cut here---------------end--------------->8--- Saluti, 380° -- 380° (lost in /traslation/) «Welcome to the chaos of the times If you go left and I go right Pray we make it out alive This is Karmageddon»