Potential Okta Brute Force (Device Token Rotation)
Detects potential brute force attacks against a single Okta user account where excessive unique device token hashes are generated, indicating automated tooling that fails to persist browser cookies between attempts.
Elastic rule (View on GitHub)
1[metadata]
2creation_date = "2024/06/17"
3integration = ["okta"]
4maturity = "production"
5updated_date = "2026/02/19"
6
7[rule]
8author = ["Elastic"]
9description = """
10Detects potential brute force attacks against a single Okta user account where excessive unique device token hashes
11are generated, indicating automated tooling that fails to persist browser cookies between attempts.
12"""
13false_positives = [
14 "A user experiencing login issues may generate multiple device tokens through repeated legitimate attempts.",
15 "Automated testing or monitoring tools that do not persist cookies may trigger this rule.",
16]
17from = "now-30m"
18language = "esql"
19license = "Elastic License v2"
20name = "Potential Okta Brute Force (Device Token Rotation)"
21note = """## Triage and analysis
22
23### Investigating Potential Okta Brute Force (Device Token Rotation)
24
25This rule identifies excessive unique device token hashes generated for a single user account, indicating automated brute force tooling that fails to persist browser cookies between authentication attempts.
26
27#### Possible investigation steps
28- Identify the targeted user account and determine if it has elevated privileges or sensitive access.
29- Review the source IP and check if it belongs to known proxy, VPN, or cloud infrastructure.
30- Examine user agent strings for signs of automation, scripting tools, or inconsistent browser fingerprints.
31- Check if Okta flagged the source as a known threat or proxy.
32- Determine if any authentication attempts succeeded following the failed attempts.
33- Review the user's recent activity for signs of account compromise.
34
35### False positive analysis
36- Users experiencing login issues may generate multiple device tokens through repeated legitimate attempts.
37- Automated testing or monitoring tools that do not persist cookies may trigger this rule.
38- Browser extensions or privacy tools that clear cookies between requests may cause device token rotation.
39
40### Response and remediation
41- If attack is confirmed, reset the user's password immediately.
42- Block the source IP at the network perimeter.
43- Review and potentially reset MFA for the targeted account.
44- Monitor for any successful authentication that may indicate compromise.
45- Contact the user to verify if they experienced legitimate login issues.
46"""
47references = [
48 "https://support.okta.com/help/s/article/Troubleshooting-Distributed-Brute-Force-andor-Password-Spray-attacks-in-Okta",
49 "https://www.okta.com/identity-101/brute-force/",
50 "https://support.okta.com/help/s/article/How-does-the-Device-Token-work?language=en_US",
51 "https://developer.okta.com/docs/reference/api/event-types/",
52 "https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy",
53 "https://sec.okta.com/articles/2023/08/cross-tenant-impersonation-prevention-and-detection",
54 "https://www.okta.com/resources/whitepaper-how-adaptive-mfa-can-help-in-mitigating-brute-force-attacks/",
55 "https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security",
56 "https://www.elastic.co/security-labs/starter-guide-to-understanding-okta",
57]
58risk_score = 21
59rule_id = "23f18264-2d6d-11ef-9413-f661ea17fbce"
60setup = "The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."
61severity = "low"
62tags = [
63 "Domain: Identity",
64 "Use Case: Identity and Access Audit",
65 "Data Source: Okta",
66 "Tactic: Credential Access",
67 "Resources: Investigation Guide",
68]
69timestamp_override = "event.ingested"
70type = "esql"
71
72query = '''
73FROM logs-okta.system-* METADATA _id, _version, _index
74| WHERE
75 event.dataset == "okta.system"
76 AND (event.action LIKE "user.authentication.*" OR event.action == "user.session.start")
77 AND okta.outcome.reason IN ("INVALID_CREDENTIALS", "LOCKED_OUT")
78 AND okta.actor.alternate_id IS NOT NULL
79 // Primary authn endpoint; sessions API provides additional coverage
80 AND (
81 okta.debug_context.debug_data.request_uri == "/api/v1/authn"
82 OR okta.debug_context.debug_data.request_uri LIKE "/api/v1/sessions*"
83 )
84// Track whether each event has a device token
85| EVAL has_dt_hash = CASE(okta.debug_context.debug_data.dt_hash IS NOT NULL, 1, 0)
86// Aggregate by IP + user to detect single-user brute force
87| STATS
88 Esql.unique_dt_hashes = COUNT_DISTINCT(okta.debug_context.debug_data.dt_hash),
89 Esql.total_attempts = COUNT(*),
90 Esql.attempts_with_dt = SUM(has_dt_hash),
91 Esql.unique_user_agents = COUNT_DISTINCT(okta.client.user_agent.raw_user_agent),
92 Esql.first_seen = MIN(@timestamp),
93 Esql.last_seen = MAX(@timestamp),
94 Esql.dt_hash_values = VALUES(okta.debug_context.debug_data.dt_hash),
95 Esql.event_action_values = VALUES(event.action),
96 Esql.user_agent_values = VALUES(okta.client.user_agent.raw_user_agent),
97 Esql.device_values = VALUES(okta.client.device),
98 Esql.is_proxy_values = VALUES(okta.security_context.is_proxy),
99 Esql.geo_country_values = VALUES(client.geo.country_name),
100 Esql.geo_city_values = VALUES(client.geo.city_name),
101 Esql.source_asn_values = VALUES(source.as.number),
102 Esql.source_asn_org_values = VALUES(source.as.organization.name),
103 Esql.threat_suspected_values = VALUES(okta.debug_context.debug_data.threat_suspected),
104 Esql.risk_level_values = VALUES(okta.debug_context.debug_data.risk_level),
105 Esql.risk_reasons_values = VALUES(okta.debug_context.debug_data.risk_reasons)
106 BY okta.client.ip, okta.actor.alternate_id
107// Calculate automation detection metrics (float-safe division)
108| EVAL Esql.dt_coverage = Esql.attempts_with_dt * 1.0 / Esql.total_attempts,
109 Esql.dt_per_attempt = Esql.unique_dt_hashes * 1.0 / Esql.total_attempts
110// Detection branches:
111// A) Many unique DT hashes relative to attempts = tooling generating new tokens per attempt
112// B) High attempts + very low DT coverage = cookie-less automation (no DT sent at all)
113// C) Multiple user agents for same user = evasion or automation
114| WHERE
115 (Esql.unique_dt_hashes >= 7 AND Esql.total_attempts >= 10 AND Esql.dt_per_attempt >= 0.5)
116 OR (Esql.total_attempts >= 12 AND Esql.dt_coverage < 0.15)
117 OR (Esql.total_attempts >= 10 AND Esql.unique_user_agents >= 5)
118| SORT Esql.total_attempts DESC
119| KEEP Esql.*, okta.client.ip, okta.actor.alternate_id
120'''
121
122
123[[rule.threat]]
124framework = "MITRE ATT&CK"
125[[rule.threat.technique]]
126id = "T1110"
127name = "Brute Force"
128reference = "https://attack.mitre.org/techniques/T1110/"
129
130
131[rule.threat.tactic]
132id = "TA0006"
133name = "Credential Access"
134reference = "https://attack.mitre.org/tactics/TA0006/"
Triage and analysis
Investigating Potential Okta Brute Force (Device Token Rotation)
This rule identifies excessive unique device token hashes generated for a single user account, indicating automated brute force tooling that fails to persist browser cookies between authentication attempts.
Possible investigation steps
- Identify the targeted user account and determine if it has elevated privileges or sensitive access.
- Review the source IP and check if it belongs to known proxy, VPN, or cloud infrastructure.
- Examine user agent strings for signs of automation, scripting tools, or inconsistent browser fingerprints.
- Check if Okta flagged the source as a known threat or proxy.
- Determine if any authentication attempts succeeded following the failed attempts.
- Review the user's recent activity for signs of account compromise.
False positive analysis
- Users experiencing login issues may generate multiple device tokens through repeated legitimate attempts.
- Automated testing or monitoring tools that do not persist cookies may trigger this rule.
- Browser extensions or privacy tools that clear cookies between requests may cause device token rotation.
Response and remediation
- If attack is confirmed, reset the user's password immediately.
- Block the source IP at the network perimeter.
- Review and potentially reset MFA for the targeted account.
- Monitor for any successful authentication that may indicate compromise.
- Contact the user to verify if they experienced legitimate login issues.
References
Related rules
- Okta Successful Login After Credential Attack
- Potential Okta Brute Force (Multi-Source)
- Potential Okta Credential Stuffing (Single Source)
- Potential Okta Password Spray (Multi-Source)
- Potential Okta Password Spray (Single Source)