Entra ID Cross-Tenant Admin Takeover: Actor Tokens and Graph API Flaw

When a Dutch researcher glanced at a token stream while preparing a Black Hat talk, he didn’t just find a bug—he found a fault line in the foundations of cloud identity that could have allowed a single click to flip virtually every Microsoft Entra (Azure AD) tenant from secure to owned. The Technology.org report summarized the discovery and the breathless stakes: two legacy-era failures—an obscure internal “Actor token” issuance path and a tenant-validation gap in the legacy Azure AD Graph API—combined into a chain that could impersonate Global Administrators across tenants, bypass conditional access and MFA, and leave little to no tenant-visible logs. That original piece lays out the discovery, timeline, and remediation; its core claims map closely to independent reporting by major security outlets and the public CVE record.

Background / Overview​

Microsoft Entra ID (formerly Azure Active Directory) is the identity backbone for Microsoft 365, Azure, and thousands of third-party services. It enforces tenant isolation, conditional access, auditing, and multi-factor authentication across an ecosystem where identity is the primary gatekeeper to data, workloads, and cloud control planes. The vulnerability chain disclosed in mid‑2025 attacked that gatekeeper by exploiting two legacy constructs that persisted inside Microsoft’s sprawling cloud stack: internal Actor tokens issued via the Access Control Service (ACS) and the legacy Azure AD Graph API (graph.windows.net), which Microsoft has been retiring in favor of Microsoft Graph. Multiple independent reports describe the same two-component failure and the rapid mitigation Microsoft applied after responsible disclosure.
This article summarizes the incident, verifies technical claims across independent sources, analyzes what made the chain both possible and dangerous, and draws practical recommendations for defenders and platform builders. It concludes with a sober look at the wider lesson: legacy compatibility in global cloud platforms is an existential risk when it intersects with identity.

---

The discovery: how one researcher almost broke (or protected) the cloud​

The finder and the moment​

Dutch security researcher Dirk‑jan Mollema of Outsider Security encountered the failure while researching token behaviors and legacy flows for conference presentations. According to public reports and the Technology.org write-up, Mollema discovered that an internal token type—referred to as Actor tokens—could be requested from a benign or trial tenant and then used in concert with a tenant-validation bug in the legacy Azure AD Graph API to impersonate users in unrelated tenants, including Global Administrators. The researcher responsibly disclosed the findings to Microsoft on July 14, 2025; Microsoft investigated immediately and deployed global mitigations within days.

What was reported and when​

Key timeline points reported across independent outlets:

• Discovery and responsible disclosure to Microsoft on July 14, 2025.
• Microsoft deployed a global fix by July 17, 2025 and confirmed remediation activity over the following week; further mitigations were applied in August.
• The issue received the CVE identifier CVE‑2025‑55241 and appeared in public vulnerability tracking feeds on September 4, 2025.

Microsoft’s public messaging confirmed mitigation and framed the event as another driver in its ongoing program to remove legacy, insecure token flows from the cloud stack. Tom Gallagher of Microsoft’s Security Response Center described the fix as a code-level validation change plus accelerated decommissioning of legacy protocol usage.

---

Technical anatomy: Actor tokens + legacy Graph API = cross‑tenant impersonation​

What are Actor tokens?​

• Actor tokens are an internal token construct used by backend Microsoft services for service‑to‑service and delegated operations. They are not typical user interactive tokens.
• These tokens carried a “trusted for delegation” property and were historically exempt from some tenant-level controls like Conditional Access and MFA enforcement and did not produce tenant-visible issuance logs in the same way as interactive tokens. Multiple post‑mortem analyses and vendor advisories describe Actor tokens as undocumented, short‑lived JWT‑style tokens used by internal Microsoft services (for example, between Exchange Online and other M365 services).

Where Azure AD Graph fits in​

• The Azure AD Graph API (graph.windows.net) is the older directory API that predates Microsoft Graph. Microsoft has been migrating customers to Microsoft Graph and deprecating the old Graph API, but some surface area remained in production.
• The critical failing was that, for certain operations, the Azure AD Graph API did not correctly validate the tenant origin of incoming Actor tokens. Attackers could therefore present an Actor token obtained in one tenant along with victim tenant identifiers and have Azure AD Graph accept the request as if it originated from the victim tenant.

