Preventing Privilege Escalation in your Modern Identity Environment

What has the world come to when "service" accounts can be compromised? It's no longer just someone's identity that gets exploited; the "unattended" accounts now pose security risks. These not-so-pesky accounts live rent-free in our tenants and perform bidding on our behalf.

Except, like with AI, we don't really have a generative conversation with them. We sometimes create them or use application deployments/scripts to provision services in our environment.

For the longest time, Nic and I have been asking, shouting, and pleading with customers and vendors to highlight what their applications "do" inside Microsoft environments because it's just so easy to spin these things up inside environments.

Before diving into the main content, it's worth noting that recent security research has uncovered critical privilege escalation vulnerabilities in Entra ID that could allow attackers to gain Global Administrator access through various attack vectors. This post will equip security professionals with the knowledge to identify these threats and implement effective countermeasures.

Understanding Microsoft Entra ID Authentication Infrastructure

The Foundation of Microsoft Identity Security

Figure 1. Entra ID traditional architecture

Microsoft Entra ID (formerly Azure AD) serves as the cornerstone of identity and access management across Microsoft 365 and Azure environments. It manages identities through several key components that work together:

Application Objects: These are the global, unique instances of an app that live within their home tenant. When you register an application, both an application object and a service principal are created in your home tenant^[1].
Service Principals: These are the local representations of a global application object in a single tenant. Service principals define what an app can do in a specific tenant, who can access it, and what resources it can access^[1]^[2].
OAuth 2.0 Authorization: This protocol enables a user to grant limited access to protected resources. It separates the client's role from the resource owner's, allowing secure access without exposing credentials^[3].
Managed Identities: These provide automatically managed identities for Azure services to authenticate without handling credentials directly, enhancing security by eliminating hardcoded credentials^[4].

Understanding these components is critical because attackers target vulnerabilities in these elements to gain elevated privileges within an environment^[5]^[6].

Authentication Flows and Permission Models

The security of any Entra ID environment depends heavily on how authentication flows are implemented and how permissions are assigned:

OAuth 2.0 Flows: Used for authorization, these flows define how applications request and receive tokens to access resources. Misconfigurations in these flows can lead to security breaches^[3].
Permission Models: Entra ID uses role-based access control (RBAC) and application permissions to secure resources. Overly permissive roles or inappropriate permission assignments create security risks^[7]^[2].
Service Principal Authentication: Service principals authenticate using client certificates or client secrets. While certificates are more secure, improper management of either can lead to significant security issues^[2].

Figure 2. Traditional representation of how identities interact with applications

Recent Vulnerability Discoveries in Microsoft Entra ID

The "UnOAuthorized" Privilege Elevation Vulnerability

In 2024, the Semperis security research team discovered a critical vulnerability that allowed privilege escalation to Global Administrator status through manipulation of OAuth 2.0 scopes:

Note: Microsoft has since then fixed certain components on the backend

The vulnerability enabled attackers to add and remove users from privileged roles, including the all-powerful Global Administrator role^[5]^[6].
The attack required that the initiator hold the Application Administrator or Cloud Application Administrator role in Entra ID. Unfortunately, many organizations don't treat these roles as highly privileged, making them attractive targets^[6].
Researchers found that select Microsoft application service principals could perform actions beyond their expected authorization controls, essentially bypassing designed security boundaries^[5].

This discovery highlights how seemingly well-protected environments can contain unexpected privilege escalation paths that attackers might exploit^[6]. (Check the webinar for examples of how this was achieved)

Abusing Intune Permissions for Lateral Movement

Mandiant's Red Team revealed another novel attack vector involving Microsoft Intune permissions:

Attackers could abuse the ReadWrite.All permission granted to Entra ID service principals to move laterally and elevate privileges within Entra ID^[8].
This attack was particularly concerning in environments using Intune-managed Privileged Access Workstations (PAWs), which are typically considered part of a highly secure architecture^[8].
The attack enabled privilege escalation even in environments that followed Microsoft's recommended Enterprise Access model and Tiered security architecture^[8].
This demonstrates how even sophisticated security architectures can be vulnerable if service principal permissions aren't strictly controlled and monitored^[8].

