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

nldcsc_elastic_rules/rules/integrations/okta/persistence_attempt_to_create_okta_api_token.toml

@@ -0,0 +1,98 @@
+[metadata]
+creation_date = "2020/05/21"
+integration = ["okta"]
+maturity = "production"
+updated_date = "2025/07/02"
+
+[rule]
+author = ["Elastic"]
+description = """
+Detects attempts to create an Okta API token. An adversary may create an Okta API token to maintain access to an
+organization's network while they work to achieve their objectives. An attacker may abuse an API token to execute
+techniques such as creating user accounts or disabling security rules or policies.
+"""
+false_positives = [
+    """
+    If the behavior of creating Okta API tokens is expected, consider adding exceptions to this rule to filter false
+    positives.
+    """,
+]
+index = ["filebeat-*", "logs-okta*"]
+language = "kuery"
+license = "Elastic License v2"
+name = "Attempt to Create Okta API Token"
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
+
+### Investigating Attempt to Create Okta API Token
+
+Okta API tokens are crucial for automating and managing identity and access tasks within an organization. However, if compromised, these tokens can be exploited by adversaries to gain persistent access, manipulate user accounts, or alter security settings. The detection rule identifies suspicious token creation activities by monitoring specific Okta system events, helping to thwart unauthorized access attempts.
+
+### Possible investigation steps
+
+- Review the event logs for entries with event.dataset:okta.system and event.action:system.api_token.create to identify the specific instance of API token creation.
+- Identify the user account associated with the token creation event to determine if the action aligns with their typical behavior or role within the organization.
+- Check the timestamp of the event to correlate with other security events or anomalies that occurred around the same time.
+- Investigate the IP address and location from which the API token creation request originated to assess if it matches the user's usual access patterns.
+- Examine any recent changes to user accounts or security settings that may have been executed using the newly created API token.
+- Review the organization's policy on API token creation to ensure compliance and determine if the action was authorized.
+
+### False positive analysis
+
+- Routine administrative tasks may trigger the rule when legitimate IT staff create API tokens for automation or integration purposes. To manage this, maintain a list of authorized personnel and their expected activities, and create exceptions for these known users.
+- Scheduled system maintenance or updates might involve creating API tokens, leading to false positives. Document these events and adjust the monitoring window or create temporary exceptions during these periods.
+- Third-party integrations that require API tokens for functionality can also trigger alerts. Identify and whitelist these integrations by verifying their necessity and security compliance.
+- Development and testing environments often involve frequent token creation for testing purposes. Exclude these environments from the rule or set up separate monitoring with adjusted thresholds to avoid unnecessary alerts.
+
+### Response and remediation
+
+- Immediately revoke the suspicious Okta API token to prevent any unauthorized access or actions within the organization's network.
+- Conduct a thorough review of recent activities associated with the compromised token to identify any unauthorized changes or access attempts.
+- Reset credentials and enforce multi-factor authentication for any accounts that were accessed or potentially compromised using the API token.
+- Notify the security team and relevant stakeholders about the incident to ensure awareness and coordination for further investigation and response.
+- Implement additional monitoring on Okta API token creation events to detect and respond to any further unauthorized attempts promptly.
+- Review and update access controls and permissions related to API token creation to ensure they align with the principle of least privilege.
+- Escalate the incident to senior security management if there is evidence of broader compromise or if the threat actor's objectives are unclear.
+
+## 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 = "96b9f4ea-0e8c-435b-8d53-2096e75fcac5"
+severity = "medium"
+tags = [
+    "Use Case: Identity and Access Audit",
+    "Data Source: Okta",
+    "Tactic: Persistence",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "query"
+
+query = '''
+event.dataset:okta.system and event.action:system.api_token.create
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1136"
+name = "Create Account"
+reference = "https://attack.mitre.org/techniques/T1136/"
+
+
+[rule.threat.tactic]
+id = "TA0003"
+name = "Persistence"
+reference = "https://attack.mitre.org/tactics/TA0003/"
+

nldcsc_elastic_rules/rules/integrations/okta/persistence_attempt_to_reset_mfa_factors_for_okta_user_account.toml

@@ -0,0 +1,99 @@
+[metadata]
+creation_date = "2020/05/21"
+integration = ["okta"]
+maturity = "production"
+updated_date = "2025/07/02"
+
+[rule]
+author = ["Elastic"]
+description = """
+Detects attempts to reset an Okta user's enrolled multi-factor authentication (MFA) factors. An adversary may attempt to
+reset the MFA factors for an Okta user's account in order to register new MFA factors and abuse the account to blend in
+with normal activity in the victim's environment.
+"""
+false_positives = [
+    """
+    Consider adding exceptions to this rule to filter false positives if the MFA factors for Okta user accounts are
+    regularly reset in your organization.
+    """,
+]
+index = ["filebeat-*", "logs-okta*"]
+language = "kuery"
+license = "Elastic License v2"
+name = "Attempt to Reset MFA Factors for an Okta User Account"
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
+
+### Investigating Attempt to Reset MFA Factors for an Okta User Account
+
+Okta is a widely used identity management service that provides multi-factor authentication (MFA) to enhance security. Adversaries may attempt to reset MFA factors to register their own, gaining unauthorized access while appearing legitimate. The detection rule identifies such attempts by monitoring specific Okta system events, helping to flag potential account manipulation activities.
+
+### Possible investigation steps
+
+- Review the Okta system logs for the specific event.action:user.mfa.factor.reset_all to identify the user account involved in the MFA reset attempt.
+- Check the timestamp of the event to determine when the reset attempt occurred and correlate it with any other suspicious activities around the same time.
+- Investigate the IP address and location associated with the event to assess if it aligns with the user's typical access patterns or if it appears unusual.
+- Examine the user account's recent activity history for any anomalies or unauthorized access attempts that might indicate compromise.
+- Verify if there have been any recent changes to the user's account settings or permissions that could suggest account manipulation.
+- Contact the affected user to confirm whether they initiated the MFA reset or if it was unauthorized, and advise them on securing their account if necessary.
+
+### False positive analysis
+
+- Routine administrative actions may trigger the rule if IT staff reset MFA factors for legitimate reasons such as assisting users who have lost access to their MFA devices. To manage this, create exceptions for known IT personnel or specific administrative actions.
+- User-initiated resets due to lost or changed devices can also appear as suspicious activity. Implement a process to verify user requests and document these instances to differentiate them from malicious attempts.
+- Automated scripts or tools used for account management might reset MFA factors as part of their operations. Identify and whitelist these tools to prevent false positives.
+- Scheduled security audits or compliance checks that involve resetting MFA factors should be documented and excluded from triggering alerts by setting up time-based exceptions during these activities.
+
+### Response and remediation
+
+- Immediately disable the affected Okta user account to prevent further unauthorized access.
+- Review recent login activity and MFA changes for the affected account to identify any unauthorized access or suspicious behavior.
+- Reset the MFA factors for the affected account and ensure that only the legitimate user can re-enroll their MFA devices.
+- Notify the legitimate user of the account compromise and advise them to change their password and review their account activity.
+- Conduct a security review of the affected user's permissions and access to sensitive resources to ensure no unauthorized changes were made.
+- Escalate the incident to the security operations team for further investigation and to determine if other accounts may be affected.
+- Update security monitoring and alerting to enhance detection of similar MFA reset attempts, leveraging the MITRE ATT&CK framework for guidance on persistence and account manipulation tactics.
+
+## 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",
+    "https://www.elastic.co/security-labs/okta-and-lapsus-what-you-need-to-know",
+]
+risk_score = 21
+rule_id = "729aa18d-06a6-41c7-b175-b65b739b1181"
+severity = "low"
+tags = [
+    "Tactic: Persistence",
+    "Use Case: Identity and Access Audit",
+    "Data Source: Okta",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "query"
+
+query = '''
+event.dataset:okta.system and event.action:user.mfa.factor.reset_all
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1098"
+name = "Account Manipulation"
+reference = "https://attack.mitre.org/techniques/T1098/"
+
+
+[rule.threat.tactic]
+id = "TA0003"
+name = "Persistence"
+reference = "https://attack.mitre.org/tactics/TA0003/"
+

nldcsc_elastic_rules/rules/integrations/okta/persistence_mfa_deactivation_with_no_reactivation.toml

@@ -0,0 +1,103 @@
+[metadata]
+creation_date = "2020/05/20"
+integration = ["okta"]
+maturity = "production"
+updated_date = "2025/09/08"
+
+[rule]
+author = ["Elastic"]
+description = """
+Detects multi-factor authentication (MFA) deactivation with no subsequent re-activation for an Okta user account. An
+adversary may deactivate MFA for an Okta user account in order to weaken the authentication requirements for the
+account.
+"""
+false_positives = [
+    """
+    If the behavior of deactivating MFA for Okta user accounts is expected, consider adding exceptions to this rule to
+    filter false positives.
+    """,
+]
+from = "now-12h"
+index = ["logs-okta.system*"]
+interval = "6h"
+language = "eql"
+license = "Elastic License v2"
+name = "MFA Deactivation with no Re-Activation for Okta User Account"
+note = """## Triage and analysis
+
+### Investigating MFA Deactivation with no Re-Activation for Okta User Account
+
+MFA is used to provide an additional layer of security for user accounts. An adversary may achieve MFA deactivation for an Okta user account to achieve persistence.
+
+This rule fires when an Okta user account has MFA deactivated and no subsequent MFA reactivation is observed within 12 hours.
+
+#### Possible investigation steps:
+
+- Identify the entity related to the alert by reviewing `okta.target.alternate_id`, `okta.target.id` or `user.target.full_name` fields. This should give the username of the account being targeted. Verify if MFA is deactivated for the target entity.
+- Using the `okta.target.alternate_id` field, search for MFA re-activation events where `okta.event_type` is `user.mfa.factor.activate`. Note if MFA re-activation attempts were made against the target.
+- Identify the actor performing the deactivation by reviewing `okta.actor.alternate_id`, `okta.actor.id` or `user.full_name` fields. This should give the username of the account performing the action. Determine if deactivation was performed by a separate user.
+- Review events where `okta.event_type` is `user.authenticate*` to determine if the actor or target accounts had suspicious login activity.
+    - Geolocation details found in `client.geo*` related fields may be useful in determining if the login activity was suspicious for this user.
+- Examine related administrative activity by the actor for privilege misuse or suspicious changes.
+
+#### False positive steps:
+
+- Determine with the target user if MFA deactivation was expected.
+- Determine if MFA is required for the target user account.
+
+#### Response and remediation:
+
+- If the MFA deactivation was not expected, consider deactivating the user
+    - This should be followed by resetting the user's password and re-enabling MFA.
+- If the MFA deactivation was expected, consider adding an exception to this rule to filter false positives.
+- 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.
+- 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, applications or systems.
+- Review the client user-agent to determine if it's a known custom application that can be whitelisted.
+"""
+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 = 21
+rule_id = "cd89602e-9db0-48e3-9391-ae3bf241acd8"
+setup = "The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.\n"
+severity = "low"
+tags = [
+    "Tactic: Persistence",
+    "Use Case: Identity and Access Audit",
+    "Data Source: Okta",
+    "Domain: Cloud",
+    "Resources: Investigation Guide",
+]
+type = "eql"
+
+query = '''
+sequence by okta.target.id with maxspan=12h
+    [any where event.dataset == "okta.system" and okta.event_type in ("user.mfa.factor.deactivate", "user.mfa.factor.reset_all")
+        and okta.outcome.reason != "User reset SECURITY_QUESTION factor" and okta.outcome.result == "SUCCESS"]
+    ![any where event.dataset == "okta.system" and okta.event_type == "user.mfa.factor.activate"]
+'''
+
+
+[[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/"
+

nldcsc_elastic_rules/rules/integrations/okta/persistence_new_idp_successfully_added_by_admin.toml

@@ -0,0 +1,94 @@
+[metadata]
+creation_date = "2023/11/06"
+integration = ["okta"]
+maturity = "production"
+updated_date = "2025/07/02"
+
+[rule]
+author = ["Elastic"]
+description = """
+Detects the creation of a new Identity Provider (IdP) by a Super Administrator or Organization Administrator within
+Okta.
+"""
+from = "now-30m"
+index = ["filebeat-*", "logs-okta*"]
+interval = "15m"
+language = "kuery"
+license = "Elastic License v2"
+name = "New Okta Identity Provider (IdP) Added by Admin"
+note = """## Triage and analysis
+
+### Investigating New Okta Identity Provider (IdP) Added by Admin
+
+This rule detects the creation of a new Identity Provider (IdP) by a Super Administrator or Organization Administrator within Okta.
+
+#### Possible investigation steps:
+- Identify the actor associated with the IdP creation by examining the `okta.actor.id`, `okta.actor.type`, `okta.actor.alternate_id`, and `okta.actor.display_name` fields.
+- Identify the IdP added by reviewing the `okta.target` field and determing if this IdP is authorized.
+- Determine the client used by the actor. Review the `okta.client.ip`, `okta.client.user_agent.raw_user_agent`, `okta.client.zone`, `okta.client.device`, and `okta.client.id` fields.
+- If the client is a device, check the `okta.device.id`, `okta.device.name`, `okta.device.os_platform`, `okta.device.os_version`, and `okta.device.managed` fields.
+- Review the past activities of the actor involved in this action by checking their previous actions logged in the `okta.target` field.
+- Examine the `okta.request.ip_chain` field to potentially determine if the actor used a proxy or VPN to perform this action.
+- 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.
+
+### False positive analysis:
+- It might be a false positive if the action was part of a planned activity or performed by an authorized person.
+- Several unsuccessful attempts prior to this success, may indicate an adversary attempting to add an unauthorized IdP multiple times.
+
+### Response and remediation:
+- If the IdP is unauthorized, deactivate it immediately via the Okta console.
+- If the IdP is authorized, ensure that the actor who created it is authorized to do so.
+- If the actor is unauthorized, deactivate their account via the Okta console.
+- If the actor is authorized, ensure that the actor's account is not compromised.
+- Reset the user's password and enforce MFA re-enrollment, if applicable.
+- Block the IP address or device used in the attempts if they appear suspicious, using the data from the `okta.client.ip` and `okta.device.id` fields.
+- Conduct a review of Okta policies and ensure they are in accordance with security best practices.
+- If the deactivated IdP was crucial to the organization, consider adding a new IdP and removing the unauthorized IdP.
+
+## Setup
+
+The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.
+"""
+references = [
+    "https://blog.cloudflare.com/cloudflare-investigation-of-the-january-2022-okta-compromise/",
+    "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://unit42.paloaltonetworks.com/muddled-libra/",
+    "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 = "29b53942-7cd4-11ee-b70e-f661ea17fbcd"
+severity = "medium"
+tags = [
+    "Use Case: Identity and Access Audit",
+    "Tactic: Persistence",
+    "Data Source: Okta",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "query"
+
+query = '''
+event.dataset: "okta.system" and event.action: "system.idp.lifecycle.create" and okta.outcome.result: "SUCCESS"
+'''
+
+
+[[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.007"
+name = "Hybrid Identity"
+reference = "https://attack.mitre.org/techniques/T1556/007/"
+
+
+
+[rule.threat.tactic]
+id = "TA0003"
+name = "Persistence"
+reference = "https://attack.mitre.org/tactics/TA0003/"
+

nldcsc_elastic_rules/rules/integrations/okta/persistence_okta_attempt_to_modify_or_delete_application_sign_on_policy.toml

@@ -0,0 +1,99 @@
+[metadata]
+creation_date = "2020/07/01"
+integration = ["okta"]
+maturity = "production"
+updated_date = "2025/07/02"
+
+[rule]
+author = ["Elastic"]
+description = """
+Detects attempts to modify or delete a sign on policy for an Okta application. An adversary may attempt to modify or
+delete the sign on policy for an Okta application in order to remove or weaken an organization's security controls.
+"""
+false_positives = [
+    """
+    Consider adding exceptions to this rule to filter false positives if sign on policies for Okta applications are
+    regularly modified or deleted in your organization.
+    """,
+]
+index = ["filebeat-*", "logs-okta*"]
+language = "kuery"
+license = "Elastic License v2"
+name = "Modification or Removal of an Okta Application Sign-On Policy"
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
+
+### Investigating Modification or Removal of an Okta Application Sign-On Policy
+
+Okta's sign-on policies are crucial for enforcing authentication controls within an organization. Adversaries may target these policies to weaken security by modifying or removing them, thus bypassing authentication measures. The detection rule monitors system events for updates or deletions of sign-on policies, flagging potential unauthorized changes to maintain security integrity.
+
+### Possible investigation steps
+
+- Review the event logs for entries with the dataset field set to okta.system to confirm the source of the alert.
+- Examine the event.action field for values application.policy.sign_on.update or application.policy.sign_on.rule.delete to identify the specific action taken.
+- Identify the user or system account associated with the event to determine if the action was performed by an authorized individual.
+- Check the timestamp of the event to correlate with any other suspicious activities or changes in the system around the same time.
+- Investigate the history of changes to the affected sign-on policy to understand the context and frequency of modifications or deletions.
+- Assess the impact of the policy change on the organization's security posture and determine if any immediate remediation is necessary.
+- If unauthorized activity is suspected, initiate a security incident response to contain and mitigate potential threats.
+
+### False positive analysis
+
+- Routine administrative updates to sign-on policies by authorized personnel can trigger alerts. To manage this, establish a list of trusted users or roles and create exceptions for their actions.
+- Scheduled maintenance or policy reviews may involve legitimate modifications or deletions. Document these activities and adjust the detection rule to exclude events during known maintenance windows.
+- Automated scripts or tools used for policy management might cause false positives. Identify these tools and configure the rule to recognize and exclude their expected actions.
+- Changes due to integration with third-party applications can be mistaken for unauthorized modifications. Verify these integrations and whitelist their associated actions to prevent unnecessary alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected Okta application to prevent further unauthorized access or changes. This can be done by disabling the application temporarily until the issue is resolved.
+- Review the audit logs to identify the source of the modification or deletion attempt, focusing on the user account and IP address associated with the event.
+- Revert any unauthorized changes to the sign-on policy by restoring it to the last known good configuration. Ensure that all security controls are reinstated.
+- Conduct a thorough review of user accounts with administrative privileges in Okta to ensure they are legitimate and have not been compromised. Reset passwords and enforce multi-factor authentication (MFA) for these accounts.
+- Notify the security team and relevant stakeholders about the incident, providing details of the attempted policy modification or deletion and the steps taken to contain the threat.
+- Escalate the incident to higher-level security management if the source of the threat is internal or if there is evidence of a broader compromise.
+- Implement additional monitoring and alerting for any future attempts to modify or delete sign-on policies, ensuring that similar threats are detected and addressed promptly.
+
+## Setup
+
+The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
+references = [
+    "https://help.okta.com/en/prod/Content/Topics/Security/App_Based_Signon.htm",
+    "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 = "cd16fb10-0261-46e8-9932-a0336278cdbe"
+severity = "medium"
+tags = [
+    "Tactic: Persistence",
+    "Use Case: Identity and Access Audit",
+    "Data Source: Okta",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "query"
+
+query = '''
+event.dataset:okta.system and event.action:(application.policy.sign_on.update or application.policy.sign_on.rule.delete)
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1556"
+name = "Modify Authentication Process"
+reference = "https://attack.mitre.org/techniques/T1556/"
+
+
+[rule.threat.tactic]
+id = "TA0003"
+name = "Persistence"
+reference = "https://attack.mitre.org/tactics/TA0003/"
+

nldcsc_elastic_rules/rules/integrations/okta/persistence_stolen_credentials_used_to_login_to_okta_account_after_mfa_reset.toml

@@ -0,0 +1,105 @@
+[metadata]
+creation_date = "2023/11/09"
+integration = ["endpoint", "okta"]
+maturity = "production"
+updated_date = "2025/07/02"
+
+[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",
+    "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 = "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",
+    "Resources: Investigation Guide",
+]
+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/"
+