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

Lesson 21 — The Successful Sign-In Wasn't Normal

The authentication result said Success.

The password worked. MFA was satisfied. Conditional Access did not block the session. If the analyst looked only at the result code, there was nothing to investigate.

But the user normally signed in from Melbourne on a managed Windows laptop. This session appeared from an unfamiliar location, used a different client and was followed by activity the user had never performed before.

Successful authentication proves that access was granted. It does not prove that the person receiving access was legitimate.

Investigate the Sign-In Back to SOC Analyst Academy

Agent Foskett SOC Analyst Academy investigating a suspicious successful sign-in

Success was only one field

The verdict depends on the wider sign-in story: identity, location, application, device, authentication and what happened next.

✓ Establish the user's baseline

✓ Compare sign-in context

✓ Inspect authentication details

✓ Follow post-authentication activity

Case briefing

07:42 — SUCCESSFUL SIGN-IN USER s.bennett@contoso.com RESULT Success APPLICATION Microsoft 365 SOURCE Unfamiliar IP address LOCATION Not normally observed for this user DEVICE No familiar managed-device context AUTHENTICATION MFA satisfied 15 MINUTES LATER Unusual mailbox activity THE EASY VERDICT "Sign-in succeeded." THE SOC QUESTION "Was this successful sign-in normal for this identity?"

Investigation objective

Investigate successful authentication by comparing the event with the user's normal sign-in behaviour and examining what happened before and after access was granted.

Investigator's rule

Success is an authentication outcome, not a security verdict. Always interpret it with identity, device, location, application and session context.

Stage 1 — establish what normal looks like

Baseline field	Normal pattern	Current sign-in
Location	Melbourne / Victoria	Unfamiliar location
Device	Managed Windows laptop	No familiar managed-device context
Application	Microsoft 365 applications	Microsoft 365
Authentication	Password + MFA	MFA satisfied
Typical hours	Business hours	07:42
Follow-on activity	Normal mailbox usage	Unusual mailbox activity

One anomaly is rarely enough

A user can travel, replace a device or work unusual hours. The investigation becomes stronger when several independent contextual differences appear together.

Baseline the identity, not the organisation

What is normal for an administrator, salesperson and finance user may be completely different. Compare the sign-in with the behaviour of the specific identity whenever possible.

Stage 2 — reconstruct recent sign-ins with KQL

Start with the identity and compare the suspicious event against recent successful and failed authentication activity.

12345 678910 1112131415 16

let TargetUser = "s.bennett@contoso.com";
SigninLogs
| where TimeGenerated > ago(7d)
| where UserPrincipalName =~ TargetUser
| project TimeGenerated,
          UserPrincipalName,
          IPAddress,
          Location,
          AppDisplayName,
          ClientAppUsed,
          ResultType,
          ResultDescription,
          ConditionalAccessStatus
| order by TimeGenerated desc

Look before the success

Failed attempts immediately before a successful sign-in can materially change the story. The successful event may be the end of an authentication sequence rather than the beginning.

Look beyond the IP address

An unfamiliar IP is a lead, not proof. Location, client, device context, authentication details and subsequent behaviour help determine whether it matters.

Stage 3 — build the authentication sequence

07:31 Failed sign-in Unfamiliar source ↓ 07:34 Failed sign-in Same source ↓ 07:38 Failed sign-in Same source ↓ 07:42 SUCCESS MFA satisfied ↓ 07:49 New mailbox activity ↓ 07:57 Unusual access pattern THE SUCCESSFUL SIGN-IN NOW HAS A HISTORY.

MFA success requires interpretation

MFA being satisfied is important evidence, but it does not automatically resolve who controlled the session. The analyst still needs to understand the authentication method and surrounding behaviour.

Do not jump straight to compromise

Suspicious context raises the priority of the investigation. It does not remove the need to test legitimate explanations such as travel, approved remote access or a changed device.

Stage 4 — compare source patterns

12345 678910 11121314

let TargetUser = "s.bennett@contoso.com";
SigninLogs
| where TimeGenerated > ago(30d)
| where UserPrincipalName =~ TargetUser
| summarize
    SignInCount=count(),
    FirstSeen=min(TimeGenerated),
    LastSeen=max(TimeGenerated)
    by IPAddress,
       Location,
       AppDisplayName,
       ClientAppUsed
| order by LastSeen desc

First-seen context matters

A source combination that has never appeared in the user's recent history deserves closer inspection, especially when other anomalies occur at the same time.

Baselines are evidence, not rules

