CVE-2025-55241: Entra ID Actor Token Impersonation Could Compromise Any Global Admin

What Was CVE-2025-55241: the Entra ID Actor Token Impersonation Flaw

CVE-2025-55241 is an Elevation of Privilege vulnerability in Microsoft Entra ID built on Entra ID Actor Token impersonation, discovered by independent security researcher Dirk-jan Mollema and reported to the Microsoft Security Response Center (MSRC) on July 14, 2025. Microsoft's own Common Vulnerabilities and Exposures (CVE) scoring rated it CVSS 10.0 (Critical); NVD's independent recalculation put it at 9.8 (Critical), with a CWE-287 (Improper Authentication) classification. Microsoft assigned the CVE on September 4, 2025 and stated no customer action was required, since the fix had already been deployed tenant-wide.

The flaw combined two things: an undocumented Microsoft-internal token type called an "Actor token," and a tenant-validation gap in the legacy Azure AD Graph API (graph.windows.net). Chained together, they let a holder of an Actor token from their own (attacker-controlled) tenant authenticate as any user — including Global Administrators — in any other Entra ID tenant, without needing that user's credentials, without triggering MFA, and without generating the audit trail defenders normally rely on. Mollema described the exposure as capable of compromising "every Entra ID tenant in the world," with the exception of national/sovereign clouds.

🚨 Danger: There is no evidence of exploitation in the wild, per both Microsoft and Mollema. This is a retrospective explainer of a vulnerability that Microsoft has already fixed globally — not an active threat requiring emergency action today.

Disclosure Timeline

• July 14, 2025 — Mollema reports the issue to MSRC; MSRC opens a case the same day.
• July 17, 2025 — Microsoft deploys a production fix to the tenant-validation gap in the Azure AD Graph API.
• July 23, 2025 — MSRC confirms to Mollema that the core issue is resolved.
• August 6, 2025 — Microsoft ships further mitigations restricting Actor token issuance for the Azure AD Graph API to Microsoft-internal services only.
• September 4, 2025 — Microsoft formally assigns CVE-2025-55241 and states no customer action is required.
• September 17, 2025 — Mollema publishes the full technical writeup, including detection guidance.

How the Actor Token Bypass Worked

Actor tokens are issued by Microsoft's Access Control Service (ACS) for service-to-service delegation — the mechanism that lets first-party backends such as Exchange Online "act as" a user when calling other Microsoft services on that user's behalf. According to Mollema's analysis, Actor tokens carry a trustedfordelegation claim and, once issued, effectively allow impersonation of any user in a tenant for up to 24 hours. This is a legitimate, long-standing internal mechanism — the vulnerability was in how a legacy consumer of these tokens validated them, not in the existence of the mechanism itself.

Two design gaps made this exploitable across tenant boundaries:

Unvalidated Tenant Origin

The legacy Azure AD Graph API failed to properly verify that the tenant ID embedded in an Actor token's impersonation claims matched the tenant actually being queried. Because the impersonation payload was carried in an unsigned JWT, an attacker could substitute a target tenant ID for their own without invalidating the token's signature — there wasn't one to break. That let a token minted for the attacker's own tenant be replayed as if it originated from any other tenant on Earth.

Predictable User Identifiers (netId)

The impersonation target within the destination tenant was resolved via netId, a legacy Microsoft Passport identifier still present in some Entra internals. Unlike an Entra object ID (a random GUID), netId values increment predictably. Mollema found they could be brute-forced in "minutes to hours" for a target tenant, and could also be harvested directly from guest users' alternativeSecurityIds attributes in B2B trust relationships, or from tokens leaked in logs, support tickets, and public screenshots.

Put together: an attacker who could request an Actor token from any tenant they controlled — including a free or trial tenant — could rewrite the target tenant ID and pair it with a resolved netId, and the legacy Azure AD Graph API would honor the resulting impersonation. That gave read and write access to directory data, the ability to create service principals, change role assignments, and modify Conditional Access policies as whichever user the token claimed to be, up to and including a Global Administrator.

Why MFA, Conditional Access, and Logging Couldn't Catch It

This is the part that made the flaw critical rather than merely serious: the bypass sat underneath the controls tenants rely on to catch account compromise.

