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

nldcsc_elastic_rules/rules/linux/execution_abnormal_process_id_file_created.toml

@@ -0,0 +1,160 @@
+[metadata]
+creation_date = "2022/05/11"
+integration = ["endpoint"]
+maturity = "production"
+updated_date = "2025/01/24"
+
+[rule]
+author = ["Elastic"]
+description = """
+Identifies the creation of a Process ID (PID), lock or reboot file created in temporary file storage paradigm (tmpfs)
+directory /var/run. On Linux, the PID files typically hold the process ID to track previous copies running and manage
+other tasks. Certain Linux malware use the /var/run directory for holding data, executables and other tasks, disguising
+itself or these files as legitimate PID files.
+"""
+false_positives = [
+    """
+    False-Positives (FP) can appear if the PID file is legitimate and holding a process ID as intended. To
+    differentiate, if the PID file is an executable or larger than 10 bytes, it should be ruled suspicious.
+    """,
+]
+from = "now-9m"
+index = ["logs-endpoint.events.*", "endgame-*"]
+language = "kuery"
+license = "Elastic License v2"
+name = "Abnormal Process ID or Lock File Created"
+note = """## Triage and analysis
+
+### Investigating Abnormal Process ID or Lock File Created
+
+Linux applications may need to save their process identification number (PID) for various purposes: from signaling that a program is running to serving as a signal that a previous instance of an application didn't exit successfully. PID files contain its creator process PID in an integer value.
+
+Linux lock files are used to coordinate operations in files so that conflicts and race conditions are prevented.
+
+This rule identifies the creation of PID, lock, or reboot files in the /var/run/ directory. Attackers can masquerade malware, payloads, staged data for exfiltration, and more as legitimate PID files.
+
+#### Possible investigation steps
+
+- Retrieve the file and determine if it is malicious:
+    - Check the contents of the PID files. They should only contain integer strings.
+    - Check the file type of the lock and PID files to determine if they are executables. This is only observed in     malicious files.
+    - Check the size of the subject file. Legitimate PID files should be under 10 bytes.
+    - Check if the lock or PID file has high entropy. This typically indicates an encrypted payload.
+        - Analysts can use tools like `ent` to measure entropy.
+    - Examine the reputation of the SHA-256 hash in the PID file. Use a database like VirusTotal to identify additional pivots and artifacts for investigation.
+- Trace the file's creation to ensure it came from a legitimate or authorized process.
+- Investigate other alerts associated with the user/host during the past 48 hours.
+- Investigate any abnormal account behavior, such as command executions, file creations or modifications, and network connections.
+- Investigate any abnormal behavior by the subject process such as network connections, file modifications, and any spawned child processes.
+
+### False positive analysis
+
+- False positives can appear if the PID file is legitimate and holding a process ID as intended. If the PID file is an executable or has a file size that's larger than 10 bytes, it should be ruled suspicious.
+- If this activity is expected and noisy in your environment, consider adding exceptions — preferably with a combination of file name and process executable conditions.
+
+### Response and remediation
+
+- Initiate the incident response process based on the outcome of the triage.
+- Isolate the involved host to prevent further post-compromise behavior.
+- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services.
+- Block the identified indicators of compromise (IoCs).
+- Take actions to terminate processes and connections used by the attacker.
+- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components.
+- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector.
+- 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).
+"""
+references = [
+    "https://www.sandflysecurity.com/blog/linux-file-masquerading-and-malicious-pids-sandfly-1-2-6-update/",
+    "https://twitter.com/GossiTheDog/status/1522964028284411907",
+    "https://exatrack.com/public/Tricephalic_Hellkeeper.pdf",
+    "https://www.elastic.co/security-labs/a-peek-behind-the-bpfdoor",
+]
+risk_score = 47
+rule_id = "cac91072-d165-11ec-a764-f661ea17fbce"
+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 = "medium"
+tags = [
+    "Domain: Endpoint",
+    "OS: Linux",
+    "Use Case: Threat Detection",
+    "Tactic: Execution",
+    "Threat: BPFDoor",
+    "Resources: Investigation Guide",
+    "Data Source: Elastic Defend",
+    "Data Source: Elastic Endgame",
+]
+timestamp_override = "event.ingested"
+type = "new_terms"
+query = '''
+host.os.type:linux and event.category:file and event.action:(creation or file_create_event) and
+file.extension:(pid or lock or reboot) and file.path:(/var/run/* or /run/*) and (
+  (process.name : (
+    bash or dash or sh or tcsh or csh or zsh or ksh or fish or ash or touch or nano or vim or vi or editor or mv or cp)
+  ) or (
+  process.executable : (
+    ./* or /tmp/* or /var/tmp/* or /dev/shm/* or /var/run/* or /boot/* or /srv/* or /run/*
+  ))
+) and not (
+  process.executable : (
+  /tmp/newroot/* or /run/containerd/* or /run/k3s/containerd/* or /run/k0s/container* or /snap/* or /vz/* or
+  /var/lib/docker/* or /etc/*/universal-hooks/pkgs/mysql-community-server/* or /var/lib/snapd/* or /etc/rubrik/* or
+  /run/udev/data/*
+  ) or
+  process.name : (
+    go or git or containerd* or snap-confine or cron or crond or sshd or unattended-upgrade or vzctl or ifup or
+    rpcbind or runc or gitlab-runner-helper or elastic-agent or metricbeat or redis-server or libvirt_leaseshelper or
+    s6-ipcserver-socketbinder or xinetd or libvirtd or veeamdeploymentsvc  or dnsmasq or virtlogd or lynis or
+    veeamtransport
+  ) or
+  file.name : (
+    jem.*.pid or lynis.pid or redis.pid or yum.pid or MFS.pid or jenkins.pid or nvmupdate.pid or openlitespeed.pid or
+    rhnsd.pid
+  ) or
+  file.path : (/run/containerd/* or /var/run/docker/containerd/* or /var/run/jem*.pid)
+)
+'''
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+
+[[rule.threat.technique]]
+id = "T1106"
+name = "Native API"
+reference = "https://attack.mitre.org/techniques/T1106/"
+
+[rule.threat.tactic]
+id = "TA0002"
+name = "Execution"
+reference = "https://attack.mitre.org/tactics/TA0002/"
+
+[rule.new_terms]
+field = "new_terms_fields"
+value = ["process.executable", "file.name"]
+
+[[rule.new_terms.history_window_start]]
+field = "history_window_start"
+value = "now-14d"

