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

nldcsc_elastic_rules/rules/linux/execution_cupsd_foomatic_rip_shell_execution.toml

@@ -0,0 +1,145 @@
+[metadata]
+creation_date = "2024/09/27"
+integration = ["endpoint", "crowdstrike", "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 shell executions from the
+foomatic-rip parent process. 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-crowdstrike.fdr*",
+    "logs-endpoint.events.process*",
+    "logs-sentinel_one_cloud_funnel.*",
+]
+language = "eql"
+license = "Elastic License v2"
+name = "Cupsd or Foomatic-rip Shell Execution"
+note = """## Triage and analysis
+
+### Investigating Cupsd or Foomatic-rip 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
+- Printer User (lp) Shell Execution - f86cd31c-5c7e-4481-99d7-6875a3e31309
+- 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 = "476267ff-e44f-476e-99c1-04c78cb3769d"
+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: Crowdstrike",
+    "Data Source: SentinelOne",
+    "Data Source: Elastic Endgame",
+    "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") and process.parent.name == "foomatic-rip" 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/"
+

nldcsc_elastic_rules/rules/linux/execution_cupsd_foomatic_rip_suspicious_child_execution.toml

@@ -0,0 +1,161 @@
+[metadata]
+creation_date = "2024/09/27"
+integration = ["endpoint", "crowdstrike", "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 process command lines
+executed by child processes of foomatic-rip and cupsd. 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-crowdstrike.fdr*",
+    "logs-endpoint.events.process*",
+    "logs-sentinel_one_cloud_funnel.*",
+]
+language = "eql"
+license = "Elastic License v2"
+name = "Suspicious Execution from Foomatic-rip or Cupsd Parent"
+note = """## Triage and analysis
+
+### Investigating Suspicious Execution from Foomatic-rip or Cupsd Parent
+
+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
+- File Creation by Cups or Foomatic-rip Child - b9b14be7-b7f4-4367-9934-81f07d2f63c4
+
+### 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 = "986361cd-3dac-47fe-afa1-5c5dd89f2fb4"
+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: Crowdstrike",
+    "Data Source: SentinelOne",
+    "Data Source: Elastic Endgame",
+    "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") and
+process.parent.name in ("foomatic-rip", "cupsd") and process.command_line like (
+  // persistence
+  "*cron*", "*/etc/rc.local*", "*/dev/tcp/*", "*/etc/init.d*", "*/etc/update-motd.d*", "*/etc/sudoers*",
+  "*/etc/profile*", "*autostart*", "*/etc/ssh*", "*/home/*/.ssh/*", "*/root/.ssh*", "*~/.ssh/*", "*udev*",
+  "*/etc/shadow*", "*/etc/passwd*",
+
+  // Downloads
+  "*curl*", "*wget*",
+
+  // encoding and decoding
+  "*base64 *", "*base32 *", "*xxd *", "*openssl*",
+
+  // reverse connections
+  "*GS_ARGS=*", "*/dev/tcp*", "*/dev/udp/*", "*import*pty*spawn*", "*import*subprocess*call*", "*TCPSocket.new*",
+  "*TCPSocket.open*", "*io.popen*", "*os.execute*", "*fsockopen*", "*disown*", "*nohup*",
+
+  // SO loads
+  "*openssl*-engine*.so*", "*cdll.LoadLibrary*.so*", "*ruby*-e**Fiddle.dlopen*.so*", "*Fiddle.dlopen*.so*",
+  "*cdll.LoadLibrary*.so*",
+
+  // misc. suspicious command lines
+   "*/etc/ld.so*", "*/dev/shm/*", "*/var/tmp*", "*echo*", "*>>*", "*|*"
+) and not 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/"
+

nldcsc_elastic_rules/rules/linux/execution_curl_cve_2023_38545_heap_overflow.toml

