Service principals (SPs) and app registrations are non-human identity objects in Entra ID that authenticate using client secrets or certificates rather than passwords and MFA. Attackers target them because credentials added to an SP survive the victim's password reset entirely — the SP authenticates independently as the application identity.
The primary attack path is: gain compromised admin access → add a new client secret to a high-privilege SP → use that secret to authenticate as the SP from the attacker's infrastructure. Microsoft Sentinel detects this via AuditLogs operation Add service principal credentials. A secondary path is creating a brand-new app registration with dangerous API permissions and self-consenting.
◈ Table of Contents
01
Background
CONTEXTB1Attack Paths & MITRE Mapping
| Technique | MITRE | Indicator |
|---|---|---|
| Add secret/cert to existing privileged SP | T1098.001 | AuditLogs: "Add service principal credentials" — existing SP with high permissions gains new secret |
| Create new app registration with dangerous permissions | T1550.001, T1136.003 | AuditLogs: "Add application" + "Add app role assignment to service principal" for Mail.Read, Files.ReadWrite, Directory.ReadWrite.All |
| SP logon from unusual IP/country | T1078.004 | AADServicePrincipalSignInLogs: SP authenticating from unexpected country or ASN never seen before |
| SP granted Application (not Delegated) permissions | T1528 | Application permissions act without a user — they can read ALL mailboxes, ALL files tenant-wide |
| Managed Identity credential abuse | T1078.004 | Azure IMDS token theft — attacker using managed identity from outside the assigned VM/function |
B2Log Sources
| Source | Table | Key Field |
|---|---|---|
| Entra ID Audit | AuditLogs | OperationName: Add service principal credentials, Add application, Add app role assignment |
| SP Sign-in Logs | AADServicePrincipalSignInLogs | ServicePrincipalName, IPAddress, Location, ResourceDisplayName |
| Azure Activity | AzureActivity | Azure ARM calls made with SP token — resource group changes, VM deployments, Key Vault reads |
02
Identification
INVESTIGATEService Principal Abuse — Investigation Workflow
I1Detect SP Credential Additions & New App RegistrationsKQL + SPL
KQL — Sentinel: SP credential additions (last 7 days)
AuditLogs
| where TimeGenerated > ago(7d)
| where OperationName in (
"Add service principal credentials",
"Update application – Certificates and secrets management",
"Add application",
"Add app role assignment to service principal"
)
| extend SPName = tostring(TargetResources[0].displayName)
| extend SPObjectId = tostring(TargetResources[0].id)
| extend Initiator = tostring(InitiatedBy.user.userPrincipalName)
| extend InitiatorApp = tostring(InitiatedBy.app.displayName)
| extend InitiatorIP = tostring(InitiatedBy.user.ipAddress)
| extend CredType = tostring(TargetResources[0].modifiedProperties[0].newValue)
| project TimeGenerated, OperationName, SPName, SPObjectId, Initiator, InitiatorApp, InitiatorIP, CredType
| order by TimeGenerated desc
KQL — Flag SP logons from unexpected countries
// SP sign-in from country that never appeared in last 30 days
let baseline_countries = AADServicePrincipalSignInLogs
| where TimeGenerated between (ago(30d) .. ago(1d))
| summarize Countries=make_set(Location) by ServicePrincipalName;
AADServicePrincipalSignInLogs
| where TimeGenerated > ago(1d)
| join kind=leftouter baseline_countries on ServicePrincipalName
| where not(Location in (Countries))
| project TimeGenerated, ServicePrincipalName, IPAddress, Location, ResourceDisplayName
| order by TimeGenerated desc
SPL — Splunk: New SP credentials added
index=azure sourcetype=azure:aad:audit
OperationName="Add service principal credentials"
| spath InitiatedBy.user.userPrincipalName OUTPUT Initiator
| spath TargetResources{}.displayName OUTPUT SPName
| table _time, SPName, Initiator, Result
| sort -_time
Application-type permissions (as opposed to Delegated) on an SP grant access to ALL tenant resources without a user context. An SP with Mail.ReadWrite.All can read every mailbox in the org. Treat any unexpected Application permission grant as critical regardless of whether the credential was used yet.
I2Audit SP Activity During Compromised WindowKQL
KQL — What did the SP do after the credential was added?
// SP activity via Azure ARM (AzureActivity) and MS Graph (AADServicePrincipalSignInLogs)
let sp_name = "TargetSPName";
let cred_add_time = datetime(2026-06-21T00:00:00Z);
AADServicePrincipalSignInLogs
| where TimeGenerated > cred_add_time
| where ServicePrincipalName == sp_name
| project TimeGenerated, IPAddress, Location, ResourceDisplayName, ServicePrincipalName
Check Azure Key Vault diagnostic logs (AzureDiagnostics where ResourceProvider == "MICROSOFT.KEYVAULT") for any secrets or keys read by the SP after the credential was added. Key Vault reads indicate the attacker is harvesting credentials for further lateral movement.
03
Containment
STOP ITC1Remove Malicious Credential & Disable SPImmediate
- 1Remove the malicious credential: Entra ID → App registrations → [SP] → Certificates and secrets → Delete only the attacker-added credential (verify key ID and creation date). Do not rotate legitimate credentials yet.
- 2If active SP session is in progress: Entra ID → Enterprise applications → [SP] → Disable application (prevents any new token issuance). Re-enable after cleanup.
- 3Revoke existing SP tokens: Azure AD does not have a direct "revoke SP tokens" button — disabling the SP and re-enabling after removing the credential effectively flushes active tokens when the next API call fails validation.
- 4Remove dangerous API permissions if any were added by the attacker: App registrations → [SP] → API permissions → Remove any non-approved permissions.
04
Eradication
CLEAN UPE1Full SP Inventory & Hardening
- 1Audit all app registrations for credentials added in the last 30 days: Entra ID → App registrations → All applications → sort by modified date. Any secret/cert not tied to a change ticket is suspect.
- 2Rotate all legitimate secrets on the affected SP to ensure the attacker's copy of any credential they may have observed is invalidated.
- 3Verify no new SP or app registration was created by the attacker: AuditLogs → "Add application" — any unknown apps must be deleted.
- 4Enable Workload Identity conditional access: Entra ID → Workload identities → Conditional access — require trusted IP ranges for SP authentication where supported.
- 5Set credential expiry policy: enforce maximum 90-day expiry on all client secrets. Long-lived secrets (1 or 2 years) give attackers extended persistence windows.
Eradication Complete When
- Malicious credential removed; all remaining credentials confirmed legitimate
- No unknown app registrations present
- SP activity log clean — no ARM or Graph calls from attacker IP post-removal
- Legitimate credentials rotated to invalidate any copied secrets
- Workload identity CA policies enforced
05
Escalation
TIERSESC1Escalation Tiers
| Tier | Trigger | Action |
|---|---|---|
| L1 → L2 | Credential added, not yet used, low-privilege SP (no Application permissions for sensitive scopes) | Remove credential, document SP name, initiator, creation time, escalate for review of initiator account |
| L2 → IR + CISO | SP had Mail.ReadWrite.All / Directory.ReadWrite.All / Files.ReadWrite.All; credential was used to sign in; Key Vault reads detected | Full data exposure assessment. Legal notification assessment. Engage CISO. Audit all tenant resources the SP touched. |
| IR → Security Engineering | Multiple SPs compromised; CI/CD pipeline injects secrets via compromised pipeline credentials | Pipeline credential rotation. Secret scanning in DevOps repos. Workload identity federation migration. |
Authorized security research & penetration testing only. Unauthorized use is illegal. Authored by Rudra Verma | Senior Security Architect | CyberHawk Consultancy.