Agent Foskett Case File • Microsoft Entra ID • Service Principals • Workload Identities • Privileged Roles • KQL
The Service Principal Hadn't Signed In for Months — Then It Changed a Privileged Role
The service principal had been quiet for months.
No recent workload sign-ins.
No obvious operational reason for it to suddenly become interesting.
Then privileged role activity appeared in the Microsoft Entra audit trail.
A non-human identity was now part of the investigation.
Agent Foskett needed to answer two separate questions:
What changed the privileged role — and why had this dormant workload identity suddenly become active?
Dormant Did Not Mean Harmless.
Service principals are workload identities. When one that has been quiet suddenly authenticates or appears around privileged directory activity, the investigation needs both sign-in evidence and audit evidence.
✓ Find the privileged role event
✓ Identify the workload identity
✓ Reconstruct its recent activity
The role change was the trigger — not the conclusion
A privileged role change deserves attention because it can materially alter what an identity is allowed to do.
But Agent Foskett did not assume the service principal itself had directly performed the change simply because it appeared in the same investigation.
First he separated the actors in the audit record: the identity that initiated the operation, the identity that received or lost privilege, and any Microsoft or automation service involved in processing it.
In cloud identity investigations, the initiator and the target are not necessarily the same thing.
But Agent Foskett did not assume the service principal itself had directly performed the change simply because it appeared in the same investigation.
First he separated the actors in the audit record: the identity that initiated the operation, the identity that received or lost privilege, and any Microsoft or automation service involved in processing it.
In cloud identity investigations, the initiator and the target are not necessarily the same thing.
Start with privileged role activity in AuditLogs
Microsoft Entra role-management activity is recorded in
AuditLogs. Agent Foskett searched for successful operations associated with adding members to roles, then preserved the complete target and initiator context.- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
AuditLogs
| where TimeGenerated > ago(30d)
| where OperationName has "Add member to role"
| where Result =~ "success"
| project TimeGenerated,
OperationName,
Category,
InitiatedBy,
TargetResources,
AdditionalDetails,
CorrelationId
| order by TimeGenerated descWas the service principal the initiator or the target?
TargetResources can contain the principal affected by the role operation and information about the role itself. InitiatedBy provides context about the identity or application that initiated the audited operation.Agent Foskett expanded the target resources instead of assuming that the first object in the array told the whole story.
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
AuditLogs
| where TimeGenerated > ago(30d)
| where OperationName has "Add member to role"
| where Result =~ "success"
| mv-expand Target = TargetResources
| extend TargetType = tostring(Target.type),
TargetName = tostring(Target.displayName),
TargetId = tostring(Target.id)
| project TimeGenerated,
OperationName,
TargetType,
TargetName,
TargetId,
InitiatedBy,
CorrelationId
| order by TimeGenerated descThe service principal had a history — even if that history was mostly silence
A service principal is a workload identity, so Agent Foskett did not look for its authentication activity in ordinary interactive user sign-ins.
Where Microsoft Entra service-principal sign-in logs had been exported to Log Analytics, he pivoted to
The absence of recent records was useful context only if the required telemetry had actually been collected and retained.
Where Microsoft Entra service-principal sign-in logs had been exported to Log Analytics, he pivoted to
AADServicePrincipalSignInLogs.The absence of recent records was useful context only if the required telemetry had actually been collected and retained.
Find the workload identity's sign-in history
Agent Foskett searched by the service principal object ID and summarised its observed activity.
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
let ServicePrincipalObjectId =
"11111111-2222-3333-4444-555555555555";
AADServicePrincipalSignInLogs
| where TimeGenerated > ago(90d)
| where ServicePrincipalId =~ ServicePrincipalObjectId
| summarize FirstSeen = min(TimeGenerated),
LastSeen = max(TimeGenerated),
Attempts = count(),
SourceIPs = make_set(IPAddress, 20),
Resources = make_set(ResourceDisplayName, 20)
by AppId, ServicePrincipalName
| order by LastSeen descObject ID and application ID are not interchangeable
Agent Foskett preserved both identifiers.
Confusing them can produce incomplete searches or lead the investigation toward the wrong object.
Know which identity identifier your telemetry actually contains.
ServicePrincipalId identifies the service principal object in the tenant, while AppId represents the application's client ID.Confusing them can produce incomplete searches or lead the investigation toward the wrong object.
Know which identity identifier your telemetry actually contains.
The first new sign-in mattered
The question was not simply whether the service principal had ever authenticated.
Agent Foskett wanted to know when activity resumed, which resource was requested and which source IP addresses appeared around that change.
Agent Foskett wanted to know when activity resumed, which resource was requested and which source IP addresses appeared around that change.
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
let ServicePrincipalObjectId =
"11111111-2222-3333-4444-555555555555";
AADServicePrincipalSignInLogs
| where TimeGenerated > ago(30d)
| where ServicePrincipalId =~ ServicePrincipalObjectId
| project TimeGenerated,
ServicePrincipalName,
AppId,
IPAddress,
ResourceDisplayName,
ResultType,
ResultDescription,
CorrelationId
| order by TimeGenerated ascA successful token request did not prove the role change
Workload sign-in telemetry establishes authentication activity by the service principal against a resource.
It does not automatically prove that the same authentication directly caused a particular directory change.
Agent Foskett correlated timestamps, identifiers, audit records and surrounding operations before linking the events.
Temporal proximity is a lead. Correlation is the investigation.
It does not automatically prove that the same authentication directly caused a particular directory change.
Agent Foskett correlated timestamps, identifiers, audit records and surrounding operations before linking the events.
Temporal proximity is a lead. Correlation is the investigation.
Did the service principal receive the privileged role?
A different scenario was possible: the service principal might not have initiated the role change at all. It might have been the principal receiving the role.
Agent Foskett specifically looked for service-principal targets in role-management events.
Agent Foskett specifically looked for service-principal targets in role-management events.
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
AuditLogs
| where TimeGenerated > ago(30d)
| where OperationName has "Add member to role"
| where Result =~ "success"
| mv-expand Target = TargetResources
| extend TargetType = tostring(Target.type),
TargetName = tostring(Target.displayName),
TargetId = tostring(Target.id)
| where TargetType =~ "ServicePrincipal"
| project TimeGenerated,
OperationName,
TargetName,
TargetId,
InitiatedBy,
CorrelationId
| order by TimeGenerated descThen investigate the identity that actually initiated the change
If the service principal was the target of the privileged assignment, the investigation shifted to the actor represented in
Was it an administrator? Another application? A governance workflow? A Microsoft-managed service involved in a legitimate PIM process?
Agent Foskett preserved the raw audit context before deciding what the initiator represented.
Do not accuse the target of performing the operation that changed the target.
InitiatedBy.Was it an administrator? Another application? A governance workflow? A Microsoft-managed service involved in a legitimate PIM process?
Agent Foskett preserved the raw audit context before deciding what the initiator represented.
Do not accuse the target of performing the operation that changed the target.
Was the service principal expected to be active again?
A dormant workload identity returning to use can have legitimate explanations: a scheduled job, a restored integration, an application deployment or a previously unused credential path.
Agent Foskett checked ownership, change records and the expected purpose of the application.
He also asked whether the workload identity still needed the permissions it retained.
Dormancy is not compromise. Unexpected reactivation is a reason to investigate.
Agent Foskett checked ownership, change records and the expected purpose of the application.
He also asked whether the workload identity still needed the permissions it retained.
Dormancy is not compromise. Unexpected reactivation is a reason to investigate.
What else did the workload identity access?
Agent Foskett expanded the scope beyond the first observed sign-in. He grouped recent workload sign-ins by target resource and source IP to see whether the service principal's behaviour had changed.
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
let ServicePrincipalObjectId =
"11111111-2222-3333-4444-555555555555";
AADServicePrincipalSignInLogs
| where TimeGenerated > ago(30d)
| where ServicePrincipalId =~ ServicePrincipalObjectId
| summarize Attempts = count(),
FirstSeen = min(TimeGenerated),
LastSeen = max(TimeGenerated)
by ResourceDisplayName, IPAddress
| order by LastSeen descCheck for credential changes around the reactivation
A service principal becoming active after a long quiet period becomes more interesting if its application credentials were also changed nearby.
Agent Foskett searched the Entra audit trail for updates involving the same application or service principal and reviewed the exact operation names and modified properties returned by the tenant.
Credential changes, renewed sign-ins and privileged activity belong on the same timeline when they occur together.
Agent Foskett searched the Entra audit trail for updates involving the same application or service principal and reviewed the exact operation names and modified properties returned by the tenant.
Credential changes, renewed sign-ins and privileged activity belong on the same timeline when they occur together.
Build the workload identity timeline
Agent Foskett organised the evidence chronologically.
Long quiet periodEstablish the last observed service-principal sign-in and confirm telemetry coverage.
Workload activity resumesIdentify the first new sign-ins, resources and source IP context.
Privileged role eventPreserve the exact AuditLogs operation and role-management context.
Actor and target separatedDetermine whether the service principal initiated the operation, received the role or was merely related context.
Additional activity scopedSearch the workload identity's other resources, sign-ins and nearby directory changes.
Business context verifiedConfirm ownership, expected automation and whether the privilege change was authorised.
What Agent Foskett checked
Role eventWhat exact privileged role-management operation was recorded?
InitiatorWhich user, application or service initiated the audited operation?
TargetWas the service principal the recipient of the role rather than the actor?
Sign-in historyWhen was the workload identity last observed before activity resumed?
Resources and IPsWhich resources and source IP addresses appeared in recent workload sign-ins?
Ownership and purposeWas the service principal still required, owned and operating as designed?
What the evidence can and cannot prove
AuditLogs can establish the directory operation Microsoft Entra recorded and provide initiator and target context. AADServicePrincipalSignInLogs can establish observed service-principal authentication activity where those logs are collected.Neither table alone automatically proves malicious intent, and a missing sign-in record is not proof of inactivity if collection or retention was incomplete.
Likewise, a service principal appearing as the target of a privileged role assignment does not mean it initiated that assignment.
Identify the actor. Identify the target. Then correlate the workload activity.
The lesson
The service principal had been quiet for months.
Then workload activity returned and privileged role activity appeared in the same investigation window.
Agent Foskett did not collapse those facts into a conclusion. He separated the initiator from the target, examined the workload sign-in history and reconstructed the surrounding identity changes.
A non-human identity can remain dormant while retaining powerful access. When it suddenly becomes active, investigate the identity — not just the operation.
Then workload activity returned and privileged role activity appeared in the same investigation window.
Agent Foskett did not collapse those facts into a conclusion. He separated the initiator from the target, examined the workload sign-in history and reconstructed the surrounding identity changes.
A non-human identity can remain dormant while retaining powerful access. When it suddenly becomes active, investigate the identity — not just the operation.
Investigation principle: Treat unexpected workload-identity reactivation and privileged directory changes as separate facts until the evidence connects them.
Related investigations
Agent Foskett InvestigationsContinue through the complete collection of real-world Microsoft security investigations.KQL Threat HuntingExplore practical investigation techniques across Microsoft Defender XDR, Microsoft Sentinel and Microsoft Entra ID.SOC Analyst AcademyBuild practical investigation and triage skills across identity, endpoint, email and cloud security.
Final thought
Non-human identities are easy to forget because they do not sit at a desk and they do not complain when their access is excessive.
But service principals can hold credentials, request tokens and participate in highly privileged automation.
When one that has been quiet suddenly becomes relevant, start with the evidence.
Find the workload sign-ins. Preserve the role event. Separate the initiator from the target. Then follow every related identity change until the timeline makes sense.
The service principal had been quiet.
The audit trail wasn't.
Follow the evidence. Build the timeline.
The Logs Already Knew! 🔎
But service principals can hold credentials, request tokens and participate in highly privileged automation.
When one that has been quiet suddenly becomes relevant, start with the evidence.
Find the workload sign-ins. Preserve the role event. Separate the initiator from the target. Then follow every related identity change until the timeline makes sense.
The service principal had been quiet.
The audit trail wasn't.
Follow the evidence. Build the timeline.
The Logs Already Knew! 🔎
