Okta Multiple OS Names Detected for a Single DT Hash

  1[metadata]
  2creation_date = "2025/10/22"
  3integration = ["okta"]
  4maturity = "production"
  5updated_date = "2025/10/22"
  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]
 66timestamp_override = "event.ingested"
 67type = "threshold"
 68
 69query = '''
 70data_stream.dataset: "okta.system"
 71    and not okta.debug_context.debug_data.dt_hash: "-"
 72    and user_agent.os.name: *
 73    and event.action: (
 74        "user.authentication.verify" or
 75        "user.authentication.auth_via_mfa"
 76    )
 77'''
 78
 79
 80[[rule.threat]]
 81framework = "MITRE ATT&CK"
 82[[rule.threat.technique]]
 83id = "T1539"
 84name = "Steal Web Session Cookie"
 85reference = "https://attack.mitre.org/techniques/T1539/"
 86
 87
 88[rule.threat.tactic]
 89id = "TA0006"
 90name = "Credential Access"
 91reference = "https://attack.mitre.org/tactics/TA0006/"
 92
 93[rule.investigation_fields]
 94field_names = [
 95    "@timestamp",
 96    "okta.debug_context.debug_data.dt_hash",
 97    "user.email",
 98    "source.ip",
 99    "user_agent.os.name",
100    "event.action",
101]
102
103[rule.threshold]
104field = ["okta.debug_context.debug_data.dt_hash"]
105value = 1
106[[rule.threshold.cardinality]]
107field = "user_agent.os.name"
108value = 2