• MFA and Conditional Access don't apply. Actor tokens are a service-to-service delegation mechanism, not an interactive sign-in — they don't pass through the Conditional Access policy engine at all, so per-user MFA, sign-in risk, and device compliance requirements are simply not evaluated. It's a reminder that MFA alone was never a complete control — it only covers the authentication paths it's actually wired into.
• Requesting the token generates no log. Per Mollema's writeup, obtaining an Actor token produces no tenant-visible log entry — an attacker could stage the attack with zero footprint in the target tenant.
• The legacy Graph API under-logs. graph.windows.net predates the logging depth that Microsoft Graph and Entra's modern audit pipeline provide, so even actions taken with the impersonation token were only partially captured.
• The token was effectively unrevocable in-window. As an unsigned, self-contained JWT valid for up to 24 hours, a leaked or forged Actor token could not be invalidated mid-flight the way a compromised session token can.

Detection: What to Look For

Because Microsoft's fix closed the underlying access path, detection here is retrospective — reviewing Entra audit history for signs the technique was used against your tenant before the patch — rather than a live monitoring control. Mollema published a KQL query for exactly this: Actor-token-driven changes still show up in AuditLogs, but with a telltale mismatch between the acting service's display name and the actual initiating context.

AuditLogs
| where not(OperationName has "group")
| where not(OperationName == "Set directory feature on tenant")
| where InitiatedBy has "user"
| where InitiatedBy.user.displayName has_any (
    "Office 365 Exchange Online", "Skype for Business Online", "Dataverse",
    "Office 365 SharePoint Online", "Microsoft Dynamics ERP")

What the Query Won't Catch

This query, adapted from Mollema's published writeup, flags directory modifications made via Actor token impersonation. It will not catch read-only reconnaissance — user or group enumeration, secret harvesting, policy review — which the legacy API did not log in enough detail to reconstruct after the fact. Treat a clean result from this query as evidence you found no write activity through this path, not as proof the tenant was never read.

Remediation

Microsoft's own fix required no customer action: MSRC confirmed the tenant-validation issue was resolved by July 23, 2025, and by August 6, 2025 further restricted Actor token issuance for the Azure AD Graph API to Microsoft-internal services only. That closes this specific chain. The durable remediation for tenants is to reduce reliance on the legacy surface and the privilege patterns this flaw exploited:

1. Retire dependencies on Azure AD Graph. Audit your app registrations and service principals for any that still call Azure AD Graph and migrate them to Microsoft Graph; every dependency you remove is one less surface exposed to the next legacy-API validation bug.
2. Eliminate standing Global Administrator assignments. This flaw's worst-case outcome was full Global Admin impersonation. Moving admin roles to just-in-time activation through Privileged Identity Management (PIM) shrinks the number of accounts a successful impersonation could actually use meaningfully.
3. Require phishing-resistant MFA on every privileged role, not just interactive sign-in in general — this doesn't stop a service-to-service token bypass like Actor tokens, but it closes the far more common path attackers actually use to reach admin accounts.
4. Block legacy authentication tenant-wide via Conditional Access. Legacy auth doesn't support modern token validation or Conditional Access enforcement, and tenants that still allow legacy auth or leave Conditional Access gaps open broaden the same class of exposure that made this vulnerability so severe: authentication paths the modern control plane can't see.
5. Review Entra AuditLogs retention and alerting for the anomalous-initiator pattern described above, so any future first-party-service impersonation bypass produces an alert rather than silence. A broader Entra ID security audit covers this alongside the rest of your tenant's posture, including the default settings that new tenants ship with.

Why the Legacy API Mattered Beyond This CVE

Microsoft has been retiring graph.windows.net in stages since its 2019 deprecation announcement: new applications were blocked from first use starting August 31, 2024, and extended-access opt-in has been required tenant-wide since February 1, 2025, with apps that don't opt in losing access outright. Microsoft has stated plainly that it makes no further investment in Azure AD Graph beyond security fixes, and that all new capability goes to Microsoft Graph. CVE-2025-55241 is a concrete illustration of why that migration matters beyond compliance checkbox: a deprecated, under-logged, under-maintained API surface is exactly where a validation gap like this one goes unnoticed the longest.

How EtcSec Detects This

EtcSec's Entra ID audit doesn't have visibility into Microsoft's internal Actor token plumbing — that control plane is entirely inside Microsoft's infrastructure and was never something a tenant-side audit could observe or fix directly. What EtcSec does check, continuously, is the set of tenant-side conditions that determine how much damage any impersonation-class bypass (this one or the next one) can do: standing Global Administrator assignments (PA_TOO_MANY_GLOBAL_ADMINS, PA_PERMANENT_ADMIN_ASSIGNMENTS), admin accounts without strong MFA (PA_GLOBAL_ADMIN_NOT_MFA), and tenants that still allow legacy authentication paths outside Conditional Access enforcement (CA_NO_LEGACY_AUTH_BLOCK).