Agent Foskett Investigation • Microsoft Entra ID • Workload Identities • Service Principal Sign-Ins • AuditLogs • KQL
The User Never Logged In — The Application Did It for Them
The activity looked like account access.
The team searched the user's sign-in history.
Nothing matched.
No interactive session.
No MFA event.
No user sign-in from the source IP.
Then Agent Foskett changed the question.
What if there was never a user session?
The authentication belonged to an application identity.
Not Every Identity Is a Person
Applications and service principals can authenticate to cloud resources without an interactive user sign-in. If you search only for people, you can miss the identity that actually performed the activity.
✓ Find service principal sign-ins
✓ Follow AppId and resource access
✓ Correlate application changes and source IPs
The user's sign-in history did not explain the activity
The investigation initially assumed a person had authenticated. That assumption sent the analyst into user sign-in telemetry, but there was no matching interactive session. The missing user sign-in was not a gap in the evidence. It was a clue that the wrong identity type was being investigated.
No matching user sign-inThe expected account activity was absent from the user's interactive sign-in history.
No MFA eventThere was no user authentication flow to explain the access.
Application identity suspectedThe investigation pivoted from people to workload identities.
Start with service principal sign-in telemetry
Where Microsoft Entra service principal sign-in logs are available in Microsoft Sentinel,
AADServicePrincipalSignInLogs provides the application identity, AppId, target resource, source IP and result needed to begin the investigation.- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
AADServicePrincipalSignInLogs
| where TimeGenerated > ago(7d)
| project TimeGenerated,
ServicePrincipalName,
ServicePrincipalId,
AppId,
ResourceDisplayName,
ResourceServicePrincipalId,
IPAddress,
ResultType,
ResultDescription
| order by TimeGenerated desc
Follow the application identity
Once the service principal name is known, narrow the history to that application. The objective is to establish when it authenticated, which resources it requested, where the requests originated and whether the results matched its normal behaviour.
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
let App = "Finance Automation";
AADServicePrincipalSignInLogs
| where TimeGenerated > ago(30d)
| where ServicePrincipalName =~ App
| project TimeGenerated,
ServicePrincipalName,
AppId,
ResourceDisplayName,
IPAddress,
ResultType,
ResultDescription
| order by TimeGenerated asc
The identity was the application
The sign-in telemetry resolved the mystery. The activity did not require the user's interactive session because the application authenticated as its own workload identity. That shifted the investigation toward the application's credentials, permissions, owners, resources and recent configuration changes.
11:06 — application authenticatedThe service principal sign-in record identified the workload identity.
11:06 — resource requestedThe target resource showed what the application was attempting to access.
User session not requiredThe activity could occur without the user logging in at all.
Where has this AppId been authenticating from?
The AppId is a strong pivot because display names can be changed or duplicated. Summarise the application's sign-ins by source IP and resource to identify new infrastructure, unexpected destinations or a sudden change in behaviour.
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
let AppIdToCheck = "00000000-0000-0000-0000-000000000000";
AADServicePrincipalSignInLogs
| where TimeGenerated > ago(30d)
| where AppId == AppIdToCheck
| summarize Attempts=count(),
Successful=countif(ResultType == 0),
Failed=countif(ResultType != 0),
FirstSeen=min(TimeGenerated),
LastSeen=max(TimeGenerated)
by IPAddress,
ResourceDisplayName
| order by Attempts desc
Did the application change before the activity?
Pivot into Entra audit telemetry and look for recent changes involving the application or service principal. Credential additions, permission changes and other directory modifications can provide important context for why the workload identity began behaving differently.
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
let AppIdToCheck = "00000000-0000-0000-0000-000000000000";
AuditLogs
| where TimeGenerated > ago(30d)
| where tostring(TargetResources) has AppIdToCheck
or tostring(InitiatedBy) has AppIdToCheck
| project TimeGenerated,
OperationName,
Result,
InitiatedBy,
TargetResources
| order by TimeGenerated asc
What else came from the same source IP?
A source IP that appears unusual for one service principal may also be associated with other workload identities. Scope the address across service principal sign-ins to determine whether the infrastructure touched one application or several.
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
let SuspiciousIP = "203.0.113.25";
AADServicePrincipalSignInLogs
| where TimeGenerated > ago(30d)
| where IPAddress == SuspiciousIP
| summarize SignIns=count(),
Apps=dcount(AppId),
Resources=dcount(ResourceServicePrincipalId)
by ServicePrincipalName,
AppId,
ResultType
| order by SignIns desc
Build a workload identity baseline
Service principals often authenticate repeatedly as part of normal automation. A tenant-wide summary helps analysts understand which applications are active, how many IPs and resources they normally use, and which identities deserve closer review when their pattern changes.
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
AADServicePrincipalSignInLogs
| where TimeGenerated > ago(30d)
| summarize SignIns=count(),
Successful=countif(ResultType == 0),
UniqueIPs=dcount(IPAddress),
Resources=dcount(ResourceServicePrincipalId),
FirstSeen=min(TimeGenerated),
LastSeen=max(TimeGenerated)
by ServicePrincipalName,
AppId
| order by SignIns desc
Application authentication changes the questions
Once the identity is a service principal, traditional user-focused questions are no longer enough. There may be no password entered by a person, no MFA prompt and no interactive browser session. The investigation must follow application credentials, permissions, resources and configuration history.
User identity questionsUseful when a person actually authenticated.
Workload identity questionsFocus on the service principal, AppId, credentials and permissions.
Resource questionsEstablish what the application accessed and whether that access was expected.
What the evidence can and cannot prove
A service principal sign-in record proves that an application identity attempted authentication to a resource. It does not by itself prove compromise, identify who possessed the credential or establish that the activity was malicious. Audit changes, credential history, permissions, IP context and application purpose are needed for that conclusion.
ProvenThe workload identity authenticated or attempted to authenticate.
CorrelateAppId, source IP, resource and audit changes help explain the activity.
Do not overclaimNo user sign-in does not automatically mean the service principal was compromised.
Agent Foskett's investigation mindset
When the expected user evidence is missing, do not force the investigation to fit a human identity. Microsoft cloud environments contain users, applications, managed identities and service principals. First identify what kind of identity actually performed the authentication.
Identify the identity typeDo not assume every authentication belongs to a person.
Follow stable identifiersUse AppId and service principal identifiers alongside display names.
Investigate the applicationCredentials, permissions, owners and resource access become central evidence.
Investigation findings
The activity could not be matched to an interactive user sign-in because no user had authenticated. Microsoft Entra service principal telemetry identified an application identity performing the authentication. The AppId, source IP and target resource provided the pivots needed to reconstruct its behaviour, while Entra audit activity helped determine whether the application's configuration had changed before the event.
The user never logged inThe missing interactive sign-in was accurate, not missing telemetry.
The application authenticatedA service principal was the identity behind the activity.
The investigation changed directionApplication credentials, permissions and resources replaced MFA and user-session questions.
Related Agent Foskett investigations
Continue with service principal, application identity and Microsoft Entra investigations.
The Service Principal Had Global AdministratorInvestigate how application identities can quietly hold extremely powerful permissions.
The New Service Principal Had No OwnerFollow a newly created workload identity whose ownership and purpose were unclear.
Agent Foskett AcademyBuild practical Microsoft security investigation and KQL skills.
Final thought
Modern identity investigations are not only about users. Applications can authenticate, obtain access and interact with cloud resources without a person signing in at that moment. If the user timeline does not explain the activity, do not assume the logs are incomplete. Ask a different question: was the identity ever a user in the first place?
Who authenticated?Determine whether the identity was human or workload-based.
What resource was requested?Follow the application into the service it accessed.
What changed?Review application configuration and audit activity around the event.
