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
andokta.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
- Attempted Bypass of Okta MFA
- High Number of Okta Device Token Cookies Generated for Authentication
- Multiple Device Token Hashes for Single Okta Session
- Multiple Okta User Auth Events with Same Device Token Hash Behind a Proxy
- Multiple Okta User Authentication Events with Client Address