I SPy: Escalating to Entra ID's Global Admin with a first-party app

This research was presented at fwd:cloudsec North America on June 30th, 2025. You can find the talk here.

Key points

• Service principals (SPs) that are assigned the Cloud Application Administrator role, Application Administrator role, or Application.ReadWrite.All permission can escalate their privileges by taking over any hybrid Entra ID user, including users with the Global Administrator role.
• This privilege escalation works when an SP is used to hijack the built-in Office 365 Exchange Online SP. The Office 365 Exchange Online SP's Domain.ReadWrite.All permission is then used to add a new federated domain to the tenant. It is then possible to forge a SAML token as any hybrid tenant user synced between on-premises Active Directory (AD) and an Entra ID tenant.
• We reported this vulnerability to the Microsoft Security Response Center (MSRC) on January 14, 2025, along with proof of concept (POC) code to replicate the issue.
• MSRC responded that "the scenario described reflects misconfiguration, not a security bypass." MSRC stated that this issue is consistent with documented risk of the Application Administrator role and the Application.ReadWrite.All Microsoft Graph permission.
• Privileged Entra ID applications that do not have the app instance property lock configured on their associated app registration are vulnerable to a similar privilege escalation.
• To detect this type of privilege escalation, monitor for credentials added to applications, especially those added to SPs. More details on this are available in Additional security considerations.
• This post provides in-depth background on Entra ID applications for security practitioners. You can skip ahead if you are already familiar with the topic.

Disclosure timeline

The following represents a timeline of our communications with MSRC about this finding:

- January 14, 2025: Datadog reported the issue to MSRC.
- January 15, 2025: MSRC responded that it had created a case, and updated the status to Review/Repro.
- March 20, 2025: MSRC confirmed that the application team was able to replicate the reported activity and said that the team was still investigating.
- April 11, 2025: Datadog shared a draft of this post with MSRC for review.
- April 30, 2025: Datadog notified MSRC of a planned talk about this finding on June 30.
- May 14, 2025: MSRC responded that "this is not a security vulnerability but expected behavior of the Application Administrator role and its associated permissions," and that "the scenario described reflects a misconfiguration, not a security bypass." Datadog requested details on how this finding differs from previous cases.
- May 27, 2025: MSRC requested clarification about whether this action could be taken by a user, or only by an SP.
- May 29, 2025: After additional testing, Datadog confirmed that only an SP could take this action.
- June 19, 2025: MSRC confirmed that "assigning the Application Administrator role directly to a service principal to generate a credential is expected behavior and does not constitute a security vulnerability."

Introduction

In this post, we share our findings about a Microsoft first-party application whose service principal (SP) in Entra ID can be used for persistence and privilege escalation by attackers with access to an SP that is assigned the Cloud Application Administrator role, the Application Administrator role, or equivalent application permissions. This privilege escalation works when a local credential is added to the first-party application's local SP, sometimes called an "SP backdooring" or "SP hijacking" attack.

An attacker can use this credential to authenticate as the application, granting them Domain.ReadWrite.All permissions to add a new federated domain. The attacker can then use the federated domain's certificate to forge a SAML token and authenticate as any hybrid user synchronized between the Entra ID tenant and an on-premises Active Directory (AD) domain. For example, an attacker who compromises a developer's user account that is assigned the Cloud Application Administrator role can use this vulnerability to impersonate hybrid users that are assigned the Global Administrator role.

The SP backdooring attack class has been covered by previous research and observed in the wild, eventually leading to Microsoft's implementation of additional protections against these attacks for most of its first-party applications. The findings in this post detail one application, Office 365 Exchange Online, that did not have these controls applied.

After outlining how an SP with application management permissions (Application Administrator, Cloud Application Administrator, or Application.ReadWrite.All) can be used to escalate privileges and take over any hybrid user, we offer guidance on how organizations can detect and defend against application and federated domain backdooring. This guidance is available in Additional security considerations.

It's important to note that user identities with application management permissions cannot escalate privileges in this way, due to specific controls on the Office 365 Exchange Online application. This application can be attacked only by an SP identity that has application management permissions.

