Okta Multiple OS Names Detected for a Single DT Hash

  1[metadata]
  2creation_date = "2025/10/22"
  3integration = ["okta"]
  4maturity = "production"
  5updated_date = "2026/09/18"
  6
  7[rule]
  8author = ["Elastic"]
  9description = """
 10Identifies when a single Okta device token hash (dt_hash) is associated with multiple operating system types. This is
 11highly anomalous because a device token is tied to a specific device and its operating system. This alert strongly
 12indicates that an attacker has stolen a device token and is using it to impersonate a legitimate user from a
 13different machine.
 14"""
 15false_positives = [
 16    """
 17    Applications will tag the operating system as null when the device is not recognized as a managed device. In
 18    environments where users frequently switch between managed and unmanaged devices, this may lead to false positives.
 19    """,
 20]
 21from = "now-60m"
 22index = ["logs-okta.system-*"]
 23language = "kuery"
 24license = "Elastic License v2"
 25name = "Okta Multiple OS Names Detected for a Single DT Hash"
 26note = """## Triage and analysis
 27
 28### Investigating Okta Multiple OS Names Detected for a Single DT Hash
 29
 30This 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.
 31
 32### Possible investigation steps
 33- Review the `okta.debug_context.debug_data.dt_hash` field to identify the specific device
 34trust hash associated with multiple operating systems.
 35- Examine the `user.email` field to determine which user account is associated with the suspicious activity
 36- 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.
 37- Review the `user_agent.os.name` field to see the different operating systems reported for the
 38same dt_hash. This will help identify the nature of the anomaly.
 39- Check the `event.action` field to understand the context of the authentication events (e.g., MFA verification, standard authentication).
 40- 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.
 41- Correlate this activity with other security events in your environment, such as failed login attempts, unusual access patterns, or alerts from endpoint security solutions.
 42
 43### False positive analysis
 44- Applications will tag the operating system as null when the device is not recognized as a managed device
 45- In environments where users frequently switch between managed and unmanaged devices, this may lead to false positives.
 46
 47### Response and remediation
 48- Immediately investigate the user account associated with the suspicious activity to determine if it has been compromised.
 49- If compromise is confirmed, reset the user's credentials and enforce multi-factor authentication (MFA)
 50- Revoke any active sessions associated with the compromised account to prevent further unauthorized access.
 51- Review and monitor the affected dt_hash for any further suspicious activity.
 52- Educate users about the importance of device security and the risks associated with device tokens.
 53- Implement additional monitoring for device token tokens and consider using conditional access policies to restrict access based on device compliance status.
 54"""
 55risk_score = 73
 56rule_id = "fb3ca230-af4e-11f0-900d-f661ea17fbcc"
 57severity = "high"
 58tags = [
 59    "Domain: Identity",
 60    "Data Source: Okta",
 61    "Data Source: Okta System Logs",
 62    "Use Case: Threat Detection",
 63    "Tactic: Credential Access",
 64    "Resources: Investigation Guide",
 65    "Noise: Low",
 66    "Performance: Fast",
 67    "Profile: Recommended",
 68    "Threat: AiTM Phishing",
 69    "Rule Type: Threshold",
 70    "Platform: Okta",
 71]
 72timestamp_override = "event.ingested"
 73type = "threshold"
 74
 75query = '''
 76data_stream.dataset: "okta.system"
 77    and not okta.debug_context.debug_data.dt_hash: "-"
 78    and user_agent.os.name: *
 79    and event.action: (
 80        "user.authentication.verify" or
 81        "user.authentication.auth_via_mfa"
 82    )
 83'''
 84
 85
 86[[rule.threat]]
 87framework = "MITRE ATT&CK"
 88
 89[[rule.threat.technique]]
 90id = "T1539"
 91name = "Steal Web Session Cookie"
 92reference = "https://attack.mitre.org/techniques/T1539/"
 93
 94[rule.threat.tactic]
 95id = "TA0006"
 96name = "Credential Access"
 97reference = "https://attack.mitre.org/tactics/TA0006/"
 98
 99[rule.investigation_fields]
100field_names = [
101    "@timestamp",
102    "okta.debug_context.debug_data.dt_hash",
103    "user.email",
104    "source.ip",
105    "user_agent.os.name",
106    "event.action",
107]
108
109[rule.threshold]
110field = ["okta.debug_context.debug_data.dt_hash"]
111value = 1
112[[rule.threshold.cardinality]]
113field = "user_agent.os.name"
114value = 2