Multiple Device Token Hashes for Single Okta Session

  1[metadata]
  2creation_date = "2023/11/08"
  3integration = ["okta"]
  4maturity = "production"
  5updated_date = "2025/09/25"
  6
  7[rule]
  8author = ["Elastic"]
  9description = """
 10This rule detects when a specific Okta actor has multiple device token hashes for a single Okta session. This may
 11indicate an authenticated session has been hijacked or is being used by multiple devices. Adversaries may hijack a
 12session to gain unauthorized access to Okta admin console, applications, tenants, or other resources.
 13"""
 14from = "now-9m"
 15language = "esql"
 16license = "Elastic License v2"
 17name = "Multiple Device Token Hashes for Single Okta Session"
 18note = """## Triage and analysis
 19
 20### Investigating Multiple Device Token Hashes for Single Okta Session
 21
 22This 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.
 23
 24#### Possible investigation steps:
 25- Since this is an ESQL 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.
 26- 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.
 27- 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.
 28- With Okta end users identified, review the `okta.debug_context.debug_data.dt_hash` field.
 29    - Historical analysis should indicate if this device token hash is commonly associated with the user.
 30- Review the `okta.event_type` field to determine the type of authentication event that occurred.
 31    - Authentication events have been filtered out to focus on Okta activity via established sessions.
 32- Review the past activities of the actor(s) involved in this action by checking their previous actions.
 33- 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.
 34    - This may help determine the authentication and authorization actions that occurred between the user, Okta and application.
 35- 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.
 36    - If various activity is reported that seems to indicate actions from separate users, consider deactivating the user's account temporarily.
 37
 38### False positive analysis:
 39- 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.
 40
 41### Response and remediation:
 42- Consider stopping all sessions for the user(s) involved in this action.
 43- If this does not appear to be a false positive, consider resetting passwords for the users involved and enabling multi-factor authentication (MFA).
 44    - If MFA is already enabled, consider resetting MFA for the users.
 45- If any of the users are not legitimate, consider deactivating the user's account.
 46- Conduct a review of Okta policies and ensure they are in accordance with security best practices.
 47- Check with internal IT teams to determine if the accounts involved recently had MFA reset at the request of the user.
 48    - If so, confirm with the user this was a legitimate request.
 49    - If so and this was not a legitimate request, consider deactivating the user's account temporarily.
 50        - Reset passwords and reset MFA for the user.
 51- Alternatively adding `okta.client.ip` or a CIDR range to the `exceptions` list can prevent future occurrences of this event from triggering the rule.
 52    - This should be done with caution as it may prevent legitimate alerts from being generated.
 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"
 65setup = """## Setup
 66
 67The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 68severity = "medium"
 69tags = [
 70    "Use Case: Identity and Access Audit",
 71    "Data Source: Okta",
 72    "Tactic: Credential Access",
 73    "Domain: SaaS",
 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    not event.action in (
 84        "policy.evaluate_sign_on",
 85        "user.session.start",
 86        "user.authentication.sso"
 87    ) and
 88    okta.actor.alternate_id != "system@okta.com" and
 89    okta.actor.alternate_id rlike "[^@\\s]+\\@[^@\\s]+" and
 90    okta.authentication_context.external_session_id != "unknown"
 91| keep
 92    event.action,
 93    okta.actor.alternate_id,
 94    okta.authentication_context.external_session_id,
 95    okta.debug_context.debug_data.dt_hash
 96| stats
 97    Esql.okta_debug_context_debug_data_dt_hash_count_distinct = count_distinct(okta.debug_context.debug_data.dt_hash)
 98  by
 99    okta.actor.alternate_id,
100    okta.authentication_context.external_session_id
101| where
102    Esql.okta_debug_context_debug_data_dt_hash_count_distinct >= 2
103| sort
104    Esql.okta_debug_context_debug_data_dt_hash_count_distinct desc
105'''
106
107
108[[rule.threat]]
109framework = "MITRE ATT&CK"
110[[rule.threat.technique]]
111id = "T1539"
112name = "Steal Web Session Cookie"
113reference = "https://attack.mitre.org/techniques/T1539/"
114
115
116[rule.threat.tactic]
117id = "TA0006"
118name = "Credential Access"
119reference = "https://attack.mitre.org/tactics/TA0006/"

References

• System Log

  The Okta System Log records system events that are related to your organization in order to provide an audit trail that can be used to understand platform activity and to diagnose problems. The System Log API provides near real-time, read-only access to your organization's System Log and is the programmatic counterpart of the [System Log UI](https://help.okta.com/okta_help.htm?id=ext_Reports_SysLog). The terms "event" and "log event" are often used interchangeably. In the context of this API, an "event" is an occurrence of interest within the system, and a "log" or "log event" is the recorded fact. The System Log API supports these primary use cases: * Event data export into a security information and event management system (SIEM) * System monitoring * Development debugging * Event introspection and audit > **Note:** Some of the curl code examples on this page include SSWS API token authentication. However, Okta recommends using scoped OAuth 2.0 and OIDC access tokens to authenticate with Okta management APIs. OAuth 2.0 and OIDC access tokens provide fine-grain control over the bearer's actions on specific endpoints. See [Okta API authentication methods](https://developer.okta.com/docs/api/openapi/okta-oauth/guides/overview/). For further details and examples, see [System Log query](https://developer.okta.com/docs/reference/system-log-query/).

  
  Read More

• Event Types | Okta Developer

  Secure, scalable, and highly available authentication and user management for any app.

  
  Read More

• Testing your Okta visibility and detection with Dorothy and Elastic Security — Elastic Security Labs

  

  Dorothy is a tool for security teams to test their visibility and detection capabilities for their Okta environment. IAM solutions are frequently targeted by adversaries but poorly monitored. Learn how to get started with Dorothy in this post.

  
  Read More

• Cross-Tenant Impersonation: Prevention and Detection

  

  SummaryOkta has observed attacks in which a threat actor used social engineering to attain a highly privileged role in an Okta customer Orga

  
  Read More

• Okta Help Center (Lightning)

  Loading ×Sorry to interrupt CSS Error Refresh

  
  Read More

• Monitoring Okta threats with Elastic Security — Elastic Security Labs

  

  This article guides readers through establishing an Okta threat detection lab, emphasizing the importance of securing SaaS platforms like Okta. It details creating a lab environment with the Elastic Stack, integrating SIEM solutions, and Okta.

  
  Read More

• Starter guide to understanding Okta — Elastic Security Labs

  

  This article delves into Okta's architecture and services, laying a solid foundation for threat research and detection engineering. Essential reading for those aiming to master threat hunting and detection in Okta environments.

  
  Read More

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
• Potential Okta MFA Bombing via Push Notifications
• Potentially Successful Okta MFA Bombing via Push Notifications