In cybersecurity, patterns matter.
Four incidents: Entra ID tenant hijack flaw (CVE-2025-55241), the Commvault Metallic OAuth credential leak (CVE-2025-3928), the Consent & Compromise Microsoft OAuth abuse, and the Midnight Blizzard attack, share one uncomfortable truth: applications, not users, are fast becoming a popular way into the world’s most secure environments.
In the spirit of learning from our collective past mistakes and doing better, let’s take a deeper dive into these examples. In this case, these breaches show us exactly where some pain points are, and how to act before the next one hits.
In 2025, researcher Dirk-jan Mollema disclosed CVE-2025-55241, a critical Entra ID issue that combined Microsoft’s legacy Azure AD Graph API with internal ‘actor’ claims used by Microsoft services. By crafting an impersonation token containing an unsigned actor claim, and taking advantage of the already retired Azure AD Graph’s failure to validate the originating tenant, the researcher was able to impersonate users in other tenants, including Global Admins, if their user IDs were known or discoverable.
In practice, an attacker would need the target tenant ID and a valid user object ID or UPN within that tenant. While this information is not directly public, in some cases it can be inferred through naming patterns, exposed metadata, or enumeration techniques. Reads left little to no telemetry, and while writes would generate audit logs, they could appear as actions by a real Global Admin. Microsoft fixed the flaw within days and issued CVE-2025-55241.
Why it matters:
It’s a vivid reminder that identity breaches don’t always start with phishing or password reuse. Identity incidents often originate in legacy components and ‘temporary’ design choices that outlive governance. Microsoft has mitigated this path, but the takeaway is clear - any lingering legacy APIs or token flows deserve priority review, as they can undermine Conditional Access and monitoring.
Dirk-jan Mollema recently joined Merill Fernando's Entra.Chat podcast to discuss his findings: I found a bug that could hack ANY Microsoft 365 tenant - Here's what happened.
In February 2025, Commvault’s Metallic SaaS backup platform, built to protect Microsoft 365 data, became a conduit for attackers. A zero-day vulnerability (CVE-2025-3928) in the Metallic web server enabled a nation-state actor to deploy web shells and extract stored OAuth client secrets for affected customer environments.
Those credentials weren’t low-value. They granted programmatic access to Exchange Online, SharePoint, OneDrive, and Teams. Many were over-permissioned (Mail.ReadWrite, Files.Read.All, Sites.Read.All) and long-lived, with no expiry or rotation. Once stolen, they gave attackers silent, durable access that blended in with normal application activity, the perfect “living-off-the-land” scenario.
Why it matters:
The breach turned a trusted vendor into an unintentional insider threat. It highlights how cross-tenant app permissions and stored secrets can make one supplier’s weakness everyone’s problem. The lesson: backup tools and automation apps often hold the keys to the kingdom. They need the same continuous scrutiny as any privileged identity.
Not every breach begins with malware. Sometimes it starts with curiosity.
A security researcher investigating Microsoft’s aka.ms short-link domains stumbled onto a misconfigured multi-tenant Entra OAuth application used internally. By consenting to the app, a Service Principal was created in his tenant. Because the internal application did not validate the token’s issuer or tenant ID, he was able to use the resulting tokens to access internal Engineering Hub resources as if he were an internal user.
From there, he was able to access 22 internal Microsoft applications, including risk registers, internal APIs, build systems, and even private keys, by leveraging the misconfigured trust. The root cause: developers had configured internal apps as multi-tenant without verifying the issuer (iss) or tenant ID (tid) claims in the access token. Entra ID did what it was designed to do: it issued tokens. The app simply trusted the wrong authority.
Why it matters:
It’s a case study in shared responsibility gone wrong. Developers assumed security handled app registration; security assumed developers validated tokens. The result: the door was open to the world. This misstep shows that even sophisticated environments can overlook one missing line of code, and that consent, not compromise, is now an easy way in.
In January 2024, Microsoft disclosed that the Russian threat group Midnight Blizzard (a.k.a. APT29) had gained access to emails belonging to its senior leadership team. The breach started with a password spray attack against a legacy, non-production test tenant. Once inside, the attackers located a connected OAuth application with elevated permissions to Microsoft’s corporate environment.
They leveraged the compromised app to create additional malicious OAuth applications, provision a user account, and escalate privileges to obtain Exchange Online full_access_as_app permissions, which ultimately allowed them to access senior leadership mailboxes.
Following the Storm-0558 incident, Microsoft took the significant step of purging over half a million Entra tenants and all their associated applications. This proactive cleanup aimed to eliminate the new and expanding attack surface revealed by the campaign. Rather than risk ongoing exploitation, Microsoft chose to remove these tenants to secure their environment and protect customers from further threats.
Why it matters:
This wasn’t a zero-day exploit; it was death by misconfiguration. A dormant test environment had production-level access, no MFA, and no monitoring. It demonstrates how OAuth applications can bridge environments and how quickly attackers can escalate privileges once they gain a single foothold.
Across all four incidents, the pattern is unmistakable:
In short, attackers don’t always need to steal passwords when they can inherit permissions through applications. In many cases, these techniques are combined to maximize persistence and reach.
Progress happens when you turn insight into action, when you stop waiting for someone else to fix the problem. For security and IT leaders, that means acting on what these incidents make painfully clear: application governance is identity governance.
Here are tangible, next-step practices that any organization, large or small, can adopt today:
The last two years have made one thing painfully clear: Entra ID application governance is a new front line of identity security.
From legacy APIs to trusted backup tools and internal test tenants, the path to compromise is often paved with good intentions and bad defaults.
“The cost of inaction compounds.” The same is true for unmonitored applications. Every unreviewed permission, every forgotten app, and every unchecked consent adds up to an attack surface waiting to be discovered.
The good news? You don’t have to wait for a breach to fix it. You can start by shining a light on your applications, because visibility isn’t just power. In today’s identity-driven world, it’s protection.
Application security and identity security are inseparable. Organizations that build structured application governance programs now will be far better positioned to detect and contain identity-layer attacks. Start by assessing your Entra ID landscape, tightening app permissions, and holding every application accountable, before attackers do it for you.