Microsoft Patches Critical Vulnerability in Entra ID

A dangerous combination of legacy components in Microsoft's ecosystem could have opened the door to full control of any Entra ID tenant in the world.

It all came down to two key elements: undocumented tokens known as actor tokens, and a vulnerability in the legacy Azure AD Graph API (identified as CVE-2025-55241). Together, these flaws allowed an attacker to generate valid tokens for any company’s Entra ID environment without restrictions.

The result? A malicious actor could have accessed extremely sensitive data—such as emails, internal files, administrative settings, and more—without triggering any visible alerts in the compromised environment’s logs. The only trace would be what they did with that access.

At TecnetOne, we want to explain how this type of flaw worked, why it poses a real risk to businesses, and what actions you can take to strengthen your infrastructure's security.

What is Entra ID and why is this so serious?

Microsoft Entra ID (formerly known as Azure Active Directory or Azure AD) is Microsoft's central cloud-based identity and access control system. It allows organizations to manage who can access what, both inside and outside their corporate network.

With Entra ID, companies provide single sign-on (SSO), multi-factor authentication (MFA), and security policies to access critical services such as:

1. Microsoft 365 (Outlook, Teams, SharePoint, etc.)

2. Custom cloud or on-premises applications

3. SaaS platforms like Salesforce, Google Workspace, Dropbox, SAP, or AWS

Each Entra ID tenant represents a distinct organization, with its own set of users, roles, policies, and applications. This means compromising a tenant is equivalent to compromising the entire company: access to emails, files, identities, databases, and more.

What could attackers do with this access?

The flaw allowed an attacker to impersonate a legitimate application and obtain global administrator permissions—the highest-level role within any Entra ID tenant. This means:

1. Full control over users and groups

2. Modification or deletion of security configurations

3. Access to protected data

4. Interaction with any service authenticated via Entra ID

And all of this, without anyone noticing… at least, not immediately.

User Impersonation in Entra ID: How Actor Tokens Worked

One of the most alarming discoveries related to the Entra ID flaw was the ability to impersonate any user within a tenant using little-known tokens called “actor tokens.”

These tokens were issued by a legacy Microsoft service called Access Control Service (ACS). Originally, this system was created to enable authentication with applications like SharePoint and is still used internally by Microsoft for certain service-to-service communications.

The discovery originated while investigating hybrid Exchange configurations. During the analysis, it was found that Exchange requested these tokens when communicating with other services on behalf of a user. In other words, the token allowed an application or service to "act" as that user, with access to services like Exchange Online, SharePoint, and, by extension, the Azure AD Graph API.

The most critical issue was that these actor tokens were not digitally signed, which created a massive security gap:

1. They could be used to impersonate any user in the tenant.

2. They were valid for 24 hours, during which they couldn’t be revoked.

3. They left no trace in standard Entra ID logs—neither when issued nor when used.

4. They completely bypassed the conditional access policies configured by companies.

5. The only way to detect their use was through the target service’s own logs.

This means an attacker who managed to generate one of these tokens could operate for a full day with another user's privileges (including administrators) without leaving clear evidence in centralized security logs.

Additionally, because these tokens could be created without involving Entra ID (meaning they bypassed its validation mechanisms), there was no effective way to audit their issuance from the main identity platform.

The Azure AD Graph bug indicates that the token is valid but the user does not exist.

Read more: Microsoft and Cloudflare Shut Down RaccoonO365 Phishing Hub

How Did Microsoft Respond?

Researcher Dirk-jan Mollema reported the vulnerability to Microsoft in mid-July 2025. In response, the Redmond security team acted quickly: they investigated the issue, applied mitigations directly in the cloud, and restricted the use of actor tokens that enabled this type of impersonation.

Shortly after, Microsoft confirmed that the flaw had been resolved and assigned it the official identifier CVE-2025-55241, along with publishing a security advisory to help administrators review their configurations. According to available reports, technical fixes were rolled out in July, while the public disclosure of the CVE and its details occurred in September 2025.

Regarding its internal investigation, Microsoft stated that it found no evidence of active exploitation of the vulnerability. However, as is often the case, the absence of evidence does not guarantee the flaw wasn’t used in an unmonitored environment.

What Can Companies Do to Protect Themselves?

Although Microsoft has already implemented platform-level mitigations, that doesn't mean the risk is fully neutralized. Every organization must assume that vendor updates are necessary, but not always sufficient. Here are several key recommendations to strengthen your environment’s security:

Ensure Everything Is Up to Date

1. Verify that your Microsoft tenant is running the latest Entra ID protections.

2. Make sure the mitigations applied by Microsoft for CVE-2025-55241 are correctly implemented in your organization.

Audit Privileged Roles

1. Review administrative roles and remove any unnecessary global administrators.

2. Whenever possible, implement Just-In-Time (JIT) and Just-Enough Access (JEA) models to reduce unnecessary access exposure.

Improve Visibility and Monitoring

1. Strengthen API-level telemetry to gain traceability of access, especially with services like Graph API.

2. Centralize logs into a SIEM solution (such as TecnetOne’s SOC) and configure specific alerts to detect anomalous cross-tenant behavior.

Strengthen Conditional Access

1. Ensure that your conditional access policies are well-defined and up to date.

2. Review any legacy applications or integrations that may still depend on old tokens or obsolete APIs like Azure AD Graph, which Microsoft is phasing out in favor of Microsoft Graph.

Conclusion

Although the issue has been technically resolved, this situation is a clear reminder of the risks that can arise from maintaining legacy components or unreviewed configurations in identity infrastructure.

At TecnetOne, we recommend not relying solely on automatic patches. A strong security strategy involves regular audits, active monitoring, patch management, the removal of unnecessary access, and a deliberate migration toward modern and secure technologies.