If you're already familiar with app registrations, SPs, and how credentials are added to applications, you can jump ahead to our findings in Hunting vulnerable applications.

Previous research

The research described in this post builds on previous findings about SP credential backdoors. The articles below are not required reading to understand this post. However, we recommend that you read them to gain additional context about this attack class.

Notably, the following security research covers key background in using SP credential backdoors against Microsoft first-party applications:

• Dirk-jan Mollema, Azure AD privilege escalation - Taking over default application permissions as Application Admin
• Emilian Cebuc and Christian Philipov, Has Anyone Seen the Principal
• Andy Robbins, Azure Privilege Escalation via Service Principal Abuse
• Eric Woodruff, UnOAuthorized: Privilege Elevation Through Microsoft Applications
• Azure Threat Research Matrix, AZT405 - Azure AD Application

Additionally, the following articles document the use of SP credential backdoors, also referred to as "SP hijacking" or "SP manipulation," in threat actor activities:

• Microsoft Security Response Center, Customer Guidance on Recent Nation-State Cyber Attacks
• CrowdStrike Services - CrowdStrike Intelligence, Early Bird Catches the Wormhole: Observations from the StellarParticle Campaign

Background: How Entra ID applications work

To better understand this attack, we'll first review why applications in Entra ID exist, and how they work by using a combination of an app registration and an SP. This technique allows applications to be created in one tenant and then used (or "consumed") in many tenants. The application model connects services within Entra ID, allowing several different applications to create a unified platform experience for users.

Applications frequently have high-risk privileges and require only a single set of credentials for authentication, making them attractive targets for an attacker.

Applications as glue

While Microsoft's cloud may appear to be one consistent platform, it is composed of hundreds of unique services (e.g., Microsoft 365, Azure Resource Manager, Azure Portal) fused together by a relatively seamless user experience. For a sense of just how many applications this entails, you can review this partial list of commonly used Microsoft first-party applications.

Microsoft's applications are called first-party applications because they are included in an Entra ID tenant by default or are seamlessly added into a tenant (without explicit consent) when an administrator activates a new service. These applications are especially trusted in the context of Entra ID because they provide the core services of Microsoft's cloud and often have significant privileges assigned.

Entra ID users can also build on their Microsoft cloud experience by adding their own applications: either by developing their own company applications to offer to employees, or by adding third-party applications into their Entra ID tenant to provide additional services. For this reason, permissions exist in Entra ID for administrators to create, consume, and publish applications.

Now that we have context about why applications are needed, let's investigate their technical structure in Entra ID.

App registrations and service principals

In Entra ID, an OAuth application is made of two distinct objects:

• An app registration that specifies the name of the application and its associated settings, such as its requested permissions and the reply URLs used to redirect users after authentication.
• A service principal (SP) that provides the application with an identity to take action within a tenant where the application is added. This specific type of SP is sometimes called an enterprise application, or enterprise app.

The use of two objects to define an application makes multi-tenant applications possible within Entra ID. An app registration can be published and managed in one Entra ID tenant. The application is then consumed by multiple tenants.

Permissions

An app registration can define two separate categories of permissions:

• Application permissions (appRoleAssignments), a set of permissions that the application can use without user interaction. The application authenticates as itself and receives tokens with application permissions that allow the application to act on its own behalf.
• Delegated permissions (oAuth2Permissions), a set of permissions that the application can use on behalf of a user. The application receives tokens with delegated permissions when a user interacts with a target app and (if required) consents to a scope of permissions that the app can use on the user’s behalf.

Details on application permissions and delegated permissions are available in Microsoft's Overview of permissions and consent in the Microsoft identity platform.

Application permissions do not require user interaction, making them a higher risk for privilege escalation. The attack vector in this post relies only on application permissions (appRoleAssignments).

By definition, registering an application grants the application publisher access to your Entra ID tenant with any granted delegated and application permissions scopes. Consider the security of an application before granting it elevated permissions.

Properties

