Agent Foskett Academy • SOC Analyst Academy • Module 3 • Lesson 30 • Identity Incidents

Lesson 30 — From Suspicious Sign-In to Identity Compromise

The first clue was a successful sign-in.

Then came repeated MFA prompts. A new authentication method appeared. Conditional Access reported success. A privileged role became active. An OAuth application gained broader access. A service principal began acting outside its normal purpose.

None of those events told the whole story alone.

The investigation only became clear when Agent Foskett built one timeline and asked: what changed, what persisted and what did the attacker gain?

Identity compromise is rarely one event. The analyst's job is to connect authentication, persistence, privilege and activity into one defensible story.

Build the Complete Timeline Back to SOC Analyst Academy

Agent Foskett SOC Analyst Academy building a complete Microsoft Entra identity compromise timeline

The timeline finally made sense

Module 3 brings together sign-ins, MFA, Conditional Access, privilege, sessions, OAuth consent and application identities into one incident narrative.

✓ Establish the initial access path

✓ Identify persistence and privilege

✓ Follow user and application activity

✓ Produce a defensible incident finding

Case briefing

07:42 — SUCCESSFUL SIGN-IN Unfamiliar source 07:43–07:48 — REPEATED MFA ACTIVITY 07:55 — NEW AUTHENTICATION METHOD 08:04 — CONDITIONAL ACCESS SUCCESS 08:17 — PRIVILEGED ROLE ACTIVATED 08:26 — UNUSUAL CLOUD SESSION ACTIVITY 08:31 — OAUTH CONSENT 08:39 — SERVICE PRINCIPAL CHANGE 08:47 — PRIVILEGED APPLICATION ACTIVITY THE WRONG WAY TO READ THIS "Nine unrelated events." THE SOC WAY "One identity-compromise timeline."

Investigation objective

Reconstruct the complete identity incident, determine the initial access path, identify persistence and privilege, scope the affected identities and applications, and produce a clear containment decision.

Investigator's rule

Build the timeline before building the conclusion. Correlation is strongest when each claim can be traced back to an event, entity and timestamp.

Stage 1 — define the identity incident

Investigation question	Evidence source
How did access begin?	SigninLogs, MFA context, authentication details
Was MFA abused?	Repeated authentication attempts and user confirmation
Was persistence created?	Authentication-method changes, OAuth grants, application credentials
Was privilege obtained?	PIM and role-management audit activity
What did the session do?	CloudAppEvents and other activity telemetry
Did application identities become involved?	AuditLogs, service principals and application-management events

Start with scope

List the users, applications, service principals, IP addresses, devices and privileged roles already connected to the incident. These entities define the first investigation boundary.

Do not let the first alert define the incident

The original sign-in alert may only be the entry point. Scope should expand as new evidence connects additional identities and resources.

Stage 2 — rebuild the authentication story

12345 678910 1112131415 161718

let TargetUser = "s.bennett@contoso.com";
SigninLogs
| where TimeGenerated > ago(24h)
| where UserPrincipalName =~ TargetUser
| project TimeGenerated,
          UserPrincipalName,
          IPAddress,
          Location,
          AppDisplayName,
          ClientAppUsed,
          ResultType,
          ResultDescription,
          AuthenticationRequirement,
          AuthenticationDetails,
          ConditionalAccessStatus,
          DeviceDetail
| order by TimeGenerated asc

Anchor on the first confirmed event

Start with the earliest event you can confidently place in the incident. Then move forward and backward in time to test whether earlier preparation or later persistence exists.

Authentication context changes the interpretation

A successful sign-in after repeated MFA prompts or from an unfamiliar source carries a different meaning from a routine successful sign-in.

Stage 3 — layer in identity changes

12345 678910 11121314

let TargetUser = "s.bennett@contoso.com";
AuditLogs
| where TimeGenerated > ago(24h)
| where tostring(InitiatedBy) has TargetUser
   or tostring(TargetResources) has TargetUser
| project TimeGenerated,
          OperationName,
          Category,
          Result,
          InitiatedBy,
          TargetResources,
          AdditionalDetails,
          CorrelationId
| order by TimeGenerated asc

Ask what changed after access

New authentication methods, role activation, OAuth consent and application changes can all represent persistence or privilege rather than simple post-login activity.

Not every change is malicious

Use helpdesk records, change windows, user validation and administrative context to test legitimate explanations for each identity change.

Stage 4 — follow the live session

INITIAL ACCESS ↓ AUTHENTICATION ↓ IDENTITY CHANGE ↓ PRIVILEGE ↓ SESSION ACTIVITY ↓ APPLICATION ACCESS ↓ PERSISTENCE ↓ IMPACT THE TIMELINE SHOULD EXPLAIN HOW ONE STAGE ENABLED THE NEXT.

Activity reveals attacker intent

Sign-ins explain access. Post-authentication actions reveal what the identity or application actually tried to achieve.

Look across human and non-human identities

The incident may begin with a user account and later move into OAuth applications or service principals. Do not stop the investigation at the human identity boundary.

Stage 5 — build the complete attack chain

1. INITIAL ACCESS Suspicious successful sign-in ↓ 2. MFA ABUSE Repeated prompts / unusual approval ↓ 3. PERSISTENCE New authentication method ↓ 4. POLICY PASS Conditional Access requirements satisfied ↓ 5. PRIVILEGE Role activation ↓ 6. SESSION ABUSE Unusual cloud activity ↓ 7. APPLICATION ACCESS OAuth consent ↓ 8. NON-HUMAN IDENTITY Service principal activity ↓ 9. IMPACT Directory / data / security changes

