Attempts to Brute Force an Okta User Account

Identifies when an Okta user account is locked out 3 times within a 3 hour window. An adversary may attempt a brute force or password spraying attack to obtain unauthorized access to user accounts. The default Okta authentication policy ensures that a user account is locked out after 10 failed authentication attempts.

Elastic rule (View on GitHub)

 1[metadata]
 2creation_date = "2020/08/19"
 3integration = ["okta"]
 4maturity = "production"
 5updated_date = "2024/12/09"
 6min_stack_version = "8.15.0"
 7min_stack_comments = "Breaking change at 8.15.0 for the Okta Integration."
 8
 9[rule]
10author = ["Elastic", "@BenB196", "Austin Songer"]
11description = """
12Identifies when an Okta user account is locked out 3 times within a 3 hour window. An adversary may attempt a brute
13force or password spraying attack to obtain unauthorized access to user accounts. The default Okta authentication policy
14ensures that a user account is locked out after 10 failed authentication attempts.
15"""
16from = "now-180m"
17index = ["filebeat-*", "logs-okta*"]
18language = "kuery"
19license = "Elastic License v2"
20name = "Attempts to Brute Force an Okta User Account"
21note = """## Triage and analysis
22
23### Investigating Attempts to Brute Force an Okta User Account
24
25Brute force attacks aim to guess user credentials through exhaustive trial-and-error attempts. In this context, Okta accounts are targeted.
26
27This rule fires when an Okta user account has been locked out 3 times within a 3-hour window. This could indicate an attempted brute force or password spraying attack to gain unauthorized access to the user account. Okta's default authentication policy locks a user account after 10 failed authentication attempts.
28
29#### Possible investigation steps:
30
31- Identify the actor related to the alert by reviewing `okta.actor.alternate_id` field in the alert. This should give the username of the account being targeted.
32- Review the `okta.event_type` field to understand the nature of the events that led to the account lockout.
33- Check the `okta.severity` and `okta.display_message` fields for more context around the lockout events.
34- Look for correlation of events from the same IP address. Multiple lockouts from the same IP address might indicate a single source for the attack.
35- If the IP is not familiar, investigate it. The IP could be a proxy, VPN, Tor node, cloud datacenter, or a legitimate IP turned malicious.
36- Determine if the lockout events occurred during the user's regular activity hours. Unusual timing may indicate malicious activity.
37- Examine the authentication methods used during the lockout events by checking the `okta.authentication_context.credential_type` field.
38
39### False positive analysis:
40
41- Determine whether the account owner or an internal user made repeated mistakes in entering their credentials, leading to the account lockout.
42- Ensure there are no known network or application issues that might cause these events.
43
44### Response and remediation:
45
46- Alert the user and your IT department immediately.
47- If unauthorized access is confirmed, initiate your incident response process.
48- Investigate the source of the attack. If a specific machine or network is compromised, additional steps may need to be taken to address the issue.
49- Require the affected user to change their password.
50- If the attack is ongoing, consider blocking the IP address initiating the brute force attack.
51- Implement account lockout policies to limit the impact of brute force attacks.
52- Encourage users to use complex, unique passwords and consider implementing multi-factor authentication.
53- Check if the compromised account was used to access or alter any sensitive data or systems.
54
55## Setup
56
57The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
58references = [
59    "https://developer.okta.com/docs/reference/api/system-log/",
60    "https://developer.okta.com/docs/reference/api/event-types/",
61    "https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy",
62    "https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security",
63    "https://www.elastic.co/security-labs/starter-guide-to-understanding-okta",
64]
65risk_score = 47
66rule_id = "e08ccd49-0380-4b2b-8d71-8000377d6e49"
67severity = "medium"
68tags = ["Use Case: Identity and Access Audit", "Tactic: Credential Access", "Data Source: Okta"]
69timestamp_override = "event.ingested"
70type = "threshold"
71
72query = '''
73event.dataset:okta.system and event.action:user.account.lock
74'''
75
76
77[[rule.threat]]
78framework = "MITRE ATT&CK"
79[[rule.threat.technique]]
80id = "T1110"
81name = "Brute Force"
82reference = "https://attack.mitre.org/techniques/T1110/"
83
84
85[rule.threat.tactic]
86id = "TA0006"
87name = "Credential Access"
88reference = "https://attack.mitre.org/tactics/TA0006/"
89
90[rule.threshold]
91field = ["okta.actor.alternate_id"]
92value = 3

Triage and analysis

Investigating Attempts to Brute Force an Okta User Account

Brute force attacks aim to guess user credentials through exhaustive trial-and-error attempts. In this context, Okta accounts are targeted.

This rule fires when an Okta user account has been locked out 3 times within a 3-hour window. This could indicate an attempted brute force or password spraying attack to gain unauthorized access to the user account. Okta's default authentication policy locks a user account after 10 failed authentication attempts.

Possible investigation steps:

  • Identify the actor related to the alert by reviewing okta.actor.alternate_id field in the alert. This should give the username of the account being targeted.
  • Review the okta.event_type field to understand the nature of the events that led to the account lockout.
  • Check the okta.severity and okta.display_message fields for more context around the lockout events.
  • Look for correlation of events from the same IP address. Multiple lockouts from the same IP address might indicate a single source for the attack.
  • If the IP is not familiar, investigate it. The IP could be a proxy, VPN, Tor node, cloud datacenter, or a legitimate IP turned malicious.
  • Determine if the lockout events occurred during the user's regular activity hours. Unusual timing may indicate malicious activity.
  • Examine the authentication methods used during the lockout events by checking the okta.authentication_context.credential_type field.

False positive analysis:

  • Determine whether the account owner or an internal user made repeated mistakes in entering their credentials, leading to the account lockout.
  • Ensure there are no known network or application issues that might cause these events.

Response and remediation:

  • Alert the user and your IT department immediately.
  • If unauthorized access is confirmed, initiate your incident response process.
  • Investigate the source of the attack. If a specific machine or network is compromised, additional steps may need to be taken to address the issue.
  • Require the affected user to change their password.
  • If the attack is ongoing, consider blocking the IP address initiating the brute force attack.
  • Implement account lockout policies to limit the impact of brute force attacks.
  • Encourage users to use complex, unique passwords and consider implementing multi-factor authentication.
  • Check if the compromised account was used to access or alter any sensitive data or systems.

Setup

The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.

References

Related rules

to-top