Entra ID can make it feel like the properties of an app registration and SP are universally linked, but this isn't always the case. Some properties of an SP are inherited from its associated app registration during creation. However, other SP properties are derived from the app registration or are configured separately on the SP and the app registration.

Inherited properties, such as the application's identifier (appId), match the properties of the app registration.

Certain properties, such as requiredResourceAccess, are used to inform the app registration's requested access. After consent is granted, these permissions are defined on the SP (appRoleAssignments and oauth2PermissionGrants).

Other properties are configured separately from one another. The app registration and SP both have properties that define authentication methods (keyCredentials, passwordCredentials). However, these properties can be configured independently on each object. In other words, the app registration and its associated SP can use different credentials to authenticate as the same application.

Credentials

A credential added to either an app registration or an SP allows authentication as that application. The scope of this authentication differs by which object the credential is added to:

• App registration: A credential that is added to an app registration allows authentication as that application in any tenant where that application is added, as long as the tenant ID is specified. After authentication, the application takes actions as the local SP.
• SP: A credential that is added to a local SP allows authentication as that application in only the tenant that the SP resides in.

Management

Users that are assigned the Cloud Application Administrator role or the Application Administrator role have permissions to "manage all aspects of app registrations and enterprise apps." These permissions apply to all app registrations and SPs within the tenant, and they may be assigned to more users than intended to support business operations.

Custom Entra ID roles that have the following permissions also grant the ability to update application credentials:

• microsoft.directory/applications/credentials/update
• microsoft.directory/servicePrincipals/credentials/update

Additionally, the Application.ReadWrite.All Microsoft Graph API permission allows the addition of application credentials.

Microsoft lists the above permissions as privileged and states that "assigning a user to the Application Administrator role gives them the ability to impersonate an application’s identity." However, these roles are required to create, onboard, and manage applications within Entra ID environments. These roles are frequently required to onboard new applications. As a result, these roles may be assigned to many users within a tenant as new applications are added, developed, and managed.

Additionally, in some cases, assignment of the Application Administrator role or Cloud Application Administrator role may be recommended for an SP to manage additional applications within the environment.

Authentication

One can authenticate as an application by using the client credentials grant flow with a single set of credentials assigned to an app registration or one of its associated SPs, along with the application ID and tenant ID. This authentication workflow is the same for authentication whether the credential was added to an SP or to an app registration.

The following request demonstrates authentication to the Microsoft Graph API (scope) with a secret (client_secret) credential, application ID (client_id), and tenant ID (/{tenant-id}/):

POST /{tenant-id}/oauth2/v2.0/token HTTP/1.1
Host: login.microsoftonline.com:443
Content-Type: application/x-www-form-urlencoded

client_id={application-id}&client_secret={secret}
&scope=https%3A%2F%2Fgraph.microsoft.com%2F.default
&grant_type=client_credentials

The only requirement for this method is that the ID of a tenant where the application is added is known in advance. The client credential flow can also be used to authenticate with a certificate. In that case, the request includes a locally generated JWT that is signed by the added certificate.

This request will receive a token for use with the target application:

{
  "accessToken": "eyJ[...snip...]",
  "expiresOn": "2025-04-10 14:08:12.000000",
  "expires_on": 1744308492,
  "subscription": "{tenant-id}",
  "tenant": "{tenant-id}",
  "tokenType": "Bearer"
}

The decoded token contains the application's permissions assignments for the target application.

No additional authentication or user interactivity is required to complete the sign-in process as an application. If you've ever heard that SPs use single-factor authentication, this workflow is likely why.

Attacking applications

We've just discussed several reasons that applications are interesting targets for attackers:

• Applications can take privileged actions without user interaction when they are assigned application permissions.
• Only a single credential, on an app registration or SP, is required to authenticate as an application.
• Permissions to manage applications (Application Administrator, Cloud Application Administrator, Application.ReadWrite.All) are often assigned to developers for application management.

Acting as an application can offer attackers two primary benefits:

• Obfuscating activities: An attacker with control over an application can use that application's identity and name to trick security operations personnel into assuming that the attacker’s activities are a part of the application's standard operations.
• Escalating privileges: An attacker can use a compromised application's permissions to move laterally across systems or to expand the attacker’s access.

