Multiple Device Token Hashes for Single Okta Session
This rule detects when a specific Okta actor has multiple device token hashes and multiple source IPs for a single Okta session. This may indicate an authenticated session has been hijacked or replayed from a different device and network. Adversaries may steal session cookies or tokens 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"
5updated_date = "2026/04/13"
6
7[rule]
8author = ["Elastic"]
9description = """
10This rule detects when a specific Okta actor has multiple device token hashes and multiple source IPs for a single Okta
11session. This may indicate an authenticated session has been hijacked or replayed from a different device and network.
12Adversaries may steal session cookies or tokens to gain unauthorized access to Okta admin console, applications,
13tenants, or other resources.
14"""
15from = "now-9m"
16interval = "8m"
17language = "esql"
18license = "Elastic License v2"
19name = "Multiple Device Token Hashes for Single Okta Session"
20note = """## Triage and analysis
21
22### Investigating Multiple Device Token Hashes for Single Okta Session
23
24This rule detects when a specific Okta actor has multiple device token hashes and multiple source IPs for a single Okta session. This may indicate an authenticated session has been hijacked or replayed from a different device and network. Adversaries may steal session cookies or tokens to gain unauthorized access to Okta admin console, applications, tenants, or other resources.
25
26> **Note**: This is an ES|QL aggregation-based rule. Exceptions can be added on the original ECS or integration-related fields. We recommend using the indicators from the alert document to pivot into the raw events for analysis.
27
28#### Possible investigation steps:
29- Use `okta.actor.alternate_id` and `okta.authentication_context.external_session_id` from the alert to pivot into the raw Okta system log events for the affected session.
30- Review the source IPs (`okta.client.ip`) and ASN information (`source.as.organization.name`) to determine if the session was used from multiple distinct networks.
31 - Multiple ASNs or geolocations (`client.geo.country_name`, `client.geo.city_name`) within the same session strongly suggest session hijacking.
32- Compare the `okta.debug_context.debug_data.dt_hash` values to identify the device token hashes associated with the session.
33 - A legitimate session should have a consistent device token hash. Multiple distinct hashes indicate the session cookie may have been replayed from a different device.
34- Examine `okta.client.user_agent.raw_user_agent` and `okta.client.device` for inconsistencies that suggest different devices or browsers using the same session.
35- Review `event.action` to understand what actions were performed during the session.
36 - Look for suspicious post-authentication activity such as admin console access, policy changes, or application assignment modifications.
37- Check `okta.debug_context.debug_data.risk_level`, `okta.debug_context.debug_data.risk_reasons`, and `okta.debug_context.debug_data.behaviors` for Okta's own risk assessment of the session activity.
38- Review the past activities of the actor(s) involved by checking their previous sessions and login patterns.
39
40### False positive analysis:
41- OAuth application integrations (e.g., backend services exchanging authorization codes for tokens) can generate multiple device token hashes per session due to the multi-step token grant flow. These typically involve `Okta-Integrations` user agents and known infrastructure IPs.
42- Users switching between networks (e.g., VPN reconnects, WiFi to cellular transitions) may produce multiple source IPs for the same session, though the device token hash should remain consistent.
43- Automated tools or scripts that interact with Okta APIs on behalf of a user may generate additional device token hashes.
44
45### Response and remediation:
46- If the alert shows multiple distinct ASNs or geolocations for the same session, immediately revoke all active sessions for the affected user via the Okta admin console.
47- Reset the user's password and all active MFA factors.
48 - If MFA is not enabled, enforce MFA enrollment before allowing re-authentication.
49- Review Okta system logs for any administrative or sensitive actions performed during the suspicious session window.
50- If the session was used to access downstream applications, review those application logs for unauthorized activity.
51- Check with the user to confirm whether they were actively using Okta during the alert time window.
52- For recurring false positives from known integrations, add exceptions on `okta.actor.alternate_id` for the specific service account or application client ID.
53"""
54references = [
55 "https://developer.okta.com/docs/reference/api/system-log/",
56 "https://developer.okta.com/docs/reference/api/event-types/",
57 "https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy",
58 "https://sec.okta.com/articles/2023/08/cross-tenant-impersonation-prevention-and-detection",
59 "https://support.okta.com/help/s/article/session-hijacking-attack-definition-damage-defense?language=en_US",
60 "https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security",
61 "https://www.elastic.co/security-labs/starter-guide-to-understanding-okta",
62]
63risk_score = 47
64rule_id = "cc382a2e-7e52-11ee-9aac-f661ea17fbcd"
65severity = "medium"
66tags = [
67 "Domain: Identity",
68 "Domain: SaaS",
69 "Data Source: Okta",
70 "Data Source: Okta System Logs",
71 "Tactic: Credential Access",
72 "Resources: Investigation Guide",
73]
74timestamp_override = "event.ingested"
75type = "esql"
76
77query = '''
78from logs-okta.system-*
79| where
80 data_stream.dataset == "okta.system" and
81 not event.action in (
82 "policy.evaluate_sign_on",
83 "user.session.start",
84 "user.authentication.sso"
85 ) and
86 okta.actor.alternate_id != "system@okta.com" and
87 okta.actor.alternate_id rlike "[^@\\s]+\\@[^@\\s]+" and
88 okta.authentication_context.external_session_id != "unknown" and
89 (
90 okta.authentication_context.external_session_id IS NOT NULL and
91 okta.debug_context.debug_data.dt_hash IS NOT NULL and
92 okta.client.ip IS NOT NULL and
93 okta.client.user_agent.raw_user_agent IS NOT NULL
94 ) and
95 (
96 okta.authentication_context.external_session_id != "-" and
97 okta.debug_context.debug_data.dt_hash != "-" and
98 okta.client.user_agent.raw_user_agent != "-"
99 )
100| stats
101 Esql.dt_hash_count_distinct = count_distinct(okta.debug_context.debug_data.dt_hash),
102 Esql.client_ip_count_distinct = count_distinct(okta.client.ip),
103 Esql.event_count = count(*),
104 Esql.first_event_time = min(@timestamp),
105 Esql.last_event_time = max(@timestamp),
106 Esql.dt_hash_values = values(okta.debug_context.debug_data.dt_hash),
107 Esql.event_action_values = values(event.action),
108 Esql.client_ip_values = values(okta.client.ip),
109 Esql.user_agent_values = values(okta.client.user_agent.raw_user_agent),
110 Esql.device_values = values(okta.client.device),
111 Esql.is_proxy_values = values(okta.security_context.is_proxy),
112 Esql.geo_country_name_values = values(client.geo.country_name),
113 Esql.geo_city_name_values = values(client.geo.city_name),
114 Esql.source_asn_number_values = values(source.`as`.number),
115 Esql.source_asn_org_name_values = values(source.`as`.organization.name),
116 Esql.threat_suspected_values = values(okta.debug_context.debug_data.threat_suspected),
117 Esql.risk_level_values = values(okta.debug_context.debug_data.risk_level),
118 Esql.risk_reasons_values = values(okta.debug_context.debug_data.risk_reasons),
119 Esql.behaviors_values = values(okta.debug_context.debug_data.behaviors),
120 Esql.device_fingerprint_values = values(okta.debug_context.debug_data.device_fingerprint),
121 Esql.risk_behaviors_values = values(okta.debug_context.debug_data.risk_behaviors),
122 Esql.request_uri_values = values(okta.debug_context.debug_data.request_uri)
123 by
124 okta.actor.alternate_id,
125 okta.authentication_context.external_session_id
126| where
127 Esql.dt_hash_count_distinct >= 4 and
128 Esql.client_ip_count_distinct >= 2
129| keep Esql.*, okta.*
130'''
131
132
133[[rule.threat]]
134framework = "MITRE ATT&CK"
135
136[[rule.threat.technique]]
137id = "T1539"
138name = "Steal Web Session Cookie"
139reference = "https://attack.mitre.org/techniques/T1539/"
140
141[rule.threat.tactic]
142id = "TA0006"
143name = "Credential Access"
144reference = "https://attack.mitre.org/tactics/TA0006/"
145
146[[rule.threat]]
147framework = "MITRE ATT&CK"
148
149[[rule.threat.technique]]
150id = "T1550"
151name = "Use Alternate Authentication Material"
152reference = "https://attack.mitre.org/techniques/T1550/"
153
154[[rule.threat.technique.subtechnique]]
155id = "T1550.004"
156name = "Web Session Cookie"
157reference = "https://attack.mitre.org/techniques/T1550/004/"
158
159[rule.threat.tactic]
160id = "TA0005"
161name = "Defense Evasion"
162reference = "https://attack.mitre.org/tactics/TA0005/"
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 and multiple source IPs for a single Okta session. This may indicate an authenticated session has been hijacked or replayed from a different device and network. Adversaries may steal session cookies or tokens to gain unauthorized access to Okta admin console, applications, tenants, or other resources.
Note: This is an ES|QL aggregation-based rule. Exceptions can be added on the original ECS or integration-related fields. We recommend using the indicators from the alert document to pivot into the raw events for analysis.
Possible investigation steps:
- Use
okta.actor.alternate_idandokta.authentication_context.external_session_idfrom the alert to pivot into the raw Okta system log events for the affected session. - Review the source IPs (
okta.client.ip) and ASN information (source.as.organization.name) to determine if the session was used from multiple distinct networks.- Multiple ASNs or geolocations (
client.geo.country_name,client.geo.city_name) within the same session strongly suggest session hijacking.
- Multiple ASNs or geolocations (
- Compare the
okta.debug_context.debug_data.dt_hashvalues to identify the device token hashes associated with the session.- A legitimate session should have a consistent device token hash. Multiple distinct hashes indicate the session cookie may have been replayed from a different device.
- Examine
okta.client.user_agent.raw_user_agentandokta.client.devicefor inconsistencies that suggest different devices or browsers using the same session. - Review
event.actionto understand what actions were performed during the session.- Look for suspicious post-authentication activity such as admin console access, policy changes, or application assignment modifications.
- Check
okta.debug_context.debug_data.risk_level,okta.debug_context.debug_data.risk_reasons, andokta.debug_context.debug_data.behaviorsfor Okta's own risk assessment of the session activity. - Review the past activities of the actor(s) involved by checking their previous sessions and login patterns.
False positive analysis:
- OAuth application integrations (e.g., backend services exchanging authorization codes for tokens) can generate multiple device token hashes per session due to the multi-step token grant flow. These typically involve
Okta-Integrationsuser agents and known infrastructure IPs. - Users switching between networks (e.g., VPN reconnects, WiFi to cellular transitions) may produce multiple source IPs for the same session, though the device token hash should remain consistent.
- Automated tools or scripts that interact with Okta APIs on behalf of a user may generate additional device token hashes.
Response and remediation:
- If the alert shows multiple distinct ASNs or geolocations for the same session, immediately revoke all active sessions for the affected user via the Okta admin console.
- Reset the user's password and all active MFA factors.
- If MFA is not enabled, enforce MFA enrollment before allowing re-authentication.
- Review Okta system logs for any administrative or sensitive actions performed during the suspicious session window.
- If the session was used to access downstream applications, review those application logs for unauthorized activity.
- Check with the user to confirm whether they were actively using Okta during the alert time window.
- For recurring false positives from known integrations, add exceptions on
okta.actor.alternate_idfor the specific service account or application client ID.
References
Related rules
- Okta Successful Login After Credential Attack
- Potential Okta Brute Force (Multi-Source)
- Potential Okta Credential Stuffing (Single Source)
- Potential Okta MFA Bombing via Push Notifications
- Potential Okta Password Spray (Multi-Source)