[New Rule] Okta MFA Bombing Attempt (#3278)

* new rule 'Potential Okta MFA Bombing via Push Notifications'

* updated naming

* TOML lint

* adjusted duplicate rule ID

* added event category override; added until sequence statement

* added verify authentication success

* moved setup to separate field

* enhanced query optimization

(cherry picked from commit e6fef85899)

rules/integrations/okta/credential_access_okta_mfa_bombing_via_push_notifications.toml

@@ -0,0 +1,95 @@
+[metadata]
+creation_date = "2023/11/18"
+integration = ["okta"]
+maturity = "production"
+min_stack_comments = "Breaking change in Okta integration bumping version to ^2.0.0"
+min_stack_version = "8.10.0"
+updated_date = "2023/11/27"
+
+[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*"]
+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/",
+]
+risk_score = 73
+rule_id = "8a0fbd26-867f-11ee-947c-f661ea17fbcd"
+setup = """
+The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.
+"""
+severity = "high"
+tags = ["Use Case: Identity and Access Audit", "Tactic: Credential Access", "Data Source: Okta"]
+type = "eql"
+
+query = '''
+sequence by okta.actor.id with maxspan=10m
+  [authentication where event.dataset == "okta.system"
+    and okta.event_type == "user.mfa.okta_verify.deny_push"] with runs=5
+  until [authentication where event.dataset == "okta.system"
+    and (okta.event_type: (
+      "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/"
+

rules/integrations/okta/credential_access_okta_potentially_successful_okta_bombing_via_push_notifications.toml

@@ -4,7 +4,7 @@ integration = ["okta"]
 maturity = "production"
 min_stack_comments = "Breaking change in Okta integration bumping version to ^2.0.0"
 min_stack_version = "8.10.0"
-updated_date = "2023/10/24"
+updated_date = "2023/11/27"
 
 [rule]
 author = ["Elastic"]
@@ -13,10 +13,11 @@ Detects when an attacker abuses the Multi-Factor authentication mechanism by rep
 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*"]
 language = "eql"
 license = "Elastic License v2"
-name = "Potential Abuse of Repeated MFA Push Notifications"
+name = "Potentially Successful MFA Bombing via Push Notifications"
 note = """## Triage and analysis
 
 ### Investigating Potential Abuse of Repeated MFA Push Notifications
@@ -57,6 +58,8 @@ The Okta Fleet integration, Filebeat module, or similarly structured data is req
 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/",
 ]
 risk_score = 73
 rule_id = "97a8e584-fd3b-421f-9b9d-9c9d9e57e9d7"
@@ -65,19 +68,24 @@ tags = ["Use Case: Identity and Access Audit", "Tactic: Credential Access", "Dat
 type = "eql"
 
 query = '''
-sequence by user.email with maxspan=10m
-  [any where event.dataset == "okta.system" and event.module == "okta" and event.action == "user.mfa.okta_verify.deny_push"]
-  [any where event.dataset == "okta.system" and event.module == "okta" and event.action == "user.mfa.okta_verify.deny_push"]
-  [any where event.dataset == "okta.system" and event.module == "okta" and event.action == "user.authentication.sso"]
+sequence by okta.actor.id with maxspan=10m
+  [authentication where event.dataset == "okta.system" and event.module == "okta"
+    and event.action == "user.mfa.okta_verify.deny_push"] with runs=3
+  [authentication where event.dataset == "okta.system" and event.module == "okta"
+    and (event.action : (
+      "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 = "T1110"
-name = "Brute Force"
-reference = "https://attack.mitre.org/techniques/T1110/"
+id = "T1621"
+name = "Multi-Factor Authentication Request Generation"
+reference = "https://attack.mitre.org/techniques/T1621/"
 
 
 [rule.threat.tactic]