The exploit chain (high level)​

• An attacker requests an Actor token in an attacker‑controlled or trial tenant (no elevated privileges required).
• The attacker crafts an impersonation token that pairs that Actor token with a target tenant’s identifier (tenantId and netId, which can be enumerated or obtained through guest relationships).
• The legacy Azure AD Graph API fails to validate the origin tenant of the Actor token for the specific call pattern and accepts the token as representing the target tenant’s user—up to and including Global Admins.
• The attacker uses directory APIs to read sensitive directory objects, create admin users, inject application credentials, or modify tenant configuration. Many read operations leave no tenant-visible issuance log; only some write operations produce audit events that may be attributed to internal Microsoft service actions.

Multiple independent writeups replicate this chain and emphasize identical root causes: legacy trust boundaries, undocumented internal tokens, and insufficient API-level tenant validation.

---

Why the chain was particularly dangerous​

• Full tenant compromise — Impersonating a Global Administrator enables creation of persistent admins, registration of service principals, and modification of tenant‑wide security settings; it is a canonical path to full control of Microsoft 365 services and Azure subscriptions.
• Bypassing core controls — Because Actor tokens weren’t governed by tenant Conditional Access or MFA in the same way as user tokens, the exploit bypassed protections defenders typically rely on.
• Stealth and forensic blind spots — Issuance of Actor tokens didn’t generate tenant-visible logs in victim tenants, and Azure AD Graph lacked detailed API telemetry for some operations; this makes detection and forensic reconstruction far harder.
• Scale — The vulnerability was not scoped to a small set of customers; the architecture meant the chain could theoretically work across any publicly accessible Entra tenant, creating catastrophic systemic risk.

Security experts compared the potential impact to other supply‑chain/identity-scale incidents (for example, Storm‑0558-style key compromises), because a core identity provider failure can cascade into government or enterprise email, document stores, and cloud compute. The comparison is apt in scale and risk profile, though each incident has unique mechanics.
Caveat: Microsoft reported no evidence of real‑world exploitation prior to mitigation, and public trackers indicate the vulnerability was patched before broad public disclosure. Still, the stealthy nature of the chain means “no evidence” should be treated as informative but not definitive.

---

Microsoft’s response: rapid mitigation and legacy decommissioning​

Microsoft’s published timeline and statements, corroborated by independent reporting, show a fast remediation cadence:

• Responsible disclosure on July 14, 2025.
• Global fix deployed on or about July 17, with confirmations and additional mitigations through late July and August.
• Vulnerability publicly assigned CVE‑2025‑55241 and documented in September.

Mitigations reported by Microsoft included:

• Blocking Actor tokens from being used for the Azure AD Graph API call patterns that accepted cross‑tenant impersonation tokens.
• Changing validation logic to require correct tenant provenance and tightening issuance controls for Actor tokens.
• Accelerating the decommissioning of legacy protocols and APIs—part of a broader “secure‑future” push to remove risky compatibility remnants.

Independent analysts and security vendors confirmed Microsoft’s mitigation steps and encouraged organizations to verify their environments, especially hybrid Exchange customers who historically relied on older token flows. Several national CERTs and agencies treated the risk as severe and issued emergency guidance for hybrid deployments, underscoring the real operational urgency this class of vulnerability creates.

---

Lessons for defenders and recommendations​

This near‑miss offers a compact set of operational and architectural lessons for organizations that rely on cloud identity providers.

Immediate defensive actions (short checklist)​

• Verify that your tenant is no longer exposed to legacy Azure AD Graph endpoints and migrate applications to Microsoft Graph if you have not already done so. Microsoft has published retirement timelines—treat the end‑of‑life schedule as a security imperative, not just a developer convenience.
• Audit and rotate any shared service principals, hybrid app credentials, and Exchange hybrid connectors. Reduce privilege of long‑lived service accounts and enforce just‑in‑time principles where possible.
• Enable and centralize audit logging to platforms that retain evidence outside the tenant when possible; use cross‑tenant telemetry correlation tools and proactive hunting queries that look for unusual application‑to‑directory calls.
• Harden discovery and guest‑sharing settings: minimize the use of guest accounts where possible and monitor cross‑tenant guest activity that can provide material for token impersonation.

