Hacking Every Entra ID Tenant With Actor Tokens

Hacking Every Entra ID Tenant With Actor Tokens

Speakers: Dirk-Jan Mollema, Freelancer, Outsider Security

Conference: Area41

YouTube: https://www.youtube.com/watch?v=UU_UkmXJGHg

Overview

In a groundbreaking presentation at Area41, security researcher Dirk-Jan Mollema unveiled a critical vulnerability that could have allowed attackers to gain global administrator access to virtually any Microsoft Entra ID (formerly Azure Active Directory) tenant. Titled "Hacking Every Entra ID Tenant With Actor Tokens," Mollema detailed a complex, multi-year research journey that culminated in the discovery of a profound architectural flaw related to legacy "actor tokens" and hybrid Exchange deployments. This talk exposed a chain of vulnerabilities that bypassed all standard security controls, including Conditional Access policies and logging, offering an attacker a stealthy and potent path to total cloud environment compromise.

Mollema's research highlights the persistent risks associated with legacy systems and the intricate interactions within Microsoft's vast cloud ecosystem. The core of the issue revolved around the misuse of "service-to-service" tokens, which, when combined with a specific flaw in how Entra ID validated these tokens, enabled cross-tenant impersonation. This meant that an attacker who compromised an on-premises Exchange server in a hybrid setup could, with minimal effort, elevate their privileges to global administrator in any other Entra ID tenant globally, provided they could identify a valid user's internal identifier.

The implications of this discovery were immense, threatening the security posture of countless organizations relying on Microsoft Entra ID. Mollema's methodical approach, tracing back years of his own research on hybrid cloud security, not only revealed the technical specifics of the exploit but also underscored the challenges of securing complex, evolving cloud environments where legacy components can harbor severe vulnerabilities. Microsoft, upon receiving Mollema's report, acted with unprecedented speed to mitigate the flaw, recognizing the severe cross-tenant impact and the potential for widespread exploitation.

Background

▶ Watch: Introduction and backstory on Entra ID research (0:00)

Dirk-Jan Mollema's journey to uncovering the actor token vulnerability began much earlier, rooted in his extensive research into hybrid Microsoft environments. His initial focus, dating back to 2019, explored the attack surface presented when an on-premises Active Directory (AD) is connected to Azure Active Directory (now Entra ID). His first talk at Troopers in 2019 specifically investigated how a compromise of the on-prem AD could lead to a pivot into the cloud.

A key component of this hybrid setup was Azure AD Connect (now Entra Connect Sync), the synchronization service. Historically, this service ran with highly privileged permissions. Initially, the sync account was a Global Admin in Entra ID, making a pivot from on-prem to cloud straightforward. While Microsoft later created a dedicated, less privileged role for this account – the Directory Synchronization Account – Mollema found that even this role retained dangerous capabilities. It could modify service principals, which are automation accounts often holding privileged roles, and it could modify or even delete Conditional Access policies, the core security configurations in Entra ID. These actions were possible through a specific, undocumented, internal version of the legacy graph.windows.net API. Despite reporting these findings, Microsoft initially deemed them "by design," only addressing the Conditional Access policy deletion in 2023 and blocking all these attack paths in August 2024.

Mollema’s research continued, leading to the development of Road Recon, an open-source tool for enumerating Entra environments and analyzing tokens. Through Road Recon, he discovered that the Entra Connect account's policy modification privileges extended to other critical security settings. This included the ability to add seamless single sign-on (SSO) keys, which could bypass first-factor authentication, and to provision external authentication providers, enabling a bypass of multi-factor authentication (MFA). These findings further solidified the attack path from on-prem compromise to significant cloud control. However, by August 2024, Microsoft had patched all these known attack vectors, completely blocking the synchronization account from modifying objects via either Microsoft Graph or Azure AD Graph APIs.