nldcsc_elastic_rules/rules/linux/execution_container_management_binary_launched_inside_container.toml

@@ -0,0 +1,118 @@
+[metadata]
+creation_date = "2025/03/12"
+integration = ["endpoint"]
+maturity = "production"
+updated_date = "2025/06/17"
+
+[rule]
+author = ["Elastic"]
+description = """
+This rule detects when a container management binary is run from inside a container. These binaries are critical
+components of many containerized environments, and their presence and execution in unauthorized containers could
+indicate compromise or a misconfiguration.
+"""
+false_positives = [
+    """
+    There is a potential for false positives if the container is used for legitimate administrative tasks that require
+    the use of container management utilities, such as deploying, scaling, or updating containerized applications. It is
+    important to investigate any alerts generated by this rule to determine if they are indicative of malicious activity
+    or part of legitimate container activity.
+    """,
+]
+from = "now-9m"
+index = ["logs-endpoint.events.process*"]
+language = "eql"
+license = "Elastic License v2"
+name = "Container Management Utility Run Inside A Container"
+risk_score = 21
+rule_id = "4b74d3b0-416e-4099-b432-677e1cd098cc"
+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: Container",
+    "OS: Linux",
+    "Use Case: Threat Detection",
+    "Tactic: Execution",
+    "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.entry_leader.entry_meta.type == "container" and process.interactive == true and
+process.name in ("dockerd", "docker", "kubelet", "kube-proxy", "kubectl", "containerd", "systemd", "crictl") and
+not process.parent.executable in ("/sbin/init", "/usr/bin/dockerd")
+'''
+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 Container Management Utility Run Inside A Container
+
+Container management utilities like Docker and Kubectl are essential for orchestrating and managing containerized applications. They facilitate tasks such as deployment, scaling, and networking. However, adversaries can exploit these tools to execute unauthorized commands within containers, potentially leading to system compromise. The detection rule identifies suspicious execution of these utilities within containers, signaling possible misuse or misconfiguration, by monitoring specific process activities and event types.
+
+### Possible investigation steps
+
+- Examine the process name and command line arguments to understand the context of the execution and identify any anomalies or unauthorized commands.
+- Check the user and permissions associated with the process to assess if it aligns with expected roles and access levels for container management tasks.
+- Investigate the container's creation and deployment history to identify any recent changes or deployments that could explain the presence of the management utility.
+- Analyze network activity associated with the container to detect any unusual connections or data transfers that might indicate malicious activity.
+- Correlate the event with other security alerts or logs to identify patterns or related incidents that could provide additional context or evidence of compromise.
+
+### False positive analysis
+
+- Routine maintenance tasks within containers can trigger the rule. Exclude known maintenance scripts or processes by adding them to an allowlist if they frequently execute container management utilities.
+- Development and testing environments often run container management commands for legitimate purposes. Consider excluding these environments from monitoring or adjust the rule to focus on production environments only.
+- Automated deployment tools may execute container management commands as part of their workflow. Identify these tools and create exceptions for their activities to prevent false positives.
+- System updates or patches might involve running container management utilities. Monitor update schedules and temporarily adjust the rule to avoid unnecessary alerts during these periods.
+- Legitimate administrative actions by authorized personnel can trigger the rule. Implement user-based exceptions for known administrators to reduce false positives while maintaining security oversight.
+
+### Response and remediation
+
+- Immediately isolate the affected container to prevent further unauthorized access or execution of commands. This can be done by stopping the container or disconnecting it from the network.
+- Review the container's configuration and access controls to identify any misconfigurations or unauthorized access permissions that may have allowed the execution of container management utilities.
+- Conduct a thorough analysis of the container's logs and process activities to determine the extent of the compromise and identify any additional malicious activities or lateral movement attempts.
+- Remove any unauthorized or suspicious binaries and scripts from the container to prevent further exploitation.
+- Patch and update the container image and underlying host system to address any known vulnerabilities that may have been exploited.
+- Implement stricter access controls and monitoring on container management utilities to ensure they are only accessible by authorized users and processes.
+- Escalate the incident to the security operations team for further investigation and to assess the need for broader security measures across the container environment."""
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+
+[[rule.threat.technique]]
+id = "T1609"
+name = "Container Administration Command"
+reference = "https://attack.mitre.org/techniques/T1609/"
+
+[rule.threat.tactic]
+id = "TA0002"
+name = "Execution"
+reference = "https://attack.mitre.org/tactics/TA0002/"

nldcsc_elastic_rules/rules/linux/execution_cupsd_foomatic_rip_file_creation.toml

@@ -0,0 +1,134 @@
+[metadata]
+creation_date = "2024/09/27"
+integration = ["endpoint", "sentinel_one_cloud_funnel"]
+maturity = "production"
+updated_date = "2025/03/20"
+
+[rule]
+author = ["Elastic"]
+description = """
+This detection rule addresses multiple vulnerabilities in the CUPS printing system, including CVE-2024-47176,
+CVE-2024-47076, CVE-2024-47175, and CVE-2024-47177. Specifically, this rule detects suspicious file creation events
+executed by child processes of foomatic-rip. These flaws impact components like cups-browsed, libcupsfilters, libppd,
+and foomatic-rip, allowing remote unauthenticated attackers to manipulate IPP URLs or inject malicious data through
+crafted UDP packets or network spoofing. This can result in arbitrary command execution when a print job is initiated.
+"""
+from = "now-9m"
+index = ["logs-endpoint.events.file*", "logs-endpoint.events.process*", "logs-sentinel_one_cloud_funnel.*"]
+language = "eql"
+license = "Elastic License v2"
+name = "File Creation by Cups or Foomatic-rip Child"
+note = """## Triage and analysis
+
+### Investigating File Creation by Cups or Foomatic-rip Child
+
+This rule identifies potential exploitation attempts of several vulnerabilities in the CUPS printing system (CVE-2024-47176, CVE-2024-47076, CVE-2024-47175, CVE-2024-47177). These vulnerabilities allow attackers to send crafted IPP requests or manipulate UDP packets to execute arbitrary commands or modify printer configurations. Attackers can exploit these flaws to inject malicious data, leading to Remote Code Execution (RCE) on affected systems.
+
+#### Possible Investigation Steps
+
+- Investigate the incoming IPP requests or UDP packets targeting port 631.
+- Examine the printer configurations on the system to determine if any unauthorized printers or URLs have been added.
+- Investigate the process tree to check if any unexpected processes were triggered as a result of IPP activity. Review the executable files for legitimacy.
+- Check for additional alerts related to the compromised system or user within the last 48 hours.
+- Investigate network traffic logs for suspicious outbound connections to unrecognized domains or IP addresses.
+- Check if any of the contacted domains or addresses are newly registered or have a suspicious reputation.
+- Retrieve any scripts or executables dropped by the attack for further analysis in a private sandbox environment:
+- Analyze potential malicious activity, including:
+  - Attempts to communicate with external servers.
+  - File access or creation of unauthorized executables.
+  - Cron jobs, services, or other persistence mechanisms.
+
+### Related Rules
+- Cupsd or Foomatic-rip Shell Execution - 476267ff-e44f-476e-99c1-04c78cb3769d
+- Printer User (lp) Shell Execution - f86cd31c-5c7e-4481-99d7-6875a3e31309
+- Network Connection by Cups or Foomatic-rip Child - e80ee207-9505-49ab-8ca8-bc57d80e2cab
+- Suspicious Execution from Foomatic-rip or Cupsd Parent - 986361cd-3dac-47fe-afa1-5c5dd89f2fb4
+
+### False Positive Analysis
+
+- This activity is rarely legitimate. However, verify the context to rule out non-malicious printer configuration changes or legitimate IPP requests.
+
+### Response and Remediation
+
+- Initiate the incident response process based on the triage outcome.
+- Isolate the compromised host to prevent further exploitation.
+- If the investigation confirms malicious activity, search the environment for additional compromised hosts.
+- Implement network segmentation or restrictions to contain the attack.
+- Stop suspicious processes or services tied to CUPS exploitation.
+- Block identified Indicators of Compromise (IoCs), including IP addresses, domains, or hashes of involved files.
+- Review compromised systems for backdoors, such as reverse shells or persistence mechanisms like cron jobs.
+- Investigate potential credential exposure on compromised systems and reset passwords for any affected accounts.
+- Restore the original printer configurations or uninstall unauthorized printer entries.
+- Perform a thorough antimalware scan to identify any lingering threats or artifacts from the attack.
+- Investigate how the attacker gained initial access and address any weaknesses to prevent future exploitation.
+- Use insights from the incident to improve detection and response times in future incidents (MTTD and MTTR).
+"""
+references = [
+    "https://www.elastic.co/security-labs/cups-overflow",
+    "https://www.evilsocket.net/2024/09/26/Attacking-UNIX-systems-via-CUPS-Part-I/",
+    "https://gist.github.com/stong/c8847ef27910ae344a7b5408d9840ee1",
+    "https://github.com/RickdeJager/cupshax/blob/main/cupshax.py",
+]
+risk_score = 73
+rule_id = "b9b14be7-b7f4-4367-9934-81f07d2f63c4"
+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",
+    "Use Case: Vulnerability",
+    "Tactic: Execution",
+    "Data Source: Elastic Defend",
+    "Data Source: SentinelOne",
+    "Resources: Investigation Guide",
+]
+type = "eql"
+
+query = '''
+sequence by host.id with maxspan=10s
+  [process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "start") and
+   process.parent.name == "foomatic-rip" and
+   process.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish")] by process.entity_id
+  [file where host.os.type == "linux" and event.type != "deletion" and
+   not (process.name == "gs" and file.path like "/tmp/gs_*")] by process.parent.entity_id
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1203"
+name = "Exploitation for Client Execution"
+reference = "https://attack.mitre.org/techniques/T1203/"
+
+
+[rule.threat.tactic]
+id = "TA0002"
+name = "Execution"
+reference = "https://attack.mitre.org/tactics/TA0002/"
+

