Critical Entra ID Impersonation Flaw - CVE-2025-55241 • William OGOU Cybersecurity Blog

Security researcher Dirk-jan Mollema has uncovered a critical vulnerability in Microsoft Entra ID that allowed an attacker, using nothing more than a free, separate Entra ID tenant, to impersonate any user, in any organization, at any time. Tracked as CVE-2025-55241, this flaw is not just a theoretical bug; it’s a catastrophic failure of the very token validation logic that is supposed to underpin our digital trust.

This is the story of how that trust was an illusion, how the attack worked, and the immediate steps every security team must take to hunt for signs of compromise.

The Attack Vector: The Deceptive Power of “Actor Tokens”

To understand this flaw, you need to understand a legitimate, if less common, feature of Entra ID: the “actor token” (represented as an actort claim within a JSON Web Token - JWT). This mechanism is part of the On-Behalf-Of (OBO) flow, designed for complex, multi-tier applications.

Think of it like a trusted introduction. An application (App A) might need to call another application (App B) on behalf of a user. To do this, it presents its own token to Entra ID, along with an “actor token” proving it has already authenticated the user. Entra ID is supposed to validate this entire chain before issuing a new token for App B.

The vulnerability was a simple but devastating logic flaw in this validation process. Entra ID was incorrectly checking the identity of the impersonator instead of checking the identity of the application it was trying to access. An attacker could craft a special token where they were a legitimate owner of the “impersonating” application, and Entra ID would mistakenly grant them access to the target application they had no right to touch.

The Kill Chain: From a Free Tenant to Global Admin in 4 Steps

The brilliance and terror of this attack lie in its simplicity and its incredibly low barrier to entry. An attacker doesn’t need to be on your network or have any of your user’s credentials.

Step 1: The Setup (The Attacker’s Tenant): The attacker registers a new, free Microsoft Entra ID tenant. Within this tenant, they register a new multi-tenant application. They are the legitimate owner of this application.
Step 2: The Forgery (Crafting the Malicious Token): The attacker obtains a legitimate access token for their own application. They then manually construct a new, malicious token.
- The Outer Token is crafted to look like a request for a high-value application in the victim’s tenant, such as SharePoint Online or the Microsoft Graph API. It specifies the victim’s User ID (Object ID) as the user being impersonated.
- The Inner Token (the actort claim) is the legitimate, valid token from the attacker’s own application.
Step 3: The Deception (Presenting the Token): The attacker sends this specially crafted, nested token to the target application (e.g., SharePoint Online). The application, seeing a token it can’t validate on its own, forwards it to Entra ID for verification, as it’s supposed to.
Step 4: The Flaw (The Compromise): This is the moment of failure. The Entra ID validation service inspects the token. It sees the actort claim and, due to the vulnerability, focuses its validation on this inner token. It sees a valid token for the attacker’s application, which the attacker legitimately owns. Based on this misplaced trust, it incorrectly grants the request and issues a brand new, valid access token for the victim’s application (SharePoint), in the name of the victim user.

Game over. The attacker now has a valid session token and can access the victim’s SharePoint, read their email via the Graph API, or perform any other action as that user, completely bypassing MFA and all other security controls.

The Impact: A Universal Key to Every Organization

The implications of this vulnerability are staggering. Because it’s a flaw in the central Entra ID system, it was a multi-tenant threat by default. An attacker in their own isolated tenant could use this method to attack any other Entra ID tenant in the world.

With a compromised token for a Global Administrator, an attacker could:

Create persistent, rogue administrator accounts.
Access and exfiltrate data from any user’s mailbox, SharePoint sites, or OneDrive.
Modify or disable security policies and conditional access rules.
Deploy malicious applications with high-level permissions.
Use their access to pivot into the on-premises environment in hybrid setups.

This was, in effect, a universal key, limited only by the attacker’s ability to guess or enumerate the User IDs of high-value targets.

Patch, Hunt, and Harden

This is a three-phase response: understand the fix, hunt for past compromise, and harden your defenses against future identity-based threats.

Phase 1: Understand the Fix (The Good News)

