Security Incidents That Exposed a Weak Link in Entra ID: Applications

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.

1. The Entra ID Flaw That Could Have Compromised Any Tenant Globally

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.

2. Commvault Metallic: When Backups Became Backdoors

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.

3. Consent & Compromise: When a Click Opens the Wrong Door

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.

4. Midnight Blizzard: The Test Tenant That Breached Microsoft’s Execs

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.

The Common Thread: OAuth and App Governance Are the New Perimeter

Across all four incidents, the pattern is unmistakable:

Legacy or over-permissioned apps became entry points.

OAuth and Service Principals enabled invisible persistence.

Consent flows and multi-tenant configurations blurred security boundaries.

Lack of continuous auditing allowed small cracks to become full breaches.

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.

Actionable Steps to Shrink Your Application Attack Surface

Here are tangible, next-step practices that any organization, large or small, can adopt today:

Inventory Every Application
Know what’s registered in your tenant. Document purpose, owner, and permissions. Unowned apps tend to be unmonitored apps, and that’s where attackers hide.
Audit App Permissions Regularly
Review all app roles such as Mail.ReadWrite, Files.Read.All, or Directory.ReadWrite.All. If an application no longer needs them, revoke consent immediately.
Monitor for Dormant or Stale Apps in Entra ID
Applications with no recent sign-ins or API calls are more likely risks, not assets. Tools like ENow’s App Governance Accelerator or even custom KQL queries in Sentinel can surface these quickly.
Control Who Can Grant Consent
Restrict consent-granting roles (Global Admin, Privileged Role Admin, Application Admin, Cloud App Admin) and enable admin consent workflow approvals.
Review Multi-Tenant App Configurations
Only make apps multi-tenant when necessary. Ensure application code validates the iss and tid claims on every token.
Apply Conditional Access to Service Principals
Extend CA policies to include workload identities where supported, limiting where and when apps can authenticate.
Rotate Secrets and Certificates
Implement automated secret rotation and enforce expiry dates for client secrets and certificates.
Separate Test and Production Tenants
Never allow test tenants to create or manage applications in production environments.
Enhance Monitoring Beyond Users
Most SIEM rules focus on user activity. Add dedicated alerts for app sign-ins, new consent grants, and role assignments.
Foster a Culture of App Accountability
Every app should have an owner who understands its purpose, risk, and lifecycle, just like every system account.

The Bottom Line

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.

Take Action to Secure Your Entra ID applications

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.

AppGov Score Blog