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

nldcsc_elastic_rules/rules/linux/persistence_yum_package_manager_plugin_file_creation.toml

@@ -0,0 +1,159 @@
+[metadata]
+creation_date = "2024/06/25"
+integration = ["endpoint"]
+maturity = "production"
+updated_date = "2025/01/24"
+
+[rule]
+author = ["Elastic"]
+description = """
+Detects file creation events in the plugin directories for the Yum package manager. In Linux, Yum (Yellowdog Updater,
+Modified) is a command-line utility used for handling packages on (by default) Fedora-based systems, providing functions
+for installing, updating, upgrading, and removing software along with managing package repositories. Attackers can
+backdoor Yum to gain persistence by injecting malicious code into plugins that Yum runs, thereby ensuring continued
+unauthorized access or control each time Yum is used for package management.
+"""
+from = "now-9m"
+index = ["logs-endpoint.events.file*"]
+language = "eql"
+license = "Elastic License v2"
+name = "Yum Package Manager Plugin File Creation"
+references = [
+    "https://github.com/rapid7/metasploit-framework/blob/master/modules/exploits/linux/local/yum_package_manager_persistence.rb",
+    "https://www.elastic.co/security-labs/sequel-on-persistence-mechanisms",
+]
+risk_score = 21
+rule_id = "0b15bcad-aff1-4250-a5be-5d1b7eb56d07"
+setup = """## Setup
+
+This rule requires data coming in from Elastic Defend.
+
+### Elastic Defend Integration Setup
+Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app.
+
+#### Prerequisite Requirements:
+- Fleet is required for Elastic Defend.
+- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).
+
+#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:
+- Go to the Kibana home page and click "Add integrations".
+- In the query bar, search for "Elastic Defend" and select the integration to see more details about it.
+- Click "Add Elastic Defend".
+- Configure the integration name and optionally add a description.
+- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads".
+- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. [Helper guide](https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html).
+- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions"
+- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead.
+For more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).
+- Click "Save and Continue".
+- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts.
+For more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).
+"""
+severity = "low"
+tags = [
+    "Domain: Endpoint",
+    "OS: Linux",
+    "Use Case: Threat Detection",
+    "Tactic: Persistence",
+    "Tactic: Defense Evasion",
+    "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "eql"
+query = '''
+file where host.os.type == "linux" and event.action in ("rename", "creation") and
+file.path : ("/usr/lib/yum-plugins/*", "/etc/yum/pluginconf.d/*") and not (
+  process.executable in (
+    "/bin/dockerd", "/usr/bin/dockerd", "/usr/sbin/dockerd", "/bin/microdnf", "/usr/bin/microdnf", "/bin/rpm",
+    "/usr/bin/rpm", "/bin/snapd", "/usr/bin/snapd", "/bin/yum", "/usr/bin/yum", "/bin/dnf", "/usr/bin/dnf",
+    "/bin/podman", "/usr/bin/podman", "/bin/dnf-automatic", "/usr/bin/dnf-automatic", "/sbin/apk", "/usr/sbin/apk",
+    "/usr/local/sbin/apk", "/bin/podman", "/usr/bin/podman", "/usr/bin/puppet", "/bin/puppet",
+    "/opt/puppetlabs/puppet/bin/puppet", "/usr/bin/chef-client", "/bin/chef-client", "/bin/autossl_check",
+    "/usr/bin/autossl_check", "/proc/self/exe", "/dev/fd/*", "/usr/lib/snapd/snapd", "/usr/local/bin/dockerd",
+    "/usr/libexec/netplan/generate"
+  ) or
+  process.name in ("yumBackend.py", "crio") or
+  file.extension in ("swp", "swpx", "swx") or
+  file.Ext.original.name like ".ansible*" or
+  file.name like ".ansible_tmp*" or
+  process.executable : (
+    "/nix/store/*", "/var/lib/dpkg/*", "/tmp/vmis.*", "/snap/*", "/dev/fd/*", "/usr/lib/*", "/usr/libexec/*",
+    "/etc/kernel/*"
+  ) or
+  process.executable == null or
+  (process.name == "sed" and file.name : "sed*") or
+  (process.name == "perl" and file.name : "e2scrub_all.tmp*")
+)
+'''
+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 Yum Package Manager Plugin File Creation
+
+The Yum package manager is integral to managing software on Fedora-based Linux systems, utilizing plugins to extend its functionality. Adversaries may exploit this by inserting malicious code into these plugins, ensuring persistent access whenever Yum is executed. The detection rule identifies suspicious file creation in plugin directories, excluding legitimate processes and temporary files, to flag potential unauthorized modifications.
+
+### Possible investigation steps
+
+- Review the file creation event details, focusing on the file path to confirm if it matches the plugin directories "/usr/lib/yum-plugins/*" or "/etc/yum/pluginconf.d/*".
+- Identify the process responsible for the file creation by examining the process.executable field, ensuring it is not one of the legitimate processes listed in the exclusion criteria.
+- Check the file extension and name to ensure it is not a temporary or excluded file type, such as those with extensions "swp", "swpx", "swx", or names starting with ".ansible".
+- Investigate the origin and legitimacy of the process by correlating with other system logs or using threat intelligence to determine if the process is known to be associated with malicious activity.
+- Assess the file content for any signs of malicious code or unauthorized modifications, especially if the file is a script or configuration file.
+- Determine if there have been any recent changes or updates to the system that could explain the file creation, such as legitimate software installations or updates.
+
+### False positive analysis
+
+- Legitimate software updates or installations may trigger file creation events in Yum plugin directories. To handle these, users can create exceptions for known package management processes like rpm, dnf, and yum, which are already included in the rule's exclusion list.
+- Temporary files created by text editors or system processes, such as those with extensions like swp, swpx, or swx, can be safely excluded as they are typically non-threatening. Ensure these extensions are part of the exclusion criteria.
+- Automation tools like Ansible may generate temporary files in the plugin directories. Users can exclude file names starting with .ansible or .ansible_tmp to prevent false positives from these operations.
+- Processes running from specific directories like /nix/store or /var/lib/dpkg are often part of legitimate system operations. Users should verify these paths and include them in the exclusion list if they are part of regular system behavior.
+- System maintenance scripts or tools like sed and perl may create temporary files during their execution. Users can exclude these specific process names and file patterns to reduce false alerts.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary.
+- Terminate any suspicious processes that may be running as a result of the malicious plugin modification to halt any ongoing malicious activity.
+- Restore the compromised plugin files from a known good backup to ensure the integrity of the Yum package manager's functionality.
+- Conduct a thorough review of user accounts and permissions on the affected system to identify and remove any unauthorized access or privilege escalations.
+- Implement file integrity monitoring on the Yum plugin directories to detect any future unauthorized modifications promptly.
+- Escalate the incident to the security operations team for further investigation and to determine if additional systems may be affected.
+- Update and patch the system to the latest security standards to mitigate any vulnerabilities that may have been exploited by the adversary."""
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+
+[[rule.threat.technique]]
+id = "T1543"
+name = "Create or Modify System Process"
+reference = "https://attack.mitre.org/techniques/T1543/"
+
+[[rule.threat.technique]]
+id = "T1546"
+name = "Event Triggered Execution"
+reference = "https://attack.mitre.org/techniques/T1546/"
+
+[[rule.threat.technique.subtechnique]]
+id = "T1546.016"
+name = "Installer Packages"
+reference = "https://attack.mitre.org/techniques/T1546/016/"
+
+[[rule.threat.technique]]
+id = "T1574"
+name = "Hijack Execution Flow"
+reference = "https://attack.mitre.org/techniques/T1574/"
+
+[rule.threat.tactic]
+id = "TA0003"
+name = "Persistence"
+reference = "https://attack.mitre.org/tactics/TA0003/"
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+
+[rule.threat.tactic]
+id = "TA0005"
+name = "Defense Evasion"
+reference = "https://attack.mitre.org/tactics/TA0005/"

nldcsc_elastic_rules/rules/linux/privilege_escalation_chown_chmod_unauthorized_file_read.toml

@@ -0,0 +1,142 @@
+[metadata]
+creation_date = "2023/07/28"
+integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_funnel"]
+maturity = "production"
+updated_date = "2025/03/20"
+
+[rule]
+author = ["Elastic"]
+description = """
+This rule monitors for the execution of the "chown" and "chmod" commands with command line flags that could indicate a
+wildcard injection attack. Linux wildcard injection is a type of security vulnerability where attackers manipulate
+commands or input containing wildcards (e.g., *, ?, []) to execute unintended operations or access sensitive data by
+tricking the system into interpreting the wildcard characters in unexpected ways.
+"""
+from = "now-9m"
+index = [
+    "auditbeat-*",
+    "endgame-*",
+    "logs-auditd_manager.auditd-*",
+    "logs-crowdstrike.fdr*",
+    "logs-endpoint.events.process*",
+    "logs-sentinel_one_cloud_funnel.*",
+]
+language = "eql"
+license = "Elastic License v2"
+name = "Potential Unauthorized Access via Wildcard Injection Detected"
+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 Potential Unauthorized Access via Wildcard Injection Detected
+
+In Linux environments, commands like `chown` and `chmod` are used to change file ownership and permissions. Adversaries may exploit wildcard characters in these commands to escalate privileges or access sensitive data by executing unintended operations. The detection rule identifies suspicious use of these commands with recursive flags and wildcard references, signaling potential misuse aimed at privilege escalation or unauthorized data access.
+
+### Possible investigation steps
+
+- Review the process execution details to confirm the presence of the "chown" or "chmod" command with the "-R" flag and wildcard usage in the arguments, as indicated by the query fields process.name, process.args, and event.action.
+- Examine the user account associated with the process execution to determine if it has the necessary permissions to perform such operations and assess if the account has been compromised.
+- Check the command execution history and related logs to identify any preceding or subsequent suspicious activities that might indicate a broader attack pattern or unauthorized access attempts.
+- Investigate the source and destination of the command execution by analyzing network logs and connections to determine if the activity originated from a known or unknown IP address or host.
+- Correlate this event with other alerts or anomalies in the system to identify potential patterns or coordinated attacks, focusing on privilege escalation or credential access attempts as suggested by the rule's tags and threat information.
+
+### False positive analysis
+
+- Routine administrative tasks using chown or chmod with recursive flags may trigger the rule. To manage this, identify and whitelist specific scripts or users that regularly perform these tasks without security risks.
+- Automated system maintenance processes that involve changing file permissions or ownership across directories can be mistaken for malicious activity. Exclude these processes by specifying their command patterns or associated user accounts in the monitoring system.
+- Backup operations that involve copying and setting permissions on large sets of files might be flagged. To prevent this, configure exceptions for known backup tools or scripts that use these commands in a controlled manner.
+- Development environments where developers frequently change file permissions for testing purposes can generate false positives. Implement user-based exceptions for development teams to reduce unnecessary alerts.
+- System updates or package installations that modify file permissions as part of their normal operation may be detected. Create exceptions for trusted package managers or update processes to avoid false alarms.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Terminate any suspicious processes identified as running the `chown` or `chmod` commands with wildcard injections to halt potential privilege escalation activities.
+- Conduct a thorough review of system logs and command histories to identify any unauthorized changes made to file permissions or ownership and revert them to their original state.
+- Reset credentials and review access permissions for users on the affected system to ensure no unauthorized access persists.
+- Implement file integrity monitoring to detect unauthorized changes to critical files and directories in the future.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.
+- Update and patch the affected system to address any vulnerabilities that may have been exploited during the attack, ensuring all security updates are applied."""
+references = ["https://www.exploit-db.com/papers/33930"]
+risk_score = 21
+rule_id = "4a99ac6f-9a54-4ba5-a64f-6eb65695841b"
+setup = """## Setup
+
+This rule requires data coming in from Elastic Defend.
+
+### Elastic Defend Integration Setup
+Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app.
+
+#### Prerequisite Requirements:
+- Fleet is required for Elastic Defend.
+- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).
+
+#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:
+- Go to the Kibana home page and click "Add integrations".
+- In the query bar, search for "Elastic Defend" and select the integration to see more details about it.
+- Click "Add Elastic Defend".
+- Configure the integration name and optionally add a description.
+- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads".
+- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. [Helper guide](https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html).
+- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions"
+- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead.
+For more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).
+- Click "Save and Continue".
+- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts.
+For more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).
+"""
+severity = "low"
+tags = [
+    "Domain: Endpoint",
+    "OS: Linux",
+    "Use Case: Threat Detection",
+    "Tactic: Privilege Escalation",
+    "Tactic: Credential Access",
+    "Data Source: Elastic Endgame",
+    "Data Source: Elastic Defend",
+    "Data Source: Auditd Manager",
+    "Data Source: Crowdstrike",
+    "Data Source: SentinelOne",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "eql"
+
+query = '''
+process where host.os.type == "linux" and event.type == "start" and
+  event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and
+  process.name in ("chown", "chmod") and process.args == "-R" and process.args : "--reference=*"
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1068"
+name = "Exploitation for Privilege Escalation"
+reference = "https://attack.mitre.org/techniques/T1068/"
+
+
+[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 = "T1003"
+name = "OS Credential Dumping"
+reference = "https://attack.mitre.org/techniques/T1003/"
+[[rule.threat.technique.subtechnique]]
+id = "T1003.008"
+name = "/etc/passwd and /etc/shadow"
+reference = "https://attack.mitre.org/techniques/T1003/008/"
+
+
+
+[rule.threat.tactic]
+id = "TA0006"
+name = "Credential Access"
+reference = "https://attack.mitre.org/tactics/TA0006/"
+

nldcsc_elastic_rules/rules/linux/privilege_escalation_container_util_misconfiguration.toml

@@ -0,0 +1,128 @@
+[metadata]
+creation_date = "2023/07/31"
+integration = ["endpoint"]
+maturity = "production"
+updated_date = "2025/02/04"
+
+[rule]
+author = ["Elastic"]
+description = """
+This rule monitors for the execution of processes that interact with Linux containers through an interactive shell
+without root permissions. Utilities such as runc and ctr are universal command-line utilities leveraged to interact with
+containers via root permissions. On systems where the access to these utilities are misconfigured, attackers might be
+able to create and run a container that mounts the root folder or spawn a privileged container vulnerable to a container
+escape attack, which might allow them to escalate privileges and gain further access onto the host file system.
+"""
+from = "now-9m"
+index = ["logs-endpoint.events.process*"]
+language = "eql"
+license = "Elastic License v2"
+name = "Potential Privilege Escalation via Container Misconfiguration"
+references = [
+    "https://book.hacktricks.xyz/linux-hardening/privilege-escalation/runc-privilege-escalation",
+    "https://book.hacktricks.xyz/linux-hardening/privilege-escalation/containerd-ctr-privilege-escalation",
+]
+risk_score = 47
+rule_id = "afe6b0eb-dd9d-4922-b08a-1910124d524d"
+setup = """## Setup
+
+This rule requires data coming in from Elastic Defend.
+
+### Elastic Defend Integration Setup
+Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app.
+
+#### Prerequisite Requirements:
+- Fleet is required for Elastic Defend.
+- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).
+
+#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:
+- Go to the Kibana home page and click "Add integrations".
+- In the query bar, search for "Elastic Defend" and select the integration to see more details about it.
+- Click "Add Elastic Defend".
+- Configure the integration name and optionally add a description.
+- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads".
+- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. [Helper guide](https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html).
+- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions"
+- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead.
+For more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).
+- Click "Save and Continue".
+- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts.
+For more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).
+
+Session View uses process data collected by the Elastic Defend integration, but this data is not always collected by default. Session View is available on enterprise subscription for versions 8.3 and above.
+#### To confirm that Session View data is enabled:
+- Go to “Manage → Policies”, and edit one or more of your Elastic Defend integration policies.
+- Select the” Policy settings” tab, then scroll down to the “Linux event collection” section near the bottom.
+- Check the box for “Process events”, and turn on the “Include session data” toggle.
+- If you want to include file and network alerts in Session View, check the boxes for “Network and File events”.
+- If you want to enable terminal output capture, turn on the “Capture terminal output” toggle.
+For more information about the additional fields collected when this setting is enabled and the usage of Session View for Analysis refer to the [helper guide](https://www.elastic.co/guide/en/security/current/session-view.html).
+"""
+severity = "medium"
+tags = [
+    "Domain: Endpoint",
+    "OS: Linux",
+    "Use Case: Threat Detection",
+    "Tactic: Privilege Escalation",
+    "Domain: Container",
+    "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "eql"
+
+query = '''
+process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and (
+  (process.name == "runc" and process.args == "run") or
+  (process.name == "ctr" and process.args == "run" and process.args in ("--privileged", "--mount"))
+) and not user.Ext.real.id == "0" and not group.Ext.real.id == "0" and
+process.interactive == true and process.parent.interactive == true
+'''
+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 Potential Privilege Escalation via Container Misconfiguration
+
+Containers, managed by tools like runc and ctr, isolate applications for security and efficiency. Misconfigurations can allow attackers to exploit these tools, running containers with elevated privileges or accessing sensitive host resources. The detection rule identifies suspicious use of these utilities by non-root users in interactive sessions, flagging potential privilege escalation attempts.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific non-root user and group involved in the suspicious activity, as indicated by the user.Ext.real.id and group.Ext.real.id fields.
+- Examine the process tree to understand the parent-child relationship of the processes, focusing on the interactive nature of both the process and its parent, as indicated by process.interactive and process.parent.interactive fields.
+- Investigate the command-line arguments used with the runc or ctr utilities, particularly looking for the use of "run" and any potentially dangerous flags like "--privileged" or "--mount" that could indicate an attempt to escalate privileges.
+- Check the system logs and audit logs for any additional context around the time of the alert, focusing on any other suspicious activities or anomalies involving the same user or process.
+- Assess the configuration and access controls of the container management tools on the host to identify any misconfigurations or vulnerabilities that could have been exploited.
+
+### False positive analysis
+
+- Non-root users in development environments may frequently use runc or ctr for legitimate container management tasks. To mitigate this, consider creating exceptions for specific user IDs or groups known to perform these actions regularly.
+- Automated scripts or CI/CD pipelines might execute container commands interactively without root permissions. Identify these scripts and exclude their associated user accounts or process names from triggering the rule.
+- Some system administrators may operate with non-root accounts for security reasons but still require access to container management tools. Document these users and adjust the rule to exclude their activities by user ID or group ID.
+- Training or testing environments where users are encouraged to experiment with container configurations might trigger false positives. Implement a separate monitoring policy for these environments to reduce noise in production alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected container to prevent further unauthorized access or potential lateral movement within the host system.
+- Terminate any suspicious container processes identified by the detection rule to halt any ongoing privilege escalation attempts.
+- Conduct a thorough review of container configurations and permissions, specifically focusing on the use of runc and ctr utilities, to identify and rectify any misconfigurations that allow non-root users to execute privileged operations.
+- Implement strict access controls and enforce the principle of least privilege for container management utilities to ensure only authorized users can execute privileged commands.
+- Monitor for any additional signs of compromise or unusual activity on the host system, particularly focusing on processes initiated by non-root users with elevated privileges.
+- Escalate the incident to the security operations team for further investigation and to assess the potential impact on the broader environment.
+- Update and enhance detection capabilities to include additional indicators of compromise related to container misconfigurations and privilege escalation attempts, ensuring timely alerts for similar threats in the future."""
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1611"
+name = "Escape to Host"
+reference = "https://attack.mitre.org/techniques/T1611/"
+
+
+[rule.threat.tactic]
+id = "TA0004"
+name = "Privilege Escalation"
+reference = "https://attack.mitre.org/tactics/TA0004/"
+

nldcsc_elastic_rules/rules/linux/privilege_escalation_cve_2025_32463_nsswitch_file_creation.toml

@@ -0,0 +1,124 @@
+[metadata]
+creation_date = "2025/10/01"
+integration = ["endpoint", "auditd_manager", "sentinel_one_cloud_funnel", "crowdstrike"]
+maturity = "production"
+updated_date = "2025/10/01"
+
+[rule]
+author = ["Elastic"]
+description = """
+Detects suspicious creation of the nsswitch.conf file, outside of the regular /etc/nsswitch.conf path,
+consistent with attempts to exploit CVE-2025-32463 (the "sudo chroot" privilege escalation), where an
+attacker tricks sudo into using attacker-controlled NSS files or libraries to gain root.
+"""
+from = "now-9m"
+index = [
+    "logs-endpoint.events.file*",
+    "logs-sentinel_one_cloud_funnel.*",
+    "endgame-*",
+    "auditbeat-*",
+    "logs-auditd_manager.auditd-*",
+    "logs-crowdstrike.fdr*",
+]
+language = "eql"
+license = "Elastic License v2"
+name = "Potential CVE-2025-32463 Nsswitch File Creation"
+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 Potential CVE-2025-32463 Nsswitch File Creation
+
+This rule flags creation of an nsswitch.conf file outside the standard /etc location by a shell, an early sign of staging a fake root to coerce sudo's chroot path and hijack NSS resolution (CVE-2025-32463). A common pattern is writing /tmp/chroot/etc/nsswitch.conf, placing or pointing to a malicious NSS module, then running sudo chroot into that directory so name lookups load attacker-controlled code and escalate to root.
+
+### Possible investigation steps
+
+- Correlate the event with any sudo or chroot executions within ±10 minutes that reference the same directory prefix (e.g., /tmp/chroot), capturing full command line, user, TTY, working directory, and exit codes.
+- Inspect the created nsswitch.conf for nonstandard services or module names and enumerate any libnss_*.so* under lib*/ or usr/lib*/ within that prefix, recording owner, hashes, and timestamps.
+- List all contemporaneous file writes under the same prefix (etc, lib*, bin, sbin) to determine whether a chroot rootfs is being assembled and attribute it to a toolchain such as tar, rsync, debootstrap, or custom scripts via process ancestry.
+- Search file access telemetry to see whether privileged processes subsequently read that specific nsswitch.conf or loaded libnss_* from the same path, which would indicate the chroot was exercised.
+- Verify sudo and glibc versions and patch status for CVE-2025-32463 and collect the initiating user’s session context (SSH source, TTY, shell history) to assess exploitability and scope.
+
+### False positive analysis
+
+- An administrator legitimately staging a temporary chroot or test root filesystem may use a shell to create /tmp/*/etc/nsswitch.conf while populating configs, matching the rule even though no privilege escalation is intended.
+- OS installation, recovery, or backup-restore workflows run from a shell can populate a mounted target like /mnt/newroot/etc/nsswitch.conf, creating the file outside /etc as part of maintenance and triggering the alert.
+
+### Response and remediation
+
+- Terminate any sudo or chroot processes referencing the created path (e.g., /tmp/chroot/etc/nsswitch.conf), lock the initiating user’s sudo access, and quarantine the parent directory with root-only permissions.
+- Remove the staged nsswitch.conf and any libnss_*.so* or ld.so.* artifacts under lib*/ or usr/lib*/ within that prefix after collecting copies, hashes, and timestamps for evidence.
+- Restore and verify /etc/nsswitch.conf on the host with correct content and root:root 0644, purge temporary chroot roots under /tmp, /var/tmp, or /mnt, and restart nscd or systemd-resolved to flush cached name-service data.
+- Escalate to incident response if sudo chroot was executed against the same directory, if root processes loaded libnss_* from that path, or if nsswitch.conf appears outside /etc on multiple hosts within a short window.
+- Apply vendor fixes for CVE-2025-32463 to sudo and glibc, disallow chroot in sudoers and enforce env_reset, noexec, and secure_path, and mount /tmp and /var/tmp with noexec,nosuid,nodev to prevent libraries being sourced from user-writable paths.
+- Add controls to block execution from user-created chroot trees by policy (AppArmor or SELinux) and create alerts on creation of */etc/nsswitch.conf or libnss_* writes under non-system paths, with auto-isolation for directories under /tmp or a user’s home.
+"""
+references = [
+    "https://www.stratascale.com/vulnerability-alert-CVE-2025-32463-sudo-chroot",
+    "https://github.com/kh4sh3i/CVE-2025-32463",
+]
+risk_score = 73
+rule_id = "163a8f2f-c8a0-4b7e-9c4a-1184310eb7f3"
+setup = """## Setup
+
+This rule requires data coming in from Elastic Defend.
+
+### Elastic Defend Integration Setup
+Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app.
+
+#### Prerequisite Requirements:
+- Fleet is required for Elastic Defend.
+- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).
+
+#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:
+- Go to the Kibana home page and click "Add integrations".
+- In the query bar, search for "Elastic Defend" and select the integration to see more details about it.
+- Click "Add Elastic Defend".
+- Configure the integration name and optionally add a description.
+- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads".
+- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. [Helper guide](https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html).
+- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions"
+- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead.
+For more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).
+- Click "Save and Continue".
+- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts.
+For more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).
+"""
+severity = "high"
+tags = [
+    "Domain: Endpoint",
+    "OS: Linux",
+    "Use Case: Threat Detection",
+    "Tactic: Privilege Escalation",
+    "Data Source: Elastic Defend",
+    "Data Source: SentinelOne",
+    "Data Source: Crowdstrike",
+    "Data Source: Elastic Endgame",
+    "Data Source: Auditd Manager",
+    "Use Case: Vulnerability",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "eql"
+query = '''
+file where host.os.type == "linux" and event.type == "creation" and file.path like "/*/etc/nsswitch.conf" and
+process.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and
+not (
+  process.name == "dash" and file.path like ("/var/tmp/mkinitramfs_*", "/tmp/tmp.*/mkinitramfs_*")
+)
+'''
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+
+[[rule.threat.technique]]
+id = "T1068"
+name = "Exploitation for Privilege Escalation"
+reference = "https://attack.mitre.org/techniques/T1068/"
+
+[rule.threat.tactic]
+id = "TA0004"
+name = "Privilege Escalation"
+reference = "https://attack.mitre.org/tactics/TA0004/"