The most important news is that Microsoft has fixed this vulnerability on the backend. There are no patches for you to deploy on your servers or endpoints. The flawed token validation logic has been corrected globally by Microsoft’s engineering teams. Your environment is no longer vulnerable to this specific attack chain.

Phase 2: Hunt for Compromise (The Critical Task)

The bad news is that your organization may have been compromised before the fix was deployed. You must now hunt for the specific indicators of this attack in your logs.

Action: Your SecOps and Identity teams need to immediately query your Entra ID sign-in logs for the tell-tale signs of this attack. The researcher, Dirk-jan Mollema, provided the critical forensic details.

What to look for: A successful exploit generates a unique sign-in log event. It will be an interactive sign-in (SignInEventTypes equals 50) that was satisfied by an “MFA claim in the token,” but crucially, it will also contain the malicious actort claim.
The KQL Query for Microsoft Sentinel: You can use the following KQL query in Microsoft Sentinel or Azure Log Analytics to search for these specific IOCs.
```
SigninLogs
| where TimeGenerated > ago(90d) // Or your desired lookback period
| where SignInEventTypes has "50"
| where AuthenticationDetails has "MFA requirement satisfied by claim in the token"
| extend ActorToken = MfaDetail.MfaAuthDetail
| where ActorToken has "actort"
| project TimeGenerated, UserPrincipalName, AppDisplayName, IPAddress, ActorToken, ConditionalAccessStatus
```

Run this query immediately. Any results should be treated as a confirmed compromise and trigger your highest-priority incident response plan.

Phase 3: Harden Your Identity Posture

This vulnerability is a powerful lesson in the fragility of cloud identity. Use it as a catalyst to strengthen your defenses against the next generation of identity-based attacks.

Continuously Monitor Sign-in Logs: The ability to run queries like the one above is not a one-time task. Ensure your SOC has the tools (like Microsoft Sentinel) and the expertise to continuously monitor and hunt for anomalies in your Entra ID logs.
Enforce Strict Conditional Access Policies: While this attack bypassed MFA, your Conditional Access policies remain your most powerful defense. Ensure you have policies that enforce trusted locations and compliant devices for all users, especially administrators.
Embrace Continuous Access Evaluation (CAE): For critical applications, enable CAE. This allows Entra ID to revoke access tokens in near real-time in response to critical events (like a user being disabled or a risky sign-in being detected), rather than waiting for the token to expire.

Conclusion: The End of an Illusion

The “Actor Token” vulnerability was a sobering reminder that even in the most mature cloud platforms, a single logic flaw can have catastrophic consequences. It has shattered the illusion that our identity systems are impenetrable fortresses and has reinforced the absolute necessity of a Zero Trust mindset: we must never implicitly trust a token, a user, or an application. We must continuously verify everything.

While Microsoft has repaired this critical crack in the foundation, our work as defenders is to hunt for the aftershocks and use this event as a catalyst to build a more resilient, more vigilant, and more secure identity posture for the future.

To further enhance your cloud security and implement Zero Trust, contact me on LinkedIn Profile or [email protected].

Entra ID “Actor Token” Vulnerability FAQ (CVE-2025-55241)

What was the “Actor Token” vulnerability (CVE-2025-55241)? It was a critical privilege escalation vulnerability in Microsoft Entra ID’s token validation logic. It allowed an attacker from any Entra ID tenant to craft a special “actor token” and use it to impersonate any user, including Global Administrators, in any other tenant.
Is there a patch I need to install? No. The vulnerability was in the central Entra ID service and has been fixed on the backend by Microsoft. There is no action required from customers to apply the fix itself.
Does this attack bypass MFA? Yes. Because the attack exploits a flaw in the token validation process, it allows an attacker to gain an access token that already has an “MFA satisfied” claim within it. This effectively bypasses all interactive MFA prompts for the victim.
How can I check if I was compromised? You must query your Entra ID sign-in logs for a specific pattern: an interactive sign-in that was satisfied by an “MFA claim in the token” and also contains an actort claim. The KQL query provided in this article is designed to find this specific indicator.
Who was affected by this vulnerability? Potentially every Microsoft Entra ID tenant was at risk before the patch was deployed, as the vulnerability was in the core, multi-tenant service.