Additional risk of first-party applications
Microsoft's first-party applications are added by default into Entra ID environments, meaning that no additional configuration is required for them to be available to an attacker. This has made first-party applications a target for attackers. Additionally, these applications provide application names that do not appear suspicious to security operations personnel. They can also include elevated permissions assignments.

How would an attacker use the application model to perform these attacks?

Backdooring app registrations

An attacker who has access to the Application Administrator role, Cloud Application Administrator role, or Application.ReadWrite.All permission in a publishing tenant can add a credential to an app registration. The attacker can then use that credential to authenticate as the application in any tenant where that application has been added.

Backdooring SPs

An attacker who has access to the Application Administrator role, Cloud Application Administrator role, or Application.ReadWrite.All permission in a consuming tenant can add a credential to the application's local SP to authenticate as that application in the consuming tenant only. This still allows the attacker to use any permissions assigned to the application within the consuming tenant.

Hunting first-party applications

In 2024, Eric Woodruff's UnOAuthorized: Privilege Elevation Through Microsoft Applications mentioned that after years of allowing credentials to be added to first-party app SPs, Microsoft was "implementing controls that restrict the ability to use credentials on service principals," and that the list of service principals an attacker can authenticate as has "continually dwindled." Before this time, Microsoft first-party apps were actively targeted by attackers for persistence and privilege escalation (see Previous research).

From Woodruff’s article, it sounded like adding credentials to Microsoft's first-party app SPs was no longer a major concern. We were curious to find out if any remaining first-party application SPs could be used for privilege escalation.

Finding target applications

We first created a script to attempt to take over all Microsoft first-party application SPs present in a default test tenant. We designed the script to:

1. Add a credential to a target SP by using Microsoft Graph to perform one of the following actions:

• Add a secret via a POST request to the /v1.0/servicePrincipals/{id}/addPassword endpoint.
• Add a certificate via a PATCH request to the /v1.0/servicePrincipals/{id} endpoint.

2. Wait a few seconds until the credential is applied to the SP.
3. Attempt to authenticate as the SP for Microsoft Graph by using the client credentials grant flow and the added secret or certificate.

Testing was initially completed by using an SP with the Application Administrator role assigned. This allowed for fast initial testing. While rare, assigning the Application Administrator roles to SPs is sometimes recommended.

Obfuscating activities

We used the test script to attempt to add credentials to several hundred Microsoft default SPs. Only a handful allowed adding a credential and authenticating as the application's SP, indicating that Microsoft has implemented defensive measures for the majority of these apps. Most of these applications did not have any permissions assigned that could allow privilege escalation.

However, one application allowed authentication with a local SP credential and had interesting permissions assignments that would eventually lead to privilege escalation: Office 365 Exchange Online (Client ID: 00000002-0000-0ff1-ce00-000000000000).

We added a certificate to the Office 365 Exchange Online application by using the test SP and then used the certificate to authenticate as the application. The authentication generated a sign-in log entry.

This action could allow obfuscation of malicious activities by letting an attacker masquerade as the Microsoft application's identity. But what other actions could an attacker take?

Reviewing token permissions

A look at the application token issued for Office 365 Exchange Online showed that permissions to modify groups and trusted domains were assigned to this identity. An attacker can modify trusted domains to forge tokens as any hybrid user in an Entra ID tenant with a federated domain.

Decoding the access token (JWT) received from authentication as the Office 365 Exchange Online application revealed that several application permissions (roles) were assigned to this identity for Microsoft Graph (aud):

