Securing Microsoft Entra ID Applications: Addressing the Threat of Misconfigured Permissions

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.

Understanding Entra ID Application Permissions

Before diving into the risks, it’s crucial to understand how permissions work in Microsoft Entra ID.

Delegated vs. Application Permissions

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

Why Permissions Matter

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.

How Misconfigurations Become Security Risks

Let’s look at the most common misconfigurations and why they’re so dangerous.

Non-Admin Owners

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.

Excessive Permissions

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

Unconstrained Consent

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.

Real-World Example: The Midnight Blizzard Attack

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:

• A legacy test account with weak protection
• An app with excessive permissions
• Lack of oversight on app ownership and credential management

The result was a stealthy, persistent foothold in one of the most secure environments in the world.

Attack Paths: How Adversaries Exploit Misconfigurations

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:

Persistence via App Registration

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

Privilege Escalation

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.

Bypassing MFA and Monitoring

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

Detection and Monitoring

You can’t protect what you can’t see. Regular auditing and monitoring are critical for detecting misconfigurations and suspicious activity.

Audit and Review

• Review app permissions and ownership regularly using the Entra admin center or PowerShell.
• Export audit logs to your SIEM for continuous monitoring. Key events to watch for include:
  • Addition of secrets or certificates to apps
  • Changes in app ownership
  • Granting of high-risk permissions (e.g., ReadWrite, Directory.ReadWrite.All)
• Monitor for new app registrations, especially those with broad permissions or suspicious owners.

Figure 6. Audit Logs

Automated Tools

Several tools can help automate the detection of risky configurations:

• Entra Security Scanner: Scans your tenant for apps with risky permissions, missing owners, expired credentials, and more.
• PowerShell Cmdlets: Use Get-AzureADApplication, Get-MgServicePrincipal, and related cmdlets to script regular reviews.

Mitigation and Best Practices

Now that we know the risks, let’s look at how to mitigate them.

Enforce Stringent App Ownership

• Assign app ownership only to trusted, trained admin accounts. Avoid making standard users or service accounts app owners.
• Regularly review and prune app owners, especially for apps with high privileges.
• Use role-based access control (RBAC) to ensure only appropriate users can register or manage applications.

Apply Least Privilege

• Grant only the permissions an app absolutely needs. Avoid tenant-wide permissions unless there is a clear, documented business need.
• Use Application Access Policies to restrict app access to specific mailboxes or groups. For example, use the New-ApplicationAccessPolicy PowerShell cmdlet to limit which mailboxes an app can access.
• Review all app permissions at least quarterly and remove any that are no longer needed.

Restrict Consent and Review Regularly

• Implement admin consent workflows for risky permissions. Do not allow users to consent to high-risk permissions without admin approval.
• Use built-in Entra policies to restrict user consent to low-risk permissions only.
• Regularly review consented permissions and revoke any that are unnecessary or suspicious.

Monitor and Respond

• Leverage audit logs and SIEM integration for real-time detection of suspicious app activity.
• Set up alerts for key activities, such as new app registrations, changes to app credentials, or assignment of high-risk permissions.
• Review and revoke unnecessary permissions using PowerShell or the Entra admin center.

Credential Hygiene

• Rotate secrets and certificates regularly. Avoid long-lived credentials.
• Monitor for expired or soon-to-expire credentials and remediate promptly.
• Store secrets securely, such as in Azure Key Vault, and avoid sharing them via email or unsecured channels.

Utilize Security Tools

• Regularly run security scanners to identify and remediate risky app configurations.
• Automate reporting so that security teams are alerted to new risks as they arise.

Actionable Steps for IT and Security Teams

Here’s a checklist you can start using today:

1. Inventory all applications: Identify owners, permissions, and credential status.
2. Audit permissions: Remove excessive or unnecessary permissions, especially for high-risk APIs.
3. Enforce ownership policies: Ensure only appropriate admin accounts are app owners.
4. Implement access policies: Use mailbox access policies and admin consent workflows.
5. Monitor continuously: Integrate audit logs with SIEM and review for suspicious activity.
6. Educate and train: Ensure admins understand the risks and responsibilities of app management.

Conclusion

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.

Further Reading & Resources:

• Microsoft: Secure application model in Azure AD
• Entra ID Security Bench
• Midnight Blizzard Attack Analysis