TLDR:
- Critical flaw in Microsoft Entra ID: Attackers could exploit “Actor tokens” to impersonate any user — even Global Administrators — across tenants.
- Invisible exploitation: MFA, Conditional Access, and logging provided no defense or detection. Identities become invisible after authentication.
- Current status: Patched.
- Red Teamer View: What other terrifying flaws exist that aren’t documented? I share my thoughts…
- Broader Implications: This isn’t just a Microsoft problem, nor is it “just another CVE.” It’s a warning shot for every organization that depends on identity in the cloud.
- Defensive takeaway: Behavioral anomaly detection is critical for the new wave of threat actor techniques across Identity, SaaS and Cloud.
When we think about catastrophic cloud vulnerabilities, we often picture advanced exploits requiring persistence and luck. But sometimes, it takes just one design flaw to collapse the trust we place in our identity providers.
One Pwnage to Rule Them All
Recently, a security researcher named Dirk-Jan Mollema wrote a blog post revealing arguably the worst vulnerability in a Microsoft product ever. In his blog post, Dirk-Jan outlined an abuse of the EntraID function within Azure: “The vulnerability consisted of two components: undocumented impersonation tokens, called “Actor tokens”, that Microsoft uses in their backend for service-to-service (S2S) communication. Additionally, there was a critical flaw in the (legacy) Azure AD Graph API that failed to properly validate the originating tenant, allowing these tokens to be used for cross-tenant access.” This discovery is pretty astounding, considering that most modern cloud service providers are secure, right?
The write up goes on to explain specifically: “Effectively this means that with a token I requested in my lab tenant I could authenticate as any user, including Global Admins, in any other tenant. Because of the nature of these Actor tokens, they are not subject to security policies like Conditional Access, which means there was no setting that could have mitigated this for specific hardened tenants” YIKES! This is pretty much the sum of all fears with regards to a vulnerability – an attacker could remotely gain access to any tenant, assume the role of any user, and run amok.
Offensive Leverage Perspective
Thinking about it from an attacker, this is a golden goose – all I have to do is spin up my own environment, generate the token, and then pivot into your tenant. From there, it’s open season as I would have the ability to pretty much do anything (as a global administrator). This attack was only really mitigated in the fed-cloud (according to Dirk-Jan) due to using their own signing keys but with supply chain and trust boundary attacks there are scenarios where attackers could still gain access in my opinion.
A Troubling History of Events
A few things come to mind with this write up. Outside of the shock factor, and complete agreement that this is probably worse than MS08-67, MS17-10, etc., there seems to be some insight that is being missed. Microsoft has a history of having undocumented WinAPIs in its Windows products, which in some cases have aided in the development of tooling or malware. With that history in mind, it doesn’t strike me as particularly “out of the blue” that Microsoft would have Azure tokens (or other features really) that are undocumented, and by extension, particularly beneficial to attackers.
Another point of concern around this is that in certain circumstances an attacker with the above forged token could, in theory, gain access to the on-prem AD physical system. This is dependent on certain factors (such as password writeback) but could be an attack path leveraged by an adversary. So that’s pretty terrifying right? Someone without any access has the ability to create a token in their tenant, gain access to yours, assume an administrative role, and then potentially gain access to your on-prem AD. YIKES!
Similar Fish in the Pond
This has some similar vibes to a recent CVE released around BlackHat 2025 (CVE-2025-53786), where an attacker could compromise an Exchange instance and then create a (temporarily) irrevocable access token in Azure cloud services, leading to the ability to do all sorts of nasty stuff like “allowing them to modify user passwords”, “convert cloud users to hybrid users”, and of course “impersonate hybrid users to gain full control over the cloud environment”. This is pretty gnarly too!
Ghostbusting
From a Red Teamer perspective, both of these vulnerabilities, and their capabilities, would have some pretty rough read-outs if leveraged. How can you patch something that you can’t control? My recommendation in this scenario would simply be to create much stronger detections on known vulnerable/critical paths. Detections, especially around VIPs on the tenant, would need to be robust (and TESTED). If you can’t harden it, you want to keep your eyes on it!
The good news for the spooky cyber stories (Hello Spooktober!): we have just been told that the vulnerability that Dirk-Jan discovered has been patched by Microsoft so nothing needs to be done in your organization to course-correct this issue. Of concern though is that this existed for some time without discovery. This is the part where I point the flashlight at myself, around the campfire, and say “… but who knows what other terrifying flaws exist that aren’t documented?” As we have outlined, Microsoft does have a history of a number of interesting undocumented flaws…
With regards to CVE-2025-53786, there is a patch in place but there are extra steps advised to remediate the flaw entirely in your environment. This one isn’t an easy fix and will more than likely be a pain point for most organizations in some capacity. The amount of effort needed in some orgs to just merely patch devices to an adequate level of security makes me believe we will see the Exchange vulnerability pop up in reports, or even worse, a breach.
Closing Thoughts
One last bit of perspective which I believe is relevant to the conversation. All of these vulnerabilities still need to assume identities within the organization. Similarly to a “www-data” user on an apache instance, there still needs to be something that the system runs in context-wise to allow them to have security boundaries (as well as execute their functionality). As the industry explores identity protections with the blossoming of AI capabilities, it is important to also remember that said identity / IAM protection advancements can still be very beneficial in a hybrid-environment.
Riddle me this: if someone assumed an administrative role and started doing suspicious things in your cloud environment, could you detect it? If Exchange delegated a new user and made them an admin in Azure, could you detect it? These are the types of robust detections that we should be thinking about as we move forward with our blended environments in my opinion, regardless of if AI is in the loop.
One last closing thought: TTPs are changing and shifting for modern attackers. Why bother with EDR if you don’t need to be on the end point? Why bother with advanced malware if users will run RustDesk connections that are trusted? The attackers know that the valuable data/crown jewels are typically resting in SaaS (or cloud) applications. This sort of vulnerability would have been a god send to APTs or Ransomware operators. Given that Microsoft has a history (as we have seen) of having these undocumented “features” popping up, I would imagine that the “future proof” savvy Blue team (or CISO) would look to detections that can track critical identities as well.
