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

nldcsc_elastic_rules/rules/integrations/okta/initial_access_first_occurrence_user_session_started_via_proxy.toml

@@ -0,0 +1,89 @@
+[metadata]
+creation_date = "2023/11/07"
+integration = ["okta"]
+maturity = "production"
+updated_date = "2025/07/02"
+
+[rule]
+author = ["Elastic"]
+description = "Identifies the first occurrence of an Okta user session started via a proxy."
+index = ["filebeat-*", "logs-okta*"]
+language = "kuery"
+license = "Elastic License v2"
+name = "First Occurrence of Okta User Session Started via Proxy"
+note = """## Triage and analysis
+
+### Investigating First Occurrence of Okta User Session Started via Proxy
+
+This rule detects the first occurrence of an Okta user session started via a proxy. This rule is designed to help identify suspicious authentication behavior that may be indicative of an attacker attempting to gain access to an Okta account while remaining anonymous. This rule leverages the New Terms rule type feature where the `okta.actor.id` value is checked against the previous 7 days of data to determine if the value has been seen before for this activity.
+
+#### Possible investigation steps:
+- Identify the user 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 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.
+- Examine the `okta.debug_context.debug_data.flattened` field for more information about the proxy used.
+- Review the `okta.request.ip_chain` field for more information about the geographic location of the proxy.
+- Review the past activities of the actor 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.
+
+### False positive analysis:
+- A user may have legitimately started a session via a proxy for security or privacy reasons.
+
+### Response and remediation:
+- Review the profile of the user involved in this action to determine if proxy usage may be expected.
+- If the user is legitimate and the authentication behavior is not suspicious, no action is required.
+- If the user is legitimate but the authentication behavior is suspicious, consider resetting the user's password and enabling multi-factor authentication (MFA).
+    - If MFA is already enabled, consider resetting MFA for the user.
+- If the user is not legitimate, consider deactivating the user's account.
+- Conduct a review of Okta policies and ensure they are in accordance with security best practices.
+
+## 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://developer.okta.com/docs/reference/api/system-log/#issuer-object",
+    "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 = 47
+rule_id = "6f1bb4b2-7dc8-11ee-92b2-f661ea17fbcd"
+severity = "medium"
+tags = [
+    "Tactic: Initial Access",
+    "Use Case: Identity and Access Audit",
+    "Data Source: Okta",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "new_terms"
+
+query = '''
+event.dataset:okta.system and okta.event_type: (user.session.start or user.authentication.verify) and okta.security_context.is_proxy:true and not okta.actor.id: okta*
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1133"
+name = "External Remote Services"
+reference = "https://attack.mitre.org/techniques/T1133/"
+
+
+[rule.threat.tactic]
+id = "TA0001"
+name = "Initial Access"
+reference = "https://attack.mitre.org/tactics/TA0001/"
+
+[rule.new_terms]
+field = "new_terms_fields"
+value = ["okta.actor.id", "cloud.account.id"]
+[[rule.new_terms.history_window_start]]
+field = "history_window_start"
+value = "now-7d"
+
+

nldcsc_elastic_rules/rules/integrations/okta/initial_access_new_authentication_behavior_detection.toml

@@ -0,0 +1,80 @@
+[metadata]
+creation_date = "2023/11/07"
+integration = ["okta"]
+maturity = "production"
+updated_date = "2025/07/02"
+
+[rule]
+author = ["Elastic"]
+description = "Detects events where Okta behavior detection has identified a new authentication behavior."
+from = "now-30m"
+index = ["filebeat-*", "logs-okta*"]
+interval = "15m"
+language = "kuery"
+license = "Elastic License v2"
+name = "New Okta Authentication Behavior Detected"
+note = """## Triage and analysis
+
+### Investigating New Okta Authentication Behavior Detected
+
+This rule detects events where Okta behavior detection has identified a new authentication behavior such as a new device or location.
+
+#### Possible investigation steps:
+- Identify the user 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 authentication anomaly by examining the `okta.debug_context.debug_data.risk_behaviors` and `okta.debug_context.debug_data.flattened` fields.
+- 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.
+- 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:
+- A user may be using a new device or location to sign in.
+- The Okta behavior detection may be incorrectly identifying a new authentication behavior and need adjusted.
+
+### Response and remediation:
+- If the user is legitimate and the authentication behavior is not suspicious, no action is required.
+- If the user is legitimate but the authentication behavior is suspicious, consider resetting the user's password and enabling multi-factor authentication (MFA).
+    - If MFA is already enabled, consider resetting MFA for the user.
+- If the user is not legitimate, consider deactivating the user's account.
+- If this is a false positive, consider adjusting the Okta behavior detection settings.
+- 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.
+
+## Setup
+
+The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.
+"""
+references = [
+    "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://help.okta.com/oie/en-us/content/topics/security/behavior-detection/about-behavior-detection.htm",
+    "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 = "260486ee-7d98-11ee-9599-f661ea17fbcd"
+severity = "medium"
+tags = [
+    "Use Case: Identity and Access Audit",
+    "Tactic: Initial Access",
+    "Data Source: Okta",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "query"
+
+query = '''
+event.dataset:okta.system and okta.debug_context.debug_data.risk_behaviors:*
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+
+[rule.threat.tactic]
+id = "TA0001"
+name = "Initial Access"
+reference = "https://attack.mitre.org/tactics/TA0001/"
+

nldcsc_elastic_rules/rules/integrations/okta/initial_access_okta_fastpass_phishing.toml

@@ -0,0 +1,95 @@
+[metadata]
+creation_date = "2023/05/07"
+integration = ["okta"]
+maturity = "production"
+updated_date = "2025/07/02"
+
+[rule]
+author = ["Austin Songer"]
+description = "Detects when Okta FastPass prevents a user from authenticating to a phishing website.\n"
+index = ["filebeat-*", "logs-okta*"]
+language = "kuery"
+license = "Elastic License v2"
+name = "Okta FastPass Phishing Detection"
+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 Okta FastPass Phishing Detection
+
+Okta FastPass is a passwordless authentication solution that enhances security by verifying user identity without traditional credentials. Adversaries may attempt to exploit this by directing users to phishing sites mimicking legitimate services. The detection rule identifies failed authentication attempts where FastPass blocks access, indicating a phishing attempt, by analyzing specific event patterns and outcomes.
+
+### Possible investigation steps
+
+- Review the event details to confirm the presence of the specific outcome reason "FastPass declined phishing attempt" to ensure the alert is related to a phishing attempt.
+- Identify the user associated with the failed authentication attempt and gather additional context about their recent activities and access patterns.
+- Investigate the source IP address and geolocation of the failed authentication attempt to determine if it aligns with the user's typical access locations or if it appears suspicious.
+- Check for any other recent authentication attempts from the same user or IP address to identify potential patterns or repeated phishing attempts.
+- Communicate with the affected user to verify if they received any suspicious communications or if they attempted to access any unfamiliar websites around the time of the alert.
+- Review any additional logs or alerts from other security systems that might provide further context or corroborate the phishing attempt.
+
+### False positive analysis
+
+- Legitimate third-party applications that mimic the behavior of phishing sites may trigger false positives. Users can create exceptions for these applications by whitelisting their domains in the Okta FastPass settings.
+- Internal testing environments that simulate phishing scenarios for training purposes might be flagged. To prevent this, ensure that these environments are registered and recognized within the Okta system to avoid unnecessary alerts.
+- Users accessing legitimate services through unusual network paths or VPNs may be mistakenly identified as phishing attempts. Regularly review and update network configurations and trusted IP addresses to minimize these occurrences.
+- Frequent failed authentication attempts due to user error, such as incorrect device settings or outdated software, can be mistaken for phishing. Educate users on maintaining their devices and software to align with Okta FastPass requirements to reduce these false positives.
+
+### Response and remediation
+
+- Immediately isolate the affected user accounts to prevent further unauthorized access attempts. This can be done by temporarily disabling the accounts or enforcing additional authentication measures.
+- Notify the affected users about the phishing attempt and instruct them to avoid interacting with suspicious emails or websites. Provide guidance on recognizing phishing attempts.
+- Conduct a thorough review of the affected users' recent activities to identify any potential data exposure or unauthorized access to sensitive information.
+- Escalate the incident to the security operations team for further investigation and to determine if there are any broader implications or related incidents.
+- Implement additional monitoring on the affected accounts and related systems to detect any further suspicious activities or attempts to bypass security controls.
+- Review and update security policies and configurations related to Okta FastPass to ensure they are optimized for detecting and preventing similar phishing attempts in the future.
+- Coordinate with the IT team to ensure that all systems and applications are patched and up-to-date to mitigate any vulnerabilities that could be exploited in conjunction with phishing attacks.
+
+## Setup
+
+The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.
+
+This rule requires Okta to have the following turned on:
+
+Okta Identity Engine - select 'Phishing Resistance for FastPass' under Settings > Features in the Admin Console.
+"""
+references = [
+    "https://developer.okta.com/docs/reference/api/system-log/",
+    "https://developer.okta.com/docs/reference/api/event-types/",
+    "https://sec.okta.com/fastpassphishingdetection",
+    "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 = 47
+rule_id = "ee39a9f7-5a79-4b0a-9815-d36b3cf28d3e"
+severity = "medium"
+tags = [
+    "Tactic: Initial Access",
+    "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.category:authentication and
+  okta.event_type:user.authentication.auth_via_mfa and event.outcome:failure and okta.outcome.reason:"FastPass declined phishing attempt"
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1566"
+name = "Phishing"
+reference = "https://attack.mitre.org/techniques/T1566/"
+
+
+[rule.threat.tactic]
+id = "TA0001"
+name = "Initial Access"
+reference = "https://attack.mitre.org/tactics/TA0001/"
+

nldcsc_elastic_rules/rules/integrations/okta/initial_access_okta_user_attempted_unauthorized_access.toml

@@ -0,0 +1,110 @@
+[metadata]
+creation_date = "2021/05/14"
+integration = ["okta"]
+maturity = "production"
+updated_date = "2025/07/02"
+
+[rule]
+author = ["Elastic", "Austin Songer"]
+description = "Identifies unauthorized access attempts to Okta applications."
+index = ["filebeat-*", "logs-okta*"]
+language = "kuery"
+license = "Elastic License v2"
+name = "Unauthorized Access to an Okta Application"
+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 Unauthorized Access to an Okta Application
+
+Okta is a widely used identity management service that facilitates secure user authentication and access to applications. Adversaries may exploit valid credentials to gain unauthorized access, bypassing security controls. The detection rule monitors specific Okta system events for unauthorized access attempts, leveraging event datasets and actions to identify potential breaches, thus aiding in early threat detection and response.
+
+### Possible investigation steps
+
+- Review the event logs for entries with event.dataset:okta.system and event.action:app.generic.unauth_app_access_attempt to identify the specific unauthorized access attempts.
+- Identify the user accounts involved in the unauthorized access attempts and check for any unusual activity or patterns associated with these accounts.
+- Investigate the source IP addresses associated with the unauthorized access attempts to determine if they are known or suspicious, and check for any geolocation anomalies.
+- Examine the timestamps of the unauthorized access attempts to see if they coincide with any other suspicious activities or known incidents.
+- Check for any recent changes in user permissions or configurations in the Okta system that might have facilitated the unauthorized access attempts.
+- Contact the affected users to verify if they were aware of the access attempts and to ensure their credentials have not been compromised.
+
+### False positive analysis
+
+- Employees accessing applications from new devices or locations may trigger alerts. Regularly update the list of known devices and locations to minimize these false positives.
+- Automated scripts or tools used for application testing might mimic unauthorized access attempts. Identify and whitelist these scripts to prevent unnecessary alerts.
+- Users with multiple accounts accessing the same application can be mistaken for unauthorized access. Maintain an updated list of legitimate multi-account users to reduce false positives.
+- Changes in user roles or permissions might lead to temporary access issues. Coordinate with HR or IT departments to ensure role changes are reflected promptly in the system.
+- Scheduled maintenance or updates to applications can generate access attempts that appear unauthorized. Exclude these events by aligning detection rules with maintenance schedules.
+
+### Response and remediation
+
+- Immediately isolate the affected user account by disabling it to prevent further unauthorized access.
+- Review and reset the credentials for the compromised account, ensuring the new password adheres to strong security policies.
+- Conduct a thorough audit of recent activities associated with the compromised account to identify any unauthorized changes or data access.
+- Notify the affected user and relevant stakeholders about the incident, providing guidance on recognizing phishing attempts and securing their accounts.
+- Escalate the incident to the security operations team for further investigation and to determine if additional accounts or systems have been compromised.
+- Implement multi-factor authentication (MFA) for the affected account and any other accounts that do not currently have it enabled to enhance security.
+- Update and refine monitoring rules to detect similar unauthorized access attempts in the future, ensuring quick identification and response.
+
+## 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 = 21
+rule_id = "4edd3e1a-3aa0-499b-8147-4d2ea43b1613"
+severity = "low"
+tags = [
+    "Tactic: Initial Access",
+    "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:app.generic.unauth_app_access_attempt
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1078"
+name = "Valid Accounts"
+reference = "https://attack.mitre.org/techniques/T1078/"
+
+
+[rule.threat.tactic]
+id = "TA0001"
+name = "Initial Access"
+reference = "https://attack.mitre.org/tactics/TA0001/"
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+
+[rule.threat.tactic]
+id = "TA0005"
+name = "Defense Evasion"
+reference = "https://attack.mitre.org/tactics/TA0005/"
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+
+[rule.threat.tactic]
+id = "TA0003"
+name = "Persistence"
+reference = "https://attack.mitre.org/tactics/TA0003/"
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+
+[rule.threat.tactic]
+id = "TA0004"
+name = "Privilege Escalation"
+reference = "https://attack.mitre.org/tactics/TA0004/"
+

nldcsc_elastic_rules/rules/integrations/okta/initial_access_okta_user_sessions_started_from_different_geolocations.toml

@@ -0,0 +1,121 @@
+[metadata]
+creation_date = "2023/11/18"
+integration = ["okta"]
+maturity = "production"
+updated_date = "2025/09/25"
+
+[rule]
+author = ["Elastic"]
+description = """
+Detects when a specific Okta actor has multiple sessions started from different geolocations. Adversaries may attempt to
+launch an attack by using a list of known usernames and passwords to gain unauthorized access to user accounts from
+different locations.
+"""
+from = "now-30m"
+interval = "15m"
+language = "esql"
+license = "Elastic License v2"
+name = "Okta User Sessions Started from Different Geolocations"
+note = """## Triage and analysis
+
+### Investigating Okta User Sessions Started from Different Geolocations
+
+This rule detects when a specific Okta actor has multiple sessions started from different geolocations. Adversaries may attempt to launch an attack by using a list of known usernames and passwords to gain unauthorized access to user accounts from different locations.
+
+#### Possible investigation steps:
+- Since this is an ESQL rule, the `okta.actor.alternate_id` and `okta.client.id` values can be used to pivot into the raw authentication events related to this alert.
+- 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.
+- 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.
+- 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:
+- It is very rare that a legitimate user would have multiple sessions started from different geo-located countries in a short time frame.
+
+### Response and remediation:
+- 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://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.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 = 47
+rule_id = "2e56e1bc-867a-11ee-b13e-f661ea17fbcd"
+setup = "The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.\n"
+severity = "medium"
+tags = [
+    "Use Case: Identity and Access Audit",
+    "Data Source: Okta",
+    "Tactic: Initial 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.security_context.is_proxy != true and
+    okta.actor.id != "unknown" and
+    event.outcome == "success"
+| keep
+    event.action,
+    okta.security_context.is_proxy,
+    okta.actor.id,
+    okta.actor.alternate_id,
+    event.outcome,
+    client.geo.country_name
+| stats
+    Esql.client_geo_country_name_count_distinct = count_distinct(client.geo.country_name)
+    by okta.actor.id, okta.actor.alternate_id
+| where
+    Esql.client_geo_country_name_count_distinct >= 2
+| sort
+    Esql.client_geo_country_name_count_distinct desc
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1078"
+name = "Valid Accounts"
+reference = "https://attack.mitre.org/techniques/T1078/"
+[[rule.threat.technique.subtechnique]]
+id = "T1078.004"
+name = "Cloud Accounts"
+reference = "https://attack.mitre.org/techniques/T1078/004/"
+
+
+
+[rule.threat.tactic]
+id = "TA0001"
+name = "Initial Access"
+reference = "https://attack.mitre.org/tactics/TA0001/"
+

nldcsc_elastic_rules/rules/integrations/okta/initial_access_sign_in_events_via_third_party_idp.toml

@@ -0,0 +1,104 @@
+[metadata]
+creation_date = "2023/11/06"
+integration = ["okta"]
+maturity = "production"
+updated_date = "2025/09/08"
+
+[rule]
+author = ["Elastic"]
+description = "Detects sign-in events where authentication is carried out via a third-party Identity Provider (IdP)."
+from = "now-30m"
+index = ["logs-okta*"]
+interval = "15m"
+language = "kuery"
+license = "Elastic License v2"
+name = "Okta Sign-In Events via Third-Party IdP"
+note = """## Triage and analysis
+
+### Investigating Okta Sign-In Events via Third-Party IdP
+
+This rule detects sign-in events where authentication is carried out via a third-party Identity Provider (IdP).
+
+Adversaries may attempt to add an unauthorized IdP to an Okta tenant to gain access to the tenant. Following this action, adversaries may attempt to sign in to the tenant using the unauthorized IdP. This rule detects both the addition of an unauthorized IdP and the subsequent sign-in attempt.
+
+#### Possible investigation steps:
+- Identify the third-party IdP by examining the `okta.authentication_context.issuer.id` field.
+- Once the third-party IdP is identified, determine if this IdP is authorized to be used by the tenant.
+- If the IdP is unauthorized, deactivate it immediately via the Okta console.
+- 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 in historical data.
+    - The `New Okta Identity Provider (IdP) Added by Admin` rule may be helpful in identifying the actor and the IdP creation event.
+- 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 this IdP is authorized to be used by the tenant.
+- This may be a false positive if an authorized third-party IdP is used to sign in to the tenant but failures occurred due to an incorrect configuration.
+
+### Response and remediation:
+- If the IdP is unauthorized, deactivate it immediately via the Okta console.
+- Reset the effected user's password and enforce MFA re-enrollment, if applicable.
+- Mobile device forensics may be required to determine if the user's device is compromised.
+- 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.
+
+- 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 = "1ceb05c4-7d25-11ee-9562-f661ea17fbcd"
+severity = "medium"
+tags = [
+    "Use Case: Identity and Access Audit",
+    "Tactic: Initial Access",
+    "Data Source: Okta",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "query"
+
+query = '''
+event.dataset:okta.system and okta.debug_context.debug_data.request_uri:/oauth2/v1/authorize/callback and
+    (not okta.authentication_context.issuer.id:Okta and event.action:(user.authentication.auth_via_IDP
+        or user.authentication.auth_via_inbound_SAML
+        or user.authentication.auth_via_mfa
+        or user.authentication.auth_via_social)
+        or event.action:user.session.start) or
+    (event.action:user.authentication.auth_via_IDP and okta.outcome.result:FAILURE
+        and okta.outcome.reason:("A SAML assert with the same ID has already been processed by Okta for a previous request"
+            or "Unable to match transformed username"
+            or "Unable to resolve IdP endpoint"
+            or "Unable to validate SAML Response"
+            or "Unable to validate incoming SAML Assertion"))
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1199"
+name = "Trusted Relationship"
+reference = "https://attack.mitre.org/techniques/T1199/"
+
+
+[rule.threat.tactic]
+id = "TA0001"
+name = "Initial Access"
+reference = "https://attack.mitre.org/tactics/TA0001/"
+