The Service Principal Had Global Administrator

The suspicious detail

The investigation began during a routine Entra ID review.

No compromised user accounts were identified. No obvious malicious sign-ins were detected.

But an enterprise application appeared in a permissions review with access far beyond what its function required. The associated service principal had privileged access that could affect the entire tenant.

The application looked legitimate The application name appeared normal and had been present in the tenant long enough to avoid immediate attention.

Nobody was monitoring it User accounts were reviewed regularly, but application identities and enterprise applications were not being checked with the same discipline.

The permissions were excessive The service principal had permissions capable of making tenant-wide changes, which made it a privileged identity in practice.

First hunt: identify privileged service principal changes

Start by looking for service principal creation, app role assignment and privileged role activity in Microsoft Entra ID audit logs.

1
2
3
4
5
6
7

AuditLogs
| where TimeGenerated > ago(90d)
| where OperationName has_any ("Add service principal", "Add app role assignment", "Add member to role")
| project TimeGenerated, OperationName, InitiatedBy, TargetResources, Result
| order by TimeGenerated desc

Plain-English translation:

Show me recent activity involving service principals, application permissions and privileged role assignments.

What Agent Foskett checks next

A privileged service principal should be treated like a privileged user. The next step is to work out why the application needs that level of authority.

What does the application do?Does the application function justify privileged access, or has it accumulated permissions over time?

Who approved the permissions?Identify who granted the app permissions or assigned the role, and whether that approval matched the change process.

When was it created?Older applications can survive migrations, ownership changes and project shutdowns while retaining powerful access.

Second hunt: review enterprise application activity

After identifying privileged service principal changes, review enterprise application activity to understand which applications are active in the environment.

1
2
3
4
5
6
7

AuditLogs
| where TimeGenerated > ago(90d)
| where OperationName has "role"
| project TimeGenerated, OperationName, InitiatedBy, TargetResources, Result
| order by TimeGenerated desc

Third hunt: look for role assignment changes

Privileged access can be created through role assignment changes. Look for role-related audit activity and review the target resources carefully.

1
2
3
4
5
6
7

CloudAppEvents
| where Timestamp > ago(30d)
| where isnotempty(Application)
| summarize EventCount = count(), Users = dcount(AccountDisplayName) by Application
| order by EventCount desc

The investigation lesson

Service principals are often treated as technical objects rather than identities.

Attackers do not care whether an identity belongs to a person or an application. If an application has enough permissions, compromising that application can provide access equivalent to compromising an administrator account.

Applications are identitiesEvery service principal should be treated as an identity that requires ownership, review and governance.

Permissions accumulateApplications often receive permissions during projects, integrations and migrations, but those permissions are rarely removed later.

Reviews must include applicationsSecurity reviews that focus only on user accounts can miss a significant attack surface in Entra ID.

Common mistakes

Reviewing only usersAdministrators often focus on human accounts and ignore application identities with powerful access.

Trusting application namesA familiar name does not prove that an application still needs the permissions it currently has.

Forgetting legacy applicationsOlder apps can remain in the tenant long after the project or vendor relationship has ended.

Related Agent Foskett investigations and KQL guides

The OAuth App Asked For Permission Review how OAuth consent can create application access that survives normal user-focused investigations.

The User Was Added To A Privileged Group At 3:12am Follow another privileged access investigation involving unexpected role and group changes.

Continue with The User Clicked Accept And Gave Away The Entire Mailbox, The Conditional Access Policy Was In Report-Only Mode, The Session Token Never Expired, KQL Threat Hunting Guide, Agent Foskett Academy, Microsoft Security and the GEMXIT Security Review.

Develop IT. Protect IT. GEMXIT PTY LTD | GEMXIT UK LTD

Investigation focus