Multiple Device Token Hashes for Single Okta Session
This rule detects when a specific Okta actor has multiple device token hashes for a single Okta session. This may indicate an authenticated session has been hijacked or is being used by multiple devices. Adversaries may hijack a session to gain unauthorized access to Okta admin console, applications, tenants, or other resources.
Elastic rule (View on GitHub)
1[metadata]
2creation_date = "2023/11/08"
3integration = ["okta"]
4maturity = "production"
5min_stack_comments = "ES|QL rule type becomes available in 8.13.0 as technical preview."
6min_stack_version = "8.13.0"
7updated_date = "2024/06/21"
8
9[rule]
10author = ["Elastic"]
11description = """
12This rule detects when a specific Okta actor has multiple device token hashes for a single Okta session. This may
13indicate an authenticated session has been hijacked or is being used by multiple devices. Adversaries may hijack a
14session to gain unauthorized access to Okta admin console, applications, tenants, or other resources.
15"""
16from = "now-9m"
17language = "esql"
18license = "Elastic License v2"
19name = "Multiple Device Token Hashes for Single Okta Session"
20note = """
21## Triage and analysis
22
23### Investigating Multiple Device Token Hashes for Single Okta Session
24
25This rule detects when a specific Okta actor has multiple device token hashes for a single Okta session. This may indicate an authenticated session has been hijacked or is being used by multiple devices. Adversaries may hijack a session to gain unauthorized access to Okta admin console, applications, tenants, or other resources.
26
27#### Possible investigation steps:
28- Since this is an ES|QL rule, the `okta.actor.alternate_id` and `okta.authentication_context.external_session_id` values can be used to pivot into the raw authentication events related to this alert.
29- 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.
30- 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.
31- With Okta end users identified, review the `okta.debug_context.debug_data.dt_hash` field.
32 - Historical analysis should indicate if this device token hash is commonly associated with the user.
33- Review the `okta.event_type` field to determine the type of authentication event that occurred.
34 - Authentication events have been filtered out to focus on Okta activity via established sessions.
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- Aggregate by `okta.actor.alternate_id` and `event.action` to determine the type of actions that are being performed by the actor(s) involved in this action.
39 - If various activity is reported that seems to indicate actions from separate users, consider deactivating the user's account temporarily.
40
41### False positive analysis:
42- It is very rare that a legitimate user would have multiple device token hashes for a single Okta session as DT hashes do not change after an authenticated session is established.
43
44### Response and remediation:
45- Consider stopping all sessions for the user(s) involved in this action.
46- If this does not appear to be a false positive, consider resetting passwords for the users involved and enabling multi-factor authentication (MFA).
47 - If MFA is already enabled, consider resetting MFA for the users.
48- If any of the users are not legitimate, consider deactivating the user's account.
49- Conduct a review of Okta policies and ensure they are in accordance with security best practices.
50- Check with internal IT teams to determine if the accounts involved recently had MFA reset at the request of the user.
51 - If so, confirm with the user this was a legitimate request.
52 - If so and this was not a legitimate request, consider deactivating the user's account temporarily.
53 - Reset passwords and reset MFA for the user.
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://support.okta.com/help/s/article/session-hijacking-attack-definition-damage-defense?language=en_US",
63]
64risk_score = 47
65rule_id = "cc382a2e-7e52-11ee-9aac-f661ea17fbcd"
66setup = """## Setup
67
68The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
69severity = "medium"
70tags = ["Use Case: Identity and Access Audit", "Data Source: Okta", "Tactic: Credential Access", "Domain: SaaS"]
71timestamp_override = "event.ingested"
72type = "esql"
73
74query = '''
75FROM logs-okta*
76| WHERE
77 event.dataset == "okta.system"
78 // ignore authentication events where session and device token hash change often
79 AND NOT event.action IN (
80 "policy.evaluate_sign_on",
81 "user.session.start",
82 "user.authentication.sso"
83 )
84 // ignore Okta system events and only allow registered users
85 AND (
86 okta.actor.alternate_id != "system@okta.com"
87 AND okta.actor.alternate_id RLIKE "[^@\\s]+\\@[^@\\s]+"
88 )
89 AND okta.authentication_context.external_session_id != "unknown"
90| STATS
91 dt_hash_counts = COUNT_DISTINCT(okta.debug_context.debug_data.dt_hash) BY
92 okta.actor.alternate_id,
93 okta.authentication_context.external_session_id
94| WHERE
95 dt_hash_counts >= 2
96| SORT
97 dt_hash_counts DESC
98'''
99
100
101[[rule.threat]]
102framework = "MITRE ATT&CK"
103[[rule.threat.technique]]
104id = "T1539"
105name = "Steal Web Session Cookie"
106reference = "https://attack.mitre.org/techniques/T1539/"
107
108
109[rule.threat.tactic]
110id = "TA0006"
111name = "Credential Access"
112reference = "https://attack.mitre.org/tactics/TA0006/"
Triage and analysis
Investigating Multiple Device Token Hashes for Single Okta Session
This rule detects when a specific Okta actor has multiple device token hashes for a single Okta session. This may indicate an authenticated session has been hijacked or is being used by multiple devices. Adversaries may hijack a session to gain unauthorized access to Okta admin console, applications, tenants, or other resources.
Possible investigation steps:
- Since this is an ES|QL rule, the
okta.actor.alternate_id
andokta.authentication_context.external_session_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.- Authentication events have been filtered out to focus on Okta activity via established sessions.
- 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.
- Aggregate by
okta.actor.alternate_id
andevent.action
to determine the type of actions that are being performed by the actor(s) involved in this action.- If various activity is reported that seems to indicate actions from separate users, consider deactivating the user's account temporarily.
False positive analysis:
- It is very rare that a legitimate user would have multiple device token hashes for a single Okta session as DT hashes do not change after an authenticated session is established.
Response and remediation:
- Consider stopping all sessions for the user(s) involved in this action.
- If this does not appear to be a false positive, consider resetting passwords for the users involved 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.
- 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
- High Number of Okta Device Token Cookies Generated for Authentication
- Multiple Okta User Authentication Events with Client Address
- Multiple Okta User Authentication Events with Same Device Token Hash
- Okta User Sessions Started from Different Geolocations
- Spike in Failed Logon Events