Persistence via App Registration in Entra ID

Cloud Service Principal is the key, abuse the hole, or the misconfiguration. While I’m investigating or attacking the cloud for many components on a daily basis. I find a lot of abuses. Some of them are great, others less. Entra ID Apps are part of them.

What are the differences between App Registration and Enterprise Apps in Entra ID? Can you spot these questions:

• How many App types do Entra ID have?
• Which type can consent via user or admin?
• How do they behave in each mode/type?
• What are the security changes in each type?
• What are the differences between Owner, Secret, and Role?

Those questions and many more are part of continued discussions in many companies that work with Entra ID and its apps. The post, Azure App Registration vs Enterprise App – What’s the Difference? provide a great explanation of those differences.

In this blog post, I’ll explain how to Persist in Application Registration, how to create a Backdoor (kind of), and the potential of Privilege Escalation. I’ll show you how the attack primitive works and show the PowerShell scripts that can be part of this persistence.

Let’s start with the Entra ID Apps explanation, the potential attack, and how to persist.

Application & Security

What are the differences between App Registration and Enterprise Apps in Entra ID? If you are still not confused, now it’s time to add addtional names and make it more confusing.

When you register an application in Entra ID, it creates both an “Application Object” and a corresponding “Service Principal.”

• Application Object contains metadata and configuration information about the application. This includes details such as the application’s display name, identifier, reply URLs, and more. The application object is essentially a representation of the application’s properties and settings in Entra ID.
• The Service Principal represents the application in Entra ID. It’s a specific type of security principle that allows the application to authenticate and request access to resources on behalf of users or itself. The service principal is the entity that receives permissions and access rights to resources within the Entra ID tenant.

When you register a multi-tenant application in Entra ID, it means the application can be used in multiple Entra ID tenants (organizations). This requires an additional service principal to be created in each tenant where the application will be used. Each tenant needs its own service principal to represent the application within that specific tenant and handle authentication and access requests for its users.

In Entra ID, both the application objects and the corresponding service principals can be managed through different Entra ID roles, with “Application Administrators” being one of the roles that have broad management capabilities.

Let’s explore this in more detail:

• The Application Administrators role in Entra ID has the authority to manage all application objects and service principals within a tenant. Members of this role can create, update, and delete applications, as well as manage their settings and configurations.
• Owners can define more granular management and ownership of specific applications, you can assign “Owners” to individual application objects. Owners have control over specific applications and can manage their settings, including who can access the application, which permissions it requires, and other relevant configurations.

By assigning owners to specific applications, you can delegate administration responsibilities and ensure that the right individuals or groups have the appropriate level of control over those applications. This allows for more fine-grained access control and better governance of the registered applications in Entra ID.

So, who are you? Application Object and Security Principal?

Application Object (App Registration)

An App Registration is a representation of an application in Entra ID. When you want to integrate an application with Entra ID for single sign-on (SSO) or to access Microsoft Graph API or other resources, you need to register the application in Entra ID. This registration creates an Application Object that contains metadata and configuration information about the application. Some key attributes of an App Registration include: Application ID (Client ID), Redirect URIs, API Permissions, Authentication settings, etc.

App Registrations provide the necessary information for Entra ID to recognize and manage the application’s interactions with users and resources in the tenant. In an Application Object (App Registration) within Entra ID, you primarily configure two important aspects: ‘API permissions’ and ‘Certificates & secrets.’

Security Principal (Enterprise App)

When an application is registered in Entra ID, it becomes an “Enterprise Application” or “Service Principal” (often referred to as a Security Principal). This is an instance of an application associated with a specific tenant. In simple terms, it represents the application’s presence in a directory and enables the application to be granted access to resources within that tenant. Each Security Principal has its own unique identifier, which can be used to grant permissions and access controls. When a user or service principal requests access to a resource (e.g., a Microsoft 365 service or an API protected by Entra ID), Entra ID checks the associated Security Principal’s permissions to determine if access should be allowed.

The Security Principal allows for fine-grained access control and is used when configuring permissions and role assignments for the application within the tenant.

Application Object Permissions

