Okta User Sessions Started from Different Geolocations

  1[metadata]
  2creation_date = "2023/11/18"
  3integration = ["okta"]
  4maturity = "production"
  5updated_date = "2025/07/16"
  6
  7[rule]
  8author = ["Elastic"]
  9description = """
 10Detects when a specific Okta actor has multiple sessions started from different geolocations. Adversaries may attempt to
 11launch an attack by using a list of known usernames and passwords to gain unauthorized access to user accounts from
 12different locations.
 13"""
 14from = "now-30m"
 15interval = "15m"
 16language = "esql"
 17license = "Elastic License v2"
 18name = "Okta User Sessions Started from Different Geolocations"
 19note = """## Triage and analysis
 20
 21### Investigating Okta User Sessions Started from Different Geolocations
 22
 23This rule detects when a specific Okta actor has multiple sessions started from different geolocations. Adversaries may attempt to launch an attack by using a list of known usernames and passwords to gain unauthorized access to user accounts from different locations.
 24
 25#### Possible investigation steps:
 26- Since this is an ESQL rule, the `okta.actor.alternate_id` and `okta.client.id` values can be used to pivot into the raw authentication events related to this alert.
 27- Identify the users involved in this action by examining the `okta.actor.id`, `okta.actor.type`, `okta.actor.alternate_id`, and `okta.actor.display_name` fields.
 28- Determine the device client used for these actions by analyzing `okta.client.ip`, `okta.client.user_agent.raw_user_agent`, `okta.client.zone`, `okta.client.device`, and `okta.client.id` fields.
 29- With Okta end users identified, review the `okta.debug_context.debug_data.dt_hash` field.
 30    - Historical analysis should indicate if this device token hash is commonly associated with the user.
 31- Review the `okta.event_type` field to determine the type of authentication event that occurred.
 32    - If the event type is `user.authentication.sso`, the user may have legitimately started a session via a proxy for security or privacy reasons.
 33    - If the event type is `user.authentication.password`, the user may be using a proxy to access multiple accounts for password spraying.
 34    - If the event type is `user.session.start`, the source may have attempted to establish a session via the Okta authentication API.
 35- Review the past activities of the actor(s) involved in this action by checking their previous actions.
 36- Evaluate the actions that happened just before and after this event in the `okta.event_type` field to help understand the full context of the activity.
 37    - This may help determine the authentication and authorization actions that occurred between the user, Okta and application.
 38
 39### False positive analysis:
 40- It is very rare that a legitimate user would have multiple sessions started from different geo-located countries in a short time frame.
 41
 42### Response and remediation:
 43- If the user is legitimate and the authentication behavior is not suspicious based on device analysis, no action is required.
 44- If the user is legitimate but the authentication behavior is suspicious, consider resetting passwords for the users involves and enabling multi-factor authentication (MFA).
 45    - If MFA is already enabled, consider resetting MFA for the users.
 46- If any of the users are not legitimate, consider deactivating the user's account.
 47- Conduct a review of Okta policies and ensure they are in accordance with security best practices.
 48- Check with internal IT teams to determine if the accounts involved recently had MFA reset at the request of the user.
 49    - If so, confirm with the user this was a legitimate request.
 50    - If so and this was not a legitimate request, consider deactivating the user's account temporarily.
 51        - Reset passwords and reset MFA for the user.
 52- If this is a false positive, consider adding the `okta.debug_context.debug_data.dt_hash` field to the `exceptions` list in the rule.
 53    - This will prevent future occurrences of this event for this device from triggering the rule.
 54    - Alternatively adding `okta.client.ip` or a CIDR range to the `exceptions` list can prevent future occurrences of this event from triggering the rule.
 55        - This should be done with caution as it may prevent legitimate alerts from being generated.
 56"""
 57references = [
 58    "https://developer.okta.com/docs/reference/api/system-log/",
 59    "https://developer.okta.com/docs/reference/api/event-types/",
 60    "https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy",
 61    "https://sec.okta.com/articles/2023/08/cross-tenant-impersonation-prevention-and-detection",
 62    "https://www.rezonate.io/blog/okta-logs-decoded-unveiling-identity-threats-through-threat-hunting/",
 63    "https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security",
 64    "https://www.elastic.co/security-labs/starter-guide-to-understanding-okta",
 65]
 66risk_score = 47
 67rule_id = "2e56e1bc-867a-11ee-b13e-f661ea17fbcd"
 68setup = "The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.\n"
 69severity = "medium"
 70tags = [
 71    "Use Case: Identity and Access Audit",
 72    "Data Source: Okta",
 73    "Tactic: Initial Access",
 74    "Resources: Investigation Guide",
 75]
 76timestamp_override = "event.ingested"
 77type = "esql"
 78
 79query = '''
 80from logs-okta*
 81| where
 82    event.dataset == "okta.system" and
 83    (event.action rlike "user\.authentication(.*)" or event.action == "user.session.start") and
 84    okta.security_context.is_proxy != true and
 85    okta.actor.id != "unknown" and
 86    event.outcome == "success"
 87| keep
 88    event.action,
 89    okta.security_context.is_proxy,
 90    okta.actor.id,
 91    okta.actor.alternate_id,
 92    event.outcome,
 93    client.geo.country_name
 94| stats
 95    Esql.client_geo_country_name_count_distinct = count_distinct(client.geo.country_name)
 96    by okta.actor.id, okta.actor.alternate_id
 97| where
 98    Esql.client_geo_country_name_count_distinct >= 2
 99| sort
100    Esql.client_geo_country_name_count_distinct desc
101'''
102
103
104[[rule.threat]]
105framework = "MITRE ATT&CK"
106[[rule.threat.technique]]
107id = "T1078"
108name = "Valid Accounts"
109reference = "https://attack.mitre.org/techniques/T1078/"
110[[rule.threat.technique.subtechnique]]
111id = "T1078.004"
112name = "Cloud Accounts"
113reference = "https://attack.mitre.org/techniques/T1078/004/"
114
115
116
117[rule.threat.tactic]
118id = "TA0001"
119name = "Initial Access"
120reference = "https://attack.mitre.org/tactics/TA0001/"