With his previous attack paths effectively nullified, Mollema was motivated to find new ways to pivot from an on-premises compromise to the cloud. This led him to revisit an old idea from 2019: the security of Exchange Hybrid setups. These environments, where some mailboxes reside on-prem and others in Microsoft 365, involved the on-premises Exchange server interacting with Exchange Online using a shared Microsoft service principal. This service principal, often highly privileged, now included on-premises redirect URLs, suggesting the on-prem Exchange server could perform OAuth authentication. This re-examination of Exchange Hybrid became the critical pivot point for discovering the actor token vulnerability, as it exposed an entirely new, and far more dangerous, attack surface.

Key Findings

▶ Watch: Uncovering the legacy "actor token" authentication protocol (12:15)

Mollema's pivotal discovery revolved around the concept of actor tokens, a legacy "service-to-service" authentication mechanism used within Microsoft's backend infrastructure and, crucially, by hybrid Exchange deployments. The research revealed that:

1. Discovery via Exchange Hybrid: The vulnerability chain began with the compromise of an on-premises Exchange server configured in a hybrid setup. This setup utilized a shared Microsoft service principal for communication between on-prem Exchange and Exchange Online. This service principal, being a Microsoft application, inherently possessed high privileges in Entra ID.
2. Exportable Certificates: Mollema found that the client certificate used by the on-premises Exchange server for OAuth authentication with this shared service principal was easily exportable. It was not marked as non-exportable, allowing an attacker with administrative access to the Exchange server to extract the private key through a simple GUI operation.
3. Actor Token Generation: By using the extracted certificate, Mollema could authenticate to a legacy Microsoft service called Access Control Service (ACS). This service, distinct from standard Entra ID authentication endpoints, issued "actor tokens." These tokens were identified by their unique OAuth request parameters and, critically, by a trusted for delegation flag within the token.
4. Impersonation Protocol: Actor tokens are designed for impersonation. They allow the holder to "act on behalf of" any user within the tenant. Mollema demonstrated this by embedding the signed actor token within a locally generated, unsigned JSON Web Token (JWT). By simply changing the User Principal Name (UPN) or name ID in the unsigned outer token, he could impersonate any user, including highly privileged accounts, in Exchange Online and SharePoint Online.
5. Stealth and Persistence: These actor tokens possessed highly dangerous properties:

• 24-hour validity: Once obtained, they remained valid for a full day.
• No revocation: There was no mechanism to revoke an issued actor token.
• No logs: The issuance of these tokens generated no audit logs, making detection extremely difficult.
• Bypassed security policies: Because the outer token was locally generated and unsigned, it bypassed all Entra ID security policies, including Conditional Access and MFA requirements.

