Microsoft Entra Actor Token Impersonated a Global Admin in Testing

A token issued in one Microsoft Entra ID tenant could impersonate users in another tenant through the legacy Azure AD Graph API. Security researcher Dirk-jan Mollema used the flaw to reach a Global Administrator account in his test environment, giving the token the same directory authority as that administrator.

Mollema reported the issue to Microsoft on July 14, 2025. Microsoft deployed the main fix globally on July 17 and later blocked applications from requesting these actor tokens for Azure AD Graph with service-principal credentials. The company assigned CVE-2025-55241 in September.

Microsoft told Mollema that its internal telemetry found no abuse. That statement narrows what Microsoft observed; it cannot establish that every silent directory read was absent. The vulnerable API offered little customer-visible evidence for the early stages of the chain.

The token and tenant did not have to match

Actor tokens are backend service-to-service credentials issued by Microsoft’s Access Control Service. Mollema encountered them while researching hybrid Exchange. A trusted actor token allowed a service to create an unsigned impersonation token for a user and call Exchange Online, SharePoint or Azure AD Graph on that user’s behalf.

The Azure AD Graph flaw failed to validate that the tenant in the actor token matched the tenant named in the impersonation request. Mollema requested an actor token in his lab tenant, changed the target tenant ID and supplied the netId of a user in the second tenant. Azure AD Graph returned that user’s data.

Once he could impersonate a regular user, Mollema queried the directory for Global Administrators and their netId values. He then created another impersonation token for an administrator and used it to list data that the regular user could not access.

The useful identifiers were easier to obtain than they looked

Tenant IDs are public. The remaining input was a valid netId, an older identifier also exposed as the puid claim in Entra access tokens. Mollema described several ways to obtain one, including old token samples, incremental-value guessing and the alternativeSecurityIds attribute on B2B guest accounts.

The guest-account path was especially broad. A guest object in one tenant can carry the home-tenant user’s netId. With the vulnerable validation in place, that identifier could be placed in an impersonation token aimed back at the user’s home tenant. Mollema tested the individual steps only in tenants where he had authorization.

The NVD record classifies CVE-2025-55241 as an Entra ID elevation-of-privilege vulnerability caused by improper authentication. Microsoft scored it 10.0 under CVSS 3.1. National cloud deployments were outside Mollema’s test scope, and his comments about possible behavior within those environments remain speculation.

Customer controls could not stop the token

Actor-token issuance produced no log entry, according to Mollema. The service could craft the unsigned impersonation token without returning to Entra ID, and the actor token could not be revoked during its 24-hour lifetime. Conditional Access did not apply.

Azure AD Graph also lacked generally available API-level logging. Silent directory reads could therefore expose user details, roles, tenant settings, applications, service principals, device records and synced BitLocker keys without leaving evidence in the victim tenant.

Directory changes usually generated audit events. A write performed with an actor token could appear with the impersonated administrator’s user principal name but the display name of a Microsoft service such as Exchange. Mollema published a KQL query that looks for that mismatch while excluding several legitimate group operations known to use actor tokens.

The Microsoft advisory for CVE-2025-55241 describes an exclusively hosted Entra vulnerability. Customers had no patch to deploy. Microsoft’s service-side changes closed the known path.

Hunt for changes the token may have made

The strongest customer-side evidence begins where the silent part of the attack ends. Review Entra audit records for a user’s identity paired with the display name of Exchange Online, SharePoint Online, Skype for Business, Dataverse or Dynamics ERP. Use Mollema’s exclusions and validate findings against expected service activity before escalating.

Prioritize changes that create durable access: new users, privileged role assignments, application credentials, consent grants and API permissions. Review additions to Microsoft-owned service principals with particular care because Mollema identified them as another route to actor-token issuance before Microsoft’s additional mitigation.

Global Administrator membership also deserves a point-in-time review. Remove accounts that no longer need the role and keep daily administration on lower-privilege identities. Privileged Identity Management cannot prevent a provider-side impersonation bug, but fewer standing administrators reduce the list of identities an attacker can immediately adopt.

For response planning, separate what the tenant can prove from what the provider must answer. Customers can preserve audit changes and rotate credentials tied to altered objects. Microsoft owns the unavailable issuance and API-access telemetry. That distinction should appear in escalation procedures before the next hosted identity incident.

CVE-2025-55241 was fixed quickly. Its harder lesson is operational: when a cloud identity service accepts a backend credential across tenants, customer MFA and sign-in policy sit outside the failing path. Detection begins with the authority that changed, even when the token that changed it never appears in the tenant’s logs.