Agent Foskett Investigation • Microsoft Entra ID • Service Principals • Workload Identities • AuditLogs • KQL
The Global Administrator Didn't Sign In — Their Service Principal Did
A privileged change appeared in the Microsoft Entra audit trail.
The team immediately checked the Global Administrator account.
No suspicious interactive sign-in.
No unfamiliar device.
No obvious MFA anomaly.
For a moment, the identity looked clean.
Then Agent Foskett stopped looking only for a user.
A service principal had authenticated during the same window.
The administrator didn't sign in. The workload identity did.
Privileged Activity Does Not Always Begin With a Human Sign-In
Applications and automation can authenticate as workload identities. When privileged activity lacks a matching user sign-in, follow the service principal, application ID and audit context.
✓ Establish the privileged change
✓ Separate user and workload sign-ins
✓ Resolve the service principal
The user sign-in trail looked normal
The first pivot was the privileged administrator because the sensitive action appeared connected to an administrative workflow. But the expected suspicious sign-in was missing. That did not make the audit event harmless; it meant the investigation needed another identity plane.
Privileged actionA sensitive Microsoft Entra change created the incident.
No matching user sign-inThe administrator's interactive authentication did not explain the timing.
Workload pivotThe investigation expanded to applications and service principals.
Start with the privileged audit event
Use AuditLogs to establish exactly what changed, when it changed, which objects were targeted and what Microsoft Entra recorded about the initiating identity. Do not begin by assuming the initiator must be a user.
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
AuditLogs
| where TimeGenerated > ago(7d)
| where Category in
("RoleManagement", "ApplicationManagement")
| project TimeGenerated,
OperationName,
Category,
Result,
InitiatedBy,
TargetResources,
CorrelationId
| order by TimeGenerated ascCheck the administrator anyway
A clean-looking user trail is still evidence. Review the administrator's sign-ins around the event so you can establish whether an interactive or non-interactive user authentication plausibly explains the action.
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
let Admin = "admin@contoso.com";
SigninLogs
| where TimeGenerated > ago(7d)
| where UserPrincipalName =~ Admin
| project TimeGenerated,
AppDisplayName,
IPAddress,
ResultType,
ConditionalAccessStatus,
DeviceDetail
| order by TimeGenerated ascThen follow the application identity
If the InitiatedBy data identifies an application or service principal, extract those identifiers and pivot into workload sign-in telemetry. This is where an investigation that appears to have no suspicious login can suddenly gain an authentication timeline.
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
AADServicePrincipalSignInLogs
| where TimeGenerated > ago(7d)
| where ServicePrincipalId ==
"00000000-0000-0000-0000-000000000000"
| project TimeGenerated,
ServicePrincipalName,
AppId,
IPAddress,
ResourceDisplayName,
ResultType,
CorrelationId
| order by TimeGenerated ascThe timestamps lined up
The workload identity authenticated shortly before the privileged audit event. Timing alone does not prove causation, but when the application identifiers, target resource and audit initiator also align, the service principal becomes the stronger investigative path.
02:04 — workload authenticationThe service principal successfully authenticated to a Microsoft resource.
02:07 — privileged changeThe sensitive directory operation appeared in AuditLogs.
Same application contextIdentifiers in the authentication and audit evidence connected the two events.
What privilege did the service principal actually have?
Do not describe a service principal as equivalent to a Global Administrator simply because its activity affected privileged configuration. Establish the actual directory roles, application permissions, delegated permissions or Azure roles assigned to the workload identity and determine which permission authorised the observed action.
Directory roleCheck whether the service principal held an Entra directory role capable of the operation.
Application permissionsReview Microsoft Graph or other application permissions that may authorise non-user activity.
Azure RBACIf the action involved Azure resources, investigate role assignments at the relevant scope.
Was the workload identity recently changed?
Next, reconstruct the service principal's own history. New credentials, certificate changes, permission grants, owner changes or role assignments shortly before the privileged activity can materially change the assessment.
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
let AppName = "Tenant Automation";
AuditLogs
| where TimeGenerated > ago(30d)
| where tostring(TargetResources) has AppName
| where OperationName has_any
("service principal",
"application",
"credential",
"consent",
"role")
| project TimeGenerated,
OperationName,
InitiatedBy,
TargetResources,
Result
| order by TimeGenerated ascScope every action by the workload identity
One privileged event may be only the first visible clue. Search the same application and service-principal identifiers across audit and workload authentication telemetry to identify other changes during the investigation window.
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
let AppId =
"11111111-1111-1111-1111-111111111111";
AuditLogs
| where TimeGenerated > ago(7d)
| where tostring(InitiatedBy) has AppId
| summarize Operations=count(),
FirstSeen=min(TimeGenerated),
LastSeen=max(TimeGenerated)
by OperationName, Result
| order by LastSeen descUser privilege and workload privilege are different evidence
The investigation should keep the human administrator and the application identity separate. A Global Administrator may own, approve or operate automation without their personal sign-in being the mechanism that performs each action. Conversely, a compromised workload identity can act without producing the interactive user sign-in an analyst initially expects.
Human identityReview the administrator's sign-ins, role and relationship to the application.
Workload identityReview the service principal's authentication, permissions, credentials and owners.
Audit initiatorUse the recorded initiating context to determine which identity actually performed the operation.
What the evidence can and cannot prove
A service principal sign-in followed by a privileged audit event can create strong correlation when the identifiers and context align. It does not mean the Global Administrator's account was compromised, and it does not mean every action performed by the service principal was malicious. Attribution must remain tied to the identities and permissions shown in the evidence.
ProvenWorkload sign-in telemetry can establish that the service principal authenticated, while AuditLogs can establish the recorded privileged operation.
CorrelatedMatching application identifiers, timing and audit initiator data can connect the workload identity to the action.
Do not confuse identitiesA privileged administrator associated with an application is not automatically the identity that authenticated or performed the operation.
Agent Foskett's investigation mindset
When a privileged action has no matching user sign-in, do not conclude that the logs are incomplete. Ask whether the action was performed by a workload identity instead.
Follow the initiatorLet the audit event tell you whether to investigate a user or an application.
Follow the privilegeDetermine the exact permission that authorised the workload identity's action.
Follow the workload historyCredential and permission changes may explain why a previously trusted automation suddenly became suspicious.
Investigation findings
The privileged Microsoft Entra activity did not originate from a suspicious interactive sign-in by the Global Administrator. The audit initiator and workload authentication evidence instead pointed to a service principal used by an administrative workflow. By separating the human identity from the workload identity, the SOC could investigate the application credentials, permissions and history that actually explained the event.
The administrator's sign-ins were not the answerThe expected user-authentication evidence did not align with the privileged change.
The service principal had its own trailWorkload sign-in telemetry established a separate authentication path.
The privilege had to be traced preciselyThe investigation focused on the workload identity's actual permissions rather than assuming the user's role transferred automatically.
Related Agent Foskett investigations
Continue with Microsoft Entra service-principal and workload-identity investigations.
The Service Principal Had Global AdministratorInvestigate a service principal holding excessive directory privilege.The New Service Principal Had No OwnerReconstruct an unfamiliar workload identity's creation, ownership and permissions.The Azure Key Vault Secret Was Read by an Identity Nobody RecognisedResolve an unfamiliar caller from Azure resource telemetry back to its cloud identity.
Final thought
Modern Microsoft environments contain privileged humans and privileged applications. An analyst who searches only for suspicious user sign-ins can miss half the identity story. When the audit trail shows a sensitive action but the administrator never appears to authenticate, inspect the application context. Sometimes the missing login is not missing at all. It belongs to a different kind of identity.
Who initiated the action?Start with the audit evidence rather than the identity you expect to find.
Which identity authenticated?Separate user sign-ins from service-principal sign-ins.
What permission made it possible?Trace the exact workload privilege before deciding what the event means.