Thirty days of history can tell you what has been observed. It cannot prove that anything new is malicious. Use the baseline to focus the investigation.

Stage 5 — follow what happened after authentication

SUCCESSFUL AUTHENTICATION ↓ WHAT DID THE SESSION DO? NORMAL ACTIVITY? ↓ Supports legitimate explanation OR NEW INBOX RULE? UNUSUAL FILE ACCESS? OAUTH CONSENT? PRIVILEGE CHANGE? NEW MFA METHOD? UNUSUAL CLOUD ACTIVITY? ↓ Strengthens compromise hypothesis AUTHENTICATION IS NOT THE END OF THE TIMELINE.

Post-authentication behaviour can be decisive

If a suspicious sign-in is followed by behaviour the user has never performed before, the combined evidence can be substantially stronger than the sign-in anomaly alone.

Keep the timeline chronological

Do not start with the conclusion and search only for supporting evidence. Record what happened before, during and after the authentication event in time order.

Stage 6 — test competing explanations

Hypothesis	Evidence to test
User travelling	Travel context, known device, expected applications, user validation.
Approved VPN / proxy	Known corporate egress, expected client and historical use.
New legitimate device	Device registration, management state and user confirmation.
Credential compromise	Preceding failures, unfamiliar source, abnormal session activity and identity changes.
Session / token abuse	Authentication details, session behaviour and activity inconsistent with normal interactive use.

Stage 7 — make the triage decision

SUCCESSFUL SIGN-IN ↓ COMPARE WITH USER BASELINE ↓ CHECK PRECEDING AUTHENTICATION ↓ VALIDATE LOCATION / DEVICE / CLIENT ↓ UNDERSTAND MFA / CA CONTEXT ↓ FOLLOW POST-SIGN-IN ACTIVITY ↓ TEST LEGITIMATE EXPLANATIONS ↓ CORRELATE EVIDENCE ↓ CLOSE / CONTINUE / ESCALATE / CONTAIN

A suspicious successful sign-in is investigated as a timeline, not as a single row in a log.

Write the investigation finding

IDENTITY TRIAGE FINDING A successful sign-in for s.bennett@contoso.com occurred at 07:42. The event differed from the user's recent baseline in source location and familiar device context. Three failed sign-ins from the same unfamiliar source preceded the successful authentication. The successful session was followed by unusual mailbox activity not observed in the user's normal pattern. MFA was satisfied; however, this fact alone does not explain the abnormal source and follow-on activity. DECISION Escalate the identity incident for further investigation and assess whether active sessions require revocation. REASON Multiple independent contextual anomalies form a stronger compromise hypothesis than the successful authentication result alone.

Lesson 21 key takeaways

A successful sign-in is an authentication result, not proof of legitimate user activity.
Compare suspicious authentication with the normal behaviour of the specific identity.
Location, IP address, device, client application and authentication context should be evaluated together.
Failed attempts before a successful sign-in can materially change the interpretation.
MFA satisfaction is important evidence but does not automatically end the investigation.
Unfamiliar IP addresses are leads, not standalone verdicts.
Use KQL to reconstruct the user's recent sign-in timeline and source baseline.
Follow the session after authentication to identify unusual mailbox, cloud, privilege or application activity.
Test legitimate explanations instead of searching only for evidence of compromise.
Make the final decision from the complete identity timeline.

Module 3 — Identity Incidents

Module 3 begins with one of the most important identity-investigation lessons: successful authentication can still be suspicious. Next, Agent Foskett investigates a user who received twelve MFA prompts.

Next: Lesson 22 — The User Received Twelve MFA Prompts

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 and follow identity activity beyond the sign-in result.

← Previous lesson

Lesson 20 — Building a Repeatable SOC Triage Workflow Turn individual triage skills into a consistent operational process.

✅ Current lesson

Lesson 21 — The Successful Sign-In Wasn't Normal Investigate successful authentication when the surrounding context is suspicious.

Next lesson

Lesson 22 — The User Received Twelve MFA Prompts Investigate MFA fatigue and repeated authentication attempts.

How to investigate a suspicious successful Microsoft Entra sign-in

Lesson 21 of the Agent Foskett SOC Analyst Academy teaches analysts how to investigate successful authentication by comparing location, device, client, application and authentication context with the user's normal sign-in behaviour.

KQL investigation of successful sign-ins and identity incidents

Learn how to use Microsoft Entra SigninLogs and KQL to reconstruct authentication timelines, identify unfamiliar sign-in patterns, review preceding failures and determine whether post-authentication activity supports escalation or containment.