One weak signal can become strong in sequence

A new MFA method, OAuth consent or role activation may each have legitimate explanations. When they occur in one suspicious timeline, the combined story becomes much stronger.

Chronology protects you from confirmation bias

By writing events in time order, the analyst is less likely to ignore facts that do not fit the first theory.

Stage 6 — identify containment requirements

Compromise element	Potential containment action
User credentials	Reset or protect credentials according to incident process.
Active sessions	Revoke sessions and tokens where appropriate.
Authentication methods	Remove unauthorised methods and require secure re-registration.
Privileged roles	Deactivate unexpected elevation and review affected administrative changes.
OAuth consent	Revoke suspicious grants and review the service principal.
Application credentials	Remove unexpected credentials and rotate legitimate secrets or certificates.
Changed security controls	Restore approved configuration and validate no additional persistence remains.

Contain every access path

Changing a password while leaving active sessions, new MFA methods or malicious OAuth access intact can leave the incident unresolved.

Containment and investigation run together

Preserve enough evidence to explain what happened, while taking proportionate action to prevent further impact.

Stage 7 — test the final hypothesis

WORKING HYPOTHESIS The identity was compromised through suspicious authentication. The attacker maintained access through identity and application changes. Privilege and cloud access were then used to expand the incident. ↓ TEST AGAINST ALL EVIDENCE What supports this? What contradicts it? What remains unknown? What alternative explanation survives? ↓ ONLY THEN WRITE THE VERDICT.

Separate facts from interpretation

“A role became active at 08:17” is a fact. “The attacker activated the role” is an interpretation that must be supported by the surrounding evidence.

Document uncertainty

A defensible finding can include unresolved questions. Do not invent certainty where telemetry does not support it.

Stage 8 — make the SOC decision

DEFINE INCIDENT SCOPE ↓ RECONSTRUCT AUTHENTICATION ↓ ADD MFA + CA CONTEXT ↓ ADD IDENTITY CHANGES ↓ ADD PRIVILEGE ↓ FOLLOW SESSION ACTIVITY ↓ ADD OAUTH / SERVICE PRINCIPALS ↓ ASSESS PERSISTENCE + IMPACT ↓ TEST ALTERNATIVE EXPLANATIONS ↓ CONTAIN ↓ DOCUMENT ↓ ESCALATE / CLOSE / MONITOR

The strongest identity investigation is not the one with the most alerts. It is the one where every conclusion can be traced back to evidence.

Write the final investigation finding

IDENTITY INCIDENT FINDING A successful sign-in for s.bennett@contoso.com began the confirmed incident timeline. The authentication was followed by repeated MFA activity, a newly registered authentication method and subsequent privileged access. Conditional Access requirements were satisfied, but the resulting session generated activity inconsistent with the user's normal baseline. OAuth consent and service-principal changes expanded the incident beyond the original human identity. DECISION Treat as confirmed identity compromise and perform coordinated containment across user, session, privilege and application access. REASON Multiple independent identity signals form one consistent attack chain from initial access through persistence, privilege and application abuse. Each conclusion is supported by timestamped authentication, audit and cloud activity.

Lesson 30 key takeaways

Identity compromise should be investigated as a timeline, not a collection of isolated alerts.
Start with the earliest confirmed event and expand scope as new entities become connected.
Combine SigninLogs, AuditLogs and cloud activity to explain access, change and behaviour.
MFA success and Conditional Access success are context, not final security verdicts.
Authentication-method changes can create identity persistence.
Privileged role activation changes both impact and investigative priority.
OAuth grants and service principals can extend compromise beyond the original user account.
Contain every access path, not only the password.
Separate observed facts from analyst interpretation.
A defensible incident finding explains what happened, why it matters and which evidence supports the conclusion.

Module 3 complete — Identity Incidents

You have now followed identity incidents from suspicious sign-in through MFA abuse, authentication-method changes, Conditional Access, privilege, session behaviour, OAuth consent and application identity compromise.

Module 3 complete — 10 identity investigation lessons finished.

Continue your SOC Analyst training

Module 3 focuses on identity incidents, authentication, MFA, privilege, sessions and application access.

SOC Analyst Academy KQL Academy Microsoft Sentinel Academy Defender for Endpoint Academy Microsoft Entra Security Academy Security Copilot Academy Agent Foskett Academy

🔎 SOC Analyst Academy — Module 3: Identity Incidents

Module 3 complete — from suspicious authentication through persistence, privilege, session abuse and application identity compromise.

← Previous lesson

Lesson 29 — The Service Principal Started Acting Like an Administrator Investigate unexpected application identity privilege and activity.

✅ Current lesson

Lesson 30 — From Suspicious Sign-In to Identity Compromise Bring the complete Module 3 identity investigation workflow together.

Module complete →

Return to SOC Analyst Academy Review the roadmap and continue to the next published SOC investigation module when available.

How to investigate a complete Microsoft Entra identity compromise

Lesson 30 of the Agent Foskett SOC Analyst Academy teaches analysts how to combine sign-ins, MFA, Conditional Access, authentication-method changes, privileged access, sessions, OAuth consent and service-principal activity into one complete identity-compromise timeline.

KQL identity investigation using SigninLogs, AuditLogs and cloud activity

Learn how SOC analysts correlate Microsoft Entra authentication and audit telemetry with cloud activity to identify initial access, persistence, privilege, application abuse and containment requirements.