Now that the Application Object and Security Principal is more clear need to tie the API Permissions, Secret, and Certificate to the Application Object (App Registration).

Certificates & Secrets – In the ‘Certificates & Secrets’ section, you can add credentials (authentication secrets) to your application. These credentials are used to prove your application’s identity when interacting with Entra ID or other services that trust your application.
One common type of credential used is a client secret, which is essentially a password that the application uses to authenticate itself. When using PowerShell or other non-interactive scenarios to authenticate to Entra ID or Microsoft Graph, you can specify this client secret (generated in the ‘Certificates & secrets’ section) in your script to obtain an access token, which grants your application the necessary permissions to access resources.

These credentials are crucial for non-interactive scenarios, as they allow applications to authenticate and obtain access tokens without requiring direct user interaction. However, keeping these credentials secure and avoiding exposing them publicly is essential, as they grant significant access to your application.

API Permissions – Under API permissions, you manage your application’s permissions to access other applications or APIs within the Entra ID tenant or external services. These permissions are required when your application wants to perform actions on behalf of users or other applications.
For example, if your application needs to interact with user mailboxes in Exchange Online via Microsoft Graph, you would need to request the ‘read all mail’ permission from the Microsoft Graph API. This permission allows your application to access user emails.

When users consent to these requested permissions during the authentication process, your application is granted the necessary rights to access the requested resources on their behalf.

API Permissions Types

API Permissions can play a significant role in the application. When you configure the API Permissions for accessing Microsoft Graph API or other APIs, you can choose between two different kinds of permissions: Delegated permissions and Application permissions.

Delegated Permissions – Delegated permissions are also known as “user permissions” or “consent-based permissions.” These permissions are used when your application needs to access resources or perform actions on behalf of a signed-in user. The user must consent to grant these permissions to your application during the authentication process.
When your application requests delegated permissions and a user signs in, Entra ID will display the requested permissions to the user and seek their consent. If the user grants consent, your application can obtain an access token with the specified delegated permissions and use that token to access the resources on the user’s behalf.

For example, if your application needs to read a user’s emails from Exchange Online via Microsoft Graph, it would request the “Mail.Read” delegated permission. When a user signs in and consents to the application, it can access the user’s emails using delegated permission.

Delegated permissions are usually preferred when your application requires access to resources owned by users, as it allows for fine-grained access control and requires explicit user consent.

Application Permissions – Application permissions are also known as “application-based permissions” or “admin-consent permissions.” These permissions are used when your application needs to access resources or perform actions not tied to a specific user but to the application itself.
Application permissions are typically granted by administrators for the entire tenant, and they are not contingent on individual user consent. This makes them useful for scenarios where your application needs elevated privileges to perform operations that affect the entire organization or require access to resources beyond what a single user could access.

For example, if your application needs to read all users’ calendars in the organization using Microsoft Graph, it would request the “Calendars.Read” application permission. An administrator must explicitly grant these permissions to your application through the Entra ID admin consent process.

It’s important to note that application permissions should be used with caution, as they grant significant privileges. Ensure that you only request application permissions when necessary and that they are properly authorized by tenant administrators.

More information about Application and service principal objects in Azure Active Directory.

The Potential Attack

When does the problem start? Entra ID environment has hundreds of applications. While Cloud Applications or other application roles are intended to be managed by technical users, the Owner granted many times to standard users. The problem with standard users is that they are compromised on a daily basis. Once a user with Owner permissions (in some App Registration) gets hacked, it provides the attacker a way to persist, create a kind of Backdoor, and do Privilege Escalation.

This scenario and many related app scenarios are in the wild, and the attackers exploit them on a daily basis. I saw some of them from a security incident investigation and simulated them as part of penetration testing. Once a standard user receives Owner permissions for App Registration, these delegations to the user can have implications from a security perspective.

Let’s break down the two scenarios:

Owner of the Security Principal Object – In this case, if the user’s account is compromised and they have the ‘owner’ role for the security principal object (such as an Entra ID role), the attacker will be able to manage access to various resources associated with that security principal. This could include applications, files, or other services that the security principal has access to. However, this might not significantly worsen the situation because, as you mentioned, the compromised account already has access to the application and other resources. The attacker will have the same permissions as the compromised user, so there won’t be an escalation of privileges in this scenario.

