High Number of Okta Device Token Cookies Generated for Authentication
Detects when an Okta client address has a certain threshold of Okta user authentication events with multiple device token hashes generated for single user authentication. Adversaries may attempt to launch a credential stuffing or password spraying attack from the same device by using a list of known usernames and passwords to gain unauthorized access to user accounts.
Elastic rule (View on GitHub)
1[metadata]
2creation_date = "2024/06/17"
3integration = ["okta"]
4maturity = "production"
5min_stack_comments = "ES|QL rule type becomes available in 8.13.0 as technical preview."
6min_stack_version = "8.13.0"
7updated_date = "2024/10/09"
8
9[rule]
10author = ["Elastic"]
11description = """
12Detects when an Okta client address has a certain threshold of Okta user authentication events with multiple device token hashes generated for single user authentication. Adversaries may attempt to launch a credential stuffing or password spraying attack from the same device by using a list of known usernames and passwords to gain unauthorized access to user accounts.
13"""
14false_positives = [
15 "Users may share an endpoint related to work or personal use in which separate Okta accounts are used.",
16 "Shared systems such as Kiosks and conference room computers may be used by multiple users.",
17]
18from = "now-9m"
19language = "esql"
20license = "Elastic License v2"
21name = "High Number of Okta Device Token Cookies Generated for Authentication"
22note = """## Triage and analysis
23
24### Investigating High Number of Okta Device Token Cookies Generated for Authentication
25
26This rule detects when a certain threshold of Okta user authentication events are reported for multiple users from the same client address. Adversaries may attempt to launch a credential stuffing attack from the same device by using a list of known usernames and passwords to gain unauthorized access to user accounts. Note that Okta does not log unrecognized usernames supplied during authentication attempts, so this rule may not detect all credential stuffing attempts or may indicate a targeted attack.
27
28#### Possible investigation steps:
29- Since this is an ES|QL rule, the `okta.actor.alternate_id` and `okta.client.ip` values can be used to pivot into the raw authentication events related to this activity.
30- Identify the users involved in this action by examining the `okta.actor.id`, `okta.actor.type`, `okta.actor.alternate_id`, and `okta.actor.display_name` fields.
31- Determine the device client used for these actions by analyzing `okta.client.ip`, `okta.client.user_agent.raw_user_agent`, `okta.client.zone`, `okta.client.device`, and `okta.client.id` fields.
32- Review the `okta.security_context.is_proxy` field to determine if the device is a proxy.
33 - If the device is a proxy, this may indicate that a user is using a proxy to access multiple accounts for password spraying.
34- With the list of `okta.actor.alternate_id` values, review `event.outcome` results to determine if the authentication was successful.
35 - If the authentication was successful for any user, pivoting to `event.action` values for those users may provide additional context.
36- With Okta end users identified, review the `okta.debug_context.debug_data.dt_hash` field.
37 - Historical analysis should indicate if this device token hash is commonly associated with the user.
38- Review the `okta.event_type` field to determine the type of authentication event that occurred.
39 - If the event type is `user.authentication.sso`, the user may have legitimately started a session via a proxy for security or privacy reasons.
40 - If the event type is `user.authentication.password`, the user may be using a proxy to access multiple accounts for password spraying.
41 - If the event type is `user.session.start`, the source may have attempted to establish a session via the Okta authentication API.
42- Examine the `okta.outcome.result` field to determine if the authentication was successful.
43- Review the past activities of the actor(s) involved in this action by checking their previous actions.
44- Evaluate the actions that happened just before and after this event in the `okta.event_type` field to help understand the full context of the activity.
45 - This may help determine the authentication and authorization actions that occurred between the user, Okta and application.
46
47### False positive analysis:
48- A user may have legitimately started a session via a proxy for security or privacy reasons.
49- Users may share an endpoint related to work or personal use in which separate Okta accounts are used.
50 - Architecturally, this shared endpoint may leverage a proxy for security or privacy reasons.
51 - Shared systems such as Kiosks and conference room computers may be used by multiple users.
52 - Shared working spaces may have a single endpoint that is used by multiple users.
53
54### Response and remediation:
55- Review the profile of the users involved in this action to determine if proxy usage may be expected.
56- If the user is legitimate and the authentication behavior is not suspicious based on device analysis, no action is required.
57- If the user is legitimate but the authentication behavior is suspicious, consider resetting passwords for the users involves and enabling multi-factor authentication (MFA).
58 - If MFA is already enabled, consider resetting MFA for the users.
59- If any of the users are not legitimate, consider deactivating the user's account.
60- Conduct a review of Okta policies and ensure they are in accordance with security best practices.
61- Check with internal IT teams to determine if the accounts involved recently had MFA reset at the request of the user.
62 - If so, confirm with the user this was a legitimate request.
63 - If so and this was not a legitimate request, consider deactivating the user's account temporarily.
64 - Reset passwords and reset MFA for the user.
65- If this is a false positive, consider adding the `okta.debug_context.debug_data.dt_hash` field to the `exceptions` list in the rule.
66 - This will prevent future occurrences of this event for this device from triggering the rule.
67 - Alternatively adding `okta.client.ip` or a CIDR range to the `exceptions` list can prevent future occurrences of this event from triggering the rule.
68 - This should be done with caution as it may prevent legitimate alerts from being generated.
69"""
70references = [
71 "https://support.okta.com/help/s/article/How-does-the-Device-Token-work?language=en_US",
72 "https://developer.okta.com/docs/reference/api/event-types/",
73 "https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy",
74 "https://sec.okta.com/articles/2023/08/cross-tenant-impersonation-prevention-and-detection",
75 "https://www.okta.com/resources/whitepaper-how-adaptive-mfa-can-help-in-mitigating-brute-force-attacks/",
76 "https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security",
77 "https://www.elastic.co/security-labs/starter-guide-to-understanding-okta",
78]
79risk_score = 21
80rule_id = "23f18264-2d6d-11ef-9413-f661ea17fbce"
81setup = "The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."
82severity = "low"
83tags = ["Use Case: Identity and Access Audit", "Data Source: Okta", "Tactic: Credential Access"]
84timestamp_override = "event.ingested"
85type = "esql"
86
87query = '''
88FROM logs-okta*
89| WHERE
90 event.dataset == "okta.system"
91 AND (event.action RLIKE "user\\.authentication(.*)" OR event.action == "user.session.start")
92 AND okta.debug_context.debug_data.request_uri == "/api/v1/authn"
93 AND okta.outcome.reason == "INVALID_CREDENTIALS"
94| KEEP event.action, okta.debug_context.debug_data.dt_hash, okta.client.ip, okta.actor.alternate_id, okta.debug_context.debug_data.request_uri, okta.outcome.reason
95| STATS
96 source_auth_count = COUNT_DISTINCT(okta.debug_context.debug_data.dt_hash)
97 BY okta.client.ip, okta.actor.alternate_id
98| WHERE
99 source_auth_count >= 30
100| SORT
101 source_auth_count DESC
102'''
103
104
105[[rule.threat]]
106framework = "MITRE ATT&CK"
107[[rule.threat.technique]]
108id = "T1110"
109name = "Brute Force"
110reference = "https://attack.mitre.org/techniques/T1110/"
111
112 [[rule.threat.technique.subtechnique]]
113 id = "T1110.003"
114 name = "Password Spraying"
115 reference = "https://attack.mitre.org/techniques/T1110/003/"
116
117[[rule.threat.technique]]
118id = "T1110"
119name = "Brute Force"
120reference = "https://attack.mitre.org/techniques/T1110/"
121
122 [[rule.threat.technique.subtechnique]]
123 id = "T1110.004"
124 name = "Credential Stuffing"
125 reference = "https://attack.mitre.org/techniques/T1110/004/"
126
127[rule.threat.tactic]
128id = "TA0006"
129name = "Credential Access"
130reference = "https://attack.mitre.org/tactics/TA0006/"
Triage and analysis
Investigating High Number of Okta Device Token Cookies Generated for Authentication
This rule detects when a certain threshold of Okta user authentication events are reported for multiple users from the same client address. Adversaries may attempt to launch a credential stuffing attack from the same device by using a list of known usernames and passwords to gain unauthorized access to user accounts. Note that Okta does not log unrecognized usernames supplied during authentication attempts, so this rule may not detect all credential stuffing attempts or may indicate a targeted attack.
Possible investigation steps:
- Since this is an ES|QL rule, the
okta.actor.alternate_id
andokta.client.ip
values can be used to pivot into the raw authentication events related to this activity. - Identify the users involved in this action by examining the
okta.actor.id
,okta.actor.type
,okta.actor.alternate_id
, andokta.actor.display_name
fields. - Determine the device client used for these actions by analyzing
okta.client.ip
,okta.client.user_agent.raw_user_agent
,okta.client.zone
,okta.client.device
, andokta.client.id
fields. - Review the
okta.security_context.is_proxy
field to determine if the device is a proxy.- If the device is a proxy, this may indicate that a user is using a proxy to access multiple accounts for password spraying.
- With the list of
okta.actor.alternate_id
values, reviewevent.outcome
results to determine if the authentication was successful.- If the authentication was successful for any user, pivoting to
event.action
values for those users may provide additional context.
- If the authentication was successful for any user, pivoting to
- With Okta end users identified, review the
okta.debug_context.debug_data.dt_hash
field.- Historical analysis should indicate if this device token hash is commonly associated with the user.
- Review the
okta.event_type
field to determine the type of authentication event that occurred.- If the event type is
user.authentication.sso
, the user may have legitimately started a session via a proxy for security or privacy reasons. - If the event type is
user.authentication.password
, the user may be using a proxy to access multiple accounts for password spraying. - If the event type is
user.session.start
, the source may have attempted to establish a session via the Okta authentication API.
- If the event type is
- Examine the
okta.outcome.result
field to determine if the authentication was successful. - Review the past activities of the actor(s) involved in this action by checking their previous actions.
- Evaluate the actions that happened just before and after this event in the
okta.event_type
field to help understand the full context of the activity.- This may help determine the authentication and authorization actions that occurred between the user, Okta and application.
False positive analysis:
- A user may have legitimately started a session via a proxy for security or privacy reasons.
- Users may share an endpoint related to work or personal use in which separate Okta accounts are used.
- Architecturally, this shared endpoint may leverage a proxy for security or privacy reasons.
- Shared systems such as Kiosks and conference room computers may be used by multiple users.
- Shared working spaces may have a single endpoint that is used by multiple users.
Response and remediation:
- Review the profile of the users involved in this action to determine if proxy usage may be expected.
- If the user is legitimate and the authentication behavior is not suspicious based on device analysis, no action is required.
- If the user is legitimate but the authentication behavior is suspicious, consider resetting passwords for the users involves and enabling multi-factor authentication (MFA).
- If MFA is already enabled, consider resetting MFA for the users.
- If any of the users are not legitimate, consider deactivating the user's account.
- Conduct a review of Okta policies and ensure they are in accordance with security best practices.
- Check with internal IT teams to determine if the accounts involved recently had MFA reset at the request of the user.
- If so, confirm with the user this was a legitimate request.
- If so and this was not a legitimate request, consider deactivating the user's account temporarily.
- Reset passwords and reset MFA for the user.
- If this is a false positive, consider adding the
okta.debug_context.debug_data.dt_hash
field to theexceptions
list in the rule.- This will prevent future occurrences of this event for this device from triggering the rule.
- Alternatively adding
okta.client.ip
or a CIDR range to theexceptions
list can prevent future occurrences of this event from triggering the rule.- This should be done with caution as it may prevent legitimate alerts from being generated.
References
Related rules
- Multiple Device Token Hashes for Single Okta Session
- Multiple Okta User Authentication Events with Client Address
- Multiple Okta User Authentication Events with Same Device Token Hash
- Attempted Bypass of Okta MFA
- Attempts to Brute Force an Okta User Account