Figure 3. Privileged Access Workstations

Authorization Misconfigurations in Multi-Tenant Applications

Microsoft identified and addressed an authorization misconfiguration affecting multi-tenant applications:

Some applications were incorrectly configured as multi-tenant, while others didn't properly implement authorization checks^[9].
This allowed external parties to potentially gain read and write access to impacted applications^[9].
The issue stemmed from applications not verifying that a client was explicitly registered in a tenant before granting access^[9].

This vulnerability underscores the importance of proper authorization checks in multi-tenant application scenarios, especially as organizations increasingly adopt cross-tenant collaboration tools^[9].

Figure 4. Multi-tenant application scenarios.

Technical Anatomy of Privilege Escalation Attacks

Exploiting OAuth 2.0 Scopes and Permissions

Privilege escalation often begins with the exploitation of OAuth 2.0 scopes and permissions:

Attackers identify applications with excessive permissions that can be leveraged for lateral movement^[6].
By targeting applications with high-privilege scopes, attackers can perform actions beyond expected authorization controls^[5]^[6].
The "UnOAuthorized" vulnerability demonstrated how attackers could manipulate OAuth 2.0 scopes to perform privileged actions without appearing to have permission to do so^[5].

The technical challenge for identity and access administrators lies in identifying which applications have potentially dangerous permission combinations and implementing proper scope limitations^[3]^[6].

Service Principal Exploitation Techniques

Service principals represent significant targets for attackers due to their often-elevated permissions:

Attackers target service principals with overly permissive roles, seeking those with administrative capabilities^[2].
Credentials associated with service principals (secrets or certificates) are prime targets for theft and misuse^[2]^[10].
Once compromised, a service principal with administrative permissions can be used to create persistence mechanisms, such as new backdoor applications or additional privileged service principals^[6]^[2].

This attack vector is particularly concerning because service principal sign-ins are not covered by traditional Conditional Access policies, making them essentially "Basic Authentication without any restrictions"^[10].
Note: Microsoft Entra Workload ID licensing is required here.

Real-World Attack Scenario: The Midnight Blizzard Attack

The recent "Midnight Blizzard" attack on Microsoft provides a concrete example of how these vulnerabilities can be exploited:

Attackers compromised a legacy non-production test tenant account that didn't have MFA enabled^[11].
They then used password spray attacks to gain initial access and move laterally to gain greater privileges^[11].
By exploiting service principal access and OAuth permissions, the attackers were able to maintain persistence and escalate privileges^[11].

This real-world example demonstrates the critical importance of securing service principals and implementing robust authentication controls across all environments, including test accounts.

Practical Mitigation Strategies for Entra ID Security

Implementing Least Privilege Principles

A fundamental approach to limiting privilege escalation risk is to strictly implement least privilege principles:

Regularly review and audit permission assignments to ensure users and applications have only the access they absolutely need^[7]^[2].
Use custom roles to create precisely scoped permissions instead of relying on broader built-in roles.
Implement Administrative Units (AUs) to limit the scope of administrative privileges to specific resources like users, groups, or devices.

By minimizing the privileges assigned to each identity, you reduce the potential impact of a compromised account or service principal.

Hardening Service Principal Security

Given their importance in application authentication and their vulnerability to attack, service principals require specific security measures:

Use managed identities wherever possible instead of service principals with secrets, as managed identities have Microsoft-managed credential rotation and protection^[4]^[10].
When service principals must be used, implement certificate-based authentication rather than secrets, as certificates provide stronger security^[2].
Store certificates and secrets in Azure Key Vault for enhanced protection, with keys secured by hardware security modules.
Regularly audit and review service principals to identify and remove unnecessary permissions or inactive principals.

Remember that Conditional Access policies don't cover service principal sign-ins, making additional protections crucial.

Strengthening Conditional Access Policies

While Conditional Access doesn't apply to service principals, it remains essential for protecting user accounts that might be used in privilege escalation:

