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_id and okta.authentication_context.external_session_id from 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.
  • Compare the okta.debug_context.debug_data.dt_hash values 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_agent and okta.client.device for inconsistencies that suggest different devices or browsers using the same session.
  • Review event.action to 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, and okta.debug_context.debug_data.behaviors for 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-Integrations user 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_id for the specific service account or application client ID.

References

Related rules

to-top