Service Principals in the cloud are often overlooked, but when misconfigured, they can offer attackers a perfect foothold in the cloud for long-term access. 

What are the differences between App Registration and Enterprise Apps in Entra ID? How well can you answer these essential questions? 

• How many App types does Entra ID have?
• Which type of consent can be obtained via a user or an admin?
• How do they behave in each mode/type?
• What are the security changes in each type?
• Are Enterprise Application permissions stronger than your admin role? 

This blog post will go through how hackers find ways to persist in Application Registration in Entra ID, create a Backdoor, and the potential for Privilege Escalation. 

Application & Security

Before diving into the attack techniques, we must first understand the differences between App Registration and Enterprise Apps in Entra ID. If you are still not confused, it’s time to add additional names to make it more confusing.

Registering an application in Entra ID creates both an “Application Object” and a corresponding “Service Principal.”

• Application Object contains metadata and configuration information about the application. This includes the application’s display name, identifier, reply URLs, and more. The application object represents 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.

Registering a multi-tenant application in Entra ID allows it to be used in multiple Entra ID tenants. This requires creating an additional service principal in each tenant where the application will be used. 

In Entra ID, the application objects and the corresponding service principals can be managed through different roles. 

Application Object 

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 or to access the Microsoft Graph API or other resources, you must 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 the Application ID, Redirect URIs, API Permissions, Authentication settings, etc.

Security Principal 

When an application is registered in Entra ID, it becomes an “Enterprise Application” or “Service Principal”. This is an instance of an application associated with a specific tenant.  

Each Security Principal has a unique identifier that can be used to grant permissions and access controls. 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 are clearer, we need to tie the API Permissions, Secret, and Certificate to the Application Object.

Certificates & Secrets: In the ‘Certificates & Secrets’ section, you can add credentials to your application. 

API Permissions: API permissions allow you to manage your application’s access to other applications or APIs within the Entra ID tenant or external services. This access is typically granted through OAuth 2.0, a widely used authorization framework that allows your application to obtain delegated permissions using access tokens. 

API Permissions Types

API Permissions can play a significant role in the application. When you configure the API Permissions for accessing the Microsoft Graph API or other APIs, you can choose between two different kinds of permissions: Delegated 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. 

When your application requests delegated permissions and a user signs in, Entra ID displays the requested permissions to the user and seeks their 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.

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

The Attack

When does the problem start? The Entra ID environment has hundreds of applications. While Cloud Applications or other application roles are intended to be managed by technical users, the Owner is often granted access to standard users. The problem with standard users is that they are compromised daily. Once a user with Owner permissions gets hacked, the attacker can persist, create a kind of Backdoor, and do Privilege Escalation.

This scenario and many related app scenarios are in the wild, and attackers exploit them daily. I saw some of them during 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, the attacker can manage access to various resources associated with that principal. This could include applications, files, or other services the security principal can access. 

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 the attacker has a chance to escalate privileges. Being the ‘owner’ of the application object might grant the user additional administrative rights or capabilities they wouldn’t have as a regular user. 

If the attacker gains access to this level of ownership, they could 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 via 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 be able 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 exploit the compromised resources further, such as Lateral Movement, Privilege Escalation, Data Theft, Malicious Actions, etc.

What do we have in this scenario?

• The application is named “MyHackedApp”.
• A standard user without any Entra ID admin roles.
• Standard user with strong authentication and part of Conditional Access Policies.
• Owner permissions are granted in the MyHackedApp.
• MyHackedApp already has API permissions.

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

Attacker Side – User Creds

Once we have user credentials, we can log in from PowerShell. We have 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, we need to know which App Registration has Owner permissions and if the compromised user has Owner permissions. For this action, we need to run Get-AzureADApplicationOwner. This command brings all the App Registration, the permissions, Object DI, etc.

Once we’ve got the information, we can check for potential persistence. We have a good result because the compromised user has Owner permissions to specific apps. In this stage, you can start actions that lead to persistence in this app.

Next, create a Secret in the App Registration with the command AzureADApplicationPasswordCredentials. This command can create a Secret with a visible Value and 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
• Secret with Value

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

Next, we will disconnect from the user session and connect with 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 scenes.

Now that the attacker is connected to specific modules, he can run many actions. Those actions can include additional recon and enumerations to check the existing permissions, run lateral movement, and escalate privileges. The last one will be useful in many scenarios and can be evaded by the SecOps, SOC, etc.

Conclusion

Abusing Entra ID App Registrations isn’t just a post-exploitation tactic, it’s a stealthy persistence layer that often flies under the radar. By registering rogue apps or hijacking existing ones, attackers can create long-term access paths that bypass traditional identity protections, survive password resets, and blend in with legitimate activity.

Potential Mitigations

To reduce risk and detect abuse, defenders should:

• Audit App Registrations Regularly: Monitor for newly created or modified app registrations, especially those created by non-admin users or outside expected business hours.
  
• Restrict Who Can Register Apps: Use Entra ID tenant settings to limit app registration capabilities to specific roles or groups.
  
• Review Consent Grants and Permissions: Flag apps with highly privileged scopes like Directory.ReadWrite.All, Mail.ReadWrite, or offline_access.
  
• Alert on Token Issuance to Unknown Apps: Monitor sign-ins or token activity to apps not listed in your sanctioned inventory.
  
• Enforce Conditional Access on Apps: Apply Conditional Access policies to block or limit access from unmanaged or suspicious apps.
  
• Revoke Unused Apps: Periodically remove stale or unused app registrations and enterprise applications.