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

to-top