Multiple Okta User Auth Events with Same Device Token Hash Behind a Proxy

Description

Detects when Okta user authentication events are reported for multiple users with the same device token hash behind a proxy.

Query · kuery

data_stream.dataset:okta.system
    and not okta.actor.id:okta* and okta.debug_context.debug_data.dt_hash:*
    and okta.event_type:user.authentication* and okta.security_context.is_proxy:true

Implementation guide

The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.

Known false positives

  • An Okta admnistrator may be logged into multiple accounts from the same host for legitimate reasons.
  • Users may share an endpoint related to work or personal use in which separate Okta accounts are used.
  • Shared systems such as Kiosks and conference room computers may be used by multiple users.

Analyst notes

Investigating Multiple Okta User Auth Events with Same Device Token Hash Behind a Proxy

This rule detects when Okta user authentication events are reported for multiple users with the same device token hash behind a proxy. This may indicate that a shared device between users, or that a user is using a proxy to access multiple accounts for password spraying.

Possible investigation steps:

  • 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.
  • 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.
    • Since the device is behind a proxy, the okta.client.ip field will not be useful for determining the actual device IP address.
  • Review the okta.request.ip_chain field for more information about the geographic location of the proxy.
  • 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.
  • Examine the okta.outcome.result field to determine if the authentication was successful.
  • 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:

  • A user may have legitimately started a session via a proxy for security or privacy reasons.
  • Users may share an endpoint related to work or personal use in which separate Okta accounts are used.
    • Architecturally, this shared endpoint may leverage a proxy for security or privacy reasons.
    • Shared systems such as Kiosks and conference room computers may be used by multiple users.
    • Shared working spaces may have a single endpoint that is used by multiple users.

Response and remediation:

  • Review the profile of the users involved in this action to determine if proxy usage may be expected.
  • 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 the exceptions list in the rule.
    • This will prevent future occurrences of this event for this device from triggering the rule.
Raw source Multiple Okta User Auth Events with Same Device Token Hash Behind a Proxy · Elastic TOML
Esc
Published by elastic/detection-rules ↗, licensed under Elastic License 2.0 ↗. Reproduced here unmodified. 
[metadata]
creation_date = "2023/11/10"
integration = ["okta"]
maturity = "production"
updated_date = "2026/04/10"

[rule]
author = ["Elastic"]
description = """
Detects when Okta user authentication events are reported for multiple users with the same device token hash behind a
proxy.
"""
false_positives = [
    "An Okta admnistrator may be logged into multiple accounts from the same host for legitimate reasons.",
    "Users may share an endpoint related to work or personal use in which separate Okta accounts are used.",
    "Shared systems such as Kiosks and conference room computers may be used by multiple users.",
]
from = "now-9m"
index = ["logs-okta*"]
language = "kuery"
license = "Elastic License v2"
name = "Multiple Okta User Auth Events with Same Device Token Hash Behind a Proxy"
note = """## Triage and analysis

### Investigating Multiple Okta User Auth Events with Same Device Token Hash Behind a Proxy

This rule detects when Okta user authentication events are reported for multiple users with the same device token hash behind a proxy. This may indicate that a shared device between users, or that a user is using a proxy to access multiple accounts for password spraying.

#### Possible investigation steps:
- 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.
- 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.
    - Since the device is behind a proxy, the `okta.client.ip` field will not be useful for determining the actual device IP address.
- Review the `okta.request.ip_chain` field for more information about the geographic location of the proxy.
- 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.
- Examine the `okta.outcome.result` field to determine if the authentication was successful.
- 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:
- A user may have legitimately started a session via a proxy for security or privacy reasons.
- Users may share an endpoint related to work or personal use in which separate Okta accounts are used.
    - Architecturally, this shared endpoint may leverage a proxy for security or privacy reasons.
    - Shared systems such as Kiosks and conference room computers may be used by multiple users.
    - Shared working spaces may have a single endpoint that is used by multiple users.

### Response and remediation:
- Review the profile of the users involved in this action to determine if proxy usage may be expected.
- 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 the `exceptions` list in the rule.
    - This will prevent future occurrences of this event for this device from triggering the rule.
"""
references = [
    "https://developer.okta.com/docs/reference/api/system-log/",
    "https://developer.okta.com/docs/reference/api/event-types/",
    "https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy",
    "https://sec.okta.com/articles/2023/08/cross-tenant-impersonation-prevention-and-detection",
    "https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security",
    "https://www.elastic.co/security-labs/starter-guide-to-understanding-okta",
]
risk_score = 47
rule_id = "50887ba8-7ff7-11ee-a038-f661ea17fbcd"
setup = "The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."
severity = "medium"
tags = [
    "Use Case: Identity and Access Audit",
    "Data Source: Okta",
    "Tactic: Credential Access",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "threshold"

query = '''
data_stream.dataset:okta.system
    and not okta.actor.id:okta* and okta.debug_context.debug_data.dt_hash:*
    and okta.event_type:user.authentication* and okta.security_context.is_proxy:true
'''


[[rule.threat]]
framework = "MITRE ATT&CK"

[[rule.threat.technique]]
id = "T1110"
name = "Brute Force"
reference = "https://attack.mitre.org/techniques/T1110/"

[[rule.threat.technique.subtechnique]]
id = "T1110.003"
name = "Password Spraying"
reference = "https://attack.mitre.org/techniques/T1110/003/"

[[rule.threat.technique.subtechnique]]
id = "T1110.004"
name = "Credential Stuffing"
reference = "https://attack.mitre.org/techniques/T1110/004/"

[rule.threat.tactic]
id = "TA0006"
name = "Credential Access"
reference = "https://attack.mitre.org/tactics/TA0006/"

[[rule.threat]]
framework = "MITRE ATT&CK"

[[rule.threat.technique]]
id = "T1078"
name = "Valid Accounts"
reference = "https://attack.mitre.org/techniques/T1078/"

[[rule.threat.technique.subtechnique]]
id = "T1078.004"
name = "Cloud Accounts"
reference = "https://attack.mitre.org/techniques/T1078/004/"

[rule.threat.tactic]
id = "TA0001"
name = "Initial Access"
reference = "https://attack.mitre.org/tactics/TA0001/"
[rule.threshold]
field = ["okta.debug_context.debug_data.dt_hash"]
value = 1
[[rule.threshold.cardinality]]
field = "okta.actor.id"
value = 3

Detection rules belong to the projects that publish them and remain under their own licenses. This site indexes and links to them; it claims no rights in them.