Microsoft Entra ID applications and service principals can access organisational resources through delegated permissions, application permissions, and directory role assignments. When these permissions are overly broad, granted without proper review, or abused through compromised credentials, an application can obtain access beyond its intended purpose.

Unlike a traditional compromised user account, a service principal can authenticate and access resources without an interactive user session. This makes application-based privilege abuse particularly important for cloud security teams to investigate.

This article explains how excessive application permissions can create privilege-escalation paths, how attackers may abuse compromised application identities, and how SOC analysts can investigate permission grants, credential changes, and suspicious service principal activity.

1. Introduction: The Application That Became an Administrator

A security analyst investigating suspicious Microsoft 365 activity discovers that an unfamiliar application has recently received permissions to access organisational data.

The application has a valid application ID and a service principal in the organisation's tenant. Its authentication activity appears separate from ordinary employee sign-ins, and its permissions allow it to interact with resources that the application does not normally need.

The analyst discovers three events close together:

• A privileged application permission was granted.

• A new credential was added to the application.

• The service principal began accessing resources through Microsoft Graph.

The investigation must determine whether this was an approved application deployment, an administrator's mistake, a compromised administrator account, or deliberate abuse of application permissions.

The key challenge is that application activity can be legitimate from an authentication perspective while still violating the organisation's intended access boundaries.

2. Understanding Applications and Service Principals

Microsoft Entra ID uses two related objects to represent applications.

Application object: The application's registration and configuration in its home tenant. It defines information such as the application's identity, supported authentication methods, requested API permissions, and other settings.

Service principal: The tenant-specific identity through which an application operates in a directory. It represents the application's local presence and is associated with the permissions and access assigned to it.

An application registered in one tenant can have service principals in other tenants where it has been provisioned or consented to.

This distinction matters during investigations because changes to an application object and changes to a service principal can appear as different audit events. Analysts should correlate the application ID, service principal object ID, tenant ID, and available audit records rather than treating every application-related object as interchangeable.

Delegated permissions versus application permissions

Permission typeHow access worksSecurity considerationDelegated permissionsAn application acts on behalf of a signed-in user, subject to the granted permissions and applicable user contextInvestigate both the application's grants and the user's effective accessApplication permissionsAn application acts as itself, without a signed-in user, using permissions granted to the service principalA compromised application credential may enable access within the application's granted scopeDirectory role assignmentsAn application or service principal receives an administrative role in Microsoft Entra IDMay provide administrative capabilities beyond ordinary resource API accessAzure RBAC assignmentsAn application identity receives a role over Azure resources at a particular scopeMay enable control of cloud resources within the assigned scope

Application permissions are especially important because they can support background access without an employee being signed in. A service principal with broad permissions may therefore continue accessing resources independently of an individual user's session.

3. How Application Permission Abuse Can Lead to Privilege Escalation

Application-based privilege escalation does not always involve exploiting a software vulnerability. It can result from misconfigured permissions, excessive administrator consent, compromised credentials, or unsafe administrative workflows.

3.1 Excessive Microsoft Graph Permissions

Microsoft Graph provides APIs for interacting with Microsoft 365 and Microsoft Entra resources. Depending on the permissions granted, applications may be able to access directory information, mail, files, groups, or other organisational data.

Permissions such as Directory.ReadWrite.All, Mail.Read, and Files.Read.All can have substantial security implications. The exact impact depends on the API, the permission type, and the resources covered.

Investigators should determine:

• Which Graph permissions were granted.

• Whether they are delegated permissions or application permissions.

• Whether administrator consent was required and granted.

• Which resources the permissions expose.

• Whether the permissions match the application's business purpose.

A permission name alone does not prove that data was accessed. It establishes potential capability; audit and resource-level evidence are needed to establish actual activity.

3.2 Abuse of Administrator Consent

Some application permissions require administrator consent. An administrator may grant these permissions during a legitimate deployment, but an attacker who compromises an appropriately privileged account may attempt to obtain consent for an unauthorised application.

The risk increases when the application requests broad permissions that are unnecessary for its stated purpose.

Relevant Microsoft Entra audit activities include:

• Consent to application

• Add app role assignment to service principal

• Add delegated permission grant

Investigators should identify the actor who granted consent, the target application, the resource API, the granted permissions, and whether the operation was approved.

Consent is not inherently malicious. The investigation must establish whether the application and its permissions were legitimate.

3.3 Compromised Application Credentials

Applications commonly authenticate using client secrets, certificates, or managed identities, depending on their design and hosting environment.

If an attacker obtains a usable application credential, they may be able to authenticate as the service principal and exercise its existing permissions.

Potential warning signs include:

• Unexpected credential additions.

• Credentials with unnecessarily long validity periods.

• Credentials added outside approved deployment workflows.

• Application sign-ins from unusual source infrastructure.

• Authentication followed by unusual API access.

• Credentials committed to public repositories or exposed in build systems.

Microsoft recommends secure credential management and, where suitable, managed identities or certificates rather than relying on long-lived client secrets. The appropriate choice depends on the application's architecture and available controls.

Adding a credential does not itself prove that an attacker has gained access. Investigators must establish whether the credential was authorised, whether it was used, and what activity followed.

3.4 Assigning Administrative Roles to Applications

A service principal may receive a Microsoft Entra directory role or an Azure RBAC role.

Depending on the role and scope, this can provide access to directory administration, resource management, or other sensitive operations.

Investigate role assignments that occur outside approved change processes, especially when the assigned role has broad administrative capabilities.

Review:

• The target service principal.

• The assigned role and scope.

• The initiating identity.

• The reason for the assignment.

• Whether the assignment was permanent or eligible for activation.

• Subsequent activity performed by the application identity.

An Azure RBAC role and a Microsoft Entra directory role are different mechanisms. Their permissions and affected resources must be evaluated separately.

3.5 Application Ownership and Configuration Changes

Changes to application ownership, redirect URIs, credentials, or other authentication-related settings may create additional opportunities for abuse.

For example, unauthorised ownership changes may allow an unexpected person to manage an application. A changed redirect URI may affect an authentication flow, depending on the application and protocol.

Relevant investigation areas include:

• Unexpected application owners.

• New or modified credentials.

• Changes to redirect URIs.

• Changes to API permissions.

• Service principal configuration changes.

• New role assignments or consent grants.

These changes are not proof of compromise by themselves. They should be correlated with the actor's permissions, deployment records, authentication events, and subsequent resource access.

4. Reconstructing an Application-Based Incident

Consider the following hypothetical timeline.

|