diff --git a/rules/linux/execution_abnormal_process_id_file_created.toml b/rules/linux/execution_abnormal_process_id_file_created.toml index 8a26cef9bb0..6310d47ea9b 100644 --- a/rules/linux/execution_abnormal_process_id_file_created.toml +++ b/rules/linux/execution_abnormal_process_id_file_created.toml @@ -2,7 +2,7 @@ creation_date = "2022/05/11" integration = ["endpoint"] maturity = "production" -updated_date = "2025/01/24" +updated_date = "2025/12/18" [rule] author = ["Elastic"] @@ -128,7 +128,9 @@ file.extension:(pid or lock or reboot) and file.path:(/var/run/* or /run/*) and 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 + veeamtransport or bash or dash or sh or touch or podman or chrome_crashpad_handler or snmpd or automount or + chrome or yumBackend.py or rhsmcertd-worker or snapd or cp or dotnet or leapp or haproxy or multipathd or + falcond or python* or atopacctd or postmaster or httpd or pulseaudio or iptables or atd or package-cleanup or local ) 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 @@ -153,8 +155,8 @@ reference = "https://attack.mitre.org/tactics/TA0002/" [rule.new_terms] field = "new_terms_fields" -value = ["process.executable", "file.name"] +value = ["process.name", "file.name"] [[rule.new_terms.history_window_start]] field = "history_window_start" -value = "now-14d" +value = "now-5d" diff --git a/rules/linux/execution_container_management_binary_launched_inside_container.toml b/rules/linux/execution_container_management_binary_launched_inside_container.toml index aa680fc485f..f32d2b56652 100644 --- a/rules/linux/execution_container_management_binary_launched_inside_container.toml +++ b/rules/linux/execution_container_management_binary_launched_inside_container.toml @@ -2,7 +2,7 @@ creation_date = "2025/03/12" integration = ["endpoint"] maturity = "production" -updated_date = "2025/06/17" +updated_date = "2025/12/18" [rule] author = ["Elastic"] @@ -24,6 +24,41 @@ index = ["logs-endpoint.events.process*"] language = "eql" license = "Elastic License v2" name = "Container Management Utility Run Inside A Container" +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.""" + risk_score = 21 rule_id = "4b74d3b0-416e-4099-b432-677e1cd098cc" setup = """## Setup @@ -66,43 +101,14 @@ 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") +process.name in ("dockerd", "kubelet", "kube-proxy", "kubectl", "containerd", "systemd", "crictl") and +not ( + process.parent.executable in ("/sbin/init", "/usr/bin/dockerd", "/usr/bin/runc", "/usr/bin/containerd-shim-runc-v2") or + process.working_directory == "/aws" or + process.parent.command_line == "runc init" or + (process.parent.name == "busybox" and process.name == "kubectl") +) ''' -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" diff --git a/rules/linux/execution_cupsd_foomatic_rip_file_creation.toml b/rules/linux/execution_cupsd_foomatic_rip_file_creation.toml index 9378a392cbb..ecf13768813 100644 --- a/rules/linux/execution_cupsd_foomatic_rip_file_creation.toml +++ b/rules/linux/execution_cupsd_foomatic_rip_file_creation.toml @@ -2,7 +2,7 @@ creation_date = "2024/09/27" integration = ["endpoint", "sentinel_one_cloud_funnel"] maturity = "production" -updated_date = "2025/03/20" +updated_date = "2025/12/18" [rule] author = ["Elastic"] @@ -69,7 +69,7 @@ references = [ "https://gist.github.com/stong/c8847ef27910ae344a7b5408d9840ee1", "https://github.com/RickdeJager/cupshax/blob/main/cupshax.py", ] -risk_score = 73 +risk_score = 47 rule_id = "b9b14be7-b7f4-4367-9934-81f07d2f63c4" setup = """## Setup @@ -96,7 +96,7 @@ For more details on Elastic Agent configuration settings, refer to the [helper g - 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" +severity = "medium" tags = [ "Domain: Endpoint", "OS: Linux", @@ -108,27 +108,27 @@ tags = [ "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 + not ( + (process.name == "gs" and file.path like ("/tmp/gs_*", "/var/spool/cups/tmp/gs_*")) or + (process.name == "pdftops" and file.path like "/tmp/0*") + )] 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/" - diff --git a/rules/linux/execution_cupsd_foomatic_rip_lp_user_execution.toml b/rules/linux/execution_cupsd_foomatic_rip_lp_user_execution.toml index be8c06d5c71..e3029462837 100644 --- a/rules/linux/execution_cupsd_foomatic_rip_lp_user_execution.toml +++ b/rules/linux/execution_cupsd_foomatic_rip_lp_user_execution.toml @@ -1,8 +1,8 @@ [metadata] creation_date = "2024/09/27" -integration = ["endpoint", "crowdstrike"] +integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"] maturity = "production" -updated_date = "2025/10/17" +updated_date = "2025/12/18" [rule] author = ["Elastic"] @@ -15,7 +15,12 @@ through crafted UDP packets or network spoofing. This can result in arbitrary co initiated. """ from = "now-9m" -index = ["endgame-*", "logs-endpoint.events.process*", "logs-crowdstrike.fdr*"] +index = [ + "endgame-*", + "logs-crowdstrike.fdr*", + "logs-endpoint.events.process*", + "logs-sentinel_one_cloud_funnel.*", +] language = "eql" license = "Elastic License v2" name = "Printer User (lp) Shell Execution" @@ -104,23 +109,25 @@ tags = [ "Use Case: Threat Detection", "Use Case: Vulnerability", "Tactic: Execution", + "Data Source: Crowdstrike", "Data Source: Elastic Defend", "Data Source: Elastic Endgame", + "Data Source: SentinelOne", "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 + event.action in ("exec", "exec_event", "ProcessRollup2", "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*" + process.args like ("gs*", "/usr/bin/lsb_release", "/usr/lib/cups/filter/gstopdf") ) ''' diff --git a/rules/linux/execution_curl_cve_2023_38545_heap_overflow.toml b/rules/linux/execution_curl_cve_2023_38545_heap_overflow.toml index 086dcc36c06..2539459c103 100644 --- a/rules/linux/execution_curl_cve_2023_38545_heap_overflow.toml +++ b/rules/linux/execution_curl_cve_2023_38545_heap_overflow.toml @@ -2,7 +2,7 @@ creation_date = "2023/10/11" integration = ["endpoint"] maturity = "production" -updated_date = "2025/02/04" +updated_date = "2025/12/18" [rule] author = ["Elastic"] @@ -18,7 +18,40 @@ from = "now-9m" index = ["logs-endpoint.events.process*"] language = "eql" license = "Elastic License v2" -name = "Potential curl CVE-2023-38545 Exploitation" +name = "Deprecated - Potential curl CVE-2023-38545 Exploitation" +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 Deprecated - 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.""" references = [ "https://curl.se/docs/CVE-2023-38545.html", "https://daniel.haxx.se/blog/2023/10/11/curl-8-4-0/", @@ -87,39 +120,6 @@ and ( 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" diff --git a/rules/linux/execution_egress_connection_from_entrypoint_in_container.toml b/rules/linux/execution_egress_connection_from_entrypoint_in_container.toml index 1e15219c594..4f987d0a01c 100644 --- a/rules/linux/execution_egress_connection_from_entrypoint_in_container.toml +++ b/rules/linux/execution_egress_connection_from_entrypoint_in_container.toml @@ -2,12 +2,12 @@ creation_date = "2024/07/10" integration = ["endpoint"] maturity = "production" -updated_date = "2025/02/04" +updated_date = "2025/12/18" [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 +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. @@ -17,34 +17,6 @@ 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**: @@ -79,6 +51,37 @@ Containers, often used for deploying applications, start with an entrypoint scri - 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.""" +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 process.executable != null 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" + ) or + // Excluding vast majority of noise + (process.name like ("python*", "pip*") and destination.port == 443) + )] by process.parent.entity_id +''' [[rule.threat]] framework = "MITRE ATT&CK" diff --git a/rules/linux/execution_file_execution_followed_by_deletion.toml b/rules/linux/execution_file_execution_followed_by_deletion.toml index 6221e571c8e..d2a3a87c967 100644 --- a/rules/linux/execution_file_execution_followed_by_deletion.toml +++ b/rules/linux/execution_file_execution_followed_by_deletion.toml @@ -2,7 +2,7 @@ creation_date = "2023/08/28" integration = ["endpoint"] maturity = "production" -updated_date = "2025/02/04" +updated_date = "2025/12/18" [rule] author = ["Elastic"] @@ -16,7 +16,42 @@ index = ["logs-endpoint.events.file*", "logs-endpoint.events.process*"] language = "eql" license = "Elastic License v2" name = "File Creation, Execution and Self-Deletion in Suspicious Directory" -risk_score = 47 +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 File Creation, Execution and Self-Deletion in Suspicious Directory + +In Linux environments, temporary directories like `/tmp` and `/var/tmp` are often used for storing transient files. Adversaries exploit these directories to execute malicious payloads and erase traces by creating, running, and deleting files swiftly. The detection rule identifies this pattern by monitoring file creation, execution, and deletion events within these directories, flagging suspicious activities that align with common malware behaviors. + +### Possible investigation steps + +- Review the file creation event details, focusing on the file path and name to determine if it matches known malicious patterns or if it is a legitimate file. +- Examine the process execution event, paying attention to the process name and parent process name to identify if the execution was initiated by a suspicious or unauthorized shell. +- Investigate the user.id and host.id associated with the events to determine if the activity aligns with expected user behavior or if it indicates potential compromise. +- Check for any network activity or connections initiated by the process to identify potential data exfiltration or communication with command and control servers. +- Analyze the deletion event to confirm whether the file was removed by a legitimate process or if it was part of a self-deletion mechanism used by malware. +- Correlate these events with any other alerts or logs from the same host or user to identify patterns or additional indicators of compromise. + +### False positive analysis + +- Development and testing activities in temporary directories can trigger false positives. Exclude specific paths or processes related to known development tools or scripts that frequently create, execute, and delete files in these directories. +- Automated system maintenance scripts may perform similar actions. Identify and whitelist these scripts by their process names or paths to prevent unnecessary alerts. +- Backup or deployment tools like Veeam or Spack may use temporary directories for legitimate operations. Add exceptions for these tools by specifying their executable paths or process names. +- Temporary file operations by legitimate applications such as web servers or database services might be flagged. Monitor and exclude these applications by their known behaviors or specific file paths they use. +- Regular system updates or package installations can involve temporary file handling. Recognize and exclude these activities by identifying the associated package manager processes or update scripts. + +### Response and remediation + +- Isolate the affected host immediately to prevent further spread of the potential malware. Disconnect it from the network to contain the threat. +- Terminate any suspicious processes identified in the alert, especially those executed from temporary directories, to stop any ongoing malicious activity. +- Conduct a thorough examination of the affected directories (/tmp, /var/tmp, etc.) to identify and remove any remaining malicious files or scripts. +- Restore any affected systems from a known good backup to ensure that no remnants of the malware remain. +- Update and patch the affected system to close any vulnerabilities that may have been exploited by the threat actor. +- Enhance monitoring and logging on the affected host and similar systems to detect any recurrence of this behavior, focusing on file creation, execution, and deletion events in temporary directories. +- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems may be compromised.""" +risk_score = 73 rule_id = "09bc6c90-7501-494d-b015-5d988dc3f233" setup = """## Setup @@ -43,7 +78,7 @@ For more details on Elastic Agent configuration settings, refer to the [helper g - 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" +severity = "high" tags = [ "Domain: Endpoint", "OS: Linux", @@ -70,41 +105,6 @@ sequence by host.id, user.id with maxspan=1m "/dev/shm/*", "/run/shm/*", "/tmp/*", "/var/tmp/*", "/run/*", "/var/run/*", "/var/www/*", "/proc/*/fd/*" ) and not process.name in ("rm", "ld", "conftest", "link", "gcc", "getarch", "ld")] by file.name ''' -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 File Creation, Execution and Self-Deletion in Suspicious Directory - -In Linux environments, temporary directories like `/tmp` and `/var/tmp` are often used for storing transient files. Adversaries exploit these directories to execute malicious payloads and erase traces by creating, running, and deleting files swiftly. The detection rule identifies this pattern by monitoring file creation, execution, and deletion events within these directories, flagging suspicious activities that align with common malware behaviors. - -### Possible investigation steps - -- Review the file creation event details, focusing on the file path and name to determine if it matches known malicious patterns or if it is a legitimate file. -- Examine the process execution event, paying attention to the process name and parent process name to identify if the execution was initiated by a suspicious or unauthorized shell. -- Investigate the user.id and host.id associated with the events to determine if the activity aligns with expected user behavior or if it indicates potential compromise. -- Check for any network activity or connections initiated by the process to identify potential data exfiltration or communication with command and control servers. -- Analyze the deletion event to confirm whether the file was removed by a legitimate process or if it was part of a self-deletion mechanism used by malware. -- Correlate these events with any other alerts or logs from the same host or user to identify patterns or additional indicators of compromise. - -### False positive analysis - -- Development and testing activities in temporary directories can trigger false positives. Exclude specific paths or processes related to known development tools or scripts that frequently create, execute, and delete files in these directories. -- Automated system maintenance scripts may perform similar actions. Identify and whitelist these scripts by their process names or paths to prevent unnecessary alerts. -- Backup or deployment tools like Veeam or Spack may use temporary directories for legitimate operations. Add exceptions for these tools by specifying their executable paths or process names. -- Temporary file operations by legitimate applications such as web servers or database services might be flagged. Monitor and exclude these applications by their known behaviors or specific file paths they use. -- Regular system updates or package installations can involve temporary file handling. Recognize and exclude these activities by identifying the associated package manager processes or update scripts. - -### Response and remediation - -- Isolate the affected host immediately to prevent further spread of the potential malware. Disconnect it from the network to contain the threat. -- Terminate any suspicious processes identified in the alert, especially those executed from temporary directories, to stop any ongoing malicious activity. -- Conduct a thorough examination of the affected directories (/tmp, /var/tmp, etc.) to identify and remove any remaining malicious files or scripts. -- Restore any affected systems from a known good backup to ensure that no remnants of the malware remain. -- Update and patch the affected system to close any vulnerabilities that may have been exploited by the threat actor. -- Enhance monitoring and logging on the affected host and similar systems to detect any recurrence of this behavior, focusing on file creation, execution, and deletion events in temporary directories. -- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems may be compromised.""" [[rule.threat]] framework = "MITRE ATT&CK" diff --git a/rules/linux/execution_file_made_executable_via_chmod_inside_container.toml b/rules/linux/execution_file_made_executable_via_chmod_inside_container.toml index 04e8710762d..18431eba5ca 100644 --- a/rules/linux/execution_file_made_executable_via_chmod_inside_container.toml +++ b/rules/linux/execution_file_made_executable_via_chmod_inside_container.toml @@ -2,20 +2,54 @@ creation_date = "2025/03/12" integration = ["endpoint"] maturity = "production" -updated_date = "2025/03/12" +updated_date = "2025/12/18" [rule] author = ["Elastic"] description = """ -This rule detects when chmod or chown are used to add the execute permission to a file inside a container. Modifying file -permissions to make a file executable could indicate malicious activity, as an attacker may attempt to run unauthorized -or malicious code inside the container. +This rule detects when chmod or chown are used to add the execute permission to a file in a world-writeable directory, +and inside of a container. Modifying file permissions to make a file executable could indicate malicious activity, as +an attacker may attempt to run unauthorized or malicious code inside the container. """ from = "now-9m" index = ["logs-endpoint.events.process*"] language = "eql" license = "Elastic License v2" -name = "File Made Executable via Chmod Inside A Container" +name = "Suspicious File Made Executable via Chmod Inside A Container" +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + +### Investigating Suspicious File Made Executable via Chmod Inside A Container + +Containers provide isolated environments for running applications, often on Linux systems. The `chmod` command is used to change file permissions, including making files executable. Adversaries may exploit this by altering permissions to execute unauthorized scripts or binaries, potentially leading to malicious activity. The detection rule identifies such actions by monitoring for `chmod` usage that grants execute permissions, focusing on specific permission patterns, and excluding benign cases. This helps in identifying potential threats where attackers attempt to execute unauthorized code within containers. + +### Possible investigation steps + +- Examine the process arguments to determine the exact permissions that were set and identify the file that was made executable. +- Investigate the origin of the `chmod` command by reviewing the process tree to understand which parent process initiated it and whether it aligns with expected behavior. +- Check the user account or service account that executed the `chmod` command to assess if it has legitimate access and reason to modify file permissions. +- Analyze the file that was made executable to determine its contents and origin, checking for any signs of unauthorized or malicious code. +- Correlate this event with other logs or alerts from the same container to identify any patterns or additional suspicious activities that might indicate a broader attack. + +### False positive analysis + +- Routine maintenance scripts or automated processes may use chmod to set execute permissions on files within containers. To handle these, identify and whitelist specific scripts or processes that are known to be safe and necessary for operations. +- Development environments often involve frequent changes to file permissions as developers test and deploy code. Consider excluding specific container IDs or paths associated with development environments to reduce noise. +- Some container orchestration tools might use chmod as part of their normal operation. Review the processes and arguments associated with these tools and create exceptions for known benign activities. +- System updates or package installations within containers might trigger this rule. Monitor and document regular update schedules and processes, and exclude these from triggering alerts if they are verified as non-threatening. +- If certain users or roles are responsible for legitimate permission changes, consider excluding their activities by user ID or role, ensuring that these exclusions are well-documented and reviewed regularly. + +### Response and remediation + +- Immediately isolate the affected container to prevent further execution of unauthorized code. This can be done by stopping the container or disconnecting it from the network. +- Conduct a thorough review of the container's file system to identify any unauthorized or suspicious files that have been made executable. Remove or quarantine these files as necessary. +- Analyze the container's logs to trace the source of the `chmod` command and determine if there are any other indicators of compromise or related malicious activities. +- If the unauthorized execution is confirmed, assess the potential impact on the host system and other containers. Implement additional security measures, such as enhanced monitoring or network segmentation, to protect other assets. +- Escalate the incident to the security operations team for further investigation and to determine if the threat is part of a larger attack campaign. +- Review and update container security policies to prevent unauthorized permission changes, such as implementing stricter access controls and using security tools that enforce policy compliance. +- Enhance detection capabilities by configuring alerts for similar suspicious activities, ensuring that any future attempts to modify file permissions within containers are promptly identified and addressed.""" risk_score = 21 rule_id = "30d94e59-e5c7-4828-bc4f-f5809ad1ffe1" setup = """## Setup @@ -59,42 +93,9 @@ 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.name in ("chmod", "chown") and -process.args in ("4755", "755", "000", "777", "444", "-x", "+x") +process.args in ("4755", "755", "000", "777", "444", "+x") and +process.args like ("/dev/shm/*", "/tmp/*", "/var/tmp/*", "/run/*", "/var/run/*", "/mnt/*", "/media/*") ''' -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 File Made Executable via Chmod Inside A Container - -Containers provide isolated environments for running applications, often on Linux systems. The `chmod` command is used to change file permissions, including making files executable. Adversaries may exploit this by altering permissions to execute unauthorized scripts or binaries, potentially leading to malicious activity. The detection rule identifies such actions by monitoring for `chmod` usage that grants execute permissions, focusing on specific permission patterns, and excluding benign cases. This helps in identifying potential threats where attackers attempt to execute unauthorized code within containers. - -### Possible investigation steps - -- Examine the process arguments to determine the exact permissions that were set and identify the file that was made executable. -- Investigate the origin of the `chmod` command by reviewing the process tree to understand which parent process initiated it and whether it aligns with expected behavior. -- Check the user account or service account that executed the `chmod` command to assess if it has legitimate access and reason to modify file permissions. -- Analyze the file that was made executable to determine its contents and origin, checking for any signs of unauthorized or malicious code. -- Correlate this event with other logs or alerts from the same container to identify any patterns or additional suspicious activities that might indicate a broader attack. - -### False positive analysis - -- Routine maintenance scripts or automated processes may use chmod to set execute permissions on files within containers. To handle these, identify and whitelist specific scripts or processes that are known to be safe and necessary for operations. -- Development environments often involve frequent changes to file permissions as developers test and deploy code. Consider excluding specific container IDs or paths associated with development environments to reduce noise. -- Some container orchestration tools might use chmod as part of their normal operation. Review the processes and arguments associated with these tools and create exceptions for known benign activities. -- System updates or package installations within containers might trigger this rule. Monitor and document regular update schedules and processes, and exclude these from triggering alerts if they are verified as non-threatening. -- If certain users or roles are responsible for legitimate permission changes, consider excluding their activities by user ID or role, ensuring that these exclusions are well-documented and reviewed regularly. - -### Response and remediation - -- Immediately isolate the affected container to prevent further execution of unauthorized code. This can be done by stopping the container or disconnecting it from the network. -- Conduct a thorough review of the container's file system to identify any unauthorized or suspicious files that have been made executable. Remove or quarantine these files as necessary. -- Analyze the container's logs to trace the source of the `chmod` command and determine if there are any other indicators of compromise or related malicious activities. -- If the unauthorized execution is confirmed, assess the potential impact on the host system and other containers. Implement additional security measures, such as enhanced monitoring or network segmentation, to protect other assets. -- Escalate the incident to the security operations team for further investigation and to determine if the threat is part of a larger attack campaign. -- Review and update container security policies to prevent unauthorized permission changes, such as implementing stricter access controls and using security tools that enforce policy compliance. -- Enhance detection capabilities by configuring alerts for similar suspicious activities, ensuring that any future attempts to modify file permissions within containers are promptly identified and addressed.""" [[rule.threat]] framework = "MITRE ATT&CK" diff --git a/rules/linux/execution_interpreter_tty_upgrade.toml b/rules/linux/execution_interpreter_tty_upgrade.toml index a163537237f..3036568b3da 100644 --- a/rules/linux/execution_interpreter_tty_upgrade.toml +++ b/rules/linux/execution_interpreter_tty_upgrade.toml @@ -2,7 +2,7 @@ creation_date = "2023/09/20" integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"] maturity = "production" -updated_date = "2025/03/20" +updated_date = "2025/12/18" [rule] author = ["Elastic"] @@ -95,33 +95,32 @@ tags = [ ] 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 +event.action in ("exec", "exec_event", "start", "ProcessRollup2") and +( + (process.name == "stty" and process.args == "raw" and process.args == "-echo" and process.args_count >= 3) or ( - (process.name == "stty" and process.args == "raw" and process.args == "-echo" and process.args_count >= 3) or - (process.name == "script" and process.args in ("-qc", "-c") and process.args == "/dev/null" and - process.args_count == 4) + process.name == "script" and process.args in ("-qc", "-c") and process.args == "/dev/null" and process.args_count == 4 ) +) and +not process.parent.command_line like ("linode-longview", "*bootstrap*", "*homebrew*") ''' - [[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/" - diff --git a/rules/linux/execution_kubectl_apply_pod_from_url.toml b/rules/linux/execution_kubectl_apply_pod_from_url.toml index 84929414f82..6befd6eb980 100644 --- a/rules/linux/execution_kubectl_apply_pod_from_url.toml +++ b/rules/linux/execution_kubectl_apply_pod_from_url.toml @@ -1,8 +1,8 @@ [metadata] creation_date = "2025/06/27" -integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"] +integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel", "auditd_manager"] maturity = "production" -updated_date = "2025/07/07" +updated_date = "2025/12/18" [rule] author = ["Elastic"] @@ -13,10 +13,12 @@ pods or modify existing ones, potentially leading to unauthorized access or data """ from = "now-9m" index = [ + "auditbeat-*", "endgame-*", "logs-crowdstrike.fdr*", "logs-endpoint.events.process*", "logs-sentinel_one_cloud_funnel.*", + "logs-auditd_manager.auditd-*", ] language = "eql" license = "Elastic License v2" @@ -90,6 +92,7 @@ tags = [ "OS: Linux", "Use Case: Threat Detection", "Tactic: Execution", + "Data Source: Auditd Manager", "Data Source: Elastic Endgame", "Data Source: Elastic Defend", "Data Source: Crowdstrike", @@ -100,8 +103,10 @@ 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.name == "kubectl" and process.args == "apply" and process.args like "http*" +event.action in ("exec", "exec_event", "start", "ProcessRollup2", "process_started", "executed") and +process.name == "kubectl" and process.args == "apply" and +process.args like ("http://*", "https://*") and +not process.command_line like ("*download.elastic.co*", "*github.com/kubernetes-sigs/*") ''' [[rule.threat]] diff --git a/rules/linux/execution_kubernetes_direct_api_request_via_curl_or_wget.toml b/rules/linux/execution_kubernetes_direct_api_request_via_curl_or_wget.toml index 5e3f95e477d..b0d37287c4f 100644 --- a/rules/linux/execution_kubernetes_direct_api_request_via_curl_or_wget.toml +++ b/rules/linux/execution_kubernetes_direct_api_request_via_curl_or_wget.toml @@ -1,8 +1,8 @@ [metadata] creation_date = "2025/06/23" -integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"] +integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel", "auditd_manager"] maturity = "production" -updated_date = "2025/07/07" +updated_date = "2025/12/18" [rule] author = ["Elastic"] @@ -14,10 +14,12 @@ config maps, and other sensitive data, without using the official Kubernetes cli """ from = "now-9m" index = [ + "auditbeat-*", "endgame-*", "logs-crowdstrike.fdr*", "logs-endpoint.events.process*", "logs-sentinel_one_cloud_funnel.*", + "logs-auditd_manager.auditd-*", ] language = "eql" license = "Elastic License v2" @@ -94,17 +96,18 @@ tags = [ "Use Case: Threat Detection", "Tactic: Execution", "Tactic: Discovery", + "Data Source: Auditd Manager", "Data Source: Elastic Defend", "Data Source: Elastic Endgame", "Data Source: Crowdstrike", "Data Source: SentinelOne", - "Resources: Investigation Guide", + "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", "executed", "process_started") and +event.action in ("exec", "exec_event", "start", "executed", "process_started", "ProcessRollup2") and process.name in ("curl", "wget") and process.args like~ ( "*http*//*/apis/authorization.k8s.io/*", "*http*//*/apis/rbac.authorization.k8s.io/*", diff --git a/rules/linux/execution_nc_listener_via_rlwrap.toml b/rules/linux/execution_nc_listener_via_rlwrap.toml index 821967f8801..7e6e8f09bbf 100644 --- a/rules/linux/execution_nc_listener_via_rlwrap.toml +++ b/rules/linux/execution_nc_listener_via_rlwrap.toml @@ -2,7 +2,7 @@ creation_date = "2023/09/22" integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"] maturity = "production" -updated_date = "2025/03/20" +updated_date = "2025/12/18" [rule] author = ["Elastic"] @@ -62,7 +62,7 @@ Netcat, a versatile networking tool, can establish connections for data transfer - Apply security patches and updates to the affected system to mitigate any exploited vulnerabilities. - Enhance monitoring and logging on the affected host and network to detect similar activities in the future. - Report the incident to the appropriate internal security team or external authorities if required, following organizational protocols.""" -risk_score = 21 +risk_score = 47 rule_id = "0f56369f-eb3d-459c-a00b-87c2bf7bdfc5" setup = """## Setup @@ -90,7 +90,7 @@ For more details on Elastic Agent configuration settings, refer to the [helper g - 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" +severity = "medium" tags = [ "Domain: Endpoint", "OS: Linux", @@ -104,7 +104,6 @@ tags = [ ] 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 @@ -112,22 +111,20 @@ process where host.os.type == "linux" and event.type == "start" and process.args : "*l*" and process.args_count >= 4 ''' - [[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/" - diff --git a/rules/linux/execution_netcon_from_rwx_mem_region_binary.toml b/rules/linux/execution_netcon_from_rwx_mem_region_binary.toml index 39958a99e37..b094488daa9 100644 --- a/rules/linux/execution_netcon_from_rwx_mem_region_binary.toml +++ b/rules/linux/execution_netcon_from_rwx_mem_region_binary.toml @@ -2,7 +2,7 @@ creation_date = "2024/03/13" integration = ["auditd_manager", "endpoint"] maturity = "production" -updated_date = "2025/02/04" +updated_date = "2025/12/18" [rule] author = ["Elastic"] @@ -58,7 +58,7 @@ query = ''' sample by host.id, process.pid, process.name /* auditd.data.a2 == "7" translates to RWX memory region protection (PROT_READ | PROT_WRITE | PROT_EXEC) */ [process where host.os.type == "linux" and auditd.data.syscall == "mprotect" and auditd.data.a2 == "7" and - not process.name == "httpd"] + not process.name in ("httpd", "java", "node", "code", "apache2")] [network where host.os.type == "linux" and event.type == "start" and event.action == "connection_attempted" and not cidrmatch(destination.ip, "127.0.0.0/8", "169.254.0.0/16", "224.0.0.0/4", "::1")] ''' diff --git a/rules/linux/execution_network_event_post_compilation.toml b/rules/linux/execution_network_event_post_compilation.toml index 18f1cdda773..42342789d2f 100644 --- a/rules/linux/execution_network_event_post_compilation.toml +++ b/rules/linux/execution_network_event_post_compilation.toml @@ -2,7 +2,7 @@ creation_date = "2023/08/28" integration = ["endpoint"] maturity = "production" -updated_date = "2025/02/04" +updated_date = "2025/12/18" [rule] author = ["Elastic"] @@ -56,12 +56,21 @@ type = "eql" query = ''' sequence by host.id with maxspan=1m [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and - process.name in ("gcc", "g++", "cc")] by process.args - [file where host.os.type == "linux" and event.action == "creation" and process.name == "ld"] by file.name + process.name like~ ( + "gcc*", "g++*", "c++", "cc", "c99", "c89", "cc1*", "cc1plus*", "clang*", "clang++*", + "musl-gcc", "musl-clang", "*-linux-gnu-gcc*", "*-linux-gnu-g++*", "*-pc-linux-gnu-gcc*", + "tcc", "zig", "ccache", "distcc" + )] by process.args + [file where host.os.type == "linux" and event.action == "creation" and process.name like~ ( + "ld", "ld.*", "lld", "ld.lld", "mold", "collect2", "*-linux-gnu-ld*", "*-pc-linux-gnu-ld*" + )] by file.name [process where host.os.type == "linux" and event.type == "start" and event.action == "exec"] by process.name [network where host.os.type == "linux" and event.action == "connection_attempted" and destination.ip != null and not ( cidrmatch(destination.ip, "127.0.0.0/8", "169.254.0.0/16", "224.0.0.0/4", "::1") or - process.name in ("simpleX", "conftest", "ssh", "python", "ispnull", "pvtui", "npreal2d", "ruby", "source", "ssh") + process.name in ( + "simpleX", "conftest", "ssh", "python", "ispnull", "pvtui", "npreal2d", "ruby", "source", "ssh", "git-remote-http", + "sshd-session", "gendb", "sqlplus" + ) )] by process.name ''' note = """## Triage and analysis diff --git a/rules/linux/execution_perl_tty_shell.toml b/rules/linux/execution_perl_tty_shell.toml index 7c1e4547b4c..fdf0986337e 100644 --- a/rules/linux/execution_perl_tty_shell.toml +++ b/rules/linux/execution_perl_tty_shell.toml @@ -1,8 +1,8 @@ [metadata] creation_date = "2020/04/16" -integration = ["endpoint", "crowdstrike"] +integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_funnel"] maturity = "production" -updated_date = "2025/10/17" +updated_date = "2025/12/19" [rule] author = ["Elastic"] @@ -11,10 +11,51 @@ Identifies when a terminal (tty) is spawned via Perl. Attackers may upgrade a si interactive tty after obtaining initial access to a host. """ from = "now-9m" -index = ["auditbeat-*", "logs-endpoint.events.*", "endgame-*", "logs-crowdstrike.fdr*"] -language = "kuery" +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 = "Interactive Terminal Spawned via Perl" +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 Interactive Terminal Spawned via Perl + +Perl, a versatile scripting language, can execute system commands, making it a target for adversaries seeking to escalate privileges or maintain persistence. Attackers may exploit Perl to spawn interactive terminals, transforming basic shells into robust command interfaces. The detection rule identifies such activity by monitoring process events on Linux systems, specifically when Perl executes shell commands, signaling potential misuse. + +### Possible investigation steps + +- Review the process event logs to confirm the presence of a Perl process with arguments indicating the execution of a shell, such as "exec \\"/bin/sh\\";", "exec \\"/bin/dash\\";", or "exec \\"/bin/bash\\";". +- Identify the user account associated with the Perl process to determine if it aligns with expected activity or if it suggests unauthorized access. +- Examine the parent process of the Perl execution to understand how the Perl script was initiated and assess if it correlates with legitimate user activity or a potential compromise. +- Check for any network connections or data transfers initiated by the Perl process to identify possible exfiltration or communication with external command and control servers. +- Investigate any recent changes to user accounts, permissions, or scheduled tasks that might indicate privilege escalation or persistence mechanisms associated with the Perl activity. +- Correlate the event with other security alerts or logs from the same host to identify patterns or additional indicators of compromise that could suggest a broader attack campaign. + +### False positive analysis + +- System maintenance scripts that use Perl to execute shell commands may trigger this rule. Review and whitelist known maintenance scripts by adding exceptions for specific script paths or process arguments. +- Automated deployment tools that utilize Perl for executing shell commands can cause false positives. Identify these tools and exclude their specific process arguments or execution paths from the detection rule. +- Development environments where Perl is used for testing or debugging purposes might inadvertently spawn interactive terminals. Consider excluding processes initiated by known development user accounts or within specific development directories. +- Backup or monitoring scripts that rely on Perl to perform system checks or data collection could be flagged. Analyze these scripts and create exceptions based on their unique process arguments or execution context. + +### Response and remediation + +- Immediately isolate the affected host from the network to prevent further unauthorized access or lateral movement. +- Terminate any suspicious Perl processes identified by the detection rule to halt any ongoing malicious activity. +- Conduct a thorough review of the affected system's logs and process history to identify any additional indicators of compromise or related malicious activity. +- Reset credentials and review access permissions for any accounts that may have been compromised or used in the attack. +- Restore the affected system from a known good backup to ensure any malicious changes are removed. +- Implement additional monitoring on the affected host and network to detect any further attempts to exploit Perl for spawning interactive terminals. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if broader organizational impacts exist.""" risk_score = 73 rule_id = "05e5a668-7b51-4a67-93ab-e9af405c9ef3" setup = """## Setup @@ -60,64 +101,36 @@ tags = [ "OS: Linux", "Use Case: Threat Detection", "Tactic: Execution", - "Data Source: Elastic Endgame", "Data Source: Elastic Defend", - "Resources: Investigation Guide", + "Data Source: Elastic Endgame", + "Data Source: Auditd Manager", "Data Source: Crowdstrike", + "Data Source: SentinelOne", + "Resources: Investigation Guide", ] timestamp_override = "event.ingested" -type = "query" - +type = "eql" query = ''' -event.category:process and host.os.type:linux and event.type:(start or process_started) and process.name:perl and - process.args:("exec \"/bin/sh\";" or "exec \"/bin/dash\";" or "exec \"/bin/bash\";") +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 == "perl" and process.args == "exec" and +process.args in ( + "\"sh\";", "\"dash\";", "\"bash\";", "\"zsh\";", + "\"/bin/sh\";", "\"/bin/dash\";", "\"/bin/bash\";", "\"/bin/zsh\";", + "\"/usr/bin/sh\";", "\"/usr/bin/dash\";", "\"/usr/bin/bash\";", "\"/usr/bin/zsh\";", + "\"/usr/local/bin/sh\";", "\"/usr/local/bin/dash\";", "\"/usr/local/bin/bash\";", "\"/usr/local/bin/zsh\";" +) ''' -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 Interactive Terminal Spawned via Perl - -Perl, a versatile scripting language, can execute system commands, making it a target for adversaries seeking to escalate privileges or maintain persistence. Attackers may exploit Perl to spawn interactive terminals, transforming basic shells into robust command interfaces. The detection rule identifies such activity by monitoring process events on Linux systems, specifically when Perl executes shell commands, signaling potential misuse. - -### Possible investigation steps - -- Review the process event logs to confirm the presence of a Perl process with arguments indicating the execution of a shell, such as "exec \\"/bin/sh\\";", "exec \\"/bin/dash\\";", or "exec \\"/bin/bash\\";". -- Identify the user account associated with the Perl process to determine if it aligns with expected activity or if it suggests unauthorized access. -- Examine the parent process of the Perl execution to understand how the Perl script was initiated and assess if it correlates with legitimate user activity or a potential compromise. -- Check for any network connections or data transfers initiated by the Perl process to identify possible exfiltration or communication with external command and control servers. -- Investigate any recent changes to user accounts, permissions, or scheduled tasks that might indicate privilege escalation or persistence mechanisms associated with the Perl activity. -- Correlate the event with other security alerts or logs from the same host to identify patterns or additional indicators of compromise that could suggest a broader attack campaign. - -### False positive analysis - -- System maintenance scripts that use Perl to execute shell commands may trigger this rule. Review and whitelist known maintenance scripts by adding exceptions for specific script paths or process arguments. -- Automated deployment tools that utilize Perl for executing shell commands can cause false positives. Identify these tools and exclude their specific process arguments or execution paths from the detection rule. -- Development environments where Perl is used for testing or debugging purposes might inadvertently spawn interactive terminals. Consider excluding processes initiated by known development user accounts or within specific development directories. -- Backup or monitoring scripts that rely on Perl to perform system checks or data collection could be flagged. Analyze these scripts and create exceptions based on their unique process arguments or execution context. - -### Response and remediation - -- Immediately isolate the affected host from the network to prevent further unauthorized access or lateral movement. -- Terminate any suspicious Perl processes identified by the detection rule to halt any ongoing malicious activity. -- Conduct a thorough review of the affected system's logs and process history to identify any additional indicators of compromise or related malicious activity. -- Reset credentials and review access permissions for any accounts that may have been compromised or used in the attack. -- Restore the affected system from a known good backup to ensure any malicious changes are removed. -- Implement additional monitoring on the affected host and network to detect any further attempts to exploit Perl for spawning interactive terminals. -- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if broader organizational impacts exist.""" - [[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.tactic] id = "TA0002" name = "Execution" reference = "https://attack.mitre.org/tactics/TA0002/" - diff --git a/rules/linux/execution_potentially_overly_permissive_container_creation.toml b/rules/linux/execution_potentially_overly_permissive_container_creation.toml index ec83824f0db..69ded33a6ec 100644 --- a/rules/linux/execution_potentially_overly_permissive_container_creation.toml +++ b/rules/linux/execution_potentially_overly_permissive_container_creation.toml @@ -1,61 +1,25 @@ [metadata] creation_date = "2024/07/10" -integration = ["endpoint"] +integration = ["endpoint", "sentinel_one_cloud_funnel"] maturity = "production" -updated_date = "2025/01/15" +updated_date = "2025/12/18" [rule] author = ["Elastic"] description = """ This rule leverages the new_terms rule type to identify the creation of a potentially unsafe docker container from an -unusual parent process. Attackers can use the `--privileged` flag to create containers with escalated privileges, which +unusual parent process. Attackers can use the "--privileged" flag to create containers with escalated privileges, which can lead to trivial privilege escalation, docker escaping and persistence. access. """ from = "now-9m" -index = ["logs-endpoint.events.process*"] +index = [ + "endgame-*", + "logs-endpoint.events.process*", + "logs-sentinel_one_cloud_funnel.*", +] language = "kuery" license = "Elastic License v2" name = "Privileged Docker Container Creation" -risk_score = 21 -rule_id = "a80d96cd-1164-41b3-9852-ef58724be496" -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", - "Domain: Container", - "OS: Linux", - "Use Case: Threat Detection", - "Tactic: Execution", - "Data Source: Elastic Defend", - "Resources: Investigation Guide", -] -timestamp_override = "event.ingested" -type = "new_terms" - -query = ''' -host.os.type:linux and event.category:process and event.type:start and event.action:exec and process.name:docker and -process.args:(run and --privileged) -''' note = """## Triage and analysis > **Disclaimer**: @@ -97,38 +61,80 @@ Docker containers are lightweight, portable units that package applications and - Update and patch the Docker daemon and any related software to the latest versions to mitigate known vulnerabilities that could be exploited. - Enhance monitoring and alerting for privileged container creation by integrating additional security tools or services that provide real-time threat intelligence and anomaly detection.""" - +risk_score = 47 +rule_id = "a80d96cd-1164-41b3-9852-ef58724be496" +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", + "Domain: Container", + "OS: Linux", + "Use Case: Threat Detection", + "Tactic: Execution", + "Data Source: Elastic Defend", + "Data Source: Elastic Endgame", + "Data Source: SentinelOne", + "Resources: Investigation Guide", +] +timestamp_override = "event.ingested" +type = "new_terms" +query = ''' +host.os.type:linux and event.category:process and event.type:start and +event.action:(exec or exec_event or start) and +process.name:docker and process.args:(run and --privileged) +''' [[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.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/" + [[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" @@ -137,8 +143,7 @@ reference = "https://attack.mitre.org/tactics/TA0004/" [rule.new_terms] field = "new_terms_fields" value = ["process.parent.executable"] + [[rule.new_terms.history_window_start]] field = "history_window_start" -value = "now-14d" - - +value = "now-5d" diff --git a/rules/linux/execution_process_backgrounded_by_unusual_parent.toml b/rules/linux/execution_process_backgrounded_by_unusual_parent.toml index f1e7ef3bd9e..b89fc96dc27 100644 --- a/rules/linux/execution_process_backgrounded_by_unusual_parent.toml +++ b/rules/linux/execution_process_backgrounded_by_unusual_parent.toml @@ -2,7 +2,7 @@ creation_date = "2025/01/29" integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"] maturity = "production" -updated_date = "2025/03/20" +updated_date = "2025/12/18" [rule] author = ["Elastic"] @@ -108,35 +108,35 @@ tags = [ ] timestamp_override = "event.ingested" type = "new_terms" - query = ''' event.category:process and host.os.type:linux and event.type:start and event.action:(ProcessRollup2 or exec or exec_event or start) and process.name:(bash or csh or dash or fish or ksh or sh or tcsh or zsh) and -process.args:(-c and *&) +process.args:(-c and *&) and +not process.parent.name:(sshd or make or su or ds_agent or fortitraylauncher or zeek or asterisk or vncserver or cron or crond) ''' - [[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.tactic] id = "TA0002" name = "Execution" reference = "https://attack.mitre.org/tactics/TA0002/" + [[rule.threat]] framework = "MITRE ATT&CK" + [[rule.threat.technique]] id = "T1564" name = "Hide Artifacts" reference = "https://attack.mitre.org/techniques/T1564/" - [rule.threat.tactic] id = "TA0005" name = "Defense Evasion" @@ -145,8 +145,7 @@ reference = "https://attack.mitre.org/tactics/TA0005/" [rule.new_terms] field = "new_terms_fields" value = ["process.parent.name"] + [[rule.new_terms.history_window_start]] field = "history_window_start" -value = "now-14d" - - +value = "now-5d" diff --git a/rules/linux/execution_process_started_in_shared_memory_directory.toml b/rules/linux/execution_process_started_in_shared_memory_directory.toml index 2c230e7fb95..1f0801f42f1 100644 --- a/rules/linux/execution_process_started_in_shared_memory_directory.toml +++ b/rules/linux/execution_process_started_in_shared_memory_directory.toml @@ -2,7 +2,7 @@ creation_date = "2022/05/10" integration = ["endpoint"] maturity = "production" -updated_date = "2025/02/04" +updated_date = "2025/12/18" [rule] author = ["Elastic"] @@ -68,12 +68,16 @@ tags = [ ] timestamp_override = "event.ingested" type = "eql" - query = ''' process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event") and -user.id == "0" and process.executable : ("/dev/shm/*", "/run/shm/*", "/var/run/*", "/var/lock/*") and -not process.executable : ("/var/run/docker/*", "/var/run/utsns/*", "/var/run/s6/*", "/var/run/cloudera-scm-agent/*", -"/var/run/argo/argoexec") and not process.parent.command_line : "/usr/bin/runc init" +user.id == "0" and process.executable like ("/dev/shm/*", "/run/shm/*", "/var/run/*", "/var/lock/*") and +not ( + process.executable : ( + "/var/run/docker/*", "/var/run/utsns/*", "/var/run/s6/*", "/var/run/cloudera-scm-agent/*", + "/var/run/argo/argoexec", "/dev/shm/*.*/sandfly" + ) or + process.parent.command_line == "/usr/bin/runc init" +) ''' note = """## Triage and analysis @@ -112,17 +116,15 @@ Shared memory directories in Linux, such as /dev/shm and /run/shm, are designed - Implement enhanced monitoring and alerting for any future execution of binaries from shared memory directories, ensuring that legitimate processes are whitelisted appropriately. - Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.""" - [[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.tactic] id = "TA0002" name = "Execution" reference = "https://attack.mitre.org/tactics/TA0002/" - diff --git a/rules/linux/execution_python_tty_shell.toml b/rules/linux/execution_python_tty_shell.toml index 959180badda..c8eff177979 100644 --- a/rules/linux/execution_python_tty_shell.toml +++ b/rules/linux/execution_python_tty_shell.toml @@ -2,7 +2,7 @@ creation_date = "2020/04/15" integration = ["endpoint", "sentinel_one_cloud_funnel"] maturity = "production" -updated_date = "2025/03/20" +updated_date = "2025/12/18" [rule] author = ["Elastic"] @@ -11,7 +11,11 @@ Identifies when a terminal (tty) is spawned via Python. Attackers may upgrade a interactive tty after obtaining initial access to a host. """ from = "now-9m" -index = ["endgame-*", "logs-endpoint.events.process*", "logs-sentinel_one_cloud_funnel.*"] +index = [ + "endgame-*", + "logs-endpoint.events.process*", + "logs-sentinel_one_cloud_funnel.*" +] language = "eql" license = "Elastic License v2" name = "Interactive Terminal Spawned via Python" @@ -89,33 +93,36 @@ tags = [ ] 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") and ( (process.parent.name : "python*" and process.name in ("bash", "dash", "ash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and process.parent.args_count >= 3 and process.parent.args : "*pty.spawn*" and process.parent.args : "-c") or - (process.parent.name : "python*" and process.name in ("bash", "dash", "ash", "sh", "tcsh", "csh", "zsh", "ksh", - "fish") and process.args : "*sh" and process.args_count == 1 and process.parent.args_count == 1) + (process.parent.name : "python*" and process.name in ("bash", "dash", "ash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and + process.args in ( + "sh", "dash", "bash", "zsh", + "/bin/sh", "/bin/dash", "/bin/bash", "/bin/zsh", + "/usr/bin/sh", "/usr/bin/dash", "/usr/bin/bash", "/usr/bin/zsh", + "/usr/local/bin/sh", "/usr/local/bin/dash", "/usr/local/bin/bash", "/usr/local/bin/zsh" + ) and process.args_count == 1 and process.parent.args_count == 1 + ) ) ''' - [[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.006" name = "Python" reference = "https://attack.mitre.org/techniques/T1059/006/" - - [rule.threat.tactic] id = "TA0002" name = "Execution" reference = "https://attack.mitre.org/tactics/TA0002/" - diff --git a/rules/linux/execution_python_webserver_spawned.toml b/rules/linux/execution_python_webserver_spawned.toml index a045f2f860e..5f6a9442737 100644 --- a/rules/linux/execution_python_webserver_spawned.toml +++ b/rules/linux/execution_python_webserver_spawned.toml @@ -2,7 +2,7 @@ creation_date = "2024/11/04" integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"] maturity = "production" -updated_date = "2025/03/20" +updated_date = "2025/12/19" [rule] author = ["Elastic"] @@ -55,7 +55,7 @@ Python's built-in HTTP server module allows quick web server deployment, often u - Apply patches and updates to the affected system and any related software to mitigate vulnerabilities that may have been exploited. - Implement network segmentation to limit the ability of unauthorized processes to communicate across the network. - Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to ensure comprehensive remediation and recovery actions are taken.""" -risk_score = 21 +risk_score = 47 rule_id = "99c2b626-de44-4322-b1f9-157ca408c17e" setup = """## Setup @@ -82,7 +82,7 @@ For more details on Elastic Agent configuration settings, refer to the [helper g - 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" +severity = "medium" tags = [ "Domain: Endpoint", "OS: Linux", @@ -96,47 +96,46 @@ tags = [ ] 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 +event.action in ("exec", "exec_event", "start", "ProcessRollup2") and +( + (process.name like "python*" and process.args in ("http.server", "SimpleHTTPServer")) or ( - (process.name like "python*" and process.args in ("http.server", "SimpleHTTPServer")) or - ( - process.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and - process.command_line like~ "*python* -m http.server*" - ) + process.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and + process.command_line like~ "*python* -m http.server*" ) +) and +not process.parent.executable == "/usr/lib/systemd/systemd" ''' - [[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.006" name = "Python" reference = "https://attack.mitre.org/techniques/T1059/006/" - - [rule.threat.tactic] id = "TA0002" name = "Execution" reference = "https://attack.mitre.org/tactics/TA0002/" + [[rule.threat]] framework = "MITRE ATT&CK" + [[rule.threat.technique]] id = "T1570" name = "Lateral Tool Transfer" reference = "https://attack.mitre.org/techniques/T1570/" - [rule.threat.tactic] id = "TA0008" name = "Lateral Movement" reference = "https://attack.mitre.org/tactics/TA0008/" - diff --git a/rules/linux/execution_remote_code_execution_via_postgresql.toml b/rules/linux/execution_remote_code_execution_via_postgresql.toml index 23b306e43a9..1cecb668514 100644 --- a/rules/linux/execution_remote_code_execution_via_postgresql.toml +++ b/rules/linux/execution_remote_code_execution_via_postgresql.toml @@ -2,7 +2,7 @@ creation_date = "2022/06/20" integration = ["endpoint"] maturity = "production" -updated_date = "2025/02/04" +updated_date = "2025/12/18" [rule] author = ["Elastic"] @@ -18,6 +18,40 @@ index = ["endgame-*", "logs-endpoint.events.process*"] language = "eql" license = "Elastic License v2" name = "Potential Code Execution via Postgresql" +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 Code Execution via Postgresql + +PostgreSQL, a robust open-source database system, can be exploited by attackers to execute arbitrary code if they gain unauthorized access or exploit vulnerabilities like SQL injection. Adversaries may leverage command execution capabilities to perform malicious actions. The detection rule identifies suspicious processes initiated by the PostgreSQL user, focusing on shell executions that resemble command injection patterns, while excluding legitimate operations, to flag potential threats. + +### Possible investigation steps + +- Review the process details to confirm the presence of suspicious shell executions by the PostgreSQL user, focusing on processes with arguments containing "*sh" and "echo*". +- Check the parent process information to determine if the process was initiated by a known legitimate service, such as "puppet", or if it includes "BECOME-SUCCESS-" in the command line, which are excluded from the rule. +- Investigate the source of the PostgreSQL access to identify if it originated from an unauthorized or unusual IP address or user account. +- Analyze the timeline of events leading up to and following the alert to identify any patterns or additional suspicious activities that may indicate a broader attack. +- Correlate the alert with other security events or logs from the same host or network segment to assess if there are related indicators of compromise or ongoing threats. + +### False positive analysis + +- Puppet processes may trigger false positives due to their legitimate use of shell commands. To mitigate this, ensure that puppet-related processes are excluded by verifying that process.parent.name is set to "puppet". +- Automation tools that use shell scripts for configuration management might be flagged. Review and exclude these by checking for specific command patterns that are known to be safe, such as those containing "BECOME-SUCCESS". +- Scheduled maintenance scripts executed by the postgres user could be misidentified as threats. Identify these scripts and add them to an exclusion list based on their command line patterns. +- Regular database backup operations that involve shell commands might be mistakenly flagged. Document these operations and exclude them by matching their specific command line arguments. +- Custom monitoring scripts that execute shell commands under the postgres user should be reviewed and excluded if they are verified as non-malicious. + +### Response and remediation + +- Immediately isolate the affected PostgreSQL server from the network to prevent further unauthorized access or malicious actions. +- Terminate any suspicious processes identified by the detection rule to halt potential malicious activities. +- Conduct a thorough review of the PostgreSQL server logs to identify any unauthorized access attempts or successful exploitations, focusing on the timeframes around the detected events. +- Reset credentials for the PostgreSQL user and any other potentially compromised accounts to prevent further unauthorized access. +- Apply the latest security patches and updates to the PostgreSQL server to mitigate known vulnerabilities that could be exploited. +- Implement network segmentation to limit access to the PostgreSQL server, ensuring only authorized systems and users can connect. +- Escalate the incident to the security operations team for further investigation and to assess the potential impact on other systems within the network.""" risk_score = 47 rule_id = "2a692072-d78d-42f3-a48a-775677d79c4e" setup = """## Setup @@ -57,7 +91,6 @@ tags = [ ] timestamp_override = "event.ingested" type = "eql" - query = ''' process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "fork", "fork_event") and user.name == "postgres" and ( @@ -67,45 +100,12 @@ event.action in ("exec", "exec_event", "fork", "fork_event") and user.name == "p process.parent.name == "puppet" or process.command_line like ( "*BECOME-SUCCESS-*", "bash -c while true; do sleep 1;*", "df -l", "sleep 1", "who", "head -v -n *", "tail -v -n *", - "/bin/sh -c echo BECOME-SUCCESS*", "/usr/bin/python3 /var/tmp/ansible-tmp*" + "/bin/sh -c echo BECOME-SUCCESS*", "/usr/bin/python3 /var/tmp/ansible-tmp*", "*chpasswd*" ) or - process.parent.command_line like "*BECOME-SUCCESS-*" + process.parent.command_line like ("*BECOME-SUCCESS-*", "-bash -c echo $HOME", "su - postgres -c echo $HOME") or + process.parent.executable in ("/usr/bin/watch", "/bin/diskmgr", "/usr/bin/diskmgr") ) ''' -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 Code Execution via Postgresql - -PostgreSQL, a robust open-source database system, can be exploited by attackers to execute arbitrary code if they gain unauthorized access or exploit vulnerabilities like SQL injection. Adversaries may leverage command execution capabilities to perform malicious actions. The detection rule identifies suspicious processes initiated by the PostgreSQL user, focusing on shell executions that resemble command injection patterns, while excluding legitimate operations, to flag potential threats. - -### Possible investigation steps - -- Review the process details to confirm the presence of suspicious shell executions by the PostgreSQL user, focusing on processes with arguments containing "*sh" and "echo*". -- Check the parent process information to determine if the process was initiated by a known legitimate service, such as "puppet", or if it includes "BECOME-SUCCESS-" in the command line, which are excluded from the rule. -- Investigate the source of the PostgreSQL access to identify if it originated from an unauthorized or unusual IP address or user account. -- Analyze the timeline of events leading up to and following the alert to identify any patterns or additional suspicious activities that may indicate a broader attack. -- Correlate the alert with other security events or logs from the same host or network segment to assess if there are related indicators of compromise or ongoing threats. - -### False positive analysis - -- Puppet processes may trigger false positives due to their legitimate use of shell commands. To mitigate this, ensure that puppet-related processes are excluded by verifying that process.parent.name is set to "puppet". -- Automation tools that use shell scripts for configuration management might be flagged. Review and exclude these by checking for specific command patterns that are known to be safe, such as those containing "BECOME-SUCCESS". -- Scheduled maintenance scripts executed by the postgres user could be misidentified as threats. Identify these scripts and add them to an exclusion list based on their command line patterns. -- Regular database backup operations that involve shell commands might be mistakenly flagged. Document these operations and exclude them by matching their specific command line arguments. -- Custom monitoring scripts that execute shell commands under the postgres user should be reviewed and excluded if they are verified as non-malicious. - -### Response and remediation - -- Immediately isolate the affected PostgreSQL server from the network to prevent further unauthorized access or malicious actions. -- Terminate any suspicious processes identified by the detection rule to halt potential malicious activities. -- Conduct a thorough review of the PostgreSQL server logs to identify any unauthorized access attempts or successful exploitations, focusing on the timeframes around the detected events. -- Reset credentials for the PostgreSQL user and any other potentially compromised accounts to prevent further unauthorized access. -- Apply the latest security patches and updates to the PostgreSQL server to mitigate known vulnerabilities that could be exploited. -- Implement network segmentation to limit access to the PostgreSQL server, ensuring only authorized systems and users can connect. -- Escalate the incident to the security operations team for further investigation and to assess the potential impact on other systems within the network.""" [[rule.threat]] framework = "MITRE ATT&CK" diff --git a/rules/linux/execution_shell_openssl_client_or_server.toml b/rules/linux/execution_shell_openssl_client_or_server.toml index 30f4cebcb1e..b57a9c5ebbe 100644 --- a/rules/linux/execution_shell_openssl_client_or_server.toml +++ b/rules/linux/execution_shell_openssl_client_or_server.toml @@ -2,7 +2,7 @@ creation_date = "2024/07/30" integration = ["endpoint", "sentinel_one_cloud_funnel"] maturity = "production" -updated_date = "2025/03/20" +updated_date = "2025/12/19" [rule] author = ["Elastic"] @@ -51,7 +51,7 @@ OpenSSL is a widely-used toolkit for implementing secure communication via SSL/T - Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if the threat has spread to other systems. - Implement enhanced monitoring and logging for OpenSSL usage across the network to detect similar activities in the future, ensuring that alerts are promptly reviewed and acted upon.""" references = ["https://gtfobins.github.io/gtfobins/openssl/"] -risk_score = 21 +risk_score = 47 rule_id = "ad5a3757-c872-4719-8c72-12d3f08db655" setup = """## Setup @@ -78,7 +78,7 @@ For more details on Elastic Agent configuration settings, refer to the [helper g - 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" +severity = "medium" tags = [ "Domain: Endpoint", "OS: Linux", @@ -91,46 +91,52 @@ tags = [ ] 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") and - process.name == "openssl" and ( - (process.args == "s_client" and process.args : ("-connect", "*:*") and not process.args == "-showcerts") or - (process.args == "s_server" and process.args == "-port") - ) and - not process.parent.executable in ( - "/pro/xymon/client/ext/awsXymonCheck.sh", "/opt/antidot-svc/nrpe/plugins/check_cert", "/etc/zabbix/scripts/check_dane_tlsa.sh" - ) +process.name == "openssl" and ( + ( + process.args == "s_client" and process.args : ("-connect", "*:*") and + process.args in ( + "sh", "dash", "bash", "zsh", + "/bin/sh", "/bin/dash", "/bin/bash", "/bin/zsh", + "/usr/bin/sh", "/usr/bin/dash", "/usr/bin/bash", "/usr/bin/zsh", + "/usr/local/bin/sh", "/usr/local/bin/dash", "/usr/local/bin/bash", "/usr/local/bin/zsh" + ) and not process.args == "-showcerts" + ) or + (process.args == "s_server" and process.args == "-port") +) and +not process.parent.executable in ( + "/pro/xymon/client/ext/awsXymonCheck.sh", "/opt/antidot-svc/nrpe/plugins/check_cert", "/etc/zabbix/scripts/check_dane_tlsa.sh" +) ''' - [[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 = "T1071" name = "Application Layer Protocol" reference = "https://attack.mitre.org/techniques/T1071/" - [rule.threat.tactic] id = "TA0011" name = "Command and Control" reference = "https://attack.mitre.org/tactics/TA0011/" - diff --git a/rules/linux/execution_shell_via_background_process.toml b/rules/linux/execution_shell_via_background_process.toml index 7960e23158b..71f6934441f 100644 --- a/rules/linux/execution_shell_via_background_process.toml +++ b/rules/linux/execution_shell_via_background_process.toml @@ -2,7 +2,7 @@ creation_date = "2023/09/20" integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"] maturity = "production" -updated_date = "2025/03/20" +updated_date = "2025/12/19" [rule] author = ["Elastic"] @@ -55,7 +55,7 @@ In Linux environments, background processes can be manipulated to establish reve - Apply security patches and updates to the affected system to address any vulnerabilities that may have been exploited. - Implement network segmentation to limit the ability of compromised systems to communicate with critical infrastructure or sensitive data repositories. - Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.""" -risk_score = 47 +risk_score = 73 rule_id = "259be2d8-3b1a-4c2c-a0eb-0c8e77f35e39" setup = """## Setup @@ -82,7 +82,7 @@ For more details on Elastic Agent configuration settings, refer to the [helper g - 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" +severity = "high" tags = [ "Domain: Endpoint", "OS: Linux", @@ -96,42 +96,40 @@ tags = [ ] 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.name in ("setsid", "nohup") and process.args : "*/dev/tcp/*0>&1*" and - process.parent.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") +event.action in ("exec", "exec_event", "start", "ProcessRollup2") and +process.name in ("setsid", "nohup") and process.args : "*/dev/tcp/*0>&1*" and +process.parent.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") ''' - [[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 = "T1071" name = "Application Layer Protocol" reference = "https://attack.mitre.org/techniques/T1071/" - [rule.threat.tactic] id = "TA0011" name = "Command and Control" reference = "https://attack.mitre.org/tactics/TA0011/" - diff --git a/rules/linux/execution_shell_via_child_tcp_utility_linux.toml b/rules/linux/execution_shell_via_child_tcp_utility_linux.toml index cb4b21a61df..b1d6944dd41 100644 --- a/rules/linux/execution_shell_via_child_tcp_utility_linux.toml +++ b/rules/linux/execution_shell_via_child_tcp_utility_linux.toml @@ -2,7 +2,7 @@ creation_date = "2023/11/02" integration = ["endpoint"] maturity = "production" -updated_date = "2025/02/04" +updated_date = "2025/12/18" [rule] author = ["Elastic"] @@ -16,10 +16,45 @@ index = ["logs-endpoint.events.network*", "logs-endpoint.events.process*"] language = "eql" license = "Elastic License v2" name = "Potential Reverse Shell via Child" +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 Reverse Shell via Child + +Reverse shells are a technique where attackers gain remote access to a system by initiating a connection from the target back to the attacker's machine. This is often achieved using shell processes like bash or socat. Adversaries exploit this by executing commands remotely, bypassing firewalls. The detection rule identifies such activity by monitoring for network events followed by suspicious shell process executions, focusing on unusual command-line arguments and parent-child process relationships. + +### Possible investigation steps + +- Review the network event details to identify the source and destination IP addresses involved in the connection attempt or acceptance. Pay special attention to any external IP addresses that are not part of the internal network. +- Examine the process execution details, focusing on the command-line arguments used by the shell process. Look for unusual or suspicious arguments such as "-i" or "-l" that may indicate interactive or login shells. +- Investigate the parent-child process relationship, especially if the parent process is "socat" with arguments containing "exec". This could suggest an attempt to execute a reverse shell. +- Check the timeline of events to determine if the network event and shell process execution occurred within a short time frame (maxspan=5s), which may indicate a coordinated attack. +- Correlate the alert with any other recent suspicious activities on the host, such as unauthorized access attempts or changes in system configurations, to assess the broader context of the potential threat. +- Verify the legitimacy of the involved processes and connections by consulting with system owners or reviewing system documentation to rule out any false positives due to legitimate administrative activities. + +### False positive analysis + +- Legitimate administrative scripts or tools that use shell processes with interactive flags may trigger the rule. To manage this, identify and document these scripts, then create exceptions for their specific command-line arguments or parent processes. +- Automated maintenance tasks or cron jobs that involve shell execution with similar command-line arguments can be mistaken for reverse shell activity. Review these tasks and exclude them by specifying their unique process names or arguments. +- Development or testing environments where developers frequently use shell processes for debugging or testing purposes might cause false positives. Consider excluding these environments by filtering based on host identifiers or specific user accounts. +- Network monitoring tools or legitimate applications that use socat for network connections may appear suspicious. Identify these applications and exclude their specific process names or parent-child relationships from the detection rule. +- Custom scripts or applications that mimic reverse shell behavior for legitimate purposes should be reviewed and excluded by adding their specific process names or command-line patterns to the exception list. + +### Response and remediation + +- Immediately isolate the affected host from the network to prevent further unauthorized access or data exfiltration. +- Terminate any suspicious shell processes identified by the detection rule, especially those initiated by or involving the listed shell programs (e.g., bash, socat). +- Conduct a forensic analysis of the affected system to identify any additional indicators of compromise, such as unauthorized user accounts or modified system files. +- Review and reset credentials for any accounts that may have been compromised, ensuring the use of strong, unique passwords. +- Apply relevant security patches and updates to the affected system to address any vulnerabilities that may have been exploited. +- Monitor network traffic for any further suspicious activity, particularly outgoing connections to unknown or suspicious IP addresses. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.""" references = [ "https://github.com/swisskyrepo/PayloadsAllTheThings/blob/master/Methodology%20and%20Resources/Reverse%20Shell%20Cheatsheet.md", ] -risk_score = 47 +risk_score = 73 rule_id = "2138bb70-5a5e-42fd-be5e-b38edf6a6777" setup = """## Setup @@ -48,7 +83,7 @@ For more details on Elastic Agent configuration settings, refer to the [helper g - 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" +severity = "high" tags = [ "Domain: Endpoint", "OS: Linux", @@ -58,7 +93,6 @@ tags = [ "Resources: Investigation Guide", ] type = "eql" - query = ''' sequence by host.id, process.entity_id with maxspan=5s [network where event.type == "start" and host.os.type == "linux" and @@ -70,70 +104,34 @@ sequence by host.id, process.entity_id with maxspan=5s (process.args : ("-i", "-l")) or (process.parent.name == "socat" and process.parent.args : "*exec*") )] ''' -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 Reverse Shell via Child - -Reverse shells are a technique where attackers gain remote access to a system by initiating a connection from the target back to the attacker's machine. This is often achieved using shell processes like bash or socat. Adversaries exploit this by executing commands remotely, bypassing firewalls. The detection rule identifies such activity by monitoring for network events followed by suspicious shell process executions, focusing on unusual command-line arguments and parent-child process relationships. - -### Possible investigation steps - -- Review the network event details to identify the source and destination IP addresses involved in the connection attempt or acceptance. Pay special attention to any external IP addresses that are not part of the internal network. -- Examine the process execution details, focusing on the command-line arguments used by the shell process. Look for unusual or suspicious arguments such as "-i" or "-l" that may indicate interactive or login shells. -- Investigate the parent-child process relationship, especially if the parent process is "socat" with arguments containing "exec". This could suggest an attempt to execute a reverse shell. -- Check the timeline of events to determine if the network event and shell process execution occurred within a short time frame (maxspan=5s), which may indicate a coordinated attack. -- Correlate the alert with any other recent suspicious activities on the host, such as unauthorized access attempts or changes in system configurations, to assess the broader context of the potential threat. -- Verify the legitimacy of the involved processes and connections by consulting with system owners or reviewing system documentation to rule out any false positives due to legitimate administrative activities. - -### False positive analysis - -- Legitimate administrative scripts or tools that use shell processes with interactive flags may trigger the rule. To manage this, identify and document these scripts, then create exceptions for their specific command-line arguments or parent processes. -- Automated maintenance tasks or cron jobs that involve shell execution with similar command-line arguments can be mistaken for reverse shell activity. Review these tasks and exclude them by specifying their unique process names or arguments. -- Development or testing environments where developers frequently use shell processes for debugging or testing purposes might cause false positives. Consider excluding these environments by filtering based on host identifiers or specific user accounts. -- Network monitoring tools or legitimate applications that use socat for network connections may appear suspicious. Identify these applications and exclude their specific process names or parent-child relationships from the detection rule. -- Custom scripts or applications that mimic reverse shell behavior for legitimate purposes should be reviewed and excluded by adding their specific process names or command-line patterns to the exception list. - -### Response and remediation - -- Immediately isolate the affected host from the network to prevent further unauthorized access or data exfiltration. -- Terminate any suspicious shell processes identified by the detection rule, especially those initiated by or involving the listed shell programs (e.g., bash, socat). -- Conduct a forensic analysis of the affected system to identify any additional indicators of compromise, such as unauthorized user accounts or modified system files. -- Review and reset credentials for any accounts that may have been compromised, ensuring the use of strong, unique passwords. -- Apply relevant security patches and updates to the affected system to address any vulnerabilities that may have been exploited. -- Monitor network traffic for any further suspicious activity, particularly outgoing connections to unknown or suspicious IP addresses. -- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.""" - [[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 = "T1071" name = "Application Layer Protocol" reference = "https://attack.mitre.org/techniques/T1071/" - [rule.threat.tactic] id = "TA0011" name = "Command and Control" reference = "https://attack.mitre.org/tactics/TA0011/" - diff --git a/rules/linux/execution_shell_via_java_revshell_linux.toml b/rules/linux/execution_shell_via_java_revshell_linux.toml index b45e10e2657..ca489d0cc11 100644 --- a/rules/linux/execution_shell_via_java_revshell_linux.toml +++ b/rules/linux/execution_shell_via_java_revshell_linux.toml @@ -2,7 +2,7 @@ creation_date = "2023/07/04" integration = ["endpoint"] maturity = "production" -updated_date = "2025/02/04" +updated_date = "2025/12/19" [rule] author = ["Elastic"] @@ -15,6 +15,39 @@ index = ["logs-endpoint.events.network*", "logs-endpoint.events.process*"] language = "eql" license = "Elastic License v2" name = "Potential Reverse Shell via Java" +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 Reverse Shell via Java + +Java applications, often run on Linux systems, can be exploited by adversaries to establish reverse shells, allowing remote control over a compromised system. Attackers may execute shell commands via Java processes post-network connection. The detection rule identifies suspicious Java activity by monitoring for shell executions following network connections, excluding benign processes, to flag potential reverse shell attempts. + +### Possible investigation steps + +- Review the network connection details, focusing on the destination IP address to determine if it is external or potentially malicious, as the rule excludes common internal and reserved IP ranges. +- Examine the Java process that initiated the network connection, including its executable path and arguments, to identify any unusual or unauthorized JAR files being executed. +- Investigate the child shell process spawned by the Java application, checking its command-line arguments and execution context to assess if it aligns with known reverse shell patterns. +- Cross-reference the parent Java process and the child shell process with known benign applications or services, such as Jenkins or NetExtender, to rule out false positives. +- Analyze historical data for the host to identify any previous similar activities or patterns that might indicate a persistent threat or repeated exploitation attempts. + +### False positive analysis + +- Java-based administrative tools like Jenkins may trigger false positives when executing shell commands. Exclude known benign Java applications such as Jenkins by adding their specific JAR paths to the exception list. +- Automated scripts or maintenance tasks that use Java to execute shell commands can be mistaken for reverse shell activity. Identify and exclude these scripts by specifying their unique process arguments or executable paths. +- Development environments where Java applications frequently execute shell commands for testing purposes can generate false alerts. Consider excluding these environments by filtering based on specific host identifiers or network segments. +- Security tools that utilize Java for network operations and shell executions might be flagged. Verify and exclude these tools by adding their process names or executable paths to the exception list. + +### Response and remediation + +- Immediately isolate the affected host from the network to prevent further unauthorized access or data exfiltration. +- Terminate any suspicious Java processes identified in the alert to stop potential reverse shell activity. +- Conduct a thorough review of the affected system's logs to identify any additional indicators of compromise or lateral movement attempts. +- Remove any unauthorized or malicious Java JAR files and associated scripts from the system. +- Apply security patches and updates to the Java environment and any other vulnerable software on the affected host. +- Restore the system from a known good backup if any unauthorized changes or persistent threats are detected. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to assess the potential impact on other systems within the network.""" references = [ "https://github.com/swisskyrepo/PayloadsAllTheThings/blob/master/Methodology%20and%20Resources/Reverse%20Shell%20Cheatsheet.md", ] @@ -55,7 +88,6 @@ tags = [ "Resources: Investigation Guide", ] type = "eql" - query = ''' sequence by host.id with maxspan=5s [network where host.os.type == "linux" and event.action in ("connection_accepted", "connection_attempted") and @@ -71,73 +103,52 @@ sequence by host.id with maxspan=5s [process where host.os.type == "linux" and event.action == "exec" and process.parent.executable : ("/usr/bin/java", "/bin/java", "/usr/lib/jvm/*", "/usr/java/*") and process.parent.args : "-jar" and process.name in ("bash", "dash", "ash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") - and not process.parent.args in ( - "/usr/share/java/jenkins.war", "/etc/remote-iot/services/remoteiot.jar", - "/usr/lib64/NetExtender.jar", "/usr/lib/jenkins/jenkins.war" + and not ( + process.parent.args in ( + "/usr/lib/jenkins/jenkins.war", "/etc/remote-iot/services/remoteiot.jar", "/opt/pentaho/data-integration/launcher/launcher.jar", + "/usr/share/java/jenkins.war", "/opt//tomcat/statistics/statistics.jar", "/usr/lib64/NetExtender.jar", + "/var/lib/jenkins/workspace/MP-QA/tc_certified_copy*/tc_certified_copy_web_ui_test/target/surefire/surefirebooter*.jar", + "-javaagent:/opt/opentelemetry/opentelemetry-javaagent-all.jar", "./lib/pipeline-job-executor*SNAPSHOT.jar", + "./lib/worker-launcher-agent*SNAPSHOT.jar", "/opt/Seqrite_EndPoint_Security/wildfly/jboss-modules.jar", + "/home/data/jenkins.war", "/pro/service-modules/deployment.jar", "/application/HES/READER/*.jar", "*-SNAPSHOT.jar", + "READER/G1A/READER_G1A.jar", "READER_G1.jar" + ) or + process.command_line like~ ( + "bash -c ps -eo pid,lstart,comm*", + "bash -c df -i /application | tail -n 1", + "/bin/sh -xe /tmp/hudson*.sh", + "bash -c cat /application/HES/*" + ) )] 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 Potential Reverse Shell via Java - -Java applications, often run on Linux systems, can be exploited by adversaries to establish reverse shells, allowing remote control over a compromised system. Attackers may execute shell commands via Java processes post-network connection. The detection rule identifies suspicious Java activity by monitoring for shell executions following network connections, excluding benign processes, to flag potential reverse shell attempts. - -### Possible investigation steps - -- Review the network connection details, focusing on the destination IP address to determine if it is external or potentially malicious, as the rule excludes common internal and reserved IP ranges. -- Examine the Java process that initiated the network connection, including its executable path and arguments, to identify any unusual or unauthorized JAR files being executed. -- Investigate the child shell process spawned by the Java application, checking its command-line arguments and execution context to assess if it aligns with known reverse shell patterns. -- Cross-reference the parent Java process and the child shell process with known benign applications or services, such as Jenkins or NetExtender, to rule out false positives. -- Analyze historical data for the host to identify any previous similar activities or patterns that might indicate a persistent threat or repeated exploitation attempts. - -### False positive analysis - -- Java-based administrative tools like Jenkins may trigger false positives when executing shell commands. Exclude known benign Java applications such as Jenkins by adding their specific JAR paths to the exception list. -- Automated scripts or maintenance tasks that use Java to execute shell commands can be mistaken for reverse shell activity. Identify and exclude these scripts by specifying their unique process arguments or executable paths. -- Development environments where Java applications frequently execute shell commands for testing purposes can generate false alerts. Consider excluding these environments by filtering based on specific host identifiers or network segments. -- Security tools that utilize Java for network operations and shell executions might be flagged. Verify and exclude these tools by adding their process names or executable paths to the exception list. - -### Response and remediation - -- Immediately isolate the affected host from the network to prevent further unauthorized access or data exfiltration. -- Terminate any suspicious Java processes identified in the alert to stop potential reverse shell activity. -- Conduct a thorough review of the affected system's logs to identify any additional indicators of compromise or lateral movement attempts. -- Remove any unauthorized or malicious Java JAR files and associated scripts from the system. -- Apply security patches and updates to the Java environment and any other vulnerable software on the affected host. -- Restore the system from a known good backup if any unauthorized changes or persistent threats are detected. -- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to assess the potential impact on other systems within the network.""" - [[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 = "T1071" name = "Application Layer Protocol" reference = "https://attack.mitre.org/techniques/T1071/" - [rule.threat.tactic] id = "TA0011" name = "Command and Control" reference = "https://attack.mitre.org/tactics/TA0011/" - diff --git a/rules/linux/execution_shell_via_lolbin_interpreter_linux.toml b/rules/linux/execution_shell_via_lolbin_interpreter_linux.toml index 4640cc46cb7..26b891475de 100644 --- a/rules/linux/execution_shell_via_lolbin_interpreter_linux.toml +++ b/rules/linux/execution_shell_via_lolbin_interpreter_linux.toml @@ -2,7 +2,7 @@ creation_date = "2023/07/04" integration = ["endpoint"] maturity = "production" -updated_date = "2025/02/04" +updated_date = "2025/12/19" [rule] author = ["Elastic"] @@ -16,10 +16,45 @@ index = ["logs-endpoint.events.network*", "logs-endpoint.events.process*"] language = "eql" license = "Elastic License v2" name = "Potential Reverse Shell via Suspicious Child Process" +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 Reverse Shell via Suspicious Child Process + +Reverse shells are a common technique used by attackers to gain remote access to a compromised system. They exploit scripting languages and utilities like Python, Perl, and Netcat to execute commands remotely. The detection rule identifies suspicious process chains and network activities, such as unexpected shell spawns and outbound connections, to flag potential reverse shell attempts, leveraging process and network event analysis to detect anomalies. + +### Possible investigation steps + +- Review the process chain to identify the parent process and determine if it is expected behavior for the system. Check the process.parent.name field for any unusual or unauthorized parent processes. +- Analyze the process arguments captured in the alert, such as process.args, to understand the command being executed and assess if it aligns with known reverse shell patterns. +- Investigate the network connection details, focusing on the destination.ip field, to determine if the connection is to a known malicious IP or an unexpected external address. +- Check the process.name field to identify the specific utility used (e.g., python, perl, nc) and verify if its usage is legitimate or if it indicates a potential compromise. +- Correlate the alert with other security events or logs from the same host.id to identify any additional suspicious activities or patterns that may indicate a broader attack. +- Consult threat intelligence sources to gather information on any identified IP addresses or domains involved in the network connection to assess their reputation and potential threat level. + +### False positive analysis + +- Development and testing environments may frequently execute scripts using languages like Python, Perl, or Ruby, which can trigger the rule. To manage this, consider excluding specific host IDs or process names associated with known development activities. +- Automated scripts or cron jobs that utilize network connections for legitimate purposes, such as data backups or updates, might be flagged. Identify these processes and add them to an exception list based on their parent process names or specific arguments. +- System administrators might use tools like Netcat or OpenSSL for troubleshooting or monitoring network connections. If these activities are routine and verified, exclude them by specifying the administrator's user ID or the specific command patterns used. +- Security tools or monitoring solutions that simulate attack scenarios for testing purposes can also trigger this rule. Ensure these tools are recognized and excluded by their process names or associated network activities. +- Custom scripts that use shell commands to interact with remote systems for maintenance tasks may appear suspicious. Review these scripts and exclude them by their unique process arguments or parent process names. + +### Response and remediation + +- Immediately isolate the affected host from the network to prevent further unauthorized access or data exfiltration. +- Terminate any suspicious processes identified by the detection rule, particularly those involving scripting languages or utilities like Python, Perl, or Netcat. +- Conduct a forensic analysis of the affected system to identify any additional indicators of compromise, such as unauthorized user accounts or modified system files. +- Review and reset credentials for any accounts that may have been accessed or compromised during the incident. +- Apply security patches and updates to the affected system to address any vulnerabilities that may have been exploited. +- Monitor network traffic for any signs of further suspicious activity, focusing on outbound connections from the affected host. +- Escalate the incident to the security operations center (SOC) or relevant security team for further investigation and to ensure comprehensive remediation efforts.""" references = [ "https://github.com/swisskyrepo/PayloadsAllTheThings/blob/master/Methodology%20and%20Resources/Reverse%20Shell%20Cheatsheet.md", ] -risk_score = 47 +risk_score = 73 rule_id = "76e4d92b-61c1-4a95-ab61-5fd94179a1ee" setup = """## Setup @@ -46,7 +81,7 @@ For more details on Elastic Agent configuration settings, refer to the [helper g - 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" +severity = "high" tags = [ "Domain: Endpoint", "OS: Linux", @@ -56,7 +91,6 @@ tags = [ "Resources: Investigation Guide", ] type = "eql" - query = ''' sequence by host.id, process.entity_id with maxspan=1s [process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "fork") and ( @@ -74,81 +108,43 @@ sequence by host.id, process.entity_id with maxspan=1s )) or (process.name : "php*" and process.args : "-r" and process.args : "*fsockopen*" and process.args : "*/bin/*sh*") or (process.name : ("awk", "gawk", "mawk", "nawk") and process.args : "*/inet/tcp/*") or - (process.name : "openssl" and process.args : "-connect") or (process.name : ("nc", "ncat", "netcat") and process.args == "-e" and process.args_count >= 3 and - not process.args == "-z") or - (process.name : "telnet" and process.args_count >= 3) + not process.args == "-z") ) and process.parent.name : ( "bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish", "python*", "php*", "perl", "ruby", "lua*", - "openssl", "nc", "netcat", "ncat", "telnet", "awk")] + "nc", "netcat", "ncat", "awk", "gawk", "mawk", "nawk")] [network where host.os.type == "linux" and event.type == "start" and event.action in ("connection_attempted", "connection_accepted") and - process.name : ("python*", "php*", "perl", "ruby", "lua*", "openssl", "nc", "netcat", "ncat", "telnet", "awk") and + process.name : ("python*", "php*", "perl", "ruby", "lua*", "nc", "netcat", "ncat", "awk", "gawk", "mawk", "nawk") and destination.ip != null and not cidrmatch(destination.ip, "127.0.0.0/8", "169.254.0.0/16", "224.0.0.0/4", "::1")] ''' -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 Reverse Shell via Suspicious Child Process - -Reverse shells are a common technique used by attackers to gain remote access to a compromised system. They exploit scripting languages and utilities like Python, Perl, and Netcat to execute commands remotely. The detection rule identifies suspicious process chains and network activities, such as unexpected shell spawns and outbound connections, to flag potential reverse shell attempts, leveraging process and network event analysis to detect anomalies. - -### Possible investigation steps - -- Review the process chain to identify the parent process and determine if it is expected behavior for the system. Check the process.parent.name field for any unusual or unauthorized parent processes. -- Analyze the process arguments captured in the alert, such as process.args, to understand the command being executed and assess if it aligns with known reverse shell patterns. -- Investigate the network connection details, focusing on the destination.ip field, to determine if the connection is to a known malicious IP or an unexpected external address. -- Check the process.name field to identify the specific utility used (e.g., python, perl, nc) and verify if its usage is legitimate or if it indicates a potential compromise. -- Correlate the alert with other security events or logs from the same host.id to identify any additional suspicious activities or patterns that may indicate a broader attack. -- Consult threat intelligence sources to gather information on any identified IP addresses or domains involved in the network connection to assess their reputation and potential threat level. - -### False positive analysis - -- Development and testing environments may frequently execute scripts using languages like Python, Perl, or Ruby, which can trigger the rule. To manage this, consider excluding specific host IDs or process names associated with known development activities. -- Automated scripts or cron jobs that utilize network connections for legitimate purposes, such as data backups or updates, might be flagged. Identify these processes and add them to an exception list based on their parent process names or specific arguments. -- System administrators might use tools like Netcat or OpenSSL for troubleshooting or monitoring network connections. If these activities are routine and verified, exclude them by specifying the administrator's user ID or the specific command patterns used. -- Security tools or monitoring solutions that simulate attack scenarios for testing purposes can also trigger this rule. Ensure these tools are recognized and excluded by their process names or associated network activities. -- Custom scripts that use shell commands to interact with remote systems for maintenance tasks may appear suspicious. Review these scripts and exclude them by their unique process arguments or parent process names. - -### Response and remediation - -- Immediately isolate the affected host from the network to prevent further unauthorized access or data exfiltration. -- Terminate any suspicious processes identified by the detection rule, particularly those involving scripting languages or utilities like Python, Perl, or Netcat. -- Conduct a forensic analysis of the affected system to identify any additional indicators of compromise, such as unauthorized user accounts or modified system files. -- Review and reset credentials for any accounts that may have been accessed or compromised during the incident. -- Apply security patches and updates to the affected system to address any vulnerabilities that may have been exploited. -- Monitor network traffic for any signs of further suspicious activity, focusing on outbound connections from the affected host. -- Escalate the incident to the security operations center (SOC) or relevant security team for further investigation and to ensure comprehensive remediation efforts.""" - [[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 = "T1071" name = "Application Layer Protocol" reference = "https://attack.mitre.org/techniques/T1071/" - [rule.threat.tactic] id = "TA0011" name = "Command and Control" reference = "https://attack.mitre.org/tactics/TA0011/" - diff --git a/rules/linux/execution_shell_via_meterpreter_linux.toml b/rules/linux/execution_shell_via_meterpreter_linux.toml index c75cdf995e1..8e75039764d 100644 --- a/rules/linux/execution_shell_via_meterpreter_linux.toml +++ b/rules/linux/execution_shell_via_meterpreter_linux.toml @@ -2,7 +2,7 @@ creation_date = "2023/08/10" integration = ["auditd_manager"] maturity = "production" -updated_date = "2025/01/15" +updated_date = "2025/12/19" [rule] author = ["Elastic"] @@ -20,7 +20,7 @@ references = [ "https://www.elastic.co/security-labs/primer-on-persistence-mechanisms", "https://www.elastic.co/security-labs/linux-detection-engineering-with-auditd", ] -risk_score = 47 +risk_score = 73 rule_id = "5c895b4f-9133-4e68-9e23-59902175355c" setup = """## Setup @@ -60,7 +60,7 @@ However, if more advanced configuration is required to detect specific behavior, -w /etc/machine-id -p wa -k machineid -w /etc/passwd -p wa -k passwd """ -severity = "medium" +severity = "high" tags = [ "Data Source: Auditd Manager", "Domain: Endpoint", @@ -71,7 +71,6 @@ tags = [ ] timestamp_override = "event.ingested" type = "eql" - query = ''' sample by host.id, process.pid, user.id [file where host.os.type == "linux" and auditd.data.syscall == "open" and auditd.data.a2 == "1b6" and file.path == "/etc/machine-id"] @@ -115,34 +114,33 @@ Meterpreter is a sophisticated payload within the Metasploit framework, enabling - Implement network segmentation to limit the potential impact of future attacks and enhance monitoring of critical systems for similar suspicious activities. - Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.""" - [[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 = "T1071" name = "Application Layer Protocol" reference = "https://attack.mitre.org/techniques/T1071/" - [rule.threat.tactic] id = "TA0011" name = "Command and Control" reference = "https://attack.mitre.org/tactics/TA0011/" - diff --git a/rules/linux/execution_shell_via_suspicious_binary.toml b/rules/linux/execution_shell_via_suspicious_binary.toml index a3e2057910d..ed5b8943ef7 100644 --- a/rules/linux/execution_shell_via_suspicious_binary.toml +++ b/rules/linux/execution_shell_via_suspicious_binary.toml @@ -2,7 +2,7 @@ creation_date = "2023/07/05" integration = ["endpoint"] maturity = "production" -updated_date = "2025/02/04" +updated_date = "2025/12/19" [rule] author = ["Elastic"] @@ -17,10 +17,45 @@ index = ["logs-endpoint.events.network*", "logs-endpoint.events.process*"] language = "eql" license = "Elastic License v2" name = "Potential Reverse Shell via Suspicious Binary" +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 Reverse Shell via Suspicious Binary + +Reverse shells are a common technique used by attackers to gain persistent access to a compromised system. They exploit legitimate shell environments to execute commands remotely. Adversaries often deploy binaries in unusual directories to evade detection. The detection rule identifies suspicious binaries executed in these locations, followed by network activity and shell spawning, indicating potential reverse shell activity. This approach helps in identifying unauthorized access attempts on Linux systems. + +### Possible investigation steps + +- Review the process execution details to identify the suspicious binary's path and name, focusing on the directories specified in the query such as /tmp, /var/tmp, and /dev/shm. +- Examine the parent process of the suspicious binary to determine if it was spawned by a legitimate shell process like bash or sh, as indicated in the query. +- Analyze the network activity associated with the suspicious binary, paying attention to the destination IP address to identify any external connections that are not local (i.e., not 127.0.0.1 or ::1). +- Check the process tree to see if a new shell was spawned following the network activity, which could indicate a reverse shell attempt. +- Investigate the user account under which the suspicious process was executed to assess if it aligns with expected behavior or if it might be compromised. +- Correlate the event timestamps to understand the sequence of actions and verify if they align with typical reverse shell behavior patterns. + +### False positive analysis + +- Legitimate administrative scripts or binaries may be executed from directories like /tmp or /var/tmp during maintenance tasks. To handle this, create exceptions for known scripts or binaries used by trusted administrators. +- Automated deployment tools might temporarily use directories such as /dev/shm or /run for staging files. Identify these tools and exclude their processes from triggering the rule. +- Custom monitoring or backup scripts could initiate network connections from non-standard directories. Review these scripts and whitelist their activities if they are verified as safe. +- Development or testing environments might involve executing binaries from unusual locations. Ensure these environments are well-documented and exclude their processes from the detection rule. +- Some legitimate applications may spawn shells as part of their normal operation. Identify these applications and add them to an exception list to prevent false alerts. + +### Response and remediation + +- Isolate the affected system from the network immediately to prevent further unauthorized access or data exfiltration. +- Terminate any suspicious processes identified by the detection rule, especially those originating from unusual directories or involving shell spawning. +- Conduct a thorough review of the system's scheduled tasks, startup scripts, and cron jobs to identify and remove any unauthorized entries that may have been added by the attacker. +- Analyze network logs to identify any external IP addresses involved in the suspicious network activity and block these IPs at the firewall to prevent further connections. +- Restore the affected system from a known good backup to ensure that any malicious changes are reverted. +- Update and patch the system to the latest security standards to close any vulnerabilities that may have been exploited. +- Escalate the incident to the security operations team for further investigation and to assess the potential impact on other systems within the network.""" references = [ "https://github.com/swisskyrepo/PayloadsAllTheThings/blob/master/Methodology%20and%20Resources/Reverse%20Shell%20Cheatsheet.md", ] -risk_score = 47 +risk_score = 73 rule_id = "fa3a59dc-33c3-43bf-80a9-e8437a922c7f" setup = """## Setup @@ -47,7 +82,7 @@ For more details on Elastic Agent configuration settings, refer to the [helper g - 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" +severity = "high" tags = [ "Domain: Endpoint", "OS: Linux", @@ -57,7 +92,6 @@ tags = [ "Resources: Investigation Guide", ] type = "eql" - query = ''' sequence by host.id, process.entity_id with maxspan=1s [ process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and @@ -78,70 +112,34 @@ sequence by host.id, process.entity_id with maxspan=1s process.name : ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and process.parent.name : ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") ] ''' -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 Reverse Shell via Suspicious Binary - -Reverse shells are a common technique used by attackers to gain persistent access to a compromised system. They exploit legitimate shell environments to execute commands remotely. Adversaries often deploy binaries in unusual directories to evade detection. The detection rule identifies suspicious binaries executed in these locations, followed by network activity and shell spawning, indicating potential reverse shell activity. This approach helps in identifying unauthorized access attempts on Linux systems. - -### Possible investigation steps - -- Review the process execution details to identify the suspicious binary's path and name, focusing on the directories specified in the query such as /tmp, /var/tmp, and /dev/shm. -- Examine the parent process of the suspicious binary to determine if it was spawned by a legitimate shell process like bash or sh, as indicated in the query. -- Analyze the network activity associated with the suspicious binary, paying attention to the destination IP address to identify any external connections that are not local (i.e., not 127.0.0.1 or ::1). -- Check the process tree to see if a new shell was spawned following the network activity, which could indicate a reverse shell attempt. -- Investigate the user account under which the suspicious process was executed to assess if it aligns with expected behavior or if it might be compromised. -- Correlate the event timestamps to understand the sequence of actions and verify if they align with typical reverse shell behavior patterns. - -### False positive analysis - -- Legitimate administrative scripts or binaries may be executed from directories like /tmp or /var/tmp during maintenance tasks. To handle this, create exceptions for known scripts or binaries used by trusted administrators. -- Automated deployment tools might temporarily use directories such as /dev/shm or /run for staging files. Identify these tools and exclude their processes from triggering the rule. -- Custom monitoring or backup scripts could initiate network connections from non-standard directories. Review these scripts and whitelist their activities if they are verified as safe. -- Development or testing environments might involve executing binaries from unusual locations. Ensure these environments are well-documented and exclude their processes from the detection rule. -- Some legitimate applications may spawn shells as part of their normal operation. Identify these applications and add them to an exception list to prevent false alerts. - -### Response and remediation - -- Isolate the affected system from the network immediately to prevent further unauthorized access or data exfiltration. -- Terminate any suspicious processes identified by the detection rule, especially those originating from unusual directories or involving shell spawning. -- Conduct a thorough review of the system's scheduled tasks, startup scripts, and cron jobs to identify and remove any unauthorized entries that may have been added by the attacker. -- Analyze network logs to identify any external IP addresses involved in the suspicious network activity and block these IPs at the firewall to prevent further connections. -- Restore the affected system from a known good backup to ensure that any malicious changes are reverted. -- Update and patch the system to the latest security standards to close any vulnerabilities that may have been exploited. -- Escalate the incident to the security operations team for further investigation and to assess the potential impact on other systems within the network.""" - [[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 = "T1071" name = "Application Layer Protocol" reference = "https://attack.mitre.org/techniques/T1071/" - [rule.threat.tactic] id = "TA0011" name = "Command and Control" reference = "https://attack.mitre.org/tactics/TA0011/" - diff --git a/rules/linux/execution_shell_via_tcp_cli_utility_linux.toml b/rules/linux/execution_shell_via_tcp_cli_utility_linux.toml index 3a93c51c73a..c8be644cd99 100644 --- a/rules/linux/execution_shell_via_tcp_cli_utility_linux.toml +++ b/rules/linux/execution_shell_via_tcp_cli_utility_linux.toml @@ -2,7 +2,7 @@ creation_date = "2023/07/04" integration = ["endpoint"] maturity = "production" -updated_date = "2025/02/04" +updated_date = "2025/12/19" [rule] author = ["Elastic"] @@ -16,10 +16,45 @@ index = ["logs-endpoint.events.network*", "logs-endpoint.events.process*"] language = "eql" license = "Elastic License v2" name = "Potential Reverse Shell" +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 Reverse Shell + +Reverse shells are tools that adversaries use to gain remote access to a system by initiating a connection from the target back to the attacker. This detection rule identifies such activity by monitoring for network events followed by shell process creation on Linux systems. It flags suspicious patterns, such as shell processes with interactive flags or spawned by tools like socat, indicating potential unauthorized access attempts. + +### Possible investigation steps + +- Review the network event details to identify the source and destination IP addresses involved in the connection attempt or acceptance. Pay special attention to any external IP addresses that are not part of the internal network ranges. +- Examine the process tree to understand the parent-child relationship, focusing on the shell process creation following the network event. Verify if the shell process was spawned by a known tool like socat. +- Check the process arguments for interactive flags such as "-i" or "-l" to determine if the shell was intended to be interactive, which could indicate malicious intent. +- Investigate the user account associated with the process to determine if it is a legitimate user or if there are signs of compromise, such as unusual login times or locations. +- Correlate the event with other security logs or alerts to identify any additional suspicious activities or patterns that might indicate a broader attack campaign. +- Assess the risk and impact of the potential reverse shell by determining if any sensitive data or critical systems could have been accessed or compromised. + +### False positive analysis + +- Legitimate administrative tasks using interactive shells may trigger this rule. System administrators often use shells with interactive flags for maintenance. To mitigate, create exceptions for known administrator accounts or specific IP addresses. +- Automated scripts or cron jobs that use shell commands with interactive flags can be mistaken for reverse shells. Review and whitelist these scripts by process name or parent process ID to prevent false alerts. +- Tools like socat are used in legitimate network troubleshooting and testing. If socat is frequently used in your environment, consider excluding specific command patterns or user accounts associated with its legitimate use. +- Development environments may spawn shell processes as part of testing or deployment workflows. Identify and exclude these environments by host ID or process name to reduce noise. +- Internal network connections that match the rule's criteria but are part of normal operations can be excluded by specifying internal IP ranges or known service accounts. + +### Response and remediation + +- Immediately isolate the affected host from the network to prevent further unauthorized access or data exfiltration. +- Terminate any suspicious shell processes identified by the detection rule, especially those initiated by socat or with interactive flags. +- Conduct a forensic analysis of the affected system to identify any additional indicators of compromise, such as unauthorized user accounts or modified files. +- Review and secure network configurations to ensure that only authorized IP addresses can initiate connections to critical systems. +- Update and patch the affected system and any related software to close vulnerabilities that may have been exploited. +- Implement enhanced monitoring and logging on the affected host and network to detect any further attempts at reverse shell activity. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if broader organizational impacts exist.""" references = [ "https://github.com/swisskyrepo/PayloadsAllTheThings/blob/master/Methodology%20and%20Resources/Reverse%20Shell%20Cheatsheet.md", ] -risk_score = 47 +risk_score = 73 rule_id = "48b3d2e3-f4e8-41e6-95e6-9b2091228db3" setup = """## Setup @@ -46,7 +81,7 @@ For more details on Elastic Agent configuration settings, refer to the [helper g - 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" +severity = "high" tags = [ "Domain: Endpoint", "OS: Linux", @@ -56,7 +91,6 @@ tags = [ "Resources: Investigation Guide", ] type = "eql" - query = ''' sequence by host.id with maxspan=5s [network where event.type == "start" and host.os.type == "linux" and @@ -68,70 +102,34 @@ sequence by host.id with maxspan=5s (process.args : ("-i", "-l")) or (process.parent.name == "socat" and process.parent.args : "*exec*") )] 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 Potential Reverse Shell - -Reverse shells are tools that adversaries use to gain remote access to a system by initiating a connection from the target back to the attacker. This detection rule identifies such activity by monitoring for network events followed by shell process creation on Linux systems. It flags suspicious patterns, such as shell processes with interactive flags or spawned by tools like socat, indicating potential unauthorized access attempts. - -### Possible investigation steps - -- Review the network event details to identify the source and destination IP addresses involved in the connection attempt or acceptance. Pay special attention to any external IP addresses that are not part of the internal network ranges. -- Examine the process tree to understand the parent-child relationship, focusing on the shell process creation following the network event. Verify if the shell process was spawned by a known tool like socat. -- Check the process arguments for interactive flags such as "-i" or "-l" to determine if the shell was intended to be interactive, which could indicate malicious intent. -- Investigate the user account associated with the process to determine if it is a legitimate user or if there are signs of compromise, such as unusual login times or locations. -- Correlate the event with other security logs or alerts to identify any additional suspicious activities or patterns that might indicate a broader attack campaign. -- Assess the risk and impact of the potential reverse shell by determining if any sensitive data or critical systems could have been accessed or compromised. - -### False positive analysis - -- Legitimate administrative tasks using interactive shells may trigger this rule. System administrators often use shells with interactive flags for maintenance. To mitigate, create exceptions for known administrator accounts or specific IP addresses. -- Automated scripts or cron jobs that use shell commands with interactive flags can be mistaken for reverse shells. Review and whitelist these scripts by process name or parent process ID to prevent false alerts. -- Tools like socat are used in legitimate network troubleshooting and testing. If socat is frequently used in your environment, consider excluding specific command patterns or user accounts associated with its legitimate use. -- Development environments may spawn shell processes as part of testing or deployment workflows. Identify and exclude these environments by host ID or process name to reduce noise. -- Internal network connections that match the rule's criteria but are part of normal operations can be excluded by specifying internal IP ranges or known service accounts. - -### Response and remediation - -- Immediately isolate the affected host from the network to prevent further unauthorized access or data exfiltration. -- Terminate any suspicious shell processes identified by the detection rule, especially those initiated by socat or with interactive flags. -- Conduct a forensic analysis of the affected system to identify any additional indicators of compromise, such as unauthorized user accounts or modified files. -- Review and secure network configurations to ensure that only authorized IP addresses can initiate connections to critical systems. -- Update and patch the affected system and any related software to close vulnerabilities that may have been exploited. -- Implement enhanced monitoring and logging on the affected host and network to detect any further attempts at reverse shell activity. -- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if broader organizational impacts exist.""" - [[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 = "T1071" name = "Application Layer Protocol" reference = "https://attack.mitre.org/techniques/T1071/" - [rule.threat.tactic] id = "TA0011" name = "Command and Control" reference = "https://attack.mitre.org/tactics/TA0011/" - diff --git a/rules/linux/execution_shell_via_udp_cli_utility_linux.toml b/rules/linux/execution_shell_via_udp_cli_utility_linux.toml index 99ad762685a..35f575a8b8e 100644 --- a/rules/linux/execution_shell_via_udp_cli_utility_linux.toml +++ b/rules/linux/execution_shell_via_udp_cli_utility_linux.toml @@ -2,7 +2,7 @@ creation_date = "2023/07/04" integration = ["auditd_manager"] maturity = "production" -updated_date = "2025/01/15" +updated_date = "2025/12/19" [rule] author = ["Elastic"] @@ -17,6 +17,41 @@ index = ["auditbeat-*", "logs-auditd_manager.auditd-*"] language = "eql" license = "Elastic License v2" name = "Potential Reverse Shell via UDP" +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 Reverse Shell via UDP + +Reverse shells over UDP can be exploited by attackers to bypass firewalls and gain unauthorized access to systems. This technique leverages UDP's connectionless nature, making it harder to detect. Adversaries may use scripting languages or network tools to initiate these connections. The detection rule identifies suspicious processes executing network-related syscalls and egress connections, flagging potential reverse shell activity. + +### Possible investigation steps + +- Review the process details such as process.pid, process.parent.pid, and process.name to identify the specific process that triggered the alert and its parent process. +- Examine the command line arguments and environment variables associated with the suspicious process to understand its intended function and origin. +- Check the network connection details, including destination.ip and network.direction, to determine the external entity the process attempted to connect to and assess if it is a known malicious IP or domain. +- Investigate the user account associated with the process to determine if it has been compromised or if there are any signs of unauthorized access. +- Analyze historical logs for any previous instances of similar process executions or network connections to identify patterns or repeated attempts. +- Correlate the alert with other security events or alerts from the same host.id to gather additional context and assess the scope of potential compromise. + +### False positive analysis + +- Legitimate administrative scripts or tools may trigger the rule if they use UDP for valid network operations. Users can create exceptions for specific scripts or processes that are known to perform routine administrative tasks. +- Automated monitoring or network management tools that use UDP for health checks or status updates might be flagged. Identify these tools and exclude their process names or network patterns from the rule. +- Development or testing environments where developers frequently use scripting languages or network tools for legitimate purposes can cause false positives. Consider excluding specific host IDs or process names associated with these environments. +- Custom applications that use UDP for communication, especially if they are developed in-house, may be mistakenly identified. Review these applications and whitelist their process names or network behaviors if they are verified as safe. +- Network scanning or diagnostic tools that use UDP for troubleshooting can be misinterpreted as malicious. Ensure these tools are recognized and excluded from the detection rule if they are part of regular network maintenance activities. + +### Response and remediation + +- Immediately isolate the affected host from the network to prevent further unauthorized access or data exfiltration. +- Terminate any suspicious processes identified by the detection rule, particularly those associated with known reverse shell tools or scripting languages. +- Conduct a forensic analysis of the affected system to identify any additional indicators of compromise, such as unauthorized user accounts or modified system files. +- Review and update firewall rules to block outbound UDP traffic from unauthorized applications or processes, ensuring legitimate traffic is not disrupted. +- Reset credentials for any accounts accessed from the affected host, especially if they have administrative privileges. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if other systems may be affected. +- Implement enhanced monitoring and logging for similar suspicious activities, focusing on the execution of network-related syscalls and egress connections from scripting languages or network tools.""" references = [ "https://github.com/swisskyrepo/PayloadsAllTheThings/blob/master/Methodology%20and%20Resources/Reverse%20Shell%20Cheatsheet.md", "https://www.elastic.co/security-labs/primer-on-persistence-mechanisms", @@ -70,13 +105,13 @@ tags = [ ] timestamp_override = "event.ingested" type = "eql" - query = ''' sample by host.id, process.pid, process.parent.pid [process where host.os.type == "linux" and event.type == "start" and event.action == "executed" and process.name : ( "bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish", "perl", "python*", "nc", "ncat", "netcat", "php*", "ruby", "openssl", "awk", "telnet", "lua*", "socat" - )] + ) and + not process.args in ("/var/www/MISP/app/Console/cake", "/var/www/MISP/app", "/usr/local/bin/wp")] [process where host.os.type == "linux" and auditd.data.syscall == "socket" and process.name : ( "bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish", "perl", "python*", "nc", "ncat", "netcat", "php*", "ruby", "openssl", "awk", "telnet", "lua*", "socat" @@ -88,70 +123,34 @@ sample by host.id, process.pid, process.parent.pid ) and network.direction == "egress" and destination.ip != null and not cidrmatch(destination.ip, "127.0.0.0/8", "169.254.0.0/16", "224.0.0.0/4", "::1")] ''' -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 Reverse Shell via UDP - -Reverse shells over UDP can be exploited by attackers to bypass firewalls and gain unauthorized access to systems. This technique leverages UDP's connectionless nature, making it harder to detect. Adversaries may use scripting languages or network tools to initiate these connections. The detection rule identifies suspicious processes executing network-related syscalls and egress connections, flagging potential reverse shell activity. - -### Possible investigation steps - -- Review the process details such as process.pid, process.parent.pid, and process.name to identify the specific process that triggered the alert and its parent process. -- Examine the command line arguments and environment variables associated with the suspicious process to understand its intended function and origin. -- Check the network connection details, including destination.ip and network.direction, to determine the external entity the process attempted to connect to and assess if it is a known malicious IP or domain. -- Investigate the user account associated with the process to determine if it has been compromised or if there are any signs of unauthorized access. -- Analyze historical logs for any previous instances of similar process executions or network connections to identify patterns or repeated attempts. -- Correlate the alert with other security events or alerts from the same host.id to gather additional context and assess the scope of potential compromise. - -### False positive analysis - -- Legitimate administrative scripts or tools may trigger the rule if they use UDP for valid network operations. Users can create exceptions for specific scripts or processes that are known to perform routine administrative tasks. -- Automated monitoring or network management tools that use UDP for health checks or status updates might be flagged. Identify these tools and exclude their process names or network patterns from the rule. -- Development or testing environments where developers frequently use scripting languages or network tools for legitimate purposes can cause false positives. Consider excluding specific host IDs or process names associated with these environments. -- Custom applications that use UDP for communication, especially if they are developed in-house, may be mistakenly identified. Review these applications and whitelist their process names or network behaviors if they are verified as safe. -- Network scanning or diagnostic tools that use UDP for troubleshooting can be misinterpreted as malicious. Ensure these tools are recognized and excluded from the detection rule if they are part of regular network maintenance activities. - -### Response and remediation - -- Immediately isolate the affected host from the network to prevent further unauthorized access or data exfiltration. -- Terminate any suspicious processes identified by the detection rule, particularly those associated with known reverse shell tools or scripting languages. -- Conduct a forensic analysis of the affected system to identify any additional indicators of compromise, such as unauthorized user accounts or modified system files. -- Review and update firewall rules to block outbound UDP traffic from unauthorized applications or processes, ensuring legitimate traffic is not disrupted. -- Reset credentials for any accounts accessed from the affected host, especially if they have administrative privileges. -- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if other systems may be affected. -- Implement enhanced monitoring and logging for similar suspicious activities, focusing on the execution of network-related syscalls and egress connections from scripting languages or network tools.""" - [[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 = "T1071" name = "Application Layer Protocol" reference = "https://attack.mitre.org/techniques/T1071/" - [rule.threat.tactic] id = "TA0011" name = "Command and Control" reference = "https://attack.mitre.org/tactics/TA0011/" - diff --git a/rules/linux/execution_sus_extraction_or_decrompression_via_funzip.toml b/rules/linux/execution_sus_extraction_or_decrompression_via_funzip.toml index 743df9ba2e4..19461e6ab6b 100644 --- a/rules/linux/execution_sus_extraction_or_decrompression_via_funzip.toml +++ b/rules/linux/execution_sus_extraction_or_decrompression_via_funzip.toml @@ -1,8 +1,8 @@ [metadata] creation_date = "2023/06/26" -integration = ["endpoint", "sentinel_one_cloud_funnel"] +integration = ["endpoint", "sentinel_one_cloud_funnel", "crowdstrike"] maturity = "production" -updated_date = "2025/03/20" +updated_date = "2025/12/19" [rule] author = ["Elastic"] @@ -13,7 +13,12 @@ output from tail can be piped to funzip in order to decompress malicious code be consistent with malware families such as Bundlore. """ from = "now-9m" -index = ["endgame-*", "logs-endpoint.events.process*", "logs-sentinel_one_cloud_funnel.*"] +index = [ + "endgame-*", + "logs-endpoint.events.process*", + "logs-sentinel_one_cloud_funnel.*", + "logs-crowdstrike.fdr*" +] language = "eql" license = "Elastic License v2" name = "Suspicious Content Extracted or Decompressed via Funzip" @@ -88,39 +93,40 @@ tags = [ "Data Source: Elastic Endgame", "Data Source: Elastic Defend", "Data Source: SentinelOne", + "Data Source: Crowdstrike", "Resources: Investigation Guide", ] timestamp_override = "event.ingested" type = "eql" - query = ''' -process where host.os.type == "linux" and event.action in ("exec", "exec_event", "start") and +process where host.os.type == "linux" and event.action in ("exec", "exec_event", "start", "ProcessRollup2") and ((process.args == "tail" and process.args == "-c" and process.args == "funzip")) and not process.args : "/var/log/messages" and -not process.parent.executable : ("/usr/bin/dracut", "/sbin/dracut", "/usr/bin/xargs") and -not (process.parent.name in ("sh", "sudo") and process.parent.command_line : "*nessus_su*") +not ?process.parent.executable : ("/usr/bin/dracut", "/sbin/dracut", "/usr/bin/xargs") and +not (process.parent.name in ("sh", "sudo") and ?process.parent.command_line : "*nessus_su*") ''' - [[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 = "T1027" name = "Obfuscated Files or Information" @@ -131,9 +137,7 @@ id = "T1140" name = "Deobfuscate/Decode Files or Information" reference = "https://attack.mitre.org/techniques/T1140/" - [rule.threat.tactic] id = "TA0005" name = "Defense Evasion" reference = "https://attack.mitre.org/tactics/TA0005/" - diff --git a/rules/linux/execution_suspicious_executable_running_system_commands.toml b/rules/linux/execution_suspicious_executable_running_system_commands.toml index a6130d42877..880ff976e63 100644 --- a/rules/linux/execution_suspicious_executable_running_system_commands.toml +++ b/rules/linux/execution_suspicious_executable_running_system_commands.toml @@ -2,7 +2,7 @@ creation_date = "2023/06/14" integration = ["endpoint"] maturity = "production" -updated_date = "2025/01/15" +updated_date = "2025/12/19" [rule] author = ["Elastic"] @@ -18,6 +18,41 @@ index = ["logs-endpoint.events.*", "endgame-*"] language = "kuery" license = "Elastic License v2" name = "Suspicious System Commands Executed by Previously Unknown Executable" +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + +### Investigating Suspicious System Commands Executed by Previously Unknown Executable + +In Linux environments, system commands are essential for managing processes and configurations. Adversaries exploit this by executing commands via unknown executables in vulnerable directories, aiming to run unauthorized code. The detection rule identifies such anomalies by monitoring command executions from unfamiliar sources, excluding known safe processes, thus highlighting potential threats for further investigation. + +### Possible investigation steps + +- Review the process.executable path to determine if it is located in a commonly abused directory such as /tmp, /dev/shm, or /var/tmp, which may indicate malicious intent. +- Examine the process.args to identify which specific system command was executed (e.g., hostname, id, ifconfig) and assess whether its execution is typical for the system's normal operations. +- Check the process.parent.executable to understand the parent process that initiated the suspicious command execution, ensuring it is not a known safe process or a legitimate system service. +- Investigate the user account associated with the process to determine if it has the necessary permissions and if the activity aligns with the user's typical behavior. +- Correlate the event with other logs or alerts from the same host to identify any patterns or additional suspicious activities that may indicate a broader compromise. +- Assess the risk score and severity in the context of the environment to prioritize the investigation and response efforts accordingly. + +### False positive analysis + +- System maintenance scripts or automated tasks may trigger alerts if they execute common system commands from directories like /tmp or /var/tmp. To handle this, identify these scripts and add their executables to the exclusion list. +- Custom user scripts that perform routine checks using commands like ls or ps might be flagged. Review these scripts and consider adding their paths to the known safe processes to prevent unnecessary alerts. +- Development or testing environments often use temporary executables in directories such as /dev/shm. If these are known and non-threatening, include their paths in the exception list to reduce false positives. +- Some monitoring tools or agents might execute commands like uptime or whoami from non-standard locations. Verify these tools and update the exclusion criteria to include their executables or parent processes. +- In environments with containerized applications, processes running from /run/containerd or similar paths might be incorrectly flagged. Ensure these paths are accounted for in the exclusion settings if they are part of legitimate operations. + +### 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 identified by the alert, especially those originating from unknown executables in commonly abused directories. +- Conduct a thorough review of the affected directories (e.g., /tmp, /var/tmp, /dev/shm) to identify and remove any unauthorized or malicious files or executables. +- Restore any altered system configurations or files from a known good backup to ensure system integrity. +- Implement stricter access controls and permissions on the directories identified in the alert to prevent unauthorized executable placement. +- Monitor the system for any signs of persistence mechanisms, such as cron jobs or startup scripts, and remove any that are unauthorized. +- Escalate the incident to the security operations team for further analysis and to determine if additional systems may be compromised.""" risk_score = 21 rule_id = "e9001ee6-2d00-4d2f-849e-b8b1fb05234c" setup = """## Setup @@ -61,56 +96,26 @@ query = ''' host.os.type:linux and event.category:process and event.action:(exec or exec_event or fork or fork_event) and process.executable:(* and ( /etc/crontab or /bin/* or /boot/* or /dev/shm/* or /etc/cron.*/* or /etc/init.d/* or /etc/rc*.d/* or /etc/update-motd.d/* or - /home/*/.* or /tmp/* or /usr/bin/* or /usr/lib/update-notifier/* or /usr/share/* or /var/tmp/* + /home/*/.* or /tmp/* or /usr/bin/* or /usr/lib/update-notifier/* or /usr/share/* or /var/tmp/* or /sbin/* or /usr/sbin/* or + /usr/local/sbin/* or /usr/local/bin/* or /var/lib/* or /var/run/* or /var/cache/* or /var/log/* or /dev/shm/* or /var/tmp/* ) and not /tmp/go-build*) and process.args:(hostname or id or ifconfig or ls or netstat or ps or pwd or route or top or uptime or whoami) and not (process.name: (apt or dnf or docker or dockerd or dpkg or hostname or id or ls or netstat or ps or pwd or rpm or snap or - snapd or sudo or top or uptime or which or whoami or yum) or + snapd or sudo or top or uptime or which or whoami or yum or sh or bash or ip or dash or find or podman or env or + busybox or aws or timeout or nmcli or dpkg-query or nsenter or pw-cli or node or npm or gnome-calculator or pidof or + steamerrorreporter or ssh or grep or xargs or apt-get or numactl or entrypoint or flatpak-spawn or logger or command or + login or sshpass or docker-compose or whereis or rbd or basename or ifconfig or tar or crictl or su) or process.parent.executable:( /opt/cassandra/bin/cassandra or /opt/nessus/sbin/nessusd or /opt/nessus_agent/sbin/nessus-agent-module or /opt/puppetlabs/puppet/bin/puppet or /opt/puppetlabs/puppet/bin/ruby or /usr/libexec/platform-python or /usr/local/cloudamize/bin/CCAgent or /usr/sbin/sshd or /bin/* or /etc/network/* or /opt/Elastic/* or /opt/TrendMicro* or /opt/aws/* or /opt/eset/* or /opt/rapid7/* or /run/containerd/* or /run/k3s/* or - /snap/* or /tmp/dpkg-licenses* or /tmp/newroot/* or /usr/bin/* or /var/lib/amagent/* or /var/lib/docker/* or /vz/* + /snap/* or /tmp/dpkg-licenses* or /tmp/newroot/* or /usr/bin/* or /var/lib/amagent/* or /var/lib/docker/* or /vz/* or + "/usr/sbin/sshd" or "./runc" or "/opt/gitlab/embedded/bin/ruby" or /opt/saltstack/salt/bin/python* or "/usr/lib/rabbitmq/bin/rabbitmqctl" ) or process.executable:(/run/containerd/* or /srv/snp/docker/* or /tmp/.criu*) ) ''' -note = """## Triage and analysis - -> **Disclaimer**: -> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. - -### Investigating Suspicious System Commands Executed by Previously Unknown Executable - -In Linux environments, system commands are essential for managing processes and configurations. Adversaries exploit this by executing commands via unknown executables in vulnerable directories, aiming to run unauthorized code. The detection rule identifies such anomalies by monitoring command executions from unfamiliar sources, excluding known safe processes, thus highlighting potential threats for further investigation. - -### Possible investigation steps - -- Review the process.executable path to determine if it is located in a commonly abused directory such as /tmp, /dev/shm, or /var/tmp, which may indicate malicious intent. -- Examine the process.args to identify which specific system command was executed (e.g., hostname, id, ifconfig) and assess whether its execution is typical for the system's normal operations. -- Check the process.parent.executable to understand the parent process that initiated the suspicious command execution, ensuring it is not a known safe process or a legitimate system service. -- Investigate the user account associated with the process to determine if it has the necessary permissions and if the activity aligns with the user's typical behavior. -- Correlate the event with other logs or alerts from the same host to identify any patterns or additional suspicious activities that may indicate a broader compromise. -- Assess the risk score and severity in the context of the environment to prioritize the investigation and response efforts accordingly. - -### False positive analysis - -- System maintenance scripts or automated tasks may trigger alerts if they execute common system commands from directories like /tmp or /var/tmp. To handle this, identify these scripts and add their executables to the exclusion list. -- Custom user scripts that perform routine checks using commands like ls or ps might be flagged. Review these scripts and consider adding their paths to the known safe processes to prevent unnecessary alerts. -- Development or testing environments often use temporary executables in directories such as /dev/shm. If these are known and non-threatening, include their paths in the exception list to reduce false positives. -- Some monitoring tools or agents might execute commands like uptime or whoami from non-standard locations. Verify these tools and update the exclusion criteria to include their executables or parent processes. -- In environments with containerized applications, processes running from /run/containerd or similar paths might be incorrectly flagged. Ensure these paths are accounted for in the exclusion settings if they are part of legitimate operations. - -### 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 identified by the alert, especially those originating from unknown executables in commonly abused directories. -- Conduct a thorough review of the affected directories (e.g., /tmp, /var/tmp, /dev/shm) to identify and remove any unauthorized or malicious files or executables. -- Restore any altered system configurations or files from a known good backup to ensure system integrity. -- Implement stricter access controls and permissions on the directories identified in the alert to prevent unauthorized executable placement. -- Monitor the system for any signs of persistence mechanisms, such as cron jobs or startup scripts, and remove any that are unauthorized. -- Escalate the incident to the security operations team for further analysis and to determine if additional systems may be compromised.""" [[rule.threat]] framework = "MITRE ATT&CK" @@ -132,8 +137,8 @@ reference = "https://attack.mitre.org/tactics/TA0002/" [rule.new_terms] field = "new_terms_fields" -value = ["process.parent.executable"] +value = ["process.parent.name"] [[rule.new_terms.history_window_start]] field = "history_window_start" -value = "now-14d" +value = "now-5d" diff --git a/rules/linux/execution_suspicious_mining_process_creation_events.toml b/rules/linux/execution_suspicious_mining_process_creation_events.toml index dae3affd53a..30a5f83b43b 100644 --- a/rules/linux/execution_suspicious_mining_process_creation_events.toml +++ b/rules/linux/execution_suspicious_mining_process_creation_events.toml @@ -2,7 +2,7 @@ creation_date = "2023/02/08" integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"] maturity = "production" -updated_date = "2025/03/20" +updated_date = "2025/12/19" [rule] author = ["Elastic"] @@ -90,28 +90,33 @@ tags = [ ] timestamp_override = "event.ingested" type = "eql" - query = ''' -file where host.os.type == "linux" and event.type == "creation" and event.action : ("creation", "file_create_event") and -file.name : ("aliyun.service", "moneroocean_miner.service", "c3pool_miner.service", "pnsd.service", "apache4.service", "pastebin.service", "xvf.service") +file where host.os.type == "linux" and event.type == "creation" and event.action in ("creation", "file_create_event") and ( + ( + file.name like~ ( + "moneroocean_miner.service", "c3pool_miner.service", "pnsd.service", "apache4.service", "pastebin.service", "xvf.service" + ) + ) or + ( + process.executable like "/usr/local/share/aliyun-assist/*/aliyun-service" and file.name like~ "aliyun.service" + ) +) ''' - [[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/" - diff --git a/rules/linux/execution_suspicious_mkfifo_execution.toml b/rules/linux/execution_suspicious_mkfifo_execution.toml index c44de2d1dc1..185b6999915 100644 --- a/rules/linux/execution_suspicious_mkfifo_execution.toml +++ b/rules/linux/execution_suspicious_mkfifo_execution.toml @@ -1,8 +1,8 @@ [metadata] creation_date = "2025/04/30" -integration = ["endpoint", "crowdstrike"] +integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"] maturity = "production" -updated_date = "2025/10/17" +updated_date = "2025/12/19" [rule] author = ["Elastic"] @@ -13,7 +13,11 @@ rule type, this rule can identify uncommon process command lines that may indica named pipe. """ from = "now-9m" -index = ["logs-endpoint.events.process*", "logs-crowdstrike.fdr*"] +index = [ + "logs-endpoint.events.process*", + "logs-crowdstrike.fdr*", + "logs-sentinel_one_cloud_funnel.*", +] language = "kuery" license = "Elastic License v2" name = "Suspicious Named Pipe Creation" @@ -52,7 +56,7 @@ Named pipes, or FIFOs, are a form of inter-process communication in Linux enviro - Implement additional monitoring on the affected system and network to detect any further attempts to create suspicious named pipes or execute unauthorized commands. - Escalate the incident to the security operations team for further investigation and to determine if the threat is part of a larger attack campaign. """ -risk_score = 21 +risk_score = 73 rule_id = "8167c5ae-3310-439a-8a58-be60f55023d2" setup = """## Setup @@ -79,7 +83,7 @@ For more details on Elastic Agent configuration settings, refer to the [helper g - 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" +severity = "high" tags = [ "Domain: Endpoint", "OS: Linux", @@ -89,13 +93,14 @@ tags = [ "Data Source: Elastic Defend", "Resources: Investigation Guide", "Data Source: Crowdstrike", + "Data Source: SentinelOne", ] timestamp_override = "event.ingested" type = "new_terms" query = ''' -host.os.type:linux and event.category:process and event.type:start and event.action:(exec or ProcessRollup2) and process.name:mkfifo and +host.os.type:linux and event.category:process and event.type:start and event.action:(exec or ProcessRollup2 or start) and process.name:mkfifo and process.parent.name:(bash or csh or dash or fish or ksh or sh or tcsh or zsh) and -process.args:((/dev/shm/* or /tmp/* or /var/tmp/*) and not /*fifo*) +process.args:((/dev/shm/* or /tmp/* or /var/tmp/*) and not (/*fifo* or /var/tmp/dracut* or /var/tmp/portage/* or /tmp/opencode_install*.trace)) ''' [[rule.threat]] @@ -131,8 +136,8 @@ reference = "https://attack.mitre.org/techniques/T1071/" [rule.new_terms] field = "new_terms_fields" -value = ["host.id", "process.command_line"] +value = ["agent.id", "process.command_line"] [[rule.new_terms.history_window_start]] field = "history_window_start" -value = "now-10d" +value = "now-5d" diff --git a/rules/linux/execution_system_binary_file_permission_change.toml b/rules/linux/execution_system_binary_file_permission_change.toml index c43395afbbe..c9804ea2744 100644 --- a/rules/linux/execution_system_binary_file_permission_change.toml +++ b/rules/linux/execution_system_binary_file_permission_change.toml @@ -2,7 +2,7 @@ creation_date = "2025/01/07" integration = ["endpoint"] maturity = "production" -updated_date = "2025/02/04" +updated_date = "2025/12/19" [rule] author = ["Elastic"] @@ -15,6 +15,40 @@ index = ["logs-endpoint.events.process*"] language = "eql" license = "Elastic License v2" name = "System Binary Path File Permission Modification" +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 System Binary Path File Permission Modification + +In Linux environments, system binary paths contain critical executables. Adversaries may exploit these by altering file permissions to execute malicious payloads. The detection rule monitors processes like `chmod` and `chown` in key directories, flagging suspicious permission changes. It excludes benign activities, focusing on unauthorized modifications to prevent potential execution of harmful scripts. + +### Possible investigation steps + +- Review the process details to identify the exact command executed, focusing on the process name and arguments, especially those involving `chmod` or `chown` in critical directories like `/bin`, `/usr/bin`, and `/lib`. +- Examine the parent process information, including the executable path and command line, to determine if the process was initiated by a known or trusted application, excluding those like `udevadm`, `systemd`, or `sudo`. +- Check the user account associated with the process to verify if the action was performed by an authorized user or if there are signs of compromised credentials. +- Investigate the file or directory whose permissions were modified to assess its importance and potential impact, focusing on changes to permissions like `4755`, `755`, or `777`. +- Correlate the event with other security alerts or logs to identify any related suspicious activities, such as unauthorized access attempts or unexpected script executions. +- Review recent changes or updates in the system that might explain the permission modification, ensuring they align with legitimate administrative tasks or software installations. + +### False positive analysis + +- System updates and package installations often involve legitimate permission changes in system binary paths. Users can exclude processes with parent executables located in directories like /var/lib/dpkg/info to reduce noise from these activities. +- Administrative scripts or automation tools may execute chmod or chown commands as part of routine maintenance. Exclude processes with parent names such as udevadm, systemd, or sudo to prevent these from being flagged. +- Container initialization processes might trigger permission changes. Exclude processes with parent command lines like runc init to avoid false positives related to container setups. +- Temporary script executions during software installations can cause permission modifications. Exclude processes with parent arguments matching patterns like /var/tmp/rpm-tmp.* to filter out these benign events. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or execution of malicious payloads. +- Terminate any suspicious processes identified as executing `chmod` or `chown` commands in critical system binary paths. +- Revert any unauthorized file permission changes to their original state to ensure system integrity and prevent execution of malicious scripts. +- Conduct a thorough review of system logs and process execution history to identify any additional unauthorized activities or related threats. +- Escalate the incident to the security operations team for further investigation and to determine if the threat has spread to other systems. +- Implement additional monitoring on the affected system and similar environments to detect any recurrence of unauthorized permission modifications. +- Review and update access controls and permissions policies to minimize the risk of unauthorized modifications in critical system directories.""" references = ["https://blog.exatrack.com/Perfctl-using-portainer-and-new-persistences/"] risk_score = 21 rule_id = "0049cf71-fe13-4d79-b767-f7519921ffb5" @@ -54,55 +88,30 @@ tags = [ ] timestamp_override = "event.ingested" type = "eql" - query = ''' -process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and process.name in ("chmod", "chown") and -process.args like~ ( - "/bin/*", "/usr/bin/*", "/usr/local/bin/*", "/sbin/*", "/usr/sbin/*", "/usr/local/sbin/*", - "/lib/*", "/usr/lib/*", "/lib64/*", "/usr/lib64/*" +process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and process.name == "chmod" and +process.args like ( + "/bin/*", "/usr/bin/*", "/sbin/*", "/usr/sbin/*", "/usr/local/sbin/*", "/lib/*", "/usr/lib/*", "/lib64/*", "/usr/lib64/*" ) and -process.args in ("4755", "755", "000", "777", "444", "-x", "+x") and not ( - process.args in ("/bin/chmod", "/usr/bin/chmod", "/usr/local/bin/chmod") or - process.parent.executable like~ ("/tmp/newroot/*", "/var/lib/dpkg/info/*") or +process.args in ("4755", "755", "000", "777", "444", "+x") and not ( + process.args in ( + "/bin/chmod", "/usr/bin/chmod", "/usr/local/bin/chmod", "/usr/bin/restic", "/usr/local/bin/ack-tool", "/usr/lib/policykit-1/polkit-agent-helper-1", + "/usr/local/bin/deploy-entrypoint.sh", "/usr/local/bin/mc", "/usr/local/bin/start.sh", "/usr/local/sbin/MySQLBackups/mysql_backup.sh", + "/usr/bin/coreutils", "/usr/bin/docker-compose", "/usr/bin/cri-dockerd", "/usr/sbin/mkfs.ext5", "/usr/bin/cyclonedx", "/usr/bin/distro", + "/usr/bin/telegraf", "/usr/bin/jq", "/usr/bin/google-chrome", "/usr/sbin/login_duo" + ) or + process.args like "/usr/lib/omnissa/*" or + process.parent.executable like ( + "/tmp/newroot/*", "/var/lib/dpkg/*", "/usr/libexec/postfix/post-install", "/kaniko/executor", "./install_viewagent.sh", "/bin/make" + ) or + process.parent.args like ( + "/var/lib/dpkg/*", "/usr/lib/postfix/bin/post-install", "/usr/lib/postfix/sbin/post-install", "/usr/libexec/postfix/post-install", + "./install_viewagent.sh", "/usr/lib/omnissa/*", "/var/tmp/rpm-tmp.*" + ) or process.parent.name in ("udevadm", "systemd", "entrypoint", "sudo", "dart") or - process.parent.command_line == "runc init" or - process.parent.args like "/var/tmp/rpm-tmp.*" + process.parent.command_line == "runc init" ) ''' -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 System Binary Path File Permission Modification - -In Linux environments, system binary paths contain critical executables. Adversaries may exploit these by altering file permissions to execute malicious payloads. The detection rule monitors processes like `chmod` and `chown` in key directories, flagging suspicious permission changes. It excludes benign activities, focusing on unauthorized modifications to prevent potential execution of harmful scripts. - -### Possible investigation steps - -- Review the process details to identify the exact command executed, focusing on the process name and arguments, especially those involving `chmod` or `chown` in critical directories like `/bin`, `/usr/bin`, and `/lib`. -- Examine the parent process information, including the executable path and command line, to determine if the process was initiated by a known or trusted application, excluding those like `udevadm`, `systemd`, or `sudo`. -- Check the user account associated with the process to verify if the action was performed by an authorized user or if there are signs of compromised credentials. -- Investigate the file or directory whose permissions were modified to assess its importance and potential impact, focusing on changes to permissions like `4755`, `755`, or `777`. -- Correlate the event with other security alerts or logs to identify any related suspicious activities, such as unauthorized access attempts or unexpected script executions. -- Review recent changes or updates in the system that might explain the permission modification, ensuring they align with legitimate administrative tasks or software installations. - -### False positive analysis - -- System updates and package installations often involve legitimate permission changes in system binary paths. Users can exclude processes with parent executables located in directories like /var/lib/dpkg/info to reduce noise from these activities. -- Administrative scripts or automation tools may execute chmod or chown commands as part of routine maintenance. Exclude processes with parent names such as udevadm, systemd, or sudo to prevent these from being flagged. -- Container initialization processes might trigger permission changes. Exclude processes with parent command lines like runc init to avoid false positives related to container setups. -- Temporary script executions during software installations can cause permission modifications. Exclude processes with parent arguments matching patterns like /var/tmp/rpm-tmp.* to filter out these benign events. - -### Response and remediation - -- Immediately isolate the affected system from the network to prevent further unauthorized access or execution of malicious payloads. -- Terminate any suspicious processes identified as executing `chmod` or `chown` commands in critical system binary paths. -- Revert any unauthorized file permission changes to their original state to ensure system integrity and prevent execution of malicious scripts. -- Conduct a thorough review of system logs and process execution history to identify any additional unauthorized activities or related threats. -- Escalate the incident to the security operations team for further investigation and to determine if the threat has spread to other systems. -- Implement additional monitoring on the affected system and similar environments to detect any recurrence of unauthorized permission modifications. -- Review and update access controls and permissions policies to minimize the risk of unauthorized modifications in critical system directories.""" [[rule.threat]] framework = "MITRE ATT&CK" diff --git a/rules/linux/execution_tc_bpf_filter.toml b/rules/linux/execution_tc_bpf_filter.toml index 63e0623347c..52cc47e2b35 100644 --- a/rules/linux/execution_tc_bpf_filter.toml +++ b/rules/linux/execution_tc_bpf_filter.toml @@ -1,8 +1,8 @@ [metadata] creation_date = "2022/07/11" -integration = ["endpoint", "sentinel_one_cloud_funnel"] +integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_funnel"] maturity = "production" -updated_date = "2025/03/20" +updated_date = "2025/12/19" [rule] author = ["Elastic"] @@ -13,7 +13,14 @@ A threat actor can utilize tc to set a bpf filter on an interface for the purpos This technique is not at all common and should indicate abnormal, suspicious or malicious activity. """ from = "now-9m" -index = ["endgame-*", "logs-endpoint.events.process*", "logs-sentinel_one_cloud_funnel.*"] +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 = "BPF filter applied using TC" @@ -89,36 +96,36 @@ tags = [ "Use Case: Threat Detection", "Tactic: Execution", "Threat: TripleCross", + "Data Source: Auditd Manager", "Data Source: Elastic Endgame", "Data Source: Elastic Defend", "Data Source: SentinelOne", + "Data Source: Crowdstrike", "Resources: Investigation Guide", ] timestamp_override = "event.ingested" type = "eql" - query = ''' -process where host.os.type == "linux" and event.type == "start" and process.executable == "/usr/sbin/tc" and -process.args == "filter" and process.args == "add" and process.args == "bpf" and -not process.parent.executable == "/usr/sbin/libvirtd" +process where host.os.type == "linux" and event.type == "start" and +event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and +process.executable == "/usr/sbin/tc" and process.args == "filter" and process.args == "add" and process.args == "bpf" and +not ?process.parent.executable == "/usr/sbin/libvirtd" ''' - [[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/" - diff --git a/rules/linux/execution_unix_socket_communication.toml b/rules/linux/execution_unix_socket_communication.toml index 04f5a0d5c86..d53549fa472 100644 --- a/rules/linux/execution_unix_socket_communication.toml +++ b/rules/linux/execution_unix_socket_communication.toml @@ -1,8 +1,8 @@ [metadata] creation_date = "2023/09/04" -integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_funnel"] +integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"] maturity = "production" -updated_date = "2025/03/20" +updated_date = "2025/12/19" [rule] author = ["Elastic"] @@ -14,9 +14,7 @@ evade detection. """ from = "now-9m" index = [ - "auditbeat-*", "endgame-*", - "logs-auditd_manager.auditd-*", "logs-crowdstrike.fdr*", "logs-endpoint.events.process*", "logs-sentinel_one_cloud_funnel.*", @@ -69,17 +67,15 @@ tags = [ "Tactic: Execution", "Data Source: Elastic Defend", "Data Source: Elastic Endgame", - "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 + event.action in ("exec", "exec_event", "start", "ProcessRollup2") and ( (process.name in ("nc", "ncat", "netcat", "nc.openbsd") and process.args == "-U" and process.args : ("/usr/local/*", "/run/*", "/var/run/*")) or @@ -89,21 +85,24 @@ process where host.os.type == "linux" and event.type == "start" and ) and not ( process.args == "/var/run/libvirt/libvirt-sock" or - process.parent.name in ("bundle", "ruby", "haproxystatus.sh") + process.parent.name in ("bundle", "ruby", "haproxystatus.sh") or + process.parent.command_line == "sh /docker-entrypoint autoheal" or + process.command_line like "*runtime.autoheal*" or + process.parent.executable == "/app/letsencrypt_service" or + process.parent.args in ("/usr/libexec/netdata/plugins.d/cgroup-name.sh", "/healthcheck") or + ?process.working_directory == "/app" ) ''' - [[rule.threat]] framework = "MITRE ATT&CK" + [[rule.threat.technique]] id = "T1559" name = "Inter-Process Communication" reference = "https://attack.mitre.org/techniques/T1559/" - [rule.threat.tactic] id = "TA0002" name = "Execution" reference = "https://attack.mitre.org/tactics/TA0002/" - diff --git a/rules/linux/execution_unknown_rwx_mem_region_binary_executed.toml b/rules/linux/execution_unknown_rwx_mem_region_binary_executed.toml index a233dec2824..6c81fd12cc5 100644 --- a/rules/linux/execution_unknown_rwx_mem_region_binary_executed.toml +++ b/rules/linux/execution_unknown_rwx_mem_region_binary_executed.toml @@ -2,7 +2,7 @@ creation_date = "2024/03/13" integration = ["auditd_manager"] maturity = "production" -updated_date = "2025/01/24" +updated_date = "2025/12/19" [rule] author = ["Elastic"] @@ -18,6 +18,41 @@ index = ["auditbeat-*", "logs-auditd_manager.auditd-*"] language = "kuery" license = "Elastic License v2" name = "Unknown Execution of Binary with RWX Memory Region" +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 Unknown Execution of Binary with RWX Memory Region + +In Linux environments, the `mprotect()` system call is crucial for managing memory permissions, allowing processes to modify access rights of memory pages. Adversaries exploit this by granting read, write, and execute (RWX) permissions to inject and execute malicious code. The detection rule identifies suspicious RWX memory allocations by monitoring `mprotect()` calls, excluding known safe binaries, thus highlighting potential threats. + +### Possible investigation steps + +- Review the process details associated with the alert, focusing on the process.executable and process.name fields to identify the binary that triggered the alert. +- Investigate the command line arguments and parent process of the suspicious binary to understand its origin and purpose. +- Check the process's hash against known threat intelligence databases to determine if it is associated with any known malicious activity. +- Analyze the network activity of the process to identify any suspicious connections or data exfiltration attempts. +- Examine the user account under which the process is running to assess if it has been compromised or is being used for unauthorized activities. +- Review recent system logs and audit records for any other anomalies or related suspicious activities around the time of the alert. + +### False positive analysis + +- Known safe binaries like Node.js, Java, and Apache may trigger the rule due to their legitimate use of RWX memory regions. These are already excluded in the rule, but additional similar applications might need to be added to the exclusion list. +- Custom or in-house developed applications that require RWX permissions for legitimate functionality can also cause false positives. Identify these applications and add them to the exclusion list to prevent unnecessary alerts. +- Development environments or testing frameworks that dynamically generate and execute code might be flagged. Consider excluding these environments if they are known and trusted within your organization. +- Security tools or monitoring software that perform memory analysis or manipulation could be mistakenly identified. Verify their behavior and exclude them if they are part of your security infrastructure. +- Regularly review and update the exclusion list to ensure it reflects the current environment and any new applications that are introduced. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent potential lateral movement or data exfiltration by the malicious code. +- Terminate the suspicious process identified by the detection rule to halt any ongoing malicious activity. +- Conduct a forensic analysis of the affected system to identify the source and scope of the compromise, focusing on the unknown binary and its origin. +- Remove any malicious binaries or scripts identified during the forensic analysis to prevent further execution. +- Apply security patches and updates to the affected system to address any vulnerabilities that may have been exploited. +- Restore the system from a known good backup if the integrity of the system is in question and ensure all security patches are applied post-restoration. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.""" references = [ "https://man7.org/linux/man-pages/man2/mprotect.2.html", "https://www.elastic.co/security-labs/linux-detection-engineering-with-auditd", @@ -52,65 +87,28 @@ tags = [ ] timestamp_override = "event.ingested" type = "new_terms" - query = ''' event.category:process and host.os.type:linux and auditd.data.syscall:mprotect and auditd.data.a2:7 and not ( process.executable:( "/usr/share/kibana/node/bin/node" or "/usr/share/elasticsearch/jdk/bin/java" or "/usr/sbin/apache2" ) or - process.name:(httpd or java) + process.name:(httpd or java or node or dotnet or github-desktop or code or tenzir or brave or qemu-* or php* or deno) ) ''' -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 Unknown Execution of Binary with RWX Memory Region - -In Linux environments, the `mprotect()` system call is crucial for managing memory permissions, allowing processes to modify access rights of memory pages. Adversaries exploit this by granting read, write, and execute (RWX) permissions to inject and execute malicious code. The detection rule identifies suspicious RWX memory allocations by monitoring `mprotect()` calls, excluding known safe binaries, thus highlighting potential threats. - -### Possible investigation steps - -- Review the process details associated with the alert, focusing on the process.executable and process.name fields to identify the binary that triggered the alert. -- Investigate the command line arguments and parent process of the suspicious binary to understand its origin and purpose. -- Check the process's hash against known threat intelligence databases to determine if it is associated with any known malicious activity. -- Analyze the network activity of the process to identify any suspicious connections or data exfiltration attempts. -- Examine the user account under which the process is running to assess if it has been compromised or is being used for unauthorized activities. -- Review recent system logs and audit records for any other anomalies or related suspicious activities around the time of the alert. - -### False positive analysis - -- Known safe binaries like Node.js, Java, and Apache may trigger the rule due to their legitimate use of RWX memory regions. These are already excluded in the rule, but additional similar applications might need to be added to the exclusion list. -- Custom or in-house developed applications that require RWX permissions for legitimate functionality can also cause false positives. Identify these applications and add them to the exclusion list to prevent unnecessary alerts. -- Development environments or testing frameworks that dynamically generate and execute code might be flagged. Consider excluding these environments if they are known and trusted within your organization. -- Security tools or monitoring software that perform memory analysis or manipulation could be mistakenly identified. Verify their behavior and exclude them if they are part of your security infrastructure. -- Regularly review and update the exclusion list to ensure it reflects the current environment and any new applications that are introduced. - -### Response and remediation - -- Immediately isolate the affected system from the network to prevent potential lateral movement or data exfiltration by the malicious code. -- Terminate the suspicious process identified by the detection rule to halt any ongoing malicious activity. -- Conduct a forensic analysis of the affected system to identify the source and scope of the compromise, focusing on the unknown binary and its origin. -- Remove any malicious binaries or scripts identified during the forensic analysis to prevent further execution. -- Apply security patches and updates to the affected system to address any vulnerabilities that may have been exploited. -- Restore the system from a known good backup if the integrity of the system is in question and ensure all security patches are applied post-restoration. -- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.""" - [[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" @@ -118,9 +116,8 @@ reference = "https://attack.mitre.org/tactics/TA0002/" [rule.new_terms] field = "new_terms_fields" -value = ["process.executable"] +value = ["process.name"] + [[rule.new_terms.history_window_start]] field = "history_window_start" -value = "now-7d" - - +value = "now-5d" diff --git a/rules/linux/execution_unusual_interactive_process_inside_container.toml b/rules/linux/execution_unusual_interactive_process_inside_container.toml index c70bddf41de..e02e0b62995 100644 --- a/rules/linux/execution_unusual_interactive_process_inside_container.toml +++ b/rules/linux/execution_unusual_interactive_process_inside_container.toml @@ -2,20 +2,21 @@ creation_date = "2025/03/12" integration = ["endpoint"] maturity = "production" -updated_date = "2025/03/12" +updated_date = "2025/12/19" [rule] author = ["Elastic"] description = """ -This rule detects when an unusual interactive process is launched inside a container. Interactive processes are typically -run in the foreground and require user input, which is unusual behavior for a containerized environment. This activity -could indicate an attacker attempting to gain access to the container environment or perform malicious actions. +This rule detects when an interactive shell process is launched via an unusual parent processes inside a container. +Interactive processes are typically run in the foreground and require user input, which is unusual behavior for a +containerized environment. This activity could indicate an attacker attempting to gain access to the container +environment or perform malicious actions. """ from = "now-9m" index = ["logs-endpoint.events.process*"] language = "kuery" license = "Elastic License v2" -name = "Unusual Interactive Process Launched in a Container" +name = "Interactive Shell Launched via Unusual Parent Process in a Container" risk_score = 47 rule_id = "7020ff25-76d7-4a7d-b95b-266cf27d70e8" setup = """## Setup @@ -57,7 +58,12 @@ timestamp_override = "event.ingested" type = "new_terms" query = ''' event.category:process and host.os.type:linux and event.type:start and event.action:exec and -process.entry_leader.entry_meta.type:container and process.interactive:true +process.entry_leader.entry_meta.type:container and process.interactive:true and +process.name:(sh or bash or dash or tcsh or csh or zsh or ksh or fish) and +not ( + process.parent.name:(dpkg or runc or tini or frontend or elastic-agent or agentbeat or dpkg-query or ansible-playbook or gpgv or apt or apt-get) or + process.parent.command_line:"runc init" +) ''' [[rule.threat]] @@ -80,8 +86,8 @@ reference = "https://attack.mitre.org/tactics/TA0002/" [rule.new_terms] field = "new_terms_fields" -value = ["process.name"] +value = ["process.parent.name"] [[rule.new_terms.history_window_start]] field = "history_window_start" -value = "now-14d" +value = "now-5d" diff --git a/rules/linux/execution_unusual_path_invocation_from_command_line.toml b/rules/linux/execution_unusual_path_invocation_from_command_line.toml index 335ab5b5acd..7c4599b99b1 100644 --- a/rules/linux/execution_unusual_path_invocation_from_command_line.toml +++ b/rules/linux/execution_unusual_path_invocation_from_command_line.toml @@ -2,7 +2,7 @@ creation_date = "2023/06/14" integration = ["endpoint"] maturity = "production" -updated_date = "2025/09/29" +updated_date = "2025/12/19" [rule] author = ["Elastic"] @@ -64,9 +64,13 @@ not ( process.command_line:(*_PATH=* or *PYTHONPATH=* or sh*/run/motd.dynamic.new) or process.parent.executable:( "/opt/puppetlabs/puppet/bin/puppet" or /var/lib/docker/overlay2/* or /vz/root/*/dovecot or - "/usr/libexec/dovecot/auth" or /home/*/.local/share/containers/* or /vz/root/*/dovecot/auth + "/usr/libexec/dovecot/auth" or /home/*/.local/share/containers/* or /vz/root/*/dovecot/auth or + "/usr/local/bin/ansible-playbook" or "/opt/puppetlabs/puppet/bin/ruby" or /tmp/CVU_19_resource_*/exectask or + "/opt/ds_agent/ds_agent" or "/usr/lib/systemd/systemd" or "/opt/TrendMicro/vls_agent/vls_agent" or + "/opt/Tanium/TaniumClient/TaniumCX" ) or - process.parent.command_line:"runc init" + process.parent.command_line:"runc init" or + process.parent.name:(gmake or sshd or sudo or make or ninja or ninja-build or steam or sshd-session) ) ''' note = """## Triage and analysis @@ -138,8 +142,8 @@ reference = "https://attack.mitre.org/tactics/TA0005/" [rule.new_terms] field = "new_terms_fields" -value = ["process.parent.executable"] +value = ["process.parent.name"] [[rule.new_terms.history_window_start]] field = "history_window_start" -value = "now-14d" +value = "now-7d" diff --git a/rules/linux/execution_unusual_pkexec_execution.toml b/rules/linux/execution_unusual_pkexec_execution.toml index 28e05736054..0b613bb5b67 100644 --- a/rules/linux/execution_unusual_pkexec_execution.toml +++ b/rules/linux/execution_unusual_pkexec_execution.toml @@ -1,8 +1,8 @@ [metadata] creation_date = "2025/01/16" -integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"] +integration = ["endpoint", "sentinel_one_cloud_funnel"] maturity = "production" -updated_date = "2025/03/20" +updated_date = "2025/12/19" [rule] author = ["Elastic"] @@ -15,7 +15,6 @@ from = "now-9m" index = [ "logs-endpoint.events.process*", "endgame-*", - "logs-crowdstrike.fdr*", "logs-sentinel_one_cloud_funnel.*", ] language = "kuery" @@ -56,7 +55,7 @@ note = """## Triage and analysis - Conduct a thorough scan of the affected system for additional indicators of compromise or persistence mechanisms that may have been deployed. - Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected. - Update and enhance monitoring rules to detect similar `pkexec` misuse attempts in the future, ensuring comprehensive coverage of shell processes and privilege escalation activities.""" -risk_score = 21 +risk_score = 73 rule_id = "3ca81a95-d5af-4b77-b0ad-b02bc746f640" setup = """## Setup @@ -94,7 +93,7 @@ Auditbeat is a lightweight shipper that you can install on your servers to audit - To run Auditbeat on Kubernetes follow the setup instructions in the [helper guide](https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-kubernetes.html). - For complete “Setup and Run Auditbeat” information refer to the [helper guide](https://www.elastic.co/guide/en/beats/auditbeat/current/setting-up-and-running.html). """ -severity = "low" +severity = "high" tags = [ "Domain: Endpoint", "OS: Linux", @@ -103,40 +102,46 @@ tags = [ "Tactic: Persistence", "Data Source: Elastic Endgame", "Data Source: Elastic Defend", - "Data Source: Crowdstrike", "Data Source: SentinelOne", "Resources: Investigation Guide", ] timestamp_override = "event.ingested" type = "new_terms" - query = ''' event.category:process and host.os.type:linux and event.type:start and event.action:(exec or exec_event or start or ProcessRollup2) and process.name:pkexec and -process.args:pkexec and process.parent.name:(bash or dash or sh or tcsh or csh or zsh or ksh or fish) +process.args:pkexec and process.parent.name:(bash or dash or sh or tcsh or csh or zsh or ksh or fish) and +not ( + process.args:( + "/usr/libexec/gvfsd-admin" or "udevadm" or "/opt/forticlient/stop-forticlient.sh" or "/usr/bin/gparted" or + "dpkg" or "/usr/sbin/gparted" or "input-remapper-control" or "/usr/lib/ubuntu-release-upgrader/do-partial-upgrade" + ) or + process.parent.command_line:*/home/*/.claude/shell-snapshots/* or + process.parent.args:"/usr/bin/timeshift-launcher" +) ''' - [[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.tactic] id = "TA0002" name = "Execution" reference = "https://attack.mitre.org/tactics/TA0002/" + [[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.tactic] id = "TA0003" name = "Persistence" @@ -145,8 +150,7 @@ reference = "https://attack.mitre.org/tactics/TA0003/" [rule.new_terms] field = "new_terms_fields" value = ["process.parent.command_line"] + [[rule.new_terms.history_window_start]] field = "history_window_start" -value = "now-14d" - - +value = "now-5d"