Entra ID App Escalations: Attacks & Defenses

Here is an interesting path many organizations are completely unaware of (or are aware of, but still struggling to tackle): app-based privilege escalation in Microsoft Entra ID.

App-based privilege escalation threats occur when an attacker leverages application permissions to gain elevated access within the Microsoft Entra ID environment. This type of attack often involves exploiting vulnerabilities in the application’s authentication and management of access tokens—used to authorize actions on behalf of users or other applications. These attacks are particularly dangerous because they bypass traditional security measures, like multi-factor authentication (MFA). Since tokens and app permissions are at the core of this attack, the traditional focus on user credentials might not be sufficient to detect or stop these threats.

While these identity posture vulnerabilities have been known for some time in environments like Microsoft Entra ID, app-based privileged escalation threats can be challenging to address due to several common factors: limited visibility, evolving attack techniques, the complexity of modern IT infrastructures, inadequate focus on app permissions, etc. Unaddressed, these threats can result in exploitable gaps that attackers can use to gain unauthorized access.

In our last Identity Security Insights® update, BeyondTrust introduced new content—rules and triggers that will alert when a threat or suspicious activity occurs and escalate to a high priority. This new content can better identify App-based privilege escalations in Microsoft Entra ID, empowering security teams to identify and block Entra ID attacks.

Read on to learn what an App escalation in Entra ID is, how it can be used to gain a privilege escalation path, and what you should do about it.

To understand Apps in Entra ID, it can be helpful to understand what Entra ID is and where it came from. Formerly called Azure Active Directory, Entra ID aimed to improve upon its predecessor: on-prem Active Directory (AD). Specifically, it was designed to address the unique traits of the cloud. Cloud environments are different from on-prem environments in that they don’t provide a way for everything to be hidden behind a protected network, making integrations a little more challenging. So, Entra ID, the cloud-native version of AD, offered an improved way to manage cloud user access by integrating more easily within a cloud environment.

To understand how Entra ID operates within a typical organization, let’s consider a basic scenario: using Entra ID to identify and authenticate a user, and then allowing the user to proceed to some other third-party cloud software. A common setup is to use Entra ID as the Identity Provider (IDP) that handles the SSO login of the user and then redirects them back to the software they want to use. This means an IT team only needs to manage single accounts for users offboarding and onboarding, without having to manage individual accounts for each piece of software used by the company.

Apps in Entra allow developers to write custom software (or applications) that integrate with Entra ID and leverage its cloud-native authentication and authorization protocols, like oauth2. This allows their applications to securely access, manage, or interact with various resources in the Microsoft cloud environment. To do this, they require the software in question to register as an Entra app within a customer's Entra ID tenant. During registration, the application must be granted the permissions it requires to operate.

This flexibility enables a wide range of use cases, from automating user management to enabling secure, single sign-on experiences and implementing custom security policies.

By granting Apps the permissions they need to operate, we can introduce the risk of creating unintended access pathways. This is especially a concern when working with apps used to manage the directory itself.

An attacker typically starts by compromising a lower-privileged account (with fewer protections). They then leverage this foothold, using privilege escalation paths and executing lateral movement until they are sufficiently entitled to perform their objective.

In Entra ID, every App has a corresponding “service principal” attached to it. When a human performs actions within Entra, they do so using their user account, which represents their identity. On the other hand, when an application performs actions within Entra, it does so using a service principal account. The service principal is essentially the application's own unique identity within Entra ID. The app can use this identity to authenticate itself to Microsoft Entra ID and get permission to perform specific actions, based on the roles and permissions it has been assigned.

Two key factors make Apps and their associated service principals dangerous:

1. API Permissions

Apps commonly request API permissions to perform actions against the APIs of other apps. Some permissions can be used to do things within the Directory itself. Here are two particularly dangerous entitlements:

• RoleManagement.ReadWrite.Directory - Allows the app to read and manage the role-based access control (RBAC) settings for your company's directory without a signed-in user. This includes instantiating directory roles, managing directory role membership, and reading directory role templates, directory roles, and memberships.
• RoleAssignmentSchedule.ReadWrite.Directory - Allows the app to read, update, and delete policies for privileged role-based access control (RBAC) assignments of your company's directory, without a signed-in user.
  
  
  

2. Directory Roles

Just like users, service principals can be assigned roles in Entra—and some built-in directory roles are very powerful! For instance:

• Global Administrator
• Privileged Authentication Administrator
• Privileged Role Administrator
• Partner Tier2 Support
• Security Administrator
• Intune Administrator

All of these directory roles have roughly the same level of privilege as the Global Administrator role, which is the highest privileged role. Roughly speaking, they have permission to do everything. If any of our App’s service principals have a role listed above, its management must be carefully protected. Anyone who can manage the app essentially has these permissions, too. This is because the human user controls the app, and, in essence, can make it do anything the service principal’s assigned role can perform.

Now that we know how Entra Apps can be dangerous, here are some steps to mitigate these risks:

1. Identify highly privileged Apps in your setup. Ensure processes are in place to carefully audit the management of highly privileged apps, as well as to remove any apps and/or permissions that are no longer required.
2. Treat Application Administrators as Global Administrators. Microsoft offers detailed guidelines for mitigating the risks associated with Microsoft Entra roles. These include recommendations such as having no more than five global admins. If you’ve created a lot of Application Administrators in your system, it’s time to rethink that.
3. Identify and audit the owners of dangerous apps. We must consider owners of these apps to be as highly privileged as Global Administrators. Determine if your organization is comfortable with these owners having such a high level of privilege.
4. Ensure proper controls (MFA, privileged access management, etc.) are in place for any account that can manage dangerous apps. It’s essential to harden access pathways to highly privileged accounts to help ensure they don’t fall into the wrong hands.

Now you know how a highly privileged application can be used by a malicious Application Owner / Administrator to escalate the attacker’s privileges to the highest possible in Entra ID.

If you want to understand if your Azure/Entra environment contains these exploitable privilege escalation paths and others, we offer a free assessment and 30-day trial that can uncover these Entra ID paths, along with many more privileged escalation pathways. Or, click here to learn more about how Identity Security Insights can help you improve your identity security posture by finding privileges and Paths to Privilege™ before an attacker does.