Owner of the Application Object – If the user’s account is the ‘owner’ of the application object, then there is a chance for the attacker to escalate privileges. Being the ‘owner’ of the application object might grant the user additional administrative rights or capabilities that they wouldn’t have as a regular user. If the attacker gains access to this level of ownership, they could potentially make changes to the application’s settings, configurations, and access controls. This could lead to broader access across the organization’s resources or even unauthorized access to sensitive data.

Suppose a user account is set as the ‘Owner’ of the application object. In that case, there is a potential risk of persistence, backdooring, and privilege escalation if that account gets compromised by an attacker. Let’s explore this scenario further:

• Persistence: The attacker could create a secret and connect vis a secret without the need for any strong authentication.
• Privilege Escalation: The user account may have elevated privileges that go beyond regular user permissions. These elevated privileges can allow attackers the ability to modify application settings, add API permissions, grant consent to certain resources, manage user access, and more.
• Unrestricted Access allows attackers to gain control of the user’s account, they could exploit the elevated privileges associated with being the ‘owner’ of the application object. This could allow the attacker to make unauthorized changes to the application, gain access to sensitive data, and potentially perform actions with significant consequences.
• Exploiting Application Weaknesses: With ownership access, the attacker might be able to exploit vulnerabilities or weaknesses in the application itself. They could tamper with the code, configurations, or access controls, potentially creating backdoors or bypassing security mechanisms.
• Consent: As the application owner, the compromised user account might also have the ability to grant admin consent for certain permissions that require it. This could lead to the escalation of privileges on other applications or resources within the organization.

The Scenario

The following scenario can be run after a standard user is compromised, and this user has Owner permissions to App Registration. In this scenario, the attacker gains access to the user resources. After a user’s account is compromised, an attacker may attempt the following scenario to further exploit the compromised resources: Lateral Movement, Privilege Escalation, Data Theft, Malicious Actions, etc.

What we’ve got in this scenario?

• The application will be MyLegitApp1.
• A standard user without any Entra ID admin roles.
• Standard user with strong authentication (MFA numbering) and part of Conditional Access Policies.
• Owner permissions are granted in the MyLegitApp1.
• MyLegitApp1 already has API permissions.

The diagram below provides a high-level flow with the main actions from the attacker side.

The following screenshots describe the attack flow and the flow and its actions based on PowerShell.

Attacker Side – User Creds

Once we’ve got user credentials, we’re able to log in from PowerShell. We’ve got an open session to run actions on the Entra ID environment.

The attacker runs several actions to ‘know the field’, mainly to reconnaissance and enumerate the environment.

Next will be to create a Secret in the App Registration with the command: AzureADApplicationPasswordCredentials. This command can create a Secret with a visible Value with the required Secret.

Notes:

• The command AzureADApplicationPasswordCredentials can run with Owner permissions on the App Registration.
• The Value must be part of the command because we need this value at the next stage.

In this stage, we need to have the following values:

• Application ID
• Object ID
• Tenant ID
• Secrest with Value

For example, those artifacts will be the same ones in the Entra ID portal.

Next will be to disconnect from the user session and connect with the Secret. The Secret and the value we created.

Now that we’ve got the required artifacts, we can continue the actions and gain persistence.

Attacker Side – Secret

In this stage, we need to log in to the Entra ID with the artifacts we’ve got from the previous stage. The login can be done with Connect-Az and Connect-AzureAD.

From the moment I connected to the Entra ID tenant, I could run a lot of commands without any interruption. Some of the commands can be writeable commands.

Once we logged in with the Secret, we got the persistence. The Secret gives us a great way to be behind the scene.

Now that the attacker is connected with both AzureAD and Az, the attacker can run many actions. The actions can be additional recon and enumerations to check the existing permissions, run lateral movement, and do Privilege Escalation. The last one will be useful in many scenarios and can be evaded from the Blue Team, SOC, etc.

What will be next? To do Privilege Escalation from this stage.

Note: The PowerShell scripts will be shared soon.