[New Rule] Adding Detection for Stolen Credentials Used to Login to O…

…kta Account After MFA Reset (#3265)

* adding new rule 'Stolen Credentials Used to Login to Okta Account After MFA Reset'

* updated non-ecs; linted rule; updated description

* adjusted interval and maxspan

* Update rules/integrations/okta/persistence_stolen_credentials_used_to_login_to_okta_account_after_mfa_reset.toml

Co-authored-by: Jonhnathan <26856693+w0rk3r@users.noreply.github.com>

* Update rules/integrations/okta/persistence_stolen_credentials_used_to_login_to_okta_account_after_mfa_reset.toml

Co-authored-by: Jonhnathan <26856693+w0rk3r@users.noreply.github.com>

* Update rules/integrations/okta/persistence_stolen_credentials_used_to_login_to_okta_account_after_mfa_reset.toml

Co-authored-by: Jonhnathan <26856693+w0rk3r@users.noreply.github.com>

* Update rules/integrations/okta/persistence_stolen_credentials_used_to_login_to_okta_account_after_mfa_reset.toml

---------

Co-authored-by: Jonhnathan <26856693+w0rk3r@users.noreply.github.com>

detection_rules/etc/non-ecs-schema.json

@@ -51,7 +51,7 @@
         "ImagePath": "keyword",
         "TaskName": "keyword",
         "Status": "keyword",
-        "EnabledPrivilegeList": "keyword", 
+        "EnabledPrivilegeList": "keyword",
         "Operation": "keyword",
         "OperationType": "keyword"
       }
@@ -114,6 +114,7 @@
   },
   ".alerts-security.*": {
     "signal.rule.name": "keyword",
+    "signal.rule.threat.tactic.name": "keyword",
     "kibana.alert.rule.threat.tactic.id": "keyword",
     "kibana.alert.rule.rule_id": "keyword"
   },

rules/integrations/okta/persistence_stolen_credentials_used_to_login_to_okta_account_after_mfa_reset.toml

@@ -0,0 +1,103 @@
+[metadata]
+creation_date = "2023/11/09"
+integration = ["endpoint", "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/10"
+
+[rule]
+author = ["Elastic"]
+description = """
+Detects a sequence of suspicious activities on Windows hosts indicative of credential compromise, followed by efforts to
+undermine multi-factor authentication (MFA) and single sign-on (SSO) mechanisms for an Okta user account.
+"""
+false_positives = [
+    """
+    A Windows administrator may have triggered a low-fidelity credential access alert during a legitimate administrative
+    action. Following this, the administrator may have reset the MFA credentials for themselves and then logged into the
+    Okta console for AD directory services integration management.
+    """,
+]
+from = "now-12h"
+index = ["filebeat-*", "logs-okta*", ".alerts-security.*", "logs-endpoint.events.*"]
+interval = "6h"
+language = "eql"
+license = "Elastic License v2"
+name = "Stolen Credentials Used to Login to Okta Account After MFA Reset"
+note = """## Triage and analysis
+
+### Investigating Stolen Credentials Used to Login to Okta Account After MFA Reset
+
+This rule detects a sequence of suspicious activities on Windows hosts indicative of credential compromise, followed by efforts to undermine multi-factor authentication (MFA) and single sign-on (SSO) mechanisms for an Okta user account.
+
+Typically, adversaries initially extract credentials from targeted endpoints through various means. Subsequently, leveraging social engineering, they may seek to reset the MFA credentials associated with an Okta account, especially in scenarios where Active Directory (AD) services are integrated with Okta. Successfully resetting MFA allows the unauthorized use of stolen credentials to gain access to the compromised Okta account. The attacker can then register their own device for MFA, paving the way for unfettered access to the user's Okta account and any associated SaaS applications. This is particularly alarming if the compromised account has administrative rights, as it could lead to widespread access to organizational resources and configurations.
+
+#### Possible investigation steps:
+- Identify the user account associated with the Okta login attempt by examining the `user.name` field.
+- Identify the endpoint for the Credential Access alert for this user by examining the `host.name` and `host.id` fields from the alert document.
+- Cross-examine the Okta user and endpoint user to confirm that they are the same person.
+- Reach out to the user to confirm if they have intentionally reset their MFA credentials recently or asked for help in doing so.
+- If the user is unaware of the MFA reset, incident response may be required immediately to prevent further compromise.
+
+### False positive analysis:
+- A Windows administrator may have triggered a low-fidelity credential access alert during a legitimate administrative action. Following this, the administrator may have reset the MFA credentials for themselves and then logged into the Okta console for AD directory services integration management.
+
+### Response and remediation:
+- If confirmed that the user did not intentionally have their MFA factor reset, deactivate the user account.
+- After deactivation, reset the user's password and MFA factor to regain control of the account.
+    - Ensure that all user sessions are stopped during this process.
+- Immediately reset the user's AD password as well if Okta does not sync back to AD.
+- Forensic analysis on the user's endpoint may be required to determine the root cause of the compromise and identify the scope of the compromise.
+- Review Okta system logs to identify any other suspicious activity associated with the user account, such as creation of a backup account.
+- With the device ID captured from the MFA factor reset, search across all Okta logs for any other activity associated with the device ID.
+
+## Setup
+The Okta and Elastic Defend fleet integration structured data is required to be compatible with this rule. Directory services integration in Okta with AD synced is also required for this rule to be effective as it relies on triaging `user.name` from Okta and Elastic Defend events.
+"""
+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://sec.okta.com/articles/2023/08/cross-tenant-impersonation-prevention-and-detection",
+]
+risk_score = 73
+rule_id = "5610b192-7f18-11ee-825b-f661ea17fbcd"
+severity = "high"
+tags = [
+    "Tactic: Persistence",
+    "Use Case: Identity and Access Audit",
+    "Data Source: Okta",
+    "Data Source: Elastic Defend",
+    "Rule Type: Higher-Order Rule",
+    "Domain: Endpoint",
+    "Domain: Cloud",
+]
+type = "eql"
+
+query = '''
+sequence by user.name with maxspan=12h
+    [any where host.os.type == "windows" and signal.rule.threat.tactic.name == "Credential Access"]
+    [any where event.dataset == "okta.system" and okta.event_type == "user.mfa.factor.update"]
+    [any where event.dataset == "okta.system" and okta.event_type: ("user.session.start", "user.authentication*")]
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1556"
+name = "Modify Authentication Process"
+reference = "https://attack.mitre.org/techniques/T1556/"
+[[rule.threat.technique.subtechnique]]
+id = "T1556.006"
+name = "Multi-Factor Authentication"
+reference = "https://attack.mitre.org/techniques/T1556/006/"
+
+
+
+[rule.threat.tactic]
+id = "TA0003"
+name = "Persistence"
+reference = "https://attack.mitre.org/tactics/TA0003/"
+