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