diff --git a/rules/linux/execution_abnormal_process_id_file_created.toml b/rules/linux/execution_abnormal_process_id_file_created.toml index 8a26cef9b..6310d47ea 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 aa680fc48..f32d2b566 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 9378a392c..ecf137688 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 be8c06d5c..e30294628 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 086dcc36c..2539459c1 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 1e15219c5..4f987d0a0 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 6221e571c..d2a3a87c9 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,60 +16,6 @@ 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 -rule_id = "09bc6c90-7501-494d-b015-5d988dc3f233" -setup = """## Setup - -This rule requires data coming in from Elastic Defend. - -### Elastic Defend Integration Setup -Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. - -#### Prerequisite Requirements: -- Fleet is required for Elastic Defend. -- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html). - -#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System: -- Go to the Kibana home page and click "Add integrations". -- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. -- Click "Add Elastic Defend". -- Configure the integration name and optionally add a description. -- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". -- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. [Helper guide](https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html). -- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" -- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. -For more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html). -- Click "Save and Continue". -- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. -For more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html). -""" -severity = "medium" -tags = [ - "Domain: Endpoint", - "OS: Linux", - "Use Case: Threat Detection", - "Tactic: Execution", - "Data Source: Elastic Defend", - "Resources: Investigation Guide", -] -type = "eql" -query = ''' -sequence by host.id, user.id with maxspan=1m - [file where host.os.type == "linux" and event.action == "creation" and - process.name in ("curl", "wget", "fetch", "ftp", "sftp", "scp", "rsync", "ld") and - file.path : ("/dev/shm/*", "/run/shm/*", "/tmp/*", "/var/tmp/*", - "/run/*", "/var/run/*", "/var/www/*", "/proc/*/fd/*")] by file.name - [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and - process.parent.name in ("bash", "dash", "ash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and - not process.parent.executable like ( - "/tmp/VeeamApp*", "/tmp/rajh/spack-stage/*", "plz-out/bin/vault/bridge/test/e2e/base/bridge-dev", - "/usr/bin/ranlib", "/usr/bin/ar", "plz-out/bin/vault/bridge/test/e2e/base/local-k8s" - )] by process.name - [file where host.os.type == "linux" and event.action == "deletion" and - file.path : ( - "/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**: @@ -105,6 +51,60 @@ In Linux environments, temporary directories like `/tmp` and `/var/tmp` are ofte - 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 + +This rule requires data coming in from Elastic Defend. + +### Elastic Defend Integration Setup +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + +#### Prerequisite Requirements: +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html). + +#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System: +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. [Helper guide](https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html). +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html). +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html). +""" +severity = "high" +tags = [ + "Domain: Endpoint", + "OS: Linux", + "Use Case: Threat Detection", + "Tactic: Execution", + "Data Source: Elastic Defend", + "Resources: Investigation Guide", +] +type = "eql" +query = ''' +sequence by host.id, user.id with maxspan=1m + [file where host.os.type == "linux" and event.action == "creation" and + process.name in ("curl", "wget", "fetch", "ftp", "sftp", "scp", "rsync", "ld") and + file.path : ("/dev/shm/*", "/run/shm/*", "/tmp/*", "/var/tmp/*", + "/run/*", "/var/run/*", "/var/www/*", "/proc/*/fd/*")] by file.name + [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and + process.parent.name in ("bash", "dash", "ash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and + not process.parent.executable like ( + "/tmp/VeeamApp*", "/tmp/rajh/spack-stage/*", "plz-out/bin/vault/bridge/test/e2e/base/bridge-dev", + "/usr/bin/ranlib", "/usr/bin/ar", "plz-out/bin/vault/bridge/test/e2e/base/local-k8s" + )] by process.name + [file where host.os.type == "linux" and event.action == "deletion" and + file.path : ( + "/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 +''' [[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 04e871076..18431eba5 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 a16353723..3036568b3 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 84929414f..6befd6eb9 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 5e3f95e47..b0d37287c 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 821967f88..7e6e8f09b 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 39958a99e..b094488da 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 18f1cdda7..42342789d 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 7c1e4547b..fdf098633 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 ec83824f0..69ded33a6 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 f1e7ef3bd..b89fc96dc 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 2c230e7fb..1f0801f42 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 959180bad..c8eff1779 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 a045f2f86..5f6a94427 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 23b306e43..1cecb6685 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 30f4cebcb..b57a9c5eb 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 7960e2315..71f693444 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 cb4b21a61..b1d6944dd 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,60 +16,6 @@ index = ["logs-endpoint.events.network*", "logs-endpoint.events.process*"] language = "eql" license = "Elastic License v2" name = "Potential Reverse Shell via Child" -references = [ - "https://github.com/swisskyrepo/PayloadsAllTheThings/blob/master/Methodology%20and%20Resources/Reverse%20Shell%20Cheatsheet.md", -] -risk_score = 47 -rule_id = "2138bb70-5a5e-42fd-be5e-b38edf6a6777" -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 to select "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" -- Enter a name for the agent policy in New agent policy name. If other agent policies already exist, you can click the Existing hosts tab and select an existing policy instead. -For more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html). -- Click Save and Continue. -- To complete the integration, select Add Elastic Agent to your hosts and continue to the next section to install the Elastic Agent on your hosts. -For more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html). -""" -severity = "medium" -tags = [ - "Domain: Endpoint", - "OS: Linux", - "Use Case: Threat Detection", - "Tactic: Execution", - "Data Source: Elastic Defend", - "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 - event.action in ("connection_attempted", "connection_accepted") and - process.name : ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish", "socat") 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")] - [process where event.type == "start" and host.os.type == "linux" and event.action == "exec" and - process.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and ( - (process.args : ("-i", "-l")) or (process.parent.name == "socat" and process.parent.args : "*exec*") - )] -''' note = """## Triage and analysis > **Disclaimer**: @@ -105,35 +51,87 @@ Reverse shells are a technique where attackers gain remote access to a system by - 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 = 73 +rule_id = "2138bb70-5a5e-42fd-be5e-b38edf6a6777" +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 to select "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in New agent policy name. If other agent policies already exist, you can click the Existing hosts tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html). +- Click Save and Continue. +- To complete the integration, select Add Elastic Agent to your hosts and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html). +""" +severity = "high" +tags = [ + "Domain: Endpoint", + "OS: Linux", + "Use Case: Threat Detection", + "Tactic: Execution", + "Data Source: Elastic Defend", + "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 + event.action in ("connection_attempted", "connection_accepted") and + process.name : ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish", "socat") 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")] + [process where event.type == "start" and host.os.type == "linux" and event.action == "exec" and + process.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and ( + (process.args : ("-i", "-l")) or (process.parent.name == "socat" and process.parent.args : "*exec*") + )] +''' + [[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 b45e10e26..ca489d0cc 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 4640cc46c..26b891475 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,75 +16,6 @@ index = ["logs-endpoint.events.network*", "logs-endpoint.events.process*"] language = "eql" license = "Elastic License v2" name = "Potential Reverse Shell via Suspicious Child Process" -references = [ - "https://github.com/swisskyrepo/PayloadsAllTheThings/blob/master/Methodology%20and%20Resources/Reverse%20Shell%20Cheatsheet.md", -] -risk_score = 47 -rule_id = "76e4d92b-61c1-4a95-ab61-5fd94179a1ee" -setup = """## Setup - -This rule requires data coming in from Elastic Defend. - -### Elastic Defend Integration Setup -Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. - -#### Prerequisite Requirements: -- Fleet is required for Elastic Defend. -- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html). - -#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System: -- Go to the Kibana home page and click "Add integrations". -- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. -- Click "Add Elastic Defend". -- Configure the integration name and optionally add a description. -- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". -- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. [Helper guide](https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html). -- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" -- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. -For more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html). -- Click "Save and Continue". -- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. -For more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html). -""" -severity = "medium" -tags = [ - "Domain: Endpoint", - "OS: Linux", - "Use Case: Threat Detection", - "Tactic: Execution", - "Data Source: Elastic Defend", - "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 ( - (process.name : "python*" and process.args : "-c" and process.args : ( - "*import*pty*spawn*", "*import*subprocess*call*" - )) or - (process.name : "perl*" and process.args : "-e" and process.args : "*socket*" and process.args : ( - "*exec*", "*system*" - )) or - (process.name : "ruby*" and process.args : ("-e", "-rsocket") and process.args : ( - "*TCPSocket.new*", "*TCPSocket.open*" - )) or - (process.name : "lua*" and process.args : "-e" and process.args : "*socket.tcp*" and process.args : ( - "*io.popen*", "*os.execute*" - )) 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) - ) and process.parent.name : ( - "bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish", "python*", "php*", "perl", "ruby", "lua*", - "openssl", "nc", "netcat", "ncat", "telnet", "awk")] - [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 - 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**: @@ -120,35 +51,100 @@ Reverse shells are a common technique used by attackers to gain remote access to - 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 = 73 +rule_id = "76e4d92b-61c1-4a95-ab61-5fd94179a1ee" +setup = """## Setup +This rule requires data coming in from Elastic Defend. + +### Elastic Defend Integration Setup +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + +#### Prerequisite Requirements: +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html). + +#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System: +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. [Helper guide](https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html). +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html). +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html). +""" +severity = "high" +tags = [ + "Domain: Endpoint", + "OS: Linux", + "Use Case: Threat Detection", + "Tactic: Execution", + "Data Source: Elastic Defend", + "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 ( + (process.name : "python*" and process.args : "-c" and process.args : ( + "*import*pty*spawn*", "*import*subprocess*call*" + )) or + (process.name : "perl*" and process.args : "-e" and process.args : "*socket*" and process.args : ( + "*exec*", "*system*" + )) or + (process.name : "ruby*" and process.args : ("-e", "-rsocket") and process.args : ( + "*TCPSocket.new*", "*TCPSocket.open*" + )) or + (process.name : "lua*" and process.args : "-e" and process.args : "*socket.tcp*" and process.args : ( + "*io.popen*", "*os.execute*" + )) 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 : ("nc", "ncat", "netcat") and process.args == "-e" and process.args_count >= 3 and + not process.args == "-z") + ) and process.parent.name : ( + "bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish", "python*", "php*", "perl", "ruby", "lua*", + "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*", "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")] +''' [[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 c75cdf995..8e7503976 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 a3e205791..ed5b8943e 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,67 +17,6 @@ index = ["logs-endpoint.events.network*", "logs-endpoint.events.process*"] language = "eql" license = "Elastic License v2" name = "Potential Reverse Shell via Suspicious Binary" -references = [ - "https://github.com/swisskyrepo/PayloadsAllTheThings/blob/master/Methodology%20and%20Resources/Reverse%20Shell%20Cheatsheet.md", -] -risk_score = 47 -rule_id = "fa3a59dc-33c3-43bf-80a9-e8437a922c7f" -setup = """## Setup - -This rule requires data coming in from Elastic Defend. - -### Elastic Defend Integration Setup -Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. - -#### Prerequisite Requirements: -- Fleet is required for Elastic Defend. -- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html). - -#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System: -- Go to the Kibana home page and click "Add integrations". -- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. -- Click "Add Elastic Defend". -- Configure the integration name and optionally add a description. -- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". -- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. [Helper guide](https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html). -- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" -- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. -For more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html). -- Click "Save and Continue". -- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. -For more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html). -""" -severity = "medium" -tags = [ - "Domain: Endpoint", - "OS: Linux", - "Use Case: Threat Detection", - "Tactic: Execution", - "Data Source: Elastic Defend", - "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 - process.executable : ( - "./*", "/tmp/*", "/var/tmp/*", "/var/www/*", "/dev/shm/*", "/etc/init.d/*", "/etc/rc*.d/*", - "/etc/crontab", "/etc/cron.*", "/etc/update-motd.d/*", "/usr/lib/update-notifier/*", - "/boot/*", "/srv/*", "/run/*", "/root/*", "/etc/rc.local" - ) and - process.parent.name : ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and not - process.name : ("curl", "wget", "ping", "apt", "dpkg", "yum", "rpm", "dnf", "dockerd") ] -[ network where host.os.type == "linux" and event.type == "start" and event.action in ("connection_attempted", "connection_accepted") and - process.executable : ( - "./*", "/tmp/*", "/var/tmp/*", "/var/www/*", "/dev/shm/*", "/etc/init.d/*", "/etc/rc*.d/*", - "/etc/crontab", "/etc/cron.*", "/etc/update-motd.d/*", "/usr/lib/update-notifier/*", - "/boot/*", "/srv/*", "/run/*", "/root/*", "/etc/rc.local" - ) and destination.ip != null and destination.ip != "127.0.0.1" and destination.ip != "::1" ] -[ process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and - 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**: @@ -113,35 +52,94 @@ Reverse shells are a common technique used by attackers to gain persistent acces - 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 = 73 +rule_id = "fa3a59dc-33c3-43bf-80a9-e8437a922c7f" +setup = """## Setup +This rule requires data coming in from Elastic Defend. + +### Elastic Defend Integration Setup +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + +#### Prerequisite Requirements: +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html). + +#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System: +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. [Helper guide](https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html). +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html). +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html). +""" +severity = "high" +tags = [ + "Domain: Endpoint", + "OS: Linux", + "Use Case: Threat Detection", + "Tactic: Execution", + "Data Source: Elastic Defend", + "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 + process.executable : ( + "./*", "/tmp/*", "/var/tmp/*", "/var/www/*", "/dev/shm/*", "/etc/init.d/*", "/etc/rc*.d/*", + "/etc/crontab", "/etc/cron.*", "/etc/update-motd.d/*", "/usr/lib/update-notifier/*", + "/boot/*", "/srv/*", "/run/*", "/root/*", "/etc/rc.local" + ) and + process.parent.name : ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and not + process.name : ("curl", "wget", "ping", "apt", "dpkg", "yum", "rpm", "dnf", "dockerd") ] +[ network where host.os.type == "linux" and event.type == "start" and event.action in ("connection_attempted", "connection_accepted") and + process.executable : ( + "./*", "/tmp/*", "/var/tmp/*", "/var/www/*", "/dev/shm/*", "/etc/init.d/*", "/etc/rc*.d/*", + "/etc/crontab", "/etc/cron.*", "/etc/update-motd.d/*", "/usr/lib/update-notifier/*", + "/boot/*", "/srv/*", "/run/*", "/root/*", "/etc/rc.local" + ) and destination.ip != null and destination.ip != "127.0.0.1" and destination.ip != "::1" ] +[ process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and + process.name : ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and + process.parent.name : ("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_tcp_cli_utility_linux.toml b/rules/linux/execution_shell_via_tcp_cli_utility_linux.toml index 3a93c51c7..c8be644cd 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,58 +16,6 @@ index = ["logs-endpoint.events.network*", "logs-endpoint.events.process*"] language = "eql" license = "Elastic License v2" name = "Potential Reverse Shell" -references = [ - "https://github.com/swisskyrepo/PayloadsAllTheThings/blob/master/Methodology%20and%20Resources/Reverse%20Shell%20Cheatsheet.md", -] -risk_score = 47 -rule_id = "48b3d2e3-f4e8-41e6-95e6-9b2091228db3" -setup = """## Setup - -This rule requires data coming in from Elastic Defend. - -### Elastic Defend Integration Setup -Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. - -#### Prerequisite Requirements: -- Fleet is required for Elastic Defend. -- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html). - -#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System: -- Go to the Kibana home page and click "Add integrations". -- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. -- Click "Add Elastic Defend". -- Configure the integration name and optionally add a description. -- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". -- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. [Helper guide](https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html). -- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" -- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. -For more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html). -- Click "Save and Continue". -- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. -For more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html). -""" -severity = "medium" -tags = [ - "Domain: Endpoint", - "OS: Linux", - "Use Case: Threat Detection", - "Tactic: Execution", - "Data Source: Elastic Defend", - "Resources: Investigation Guide", -] -type = "eql" - -query = ''' -sequence by host.id with maxspan=5s - [network where event.type == "start" and host.os.type == "linux" and - event.action in ("connection_attempted", "connection_accepted") and - process.name : ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish", "socat") 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")] by process.entity_id - [process where event.type == "start" and host.os.type == "linux" and event.action in ("exec", "fork") and - process.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and ( - (process.args : ("-i", "-l")) or (process.parent.name == "socat" and process.parent.args : "*exec*") - )] by process.parent.entity_id -''' note = """## Triage and analysis > **Disclaimer**: @@ -103,35 +51,85 @@ Reverse shells are tools that adversaries use to gain remote access to a system - 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 = 73 +rule_id = "48b3d2e3-f4e8-41e6-95e6-9b2091228db3" +setup = """## Setup +This rule requires data coming in from Elastic Defend. + +### Elastic Defend Integration Setup +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + +#### Prerequisite Requirements: +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html). + +#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System: +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. [Helper guide](https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html). +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html). +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html). +""" +severity = "high" +tags = [ + "Domain: Endpoint", + "OS: Linux", + "Use Case: Threat Detection", + "Tactic: Execution", + "Data Source: Elastic Defend", + "Resources: Investigation Guide", +] +type = "eql" +query = ''' +sequence by host.id with maxspan=5s + [network where event.type == "start" and host.os.type == "linux" and + event.action in ("connection_attempted", "connection_accepted") and + process.name : ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish", "socat") 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")] by process.entity_id + [process where event.type == "start" and host.os.type == "linux" and event.action in ("exec", "fork") and + process.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and ( + (process.args : ("-i", "-l")) or (process.parent.name == "socat" and process.parent.args : "*exec*") + )] by process.parent.entity_id +''' [[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 99ad76268..35f575a8b 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 743df9ba2..19461e6ab 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 a6130d428..880ff976e 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 dae3affd5..30a5f83b4 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 c44de2d1d..185b69999 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 c43395afb..c9804ea27 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 63e062334..52cc47e2b 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 04f5a0d5c..d53549fa4 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 a233dec28..6c81fd12c 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,49 +18,6 @@ index = ["auditbeat-*", "logs-auditd_manager.auditd-*"] language = "kuery" license = "Elastic License v2" name = "Unknown Execution of Binary with RWX Memory Region" -references = [ - "https://man7.org/linux/man-pages/man2/mprotect.2.html", - "https://www.elastic.co/security-labs/linux-detection-engineering-with-auditd", -] -risk_score = 47 -rule_id = "23bcd283-2bc0-4db2-81d4-273fc051e5c0" -setup = """## Setup - -This rule requires the use of the `auditd_manager` integration. `Auditd_manager` is a tool designed to simplify and enhance the management of the audit subsystem in Linux systems. It provides a user-friendly interface and automation capabilities for configuring and monitoring system auditing through the auditd daemon. With `auditd_manager`, administrators can easily define audit rules, track system events, and generate comprehensive audit reports, improving overall security and compliance in the system. The following steps should be executed in order to install and deploy `auditd_manager` on a Linux system. -``` -Kibana --> -Management --> -Integrations --> -Auditd Manager --> -Add Auditd Manager -``` -`Auditd_manager` subscribes to the kernel and receives events as they occur without any additional configuration. However, if more advanced configuration is required to detect specific behavior, audit rules can be added to the integration in either the "audit rules" configuration box or the "auditd rule files" box by specifying a file to read the audit rules from. -For this detection rule to trigger, the following additional audit rules are required to be added to the integration: -``` --a always,exit -F arch=b64 -S mprotect -``` -Add the newly installed `auditd manager` to an agent policy, and deploy the agent on a Linux system from which auditd log files are desirable. -""" -severity = "medium" -tags = [ - "Domain: Endpoint", - "OS: Linux", - "Use Case: Threat Detection", - "Tactic: Execution", - "Data Source: Auditd Manager", - "Resources: Investigation Guide", -] -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) -) -''' note = """## Triage and analysis > **Disclaimer**: @@ -96,21 +53,62 @@ In Linux environments, the `mprotect()` system call is crucial for managing memo - 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", +] +risk_score = 47 +rule_id = "23bcd283-2bc0-4db2-81d4-273fc051e5c0" +setup = """## Setup +This rule requires the use of the `auditd_manager` integration. `Auditd_manager` is a tool designed to simplify and enhance the management of the audit subsystem in Linux systems. It provides a user-friendly interface and automation capabilities for configuring and monitoring system auditing through the auditd daemon. With `auditd_manager`, administrators can easily define audit rules, track system events, and generate comprehensive audit reports, improving overall security and compliance in the system. The following steps should be executed in order to install and deploy `auditd_manager` on a Linux system. +``` +Kibana --> +Management --> +Integrations --> +Auditd Manager --> +Add Auditd Manager +``` +`Auditd_manager` subscribes to the kernel and receives events as they occur without any additional configuration. However, if more advanced configuration is required to detect specific behavior, audit rules can be added to the integration in either the "audit rules" configuration box or the "auditd rule files" box by specifying a file to read the audit rules from. +For this detection rule to trigger, the following additional audit rules are required to be added to the integration: +``` +-a always,exit -F arch=b64 -S mprotect +``` +Add the newly installed `auditd manager` to an agent policy, and deploy the agent on a Linux system from which auditd log files are desirable. +""" +severity = "medium" +tags = [ + "Domain: Endpoint", + "OS: Linux", + "Use Case: Threat Detection", + "Tactic: Execution", + "Data Source: Auditd Manager", + "Resources: Investigation Guide", +] +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 or node or dotnet or github-desktop or code or tenzir or brave or qemu-* or php* or deno) +) +''' [[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 c70bddf41..e02e0b629 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 335ab5b5a..7c4599b99 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 28e057360..0b613bb5b 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"