Agent Foskett Academy • Lesson 101 • Hunting Playbook Series

Hunting Playbook: Impossible Travel in Microsoft Defender XDR.

The account signed in from Melbourne.

Minutes later, it appeared to sign in from another country.

The alert said impossible travel, but Agent Foskett knew the alert was only the start of the investigation.

The real question was whether this was a travelling user, a VPN, cloud routing, mobile network behaviour or a compromised account being used by an attacker.

Start Lesson 101 Back to Academy

Agent Foskett Academy lesson hunting impossible travel in Microsoft Defender XDR

Lesson overview

Learn how to investigate impossible travel by reviewing sign-in telemetry, locations, IP addresses, authentication events, device context and user behaviour across Microsoft Defender XDR and Microsoft Entra ID.

Identify suspicious sign-in geography

Compare locations, IP addresses and timestamps

Separate compromise from false positives

Build a repeatable identity hunting workflow

Why impossible travel matters

Impossible travel is not proof of compromise by itself. It is a signal that asks defenders to validate whether the same user account appears to be active from locations that do not make sense together.

It may indicate credential theftIf a password, session token or authentication cookie is stolen, the attacker may sign in from a different location while the real user continues working normally.

It may be legitimateVPNs, mobile carriers, cloud services, remote access gateways and travelling users can all create location patterns that look suspicious at first glance.

It needs correlationThe answer rarely comes from one event. Defenders need to compare timestamps, IP addresses, authentication details, devices, user behaviour and related alerts.

The impossible travel hunting workflow

Agent Foskett investigates impossible travel by moving from the identity signal to the supporting evidence.

1. Confirm the user and timeframeStart with the account, alert time and sign-in window. Do not assume the alert is correct until the evidence supports it.

2. Review sign-in geographyCompare countries, cities, regions and timestamps to understand whether the activity is physically plausible.

3. Check IP address behaviourLook for VPN providers, hosting networks, anonymisers, unfamiliar ISPs or IP addresses that appear across multiple users.

4. Review authentication contextCheck MFA status, authentication method, failure reasons, conditional access outcomes and whether the sign-in was interactive.

5. Correlate Defender XDR evidencePivot into device, cloud app, email and alert telemetry to determine what happened after the suspicious sign-in.

6. Decide the responseIf compromise is likely, revoke sessions, reset credentials, review MFA methods and investigate mailbox, endpoint and cloud activity.

Step 1 — Review recent sign-ins for the user

Start simple. Establish the account timeline before trying to prove impossible travel.

let TimeFrame = 7d;
let TargetUser = "user@contoso.com";
IdentityLogonEvents
| where Timestamp > ago(TimeFrame)
| where AccountUpn =~ TargetUser
| project Timestamp,
          AccountUpn,
          ActionType,
          IPAddress,
          Location,
          DeviceName,
          FailureReason
| order by Timestamp desc

Step 2 — Summarise sign-ins by location

A location summary helps reveal whether the user has activity across multiple regions during the same investigation window.

let TimeFrame = 7d;
let TargetUser = "user@contoso.com";
IdentityLogonEvents
| where Timestamp > ago(TimeFrame)
| where AccountUpn =~ TargetUser
| summarize SignInCount = count(),
            FirstSeen = min(Timestamp),
            LastSeen = max(Timestamp),
            IPAddresses = make_set(IPAddress, 20),
            Devices = make_set(DeviceName, 20)
      by AccountUpn,
         Location,
         ActionType
| order by LastSeen desc

Step 3 — Look for multiple locations in a short window

This hunt highlights users with sign-ins from multiple locations inside a short investigation period.

let TimeFrame = 24h;
IdentityLogonEvents
| where Timestamp > ago(TimeFrame)
| where ActionType has_any ("LogonSuccess", "Success")
| summarize LocationCount = dcount(Location),
            Locations = make_set(Location, 10),
            IPAddresses = make_set(IPAddress, 20),
            FirstSeen = min(Timestamp),
            LastSeen = max(Timestamp),
            SignInCount = count()
      by AccountUpn