Apply Conditional Access policies to every application to ensure consistent protection^[12].
Implement risk-based Conditional Access policies that respond to unusual sign-in behaviors.
Configure report-only mode initially to understand the impact of policies before full enforcement.
Create emergency access or "break-glass" accounts that are excluded from certain policies to prevent complete lockout scenarios.

Effective Conditional Access policies create multiple security layers that help prevent initial compromise that could lead to privilege escalation.

Monitoring and Detection Strategies

Proactive monitoring is crucial for identifying potential privilege escalation attempts:

Monitor changes to service principal credentials or authentication methods, as these may indicate compromise attempts^[2].
Implement privileged identity management (PIM) to ensure that access to critical roles is time-limited and requires justification^[13].
Use access reviews to periodically verify that users and service principals maintain appropriate privileges.
Deploy specialized monitoring solutions that can detect suspicious activities related to privilege escalation, such as unusual permission changes or authentication patterns.

Effective monitoring allows organizations to identify and respond to potential attacks before they result in full privilege escalation.

Best Practices for Ongoing Entra ID Security

In Episode 3 of Season 3 (App Governance Biomarkers in Entra ID – Your 100-Day Health Check) of our Preventative Maintenance series, we discussed the importance of a proper Identity Governance Framework and why you should implement one. Grab the on-demand webinar here.

Governance Framework Implementation

A comprehensive governance framework provides the foundation for sustainable Entra ID security:

Implement Microsoft Entra Identity Governance to ensure the right individuals have appropriate access to applications and services when needed.
Use entitlement management features to automate access request workflows and secure resources with role assignments, reviews, and expirations.
Deploy lifecycle workflows to ensure proper identity management from employee onboarding through offboarding.
Enforce separation of duties to prevent conflicts of interest and reduce the risk of privilege abuse.

Good governance ensures that permissions remain appropriate and well-managed throughout the identity lifecycle^[14].

Application Security Hardening

Since applications and their associated service principals are common targets for privilege escalation, specific application security measures are essential:

Implement a rigorous application registration process that includes security review and proper permission scoping^[15].
Regularly review application permissions and reduce them to the minimum required.
Monitor for suspicious application behavior, such as unusual API calls or access to sensitive resources.
Enforce proper credential management for applications, including regular rotation and secure storage.

These measures help prevent applications from becoming entry points for privilege escalation attacks.

Preparing for the Future: Service Principal-Less Authentication Block

Organizations should be aware of upcoming security changes that may affect their environments:

Microsoft will disable service principal-less authentication in March 2026, closing a potential security gap where enterprise apps could function without a service principal in the host tenant^[16].
Organizations should identify any third-party enterprise apps that might be affected by this change and contact their vendors for remediation plans.
Microsoft will handle the creation of service principals for Microsoft apps, but tenant administrators will need to address third-party applications.

Staying informed about such changes helps organizations maintain security while avoiding disruption.

Conclusion: Building a Resilient Entra ID Security Posture

Key Takeaways for Immediate Action

To protect against privilege escalation in Microsoft Entra ID, security professionals should prioritize these actions:

Conduct a comprehensive audit of service principals and their permissions, focusing on those with administrative capabilities^[2]^[10].
Implement strong governance controls, including access reviews and privileged identity management^[13]^[7]^[2].
Move toward managed identities where possible and strengthen authentication for service principals where not^[4]^[10].
Deploy robust monitoring and detection mechanisms focused on privilege escalation indicators^[6]^[7]^[2].
Stay informed about emerging threats and Microsoft security updates related to Entra ID^[16]^[11].
By implementing these measures, organizations can significantly reduce their risk of privilege escalation attacks while maintaining the functionality of their Microsoft cloud environments^[12]^[13]^[7]^[2].

Final Thoughts

Securing Microsoft Entra ID against privilege escalation requires a multi-layered approach that combines technical controls, governance processes, and ongoing vigilance. As attacks continue to evolve, security professionals must stay informed about new vulnerabilities and attack techniques while consistently applying best practices for identity security.

By understanding the technical details of privilege escalation vulnerabilities, implementing appropriate mitigations, and maintaining robust monitoring, organizations can protect their critical cloud resources and maintain the trust of their users and customers^[6]^[7]^[2].

AppGov Score Blog