M365 Identity Login from Impossible Travel Location

Detects successful Microsoft 365 portal logins from impossible travel locations. Impossible travel locations are defined as two different countries within a short time frame. This behavior may indicate an adversary attempting to access a Microsoft 365 account from a compromised account or a malicious actor attempting to access a Microsoft 365 account from a different location.

Elastic rule (View on GitHub)

  1[metadata]
  2creation_date = "2024/09/04"
  3integration = ["o365"]
  4maturity = "production"
  5updated_date = "2025/10/30"
  6
  7[rule]
  8author = ["Elastic"]
  9description = """
 10Detects successful Microsoft 365 portal logins from impossible travel locations. Impossible travel locations are defined
 11as two different countries within a short time frame. This behavior may indicate an adversary attempting to access a
 12Microsoft 365 account from a compromised account or a malicious actor attempting to access a Microsoft 365 account from
 13a different location.
 14"""
 15false_positives = [
 16    """
 17    False positives may occur when users are using a VPN or when users are traveling to different locations for
 18    legitimate purposes.
 19    """,
 20]
 21from = "now-15m"
 22index = ["logs-o365.audit-*"]
 23language = "kuery"
 24license = "Elastic License v2"
 25name = "M365 Identity Login from Impossible Travel Location"
 26note = """## Triage and analysis
 27
 28### Investigating M365 Identity Login from Impossible Travel Location
 29
 30Microsoft 365's cloud-based services enable global access, but this can be exploited by adversaries logging in from disparate locations within short intervals, indicating potential account compromise. The detection rule identifies such anomalies by analyzing login events for rapid geographic shifts, flagging suspicious activity that may suggest unauthorized access attempts.
 31
 32### Possible investigation steps
 33
 34- Review the user associated with these sign-ins to determine if the login attempt was legitimate or if further investigation is needed.
 35- Analyze the geographic locations of the logins to identify any patterns or anomalies that may indicate malicious activity.
 36- Review the ISP information for the login attempts to identify any unusual or suspicious providers.
 37- Review the authorization request type to understand the context of the login attempts and whether they align with the user's typical behavior.
 38- Analyze the client application used for the login attempts to determine if it is consistent with the user's normal usage patterns (Teams, Office, etc.)
 39- Analyze the user-agent associated with the login attempts to identify any unusual or suspicious patterns. These could also indicate mobile and endpoint logins causing false-positives.
 40
 41### False positive analysis
 42
 43- Users traveling or using VPNs may trigger this alert. Verify with the user if they were traveling or using a VPN at the time of the login attempt.
 44- Mobile access may also result in false positives, as users may log in from various locations while on the go.
 45
 46### Response and remediation
 47
 48- Investigate the login attempt further by checking for any additional context or related events that may provide insight into the user's behavior.
 49- If the login attempt is deemed suspicious, consider implementing additional security measures, such as requiring multi-factor authentication (MFA) for logins from unusual locations.
 50- Educate users about the risks of accessing corporate resources from unfamiliar locations and the importance of using secure connections (e.g., VPNs) when doing so.
 51- Monitor for any subsequent login attempts from the same location or IP address to identify potential patterns of malicious activity.
 52- Consider adding exceptions to this rule for the user or source application ID if the login attempts are determined to be legitimate and not a security concern.
 53"""
 54references = ["https://www.huntress.com/blog/time-travelers-busted-how-to-detect-impossible-travel-"]
 55risk_score = 47
 56rule_id = "3896d4c0-6ad1-11ef-8c7b-f661ea17fbcc"
 57severity = "medium"
 58tags = [
 59    "Domain: Cloud",
 60    "Domain: Identity",
 61    "Data Source: Microsoft 365",
 62    "Data Source: Microsoft 365 Audit Logs",
 63    "Use Case: Threat Detection",
 64    "Use Case: Identity and Access Audit",
 65    "Tactic: Initial Access",
 66    "Resources: Investigation Guide",
 67]
 68timestamp_override = "event.ingested"
 69type = "threshold"
 70
 71query = '''
 72event.dataset:o365.audit and
 73    event.provider:AzureActiveDirectory and
 74    event.action:UserLoggedIn and
 75    event.outcome:success and
 76    o365.audit.Target.Type:(0 or 10 or 2 or 3 or 5 or 6) and
 77    o365.audit.UserId:(* and not "Not Available") and
 78    source.geo.region_iso_code:* and
 79    not o365.audit.ApplicationId:(
 80        29d9ed98-a469-4536-ade2-f981bc1d605e or
 81        38aa3b87-a06d-4817-b275-7a316988d93b or
 82        a809996b-059e-42e2-9866-db24b99a9782
 83    ) and not o365.audit.ExtendedProperties.RequestType:(
 84        "Cmsi:Cmsi" or
 85        "Consent:Set" or
 86        "Login:reprocess" or
 87        "Login:resume" or
 88        "MessagePrompt:MessagePrompt" or
 89        "SAS:EndAuth"
 90    )
 91'''
 92
 93
 94[[rule.threat]]
 95framework = "MITRE ATT&CK"
 96[[rule.threat.technique]]
 97id = "T1078"
 98name = "Valid Accounts"
 99reference = "https://attack.mitre.org/techniques/T1078/"
