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

nldcsc_elastic_rules/rules/integrations/o365/privilege_escalation_new_or_modified_federation_domain.toml

@@ -0,0 +1,101 @@
+[metadata]
+creation_date = "2021/05/17"
+integration = ["o365"]
+maturity = "production"
+updated_date = "2025/09/26"
+
+[rule]
+author = ["Austin Songer"]
+description = """
+Identifies a new or modified federation domain, which can be used to create a trust between O365 and an external
+identity provider.
+"""
+index = ["logs-o365.audit-*", "filebeat-*"]
+language = "kuery"
+license = "Elastic License v2"
+name = "New or Modified Federation Domain"
+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 New or Modified Federation Domain
+
+Federation domains enable trust between Office 365 and external identity providers, facilitating seamless authentication. Adversaries may exploit this by altering federation settings to redirect authentication flows, potentially gaining unauthorized access. The detection rule monitors specific actions like domain modifications, signaling potential privilege escalation attempts, and alerts analysts to investigate these changes.
+
+### Possible investigation steps
+
+- Review the event logs for the specific actions listed in the query, such as "Set-AcceptedDomain" or "Add-FederatedDomain", to identify the exact changes made to the federation domain settings.
+- Identify the user account associated with the event by examining the event logs, and verify if the account has the necessary permissions to perform such actions.
+- Check the event.outcome field to confirm the success of the action and cross-reference with any recent administrative changes or requests to validate legitimacy.
+- Investigate the event.provider and event.category fields to ensure the actions were performed through legitimate channels and not via unauthorized or suspicious methods.
+- Analyze the timing and frequency of the federation domain changes to detect any unusual patterns or repeated attempts that could indicate malicious activity.
+- Correlate the detected changes with any recent alerts or incidents involving privilege escalation or unauthorized access attempts to assess potential links or broader security implications.
+
+### False positive analysis
+
+- Routine administrative changes to federation domains by IT staff can trigger alerts. To manage this, create exceptions for known and scheduled maintenance activities by trusted administrators.
+- Automated scripts or tools used for domain management may cause false positives. Identify these scripts and exclude their actions from triggering alerts by whitelisting their associated accounts or IP addresses.
+- Integration of new services or applications that require federation domain modifications can be mistaken for suspicious activity. Document these integrations and adjust the rule to recognize these legitimate changes.
+- Changes made during organizational restructuring, such as mergers or acquisitions, might appear as unauthorized modifications. Coordinate with relevant departments to anticipate these changes and temporarily adjust monitoring thresholds or exclusions.
+- Regular audits or compliance checks that involve domain settings adjustments can lead to false positives. Schedule these audits and inform the security team to prevent unnecessary alerts.
+
+### Response and remediation
+
+- Immediately disable any newly added or modified federation domains to prevent unauthorized access. This can be done using the appropriate administrative tools in Office 365.
+- Review and revoke any suspicious or unauthorized access tokens or sessions that may have been issued through the compromised federation domain.
+- Conduct a thorough audit of recent administrative actions and access logs to identify any unauthorized changes or access patterns related to the federation domain modifications.
+- Escalate the incident to the security operations team for further investigation and to determine if additional containment measures are necessary.
+- Implement additional monitoring on federation domain settings to detect any further unauthorized changes promptly.
+- Communicate with affected stakeholders and provide guidance on any immediate actions they need to take, such as password resets or additional authentication steps.
+- Review and update federation domain policies and configurations to ensure they align with best practices and reduce the risk of similar incidents in the future.
+
+## Setup
+
+The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
+references = [
+    "https://docs.microsoft.com/en-us/powershell/module/exchange/remove-accepteddomain?view=exchange-ps",
+    "https://docs.microsoft.com/en-us/powershell/module/exchange/remove-federateddomain?view=exchange-ps",
+    "https://docs.microsoft.com/en-us/powershell/module/exchange/new-accepteddomain?view=exchange-ps",
+    "https://docs.microsoft.com/en-us/powershell/module/exchange/add-federateddomain?view=exchange-ps",
+    "https://docs.microsoft.com/en-us/powershell/module/exchange/set-accepteddomain?view=exchange-ps",
+    "https://docs.microsoft.com/en-us/powershell/module/msonline/set-msoldomainfederationsettings?view=azureadps-1.0",
+]
+risk_score = 21
+rule_id = "684554fc-0777-47ce-8c9b-3d01f198d7f8"
+severity = "low"
+tags = [
+    "Domain: Cloud",
+    "Data Source: Microsoft 365",
+    "Use Case: Identity and Access Audit",
+    "Tactic: Privilege Escalation",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "query"
+
+query = '''
+event.dataset:o365.audit and event.provider:Exchange and event.category:web and event.action:("Set-AcceptedDomain" or
+"Set-MsolDomainFederationSettings" or "Add-FederatedDomain" or "New-AcceptedDomain" or "Remove-AcceptedDomain" or "Remove-FederatedDomain") and
+event.outcome:success
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1484"
+name = "Domain or Tenant Policy Modification"
+reference = "https://attack.mitre.org/techniques/T1484/"
+[[rule.threat.technique.subtechnique]]
+id = "T1484.002"
+name = "Trust Modification"
+reference = "https://attack.mitre.org/techniques/T1484/002/"
+
+
+
+[rule.threat.tactic]
+id = "TA0004"
+name = "Privilege Escalation"
+reference = "https://attack.mitre.org/tactics/TA0004/"
+

nldcsc_elastic_rules/rules/integrations/okta/credential_access_attempted_bypass_of_okta_mfa.toml

@@ -0,0 +1,94 @@
+[metadata]
+creation_date = "2020/05/21"
+integration = ["okta"]
+maturity = "production"
+updated_date = "2025/07/02"
+
+[rule]
+author = ["Elastic"]
+description = """
+Detects attempts to bypass Okta multi-factor authentication (MFA). An adversary may attempt to bypass the Okta MFA
+policies configured for an organization in order to obtain unauthorized access to an application.
+"""
+index = ["filebeat-*", "logs-okta*"]
+language = "kuery"
+license = "Elastic License v2"
+name = "Attempted Bypass of Okta MFA"
+note = """## Triage and analysis
+
+### Investigating Attempted Bypass of Okta MFA
+
+Multi-factor authentication (MFA) is a crucial security measure in preventing unauthorized access. Okta MFA, like other MFA solutions, requires the user to provide multiple means of identification at login. An adversary might attempt to bypass Okta MFA to gain unauthorized access to an application.
+
+This rule detects attempts to bypass Okta MFA. It might indicate a serious attempt to compromise a user account within the organization's network.
+
+#### Possible investigation steps
+
+- Identify the actor related to the alert by reviewing `okta.actor.id`, `okta.actor.type`, `okta.actor.alternate_id`, or `okta.actor.display_name` fields in the alert.
+- Review the `okta.client.user_agent.raw_user_agent` field to understand the device and software used by the actor.
+- Examine the `okta.outcome.reason` field for additional context around the bypass attempt.
+- Check the `okta.outcome.result` field to confirm the MFA bypass attempt.
+- Check if there are multiple unsuccessful MFA attempts from the same actor or IP address (`okta.client.ip`).
+- Check for successful logins immediately following the MFA bypass attempt.
+- Verify whether the actor's activity aligns with typical behavior or if any unusual activity took place around the time of the bypass attempt.
+
+### False positive analysis
+
+- Check if there were issues with the MFA system at the time of the bypass attempt. This could indicate a system error rather than a genuine bypass attempt.
+- Check the geographical location (`okta.request.ip_chain.geographical_context`) and time of the login attempt. If these match the actor's normal behavior, it might be a false positive.
+- Verify the actor's MFA settings to ensure they are correctly configured.
+
+### Response and remediation
+
+- If unauthorized access is confirmed, initiate the incident response process.
+- Immediately lock the affected actor account and require a password change.
+- Consider resetting MFA tokens for the actor and require re-enrollment.
+- Check if the compromised account was used to access or alter any sensitive data or systems.
+- If a specific MFA bypass technique was used, ensure your systems are patched or configured to prevent such techniques.
+- Assess the criticality of affected services and servers.
+- Work with your IT team to minimize the impact on users and maintain business continuity.
+- If multiple accounts are affected, consider a broader reset or audit of MFA tokens.
+- Implement security best practices [outlined](https://www.okta.com/blog/2019/10/9-admin-best-practices-to-keep-your-org-secure/) by Okta.
+- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).
+
+## 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/okta-and-lapsus-what-you-need-to-know",
+    "https://www.elastic.co/security-labs/starter-guide-to-understanding-okta",
+]
+risk_score = 73
+rule_id = "3805c3dc-f82c-4f8d-891e-63c24d3102b0"
+severity = "high"
+tags = [
+    "Data Source: Okta",
+    "Use Case: Identity and Access Audit",
+    "Tactic: Credential Access",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "query"
+
+query = '''
+event.dataset:okta.system and event.action:user.mfa.attempt_bypass
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1111"
+name = "Multi-Factor Authentication Interception"
+reference = "https://attack.mitre.org/techniques/T1111/"
+
+
+[rule.threat.tactic]
+id = "TA0006"
+name = "Credential Access"
+reference = "https://attack.mitre.org/tactics/TA0006/"
+

nldcsc_elastic_rules/rules/integrations/okta/credential_access_attempts_to_brute_force_okta_user_account.toml

@@ -0,0 +1,96 @@
+[metadata]
+creation_date = "2020/08/19"
+integration = ["okta"]
+maturity = "production"
+updated_date = "2025/07/02"
+
+[rule]
+author = ["Elastic", "@BenB196", "Austin Songer"]
+description = """
+Identifies when an Okta user account is locked out 3 times within a 3 hour window. An adversary may attempt a brute
+force or password spraying attack to obtain unauthorized access to user accounts. The default Okta authentication policy
+ensures that a user account is locked out after 10 failed authentication attempts.
+"""
+from = "now-180m"
+index = ["filebeat-*", "logs-okta*"]
+language = "kuery"
+license = "Elastic License v2"
+name = "Attempts to Brute Force an Okta User Account"
+note = """## Triage and analysis
+
+### Investigating Attempts to Brute Force an Okta User Account
+
+Brute force attacks aim to guess user credentials through exhaustive trial-and-error attempts. In this context, Okta accounts are targeted.
+
+This rule fires when an Okta user account has been locked out 3 times within a 3-hour window. This could indicate an attempted brute force or password spraying attack to gain unauthorized access to the user account. Okta's default authentication policy locks a user account after 10 failed authentication attempts.
+
+#### Possible investigation steps:
+
+- Identify the actor related to the alert by reviewing `okta.actor.alternate_id` field in the alert. This should give the username of the account being targeted.
+- Review the `okta.event_type` field to understand the nature of the events that led to the account lockout.
+- Check the `okta.severity` and `okta.display_message` fields for more context around the lockout events.
+- Look for correlation of events from the same IP address. Multiple lockouts from the same IP address might indicate a single source for the attack.
+- If the IP is not familiar, investigate it. The IP could be a proxy, VPN, Tor node, cloud datacenter, or a legitimate IP turned malicious.
+- Determine if the lockout events occurred during the user's regular activity hours. Unusual timing may indicate malicious activity.
+- Examine the authentication methods used during the lockout events by checking the `okta.authentication_context.credential_type` field.
+
+### False positive analysis:
+
+- Determine whether the account owner or an internal user made repeated mistakes in entering their credentials, leading to the account lockout.
+- Ensure there are no known network or application issues that might cause these events.
+
+### Response and remediation:
+
+- Alert the user and your IT department immediately.
+- If unauthorized access is confirmed, initiate your incident response process.
+- 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.
+- Require the affected user to change their password.
+- If the attack is ongoing, consider blocking the IP address initiating the brute force attack.
+- Implement account lockout policies to limit the impact of brute force attacks.
+- 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 or systems.
+
+## 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 = "e08ccd49-0380-4b2b-8d71-8000377d6e49"
+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.action:user.account.lock
+'''
+
+
+[[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 = ["okta.actor.alternate_id"]
+value = 3
+

nldcsc_elastic_rules/rules/integrations/okta/credential_access_multiple_auth_events_from_single_device_behind_proxy.toml

@@ -0,0 +1,128 @@
+[metadata]
+creation_date = "2023/11/10"
+integration = ["okta"]
+maturity = "production"
+updated_date = "2025/09/08"
+
+[rule]
+author = ["Elastic"]
+description = """
+Detects when Okta user authentication events are reported for multiple users with the same device token hash behind a
+proxy.
+"""
+false_positives = [
+    "An Okta admnistrator may be logged into multiple accounts from the same host for legitimate reasons.",
+    "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"
+index = ["logs-okta*"]
+language = "kuery"
+license = "Elastic License v2"
+name = "Multiple Okta User Auth Events with Same Device Token Hash Behind a Proxy"
+note = """## Triage and analysis
+
+### Investigating Multiple Okta User Auth Events with Same Device Token Hash Behind a Proxy
+
+This rule detects when Okta user authentication events are reported for multiple users with the same device token hash behind a proxy. This may indicate that a shared device between users, or that a user is using a proxy to access multiple accounts for password spraying.
+
+#### Possible investigation steps:
+- 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.
+    - Since the device is behind a proxy, the `okta.client.ip` field will not be useful for determining the actual device IP address.
+- Review the `okta.request.ip_chain` field for more information about the geographic location of the proxy.
+- 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://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 = 47
+rule_id = "50887ba8-7ff7-11ee-a038-f661ea17fbcd"
+setup = "The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."
+severity = "medium"
+tags = [
+    "Use Case: Identity and Access Audit",
+    "Data Source: Okta",
+    "Tactic: Credential Access",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "threshold"
+
+query = '''
+event.dataset:okta.system
+    and not okta.actor.id:okta* and okta.debug_context.debug_data.dt_hash:*
+    and okta.event_type:user.authentication* and okta.security_context.is_proxy:true
+'''
+
+
+[[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/"
+
+[rule.threshold]
+field = ["okta.debug_context.debug_data.dt_hash"]
+value = 1
+[[rule.threshold.cardinality]]
+field = "okta.actor.id"
+value = 3
+
+

nldcsc_elastic_rules/rules/integrations/okta/credential_access_multiple_device_token_hashes_for_single_okta_session.toml

@@ -0,0 +1,120 @@
+[metadata]
+creation_date = "2023/11/08"
+integration = ["okta"]
+maturity = "production"
+updated_date = "2025/09/25"
+
+[rule]
+author = ["Elastic"]
+description = """
+This rule detects when a specific Okta actor has multiple device token hashes for a single Okta session. This may
+indicate an authenticated session has been hijacked or is being used by multiple devices. Adversaries may hijack a
+session to gain unauthorized access to Okta admin console, applications, tenants, or other resources.
+"""
+from = "now-9m"
+language = "esql"
+license = "Elastic License v2"
+name = "Multiple Device Token Hashes for Single Okta Session"
+note = """## Triage and analysis
+
+### Investigating Multiple Device Token Hashes for Single Okta Session
+
+This rule detects when a specific Okta actor has multiple device token hashes for a single Okta session. This may indicate an authenticated session has been hijacked or is being used by multiple devices. Adversaries may hijack a session to gain unauthorized access to Okta admin console, applications, tenants, or other resources.
+
+#### Possible investigation steps:
+- Since this is an ESQL rule, the `okta.actor.alternate_id` and `okta.authentication_context.external_session_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.
+    - Authentication events have been filtered out to focus on Okta activity via established sessions.
+- 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.
+- Aggregate by `okta.actor.alternate_id` and `event.action` to determine the type of actions that are being performed by the actor(s) involved in this action.
+    - If various activity is reported that seems to indicate actions from separate users, consider deactivating the user's account temporarily.
+
+### False positive analysis:
+- It is very rare that a legitimate user would have multiple device token hashes for a single Okta session as DT hashes do not change after an authenticated session is established.
+
+### Response and remediation:
+- Consider stopping all sessions for the user(s) involved in this action.
+- If this does not appear to be a false positive, consider resetting passwords for the users involved 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.
+- 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://support.okta.com/help/s/article/session-hijacking-attack-definition-damage-defense?language=en_US",
+    "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 = "cc382a2e-7e52-11ee-9aac-f661ea17fbcd"
+setup = """## Setup
+
+The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
+severity = "medium"
+tags = [
+    "Use Case: Identity and Access Audit",
+    "Data Source: Okta",
+    "Tactic: Credential Access",
+    "Domain: SaaS",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "esql"
+
+query = '''
+from logs-okta*
+| where
+    event.dataset == "okta.system" and
+    not event.action in (
+        "policy.evaluate_sign_on",
+        "user.session.start",
+        "user.authentication.sso"
+    ) and
+    okta.actor.alternate_id != "system@okta.com" and
+    okta.actor.alternate_id rlike "[^@\\s]+\\@[^@\\s]+" and
+    okta.authentication_context.external_session_id != "unknown"
+| keep
+    event.action,
+    okta.actor.alternate_id,
+    okta.authentication_context.external_session_id,
+    okta.debug_context.debug_data.dt_hash
+| stats
+    Esql.okta_debug_context_debug_data_dt_hash_count_distinct = count_distinct(okta.debug_context.debug_data.dt_hash)
+  by
+    okta.actor.alternate_id,
+    okta.authentication_context.external_session_id
+| where
+    Esql.okta_debug_context_debug_data_dt_hash_count_distinct >= 2
+| sort
+    Esql.okta_debug_context_debug_data_dt_hash_count_distinct desc
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1539"
+name = "Steal Web Session Cookie"
+reference = "https://attack.mitre.org/techniques/T1539/"
+
+
+[rule.threat.tactic]
+id = "TA0006"
+name = "Credential Access"
+reference = "https://attack.mitre.org/tactics/TA0006/"
+

nldcsc_elastic_rules/rules/integrations/okta/credential_access_multiple_user_agent_os_authentication.toml

@@ -0,0 +1,110 @@
+[metadata]
+creation_date = "2025/10/22"
+integration = ["okta"]
+maturity = "production"
+updated_date = "2025/10/22"
+
+[rule]
+author = ["Elastic"]
+description = """
+Identifies when a single Okta device token hash (dt_hash) is associated with multiple operating system types. This is
+highly anomalous because a device token is tied to a specific device and its operating system. This alert strongly
+indicates that an attacker has stolen a device token and is using it to impersonate a legitimate user from a
+different machine.
+"""
+false_positives = [
+    """
+    Applications will tag the operating system as null when the device is not recognized as a managed device. In
+    environments where users frequently switch between managed and unmanaged devices, this may lead to false positives.
+    """,
+]
+from = "now-60m"
+index = ["logs-okta.system-*"]
+language = "kuery"
+license = "Elastic License v2"
+name = "Okta Multiple OS Names Detected for a Single DT Hash"
+note = """## Triage and analysis
+
+### Investigating Okta Multiple OS Names Detected for a Single DT Hash
+
+This rule detects when a single Okta device token hash (dt_hash) is associated with multiple operating system types. This is highly anomalous because a device token is tied to a specific device and its operating system. This alert strongly indicates that an attacker has stolen a device token token and is using it to impersonate a legitimate user from a different machine.
+
+### Possible investigation steps
+- Review the `okta.debug_context.debug_data.dt_hash` field to identify the specific device
+trust hash associated with multiple operating systems.
+- Examine the `user.email` field to determine which user account is associated with the suspicious activity
+- Analyze the `source.ip` field to identify the IP addresses from which the different operating systems were reported. Look for any unusual or unexpected locations.
+- Review the `user_agent.os.name` field to see the different operating systems reported for the
+same dt_hash. This will help identify the nature of the anomaly.
+- Check the `event.action` field to understand the context of the authentication events (e.g., MFA verification, standard authentication).
+- Investigate the timeline of events to see when the different operating systems were reported for the same dt_hash. Look for patterns or sequences that may indicate malicious activity.
+- Correlate this activity with other security events in your environment, such as failed login attempts, unusual access patterns, or alerts from endpoint security solutions.
+
+### False positive analysis
+- Applications will tag the operating system as null when the device is not recognized as a managed device
+- In environments where users frequently switch between managed and unmanaged devices, this may lead to false positives.
+
+### Response and remediation
+- Immediately investigate the user account associated with the suspicious activity to determine if it has been compromised.
+- If compromise is confirmed, reset the user's credentials and enforce multi-factor authentication (MFA)
+- Revoke any active sessions associated with the compromised account to prevent further unauthorized access.
+- Review and monitor the affected dt_hash for any further suspicious activity.
+- Educate users about the importance of device security and the risks associated with device tokens.
+- Implement additional monitoring for device token tokens and consider using conditional access policies to restrict access based on device compliance status.
+"""
+risk_score = 73
+rule_id = "fb3ca230-af4e-11f0-900d-f661ea17fbcc"
+severity = "high"
+tags = [
+    "Domain: Identity",
+    "Data Source: Okta",
+    "Data Source: Okta System Logs",
+    "Use Case: Threat Detection",
+    "Tactic: Credential Access",
+    "Resources: Investigation Guide"
+]
+timestamp_override = "event.ingested"
+type = "threshold"
+
+query = '''
+data_stream.dataset: "okta.system"
+    and not okta.debug_context.debug_data.dt_hash: "-"
+    and user_agent.os.name: *
+    and event.action: (
+        "user.authentication.verify" or
+        "user.authentication.auth_via_mfa"
+    )
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1539"
+name = "Steal Web Session Cookie"
+reference = "https://attack.mitre.org/techniques/T1539/"
+
+
+[rule.threat.tactic]
+id = "TA0006"
+name = "Credential Access"
+reference = "https://attack.mitre.org/tactics/TA0006/"
+
+[rule.investigation_fields]
+field_names = [
+    "@timestamp",
+    "okta.debug_context.debug_data.dt_hash",
+    "user.email",
+    "source.ip",
+    "user_agent.os.name",
+    "event.action",
+]
+
+[rule.threshold]
+field = ["okta.debug_context.debug_data.dt_hash"]
+value = 1
+[[rule.threshold.cardinality]]
+field = "user_agent.os.name"
+value = 2
+
+