@@ -0,0 +1,135 @@
+[metadata]
+creation_date = "2023/10/11"
+integration = ["endpoint"]
+maturity = "production"
+updated_date = "2025/02/04"
+
+[rule]
+author = ["Elastic"]
+description = """
+Detects potential exploitation of curl CVE-2023-38545 by monitoring for vulnerable command line arguments in conjunction
+with an unusual command line length. A flaw in curl version <= 8.3 makes curl vulnerable to a heap based buffer overflow
+during the SOCKS5 proxy handshake. Upgrade to curl version >= 8.4 to patch this vulnerability. This exploit can be
+executed with and without the use of environment variables. For increased visibility, enable the collection of
+http_proxy, HTTPS_PROXY and ALL_PROXY environment variables based on the instructions provided in the setup guide of
+this rule.
+"""
+from = "now-9m"
+index = ["logs-endpoint.events.process*"]
+language = "eql"
+license = "Elastic License v2"
+name = "Potential curl CVE-2023-38545 Exploitation"
+references = [
+    "https://curl.se/docs/CVE-2023-38545.html",
+    "https://daniel.haxx.se/blog/2023/10/11/curl-8-4-0/",
+    "https://twitter.com/_JohnHammond/status/1711986412554531015",
+]
+risk_score = 47
+rule_id = "f41296b4-9975-44d6-9486-514c6f635b2d"
+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).
+
+Elastic Defend integration does not collect environment variable logging by default.
+In order to capture this behavior, this rule requires a specific configuration option set within the advanced settings of the Elastic Defend integration.
+ #### To set up environment variable capture for an Elastic Agent policy:
+- Go to “Security → Manage → Policies”.
+- Select an “Elastic Agent policy”.
+- Click “Show advanced settings”.
+- Scroll down or search for “linux.advanced.capture_env_vars”.
+- Enter the names of environment variables you want to capture, separated by commas.
+- For this rule the linux.advanced.capture_env_vars variable should be set to "http_proxy,HTTPS_PROXY,ALL_PROXY".
+- Click “Save”.
+After saving the integration change, the Elastic Agents running this policy will be updated and the rule will function properly.
+For more information on capturing environment variables refer to the [helper guide](https://www.elastic.co/guide/en/security/current/environment-variable-capture.html).
+"""
+severity = "medium"
+tags = [
+    "Domain: Endpoint",
+    "OS: Linux",
+    "Use Case: Threat Detection",
+    "Use Case: Vulnerability",
+    "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.name == "curl"
+and (
+  process.args like ("--socks5-hostname", "--proxy", "--preproxy", "socks5*") or
+  process.env_vars like ("http_proxy=socks5h://*", "HTTPS_PROXY=socks5h://*", "ALL_PROXY=socks5h://*")
+) and length(process.command_line) > 255 and not (
+  process.parent.name in ("cf-agent", "agent-run", "agent-check", "rudder", "agent-inventory", "cf-execd") or
+  process.args like "/opt/rudder/*" or
+  process.parent.executable like ("/vz/root/*", "/var/rudder/*")
+)
+'''
+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 curl CVE-2023-38545 Exploitation
+
+Curl is a command-line tool used for transferring data with URLs, often employed in scripts and automation. A vulnerability in versions up to 8.3 allows a buffer overflow during SOCKS5 proxy handshakes, potentially leading to arbitrary code execution. Adversaries might exploit this by crafting specific command lines or environment variables. The detection rule identifies suspicious curl usage patterns, such as unusual command lengths and specific proxy settings, to flag potential exploitation attempts.
+
+### Possible investigation steps
+
+- Review the process command line arguments and environment variables to confirm the presence of SOCKS5 proxy settings, such as "--socks5-hostname", "--proxy", "--preproxy", or environment variables like "http_proxy=socks5h://*", "HTTPS_PROXY=socks5h://*", and "ALL_PROXY=socks5h://*".
+- Check the length of the command line to ensure it exceeds 255 characters, as this is a key indicator of potential exploitation attempts.
+- Investigate the parent process of the curl execution to determine if it is one of the known benign processes like "cf-agent", "agent-run", "agent-check", "rudder", "agent-inventory", or "cf-execd", or if it originates from directories like "/opt/rudder/*", "/vz/root/*", or "/var/rudder/*".
+- Examine the network activity associated with the curl process to identify any unusual or unauthorized data transfers, especially those involving SOCKS5 proxies.
+- Cross-reference the alert with other security logs and alerts to identify any correlated suspicious activities or patterns that might indicate a broader attack campaign.
+
+### False positive analysis
+
+- Legitimate administrative tools like cf-agent, agent-run, and rudder may trigger the rule due to their use of curl with SOCKS5 proxies. To mitigate this, add these tools to the exception list in the rule configuration.
+- Automated scripts running in environments like /opt/rudder or /var/rudder might be flagged. Exclude these paths from the rule to prevent false positives.
+- Processes executed within virtualized environments, such as those under /vz/root, can be mistakenly identified. Consider excluding these directories if they are known to host benign activities.
+- Regularly review and update the list of known safe parent processes and directories to ensure that legitimate operations are not disrupted by the detection rule.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further exploitation or lateral movement by the adversary.
+- Terminate any suspicious curl processes identified by the detection rule to halt potential exploitation activities.
+- Upgrade curl to version 8.4 or later on all affected systems to patch the vulnerability and prevent future exploitation attempts.
+- Review and reset any potentially compromised environment variables, such as http_proxy, HTTPS_PROXY, and ALL_PROXY, to ensure they are not being used maliciously.
+- Conduct a thorough investigation of the affected system for signs of further compromise, such as unauthorized access or changes to critical files, and take appropriate remediation actions.
+- Notify the security team and relevant stakeholders about the incident for awareness and further analysis, ensuring that any findings are documented for future reference.
+- Enhance monitoring and logging for curl usage and SOCKS5 proxy connections to improve detection capabilities for similar threats in the future."""
+
+[[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_egress_connection_from_entrypoint_in_container.toml

@@ -0,0 +1,112 @@
+[metadata]
+creation_date = "2024/07/10"
+integration = ["endpoint"]
+maturity = "production"
+updated_date = "2025/02/04"
+
+[rule]
+author = ["Elastic"]
+description = """
+This rule identifies a sequence of events where a process named `entrypoint.sh` is started in a container, followed by a
+network connection attempt. This sequence indicates a potential egress connection from an entrypoint in a container. An
+entrypoint is a command or script specified in the Dockerfile and executed when the container starts. Attackers can use
+this technique to establish a foothold in the environment, escape from a container to the host, or establish persistence.
+"""
+from = "now-9m"
+index = ["logs-endpoint.events.network*", "logs-endpoint.events.process*"]
+language = "eql"
+license = "Elastic License v2"
+name = "Egress Connection from Entrypoint in Container"
+risk_score = 47
+rule_id = "c75d0c86-38d6-4821-98a1-465cff8ff4c8"
+severity = "medium"
+tags = [
+    "Domain: Endpoint",
+    "Domain: Container",
+    "OS: Linux",
+    "Use Case: Threat Detection",
+    "Tactic: Execution",
+    "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "eql"
+query = '''
+sequence by host.id with maxspan=3s
+  [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and
+   process.entry_leader.entry_meta.type == "container" and process.name == "entrypoint.sh"] by process.entity_id
+  [network where event.type == "start" and event.action == "connection_attempted" and not (
+     destination.ip == null or destination.ip == "0.0.0.0" or cidrmatch(
+       destination.ip, "10.0.0.0/8", "127.0.0.0/8", "169.254.0.0/16", "172.16.0.0/12", "192.0.0.0/24", "192.0.0.0/29",
+       "192.0.0.8/32", "192.0.0.9/32", "192.0.0.10/32", "192.0.0.170/32", "192.0.0.171/32", "192.0.2.0/24",
+       "192.31.196.0/24", "192.52.193.0/24", "192.168.0.0/16", "192.88.99.0/24", "224.0.0.0/4", "100.64.0.0/10",
+       "192.175.48.0/24","198.18.0.0/15", "198.51.100.0/24", "203.0.113.0/24", "240.0.0.0/4", "::1", "FE80::/10",
+       "FF00::/8", "172.31.0.0/16"
+       )
+    )] by process.parent.entity_id
+'''
+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 Egress Connection from Entrypoint in Container
+
+Containers, often used for deploying applications, start with an entrypoint script that initializes the environment. Adversaries may exploit this by embedding malicious commands to initiate unauthorized network connections, potentially breaching security boundaries. The detection rule monitors for processes named `entrypoint.sh` followed by suspicious network activity, flagging attempts to connect to external IPs, thus identifying potential threats.
+
+### Possible investigation steps
+
+- Review the process details for the `entrypoint.sh` script execution, focusing on the `process.entity_id` and `host.id` to understand the context of the container where the script was executed.
+- Examine the network connection attempt details, particularly the `destination.ip`, to determine if the IP address is known to be malicious or associated with suspicious activity.
+- Check the container's Dockerfile or image configuration to verify if the `entrypoint.sh` script is expected and whether it contains any unauthorized modifications or additions.
+- Investigate the parent process of the network connection attempt using `process.parent.entity_id` to identify if there are any other suspicious processes or activities linked to the same parent.
+- Correlate the event with other logs or alerts from the same `host.id` to identify any additional indicators of compromise or related suspicious activities within the same timeframe.
+
+### False positive analysis
+
+- Legitimate application updates or installations may trigger the rule if they involve network connections from the entrypoint script. To handle this, identify and whitelist specific applications or update processes that are known to perform such actions.
+- Automated configuration management tools might execute scripts that initiate network connections as part of their normal operations. Exclude these tools by specifying their process names or parent entity IDs in the rule exceptions.
+- Containers designed to perform network diagnostics or monitoring could naturally attempt connections to external IPs. Review and exclude these containers by their image names or specific entrypoint scripts.
+- Development or testing environments often run scripts that connect to external services for integration testing. Consider excluding these environments by tagging them appropriately and adjusting the rule to ignore these tags.
+- Scheduled maintenance scripts that run periodically and require network access might be flagged. Document these scripts and create exceptions based on their execution schedule or specific network destinations.
+
+### Response and remediation
+
+- Immediately isolate the affected container to prevent further unauthorized network connections. This can be done by stopping the container or disconnecting it from the network.
+- Conduct a thorough review of the `entrypoint.sh` script within the container to identify and remove any malicious commands or scripts that may have been injected.
+- Analyze the network traffic logs to identify any external IP addresses that the container attempted to connect to. Block these IPs at the firewall level to prevent future connections.
+- Check for any signs of lateral movement or attempts to escape the container to the host system. If detected, escalate to the security team for a comprehensive investigation.
+- Restore the container from a known good backup if available, ensuring that the restored version is free from any malicious modifications.
+- Implement additional monitoring on the affected host and container environment to detect any similar suspicious activities in the future.
+- Report the incident to the appropriate internal security team or incident response team for further analysis and to update threat intelligence databases."""
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+
+[[rule.threat.technique]]
+id = "T1059"
+name = "Command and Scripting Interpreter"
+reference = "https://attack.mitre.org/techniques/T1059/"
+
+[[rule.threat.technique.subtechnique]]
+id = "T1059.004"
+name = "Unix Shell"
+reference = "https://attack.mitre.org/techniques/T1059/004/"
+
+[rule.threat.tactic]
+id = "TA0002"
+name = "Execution"
+reference = "https://attack.mitre.org/tactics/TA0002/"
+
+[[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/"