Strategic changes (1–6 months)​

• Remove reliance on deprecated APIs and token formats: inventory all apps and connectors and migrate to supported endpoints.
• Apply least privilege to service principals with narrow consent scopes and short credential lifetimes. Rotate keys frequently and monitor for unusual usage.
• Invest in telemetry that captures API-level calls and enriches identity signals with network and endpoint context to reduce blind spots.

What platform owners should do​

• Cloud providers must accelerate the deprecation and wholesale removal of legacy flows that bypass modern policy enforcement. Compatibility is a feature, but retained "back doors" that skip policy checks are a systemic liability.
• Provide clearer, tenant‑visible telemetry for internal service impersonation tokens or eliminate silent issuance entirely. If tokens are necessary for internal services, make their issuance and use auditable for tenant operators.

---

Structural risks: why legacy compatibility becomes a single‑point failure​

Two structural pressures produced this near catastrophe:

• The need for backward compatibility across millions of customers and years of engineering creates inertial drag; legacy APIs and token flows persist long after safer replacements exist.
• Identity flows are by design highly trusted. Small mistakes in token validation or tenant attribution can escalate to catastrophic control‑plane access far more easily than similar bugs in lower‑impact services.

This is the reason the cloud industry’s migration and deprecation schedules are not just product timelines; they are security hygiene on a planetary scale. When a legacy flow can bypass conditional access, telemetry, and tenant boundaries, it becomes a logical single‑point-of-failure for any customer that relies on the provider for identity.

---

What wasn’t verifiable (and why that matters)​

Public reporting and vendor statements converge on the core mechanics and timeline, but some operational details remain difficult to verify from outside Microsoft’s internal telemetry:

• Precise internal naming, exact token lifetimes, and which specific Microsoft services still used Actor tokens at the time of discovery vary between writeups. Those differences are minor for exploit mechanics but important if you are building detailed detection rules. Treat those internal specifics as implementation details subject to revision.
• Microsoft reported no evidence of exploitation in the wild. Given the incident’s stealth characteristics, defenders should treat that as reassuring but not conclusive—absence of evidence is not proof of absence.

---

Broader implications for cloud trust models​

This event is not primarily about one company making a mistake; it’s about the brittle trust model that arises when identity, telemetry, and legacy compatibility intersect at global scale. Three systemic takeaways:

• Identity is now the system of truth for an organization’s cloud presence. Weaknesses in identity systems produce systemic risk far beyond single‑application vulnerabilities.
• Providers must avoid silent, privileged token flows that are invisible to tenant administrators. If the provider needs internal impersonation for orchestration, that activity must be auditable by tenants and protected by policy gates.
• Organizations must treat cloud deprecations as security deadlines. Migration timelines should be resourced and enforced like patch cycles—because they are.

---

Conclusion​

The Entra ID incident discovered by Dirk‑jan Mollema was a classic near‑miss: the exploit chain existed, would have been devastating in attack, and was patched before public exploitation was detected. The event’s true value is in the alarm it sounds. It demonstrates how decades of compatibility engineering, small internal shortcuts, and incomplete telemetry can conspire to create a single mouse click that would grant an adversary god‑mode across millions of cloud tenants.
For defenders, the prescription is clear: treat legacy APIs as untrusted, rotate and shrink service‑principal privileges, centralize and enrich telemetry, and migrate to modern, auditable token flows as a security priority. For platform operators, the obligation is weightier: remove silent, privileged internal paths and make identity issuance auditable by design.
Cloud identity will attract future research, and inevitably more discoveries. This incident should be treated less as an isolated scare story and more as a hard lesson in how engineering choices at the platform level become operational risk for every customer that relies on that platform. The fix was applied, mitigations were rolled out, and the immediate threat faded—but the structural vulnerabilities that enabled the chain remain a shared responsibility between cloud providers and their customers. Safeguarding the digital economy requires treating those responsibilities with matching urgency.

---

Source: Technology Org Azure Bug Could Have Hijacked Every Cloud Account Worldwide - Technology Org