ACSC Logo
© 2026 GEMXIT
GEMXIT Logo
Agent Foskett Academy • Lesson 108 • Hunting Playbook Series

Hunting Playbook: Risky Sign-ins in Microsoft Defender XDR.

The sign-in succeeded.

The password was correct. MFA may have passed. The user reached Microsoft 365.

But Microsoft still marked the activity as risky.

Agent Foskett knew the alert was not the whole investigation. Risky sign-ins must be tested against identity telemetry, user behaviour, IP addresses, device context and the timeline before defenders decide whether the account is genuinely compromised.

Start Lesson 108 Back to Academy
Agent Foskett Academy lesson hunting risky sign-ins in Microsoft Defender XDR
Lesson overview

Learn how to investigate risky sign-ins by correlating Microsoft Defender XDR, Microsoft Entra ID identity telemetry, risk signals, authentication patterns, IP addresses and user behaviour.

Review risky identity activity
Compare locations, IPs and devices
Separate false positives from compromise
Build a clear sign-in timeline

Why risky sign-ins matter

A risky sign-in is not proof of compromise, but it is a strong signal that identity behaviour has drifted away from normal expectations.
Risk needs contextRisk detections should be validated against user behaviour, device context, network location, authentication method and surrounding activity.
Successful access can still be dangerousA successful sign-in can be suspicious when it appears from unusual infrastructure, impossible geography or unfamiliar device context.
Identity investigations need timelinesThe best risky sign-in investigations reconstruct what happened before, during and after authentication.

The risky sign-in hunting workflow

Agent Foskett treats risky sign-ins as an investigation path, not just an alert to accept or dismiss.
1. Identify the risky eventStart with the user, timestamp, IP address, location, device name and action result that triggered concern.
2. Review recent sign-insCompare the risky event with the user's normal sign-in pattern across the last few days.
3. Analyse locations and IPsLook for new countries, unexpected cities, anonymising services, unfamiliar ASNs or suspicious hosting providers.
4. Check authentication contextReview MFA, failure reasons, authentication methods and whether the sign-in succeeded after suspicious failures.
5. Correlate Defender evidencePivot into alerts, cloud activity, email activity and endpoint context to determine what happened after access.
6. Decide the responseReset credentials, revoke sessions, review MFA methods, block risky locations or escalate the incident when compromise is likely.

Step 1 — Review recent risky sign-ins

Start by collecting recent sign-in activity that contains risk-related language or suspicious identity outcomes.
step-1-review-risky-signins.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
let TimeFrame = 7d;
IdentityLogonEvents
| where Timestamp > ago(TimeFrame)
| where ActionType has_any ("risk", "suspicious", "unfamiliar", "failed", "success")
| project Timestamp,
          AccountUpn,
          ActionType,
          IPAddress,
          Location,
          DeviceName,
          FailureReason
| order by Timestamp desc

Step 2 — Build a user sign-in timeline

A timeline helps determine whether the risky sign-in is isolated or part of a wider authentication pattern.
step-2-user-signin-timeline.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
let TimeFrame = 14d;
let UserToInvestigate = "user@contoso.com";
IdentityLogonEvents
| where Timestamp > ago(TimeFrame)
| where AccountUpn =~ UserToInvestigate
| project Timestamp,
          AccountUpn,
          ActionType,
          IPAddress,
          Location,
          DeviceName,
          FailureReason
| order by Timestamp asc

Step 3 — Summarise countries and IP addresses

Summaries quickly reveal whether a user is authenticating from unusual locations or too many IP addresses.
step-3-summarise-locations-and-ips.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
let TimeFrame = 14d;
IdentityLogonEvents
| where Timestamp > ago(TimeFrame)
| summarize SignInCount = count(),
            Countries = make_set(Location, 20),
            IPAddresses = make_set(IPAddress, 50),
            Devices = make_set(DeviceName, 20),
            FirstSeen = min(Timestamp),
            LastSeen = max(Timestamp)
      by AccountUpn
| order by SignInCount desc

Step 4 — Find users with multiple sign-in locations

This pattern helps defenders identify accounts moving between unusual locations during a short period.
step-4-multiple-location-users.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
let TimeFrame = 24h;
IdentityLogonEvents
| where Timestamp > ago(TimeFrame)
| summarize Locations = make_set(Location, 20),
            IPAddresses = make_set(IPAddress, 50),
            DeviceNames = make_set(DeviceName, 20),
            SignInCount = count(),
            FirstSeen = min(Timestamp),
            LastSeen = max(Timestamp)
      by AccountUpn
| where array_length(Locations) > 1
| order by SignInCount desc

Step 5 — Look for suspicious success after failures

Credential attacks often produce failed attempts before a successful sign-in.
step-5-success-after-failures.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
let TimeFrame = 7d;
IdentityLogonEvents
| where Timestamp > ago(TimeFrame)
| summarize FailedAttempts = countif(ActionType has "Failed"),
            SuccessfulAttempts = countif(ActionType has "Success"),
            IPAddresses = make_set(IPAddress, 50),
            Locations = make_set(Location, 20),
            FirstSeen = min(Timestamp),
            LastSeen = max(Timestamp)
      by AccountUpn
