Service Principal Credential Compromise Response
Service principal credential compromise response maps added credentials, token issuance, permissions, resource access, persistence, containment, and recovery.
Open the case with an authority snapshot
Service principal credential compromise response begins by freezing the identity’s current meaning: application and service-principal object IDs, tenant, owners, credential inventory, federated identity credentials, API permissions and consent, directory and cloud roles, resource assignments, redirect URIs, expected workloads, and business owner.
MITRE ATT&CK T1098.001 describes adversaries adding secrets or certificates to preserve access. Do not assume the known leaked secret is the only unauthorized credential.
Build two interleaved timelines: configuration and use
Configuration timeline: creation, owner changes, credential additions and removals, permission consent, role assignments, redirect or federation changes, and disablement. Use timeline: token requests, sign-in result, credential type, source, resource, scope or role, API calls, and data access.
Microsoft’s application security operations guidance recommends monitoring added credentials, long lifetimes, privileged permissions, roles, and owner changes. Join identity tokens and sessions to resource audit; authentication success alone does not show what the token did.
Test competing explanations for every new credential
Hypothesis A: expected rotation by approved automation. B: emergency manual recovery. C: accidental duplicate. D: malicious persistence after administrator compromise. Compare initiator, change path, ticket, timing, lifetime, credential type, owner, source, subsequent token issuance, and target resources.
Raise confidence for credential additions outside the normal pipeline, unfamiliar initiators, long expiry, privileged applications, owner changes, immediate cross-resource use, or a credential added by an identity with less privilege than the application it captures.
Choose containment from dependency criticality and attacker activity
If active abuse or high privilege is confirmed, block sign-in or disable the identity through a trusted administrator, remove unauthorized credentials and federation, revoke sessions or tokens where supported, and restrict resource access. For critical workloads, prepare a clean replacement identity and narrow temporary permissions before cutover.
Preserve credentials as identifiers, never plaintext; capture audit old/new values and downstream logs. Rotate legitimate secrets through secrets management, remove excess owners and consent, and hunt the initiator across other applications.
Prove recovery through denied old credentials and expected new use
Verify every unauthorized credential and role is gone, old credentials fail, the clean workload authenticates only from expected infrastructure, permissions match the principle of least privilege, and downstream access returns to baseline. Review consent and owners separately from credentials.
Close the case with an authority diff
Next step: choose one non-production service principal. Export its authority snapshot, add an approved disposable credential through the normal pipeline, observe audit and sign-in evidence, remove it, prove it fails, and produce a before/after diff. Label the drill; never expose the secret in logs or source control.
Frequently asked questions
Is rotating the suspected client secret enough?
No. Attackers can add another credential, obtain tokens, change owners or permissions, and access resources. Inventory every credential and persistence path, revoke authority, and investigate downstream use.
Should a compromised service principal always be deleted immediately?
Not always. Deletion may disrupt critical services and destroy context. When safe, disable or block access, preserve configuration and logs, then recover or replace deliberately.