nldcsc_elastic_rules/rules/linux/execution_cupsd_foomatic_rip_lp_user_execution.toml

@@ -0,0 +1,138 @@
+[metadata]
+creation_date = "2024/09/27"
+integration = ["endpoint", "crowdstrike"]
+maturity = "production"
+updated_date = "2025/10/17"
+
+[rule]
+author = ["Elastic"]
+description = """
+This detection rule addresses multiple vulnerabilities in the CUPS printing system, including CVE-2024-47176,
+CVE-2024-47076, CVE-2024-47175, and CVE-2024-47177. Specifically, this rule detects shell executions from the foomatic-rip
+parent process through the default printer user (lp). These flaws impact components like cups-browsed, libcupsfilters,
+libppd, and foomatic-rip, allowing remote unauthenticated attackers to manipulate IPP URLs or inject malicious data
+through crafted UDP packets or network spoofing. This can result in arbitrary command execution when a print job is
+initiated.
+"""
+from = "now-9m"
+index = ["endgame-*", "logs-endpoint.events.process*", "logs-crowdstrike.fdr*"]
+language = "eql"
+license = "Elastic License v2"
+name = "Printer User (lp) Shell Execution"
+note = """## Triage and analysis
+
+### Investigating Printer User (lp) Shell Execution
+
+This rule identifies potential exploitation attempts of several vulnerabilities in the CUPS printing system (CVE-2024-47176, CVE-2024-47076, CVE-2024-47175, CVE-2024-47177). These vulnerabilities allow attackers to send crafted IPP requests or manipulate UDP packets to execute arbitrary commands or modify printer configurations. Attackers can exploit these flaws to inject malicious data, leading to Remote Code Execution (RCE) on affected systems.
+
+#### Possible Investigation Steps
+
+- Investigate the incoming IPP requests or UDP packets targeting port 631.
+- Examine the printer configurations on the system to determine if any unauthorized printers or URLs have been added.
+- Investigate the process tree to check if any unexpected processes were triggered as a result of IPP activity. Review the executable files for legitimacy.
+- Check for additional alerts related to the compromised system or user within the last 48 hours.
+- Investigate network traffic logs for suspicious outbound connections to unrecognized domains or IP addresses.
+- Check if any of the contacted domains or addresses are newly registered or have a suspicious reputation.
+- Retrieve any scripts or executables dropped by the attack for further analysis in a private sandbox environment:
+- Analyze potential malicious activity, including:
+  - Attempts to communicate with external servers.
+  - File access or creation of unauthorized executables.
+  - Cron jobs, services, or other persistence mechanisms.
+
+### Related Rules
+- Cupsd or Foomatic-rip Shell Execution - 476267ff-e44f-476e-99c1-04c78cb3769d
+- Network Connection by Cups or Foomatic-rip Child - e80ee207-9505-49ab-8ca8-bc57d80e2cab
+- File Creation by Cups or Foomatic-rip Child - b9b14be7-b7f4-4367-9934-81f07d2f63c4
+- Suspicious Execution from Foomatic-rip or Cupsd Parent - 986361cd-3dac-47fe-afa1-5c5dd89f2fb4
+
+### False Positive Analysis
+
+- This activity is rarely legitimate. However, verify the context to rule out non-malicious printer configuration changes or legitimate IPP requests.
+
+### Response and Remediation
+
+- Initiate the incident response process based on the triage outcome.
+- Isolate the compromised host to prevent further exploitation.
+- If the investigation confirms malicious activity, search the environment for additional compromised hosts.
+- Implement network segmentation or restrictions to contain the attack.
+- Stop suspicious processes or services tied to CUPS exploitation.
+- Block identified Indicators of Compromise (IoCs), including IP addresses, domains, or hashes of involved files.
+- Review compromised systems for backdoors, such as reverse shells or persistence mechanisms like cron jobs.
+- Investigate potential credential exposure on compromised systems and reset passwords for any affected accounts.
+- Restore the original printer configurations or uninstall unauthorized printer entries.
+- Perform a thorough antimalware scan to identify any lingering threats or artifacts from the attack.
+- Investigate how the attacker gained initial access and address any weaknesses to prevent future exploitation.
+- Use insights from the incident to improve detection and response times in future incidents (MTTD and MTTR).
+"""
+references = [
+    "https://www.elastic.co/security-labs/cups-overflow",
+    "https://www.evilsocket.net/2024/09/26/Attacking-UNIX-systems-via-CUPS-Part-I/",
+    "https://gist.github.com/stong/c8847ef27910ae344a7b5408d9840ee1",
+    "https://github.com/RickdeJager/cupshax/blob/main/cupshax.py",
+]
+risk_score = 73
+rule_id = "f86cd31c-5c7e-4481-99d7-6875a3e31309"
+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",
+  "Use Case: Vulnerability",
+  "Tactic: Execution",
+  "Data Source: Elastic Defend",
+  "Data Source: Elastic Endgame",
+  "Resources: Investigation Guide",
+  "Data Source: Crowdstrike",
+]
+timestamp_override = "event.ingested"
+type = "eql"
+query = '''
+process where host.os.type == "linux" and event.type == "start" and
+  event.action in ("exec", "exec_event", "ProcessRollup2") and user.name == "lp" and
+  process.parent.name in ("cupsd", "foomatic-rip", "bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and
+  process.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and not (
+    process.command_line like (
+      "*/tmp/foomatic-*", "*-sDEVICE=ps2write*", "*printf*", "/bin/sh -e -c cat", "/bin/bash -c cat",
+      "/bin/bash -e -c cat"
+    ) or
+    process.args like "gs*"
+  )
+'''
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+
+[[rule.threat.technique]]
+id = "T1203"
+name = "Exploitation for Client Execution"
+reference = "https://attack.mitre.org/techniques/T1203/"
+
+[rule.threat.tactic]
+id = "TA0002"
+name = "Execution"
+reference = "https://attack.mitre.org/tactics/TA0002/"