| where FailedAttempts > 5 and SuccessfulAttempts > 0
| order by FailedAttempts desc

Step 6 — Correlate risky sign-ins with alerts

A risky sign-in becomes more serious when Defender alerts or evidence appear near the same account and timeframe.
step-6-correlate-with-alerts.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
  18. 18
  19. 19
let TimeFrame = 7d;
let RiskyUsers =
    IdentityLogonEvents
    | where Timestamp > ago(TimeFrame)
    | where ActionType has_any ("risk", "suspicious", "unfamiliar")
    | distinct AccountUpn;
AlertEvidence
| where Timestamp > ago(TimeFrame)
| where AccountName in~ (RiskyUsers)
| project Timestamp,
          AlertId,
          AccountName,
          EntityType,
          EvidenceRole,
          DeviceName,
          RemoteIP
| order by Timestamp desc

Common risky sign-in investigation clues

Risk is strongest when multiple weak signals point in the same direction.
New geographyThe user appears from a country, city or region not seen in their recent sign-in history.
Unfamiliar IP infrastructureSign-ins originate from hosting providers, VPN services, proxies or infrastructure that does not fit normal business activity.
MFA changes or promptsRisky access near MFA registration changes, repeated prompts or unusual authentication methods deserves attention.
Success after repeated failuresA successful sign-in following password guessing attempts can indicate credential theft or password spray activity.
Activity after accessMailbox access, OAuth consent, file downloads or endpoint activity after a risky sign-in can confirm impact.
User denialIf the user does not recognise the session, treat the investigation as potential account compromise until disproven.

False positives to consider

Not every risky sign-in is malicious. Defenders must validate the business context before taking disruptive action.
Legitimate travelUsers may genuinely travel between locations or work while in transit.
Corporate VPNVPN concentrators can make users appear from shared or unexpected regions.
Mobile networksMobile carrier routing can make sign-ins appear from cities or regions that do not match the user location.
Cloud proxiesSecurity gateways, CASB tools and reverse proxies can change the observed source IP or location.
Shared workstationsA device used by multiple staff can blur identity and device context.
Remote supportHelpdesk and managed service actions may create unusual authentication patterns.

Investigation checklist

Use this checklist before closing a risky sign-in investigation.
Was the sign-in successful?A failed risky sign-in may need monitoring, while a successful one requires deeper post-access analysis.
Does the location fit the user?Compare the sign-in location with normal work patterns, travel and VPN use.
Was MFA involved?Confirm whether MFA was challenged, satisfied, bypassed or recently modified.
Was the device familiar?Review device names, browser context and whether the sign-in came from a known endpoint.
What happened next?Check mailbox access, cloud activity, file downloads, OAuth consent and endpoint activity after the risky sign-in.
Is response required?Reset the password, revoke sessions, remove suspicious MFA methods and escalate if compromise is likely.

Related Agent Foskett Academy lessons

These lessons help support risky sign-in investigations.
Hunting Playbook: Impossible TravelUse travel patterns and location analysis to validate suspicious authentication activity.
Hunting Playbook: Credential TheftInvestigate suspicious authentication, token usage and compromised user accounts.
Investigating IdentityLogonEventsUnderstand identity sign-in telemetry inside Microsoft Defender XDR.
Building Reusable Hunting QueriesTurn identity investigation logic into repeatable KQL hunting workflows.
Using arg_max() in KQLFind the latest sign-in event for each account or device.
Hunting Playbook: OAuth AbuseInvestigate persistent access through suspicious application consent and delegated permissions.

Coming next

The Hunting Playbook series continues with insider threat investigations.
Lesson 109 — Hunting Playbook: Insider ThreatsNext, Agent Foskett investigates unusual internal behaviour, suspicious file access, data movement, privilege misuse and signs that a trusted account may be acting outside normal expectations.
Why this mattersRisky sign-ins help defenders identify suspicious access. Insider threat hunting helps determine whether trusted access is being misused after authentication succeeds.

Final thought

Risky sign-ins are not just identity alerts. They are investigation starting points.
Agent Foskett mindsetDo not close the alert because the sign-in succeeded. Ask what made it risky, what happened next, and whether the user behaviour still makes sense.
Hunting Playbook SeriesLesson 108 connects identity risk, sign-in behaviour and Defender XDR evidence into a repeatable investigation workflow.
Develop IT. Protect IT.GEMXIT PTY LTD | GEMXIT UK LTD

Hunting Playbook Risky Sign-ins in Microsoft Defender XDR

Agent Foskett Academy Lesson 108 teaches defenders how to investigate risky sign-ins using Microsoft Defender XDR, Microsoft Entra ID, identity telemetry, authentication behaviour, risk detections and KQL hunting workflows.

Learn risky sign-in hunting with KQL and Microsoft Defender XDR

Risky sign-in investigations help Microsoft security analysts validate suspicious authentication events, review locations, IP addresses, device context, MFA behaviour and post-authentication activity.

Microsoft Entra ID risky sign-in investigation tutorial

This lesson explains how to hunt for risky sign-ins, suspicious successful access, failed authentication patterns, unusual locations and identity risk signals using Microsoft security telemetry.

ACSC Logo

GEMXIT PTY LTD  |  GEMXIT UK LTD  |  © GEMXIT 2026