100[[rule.threat.technique.subtechnique]]
101id = "T1078.004"
102name = "Cloud Accounts"
103reference = "https://attack.mitre.org/techniques/T1078/004/"
104
105
106
107[rule.threat.tactic]
108id = "TA0001"
109name = "Initial Access"
110reference = "https://attack.mitre.org/tactics/TA0001/"
111
112[rule.investigation_fields]
113field_names = [
114    "@timestamp",
115    "organization.id",
116    "o365.audit.UserId",
117    "o365.audit.ActorIpAddress",
118    "o365.audit.ApplicationId",
119    "o365.audit.ExtendedProperties.RequestType",
120    "o365.audit.Target.ID",
121    "source.geo.country_name",
122]
123
124[rule.threshold]
125field = ["o365.audit.UserId"]
126value = 1
127[[rule.threshold.cardinality]]
128field = "source.geo.country_name"
129value = 2

Triage and analysis

Investigating M365 Identity Login from Impossible Travel Location

Microsoft 365's cloud-based services enable global access, but this can be exploited by adversaries logging in from disparate locations within short intervals, indicating potential account compromise. The detection rule identifies such anomalies by analyzing login events for rapid geographic shifts, flagging suspicious activity that may suggest unauthorized access attempts.

Possible investigation steps

  • Review the user associated with these sign-ins to determine if the login attempt was legitimate or if further investigation is needed.
  • Analyze the geographic locations of the logins to identify any patterns or anomalies that may indicate malicious activity.
  • Review the ISP information for the login attempts to identify any unusual or suspicious providers.
  • Review the authorization request type to understand the context of the login attempts and whether they align with the user's typical behavior.
  • Analyze the client application used for the login attempts to determine if it is consistent with the user's normal usage patterns (Teams, Office, etc.)
  • Analyze the user-agent associated with the login attempts to identify any unusual or suspicious patterns. These could also indicate mobile and endpoint logins causing false-positives.

False positive analysis

  • Users traveling or using VPNs may trigger this alert. Verify with the user if they were traveling or using a VPN at the time of the login attempt.
  • Mobile access may also result in false positives, as users may log in from various locations while on the go.

Response and remediation

  • Investigate the login attempt further by checking for any additional context or related events that may provide insight into the user's behavior.
  • If the login attempt is deemed suspicious, consider implementing additional security measures, such as requiring multi-factor authentication (MFA) for logins from unusual locations.
  • Educate users about the risks of accessing corporate resources from unfamiliar locations and the importance of using secure connections (e.g., VPNs) when doing so.
  • Monitor for any subsequent login attempts from the same location or IP address to identify potential patterns of malicious activity.
  • Consider adding exceptions to this rule for the user or source application ID if the login attempts are determined to be legitimate and not a security concern.

References

Related rules

to-top