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

Lesson 27 — The Sign-In Was Successful but the Session Wasn't Normal

The authentication event looked normal enough.

The user signed in successfully. MFA was satisfied. Conditional Access allowed access. But the session that followed immediately began doing things the user had never done before.

Files were accessed in unusual locations. New cloud actions appeared. The activity pattern did not match the user's baseline.

The sign-in succeeded. The session was the clue.

A legitimate-looking sign-in can still produce a compromised session. Follow what happened after authentication.

Investigate the Session Back to SOC Analyst Academy

Agent Foskett SOC Analyst Academy investigating a successful sign-in followed by abnormal session activity

The session changed the verdict

The analyst must compare the authenticated session with the user's normal activity and determine whether token theft, session hijacking or account compromise better explains the behaviour.

✓ Establish the sign-in context

✓ Follow post-authentication activity

✓ Compare the session with the user's baseline

✓ Test session-hijack and compromise hypotheses

Case briefing

11:04 — SUCCESSFUL SIGN-IN USER s.bennett@contoso.com MFA Satisfied CONDITIONAL ACCESS Success 11:09 — FILE ACCESS Unusual SharePoint location 11:13 — CLOUD ACTIVITY Application not normally used 11:17 — MORE FILE ACCESS Unusual volume 11:21 — SESSION CONTINUES THE EASY VERDICT "Authentication succeeded." THE SOC QUESTION "Does the activity after sign-in look like this user?"

Investigation objective

Determine whether the post-authentication session is consistent with legitimate user behaviour or whether the account, token or session may have been compromised.

Investigator's rule

Authentication is only the beginning of the session timeline. Always follow what the identity does after access is granted.

Stage 1 — establish the sign-in context

Field	Observed	Question
Result	Success	What happened immediately afterwards?
MFA	Satisfied	How was MFA satisfied?
Conditional Access	Success	Which controls were applied?
Device	Known browser	Was the session token reused elsewhere?
Source	Expected location	Does later activity remain consistent with this source?

Normal authentication can still lead to abnormal activity

A session can become suspicious after a perfectly ordinary sign-in. Token theft, session hijacking, malicious browser activity or compromised applications can all change the story after authentication.

Baseline the user, not just the event

Ask what applications, repositories, file volumes and cloud actions are normal for this identity. Session behaviour becomes meaningful when compared with that baseline.

Stage 2 — reconstruct the sign-in timeline with KQL

Start with the authentication event and record the identity, source, application, client and access-control context.

12345 678910 1112131415

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

Capture the session anchor

The sign-in event gives you the starting point for the investigation. Record the exact time and use it to search for cloud activity immediately afterwards.

Do not over-trust familiar context

A familiar location or browser does not prove the session is safe. Compromised tokens and session artefacts can make later activity appear closer to normal than expected.

Stage 3 — follow post-authentication cloud activity

Use cloud activity telemetry to examine what the identity did after the sign-in.

12345 678910 11121314

let TargetUser = "s.bennett@contoso.com";
CloudAppEvents
| where Timestamp > ago(24h)
| where AccountDisplayName =~ TargetUser
   or AccountId =~ TargetUser
| project Timestamp,
          Application,
          ActionType,
          IPAddress,
          DeviceType,
          ObjectName,
          RawEventData
| order by Timestamp asc

Look for new applications

An application the user has never accessed before can be an important clue, especially when it appears minutes after authentication.

Look for unusual volume

Large numbers of file reads, downloads or object accesses can indicate collection or exfiltration even when each individual action appears legitimate.

Stage 4 — compare the session with the user's normal pattern

SUCCESSFUL SIGN-IN ↓ NORMAL SOURCE / MFA / CA ↓ SESSION ACTIVITY ↓ NEW APPLICATION? UNUSUAL FILE LOCATION? ABNORMAL VOLUME? UNEXPECTED ADMIN ACTION? NEW OAUTH CONSENT? IMPOSSIBLE DEVICE CONTEXT? ↓ COMPARE WITH USER BASELINE ↓ NORMAL SESSION OR COMPROMISED SESSION?

Session baselines can be stronger than sign-in baselines

Some users sign in from many locations and devices, but their application and file-access patterns remain consistent. Behaviour after sign-in may therefore provide the stronger signal.

One unusual action may still be legitimate