| where LocationCount > 1
| order by LocationCount desc, SignInCount desc

Step 4 — Identify IP addresses shared across users

A suspicious IP that appears across many accounts may point to a proxy, VPN, attacker infrastructure or broad credential abuse.

let TimeFrame = 7d;
IdentityLogonEvents
| where Timestamp > ago(TimeFrame)
| where isnotempty(IPAddress)
| summarize UserCount = dcount(AccountUpn),
            Users = make_set(AccountUpn, 50),
            Locations = make_set(Location, 20),
            FirstSeen = min(Timestamp),
            LastSeen = max(Timestamp)
      by IPAddress
| where UserCount > 5
| order by UserCount desc

Step 5 — Build an impossible travel candidate list

This query creates a reusable starting point for accounts with unusual location diversity and recent successful activity.

let TimeFrame = 48h;
let MinimumLocations = 2;
IdentityLogonEvents
| where Timestamp > ago(TimeFrame)
| where ActionType has_any ("LogonSuccess", "Success")
| summarize SignInCount = count(),
            LocationCount = dcount(Location),
            Locations = make_set(Location, 10),
            IPAddresses = make_set(IPAddress, 20),
            Devices = make_set(DeviceName, 20),
            FirstSeen = min(Timestamp),
            LastSeen = max(Timestamp)
      by AccountUpn
| where LocationCount >= MinimumLocations
| extend InvestigationNote = "Review locations, IP ownership, MFA status and user travel context"
| order by LocationCount desc, SignInCount desc

Step 6 — Correlate identity activity with alerts

If the sign-in is suspicious, check whether Microsoft Defender XDR generated related alerts for the same account.

let TimeFrame = 7d;
let TargetUser = "user@contoso.com";
let IdentityActivity =
    IdentityLogonEvents
    | where Timestamp > ago(TimeFrame)
    | where AccountUpn =~ TargetUser
    | project IdentityTime = Timestamp,
              AccountUpn,
              IPAddress,
              Location,
              ActionType;
let AlertActivity =
    AlertEvidence
    | where Timestamp > ago(TimeFrame)
    | where AccountUpn =~ TargetUser or EntityValue =~ TargetUser
    | project AlertTime = Timestamp,
              AccountUpn,
              EntityValue,
              EvidenceRole,
              DetectionSource;
IdentityActivity
| join kind=leftouter AlertActivity on AccountUpn
| order by IdentityTime desc

Step 7 — Build a clean investigation timeline

A timeline helps defenders explain what happened before and after the suspicious sign-in.

let TimeFrame = 7d;
let TargetUser = "user@contoso.com";
IdentityLogonEvents
| where Timestamp > ago(TimeFrame)
| where AccountUpn =~ TargetUser
| project Timestamp,
          EventType = "Identity sign-in",
          AccountUpn,
          IPAddress,
          Location,
          DeviceName,
          Details = strcat("Action=", ActionType, "; Failure=", FailureReason)
| order by Timestamp asc

Common false positives

VPN and remote access gatewaysCorporate VPNs and remote access platforms can make users appear to sign in from locations that do not match their physical location.

Mobile carrier routingMobile networks sometimes route traffic through distant gateways, making a local user appear to be in another city or region.

Cloud services and proxiesSecurity proxies, cloud access gateways and third-party services may change the apparent source location of authentication traffic.

Travelling usersExecutives, field workers and consultants may genuinely move between locations. Validate with calendar, travel and business context where appropriate.

Shared IP addressesA shared IP address used by many employees may indicate a known gateway rather than an attacker.

Incomplete location dataGeoIP data is useful but imperfect. Treat location as evidence, not as absolute truth.

Real-world investigation

The alertMicrosoft Defender reported impossible travel for a user who normally signs in from Australia.

