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

nldcsc_elastic_rules/rules/integrations/okta/initial_access_successful_application_sso_from_unknown_client_device.toml

@@ -0,0 +1,99 @@
+[metadata]
+creation_date = "2024/10/07"
+integration = ["okta"]
+maturity = "production"
+updated_date = "2025/07/02"
+
+[rule]
+author = ["Elastic"]
+description = """
+Detects successful single sign-on (SSO) events to Okta applications from an unrecognized or "unknown" client device, as
+identified by the user-agent string. This activity may be indicative of exploitation of a vulnerability in Okta's
+Classic Engine, which could allow an attacker to bypass application-specific sign-on policies, such as device or network
+restrictions. The vulnerability potentially enables unauthorized access to applications using only valid, stolen
+credentials, without requiring additional authentication factors.
+"""
+from = "now-9m"
+index = ["filebeat-*", "logs-okta*"]
+language = "kuery"
+license = "Elastic License v2"
+name = "Successful Application SSO from Rare Unknown Client Device"
+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 Successful Application SSO from Rare Unknown Client Device
+
+Single sign-on (SSO) streamlines user access across applications by using a single set of credentials. However, adversaries can exploit vulnerabilities in SSO systems, like Okta's, to bypass security policies using stolen credentials. The detection rule identifies unusual SSO events from unknown devices, signaling potential unauthorized access attempts, thus helping to mitigate risks associated with credential theft.
+
+### Possible investigation steps
+
+- Review the event details in the alert to confirm the presence of the "Unknown" or "unknown" client device in the okta.client.device field.
+- Check the user-agent string associated with the event to gather more information about the unknown device and assess if it matches any known legitimate devices used by the user.
+- Investigate the user's recent login history and patterns to identify any anomalies or deviations from their typical behavior, such as unusual login times or locations.
+- Verify if there have been any recent changes to the user's account, such as password resets or modifications to multi-factor authentication settings, which could indicate account compromise.
+- Cross-reference the IP address associated with the SSO event against known malicious IP databases or internal threat intelligence to identify potential threats.
+- Contact the user to confirm whether they recognize the login activity and the device used, ensuring it was an authorized access attempt.
+
+### False positive analysis
+
+- Employees using new or updated devices may trigger false positives. Regularly update the list of recognized devices to include these changes.
+- Legitimate users accessing applications from different locations or networks, such as while traveling, can appear as unknown devices. Implement geolocation checks and allow exceptions for known travel patterns.
+- Software updates or changes in user-agent strings can cause devices to be misidentified. Monitor for consistent patterns and adjust the rule to accommodate these variations.
+- Shared devices in environments like conference rooms or labs may not have unique identifiers. Establish a process to register these shared devices to prevent them from being flagged.
+- Temporary network issues causing devices to appear as unknown can lead to false positives. Correlate with network logs to verify if the device is indeed unknown or if it was a transient issue.
+
+### Response and remediation
+
+- Immediately isolate the affected user account by disabling it to prevent further unauthorized access.
+- Conduct a thorough review of the affected user's recent activity across all Okta-integrated applications to identify any unauthorized actions or data access.
+- Reset the affected user's credentials and enforce a password change, ensuring the new password adheres to strong security policies.
+- Implement multi-factor authentication (MFA) for the affected user account if not already in place, to add an additional layer of security.
+- Notify the security team and relevant stakeholders about the incident for awareness and further investigation.
+- Review and update Okta's device recognition policies to improve detection of unknown or rare devices, reducing the risk of similar incidents.
+- Monitor for any further suspicious SSO activities from unknown devices and escalate to the incident response team if additional alerts are triggered."""
+references = ["https://trust.okta.com/security-advisories/okta-classic-application-sign-on-policy-bypass-2024/"]
+risk_score = 47
+rule_id = "1502a836-84b2-11ef-b026-f661ea17fbcc"
+severity = "medium"
+tags = [
+    "Domain: SaaS",
+    "Data Source: Okta",
+    "Use Case: Threat Detection",
+    "Use Case: Identity and Access Audit",
+    "Tactic: Initial Access",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "new_terms"
+
+query = '''
+event.dataset: "okta.system"
+    and event.action: "user.authentication.sso"
+    and event.outcome: "success"
+    and okta.client.device: ("Unknown" or "unknown")
+'''
+
+
+[[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.new_terms]
+field = "new_terms_fields"
+value = ["client.user.name", "okta.client.user_agent.raw_user_agent"]
+[[rule.new_terms.history_window_start]]
+field = "history_window_start"
+value = "now-14d"
+
+

nldcsc_elastic_rules/rules/integrations/okta/initial_access_suspicious_activity_reported_by_okta_user.toml

@@ -0,0 +1,129 @@
+[metadata]
+creation_date = "2020/05/21"
+integration = ["okta"]
+maturity = "production"
+updated_date = "2025/07/02"
+
+[rule]
+author = ["Elastic"]
+description = """
+Detects when a user reports suspicious activity for their Okta account. These events should be investigated, as they can
+help security teams identify when an adversary is attempting to gain access to their network.
+"""
+false_positives = ["A user may report suspicious activity on their Okta account in error."]
+index = ["filebeat-*", "logs-okta*"]
+language = "kuery"
+license = "Elastic License v2"
+name = "Suspicious Activity Reported by Okta User"
+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 Suspicious Activity Reported by Okta User
+
+Okta is a widely used identity management service that facilitates secure user authentication and access control. Adversaries may exploit compromised credentials to gain unauthorized access, posing a threat to network security. The detection rule monitors for user-reported suspicious activity, signaling potential unauthorized access attempts. By analyzing these alerts, security teams can swiftly identify and mitigate threats, leveraging Okta's logging capabilities to trace and respond to malicious actions.
+
+### Possible investigation steps
+
+- Review the specific event details in the Okta logs where event.dataset is okta.system and event.action is user.account.report_suspicious_activity_by_enduser to gather initial context about the reported activity.
+- Identify the user who reported the suspicious activity and check their recent login history and access patterns for any anomalies or deviations from their typical behavior.
+- Correlate the reported suspicious activity with other security logs and alerts to determine if there are any related incidents or patterns indicating a broader attack.
+- Verify if there are any known vulnerabilities or compromised credentials associated with the user's account that could have been exploited.
+- Contact the user to gather additional information about the suspicious activity they observed and confirm whether they recognize any recent access attempts or changes to their account.
+- Assess the risk and potential impact of the suspicious activity on the network and determine if any immediate containment or remediation actions are necessary.
+
+### False positive analysis
+
+- Users frequently accessing their accounts from new devices or locations may trigger false positives. Implement geofencing or device recognition to reduce these alerts.
+- Routine administrative actions, such as password resets or account updates, might be misinterpreted as suspicious. Exclude these actions from alerts if they are performed by known administrators.
+- Automated scripts or applications using service accounts can generate alerts if not properly configured. Ensure these accounts are whitelisted or have appropriate permissions set.
+- Employees using VPNs or proxy services for remote work can cause location-based false positives. Consider marking known VPN IP addresses as safe.
+- High-volume login attempts from legitimate users, such as during password recovery, can be mistaken for suspicious activity. Monitor for patterns and adjust thresholds accordingly.
+
+### Response and remediation
+
+- Immediately isolate the affected user account by temporarily disabling it to prevent further unauthorized access.
+- Notify the user and relevant stakeholders about the suspicious activity and the actions being taken to secure the account.
+- Conduct a password reset for the affected user account and enforce multi-factor authentication (MFA) if not already enabled.
+- Review recent login activity and access logs for the affected account to identify any unauthorized access or data exfiltration attempts.
+- Escalate the incident to the security operations center (SOC) for further investigation and to determine if other accounts or systems have been compromised.
+- Implement additional monitoring on the affected account and related systems to detect any further suspicious activity.
+- Update security policies and procedures based on findings to prevent similar incidents in the future, ensuring alignment with MITRE ATT&CK framework recommendations for Initial Access and Valid Accounts.
+
+## 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 = "f994964f-6fce-4d75-8e79-e16ccc412588"
+severity = "medium"
+tags = [
+    "Use Case: Identity and Access Audit",
+    "Data Source: Okta",
+    "Tactic: Initial Access",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "query"
+
+query = '''
+event.dataset:okta.system and event.action:user.account.report_suspicious_activity_by_enduser
+'''
+
+
+[[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.technique]]
+id = "T1078"
+name = "Valid Accounts"
+reference = "https://attack.mitre.org/techniques/T1078/"
+
+
+[rule.threat.tactic]
+id = "TA0003"
+name = "Persistence"
+reference = "https://attack.mitre.org/tactics/TA0003/"
+[[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 = "TA0004"
+name = "Privilege Escalation"
+reference = "https://attack.mitre.org/tactics/TA0004/"
+[[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 = "TA0005"
+name = "Defense Evasion"
+reference = "https://attack.mitre.org/tactics/TA0005/"
+

nldcsc_elastic_rules/rules/integrations/okta/lateral_movement_multiple_sessions_for_single_user.toml

@@ -0,0 +1,113 @@
+[metadata]
+creation_date = "2023/11/07"
+integration = ["okta"]
+maturity = "production"
+updated_date = "2025/07/02"
+
+[rule]
+author = ["Elastic"]
+description = """
+Detects when a user has started multiple Okta sessions with the same user account and different session IDs. This may
+indicate that an attacker has stolen the user's session cookie and is using it to access the user's account from a
+different location.
+"""
+false_positives = ["A user may have multiple sessions open at the same time, such as on a mobile device and a laptop."]
+from = "now-35m"
+index = ["filebeat-*", "logs-okta*"]
+interval = "30m"
+language = "kuery"
+license = "Elastic License v2"
+name = "Multiple Okta Sessions Detected for a Single User"
+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 Multiple Okta Sessions Detected for a Single User
+
+Okta is a widely used identity management service that facilitates secure user authentication and access control. Adversaries may exploit Okta by hijacking session cookies, allowing unauthorized access to user accounts from different locations. The detection rule identifies anomalies by flagging multiple session initiations with distinct session IDs for the same user, excluding legitimate Okta system actors, thus highlighting potential unauthorized access attempts.
+
+### Possible investigation steps
+
+- Review the Okta logs to identify the specific user account associated with the multiple session initiations and note the distinct session IDs.
+- Check the geographic locations and IP addresses associated with each session initiation to determine if there are any unusual or unexpected locations.
+- Investigate the timestamps of the session initiations to see if they align with the user's typical login patterns or if they suggest simultaneous logins from different locations.
+- Examine the okta.actor.id and okta.actor.display_name fields to ensure that the sessions were not initiated by legitimate Okta system actors.
+- Contact the user to verify if they recognize the session activity and if they have recently logged in from multiple devices or locations.
+- Assess if there are any other related security alerts or incidents involving the same user account that could indicate a broader compromise.
+
+### False positive analysis
+
+- Legitimate multiple device usage: Users may legitimately access their accounts from multiple devices, leading to multiple session initiations. To handle this, create exceptions for users who frequently use multiple devices for work.
+- Frequent travel or remote work: Users who travel often or work remotely may trigger this rule due to accessing Okta from various locations. Consider setting up location-based exceptions for these users.
+- Shared accounts: In environments where account sharing is common, multiple sessions may be expected. Implement policies to discourage account sharing or create exceptions for known shared accounts.
+- Automated scripts or integrations: Some users may have automated processes that initiate multiple sessions. Identify these scripts and exclude them from the rule by their specific session patterns.
+- Testing and development environments: Users involved in testing or development may generate multiple sessions as part of their work. Exclude these environments from the rule to prevent false positives.
+
+### Response and remediation
+
+- Immediately terminate all active sessions for the affected user account to prevent further unauthorized access.
+- Reset the user's password and invalidate any existing session cookies to ensure that any stolen session cookies are rendered useless.
+- Conduct a thorough review of recent login activity and session logs for the affected user to identify any suspicious or unauthorized access patterns.
+- Notify the user of the potential compromise and advise them to verify any recent account activity for unauthorized actions.
+- Escalate the incident to the security operations team for further investigation and to determine if additional accounts or systems may be affected.
+- Implement multi-factor authentication (MFA) for the affected user account if not already in place, to add an additional layer of security against unauthorized access.
+- Update and enhance monitoring rules to detect similar anomalies in the future, focusing on unusual session patterns and access from unexpected locations.
+
+## 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://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 = "621e92b6-7e54-11ee-bdc0-f661ea17fbcd"
+severity = "medium"
+tags = [
+    "Use Case: Identity and Access Audit",
+    "Data Source: Okta",
+    "Tactic: Lateral Movement",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "threshold"
+
+query = '''
+event.dataset:okta.system
+    and okta.event_type:user.session.start
+    and okta.authentication_context.external_session_id:*
+    and not (okta.actor.id: okta* or okta.actor.display_name: okta*)
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1550"
+name = "Use Alternate Authentication Material"
+reference = "https://attack.mitre.org/techniques/T1550/"
+[[rule.threat.technique.subtechnique]]
+id = "T1550.004"
+name = "Web Session Cookie"
+reference = "https://attack.mitre.org/techniques/T1550/004/"
+
+
+
+[rule.threat.tactic]
+id = "TA0008"
+name = "Lateral Movement"
+reference = "https://attack.mitre.org/tactics/TA0008/"
+
+[rule.threshold]
+field = ["okta.actor.id"]
+value = 1
+[[rule.threshold.cardinality]]
+field = "okta.authentication_context.external_session_id"
+value = 3
+
+

nldcsc_elastic_rules/rules/integrations/okta/okta_threatinsight_threat_suspected_promotion.toml

@@ -0,0 +1,67 @@
+[metadata]
+creation_date = "2020/05/21"
+integration = ["okta"]
+maturity = "production"
+promotion = true
+updated_date = "2025/07/02"
+
+[rule]
+author = ["Elastic"]
+description = """
+Okta ThreatInsight is a feature that provides valuable debug data regarding authentication and authorization processes,
+which is logged in the system. Within this data, there is a specific field called threat_suspected, which represents
+Okta's internal evaluation of the authentication or authorization workflow. When this field is set to True, it suggests
+the presence of potential credential access techniques, such as password-spraying, brute-forcing, replay attacks, and
+other similar threats.
+"""
+index = ["filebeat-*", "logs-okta*"]
+language = "kuery"
+license = "Elastic License v2"
+name = "Okta ThreatInsight Threat Suspected Promotion"
+note = """## Setup
+
+## Triage and analysis
+
+This is a promotion rule for Okta ThreatInsight suspected threat events, which are alertable events per the vendor.
+Consult vendor documentation on interpreting specific events.
+"""
+references = [
+    "https://developer.okta.com/docs/reference/api/system-log/",
+    "https://developer.okta.com/docs/reference/api/event-types/",
+    "https://help.okta.com/en-us/Content/Topics/Security/threat-insight/configure-threatinsight-system-log.html",
+    "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 = "6885d2ae-e008-4762-b98a-e8e1cd3a81e9"
+rule_name_override = "okta.display_message"
+severity = "medium"
+tags = ["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:security.threat.detected or okta.debug_context.debug_data.threat_suspected: true)
+'''
+
+
+[[rule.severity_mapping]]
+field = "okta.debug_context.debug_data.risk_level"
+operator = "equals"
+severity = "low"
+value = "LOW"
+
+[[rule.severity_mapping]]
+field = "okta.debug_context.debug_data.risk_level"
+operator = "equals"
+severity = "medium"
+value = "MEDIUM"
+
+[[rule.severity_mapping]]
+field = "okta.debug_context.debug_data.risk_level"
+operator = "equals"
+severity = "high"
+value = "HIGH"
+
+

nldcsc_elastic_rules/rules/integrations/okta/persistence_administrator_privileges_assigned_to_okta_group.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 when an administrator role is assigned to an Okta group. An adversary may attempt to assign administrator
+privileges to an Okta group in order to assign additional permissions to compromised user accounts and maintain access
+to their target organization.
+"""
+false_positives = [
+    """
+    Administrator roles may be assigned to Okta users by a Super Admin user. Verify that the behavior was expected.
+    Exceptions can be added to this rule to filter expected behavior.
+    """,
+]
+index = ["filebeat-*", "logs-okta*"]
+language = "kuery"
+license = "Elastic License v2"
+name = "Administrator Privileges Assigned to an Okta Group"
+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 Administrator Privileges Assigned to an Okta Group
+
+Okta is a widely used identity management service that facilitates secure user authentication and access control. Administrator privileges in Okta allow users to manage settings and permissions, making them a target for adversaries seeking persistent access. Malicious actors may exploit these privileges by assigning them to groups, thereby extending elevated access to compromised accounts. The detection rule monitors system events for privilege grants to groups, flagging potential unauthorized privilege escalations.
+
+### Possible investigation steps
+
+- Review the event logs for entries with event.dataset:okta.system and event.action:group.privilege.grant to identify the specific group and administrator role assigned.
+- Identify the user account that initiated the privilege grant action and verify if the account has a history of suspicious activity or if it has been compromised.
+- Check the membership of the affected Okta group to determine which user accounts have gained elevated privileges and assess if any of these accounts are unauthorized or compromised.
+- Investigate recent activities of the affected group members to identify any unusual or unauthorized actions that may indicate malicious intent.
+- Review the organization's change management records to confirm if the privilege assignment was part of an approved change request or if it was unauthorized.
+- If unauthorized activity is confirmed, initiate incident response procedures to revoke the unauthorized privileges and secure the affected accounts.
+
+### False positive analysis
+
+- Routine administrative tasks may trigger alerts when legitimate IT staff assign administrator roles to groups for maintenance or updates. To manage this, create exceptions for known IT personnel or scheduled maintenance windows.
+- Organizational changes such as mergers or department restructuring might require temporary privilege escalations. Document these changes and adjust the detection rule to exclude these specific events during the transition period.
+- Automated scripts or third-party integrations that manage group permissions could inadvertently trigger false positives. Identify these scripts and whitelist their actions within the monitoring system to prevent unnecessary alerts.
+- Training or onboarding sessions where temporary admin access is granted to groups for demonstration purposes can cause alerts. Ensure these sessions are logged and recognized as non-threatening to avoid false positives.
+
+### Response and remediation
+
+- Immediately revoke the administrator privileges assigned to the Okta group to prevent further unauthorized access or privilege escalation.
+- Conduct a thorough review of recent group membership changes and privilege assignments in Okta to identify any other unauthorized modifications.
+- Isolate and investigate any user accounts that were part of the affected group to determine if they have been compromised.
+- Reset passwords and enforce multi-factor authentication (MFA) for all accounts that were part of the affected group to secure them against further unauthorized access.
+- Notify the security team and relevant stakeholders about the incident to ensure awareness and coordinated response efforts.
+- Implement additional monitoring on the affected group and related user accounts to detect any further suspicious activities.
+- Review and update access control policies to ensure that only necessary groups and users have administrative privileges, reducing the risk of similar incidents in the future.
+
+## 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/administrators-admin-comparison.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 = "b8075894-0b62-46e5-977c-31275da34419"
+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:group.privilege.grant
+'''
+
+
+[[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_administrator_role_assigned_to_okta_user.toml

@@ -0,0 +1,100 @@
+[metadata]
+creation_date = "2020/11/06"
+integration = ["okta"]
+maturity = "production"
+updated_date = "2025/07/02"
+
+[rule]
+author = ["Elastic"]
+description = """
+Identifies when an administrator role is assigned to an Okta user. An adversary may attempt to assign an administrator
+role to an Okta user in order to assign additional permissions to a user account and maintain access to their target's
+environment.
+"""
+false_positives = [
+    """
+    Administrator roles may be assigned to Okta users by a Super Admin user. Verify that the behavior was expected.
+    Exceptions can be added to this rule to filter expected behavior.
+    """,
+]
+index = ["filebeat-*", "logs-okta*"]
+language = "kuery"
+license = "Elastic License v2"
+name = "Administrator Role Assigned to an Okta User"
+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 Administrator Role Assigned to an Okta User
+
+Okta is a widely used identity management service that facilitates secure user authentication and access control. In environments using Okta, assigning an administrator role grants elevated permissions, which can be exploited by adversaries to maintain unauthorized access. The detection rule monitors system events for privilege grants, flagging suspicious role assignments to mitigate potential abuse.
+
+### Possible investigation steps
+
+- Review the event details to confirm the presence of the event.dataset:okta.system and event.action:user.account.privilege.grant fields, ensuring the alert is triggered by the correct conditions.
+- Identify the user account that was assigned the administrator role and gather information about their recent activities and login history to assess any unusual behavior.
+- Check the timestamp of the role assignment event to determine if it coincides with any other suspicious activities or known incidents.
+- Investigate the source IP address and location associated with the role assignment event to verify if it aligns with the user's typical access patterns.
+- Review the change history for the affected user account to identify any other recent modifications or privilege escalations that may indicate malicious intent.
+- Consult with the user or their manager to verify if the role assignment was authorized and legitimate, documenting any discrepancies or unauthorized actions.
+
+### False positive analysis
+
+- Routine administrative tasks may trigger the rule when legitimate IT staff assign administrator roles for maintenance or onboarding purposes. To manage this, create exceptions for known IT personnel or scheduled maintenance windows.
+- Automated scripts or integrations that require elevated permissions might cause false positives. Identify these scripts and whitelist their associated accounts to prevent unnecessary alerts.
+- Organizational changes such as mergers or department restructuring can lead to multiple legitimate role assignments. During these periods, temporarily adjust the rule sensitivity or increase monitoring to differentiate between expected and suspicious activities.
+- Training or testing environments where roles are frequently assigned for simulation purposes can generate false positives. Exclude these environments from the rule or set up a separate monitoring profile for them.
+
+### Response and remediation
+
+- Immediately revoke the administrator role from the affected Okta user account to prevent further unauthorized access or privilege escalation.
+- Conduct a thorough review of recent activity logs for the affected user account to identify any unauthorized actions or changes made while the elevated privileges were active.
+- Reset the password and enforce multi-factor authentication (MFA) for the affected user account to secure it against potential compromise.
+- Notify the security team and relevant stakeholders about the incident, providing details of the unauthorized role assignment and any identified malicious activities.
+- Implement additional monitoring for the affected user account and similar accounts to detect any further suspicious activities or attempts to reassign elevated privileges.
+- Review and update access control policies to ensure that administrator role assignments require additional verification or approval processes to prevent unauthorized changes.
+- If evidence of broader compromise is found, initiate a full security incident response process, including forensic analysis and potential involvement of external cybersecurity experts.
+
+## 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/administrators-admin-comparison.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",
+    "https://www.elastic.co/security-labs/okta-and-lapsus-what-you-need-to-know",
+]
+risk_score = 47
+rule_id = "f06414a6-f2a4-466d-8eba-10f85e8abf71"
+severity = "medium"
+tags = [
+    "Data Source: Okta",
+    "Use Case: Identity and Access Audit",
+    "Tactic: Persistence",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "query"
+
+query = '''
+event.dataset:okta.system and event.action:user.account.privilege.grant
+'''
+
+
+[[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/"
+