A user can access a new file or application for a genuine reason. Confidence increases when several independent session anomalies appear together.

Stage 5 — test session-compromise hypotheses

Hypothesis	Evidence to test
Legitimate unusual work	User confirmation, expected business task and activity consistent with the stated reason.
Compromised account	Suspicious authentication history plus abnormal session activity.
Token or session hijacking	Normal sign-in followed by session behaviour inconsistent with device, source or user baseline.
Malicious OAuth/application activity	Unexpected consent, application access or cloud actions after authentication.
Automated background service	Known application, expected service behaviour and historical recurrence.

Stage 6 — decide whether containment is required

ABNORMAL SESSION CONFIRMED ↓ REVOKE ACTIVE SESSIONS? ↓ RESET / PROTECT CREDENTIALS? ↓ REVIEW MFA METHODS? ↓ REMOVE MALICIOUS CONSENT? ↓ CHECK MAILBOX / FILE / CLOUD CHANGES? ↓ MONITOR FOR RE-ENTRY?

Password reset may not be enough

If the problem involves an active token or session, credential remediation alone may not terminate access. Session revocation and application review can be essential.

Follow every durable change

If the session created mailbox rules, OAuth grants, new authentication methods or privilege changes, those artefacts must be investigated and remediated separately.

Stage 7 — make the SOC decision

SUCCESSFUL SIGN-IN ↓ ESTABLISH SESSION ANCHOR ↓ FOLLOW CLOUD ACTIVITY ↓ COMPARE WITH USER BASELINE ↓ CHECK APP / FILE / VOLUME / ACTIONS ↓ TEST TOKEN / SESSION HYPOTHESES ↓ VALIDATE LEGITIMATE EXPLANATIONS ↓ ASSESS PERSISTENCE + IMPACT ↓ CLOSE / CONTINUE / ESCALATE / CONTAIN

The authentication event may look normal while the session tells a completely different story.

Write the investigation finding

IDENTITY TRIAGE FINDING A successful sign-in occurred for s.bennett@contoso.com at 11:04. MFA was satisfied and Conditional Access reported Success. Within minutes, the resulting session accessed SharePoint content not normally used by the identity and generated an unusual volume of cloud activity. The activity pattern was inconsistent with the user's recent baseline. DECISION Escalate and contain the identity session. REASON The authentication event appears legitimate in isolation, but the post-authentication behaviour is inconsistent with the user and supports a compromised-session hypothesis.

Lesson 27 key takeaways

A successful sign-in does not guarantee the resulting session is legitimate.
Use the authentication event as the anchor for a wider session timeline.
Follow cloud activity immediately after access is granted.
Compare session behaviour with the specific user's normal applications and data access.
New applications, unusual file locations and abnormal volume can strengthen the compromise hypothesis.
Familiar sign-in context does not rule out token theft or session hijacking.
Use SigninLogs and CloudAppEvents together to follow identity activity beyond authentication.
Test legitimate business explanations before escalating.
Credential resets may need to be combined with session revocation and application remediation.
The session can be more revealing than the sign-in.

Module 3 — Identity Incidents

Lesson 27 follows identity activity beyond authentication and into the live cloud session. Next, Agent Foskett investigates an OAuth application that had more access than expected.

Next: Lesson 28 — The OAuth Application Had More Access Than Expected

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

Investigate suspicious authentication, session behaviour and identity activity across Microsoft Entra and cloud telemetry.

← Previous lesson

Lesson 26 — The Same IP Address Touched Five Accounts Correlate one source across multiple identities.

✅ Current lesson

Lesson 27 — The Sign-In Was Successful but the Session Wasn't Normal Follow suspicious identity activity beyond successful authentication.

Next lesson

Lesson 28 — The OAuth Application Had More Access Than Expected Investigate consent, permissions and application access.

How to investigate a suspicious Microsoft Entra session after successful sign-in

Lesson 27 of the Agent Foskett SOC Analyst Academy teaches analysts how to investigate abnormal post-authentication behaviour, compare cloud activity with user baselines and determine whether a session may have been hijacked or compromised.

KQL investigation of sign-ins and CloudAppEvents

Learn how to use Microsoft Entra SigninLogs and Microsoft Defender XDR CloudAppEvents with KQL to reconstruct a session timeline, follow post-authentication activity and identify unusual application, file and cloud behaviour.