Impossible travel in Microsoft 365: investigate before assuming compromise

ThreatLocker has announced Advanced Anomaly Detection for its Cloud Detect product, describing capabilities for identifying unusual cloud activity, including impossible travel. For Australian businesses using Microsoft 365, the practical question is whether geographically unlikely sign-ins will be detected, investigated and contained when necessary.

An impossible travel alert is a lead, not proof of credential theft. VPNs, mobile networks and cloud services can make legitimate activity appear to cross borders in minutes. Equally, a successful sign-in using a stolen session token may need urgent attention even when no travel alert appears.

What impossible travel actually tells you

These detections compare activity associated with an account across locations and times. If the apparent journey is implausible, the activity may warrant investigation. The location normally comes from the public IP address, not the person's actual position.

That distinction matters. A staff member working in Brisbane might access email through a corporate VPN exit point overseas, then use a phone through a local mobile network. The records can look geographically inconsistent without anyone travelling.

Conversely, an attacker can use infrastructure near the victim and avoid an obvious location mismatch. Treat location as one signal alongside device information, authentication details, application access and subsequent activity.

In its Cloud Detect announcement, ThreatLocker describes trusted-IP handling and configurable responses. These are vendor-described capabilities, not evidence that every Microsoft 365 tenant already has equivalent protection enabled.

Check which Microsoft alerts and licences you have

Microsoft has related detections in different products. Similar names do not mean identical coverage.

| Capability | What to check | | --- | --- | | Microsoft Entra sign-in logs | Confirm administrators can access the relevant logs and understand retention limits. Logs support investigation but are not equivalent to automated anomaly detection. | | Entra ID Protection | Microsoft documents an atypical travel risk detection. Detailed access to premium risk detections and risk-based policies generally requires Entra ID P2. | | Microsoft Defender for Cloud Apps | Microsoft documents an impossible travel anomaly detection policy. Confirm the appropriate licence, application connections, policy configuration and alert routing. | | Third-party monitoring | Confirm which events the service ingests, how quickly it processes them and what permissions and retention it requires. |

Use Microsoft's documentation on identity risk detections and Defender for Cloud Apps anomaly detection policies when checking your environment.

Microsoft 365 Business Premium includes Entra ID P1, not the full P2 feature set. Do not assume it includes every identity risk detection or Defender for Cloud Apps capability. Product names, bundles and entitlements can change, so verify your actual subscriptions and assigned licences.

Ask your provider to show an enabled policy, its data source and its notification destination. Also establish detection latency: some risk analysis happens after the sign-in rather than blocking it in real time.

Investigate impossible travel with a consistent checklist

Start with the original records, not just the alert summary. Preserve the event identifiers and timestamps before changing settings.

• Compare the events. Record the account, source IPs, applications, timestamps and result of each sign-in. Normalise time zones. Distinguish successful access from failed attempts.
• Check the network path. Compare addresses with documented VPN, proxy, secure web gateway and remote desktop infrastructure. Check whether split tunnelling could explain different routes.
• Inspect authentication details. Review the authentication method, MFA result and Conditional Access outcome. An MFA requirement satisfied by an existing token does not necessarily mean the user approved a fresh prompt.
• Compare device context. Examine device ID, operating system, browser and managed or compliant status where available. Missing device information alone does not prove compromise.
• Contact the user independently. Use a known phone number or another trusted channel. Ask about travel, VPN use, recent sign-ins and unexpected authentication prompts.
• Review surrounding activity. Look beyond the two events for additional accounts, IP addresses, applications and suspicious activity before and after the alert.

Check both interactive and non-interactive sign-ins where relevant. Background token activity can help explain the sequence, although it should not be mistaken for a person typing a password each time.

Record the evidence supporting your conclusion. “The user says it was them” is weaker than a matching device, confirmed VPN exit address and expected application activity.

Handle VPN explanations without creating blind spots

Maintain an inventory of approved internet exit addresses, including the owner, purpose and review date. This makes investigation faster without treating every known network as inherently safe.

Before marking an address as trusted or suppressing a detection, confirm that it is stable and controlled by your organisation or a contracted provider. A shared consumer VPN address is not a reliable identity boundary.

Keep any exclusion narrow, documented and periodically reviewed. Trusted-location settings behave differently across Microsoft services; they should not become a blanket exception to authentication controls.

Close an alert as benign only when the explanation fits the evidence. Escalate if the VPN explains the location but not a new device, unusual mailbox access or an unexpected MFA registration.

Define containment before an account is compromised

Your response plan should identify who can disable accounts, revoke sessions and approve disruptive action. Document pre-authorised emergency actions so a responder does not have to wait for a meeting during an active incident.

For credible evidence of compromise, use a coordinated sequence:

• Restrict access. Block sign-in or apply an appropriate access restriction, considering operational impact and privileged access first.
• Revoke sessions and reset credentials. Do both where applicable. A password reset alone may not address stolen sessions. Revocation effects can vary by application and token type, so confirm access has actually stopped.
• Inspect authentication methods. Remove unauthorised methods and arrange secure re-registration where necessary.
• Check persistence. Review mailbox forwarding, inbox rules, delegates, application consent and unexpected role assignments. Remove malicious changes through controlled administration.
• Assess downstream activity. Examine available audit records for email access, sending, file access and sharing changes. Check connected business systems where relevant.
• Preserve evidence and assess obligations. Retain logs and document decisions. If personal information may be involved, assess applicable breach notification requirements rather than assuming an alert alone triggers notification.

Restore access only after addressing the suspected entry point and reviewing the device where appropriate. Continue monitoring the account for recurrence.

For a broader view of unauthorised access pathways, see our remote management access checks.

Make detection part of everyday security operations

Impossible travel monitoring needs an owner, an escalation path and defined coverage outside business hours. A dashboard nobody checks is not an effective response process.

Test alert routing and responder access through a controlled exercise. Confirm that investigators can retrieve logs before retention expires and that emergency access accounts remain available under documented controls.

Use phishing-resistant authentication where supported, restrict legacy authentication and deploy suitable Conditional Access policies. Test changes in report-only mode where available before enforcement. Country restrictions can reduce exposure, but cannot establish whether a person or session is trustworthy.

Include identity monitoring in your wider cyber threat readiness checklist. The objective is a repeatable decision: explain legitimate activity, contain credible compromise and retain enough evidence to understand the impact.

Tech Engine can review your cyber security, Microsoft 365 alert coverage and account containment procedures. Contact sales@techengine.au or call 1300 088 324 to identify gaps before the next suspicious sign-in.