{
  "typ": "JWT",
  "nonce": "[...snip...]",
  "alg": "RS256",
  "x5t": "z1rsYHHJ9-8mggt4HsZu8BKkBPw",
  "kid": "z1rsYHHJ9-8mggt4HsZu8BKkBPw"
}.{
  "aud": "https://graph.microsoft.com",
  "iss": "https://sts.windows.net/[...snip...]/",
[...snip...]
  "app_displayname": "Office 365 Exchange Online",
  "appid": "00000002-0000-0ff1-ce00-000000000000",
  "appidacr": "2",
  "idp": "https://sts.windows.net/[...snip...]/",
  "idtyp": "app",
  "oid": "9f0f1e6d-9b37-4b17-8388-591f69d4e252",
  "rh": "[...snip...]",
  "roles": [
    "Directory.Read.All",
    "Domain.ReadWrite.All",
    "EduRoster.Read.All",
    "Group.ReadWrite.All",
    "Policy.Read.All",
    "User.Read.All"
  ],
[...snip...]

Of these permissions, Domain.ReadWrite.All and Group.ReadWrite.All, were the most interesting. ReadWrite permissions allow modification of objects and settings, which can be useful for privilege escalation.

Additional information about high-risk Microsoft Graph permissions can be found in Emilien Socchi's project, Application permissions tiering.

Group.ReadWrite.All
Microsoft states that an application with the Group.ReadWrite.All permission can "update group properties and memberships, and delete groups." This permission allows an attacker to add users to a group that is assigned Azure Resource Manager (ARM) or M365 roles, granting access to Azure resources. However, this permission cannot modify groups with Entra ID permissions assignments.

Domain.ReadWrite.All
The Domain.ReadWrite.All permission "allows the app to add, verify and remove domains." This includes the ability to configure trusted domains and federated authentication settings. This permission could allow an attacker to manipulate trusted domains of an Entra ID tenant.

Escalating to Global Administrator with a federated domain

An attacker who has the ability to configure a federated domain (Domain.ReadWrite.All) can use this privilege to ultimately authenticate to Entra ID as any hybrid user. This authentication can include spoofed MFA claims, allowing the attacker to access Entra ID, Azure, and M365 as any hybrid user without having the user's password or MFA device.

To illustrate the impact, let's imagine a scenario where an attacker has compromised an SP that is assigned the Application Administrator role or Application.ReadWrite.All permission in Entra ID. The attacker adds a certificate to the Office 365 Exchange Online SP and uses that certificate to authenticate as the application's SP.

Using the Office 365 Exchange Online identity's Domain.ReadWrite.All permissions, the attacker adds a new federated domain to the Entra ID tenant. The certificate that is associated with this federated domain can then be used to forge tokens as any user synced with an on-premises Active Directory (AD) user, including users with the Global Administrator role.

Let's take a look at how this works. We'll demonstrate how an attacker could add a new federated domain and then forge tokens for a hybrid user that is assigned the Global Administrator role.

A note on federated domain backdoors

The impact of an attack that abuses federated domains was outlined by Dr. Nestori Syynimaa in his post How to create a backdoor to Azure AD. Dr. Syynimaa introduced the AADInternals module command ConvertTo-AADIntBackdoor to automate the process. More details on this general technique are available in the Azure Threat Research Matrix, as AZT507.3 - Domain Trust Modification.

AADInternals uses the Azure AD Graph API, not the Microsoft Graph API. This means that we needed to use Microsoft Graph API endpoints to add a malicious federated domain for an attack that uses the Microsoft Graph Domain.ReadWrite.All scope assigned to the Office 365 Exchange Online application.

We created a script to replicate the behavior of AADInternals' ConvertTo-AADIntBackdoor by performing the following steps:

1. Add a new domain to Entra ID tenant settings, and fetch the DNS verification code for this domain.
2. Verify the domain with a supplied DNS record.
3. Create federated domain settings for this domain, allowing anyone with the domain's registered certificate to authenticate hybrid users and attest MFA claims.
4. Use this certificate with AADInternals to forge a SAML token as a target hybrid user and authenticate as Global Administrator.

1. Adding the domain

For a domain to be trusted, it first needs to be added into Entra ID domains. Although a trusted administrator can perform this action in the Azure portal, the administrator’s web browser calls the Microsoft Graph API behind the scenes to update these domains.

Before we ran the script, we registered an external "malicious" domain for the attack.

The first stage of this script called the following endpoints:

• POST /v1.0/domains: Add a new malicious domain. At this stage, the domain is unverified and cannot be used yet for authentication.
• GET /v1.0/domains/{domain}/verificationDnsRecords: Retrieve the new domain's DNS verification record. This token is used to verify that the organization that manages the Entra ID tenant owns the added domain.

After these steps, the malicious domain appeared in Entra ID's custom domain names with a status of Unverified.

2. Verifying the domain

To verify the domain, the DNS verification record was added to the malicious domain's TXT records.

Once this DNS record was added to the external domain, the script called the POST /v1.0/domains/{domain}/verificationDnsRecords Microsoft Graph endpoint to request that Entra ID check the domain's DNS records and update verification status.

This API call ensured that the domain would have a verified status in Entra ID.

3. Configuring a federated domain

Entra ID federation configuration assigns a certificate to a verified domain within tenant settings. This configuration tells Entra ID to trust SAML tokens that are signed by the federated domain's certificate. Entra ID accepts these tokens as valid and exchanges them for Entra ID tokens. While this certificate is typically used as part of an Active Directory Federation Services (ADFS) configuration, the certificate can be used independently of ADFS to generate a malicious SAML token.

The script configured federation settings by using the POST /v1.0/domains/{domain}/federationConfiguration API endpoint. This request set required fields of the federated domain configuration, including the certificate to trust for authentication (signingCertificate).

This request was more complex than the others, so it's worth looking at it in detail:

POST https://graph.microsoft.com/v1.0/domains/{domain}/federationConfiguration
Content-Type: application/json

{
  "@odata.type": "#microsoft.graph.internalDomainFederation",
  "displayName": "Domain Backdoor",
  "issuerUri": "https://any.sts/TEST123",
  "metadataExchangeUri": "https://any.sts/TEST123",
  "signingCertificate": "MII[...snip...]",
  "passiveSignInUri": "https://any.sts/TEST123",
  "preferredAuthenticationProtocol": "wsFed",
  "activeSignInUri": "https://any.sts/TEST123",
  "signOutUri": "https://any.sts/TEST123",
  "promptLoginBehavior": "nativeSupport",
  "isSignedAuthenticationRequestRequired": true,
  "nextSigningCertificate": "MII[...snip...]",
  "federatedIdpMfaBehavior": "acceptIfMfaDoneByFederatedIdp"
}

The following key properties from this request are important to understand.
signingCertificate
This property contains the certificate to trust as this domain's signing authority. A SAML token signed by this certificate will be treated as valid authentication to Entra ID for a hybrid user.

signingCertificate

While this certificate is typically used as part of an ADFS configuration, no ADFS server is required to generate a valid SAML token. This is conceptually the same as a golden SAML attack: When an attacker has the certificate of a trusted authentication provider, they can create tokens as that provider.

federatedIdpMfaBehavior

This property determines whether Entra ID trusts MFA attestations from this domain. If the domain is configured with acceptIfMfaDoneByFederatedIdp, Entra ID will trust any claim that MFA has already been completed, regardless of the user's actual MFA status.

This facilitates third-party MFA verification outside of Entra ID.

URI fields

The request's URI fields—issuerUri, metadataExchangeUri, passiveSignInUri, activeSignInUri, and signOutUri—do not need to be valid URLs for the purposes of token forging. So long as these fields meet the format of an expected URL and are included where required in forged SAML tokens, they will be accepted by Entra ID.

4. Confirming the federated domain backdoor

After we took steps to verify the domain and create a federation configuration for it, the malicious domain appeared as both verified and federated in the Azure Portal.

At this stage, the certificate that is associated with this domain could be used on its own to forge SAML user tokens.

5. Forging SAML tokens as the federated domain

AADInternals can create a forged SAML token for hybrid users with the Open-AADIntOffice365Portal module. A trusted certificate for a federated domain and a hybrid user's onPremisesImmutableId are required to execute this module.

The onPremisesImmutableId represents the base64-encoded GUID of an on-premises user. This value is used to associate the user's on-premises account back to their Entra ID user object during federated authentication.

The script gathered a target user's onPremisesImmutableId by using the GET /v1.0/users/{id}?select=onPremisesImmutableId Microsoft Graph endpoint. This property is not protected and is visible to standard directory readers.

This identifier was used in combination with the certificate added for federated authentication to forge a SAML token via AADInternals:

PS C:\> import-module aadinternals
PS C:\> Open-AADIntOffice365Portal -ImmutableId "Ah2[...snip...]" `
>>    -Issuer "https://any.sts/TEST123" `
>>    -ByPassMFA $true `
>>    -PfxFileName "{certificate-file}.pfx" `
>>    -PfxPassword ""

The trusted certificate was included as a bundled .pfx file, along with the target user's onPremisesImmutableId as -ImmutableId and the -Issuer URL set during creation of the federated domain settings. The -ByPassMFA $true flag was used to forge a claim that the user had already passed MFA.

Executing this AADInternals cmdlet opened an attacker-controlled browser session in M365. The session was established with a SAML token that had been forged with the provided certificate. This SAML token was exchanged with Entra ID for a valid session token as the target user, indicating that authentication was successful.

The browser was authenticated to M365 as the target Global Administrator after proceeding through this prompt.

Browser tokens for the M365 portal are seamlessly exchanged in the same browsing session for Azure Portal tokens. This meant that access to the Azure Portal was also possible without additional authentication.

User login activity during this event indicated that the Global Administrator account had logged in after successfully completing MFA. However, because the multifactor claim was included in the forged SAML token, no password or multifactor method had been supplied during the login process.

Microsoft's response

Datadog reported this use of a Microsoft first-party application to escalate to Global Administrator from an SP with the Application Administrator role to MSRC on January 14, 2025.

On May 14, 2025, MSRC provided the following response to Datadog:

"We have determined that this is not a security vulnerability but expected behavior of the Application Administrator role and its associated permissions.

Specifically:

• The Application Administrator role includes the ability to manage application credentials. This means users with this role can add credentials to SPs and impersonate the application’s identity.
• If the app has been granted high privilege MS Graph API permissions such as Domain.ReadWrite.All, the Application Administrator can leverage those permissions through the app's identity. The reported technique is only possible if the app already has application-level permissions such as Domain.ReadWrite.ALL.

This is an example of privilege use within the boundaries of an already highly privileged context, not an escalation beyond the user's assigned role. The Application Administrator does not gain access to resources or actions outside the scope of the apps granted permissions."

"Overall, the scenario described reflects misconfiguration, not a security bypass. This is consistent with the documented behavior of the role (https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/permissions-reference#application-administrator).

Organizations should be cautious when assigning the Application Administrator role and ensure that apps with high impact permissions are tightly governed, as these inherently carry high trust requirements."

Additional security considerations

Monitoring app registrations, SPs, and trusted domains will help identify privilege escalation attempts related to this type of application abuse in all Entra ID tenants. Customers that use Datadog can review detections related to these events in How Datadog can help.

Defenders should also review app registrations and SPs within their Entra ID environment for unexpected credentials, consider cloud-only administrators, and review Conditional Access policies (CAPs) that may protect against these types of attacks.

Finally, developers should consider configuring the app instance property lock setting on app registrations that they control. This will prevent use of their application's SPs for local privilege escalation.

Details on these steps are provided below.

Monitor app registrations and service principals

Security teams should monitor for the addition of credentials to app registrations and SPs. The following events are associated with this behavior:

Service: Core Directory
Category: ApplicationManagement
Activities:

• Add service principal credentials
• Update application - Certificates and secrets management

These activities may indicate that an attacker that has the Application Administrator role, Cloud Application Administrator role, or Application.ReadWrite.All permission is attempting to compromise the associated identity.

Monitor trusted domains

Additionally, security teams should consider monitoring modification of Entra ID tenant domains. Events that may indicate modification or addition of trusted domains are as follows:

Service: Core Directory
Category: DirectoryManagement
Activities:

• Add unverified domain
• Verify domain
• Set federation settings on domain
• Set domain authentication

Addition or modification of trusted domains may indicate that an attacker who has elevated access to an environment is configuring malicious federated authentication for persistence.

Audit application credentials

Security teams should review credentials added to applications, especially those added to SPs. This is recommended for any application that may have experienced suspicious activity or alerts, as well as those with high privileges. Credentials should be added to SPs only in rare circumstances, such as for required troubleshooting, and should not be a part of standard application usage.

To review SP credentials at scale, consider reviewing Vasil Michev's post, Script to review and remove service principal credentials. You can identify highly permissioned SPs by using an additional script outlined in Reporting on Entra ID integrated applications and their permissions.

Individual SP credentials cannot be reviewed in the Azure Portal. Instead, you can use the Azure CLI or PowerShell:

• Azure CLI: az ad sp credential list --id {sp-object-id}
• PowerShell: Get-AzADSpCredential -ObjectId {sp-object-id}

You can review and manage app registration credentials in the Azure Portal on the app registration's settings, under Manage → Certificates & secrets.

Enforce cloud-only administrators

Microsoft recommends that "Global Administrator (and other privileged groups) accounts should be cloud-only accounts with no ties to on-premises Active Directory." This will ensure that these accounts are not synced users and that these accounts cannot be targeted for privilege escalation via a federated domain backdoor.

To ensure that privileged users are using cloud-only accounts, Microsoft recommends reviewing users that have the onPremisesImmutableId and onPremisesSyncEnabled properties set.

Users that have onPremisesSyncEnabled set can be reviewed in Entra ID, under Users → Add filter → On-premises sync enabled == Yes. Any user that has significant privileges and this property set should be replaced with a cloud-only administrator that has equivalent permissions. This will prevent Entra ID from trusting a forged SAML token that is issued by a federated domain for the privileged user.

Implement Conditional Access policies

You can implement Conditional Access policies (CAPs) to restrict which locations and devices that users are permitted to sign in from. You can also use workload identity CAPs to protect your own applications.

A set of policies configured to prevent malicious user access from outside of trusted systems may require:

• Access from named locations to restrict access to known IP addresses
• Entra ID compliant or joined devices with a level of known device security
• Additional multifactor authentication for elevated sign-in risk

Restricting authentication based on these conditions will prevent an attacker from using arbitrary network locations and devices to target identities in your Entra ID tenant.

For publishers and developers: Configure the app instance property lock

In December 2023, Microsoft announced the app instance property lock setting. This setting can be configured on app registrations to prevent the addition of credentials to their associated SPs. App instance property locks are enabled by default for app registrations created after March 2024.

Consider reviewing app instance property lock settings for any multi-tenant applications published in your Entra ID tenant, especially those created before March 2024. If the app instance property lock is not configured for these app registrations, it can be enabled for an app registration in the Azure Portal under Manage → Authentication → App instance property lock.

Configuring this setting for app registrations that you control will prevent the addition of credentials to the app registration's associated SP, limiting the credential attack surface of the application to only its app registration.

How Datadog can help

For customers that use Datadog Cloud SIEM, the following detections monitor for potential tampering with app registrations and SPs:

• Credential added to Azure AD application
• Credential added to rarely used Azure AD application

Additionally, the following detections identify when trusted domains are modified:

• Azure AD new verified domain added to tenant
• Microsoft 365 - Modification of Trusted Domain

Conclusion

In this post, we described a finding in which a Microsoft first-party application’s SP in Entra ID can be exploited for persistence and privilege escalation via federated authentication. In this scenario, an SP that is assigned the Application Administrator role, Cloud Application Administrator role, or Application.ReadWrite.All permission can take over any user in a hybrid tenant by using the Office 365 Exchange Online SP's Domain.ReadWrite.All permission.

Microsoft first-party applications are not the only SPs that are vulnerable to this kind of takeover. To help protect against this type of privilege escalation, we recommend that you review the security considerations provided in this post.

We'd like to thank MSRC for verifying this behavior and for clarifying its stance surrounding this scenario.

We're always eager to hear from you. If you have any questions, thoughts, or suggestions, send us a message at securitylabs@datadoghq.com, or open an issue. You can also subscribe to our newsletter or RSS feed.