The second locationA successful sign-in appeared from another country shortly after the normal login.

The first questionAgent Foskett checked whether this was a VPN, mobile carrier, travel event or cloud routing issue.

The authentication contextThe suspicious sign-in used a different IP address, a different location and no familiar device context.

The pivotThe investigation moved from the alert into IdentityLogonEvents, related alerts and post-login activity.

The outcomeThe evidence determined whether the account required session revocation, password reset and further mailbox or endpoint investigation.

Investigation checklist

Is the sign-in successful?A failed sign-in from another country is different from a successful authenticated session.

Is MFA present?Confirm whether MFA was required, passed, failed, bypassed or satisfied by an existing session.

Is the IP address familiar?Check whether the IP belongs to a known VPN, office, cloud proxy, ISP or suspicious hosting provider.

Is the device familiar?A known compliant device changes the investigation context. An unknown device increases concern.

What happened after sign-in?Look for mailbox access, cloud app activity, file access, inbox rules, OAuth consent or endpoint activity.

Is response required?If compromise is likely, revoke sessions, reset credentials, review MFA methods and continue hunting related activity.

Related Agent Foskett Academy lessons

Investigating IdentityLogonEventsUnderstand identity sign-in activity inside Microsoft Defender XDR.

Investigating DeviceLogonEventsCompare account logons on devices with cloud identity activity.

Investigating IdentityDirectoryEventsReview directory changes that may support identity compromise investigations.

Building Reusable Hunting QueriesUse repeatable query patterns to structure identity hunting workflows.

Using arg_max() in KQLFind the latest sign-in or entity state for each account.

Using make_set() in KQLCollect locations, IP addresses, devices and related evidence into readable summaries.

Related Agent Foskett investigations

Impossible Travel Sign-in InvestigationA practical investigation into suspicious sign-in geography and account compromise signals.

The Impossible Travel Alert Was WrongWhy impossible travel alerts must be validated before assuming compromise.

The User Passed MFA But It Wasn't Really ThemExplore why passing MFA does not always prove the legitimate user was in control.

The Login Was Successful But The Risk Was HighInvestigate successful sign-ins that still deserve scrutiny.

The Attacker Logged In After MFAUnderstand how attackers may continue activity after authentication controls appear to pass.

The Session Token Never ExpiredReview session risk and why sign-in investigations should include token behaviour.

Coming next

Lesson 102 — Hunting Playbook: Credential TheftNext, Agent Foskett Academy investigates credential theft by looking for suspicious sign-ins, password attacks, unfamiliar IP addresses, abnormal authentication behaviour and post-compromise activity.

Why this mattersImpossible travel teaches the core playbook mindset: do not trust a single alert. Build the evidence chain, validate the context and then decide the response.

Final thought

Impossible travel is not the verdict. It is the question.

Agent Foskett mindsetA good identity investigation does not stop at geography. It asks whether the sign-in, device, IP address, authentication method and user behaviour all belong together.

Hunting Playbook SeriesLesson 101 begins the next phase of the Academy: practical hunting playbooks that combine KQL, Defender XDR telemetry and investigation thinking.

Develop IT. Protect IT.GEMXIT PTY LTD | GEMXIT UK LTD

Hunting Playbook Impossible Travel in Microsoft Defender XDR

Agent Foskett Academy Lesson 101 teaches defenders how to hunt for impossible travel using Microsoft Defender XDR, Microsoft Entra ID identity telemetry, sign-in locations, IP addresses, authentication events and KQL investigation workflows.

Investigate impossible travel with KQL and Microsoft Defender XDR

This lesson explains how to review impossible travel alerts, validate sign-in geography, compare IP addresses, identify false positives and determine whether account compromise is likely.

Microsoft Entra ID impossible travel investigation playbook

Defenders can use IdentityLogonEvents, sign-in timelines, location summaries, IP address analysis, related alerts and Defender XDR correlation to investigate impossible travel activity.