In today’s cloud-first world, Microsoft Entra ID (formerly Azure Active Directory) is the backbone of identity and access management for organizations leveraging Microsoft 365 and Azure. While Entra ID offers robust controls and a flexible application model, it also introduces new risks, particularly when it comes to how applications are registered, managed, and granted permissions.
Nic and I have been preaching to whomever will listen for the last 3 years on why identity and application security is important. We’ve repeatedly highlighted that application security is a somewhat grey area, almost no man’s land of sorts because application security traditionally sits with developers and identity security, with the identity support people. But since the advent of Azure Active Directory, now known as Entra ID, the “home” of applications now live, rent free, in the identity space.
And it’s because of this, that we have been laboring on and on, and on, about what people should be looking for, when managing applications in Entra.
In Season 3, Episode 5, we focused our attention on misconfigured permissions for applications and what to look out for when working with application security in Entra. When apps are over-permissioned or managed by inappropriate owners, attackers can exploit these weaknesses to escalate privileges, persist in the environment, and exfiltrate sensitive data. Recent high-profile breaches, such as the Midnight Blizzard attack, have shown just how devastating these vulnerabilities can be.
Before we unpack what it all means, we need to take a look and a few principles so that what we recommend looking at, makes sense.
Before diving into the risks, it’s crucial to understand how permissions work in Microsoft Entra ID.
Delegated permissions allow an app to act on behalf of a signed-in user. The app’s access is limited to what the user can do. For example, an app with Mail.Read delegated permission can only read mail from the mailbox of the signed-in user.
Figure 1. Delegated Permissions
Application permissions, on the other hand, allow the app to act as itself-without a user context. These permissions are typically granted by an administrator and can apply tenant wide. For example, an app with Mail.ReadWrite application permission can read and write mail in any mailbox in the tenant, regardless of user consent.
Figure 2. Application Permissions
The flexibility of Entra ID’s permissions model is a double-edged sword. While it enables powerful integrations, it also means that a misconfigured app can become a high-value target. An app with excessive permissions, especially application permissions, can provide attackers with broad access to your organization’s data and resources.
Let’s look at the most common misconfigurations and why they’re so dangerous.
Every app registration in Entra ID has one or more “owners.” Owners can manage the app, add secrets or certificates, and change permissions. Assigning standard users or service accounts as app owners is a critical mistake. If such an account is compromised, an attacker can take full control of the app-adding new credentials, escalating its permissions, or even transferring ownership to themselves.
It’s tempting to grant broad permissions “just in case” during app development or troubleshooting. And trust me, even I have done this, just so that we can get the app functional for testing, because customers always want things done yesterday. However, permissions like Mail.ReadWrite, Mail.Send, or Directory.ReadWrite.All can give an app sweeping access to sensitive data and administrative functions. If an attacker gains access to such an app, they can read or send emails from any mailbox, modify directory objects, or even create new privileged accounts.
Figure 3. Excessive Permissions
By default, users may be able to consent to certain app permissions on their own. If this isn’t restricted, a user could inadvertently grant a malicious app high risk permissions. Without regular reviews, these permissions can go unnoticed and unrevoked for months or years.
The risks of misconfigured permissions aren’t theoretical. The Midnight Blizzard attack (also known as the Nobelium or SolarWinds attack) provides a chilling example. And even more than a year after the world being told, we are still using it as a textbook example of how “wrong” things can go.
In this incident, attackers compromised a legacy OAuth application in Microsoft’s own tenant. The app had excessive permissions and was owned by a weakly protected account. The attackers created new secrets for the app, authenticated as the app, and used its privileged Microsoft Graph permissions (Directory.ReadWrite.All, RoleManagement.ReadWrite.Directory) to create new admin users and escalate their privileges.
This attack was possible because of three key misconfigurations:
The result was a stealthy, persistent foothold in one of the most secure environments in the world.
Understanding the attacker’s playbook is essential for building effective defenses. We need to start thinking like threat actors, if we going to understand what they do and how they do it. Here are some examples of the mind of a hacker:
Once an attacker compromises a user with app owner rights, they can enumerate all applications the user owns. By adding a new secret or certificate to an app, the attacker can authenticate as the app-bypassing user-based controls like MFA or Conditional Access. This provides a “backdoor” that can persist even if the original user’s account is remediated.
Figure 4. Application Owner
This is such a big thing that we dedicated an entire episode to it. Attackers often use tools like AzureHound or BloodHound to map relationships between users, applications, and permissions in Entra ID. By chaining together app ownership and excessive permissions, they can move laterally and escalate privileges-sometimes all the way to Global Administrator.
Unlike user accounts, service principals (apps) are not subject to Conditional Access or MFA. Many organizations also lack detailed monitoring of app creation, permission changes, or credential management. This makes apps a stealthy way for attackers to maintain access and escalate privileges without triggering alerts.
Figure 5. Service Principal Permissions
You can’t protect what you can’t see. Regular auditing and monitoring are critical for detecting misconfigurations and suspicious activity.
Figure 6. Audit Logs
Several tools can help automate the detection of risky configurations:
Now that we know the risks, let’s look at how to mitigate them.
Here’s a checklist you can start using today:
Misconfigured app permissions in Microsoft Entra ID are one of the most significant-and preventable-security risks facing cloud-first organizations today. As the Midnight Blizzard attack demonstrated, attackers are actively seeking out these weaknesses and exploiting them for privilege escalation, persistence, and data theft.
By understanding the risks, auditing your environment, enforcing least privilege, and leveraging the right tools, you can dramatically reduce your exposure and secure your Entra ID applications against modern threats.
Don’t wait for an incident to highlight your gaps. Start reviewing your Entra ID app permissions today-and make robust permission management a cornerstone of your cloud security strategy.