|
| 1 | +[metadata] |
| 2 | +creation_date = "2025/10/22" |
| 3 | +integration = ["okta"] |
| 4 | +maturity = "production" |
| 5 | +updated_date = "2025/10/22" |
| 6 | + |
| 7 | +[rule] |
| 8 | +author = ["Elastic"] |
| 9 | +description = """ |
| 10 | +Identifies when a single Okta device token hash (dt_hash) is associated with multiple operating system types. This is |
| 11 | +highly anomalous because a device token is tied to a specific device and its operating system. This alert strongly |
| 12 | +indicates that an attacker has stolen a device token and is using it to impersonate a legitimate user from a |
| 13 | +different machine. |
| 14 | +""" |
| 15 | +false_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 | +] |
| 21 | +from = "now-60m" |
| 22 | +index = ["logs-okta.system-*"] |
| 23 | +language = "kuery" |
| 24 | +license = "Elastic License v2" |
| 25 | +name = "Okta Multiple OS Names Detected for a Single DT Hash" |
| 26 | +note = """## Triage and analysis |
| 27 | +
|
| 28 | +### Investigating Okta Multiple OS Names Detected for a Single DT Hash |
| 29 | +
|
| 30 | +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. |
| 31 | +
|
| 32 | +### Possible investigation steps |
| 33 | +- Review the `okta.debug_context.debug_data.dt_hash` field to identify the specific device |
| 34 | +trust 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 |
| 38 | +same 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 | +""" |
| 55 | +risk_score = 73 |
| 56 | +rule_id = "fb3ca230-af4e-11f0-900d-f661ea17fbcc" |
| 57 | +severity = "high" |
| 58 | +tags = [ |
| 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 | +] |
| 66 | +timestamp_override = "event.ingested" |
| 67 | +type = "threshold" |
| 68 | + |
| 69 | +query = ''' |
| 70 | +data_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]] |
| 81 | +framework = "MITRE ATT&CK" |
| 82 | +[[rule.threat.technique]] |
| 83 | +id = "T1539" |
| 84 | +name = "Steal Web Session Cookie" |
| 85 | +reference = "https://attack.mitre.org/techniques/T1539/" |
| 86 | + |
| 87 | + |
| 88 | +[rule.threat.tactic] |
| 89 | +id = "TA0006" |
| 90 | +name = "Credential Access" |
| 91 | +reference = "https://attack.mitre.org/tactics/TA0006/" |
| 92 | + |
| 93 | +[rule.investigation_fields] |
| 94 | +field_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] |
| 104 | +field = ["okta.debug_context.debug_data.dt_hash"] |
| 105 | +value = 1 |
| 106 | +[[rule.threshold.cardinality]] |
| 107 | +field = "user_agent.os.name" |
| 108 | +value = 2 |
| 109 | + |
| 110 | + |
0 commit comments