Okta Multiple OS Names Detected for a Single DT Hash

[metadata]
creation_date = "2025/10/22"
integration = ["okta"]
maturity = "production"
updated_date = "2026/03/24"

[rule]
author = ["Elastic"]
description = """
Identifies when a single Okta device token hash (dt_hash) is associated with multiple operating system types. This is
highly anomalous because a device token is tied to a specific device and its operating system. This alert strongly
indicates that an attacker has stolen a device token and is using it to impersonate a legitimate user from a
different machine.
"""
false_positives = [
    """
    Applications will tag the operating system as null when the device is not recognized as a managed device. In
    environments where users frequently switch between managed and unmanaged devices, this may lead to false positives.
    """,
]
from = "now-60m"
index = ["logs-okta.system-*"]
language = "kuery"
license = "Elastic License v2"
name = "Okta Multiple OS Names Detected for a Single DT Hash"
note = """## Triage and analysis

### Investigating Okta Multiple OS Names Detected for a Single DT Hash

This rule detects when a single Okta device token hash (dt_hash) is associated with multiple operating system types. This is highly anomalous because a device token is tied to a specific device and its operating system. This alert strongly indicates that an attacker has stolen a device token token and is using it to impersonate a legitimate user from a different machine.

### Possible investigation steps
- Review the `okta.debug_context.debug_data.dt_hash` field to identify the specific device
trust hash associated with multiple operating systems.
- Examine the `user.email` field to determine which user account is associated with the suspicious activity
- Analyze the `source.ip` field to identify the IP addresses from which the different operating systems were reported. Look for any unusual or unexpected locations.
- Review the `user_agent.os.name` field to see the different operating systems reported for the
same dt_hash. This will help identify the nature of the anomaly.
- Check the `event.action` field to understand the context of the authentication events (e.g., MFA verification, standard authentication).
- Investigate the timeline of events to see when the different operating systems were reported for the same dt_hash. Look for patterns or sequences that may indicate malicious activity.
- Correlate this activity with other security events in your environment, such as failed login attempts, unusual access patterns, or alerts from endpoint security solutions.

### False positive analysis
- Applications will tag the operating system as null when the device is not recognized as a managed device
- In environments where users frequently switch between managed and unmanaged devices, this may lead to false positives.

### Response and remediation
- Immediately investigate the user account associated with the suspicious activity to determine if it has been compromised.
- If compromise is confirmed, reset the user's credentials and enforce multi-factor authentication (MFA)
- Revoke any active sessions associated with the compromised account to prevent further unauthorized access.
- Review and monitor the affected dt_hash for any further suspicious activity.
- Educate users about the importance of device security and the risks associated with device tokens.
- Implement additional monitoring for device token tokens and consider using conditional access policies to restrict access based on device compliance status.
"""
risk_score = 73
rule_id = "fb3ca230-af4e-11f0-900d-f661ea17fbcc"
severity = "high"
tags = [
    "Domain: Identity",
    "Data Source: Okta",
    "Data Source: Okta System Logs",
    "Use Case: Threat Detection",
    "Tactic: Credential Access",
    "Resources: Investigation Guide"
]
timestamp_override = "event.ingested"
type = "threshold"

query = '''
data_stream.dataset: "okta.system"
    and not okta.debug_context.debug_data.dt_hash: "-"
    and user_agent.os.name: *
    and event.action: (
        "user.authentication.verify" or
        "user.authentication.auth_via_mfa"
    )
'''


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

[[rule.threat.technique]]
id = "T1539"
name = "Steal Web Session Cookie"
reference = "https://attack.mitre.org/techniques/T1539/"

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

[rule.investigation_fields]
field_names = [
    "@timestamp",
    "okta.debug_context.debug_data.dt_hash",
    "user.email",
    "source.ip",
    "user_agent.os.name",
    "event.action",
]

[rule.threshold]
field = ["okta.debug_context.debug_data.dt_hash"]
value = 1
[[rule.threshold.cardinality]]
field = "user_agent.os.name"
value = 2