nldcsc-elastic-rules 0.0.8__py3-none-any.whl

nldcsc_elastic_rules/rules/integrations/okta/credential_access_okta_authentication_for_multiple_users_from_single_source.toml

@@ -0,0 +1,143 @@
+[metadata]
+creation_date = "2024/06/17"
+integration = ["okta"]
+maturity = "production"
+updated_date = "2025/09/25"
+
+[rule]
+author = ["Elastic"]
+description = """
+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 or password spraying attack from the same device by
+using a list of known usernames and passwords to gain unauthorized access to user accounts.
+"""
+false_positives = [
+    "Users may share an endpoint related to work or personal use in which separate Okta accounts are used.",
+    "Shared systems such as Kiosks and conference room computers may be used by multiple users.",
+]
+from = "now-9m"
+language = "esql"
+license = "Elastic License v2"
+name = "Multiple Okta User Authentication Events with Client Address"
+note = """## Triage and analysis
+
+### Investigating Multiple Okta User Authentication Events with Client Address
+
+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 ESQL 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.
+- 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.
+- 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.
+- 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, review `event.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.
+- 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.
+- 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 the `exceptions` 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 the `exceptions` 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 = [
+    "https://support.okta.com/help/s/article/How-does-the-Device-Token-work?language=en_US",
+    "https://developer.okta.com/docs/reference/api/event-types/",
+    "https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy",
+    "https://sec.okta.com/articles/2023/08/cross-tenant-impersonation-prevention-and-detection",
+    "https://www.okta.com/resources/whitepaper-how-adaptive-mfa-can-help-in-mitigating-brute-force-attacks/",
+    "https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security",
+    "https://www.elastic.co/security-labs/starter-guide-to-understanding-okta",
+]
+risk_score = 21
+rule_id = "94e734c0-2cda-11ef-84e1-f661ea17fbce"
+setup = "The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."
+severity = "low"
+tags = [
+    "Use Case: Identity and Access Audit",
+    "Data Source: Okta",
+    "Tactic: Credential Access",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "esql"
+
+query = '''
+from logs-okta*
+| where
+    event.dataset == "okta.system" and
+    (event.action == "user.session.start" or event.action like "user.authentication.*") and
+    okta.outcome.reason == "INVALID_CREDENTIALS"
+| keep
+    okta.client.ip,
+    okta.actor.alternate_id,
+    okta.actor.id,
+    event.action,
+    okta.outcome.reason
+| stats
+    Esql.okta_actor_id_count_distinct = count_distinct(okta.actor.id)
+  by
+    okta.client.ip,
+    okta.actor.alternate_id
+| where
+    Esql.okta_actor_id_count_distinct > 5
+| sort
+    Esql.okta_actor_id_count_distinct desc
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1110"
+name = "Brute Force"
+reference = "https://attack.mitre.org/techniques/T1110/"
+[[rule.threat.technique.subtechnique]]
+id = "T1110.003"
+name = "Password Spraying"
+reference = "https://attack.mitre.org/techniques/T1110/003/"
+
+
+[[rule.threat.technique]]
+id = "T1110"
+name = "Brute Force"
+reference = "https://attack.mitre.org/techniques/T1110/"
+[[rule.threat.technique.subtechnique]]
+id = "T1110.004"
+name = "Credential Stuffing"
+reference = "https://attack.mitre.org/techniques/T1110/004/"
+
+
+
+[rule.threat.tactic]
+id = "TA0006"
+name = "Credential Access"
+reference = "https://attack.mitre.org/tactics/TA0006/"
+

nldcsc_elastic_rules/rules/integrations/okta/credential_access_okta_authentication_for_multiple_users_with_the_same_device_token_hash.toml

@@ -0,0 +1,141 @@
+[metadata]
+creation_date = "2024/06/17"
+integration = ["okta"]
+maturity = "production"
+updated_date = "2025/09/25"
+
+[rule]
+author = ["Elastic"]
+description = """
+Detects when a high number of Okta user authentication events are reported for multiple users in a short time frame.
+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.
+"""
+false_positives = [
+    "Users may share an endpoint related to work or personal use in which separate Okta accounts are used.",
+    "Shared systems such as Kiosks and conference room computers may be used by multiple users.",
+]
+from = "now-9m"
+language = "esql"
+license = "Elastic License v2"
+name = "Multiple Okta User Authentication Events with Same Device Token Hash"
+note = """## Triage and analysis
+
+### Investigating Multiple Okta User Authentication Events with Same Device Token Hash
+
+This rule detects when a high number of Okta user authentication events are reported for multiple users in a short time frame. 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 ESQL rule, the `okta.actor.alternate_id` and `okta.debug_context.debug_data.dt_hash` 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`, and `okta.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`, and `okta.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, review `event.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.
+- 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.
+- 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 the `exceptions` list in the rule.
+    - This will prevent future occurrences of this event for this device from triggering the rule.
+"""
+references = [
+    "https://support.okta.com/help/s/article/How-does-the-Device-Token-work?language=en_US",
+    "https://developer.okta.com/docs/reference/api/event-types/",
+    "https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy",
+    "https://sec.okta.com/articles/2023/08/cross-tenant-impersonation-prevention-and-detection",
+    "https://www.okta.com/resources/whitepaper-how-adaptive-mfa-can-help-in-mitigating-brute-force-attacks/",
+    "https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security",
+    "https://www.elastic.co/security-labs/starter-guide-to-understanding-okta",
+]
+risk_score = 21
+rule_id = "95b99adc-2cda-11ef-84e1-f661ea17fbce"
+setup = "The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."
+severity = "low"
+tags = [
+    "Use Case: Identity and Access Audit",
+    "Data Source: Okta",
+    "Tactic: Credential Access",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "esql"
+
+query = '''
+from logs-okta*
+| where
+    event.dataset == "okta.system" and
+    (event.action like "user.authentication.*" or event.action == "user.session.start") and
+    okta.debug_context.debug_data.dt_hash != "-" and
+    okta.outcome.reason == "INVALID_CREDENTIALS"
+| keep
+    event.action,
+    okta.debug_context.debug_data.dt_hash,
+    okta.actor.id,
+    okta.actor.alternate_id,
+    okta.outcome.reason
+| stats
+    Esql.okta_actor_id_count_distinct = count_distinct(okta.actor.id)
+  by
+    okta.debug_context.debug_data.dt_hash,
+    okta.actor.alternate_id
+| where
+    Esql.okta_actor_id_count_distinct > 20
+| sort
+    Esql.okta_actor_id_count_distinct desc
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1110"
+name = "Brute Force"
+reference = "https://attack.mitre.org/techniques/T1110/"
+[[rule.threat.technique.subtechnique]]
+id = "T1110.003"
+name = "Password Spraying"
+reference = "https://attack.mitre.org/techniques/T1110/003/"
+
+
+[[rule.threat.technique]]
+id = "T1110"
+name = "Brute Force"
+reference = "https://attack.mitre.org/techniques/T1110/"
+[[rule.threat.technique.subtechnique]]
+id = "T1110.004"
+name = "Credential Stuffing"
+reference = "https://attack.mitre.org/techniques/T1110/004/"
+
+
+
+[rule.threat.tactic]
+id = "TA0006"
+name = "Credential Access"
+reference = "https://attack.mitre.org/tactics/TA0006/"
+

nldcsc_elastic_rules/rules/integrations/okta/credential_access_okta_brute_force_or_password_spraying.toml

@@ -0,0 +1,96 @@
+[metadata]
+creation_date = "2020/07/16"
+integration = ["okta"]
+maturity = "production"
+updated_date = "2025/07/02"
+
+[rule]
+author = ["Elastic"]
+description = """
+Identifies a high number of failed Okta user authentication attempts from a single IP address, which could be indicative
+of a brute force or password spraying attack. An adversary may attempt a brute force or password spraying attack to
+obtain unauthorized access to user accounts.
+"""
+false_positives = [
+    """
+    Automated processes that attempt to authenticate using expired credentials and unbounded retries may lead to false
+    positives.
+    """,
+]
+index = ["filebeat-*", "logs-okta*"]
+language = "kuery"
+license = "Elastic License v2"
+name = "Okta Brute Force or Password Spraying Attack"
+note = """## Triage and analysis
+
+### Investigating Okta Brute Force or Password Spraying Attack
+
+This rule alerts when a high number of failed Okta user authentication attempts occur from a single IP address. This could be indicative of a brute force or password spraying attack, where an adversary may attempt to gain unauthorized access to user accounts by guessing the passwords.
+
+#### Possible investigation steps:
+
+- Review the `source.ip` field to identify the IP address from which the high volume of failed login attempts originated.
+- Look into the `event.outcome` field to verify that these are indeed failed authentication attempts.
+- Determine the `user.name` or `user.email` related to these failed login attempts. If the attempts are spread across multiple accounts, it might indicate a password spraying attack.
+- Check the timeline of the events. Are the failed attempts spread out evenly, or are there burst periods, which might indicate an automated tool?
+- Determine the geographical location of the source IP. Is this location consistent with the user's typical login location?
+- Analyze any previous successful logins from this IP. Was this IP previously associated with successful logins?
+
+### False positive analysis:
+
+- A single user or automated process that attempts to authenticate using expired or wrong credentials multiple times may trigger a false positive.
+- Analyze the behavior of the source IP. If the IP is associated with legitimate users or services, it may be a false positive.
+
+### Response and remediation:
+
+- If you identify unauthorized access attempts, consider blocking the source IP at the firewall level.
+- Notify the users who are targeted by the attack. Ask them to change their passwords and ensure they use unique, complex passwords.
+- Enhance monitoring on the affected user accounts for any suspicious activity.
+- If the attack is persistent, consider implementing CAPTCHA or account lockouts after a certain number of failed login attempts.
+- If the attack is persistent, consider implementing multi-factor authentication (MFA) for the affected user accounts.
+- Review and update your security policies based on the findings from the incident.
+
+## Setup
+
+The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
+references = [
+    "https://developer.okta.com/docs/reference/api/system-log/",
+    "https://developer.okta.com/docs/reference/api/event-types/",
+    "https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy",
+    "https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security",
+    "https://www.elastic.co/security-labs/starter-guide-to-understanding-okta",
+]
+risk_score = 47
+rule_id = "42bf698b-4738-445b-8231-c834ddefd8a0"
+severity = "medium"
+tags = [
+    "Use Case: Identity and Access Audit",
+    "Tactic: Credential Access",
+    "Data Source: Okta",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "threshold"
+
+query = '''
+event.dataset:okta.system and event.category:authentication and event.outcome:failure
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1110"
+name = "Brute Force"
+reference = "https://attack.mitre.org/techniques/T1110/"
+
+
+[rule.threat.tactic]
+id = "TA0006"
+name = "Credential Access"
+reference = "https://attack.mitre.org/tactics/TA0006/"
+
+[rule.threshold]
+field = ["source.ip"]
+value = 25
+

nldcsc_elastic_rules/rules/integrations/okta/credential_access_okta_mfa_bombing_via_push_notifications.toml

@@ -0,0 +1,113 @@
+[metadata]
+creation_date = "2023/11/18"
+integration = ["okta"]
+maturity = "production"
+updated_date = "2025/09/10"
+
+[rule]
+author = ["Elastic"]
+description = """
+Detects when an attacker abuses the Multi-Factor authentication mechanism by repeatedly issuing login requests until the
+user eventually accepts the Okta push notification. An adversary may attempt to bypass the Okta MFA policies configured
+for an organization to obtain unauthorized access.
+"""
+event_category_override = "event.category"
+index = ["filebeat-*", "logs-okta.system*"]
+language = "eql"
+license = "Elastic License v2"
+name = "Potential Okta MFA Bombing via Push Notifications"
+note = """## Triage and analysis
+
+### Investigating Potential Okta MFA Bombing via Push Notifications
+
+Multi-Factor Authentication (MFA) is an effective method to prevent unauthorized access. However, some adversaries may abuse the system by repeatedly sending MFA push notifications until the user unwittingly approves the access.
+
+This rule detects when a user denies MFA Okta Verify push notifications twice, followed by a successful authentication event within a 10-minute window. This sequence could indicate an adversary's attempt to bypass the Okta MFA policy.
+
+#### Possible investigation steps:
+
+- Identify the user who received the MFA notifications by reviewing the `user.email` field.
+- Identify the time, source IP, and geographical location of the MFA requests and the subsequent successful login.
+- Review the `event.action` field to understand the nature of the events. It should include two `user.mfa.okta_verify.deny_push` actions and one `user.authentication.sso` action.
+- Ask the user if they remember receiving the MFA notifications and subsequently logging into their account.
+- Check if the MFA requests and the successful login occurred during the user's regular activity hours.
+- Look for any other suspicious activity on the account around the same time.
+- Identify whether the same pattern is repeated for other users in your organization. Multiple users receiving push notifications simultaneously might indicate a larger attack.
+
+### False positive analysis:
+
+- Determine if the MFA push notifications were legitimate. Sometimes, users accidentally trigger MFA requests or deny them unintentionally and later approve them.
+- Check if there are known issues with the MFA system causing false denials.
+
+### Response and remediation:
+
+- If unauthorized access is confirmed, initiate your incident response process.
+- Alert the user and your IT department immediately.
+- If possible, isolate the user's account until the issue is resolved.
+- Investigate the source of the unauthorized access.
+- If the account was accessed by an unauthorized party, determine the actions they took after logging in.
+- Consider enhancing your MFA policy to prevent such incidents in the future.
+- Encourage users to report any unexpected MFA notifications immediately.
+- Review and update your incident response plans and security policies based on the findings from the incident.
+"""
+references = [
+    "https://www.mandiant.com/resources/russian-targeting-gov-business",
+    "https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy",
+    "https://sec.okta.com/articles/2023/08/cross-tenant-impersonation-prevention-and-detection",
+    "https://www.rezonate.io/blog/okta-logs-decoded-unveiling-identity-threats-through-threat-hunting/",
+    "https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security",
+    "https://www.elastic.co/security-labs/starter-guide-to-understanding-okta",
+]
+risk_score = 73
+rule_id = "8a0fbd26-867f-11ee-947c-f661ea17fbcd"
+severity = "high"
+tags = [
+    "Domain: Identity",
+    "Use Case: Identity and Access Audit",
+    "Tactic: Credential Access",
+    "Data Source: Okta",
+    "Data Source: Okta System Logs",
+    "Resources: Investigation Guide",
+]
+type = "eql"
+
+query = '''
+sequence by okta.actor.id with maxspan=10m
+  [ any
+    where event.dataset == "okta.system"
+      and (
+        okta.event_type == "user.mfa.okta_verify.deny_push"
+        or (
+          okta.event_type == "user.authentication.auth_via_mfa"
+          and okta.debug_context.debug_data.factor == "OKTA_VERIFY_PUSH"
+          and okta.outcome.reason == "INVALID_CREDENTIALS"
+        )
+      )
+  ] with runs=5
+  until
+  [ any
+    where event.dataset == "okta.system"
+      and okta.event_type in (
+        "user.authentication.sso",
+        "user.authentication.auth_via_mfa",
+        "user.authentication.verify",
+        "user.session.start"
+      )
+      and okta.outcome.result == "SUCCESS"
+  ]
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1621"
+name = "Multi-Factor Authentication Request Generation"
+reference = "https://attack.mitre.org/techniques/T1621/"
+
+
+[rule.threat.tactic]
+id = "TA0006"
+name = "Credential Access"
+reference = "https://attack.mitre.org/tactics/TA0006/"
+

nldcsc_elastic_rules/rules/integrations/okta/credential_access_okta_multiple_device_token_hashes_for_single_user.toml

@@ -0,0 +1,146 @@
+[metadata]
+creation_date = "2024/06/17"
+integration = ["okta"]
+maturity = "production"
+updated_date = "2025/09/25"
+
+[rule]
+author = ["Elastic"]
+description = """
+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.
+"""
+false_positives = [
+    "Users may share an endpoint related to work or personal use in which separate Okta accounts are used.",
+    "Shared systems such as Kiosks and conference room computers may be used by multiple users.",
+]
+from = "now-9m"
+language = "esql"
+license = "Elastic License v2"
+name = "High Number of Okta Device Token Cookies Generated for Authentication"
+note = """## 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 ESQL 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.
+- 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.
+- 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.
+- 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, review `event.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.
+- 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.
+- 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 the `exceptions` 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 the `exceptions` 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 = [
+    "https://support.okta.com/help/s/article/How-does-the-Device-Token-work?language=en_US",
+    "https://developer.okta.com/docs/reference/api/event-types/",
+    "https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy",
+    "https://sec.okta.com/articles/2023/08/cross-tenant-impersonation-prevention-and-detection",
+    "https://www.okta.com/resources/whitepaper-how-adaptive-mfa-can-help-in-mitigating-brute-force-attacks/",
+    "https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security",
+    "https://www.elastic.co/security-labs/starter-guide-to-understanding-okta",
+]
+risk_score = 21
+rule_id = "23f18264-2d6d-11ef-9413-f661ea17fbce"
+setup = "The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."
+severity = "low"
+tags = [
+    "Use Case: Identity and Access Audit",
+    "Data Source: Okta",
+    "Tactic: Credential Access",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "esql"
+
+query = '''
+from logs-okta*
+| where
+    event.dataset == "okta.system" and
+    (event.action like "user.authentication.*" or event.action == "user.session.start") and
+    okta.debug_context.debug_data.request_uri == "/api/v1/authn" and
+    okta.outcome.reason == "INVALID_CREDENTIALS"
+| 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
+| stats
+    Esql.okta_debug_context_debug_data_dt_hash_count_distinct = count_distinct(okta.debug_context.debug_data.dt_hash)
+  by
+    okta.client.ip,
+    okta.actor.alternate_id
+| where
+    Esql.okta_debug_context_debug_data_dt_hash_count_distinct >= 30
+| sort
+    Esql.okta_debug_context_debug_data_dt_hash_count_distinct desc
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1110"
+name = "Brute Force"
+reference = "https://attack.mitre.org/techniques/T1110/"
+[[rule.threat.technique.subtechnique]]
+id = "T1110.003"
+name = "Password Spraying"
+reference = "https://attack.mitre.org/techniques/T1110/003/"
+
+
+[[rule.threat.technique]]
+id = "T1110"
+name = "Brute Force"
+reference = "https://attack.mitre.org/techniques/T1110/"
+[[rule.threat.technique.subtechnique]]
+id = "T1110.004"
+name = "Credential Stuffing"
+reference = "https://attack.mitre.org/techniques/T1110/004/"
+
+
+
+[rule.threat.tactic]
+id = "TA0006"
+name = "Credential Access"
+reference = "https://attack.mitre.org/tactics/TA0006/"
+