Lesson 29 — The Service Principal Started Acting Like an Administrator
Nobody had signed in as the application.
There was no user sitting at a keyboard and no MFA prompt to review.
Yet the audit trail showed an application identity making privileged changes inside the tenant.
The service principal had existed for months. Its normal job was narrow and predictable.
Today, its behaviour was different.
Agent Foskett had to answer a critical question:
was the application legitimately changed, or had its identity become an attacker's access path?
No user sign-in. Still an identity incident.
The analyst must establish the service principal's purpose, permissions, credentials and historical behaviour before deciding whether the privileged actions were expected.
Case briefing
Investigation objective
Determine whether the service principal's privileged activity was authorised, whether its permissions or credentials recently changed, and whether the application identity may have been compromised or abused.
Investigator's rule
Non-human identities still have behaviour. Establish what an application normally does, then investigate meaningful deviation from that baseline.
Stage 1 — identify the application identity
| Question | Why it matters |
|---|---|
| What is the application? | Establish its legitimate business purpose and owner. |
| What service principal represents it? | Provides the tenant-local application identity to investigate. |
| What permissions does it hold? | Defines what the application can potentially do. |
| What credentials does it use? | Secrets and certificates can become attacker access paths if compromised. |
| What does it normally do? | Creates the behavioural baseline needed to identify abnormal activity. |
Start with business purpose
If an application exists to read inventory data, directory administration should be difficult to explain. Technical permissions should align with the documented purpose.
Find the owner
Identify the team responsible for the integration. A legitimate deployment or maintenance change may explain new behaviour — but validate it against the audit trail.
Stage 2 — hunt for application identity audit activity
Use Microsoft Entra audit telemetry to build a timeline of actions associated with the application or service principal.
let AppName = "InventorySync-App";
AuditLogs
| where TimeGenerated > ago(7d)
| where tostring(InitiatedBy.app.displayName) =~ AppName
or tostring(InitiatedBy.servicePrincipal.displayName) =~ AppName
| project TimeGenerated,
OperationName,
Category,
Result,
InitiatedBy,
TargetResources,
AdditionalDetails,
CorrelationId
| order by TimeGenerated asc
Sequence matters
A permission change followed minutes later by privileged operations is more meaningful than either event viewed independently. Preserve the order of events.
Look for first-time behaviour
An action the service principal has never performed before deserves attention, especially if the application has had a stable workload for months.
Stage 3 — look for changes to the application identity
New credentials are high-value clues
An unexpected client secret or certificate can provide a new authentication path for the application identity. Determine who added it and whether the change was authorised.
Permission expansion changes risk
A long-standing service principal may suddenly become dangerous if new application permissions or directory roles expand what it can do.
Stage 4 — search specifically for application-management changes
AuditLogs
| where TimeGenerated > ago(14d)
| where Category == "ApplicationManagement"
| where OperationName has_any (
"service principal",
"application",
"credential",
"consent"
)
| project TimeGenerated,
OperationName,
Result,
InitiatedBy,
TargetResources,
AdditionalDetails
| order by TimeGenerated desc
Pivot to the human who changed it
If a user or administrator added the credential or permission, investigate that person's sign-in context. The application incident may have started with a compromised human identity.
Do not stop at the application
Service-principal abuse can be one stage of a larger attack chain. Follow the identities, permissions, objects and resources connected to each suspicious change.
Stage 5 — compare expected and observed behaviour
| Normal baseline | Observed anomaly |
|---|---|
| Reads inventory data | Modifies directory configuration |
| Runs during scheduled integration windows | Privileged actions at 02:07 |
| Stable certificate authentication | New client secret recently added |
| Limited application permissions | New broad directory permission |
| No administrative activity | Multiple privileged objects modified |
Time of day is context, not proof
Applications often run overnight. The 02:07 timestamp is useful only when combined with unexpected operations, permission changes and the application's historical pattern.
Automation can make abuse fast
A compromised application identity can perform many operations rapidly and without interactive MFA. Scope the full period in which the suspicious credential or permission existed.
Stage 6 — test competing explanations
Validate change records
If the owner says the change was planned, verify the implementation time, requested permissions and expected actions against the actual audit events.
Absence of a user sign-in is not reassuring
Application identities can authenticate and operate non-interactively. A SOC workflow that only looks for suspicious user sign-ins can miss the real access path.
Stage 7 — contain the application identity
Coordinate before disabling production integrations
Containment can affect business systems. Work with the application owner while preserving the urgency required by the evidence and organisational incident-response process.
Remove the access path, not just the symptom
If a malicious credential was added, removing one suspicious permission may not be enough. Rotate credentials and review every mechanism that could allow the application to authenticate.
Stage 8 — make the SOC decision
Write the investigation finding
Lesson 29 key takeaways
- Service principals and applications are identities and require identity-focused investigation.
- Establish the application's legitimate business purpose before judging its behaviour.
- Compare observed actions with the service principal's historical baseline.
- Unexpected secrets, certificates and permission changes are high-value clues.
- Sequence permission or credential changes with the privileged actions that followed.
- Pivot to any human administrator who modified the application identity.
- Non-interactive application activity may not produce the user sign-in clues analysts expect.
- Validate claimed maintenance against actual change records and audit events.
- Containment may require credential rotation, permission removal and application disablement.
- Always remove the underlying access path, not only the visible malicious action.
Module 3 — Identity Incidents
Lesson 29 expands identity investigation beyond human accounts and into privileged application identities. Next, Agent Foskett brings the entire module together in one end-to-end identity incident.
Continue your SOC Analyst training
🔎 SOC Analyst Academy — Module 3: Identity Incidents
How to investigate suspicious service principal activity in Microsoft Entra
Lesson 29 of the Agent Foskett SOC Analyst Academy teaches analysts how to investigate a service principal performing unexpected privileged actions, review application credentials and permissions, and compare application identity behaviour with its normal business purpose.
KQL investigation of Microsoft Entra application identity changes
Learn how to use AuditLogs with KQL to investigate service principal activity, application-management events, credential changes, permission changes and suspicious privileged operations.