1. Escalation to Global Admin: The initial impact on Exchange and SharePoint was significant but not the ultimate goal. Mollema discovered that the Exchange service principal, when requesting tokens for other APIs, could obtain permissions like Domain.ReadWrite.All on Microsoft Graph, allowing domain manipulation. More critically, requesting a token for the Azure AD Graph (graph.windows.net) yielded an actor token with trusted for delegation: true, enabling full tenant management. By querying the name ID (a legacy unique identifier) of a global administrator and injecting it into the unsigned token, Mollema could fully impersonate a global admin.
2. Cross-Tenant Compromise (The "Every Tenant" Part): The most devastating finding was the ability to perform cross-tenant impersonation. The critical flaw lay in how Entra ID processed these nested tokens. While the inner actor token was signed and contained the tenant ID of the issuing tenant (Mollema's lab tenant), the outer, unsigned token's tenant ID could be arbitrarily changed. Entra ID's validation logic, or lack thereof, meant it would accept an actor token from one tenant and apply its impersonation capabilities to a different target tenant, as long as a valid name ID from the target tenant was provided.
3. Target ID Acquisition: To exploit the cross-tenant aspect, an attacker needed a target tenant's ID and a valid name ID of a user within it. Tenant IDs are easily discoverable. name IDs could be brute-forced (as they were sequential) or, more effectively, extracted from B2B guest invites. When a user accepts a guest invite into an attacker-controlled tenant, their home tenant's name ID is exposed in the alternative security IDs property of their guest account. This allowed an attacker to map name IDs to users in their home tenants.
4. Exponential Compromise: The B2B invite vector created an exponential compromise path. An attacker could invite users from various organizations, collect their name IDs, compromise their home tenants, and then repeat the process from those newly compromised tenants, potentially compromising a vast network of Entra ID tenants rapidly and stealthily. Mollema even speculated about compromising Microsoft's own tenant due to their consultants frequently accepting invites to client tenants.

Technical Deep Dive

▶ Watch: Escalating privileges to Global Admin with actor tokens (21:00)

The technical foundation of this widespread vulnerability rested on a confluence of legacy authentication mechanisms, shared service principals, and an critical flaw in token validation.

1. Exchange Hybrid and Service Principal Configuration:

The journey began with the Exchange Hybrid setup. In such a configuration, a single Microsoft-managed service principal is used by both the on-premises Exchange server and Exchange Online. This service principal, often identified by a GUID like 00000002-0000-0ffs-ce00-000000000000 (for Exchange Online), is configured with on-premises redirect URLs. This enables the on-prem server to participate in OAuth flows as a confidential client. For a confidential client, authentication requires a shared secret, typically a certificate or a client secret.

2. Certificate Extraction:

Mollema found that the client certificate provisioned on the on-premises Exchange server for this OAuth communication was trivially extractable. By default, the private key associated with this certificate was marked as exportable. An attacker with administrative access to the Exchange server could simply open certmgr.msc, locate the certificate, and export it as a PFX file, including the private key, without any additional security measures. This PFX file then contained the cryptographic material necessary to impersonate the Exchange service principal.

3. Discovering Actor Tokens via test-OAuthConnectivity:

The existence and usage of actor tokens were unveiled through the test-OAuthConnectivity PowerShell cmdlet, designed to diagnose communication between on-prem Exchange and Exchange Online. Running this cmdlet with verbose logging revealed a peculiar authentication flow:

• The on-prem Exchange server was not directly communicating with standard Entra ID endpoints.
• Instead, it was interacting with a service called ACS (Access Control Service). ACS is a legacy identity provider that predates modern Entra ID for certain service-to-service scenarios.
• The cmdlet's output showed the Exchange server requesting an "actor token" from ACS.

4. Actor Token Request and Structure:

The OAuth request to ACS was non-standard for modern Entra ID:

• Endpoint: It used a /2 endpoint, indicative of a legacy API.
• Grant Type: urn:ietf:params:oauth:grant-type:jwt-bearer.
• Assertion: The request included a signed JWT (JSON Web Token) assertion, signed using the private key from the extracted certificate, proving the identity of the Exchange service principal.
• Resource: The target resource was specific to Exchange Online, often in the format of a GUID or URL.

The response from ACS was an "actor token," which is itself a signed JWT. Key claims within this token included:

• aud (audience): The GUID and URL of the Exchange Online service.
• iss (issuer): The ACS service itself, representing Entra ID.
• trusted for delegation: true: This crucial claim explicitly indicated that the token was intended for impersonation, allowing the holder to act on behalf of other users.

5. Impersonation with Unsigned Tokens:

The core of the impersonation technique involved a two-layer token structure:

• Inner Token: The valid, signed actor token received from ACS, containing the trusted for delegation claim.
• Outer Token: A locally generated, unsigned JWT. This outer token encapsulated the inner signed actor token.

The critical characteristic of the outer token was its alg: none (none algorithm) signing algorithm. This meant the outer token was not cryptographically protected, allowing an attacker to modify its claims at will. Specifically, the attacker could insert a upn (User Principal Name) or, for certain legacy APIs, a name ID claim into this unsigned outer token, specifying the user they wished to impersonate. When this composite token was presented to target services (like Exchange Online or SharePoint), the service would trust the trusted for delegation flag from the inner signed token and accept the upn/name ID from the outer unsigned token for impersonation.

6. Privilege Escalation to Global Admin:

Initially, actor tokens granted access to Exchange Online and SharePoint. However, Mollema broadened his scope:

• Microsoft Graph: By requesting an actor token for the Microsoft Graph API, the Exchange service principal could obtain permissions such as Domain.ReadWrite.All. This allowed an attacker to add new domains, mark domains as federated, and potentially take over authentication for a tenant.
• Azure AD Graph (graph.windows.net): Requesting an actor token for the legacy Azure AD Graph API yielded the most powerful result. This API is used for managing the entire Entra ID tenant. The returned actor token also contained trusted for delegation: true. For this specific API, impersonation relied on the name ID attribute, a legacy unique identifier for users. By querying the name ID of a Global Administrator (which the Exchange service principal had permissions to do) and injecting it into the unsigned outer token, Mollema could fully impersonate that Global Administrator, gaining complete control over the tenant (e.g., creating new users, assigning roles, modifying Conditional Access policies).

7. The Cross-Tenant Vulnerability:

The most severe aspect was the cross-tenant bypass. When a composite token (unsigned outer, signed inner) was presented to the Azure AD Graph API, the API's validation logic had a critical flaw:

• It honored the trusted for delegation claim from the inner, signed actor token, which was issued for a specific tenant (the attacker's lab tenant).
• However, it failed to adequately validate that the tenant ID specified in the outer, unsigned token matched the tenant ID within the inner, signed token.
• This meant an attacker could generate an actor token in their own tenant (Tenant A), then craft an unsigned outer token where the tenant ID was set to a different target tenant (Tenant B). As long as a valid name ID from Tenant B was inserted into the outer token, the Azure AD Graph API would process the request as if it originated from a global administrator within Tenant B.

8. Acquiring Target name IDs:

To exploit the cross-tenant vulnerability, the attacker needed the name ID of a user in the target tenant. Mollema identified several methods:

• Brute-Forcing: name IDs were found to be sequential, making them susceptible to brute-force attacks, though time-consuming.
• Existing Tokens: An attacker could extract name IDs from any existing Entra ID tokens (even expired ones) found through OSINT or prior breaches.
• B2B Guest Invites (Most Effective): This was the most potent method. When a user from an external organization (Tenant B) accepts a B2B guest invitation into an attacker-controlled tenant (Tenant A), their guest account in Tenant A contains a property called alternative security IDs. This property, when base64-decoded, reveals the name ID of the user in their home tenant (Tenant B). This meant that merely inviting a user as a guest allowed an attacker to discover the identifier needed to compromise their home tenant.

This chain of vulnerabilities, from certificate extraction to cross-tenant name ID impersonation, presented an unprecedented attack surface, allowing an attacker to move from a relatively contained on-premise compromise to potentially owning any Entra ID tenant globally.

Demo / Proof of Concept

▶ Watch: Explaining exponential tenant compromise via B2B links (28:00)

Dirk-Jan Mollema's presentation included compelling demonstrations that visually underscored the severity of the actor token vulnerability.

The initial proof of concept focused on the impersonation capabilities within a single tenant for Microsoft 365 services. Mollema demonstrated how, after obtaining an actor token from a compromised Exchange Hybrid setup, he could craft local, unsigned tokens to impersonate any user in the tenant for SharePoint Online (which also encompasses OneDrive).

The demo sequence involved:

1. Token Generation: Using a custom script, Mollema generated an unsigned actor token, embedding the valid signed actor token (from Exchange) and specifying the User Principal Name (UPN) of a target test account in his lab tenant. This target account was a global administrator, though the impersonation worked for any user.
2. Browser Injection: He then launched a web browser and injected this locally generated token directly into the browser session.
3. SharePoint/OneDrive Access: Upon injection, the browser immediately opened the OneDrive interface for the impersonated user. The demo clearly showed access to the user's files and folders, demonstrating full access to their SharePoint/OneDrive data.
4. User Switching: To emphasize the "act on behalf of anybody" capability, Mollema closed the browser, modified the UPN in his script to a different test user, regenerated the token, and re-injected it. The browser then opened the OneDrive of this second user, seamlessly switching context and confirming the wide-ranging impersonation power.

The most impactful demonstration, however, showcased the cross-tenant global administrator escalation. While Mollema stated that he performed the actual cross-tenant test against his own real tenant (and then immediately reported it), the demonstration for MSRC (and the conference audience) simulated this by performing the escalation within a single target tenant, but using the same technical mechanism that enabled cross-tenant compromise.

This advanced demo involved:

1. Target ID Acquisition (Simulated): Mollema explained the process of acquiring a target name ID (e.g., from a guest invite). For the demo, he manually queried the name ID of an existing global administrator in a test tenant.
2. Global Admin Creation Script: He then executed a custom script that leveraged the actor token's capabilities against the Azure AD Graph API. This script performed the following actions, impersonating a global administrator:

• Created a new user account in the target Entra ID tenant.
• Assigned the Global Administrator role to this newly created user.

1. Interactive Login Verification: After the script completed, Mollema navigated to admin.microsoft.com (the Entra admin center). He then logged in interactively using the credentials of the newly created user.
2. Role Verification: The demonstration concluded by showing the user's profile in the admin center, explicitly confirming that the new account had indeed been assigned the Global Administrator role. This proved a complete privilege escalation from an on-premises compromise to full control over an Entra ID tenant, using the actor token mechanism.

These demonstrations left no doubt about the severity and potential for widespread abuse of the actor token vulnerability, highlighting its ability to bypass all conventional security measures and grant attackers unfettered access across Microsoft's cloud ecosystem.

Defensive Implications

▶ Watch: Microsoft's rapid 3-day fix and mitigations (30:20)

The discovery and rapid remediation of the "Hacking Every Entra ID Tenant With Actor Tokens" vulnerability by Microsoft underscore several critical defensive implications for organizations utilizing Microsoft Entra ID and related services.

1. Immediate Microsoft Mitigation:

Microsoft's response to Dirk-Jan Mollema's report was exceptionally swift, with a fix deployed to production within three days – an unprecedented timeline for such a complex vulnerability. This rapid action highlights the severity of the cross-tenant impact and the potential for widespread exploitation. The mitigations implemented include:

• Blocking Actor Token Requests: Microsoft blocked the ability to request and use actor tokens for Exchange Online and SharePoint Online through the vulnerable path.
• Reducing Internal Use: Microsoft also reduced its own internal reliance on actor tokens for service-to-service communication, acknowledging the inherent risks of this legacy mechanism.
• Split Service Principals for Exchange Hybrid: To prevent future similar issues, Microsoft now requires a split service principal for Exchange Hybrid deployments, meaning organizations must "bring their own service principal" rather than relying on a shared, highly privileged Microsoft-managed one. This isolates the permissions and prevents a single compromise from affecting a broader scope.

2. Audit Legacy Components and APIs:

The vulnerability originated from legacy components (ACS, Azure AD Graph API) and a legacy authentication flow. Organizations should:

• Identify Legacy Dependencies: Conduct thorough audits to identify any reliance on older APIs (e.g., graph.windows.net), services, or authentication mechanisms.
• Migrate to Modern Alternatives: Prioritize migrating away from legacy components to modern, more secure alternatives (e.g., Microsoft Graph API, modern OAuth flows).
• Understand Hybrid Risks: Hybrid environments, while necessary for many organizations, often introduce complex attack surfaces where on-premises compromises can pivot to the cloud. Regularly review the security posture of all hybrid components, especially those with cloud synchronization or authentication roles.

3. Review Service Principal Permissions:

The Exchange service principal was highly privileged, a characteristic of many Microsoft-managed applications. While this specific vulnerability is patched, the principle remains:

• Least Privilege for Service Principals: Ensure that all service principals (both custom and Microsoft-managed, where configurable) are granted only the absolute minimum permissions required for their function.
• Regular Audits: Periodically audit service principal permissions, especially for those involved in hybrid scenarios or with high-privilege roles like Domain.ReadWrite.All.

4. Secure Private Keys and Certificates:

The initial attack vector relied on the exportability of a private key from an on-premises server.

• Non-Exportable Private Keys: Whenever possible, private keys for certificates used in authentication or critical operations should be marked as non-exportable and stored in secure hardware (e.g., HSMs, TPMs) to prevent easy extraction.
• Secure Server Hardening: Ensure that servers hosting critical applications like Exchange are hardened against compromise, as administrative access to these servers can yield significant collateral.

5. Enhanced Monitoring and Logging (Post-Patch):

While actor token issuance lacked logs, organizations should still focus on robust monitoring:

• Unusual API Calls: Monitor for unusual or high-volume API calls from service principals, especially those to sensitive APIs like Azure AD Graph.
• New Global Admins/Role Assignments: Implement alerts for the creation of new global administrator accounts or other high-privilege role assignments, particularly if they appear outside of standard change management processes.
• B2B Invite Monitoring: Monitor B2B guest invite activity for anomalies, such as invites to a large number of external tenants or invites from untrusted sources, as this was a key name ID acquisition vector.

6. User Awareness and B2B Governance:

The B2B guest invite mechanism was a critical enabler for the cross-tenant aspect.

• B2B Governance: Implement strict governance policies for B2B collaboration, including approval workflows for guest invites and regular reviews of external user access.
• User Education: Educate users about the risks of accepting invites from unknown or suspicious sources, as their acceptance could inadvertently expose their home tenant's name ID.

In summary, while Microsoft has addressed this specific vulnerability, the underlying principles — the dangers of legacy systems, the complexity of hybrid security, and the need for rigorous permission management — remain paramount. Defenders must maintain a vigilant posture, continuously auditing their environments for similar weaknesses and adapting their security strategies to the evolving threat landscape in cloud and hybrid architectures.

Key Takeaways

• Legacy Mechanisms are High-Risk: The "actor token" vulnerability stemmed from a legacy authentication mechanism (Access Control Service - ACS) and older APIs (graph.windows.net) that were not designed with modern, multi-tenant cloud security in mind. These legacy components can harbor critical flaws that bypass contemporary security controls.
• Cross-Tenant Compromise was Possible: The most severe aspect was the ability to compromise any Entra ID tenant globally from a single compromised on-premises Exchange server. This was due to a validation flaw allowing an attacker to swap the target tenant ID in an unsigned outer token while using a valid, signed inner actor token from a different tenant.
• Full Global Admin Escalation: An attacker could escalate from an on-premises Exchange compromise to full global administrator privileges in a target Entra ID tenant, gaining complete control over users, roles, and security policies.
• Stealthy & Undetectable: The actor token mechanism bypassed all standard Entra ID security policies, including Multi-Factor Authentication (MFA) and Conditional Access. Crucially, the issuance and use of these tokens generated no audit logs, making detection extremely difficult for defenders.
• B2B Invites as a Discovery Vector: The name ID of target tenant users, essential for cross-tenant impersonation, could be efficiently acquired through B2B guest invites. When a user accepted an invite into an attacker-controlled tenant, their home tenant's name ID was exposed, enabling exponential compromise across connected organizations.
• Rapid Microsoft Remediation: Microsoft recognized the severe impact of this vulnerability and deployed a fix to production within three days of Mollema's report, demonstrating the critical nature of the flaw and their commitment to rapid response.

About the Speaker(s)

Dirk-Jan Mollema is an independent security researcher, consultant, and trainer specializing in Microsoft Entra ID (formerly Azure Active Directory) security. Operating under his company, Outsider Security, Dirk-Jan is dedicated to uncovering vulnerabilities and educating others on the intricacies of Entra ID security, a domain he notes "nobody apparently understands." He is the creator of Road Recon, an open-source tool widely used for enumerating Entra environments and token analysis, which also aids his own research. Mollema is a frequent speaker at major security conferences globally, including Black Hat, Def Con, and Area41, where he has previously presented. His work consistently highlights the complexities and potential pitfalls in securing modern cloud and hybrid identity infrastructures.