diff --git a/rules/linux/discovery_docker_socket_discovery.toml b/rules/linux/discovery_docker_socket_discovery.toml index 1cd511a6daf..baefc1b935e 100644 --- a/rules/linux/discovery_docker_socket_discovery.toml +++ b/rules/linux/discovery_docker_socket_discovery.toml @@ -2,7 +2,7 @@ creation_date = "2025/03/04" integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_funnel"] maturity = "production" -updated_date = "2025/04/07" +updated_date = "2025/12/18" [rule] author = ["Elastic"] @@ -61,7 +61,7 @@ Docker sockets facilitate communication between the Docker client and daemon, en - Escalate the incident to the security operations team for further investigation and to determine if additional hosts or systems are affected. - Implement enhanced monitoring and logging for Docker socket interactions to detect and respond to similar threats more quickly in the future. """ -risk_score = 21 +risk_score = 47 rule_id = "dd983e79-22e8-44d1-9173-d57dba514cac" setup = """## Setup @@ -88,7 +88,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", "Domain: Container", @@ -104,25 +104,27 @@ 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", "executed", "process_started") and process.name in ("curl", "socat", "nc", "netcat", "ncat", "nc.traditional") and -process.command_line like ("*/var/run/docker.sock*", "*/run/docker.sock*") +process.command_line like ("*/var/run/docker.sock*", "*/run/docker.sock*") and +process.parent.executable != null and +not ( + process.parent.executable in ("/usr/sbin/sshd", "/www/server/panel/BT-Panel") or + process.parent.args in ("/usr/libexec/netdata/plugins.d/cgroup-name.sh", "/docker-entrypoint") +) ''' - [[rule.threat]] framework = "MITRE ATT&CK" + [[rule.threat.technique]] id = "T1613" name = "Container and Resource Discovery" reference = "https://attack.mitre.org/techniques/T1613/" - [rule.threat.tactic] id = "TA0007" name = "Discovery" reference = "https://attack.mitre.org/tactics/TA0007/" - diff --git a/rules/linux/discovery_dynamic_linker_via_od.toml b/rules/linux/discovery_dynamic_linker_via_od.toml index dc05592fcc1..40420f501f9 100644 --- a/rules/linux/discovery_dynamic_linker_via_od.toml +++ b/rules/linux/discovery_dynamic_linker_via_od.toml @@ -2,7 +2,7 @@ creation_date = "2024/02/01" integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_funnel"] maturity = "production" -updated_date = "2025/03/20" +updated_date = "2025/12/18" [rule] author = ["Elastic"] @@ -58,7 +58,7 @@ The dynamic linker in Linux environments is crucial for loading shared libraries - Escalate the incident to the security operations team for further analysis and to determine if additional systems are affected or if there is a broader threat campaign. - Update detection and monitoring systems to enhance visibility and alerting for similar suspicious activities involving the `od` utility and critical system files.""" references = ["https://github.com/arget13/DDexec"] -risk_score = 21 +risk_score = 73 rule_id = "0369e8a6-0fa7-4e7a-961a-53180a4c966e" setup = """## Setup @@ -86,7 +86,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", @@ -101,7 +101,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", "executed", "process_started") and process.name == "od" and process.args in ( @@ -110,17 +109,15 @@ process where host.os.type == "linux" and event.type == "start" and event.action ) ''' - [[rule.threat]] framework = "MITRE ATT&CK" + [[rule.threat.technique]] id = "T1057" name = "Process Discovery" reference = "https://attack.mitre.org/techniques/T1057/" - [rule.threat.tactic] id = "TA0007" name = "Discovery" reference = "https://attack.mitre.org/tactics/TA0007/" - diff --git a/rules/linux/discovery_esxi_software_via_find.toml b/rules/linux/discovery_esxi_software_via_find.toml index aebf5e78d38..a2e43bc8e59 100644 --- a/rules/linux/discovery_esxi_software_via_find.toml +++ b/rules/linux/discovery_esxi_software_via_find.toml @@ -1,8 +1,8 @@ [metadata] creation_date = "2023/04/11" -integration = ["endpoint", "auditd_manager", "sentinel_one_cloud_funnel"] +integration = ["endpoint", "auditd_manager", "sentinel_one_cloud_funnel", "crowdstrike"] maturity = "production" -updated_date = "2025/03/20" +updated_date = "2025/12/18" [rule] author = ["Elastic"] @@ -19,6 +19,7 @@ index = [ "logs-auditd_manager.auditd-*", "logs-endpoint.events.process*", "logs-sentinel_one_cloud_funnel.*", + "logs-crowdstrike.fdr*", ] language = "eql" license = "Elastic License v2" @@ -97,29 +98,27 @@ tags = [ "Data Source: Elastic Endgame", "Data Source: Auditd Manager", "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 - event.action in ("exec", "exec_event", "start", "executed", "process_started") and - process.name == "find" and process.args : ("/etc/vmware/*", "/usr/lib/vmware/*", "/vmfs/*") and - not process.parent.executable == "/usr/lib/vmware/viewagent/bin/uninstall_viewagent.sh" +event.action in ("exec", "exec_event", "start", "executed", "process_started", "ProcessRollup2") and +process.name == "find" and process.args like ("/etc/vmware/*", "/usr/lib/vmware/*", "/vmfs/*") and +not ?process.parent.executable == "/usr/lib/vmware/viewagent/bin/uninstall_viewagent.sh" ''' - [[rule.threat]] framework = "MITRE ATT&CK" + [[rule.threat.technique]] id = "T1518" name = "Software Discovery" reference = "https://attack.mitre.org/techniques/T1518/" - [rule.threat.tactic] id = "TA0007" name = "Discovery" reference = "https://attack.mitre.org/tactics/TA0007/" - diff --git a/rules/linux/discovery_esxi_software_via_grep.toml b/rules/linux/discovery_esxi_software_via_grep.toml index d15c6a2b9f5..af3f9c6de0c 100644 --- a/rules/linux/discovery_esxi_software_via_grep.toml +++ b/rules/linux/discovery_esxi_software_via_grep.toml @@ -1,8 +1,8 @@ [metadata] creation_date = "2023/04/11" -integration = ["endpoint", "auditd_manager", "sentinel_one_cloud_funnel"] +integration = ["endpoint", "auditd_manager", "sentinel_one_cloud_funnel", "crowdstrike"] maturity = "production" -updated_date = "2025/03/20" +updated_date = "2025/12/18" [rule] author = ["Elastic"] @@ -19,6 +19,7 @@ index = [ "logs-auditd_manager.auditd-*", "logs-endpoint.events.process*", "logs-sentinel_one_cloud_funnel.*", + "logs-crowdstrike.fdr*", ] language = "eql" license = "Elastic License v2" @@ -96,30 +97,28 @@ tags = [ "Data Source: Elastic Endgame", "Data Source: Auditd Manager", "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 - event.action in ("exec", "exec_event", "start", "executed", "process_started") and - process.name in ("grep", "egrep", "pgrep") and - process.args in ("vmdk", "vmx", "vmxf", "vmsd", "vmsn", "vswp", "vmss", "nvram", "vmem") and - not process.parent.executable == "/usr/share/qemu/init/qemu-kvm-init" +event.action in ("exec", "exec_event", "start", "executed", "process_started", "ProcessRollup2") and +process.name in ("grep", "egrep", "pgrep") and +process.args in ("vmdk", "vmx", "vmxf", "vmsd", "vmsn", "vswp", "vmss", "nvram", "vmem") and +not ?process.parent.executable in ("/usr/share/qemu/init/qemu-kvm-init", "/etc/sysconfig/modules/kvm.modules") ''' - [[rule.threat]] framework = "MITRE ATT&CK" + [[rule.threat.technique]] id = "T1518" name = "Software Discovery" reference = "https://attack.mitre.org/techniques/T1518/" - [rule.threat.tactic] id = "TA0007" name = "Discovery" reference = "https://attack.mitre.org/tactics/TA0007/" - diff --git a/rules/linux/discovery_kernel_module_enumeration.toml b/rules/linux/discovery_kernel_module_enumeration.toml index 64a7eeaf5f2..23fb03723f1 100644 --- a/rules/linux/discovery_kernel_module_enumeration.toml +++ b/rules/linux/discovery_kernel_module_enumeration.toml @@ -2,7 +2,7 @@ creation_date = "2020/04/23" integration = ["endpoint"] maturity = "production" -updated_date = "2025/01/24" +updated_date = "2025/12/18" [rule] author = ["Elastic"] @@ -21,8 +21,42 @@ from = "now-9m" index = ["logs-endpoint.events.*", "endgame-*"] language = "kuery" license = "Elastic License v2" -name = "Enumeration of Kernel Modules" -risk_score = 47 +name = "Unusual Kernel Module Enumeration" +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 Unusual Kernel Module Enumeration + +Loadable Kernel Modules (LKMs) enhance a Linux kernel's capabilities dynamically, without requiring a system reboot. Adversaries may exploit this by enumerating kernel modules to gather system information or identify vulnerabilities. The detection rule identifies suspicious enumeration activities by monitoring specific processes and arguments associated with module listing commands, while excluding benign parent processes to reduce false positives. + +### Possible investigation steps + +- Review the process details in the alert to identify the specific command used for kernel module enumeration, such as lsmod, modinfo, kmod with list argument, or depmod with --all or -a arguments. +- Examine the process parent name to ensure it is not one of the benign processes listed in the exclusion criteria, such as mkinitramfs, dracut, or systemd, which could indicate a false positive. +- Investigate the user account associated with the process to determine if the activity aligns with expected behavior or if it might indicate unauthorized access. +- Check the timing and frequency of the enumeration activity to assess whether it is part of routine system operations or an anomaly that warrants further investigation. +- Correlate the alert with other security events or logs from the same host to identify any additional suspicious activities or patterns that could suggest a broader attack or compromise. + +### False positive analysis + +- System maintenance tools like mkinitramfs and dracut may trigger the rule during legitimate operations. To handle this, ensure these processes are included in the exclusion list to prevent unnecessary alerts. +- Backup and recovery processes such as rear and casper can cause false positives when they interact with kernel modules. Verify these processes are part of the exclusion criteria to avoid misidentification. +- Disk management and storage tools like lvm2 and mdadm might enumerate kernel modules as part of their normal function. Add these to the exclusion list to reduce false positives. +- Virtualization and container management tools such as vz-start and overlayroot may also enumerate modules. Confirm these are excluded to maintain focus on genuine threats. +- Kernel update and management utilities like dkms and kernel-install can trigger alerts during updates. Ensure these are accounted for in the exclusion list to minimize false alarms. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent potential lateral movement by the adversary. +- Terminate any suspicious processes identified by the detection rule, specifically those involving unauthorized use of lsmod, modinfo, kmod, or depmod commands. +- Conduct a thorough review of recent system logs and process execution history to identify any unauthorized access or changes made to the system. +- Restore the system from a known good backup if any unauthorized modifications to kernel modules or system files are detected. +- Update and patch the system to the latest security standards to mitigate any known vulnerabilities that could be exploited through kernel modules. +- Implement stricter access controls and monitoring for kernel module management, ensuring only authorized personnel can load or unload modules. +- 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 = 21 rule_id = "2d8043ed-5bda-4caf-801c-c1feb7410504" setup = """## Setup @@ -49,7 +83,7 @@ For more details on Elastic Agent configuration settings, refer to the [helper g - To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. For more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html). """ -severity = "medium" +severity = "low" tags = [ "Domain: Endpoint", "OS: Linux", @@ -61,7 +95,6 @@ tags = [ ] 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) and ( (process.name:(lsmod or modinfo)) or @@ -74,43 +107,13 @@ not ( vz-start or iscsi or mdadm or ovalprobes or bcache or plymouth or dkms or overlayroot or weak-modules or zfs or systemd or whoopsie-upload-all or kdumpctl or apport-gtk or casper or rear or kernel-install or newrelic-infra ) or - process.parent.executable:/var/lib/dpkg/info/linux-modules*-generic.post* + process.parent.executable:( + /var/lib/dpkg/info/linux-modules*-generic.post* or "/var/ossec/bin/wazuh-modulesd" or "/opt/gitlab/embedded/bin/ruby" or + "/usr/share/initramfs-tools/hooks/thermal" or "/usr/libexec/iptables/iptables.init" + ) or + process.parent.args:(/var/lib/dpkg/info/* or /var/tmp/rpm-tmp* or "longhorn-manager" or "/usr/bin/entry") ) ''' -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 Enumeration of Kernel Modules - -Loadable Kernel Modules (LKMs) enhance a Linux kernel's capabilities dynamically, without requiring a system reboot. Adversaries may exploit this by enumerating kernel modules to gather system information or identify vulnerabilities. The detection rule identifies suspicious enumeration activities by monitoring specific processes and arguments associated with module listing commands, while excluding benign parent processes to reduce false positives. - -### Possible investigation steps - -- Review the process details in the alert to identify the specific command used for kernel module enumeration, such as lsmod, modinfo, kmod with list argument, or depmod with --all or -a arguments. -- Examine the process parent name to ensure it is not one of the benign processes listed in the exclusion criteria, such as mkinitramfs, dracut, or systemd, which could indicate a false positive. -- Investigate the user account associated with the process to determine if the activity aligns with expected behavior or if it might indicate unauthorized access. -- Check the timing and frequency of the enumeration activity to assess whether it is part of routine system operations or an anomaly that warrants further investigation. -- Correlate the alert with other security events or logs from the same host to identify any additional suspicious activities or patterns that could suggest a broader attack or compromise. - -### False positive analysis - -- System maintenance tools like mkinitramfs and dracut may trigger the rule during legitimate operations. To handle this, ensure these processes are included in the exclusion list to prevent unnecessary alerts. -- Backup and recovery processes such as rear and casper can cause false positives when they interact with kernel modules. Verify these processes are part of the exclusion criteria to avoid misidentification. -- Disk management and storage tools like lvm2 and mdadm might enumerate kernel modules as part of their normal function. Add these to the exclusion list to reduce false positives. -- Virtualization and container management tools such as vz-start and overlayroot may also enumerate modules. Confirm these are excluded to maintain focus on genuine threats. -- Kernel update and management utilities like dkms and kernel-install can trigger alerts during updates. Ensure these are accounted for in the exclusion list to minimize false alarms. - -### Response and remediation - -- Immediately isolate the affected system from the network to prevent potential lateral movement by the adversary. -- Terminate any suspicious processes identified by the detection rule, specifically those involving unauthorized use of lsmod, modinfo, kmod, or depmod commands. -- Conduct a thorough review of recent system logs and process execution history to identify any unauthorized access or changes made to the system. -- Restore the system from a known good backup if any unauthorized modifications to kernel modules or system files are detected. -- Update and patch the system to the latest security standards to mitigate any known vulnerabilities that could be exploited through kernel modules. -- Implement stricter access controls and monitoring for kernel module management, ensuring only authorized personnel can load or unload modules. -- 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" @@ -127,8 +130,8 @@ reference = "https://attack.mitre.org/tactics/TA0007/" [rule.new_terms] field = "new_terms_fields" -value = ["process.executable", "process.parent.executable"] +value = ["process.executable"] [[rule.new_terms.history_window_start]] field = "history_window_start" -value = "now-14d" +value = "now-5d" diff --git a/rules/linux/discovery_kernel_seeking.toml b/rules/linux/discovery_kernel_seeking.toml index 72efe98deed..f7159bd2840 100644 --- a/rules/linux/discovery_kernel_seeking.toml +++ b/rules/linux/discovery_kernel_seeking.toml @@ -2,7 +2,7 @@ creation_date = "2025/01/07" integration = ["endpoint"] maturity = "production" -updated_date = "2025/02/04" +updated_date = "2025/12/18" [rule] author = ["Elastic"] @@ -16,8 +16,42 @@ index = ["logs-endpoint.events.process*"] language = "eql" license = "Elastic License v2" name = "Kernel Seeking Activity" +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 Kernel Seeking Activity + +Kernel seeking involves probing the Linux kernel for symbols and functions, often using utilities like `tail`, `cmp`, `hexdump`, `xxd`, and `dd`. Adversaries exploit this to discover vulnerabilities for kernel exploitation. The detection rule identifies suspicious execution patterns of these utilities, particularly when accessing kernel-related paths, signaling potential malicious reconnaissance or exploitation attempts. + +### Possible investigation steps + +- Review the process execution details to confirm the use of utilities like `tail`, `cmp`, `hexdump`, `xxd`, or `dd` with the specified arguments, focusing on the `process.name` and `process.args` fields. +- Examine the `process.parent.args` and `process.args` fields to identify the specific kernel-related paths accessed, such as those under `/boot/*`, to understand the context of the access. +- Investigate the parent process of the suspicious activity by analyzing the `process.parent` field to determine if it was initiated by a legitimate or potentially malicious process. +- Check the timeline of events around the alert to identify any preceding or subsequent suspicious activities that might indicate a broader attack pattern. +- Correlate the alert with other security events or logs from the same host to assess if there are additional indicators of compromise or related malicious activities. +- Evaluate the user account associated with the process execution to determine if it aligns with expected behavior or if it might be compromised. + +### False positive analysis + +- System administrators or automated scripts may use utilities like `tail`, `cmp`, `hexdump`, `xxd`, and `dd` for legitimate maintenance tasks involving kernel files. To mitigate this, identify and whitelist specific scripts or processes that are known to perform these actions regularly. +- Backup or recovery operations might involve accessing kernel-related paths with these utilities. Exclude these operations by defining exceptions for known backup tools or processes that interact with the `/boot` directory. +- Developers working on kernel modules or custom kernel builds may trigger this rule during their normal workflow. Consider excluding specific user accounts or development environments from this rule to prevent false positives. +- Security tools or monitoring solutions that perform regular checks on kernel files could be mistakenly flagged. Review and whitelist these tools to ensure they are not incorrectly identified as threats. + +### Response and remediation + +- Isolate the affected system from the network to prevent further unauthorized access or data exfiltration. +- Terminate any suspicious processes identified by the detection rule, particularly those involving the utilities `tail`, `cmp`, `hexdump`, `xxd`, and `dd` accessing kernel paths. +- Conduct a thorough review of system logs and process execution history to identify any additional suspicious activities or related indicators of compromise. +- Restore the system from a known good backup if any unauthorized modifications to the kernel or system files are detected. +- Update the Linux kernel and all related packages to the latest versions to patch any known vulnerabilities that could be exploited. +- Implement enhanced monitoring and alerting for similar activities, focusing on the execution of the specified utilities with kernel-related arguments. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems may be affected.""" references = ["https://www.elastic.co/security-labs/declawing-pumakit"] -risk_score = 21 +risk_score = 47 rule_id = "3c9f7901-01d8-465d-8dc0-5d46671035fa" setup = """## Setup @@ -44,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", @@ -63,42 +97,17 @@ process where host.os.type == "linux" and event.type == "start" and event.action (process.name == "cmp" and process.args == "-i") or (process.name in ("hexdump", "xxd") and process.args == "-s") or (process.name == "dd" and process.args like "seek*") +) and process.parent.executable != null and +not ( + process.parent.executable in ( + "/usr/lib/needrestart/vmlinuz-get-version", "/bin/dracut", "/sbin/dracut", "/usr/sbin/dracut" + ) or + process.parent.args in ( + "/usr/bin/dracut", "/usr/lib/needrestart/vmlinuz-get-version", "/sbin/dracut", "/bin/dracut", + "/usr/sbin/dracut", "/usr/bin/spectre-meltdown-checker", "/usr/lib/module-init-tools/lsinitrd-quick" + ) ) ''' -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 Kernel Seeking Activity - -Kernel seeking involves probing the Linux kernel for symbols and functions, often using utilities like `tail`, `cmp`, `hexdump`, `xxd`, and `dd`. Adversaries exploit this to discover vulnerabilities for kernel exploitation. The detection rule identifies suspicious execution patterns of these utilities, particularly when accessing kernel-related paths, signaling potential malicious reconnaissance or exploitation attempts. - -### Possible investigation steps - -- Review the process execution details to confirm the use of utilities like `tail`, `cmp`, `hexdump`, `xxd`, or `dd` with the specified arguments, focusing on the `process.name` and `process.args` fields. -- Examine the `process.parent.args` and `process.args` fields to identify the specific kernel-related paths accessed, such as those under `/boot/*`, to understand the context of the access. -- Investigate the parent process of the suspicious activity by analyzing the `process.parent` field to determine if it was initiated by a legitimate or potentially malicious process. -- Check the timeline of events around the alert to identify any preceding or subsequent suspicious activities that might indicate a broader attack pattern. -- Correlate the alert with other security events or logs from the same host to assess if there are additional indicators of compromise or related malicious activities. -- Evaluate the user account associated with the process execution to determine if it aligns with expected behavior or if it might be compromised. - -### False positive analysis - -- System administrators or automated scripts may use utilities like `tail`, `cmp`, `hexdump`, `xxd`, and `dd` for legitimate maintenance tasks involving kernel files. To mitigate this, identify and whitelist specific scripts or processes that are known to perform these actions regularly. -- Backup or recovery operations might involve accessing kernel-related paths with these utilities. Exclude these operations by defining exceptions for known backup tools or processes that interact with the `/boot` directory. -- Developers working on kernel modules or custom kernel builds may trigger this rule during their normal workflow. Consider excluding specific user accounts or development environments from this rule to prevent false positives. -- Security tools or monitoring solutions that perform regular checks on kernel files could be mistakenly flagged. Review and whitelist these tools to ensure they are not incorrectly identified as threats. - -### Response and remediation - -- Isolate the affected system from the network to prevent further unauthorized access or data exfiltration. -- Terminate any suspicious processes identified by the detection rule, particularly those involving the utilities `tail`, `cmp`, `hexdump`, `xxd`, and `dd` accessing kernel paths. -- Conduct a thorough review of system logs and process execution history to identify any additional suspicious activities or related indicators of compromise. -- Restore the system from a known good backup if any unauthorized modifications to the kernel or system files are detected. -- Update the Linux kernel and all related packages to the latest versions to patch any known vulnerabilities that could be exploited. -- Implement enhanced monitoring and alerting for similar activities, focusing on the execution of the specified utilities with kernel-related arguments. -- Escalate the incident to the security operations team for further investigation and to determine if additional systems may be affected.""" [[rule.threat]] framework = "MITRE ATT&CK" diff --git a/rules/linux/discovery_kernel_unpacking.toml b/rules/linux/discovery_kernel_unpacking.toml index 81323d2a478..5fd3d44ce52 100644 --- a/rules/linux/discovery_kernel_unpacking.toml +++ b/rules/linux/discovery_kernel_unpacking.toml @@ -2,7 +2,7 @@ creation_date = "2025/01/07" integration = ["endpoint"] maturity = "production" -updated_date = "2025/02/04" +updated_date = "2025/12/18" [rule] author = ["Elastic"] @@ -15,8 +15,42 @@ index = ["logs-endpoint.events.process*"] language = "eql" license = "Elastic License v2" name = "Kernel Unpacking Activity" +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 Kernel Unpacking Activity + +Kernel unpacking involves using utilities to extract or inspect kernel images and modules, often for legitimate maintenance or updates. However, adversaries exploit this to identify vulnerabilities or alter the kernel for malicious purposes. The detection rule identifies suspicious unpacking by monitoring specific Linux utilities and command patterns, excluding benign processes like system updates, to flag potential threats. + +### Possible investigation steps + +- Review the process details to identify the specific utility used for unpacking, such as "file", "unlzma", "gunzip", etc., and verify if the usage aligns with typical system maintenance activities. +- Examine the parent process name and arguments, especially those involving "/boot/*", to determine if the unpacking activity is part of a legitimate system operation or an unauthorized action. +- Check the user account associated with the process to assess if the activity was initiated by a legitimate user or an unauthorized entity. +- Investigate the timing of the event to see if it coincides with scheduled maintenance or updates, which might explain the unpacking activity. +- Look for any related alerts or logs that might indicate further suspicious behavior, such as attempts to modify kernel modules or other system files following the unpacking activity. +- Cross-reference the event with recent system updates or patches to rule out false positives related to legitimate system operations. + +### False positive analysis + +- System updates and maintenance activities can trigger this rule when legitimate processes unpack kernel images. To manage this, exclude processes initiated by known update utilities like "mkinitramfs" from triggering alerts. +- Custom scripts or administrative tasks that involve unpacking kernel images for legitimate purposes may also cause false positives. Identify and whitelist these scripts or processes by their specific command patterns or parent process names. +- Backup or recovery operations that involve accessing or unpacking kernel files might be flagged. Review these operations and exclude them by specifying the responsible process names or arguments in the detection rule. +- Automated security tools that scan or analyze kernel images for compliance or vulnerability assessments can be mistaken for malicious activity. Exclude these tools by adding their process names to the exception list. + +### Response and remediation + +- Isolate the affected system from the network to prevent potential lateral movement or further exploitation by the adversary. +- Terminate any suspicious processes identified by the detection rule, especially those involving the unpacking of kernel images or modules. +- Conduct a thorough review of the system's kernel and module integrity using trusted tools to ensure no unauthorized modifications have been made. +- Restore the system from a known good backup if any unauthorized changes to the kernel or system files are detected. +- Update the system's kernel and all related packages to the latest versions to mitigate any known vulnerabilities that could be exploited. +- Monitor the system for any recurring suspicious activity, focusing on the use of utilities and command patterns identified in the detection rule. +- 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://www.elastic.co/security-labs/declawing-pumakit"] -risk_score = 21 +risk_score = 47 rule_id = "4f725dc5-ae44-46c1-9ac5-99f6f7a70d8a" setup = """## Setup @@ -43,7 +77,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", @@ -62,42 +96,16 @@ process where host.os.type == "linux" and event.type == "start" and event.action (process.name == "grep" and process.args == "ELF") or (process.name in ("lzop", "lz4") and process.args in ("-d", "--decode")) ) and -not process.parent.name == "mkinitramfs" +not ( + process.parent.name == "mkinitramfs" or + process.parent.executable like ( + "/usr/lib/needrestart/vmlinuz-get-version", "/usr/libexec/platform-python*", "/tmp/newroot/usr/libexec/platform-python*", + "/usr/bin/kdumpctl", "/usr/bin/stap-report", "/usr/sbin/nv-update-initrd" + ) or + process.parent.command_line like "*ansible*" or + process.parent.args == "/usr/bin/kdumpctl" +) ''' -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 Kernel Unpacking Activity - -Kernel unpacking involves using utilities to extract or inspect kernel images and modules, often for legitimate maintenance or updates. However, adversaries exploit this to identify vulnerabilities or alter the kernel for malicious purposes. The detection rule identifies suspicious unpacking by monitoring specific Linux utilities and command patterns, excluding benign processes like system updates, to flag potential threats. - -### Possible investigation steps - -- Review the process details to identify the specific utility used for unpacking, such as "file", "unlzma", "gunzip", etc., and verify if the usage aligns with typical system maintenance activities. -- Examine the parent process name and arguments, especially those involving "/boot/*", to determine if the unpacking activity is part of a legitimate system operation or an unauthorized action. -- Check the user account associated with the process to assess if the activity was initiated by a legitimate user or an unauthorized entity. -- Investigate the timing of the event to see if it coincides with scheduled maintenance or updates, which might explain the unpacking activity. -- Look for any related alerts or logs that might indicate further suspicious behavior, such as attempts to modify kernel modules or other system files following the unpacking activity. -- Cross-reference the event with recent system updates or patches to rule out false positives related to legitimate system operations. - -### False positive analysis - -- System updates and maintenance activities can trigger this rule when legitimate processes unpack kernel images. To manage this, exclude processes initiated by known update utilities like "mkinitramfs" from triggering alerts. -- Custom scripts or administrative tasks that involve unpacking kernel images for legitimate purposes may also cause false positives. Identify and whitelist these scripts or processes by their specific command patterns or parent process names. -- Backup or recovery operations that involve accessing or unpacking kernel files might be flagged. Review these operations and exclude them by specifying the responsible process names or arguments in the detection rule. -- Automated security tools that scan or analyze kernel images for compliance or vulnerability assessments can be mistaken for malicious activity. Exclude these tools by adding their process names to the exception list. - -### Response and remediation - -- Isolate the affected system from the network to prevent potential lateral movement or further exploitation by the adversary. -- Terminate any suspicious processes identified by the detection rule, especially those involving the unpacking of kernel images or modules. -- Conduct a thorough review of the system's kernel and module integrity using trusted tools to ensure no unauthorized modifications have been made. -- Restore the system from a known good backup if any unauthorized changes to the kernel or system files are detected. -- Update the system's kernel and all related packages to the latest versions to mitigate any known vulnerabilities that could be exploited. -- Monitor the system for any recurring suspicious activity, focusing on the use of utilities and command patterns identified in the detection rule. -- 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/discovery_kubeconfig_file_discovery.toml b/rules/linux/discovery_kubeconfig_file_discovery.toml index fb344399628..481b849574d 100644 --- a/rules/linux/discovery_kubeconfig_file_discovery.toml +++ b/rules/linux/discovery_kubeconfig_file_discovery.toml @@ -2,7 +2,7 @@ creation_date = "2025/06/17" integration = ["endpoint"] maturity = "production" -updated_date = "2025/07/07" +updated_date = "2025/12/18" [rule] author = ["Elastic"] @@ -124,7 +124,14 @@ process where host.os.type == "linux" and event.type == "start" and event.action "/root/.kube/config", "/var/lib/*/kubeconfig" ) -) and not process.name in ("stat", "md5sum", "dirname") +) and not ( + process.name in ("stat", "md5sum", "dirname") or + (process.name like "python*" and process.args == "/usr/bin/yq" and process.parent.name == "fish") or + process.executable in ( + "/usr/bin/file", "/usr/bin/readlink", "/bin/readlink", "/bin/file", "/tmp/newroot/bin/readlink", + "/tmp/newroot/bin/file", "/usr/local/bin/helm" + ) +) ''' [[rule.threat]] diff --git a/rules/linux/discovery_kubectl_permission_discovery.toml b/rules/linux/discovery_kubectl_permission_discovery.toml index e50f1a77a15..ea8707c76ff 100644 --- a/rules/linux/discovery_kubectl_permission_discovery.toml +++ b/rules/linux/discovery_kubectl_permission_discovery.toml @@ -1,8 +1,8 @@ [metadata] creation_date = "2025/06/17" -integration = ["endpoint", "crowdstrike"] +integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_funnel"] maturity = "production" -updated_date = "2025/10/17" +updated_date = "2025/12/18" [rule] author = ["Elastic"] @@ -13,8 +13,12 @@ them to gain unauthorized access or escalate privileges. """ from = "now-9m" index = [ - "logs-endpoint.events.process*", - "logs-crowdstrike.fdr*", + "auditbeat-*", + "endgame-*", + "logs-auditd_manager.auditd-*", + "logs-crowdstrike.fdr*", + "logs-endpoint.events.process*", + "logs-sentinel_one_cloud_funnel.*", ] language = "eql" license = "Elastic License v2" @@ -57,7 +61,7 @@ Kubectl is a command-line tool for interacting with Kubernetes clusters, allowin references = [ "https://kubernetes.io/docs/reference/kubectl/generated/kubectl_auth/kubectl_auth_can-i/", ] -risk_score = 21 +risk_score = 47 rule_id = "1600f9e2-5be6-4742-8593-1ba50cd94069" setup = """## Setup @@ -84,7 +88,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", "Domain: Container", @@ -93,13 +97,17 @@ tags = [ "Use Case: Threat Detection", "Tactic: Discovery", "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 = "eql" query = ''' -process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "ProcessRollup2") and +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 == "kubectl" and process.args == "auth" and process.args == "can-i" ''' diff --git a/rules/linux/discovery_manual_mount_discovery_via_exports_or_fstab.toml b/rules/linux/discovery_manual_mount_discovery_via_exports_or_fstab.toml index 94904792ed5..221cc4ff072 100644 --- a/rules/linux/discovery_manual_mount_discovery_via_exports_or_fstab.toml +++ b/rules/linux/discovery_manual_mount_discovery_via_exports_or_fstab.toml @@ -1,8 +1,8 @@ [metadata] creation_date = "2025/04/25" -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 @@ file to gather information about shared directories and potential targets for fu """ 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" @@ -57,7 +59,7 @@ In Linux environments, the `/etc/exports` and `/etc/fstab` files are crucial for - Escalate the incident to the security operations team for further investigation and to determine if additional systems have been compromised. - Implement enhanced monitoring and logging for access to critical configuration files like `/etc/exports` and `/etc/fstab` to detect similar threats in the future. """ -risk_score = 21 +risk_score = 47 rule_id = "bd18f4a3-c4c6-43b9-a1e4-b05e09998110" setup = """## Setup @@ -84,7 +86,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", @@ -94,13 +96,16 @@ tags = [ "Data Source: Elastic Endgame", "Data Source: Crowdstrike", "Data Source: SentinelOne", + "Data Source: Auditd Manager", "Resources: Investigation Guide", ] timestamp_override = "event.ingested" type = "eql" query = ''' -process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start", "ProcessRollup2") and -process.name in ("cat", "grep", "tail", "less", "more", "egrep", "fgrep") and process.command_line like ("/etc/exports", "/etc/fstab") +process where host.os.type == "linux" and event.type == "start" and +event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and +process.name in ("cat", "grep", "tail", "less", "more", "egrep", "fgrep", "awk") and +process.command_line like ("/etc/exports", "/etc/fstab") ''' [[rule.threat]] diff --git a/rules/linux/discovery_pam_version_discovery.toml b/rules/linux/discovery_pam_version_discovery.toml index 694412a51eb..fd9295a70a0 100644 --- a/rules/linux/discovery_pam_version_discovery.toml +++ b/rules/linux/discovery_pam_version_discovery.toml @@ -2,7 +2,7 @@ creation_date = "2024/12/16" integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"] maturity = "production" -updated_date = "2025/03/20" +updated_date = "2025/12/18" [rule] author = ["Elastic"] @@ -101,52 +101,59 @@ 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.parent.name != null and + event.action in ("exec", "exec_event", "start", "ProcessRollup2") and ?process.parent.name != null and ( (process.name in ("dpkg", "dpkg-query") and process.args == "libpam-modules") or (process.name == "rpm" and process.args == "pam") ) and -not process.parent.name in ("dcservice", "inspectorssmplugin") +not ( + ?process.parent.name in ("dcservice", "inspectorssmplugin") or + ?process.working_directory in ("/var/ossec", "/opt/msp-agent") or + ?process.parent.executable in ( + "/opt/CyberCNSAgent/cybercnsagent_linux", "/usr/local/manageengine/uems_agent/bin/dcpatchscan", + "/usr/local/manageengine/uems_agent/bin/dcconfig", "/usr/share/vicarius/topiad", + "/etc/rc.d/init.d/sshd-chroot" + ) +) ''' - [[rule.threat]] framework = "MITRE ATT&CK" + [[rule.threat.technique]] id = "T1082" name = "System Information Discovery" reference = "https://attack.mitre.org/techniques/T1082/" - [rule.threat.tactic] id = "TA0007" name = "Discovery" reference = "https://attack.mitre.org/tactics/TA0007/" + [[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" reference = "https://attack.mitre.org/tactics/TA0003/" + [[rule.threat]] framework = "MITRE ATT&CK" + [[rule.threat.technique]] id = "T1556" name = "Modify Authentication Process" reference = "https://attack.mitre.org/techniques/T1556/" - [rule.threat.tactic] id = "TA0006" name = "Credential Access" reference = "https://attack.mitre.org/tactics/TA0006/" - diff --git a/rules/linux/discovery_ping_sweep_detected.toml b/rules/linux/discovery_ping_sweep_detected.toml index 6819c66e02b..1cffefe920a 100644 --- a/rules/linux/discovery_ping_sweep_detected.toml +++ b/rules/linux/discovery_ping_sweep_detected.toml @@ -1,8 +1,8 @@ [metadata] creation_date = "2023/09/04" -integration = ["endpoint", "auditd_manager"] +integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_funnel"] maturity = "production" -updated_date = "2025/01/15" +updated_date = "2025/12/18" [rule] author = ["Elastic"] @@ -12,10 +12,52 @@ Adversaries may leverage built-in tools such as ping, netcat or socat to execute attempting to evade detection or due to the lack of network mapping tools available on the compromised host. """ from = "now-9m" -index = ["logs-endpoint.events.*", "endgame-*", "auditbeat-*", "logs-auditd_manager.auditd-*"] +index = [ + "auditbeat-*", + "endgame-*", + "logs-auditd_manager.auditd-*", + "logs-crowdstrike.fdr*", + "logs-endpoint.events.process*", + "logs-sentinel_one_cloud_funnel.*", +] language = "kuery" license = "Elastic License v2" name = "Potential Network Scan Executed From Host" +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 Network Scan Executed From Host + +In Linux environments, utilities like ping, netcat, and socat are essential for network diagnostics and communication. However, adversaries can exploit these tools to perform network scans, identifying active hosts and services for further exploitation. The detection rule identifies rapid execution of these utilities, signaling potential misuse for network reconnaissance, by monitoring process initiation events linked to these tools. + +### Possible investigation steps + +- Review the process initiation events to confirm the rapid execution of utilities like ping, netcat, or socat by examining the process.name field in the alert. +- Identify the user account associated with the process execution by checking the user information in the event data to determine if the activity aligns with expected behavior. +- Analyze the command line arguments used with the executed utilities by inspecting the process.command_line field to understand the scope and intent of the network scan. +- Correlate the alert with other recent events on the host by reviewing event timestamps and related process activities to identify any patterns or additional suspicious behavior. +- Check network logs or firewall logs for any unusual outbound connections or traffic patterns originating from the host to assess the potential impact of the network scan. +- Investigate the host's recent login history and user activity to determine if there are signs of unauthorized access or compromise that could explain the network scan activity. + +### False positive analysis + +- Routine network diagnostics by system administrators can trigger alerts. To manage this, create exceptions for known administrator accounts or specific IP addresses frequently used for legitimate network diagnostics. +- Automated monitoring scripts that use these utilities for health checks or performance monitoring may cause false positives. Identify and exclude these scripts by their process names or execution paths. +- Scheduled tasks or cron jobs that involve network utilities for maintenance purposes can be mistaken for network scans. Exclude these tasks by their specific scheduling patterns or associated user accounts. +- Security tools that perform regular network sweeps as part of their functionality might be flagged. Whitelist these tools by their process names or hash values to prevent unnecessary alerts. +- Development or testing environments where network utilities are used for testing purposes can generate false positives. Implement exclusions based on environment-specific identifiers or network segments. + +### Response and remediation + +- Isolate the affected host from the network to prevent further reconnaissance or lateral movement by the adversary. +- Terminate any suspicious processes identified by the detection rule, such as those involving ping, netcat, or socat, to halt ongoing network scans. +- Conduct a thorough review of the host's process logs and network activity to identify any additional indicators of compromise or related malicious activity. +- Reset credentials and review access permissions for accounts that were active on the compromised host to prevent unauthorized access. +- Apply patches and updates to the host's operating system and installed software to mitigate vulnerabilities that could be exploited by adversaries. +- Enhance network monitoring and logging to detect similar reconnaissance activities in the future, ensuring that alerts are configured to notify security teams promptly. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional hosts or systems are affected.""" risk_score = 47 rule_id = "03c23d45-d3cb-4ad4-ab5d-b361ffe8724a" setup = """## Setup @@ -53,60 +95,26 @@ tags = [ "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 = "threshold" - query = ''' -event.category:process and host.os.type:linux and event.action:(exec or exec_event or executed or process_started) and -event.type:start and process.name:(ping or nping or hping or hping2 or hping3 or nc or ncat or netcat or socat) +event.category:process and host.os.type:linux and event.type:start and +event.action:(exec or exec_event or executed or process_started or start or ProcessRollup2) and +process.name:(ping or nping or hping or hping2 or hping3 or nc or ncat or netcat or socat) ''' -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 Network Scan Executed From Host - -In Linux environments, utilities like ping, netcat, and socat are essential for network diagnostics and communication. However, adversaries can exploit these tools to perform network scans, identifying active hosts and services for further exploitation. The detection rule identifies rapid execution of these utilities, signaling potential misuse for network reconnaissance, by monitoring process initiation events linked to these tools. - -### Possible investigation steps - -- Review the process initiation events to confirm the rapid execution of utilities like ping, netcat, or socat by examining the process.name field in the alert. -- Identify the user account associated with the process execution by checking the user information in the event data to determine if the activity aligns with expected behavior. -- Analyze the command line arguments used with the executed utilities by inspecting the process.command_line field to understand the scope and intent of the network scan. -- Correlate the alert with other recent events on the host by reviewing event timestamps and related process activities to identify any patterns or additional suspicious behavior. -- Check network logs or firewall logs for any unusual outbound connections or traffic patterns originating from the host to assess the potential impact of the network scan. -- Investigate the host's recent login history and user activity to determine if there are signs of unauthorized access or compromise that could explain the network scan activity. - -### False positive analysis - -- Routine network diagnostics by system administrators can trigger alerts. To manage this, create exceptions for known administrator accounts or specific IP addresses frequently used for legitimate network diagnostics. -- Automated monitoring scripts that use these utilities for health checks or performance monitoring may cause false positives. Identify and exclude these scripts by their process names or execution paths. -- Scheduled tasks or cron jobs that involve network utilities for maintenance purposes can be mistaken for network scans. Exclude these tasks by their specific scheduling patterns or associated user accounts. -- Security tools that perform regular network sweeps as part of their functionality might be flagged. Whitelist these tools by their process names or hash values to prevent unnecessary alerts. -- Development or testing environments where network utilities are used for testing purposes can generate false positives. Implement exclusions based on environment-specific identifiers or network segments. - -### Response and remediation - -- Isolate the affected host from the network to prevent further reconnaissance or lateral movement by the adversary. -- Terminate any suspicious processes identified by the detection rule, such as those involving ping, netcat, or socat, to halt ongoing network scans. -- Conduct a thorough review of the host's process logs and network activity to identify any additional indicators of compromise or related malicious activity. -- Reset credentials and review access permissions for accounts that were active on the compromised host to prevent unauthorized access. -- Apply patches and updates to the host's operating system and installed software to mitigate vulnerabilities that could be exploited by adversaries. -- Enhance network monitoring and logging to detect similar reconnaissance activities in the future, ensuring that alerts are configured to notify security teams promptly. -- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional hosts or systems are affected.""" - [[rule.threat]] framework = "MITRE ATT&CK" + [[rule.threat.technique]] id = "T1046" name = "Network Service Discovery" reference = "https://attack.mitre.org/techniques/T1046/" - [rule.threat.tactic] id = "TA0007" name = "Discovery" @@ -115,8 +123,7 @@ reference = "https://attack.mitre.org/tactics/TA0007/" [rule.threshold] field = ["host.id", "process.parent.entity_id", "process.executable"] value = 1 + [[rule.threshold.cardinality]] field = "process.args" value = 100 - - diff --git a/rules/linux/discovery_polkit_version_discovery.toml b/rules/linux/discovery_polkit_version_discovery.toml index 2f24ec30aef..2420b1dc14c 100644 --- a/rules/linux/discovery_polkit_version_discovery.toml +++ b/rules/linux/discovery_polkit_version_discovery.toml @@ -1,8 +1,8 @@ [metadata] creation_date = "2025/01/16" -integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"] +integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel", "auditd_manager"] maturity = "production" -updated_date = "2025/03/20" +updated_date = "2025/12/18" [rule] author = ["Elastic"] @@ -12,10 +12,12 @@ an attacker attempting to exploit misconfigurations or vulnerabilities in the Po """ 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" @@ -86,32 +88,34 @@ tags = [ "Data Source: Elastic Endgame", "Data Source: Crowdstrike", "Data Source: SentinelOne", + "Data Source: Auditd Manager", "Resources: Investigation Guide", ] timestamp_override = "event.ingested" type = "eql" - query = ''' process where host.os.type == "linux" and event.type == "start" and -event.action in ("exec", "exec_event", "start", "ProcessRollup2") and ( +event.action in ("exec", "exec_event", "start", "ProcessRollup2", "process_started", "executed") and ( (process.name == "dnf" and process.args == "dnf" and process.args == "info" and process.args == "polkit") or (process.name == "rpm" and process.args == "polkit") or (process.name == "apt" and process.args == "show" and process.args == "policykit-1") or (process.name == "pkaction" and process.args == "--version") +) and +not ( + ?process.working_directory in ("/opt/msp-agent", "/opt/CyberCNSAgent") or + ?process.parent.executable like ("/usr/local/cpanel/3rdparty/perl/*/bin/perl", "/usr/share/vicarius/topiad") ) ''' - [[rule.threat]] framework = "MITRE ATT&CK" + [[rule.threat.technique]] id = "T1082" name = "System Information Discovery" reference = "https://attack.mitre.org/techniques/T1082/" - [rule.threat.tactic] id = "TA0007" name = "Discovery" reference = "https://attack.mitre.org/tactics/TA0007/" - diff --git a/rules/linux/discovery_port_scanning_activity_from_compromised_host.toml b/rules/linux/discovery_port_scanning_activity_from_compromised_host.toml index bd1d4303239..df58b88100b 100644 --- a/rules/linux/discovery_port_scanning_activity_from_compromised_host.toml +++ b/rules/linux/discovery_port_scanning_activity_from_compromised_host.toml @@ -2,7 +2,7 @@ creation_date = "2025/03/04" integration = ["endpoint"] maturity = "production" -updated_date = "2025/09/29" +updated_date = "2025/12/18" [rule] author = ["Elastic"] @@ -94,9 +94,9 @@ tags = [ timestamp_override = "event.ingested" type = "esql" query = ''' -from logs-endpoint.events.network-* +from logs-endpoint.events.network-* metadata _id, _index, _version +| mv_expand event.action | where - @timestamp > now() - 1h and host.os.type == "linux" and event.type == "start" and event.action == "connection_attempted" and @@ -104,42 +104,50 @@ from logs-endpoint.events.network-* destination.port < 32768 and not ( cidr_match(destination.ip, "127.0.0.0/8", "::1", "FE80::/10", "FF00::/8") or + process.name in ("java", "node") or + process.name like "python*" or process.executable in ( - "/opt/dbtk/bin/jsvc", "/usr/lib/dotnet/dotnet", "/usr/share/elasticsearch/jdk/bin/java", "/usr/sbin/haproxy", - "/usr/bin/java", "/opt/kaspersky/kesl/libexec/kesl", "/usr/bin/dotnet", "/opt/java/openjdk/bin/java" + "/opt/dbtk/bin/jsvc", "/usr/lib/dotnet/dotnet", "/usr/sbin/haproxy", "/opt/kaspersky/kesl/libexec/kesl", + "/usr/bin/dotnet", "/usr/sap/SAPBusinessOne/EDS/bin/EDFBackend", "/usr/local/bin/longhorn-instance-manager" ) or process.executable like "/var/opt/kaspersky/kesl/*kesl" or - process.executable like "/usr/lib/jvm/*/java" or process.executable like "/opt/google/chrome*" or - process.executable like "/var/lib/docker/*/java" or - process.executable like "/usr/lib64/jvm/*/java" or process.executable like "/snap/*" or process.executable like "/home/*/.local/share/JetBrains/*" ) | keep @timestamp, + _id, + _index, + _version, host.os.type, event.type, event.action, + network.direction, destination.port, process.executable, + process.name, destination.ip, source.ip, agent.id, - host.name + host.name, + event.dataset, + data_stream.namespace + | stats Esql.event_count = count(), Esql.destination_port_count_distinct = count_distinct(destination.port), Esql.agent_id_count_distinct = count_distinct(agent.id), Esql.host_name_values = values(host.name), Esql.agent_id_values = values(agent.id), - Esql.source_ip_values = values(source.ip) + Esql.source_ip_values = values(source.ip), + Esql.event_dataset_values = values(event.dataset), + Esql.data_stream_namespace_values = values(data_stream.namespace) by process.executable, destination.ip | where Esql.agent_id_count_distinct == 1 and Esql.destination_port_count_distinct > 100 | sort Esql.event_count asc -| limit 100 ''' [[rule.threat]] diff --git a/rules/linux/discovery_private_key_password_searching_activity.toml b/rules/linux/discovery_private_key_password_searching_activity.toml index d9d0f29ef75..413d337fc5a 100644 --- a/rules/linux/discovery_private_key_password_searching_activity.toml +++ b/rules/linux/discovery_private_key_password_searching_activity.toml @@ -1,8 +1,8 @@ [metadata] creation_date = "2024/11/04" -integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"] +integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel", "auditd_manager"] maturity = "production" -updated_date = "2025/03/20" +updated_date = "2025/12/18" [rule] author = ["Elastic"] @@ -12,10 +12,12 @@ attacker attempting to escalate privileges or exfiltrate sensitive information. """ 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" @@ -54,7 +56,7 @@ In Linux environments, private keys are crucial for secure communications and au - Implement stricter access controls and permissions on directories containing private keys to limit exposure to unauthorized users. - Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected. - Enhance monitoring and alerting for similar activities by ensuring that detection rules are tuned to capture variations of the 'find' command targeting sensitive files.""" -risk_score = 21 +risk_score = 73 rule_id = "627374ab-7080-4e4d-8316-bef1122444af" setup = """## Setup @@ -81,12 +83,14 @@ 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", "Use Case: Threat Detection", "Tactic: Discovery", + "Tactic: Credential Access", + "Data Source: Auditd Manager", "Data Source: Elastic Defend", "Data Source: Crowdstrike", "Data Source: SentinelOne", @@ -95,15 +99,14 @@ 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 == "find" and - process.command_line like ("*id_dsa*", "*id_rsa*", "*id_ed*", "*id_ecdsa*", "*id_xmss*", "*id_dh*") and - process.command_line like ("*/home/*", "*/etc/ssh*", "*/root/*", "/") +event.action in ("exec", "exec_event", "start", "ProcessRollup2", "process_started", "executed") and +process.name == "find" and +process.command_line like ("*id_dsa*", "*id_rsa*", "*id_ed*", "*id_ecdsa*", "*id_xmss*", "*id_dh*") and +process.command_line like ("*/home/*", "*/etc/ssh*", "*/root/*", "/") ''' - [[rule.threat]] framework = "MITRE ATT&CK" @@ -112,3 +115,20 @@ id = "TA0007" name = "Discovery" reference = "https://attack.mitre.org/tactics/TA0007/" +[[rule.threat]] +framework = "MITRE ATT&CK" + +[[rule.threat.technique]] +id = "T1552" +name = "Unsecured Credentials" +reference = "https://attack.mitre.org/techniques/T1552/" + +[[rule.threat.technique.subtechnique]] +id = "T1552.001" +name = "Credentials In Files" +reference = "https://attack.mitre.org/techniques/T1552/001/" + +[rule.threat.tactic] +id = "TA0006" +name = "Credential Access" +reference = "https://attack.mitre.org/tactics/TA0006/" diff --git a/rules/linux/discovery_proc_maps_read.toml b/rules/linux/discovery_proc_maps_read.toml index 2b66a528aa3..986cceed84d 100644 --- a/rules/linux/discovery_proc_maps_read.toml +++ b/rules/linux/discovery_proc_maps_read.toml @@ -1,8 +1,8 @@ [metadata] creation_date = "2024/01/29" -integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"] +integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel", "auditd_manager"] maturity = "production" -updated_date = "2025/04/25" +updated_date = "2025/12/18" [rule] author = ["Elastic"] @@ -13,16 +13,52 @@ memory map to identify memory addresses for code injection or process hijacking. """ 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" name = "Suspicious /proc/maps Discovery" +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 /proc/maps Discovery + +In Linux environments, the `/proc/*/maps` files provide detailed memory mapping of processes, crucial for system diagnostics. However, adversaries exploit this by reading these files to pinpoint memory addresses for malicious activities like code injection. The detection rule identifies suspicious reads of these files by monitoring specific command executions, such as `cat` or `grep`, initiated from common shell environments, flagging potential reconnaissance attempts. + +### Possible investigation steps + +- Review the process details, including the process name and arguments, to confirm if the access to /proc/*/maps was initiated by a legitimate user or application. Pay special attention to the process.name and process.args fields. +- Check the process.entry_leader.name to determine the shell environment from which the command was executed, and assess if this aligns with typical user behavior or known scripts. +- Investigate the user account associated with the process to determine if there are any signs of compromise or unusual activity, such as recent logins from unfamiliar IP addresses or changes in user permissions. +- Examine the parent process and any related child processes to understand the broader context of the command execution, looking for any signs of a script or automated task that might have triggered the alert. +- Correlate this event with other security alerts or logs from the same host or user to identify any patterns or sequences of suspicious activities that could indicate a larger attack or reconnaissance effort. + +### False positive analysis + +- System diagnostics tools may read /proc/*/maps files as part of routine checks. Identify these tools and create exceptions for their processes to avoid unnecessary alerts. +- Developers and system administrators might manually inspect /proc/*/maps during debugging or performance tuning. Establish a list of known users and processes that perform these actions regularly and exclude them from triggering the rule. +- Automated scripts for monitoring or logging purposes could access /proc/*/maps files. Review these scripts and whitelist them if they are verified to be non-malicious. +- Security software might access these files as part of its scanning operations. Confirm the legitimacy of such software and add it to an exception list to prevent false positives. +- Consider the context of the process entry leader. If certain shell environments are used predominantly for legitimate administrative tasks, adjust the rule to reduce sensitivity for those specific environments. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent potential lateral movement by the adversary. +- Terminate any suspicious processes identified as reading the `/proc/*/maps` files using commands like `cat` or `grep` from unauthorized shell environments. +- Conduct a memory analysis on the affected system to identify any injected code or unauthorized modifications in the process memory. +- Review and audit user accounts and permissions on the affected system to ensure that only authorized users have access to sensitive files and directories. +- Implement stricter access controls and monitoring on `/proc/*/maps` files to limit exposure and detect unauthorized access attempts. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are compromised. +- Update and enhance endpoint detection and response (EDR) solutions to improve monitoring and alerting for similar suspicious activities in the future.""" references = ["https://github.com/arget13/DDexec"] -risk_score = 21 +risk_score = 73 rule_id = "2f95540c-923e-4f57-9dae-de30169c68b9" setup = """## Setup @@ -49,12 +85,14 @@ 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", "Use Case: Threat Detection", "Tactic: Discovery", + "Tactic: Credential Access", + "Data Source: Auditd Manager", "Data Source: Elastic Defend", "Data Source: Elastic Endgame", "Data Source: Crowdstrike", @@ -64,43 +102,18 @@ 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 ("cat", "grep", "tail", "less", "more", "egrep", "fgrep") and process.args like "/proc/*/maps" +process where host.os.type == "linux" and event.type == "start" and +event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and +process.name in ("cat", "grep", "tail", "less", "more", "egrep", "fgrep", "awk") and process.args like "/proc/*/maps" and +not ( + ?process.parent.args in ("/usr/bin/finalrd", "/sbin/chkrootkit", "./uac", "/usr/sbin/chkrootkit") or + ?process.parent.executable in ("/usr/sbin/chkrootkit", "/sbin/chkrootkit") or + ?process.parent.name == "uac" or + ?process.parent.executable in ("/opt/secl/linux-ir-scripts-v3/thieves.sh", "/opt/traps/rpm-installer/setup.sh") or + ?process.working_directory like ("/opt/traps/deb-installer", "/opt/Tanium/TaniumClient/*") or + ?process.parent.executable like ("/home/*/sunlight/thieves.sh") +) ''' -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 /proc/maps Discovery - -In Linux environments, the `/proc/*/maps` files provide detailed memory mapping of processes, crucial for system diagnostics. However, adversaries exploit this by reading these files to pinpoint memory addresses for malicious activities like code injection. The detection rule identifies suspicious reads of these files by monitoring specific command executions, such as `cat` or `grep`, initiated from common shell environments, flagging potential reconnaissance attempts. - -### Possible investigation steps - -- Review the process details, including the process name and arguments, to confirm if the access to /proc/*/maps was initiated by a legitimate user or application. Pay special attention to the process.name and process.args fields. -- Check the process.entry_leader.name to determine the shell environment from which the command was executed, and assess if this aligns with typical user behavior or known scripts. -- Investigate the user account associated with the process to determine if there are any signs of compromise or unusual activity, such as recent logins from unfamiliar IP addresses or changes in user permissions. -- Examine the parent process and any related child processes to understand the broader context of the command execution, looking for any signs of a script or automated task that might have triggered the alert. -- Correlate this event with other security alerts or logs from the same host or user to identify any patterns or sequences of suspicious activities that could indicate a larger attack or reconnaissance effort. - -### False positive analysis - -- System diagnostics tools may read /proc/*/maps files as part of routine checks. Identify these tools and create exceptions for their processes to avoid unnecessary alerts. -- Developers and system administrators might manually inspect /proc/*/maps during debugging or performance tuning. Establish a list of known users and processes that perform these actions regularly and exclude them from triggering the rule. -- Automated scripts for monitoring or logging purposes could access /proc/*/maps files. Review these scripts and whitelist them if they are verified to be non-malicious. -- Security software might access these files as part of its scanning operations. Confirm the legitimacy of such software and add it to an exception list to prevent false positives. -- Consider the context of the process entry leader. If certain shell environments are used predominantly for legitimate administrative tasks, adjust the rule to reduce sensitivity for those specific environments. - -### Response and remediation - -- Immediately isolate the affected system from the network to prevent potential lateral movement by the adversary. -- Terminate any suspicious processes identified as reading the `/proc/*/maps` files using commands like `cat` or `grep` from unauthorized shell environments. -- Conduct a memory analysis on the affected system to identify any injected code or unauthorized modifications in the process memory. -- Review and audit user accounts and permissions on the affected system to ensure that only authorized users have access to sensitive files and directories. -- Implement stricter access controls and monitoring on `/proc/*/maps` files to limit exposure and detect unauthorized access attempts. -- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are compromised. -- Update and enhance endpoint detection and response (EDR) solutions to improve monitoring and alerting for similar suspicious activities in the future.""" [[rule.threat]] framework = "MITRE ATT&CK" @@ -114,3 +127,21 @@ reference = "https://attack.mitre.org/techniques/T1057/" id = "TA0007" name = "Discovery" reference = "https://attack.mitre.org/tactics/TA0007/" + +[[rule.threat]] +framework = "MITRE ATT&CK" + +[[rule.threat.technique]] +id = "T1003" +name = "OS Credential Dumping" +reference = "https://attack.mitre.org/techniques/T1003/" + +[[rule.threat.technique.subtechnique]] +id = "T1003.007" +name = "Proc Filesystem" +reference = "https://attack.mitre.org/techniques/T1003/007/" + +[rule.threat.tactic] +id = "TA0006" +name = "Credential Access" +reference = "https://attack.mitre.org/tactics/TA0006/" diff --git a/rules/linux/discovery_process_capabilities.toml b/rules/linux/discovery_process_capabilities.toml index dc379d05024..41b4c8bda26 100644 --- a/rules/linux/discovery_process_capabilities.toml +++ b/rules/linux/discovery_process_capabilities.toml @@ -2,7 +2,7 @@ creation_date = "2024/01/09" integration = ["endpoint", "crowdstrike"] maturity = "production" -updated_date = "2025/02/04" +updated_date = "2025/12/18" [rule] author = ["Elastic"] @@ -15,7 +15,7 @@ index = ["endgame-*", "logs-crowdstrike.fdr*", "logs-endpoint.events.process*"] language = "eql" license = "Elastic License v2" name = "Process Capability Enumeration" -risk_score = 21 +risk_score = 47 rule_id = "5c351f54-4187-4ad8-abc8-29b0cfbef8b1" setup = """## Setup @@ -43,7 +43,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", @@ -56,7 +56,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", "ProcessRollup2") and @@ -98,17 +97,15 @@ In Linux environments, the `getcap` command is used to list file capabilities, w - Implement monitoring for similar `getcap` command executions across the environment to detect and respond to future attempts promptly. - Review and update access controls and user permissions to ensure that only authorized users have the necessary privileges to execute potentially sensitive commands like `getcap`.""" - [[rule.threat]] framework = "MITRE ATT&CK" + [[rule.threat.technique]] id = "T1057" name = "Process Discovery" reference = "https://attack.mitre.org/techniques/T1057/" - [rule.threat.tactic] id = "TA0007" name = "Discovery" reference = "https://attack.mitre.org/tactics/TA0007/" - diff --git a/rules/linux/discovery_pspy_process_monitoring_detected.toml b/rules/linux/discovery_pspy_process_monitoring_detected.toml index b03f97dae68..209802d5b2b 100644 --- a/rules/linux/discovery_pspy_process_monitoring_detected.toml +++ b/rules/linux/discovery_pspy_process_monitoring_detected.toml @@ -2,7 +2,7 @@ creation_date = "2023/07/20" integration = ["auditd_manager"] maturity = "production" -updated_date = "2025/01/24" +updated_date = "2025/12/18" [rule] author = ["Elastic"] @@ -16,7 +16,42 @@ from = "now-9m" index = ["logs-auditd_manager.auditd-*"] language = "eql" license = "Elastic License v2" -name = "Potential Pspy Process Monitoring Detected" +name = "Deprecated - Potential Pspy Process Monitoring Detected" +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + +### Investigating Deprecated - Potential Pspy Process Monitoring Detected + +Auditd is a Linux auditing system that tracks system calls, providing insights into process activities. Adversaries exploit tools like pspy to monitor processes via the /proc directory, seeking privilege escalation opportunities without root access. The detection rule identifies suspicious openat syscalls targeting /proc, excluding benign processes, to flag potential misuse of pspy for process discovery. + +### Possible investigation steps + +- Review the process details associated with the alert, focusing on the process.pid and process.name fields to identify the process attempting to access the /proc directory. +- Investigate the host.id to determine if this activity is isolated to a single host or part of a broader pattern across multiple systems. +- Examine the process tree and parent processes of the flagged process to understand how it was initiated and if it is part of a legitimate workflow or potentially malicious activity. +- Check for any recent changes or installations on the host that might explain the presence of a tool like pspy, such as new software installations or updates. +- Correlate the timing of the alert with any other suspicious activities or alerts on the same host to identify potential lateral movement or privilege escalation attempts. +- Verify if the process name is a known benign process that might have been mistakenly excluded from the query, ensuring that the exclusion list is up-to-date and accurate. + +### False positive analysis + +- Frequent scanning by legitimate monitoring tools can trigger the rule. Identify and whitelist these tools by adding their process names to the exclusion list. +- System management scripts that regularly access the /proc directory may cause false positives. Review these scripts and exclude their process names if they are verified as non-threatening. +- Automated backup or security software that interacts with the /proc directory might be flagged. Confirm their legitimacy and add them to the exception list to prevent unnecessary alerts. +- Custom applications developed in-house that require access to the /proc directory for performance monitoring should be reviewed and excluded if they are deemed safe. +- Regularly update the exclusion list to reflect changes in legitimate software and tools used within the organization to minimize false positives. + +### Response and remediation + +- Immediately isolate the affected host from the network to prevent potential lateral movement by the adversary. +- Terminate any suspicious processes identified as using the pspy utility to halt further unauthorized process monitoring. +- Conduct a thorough review of the affected system's /proc directory access logs to identify any other unauthorized access attempts or anomalies. +- Reset credentials and review permissions for any accounts that may have been compromised or used in the attack to prevent further unauthorized access. +- Apply patches and updates to the affected system to address any vulnerabilities that may have been exploited for privilege escalation. +- Enhance monitoring and logging on the affected host to detect any future attempts to access the /proc directory using similar methods. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems may be affected.""" references = ["https://github.com/DominicBreuker/pspy"] risk_score = 21 rule_id = "bdb04043-f0e3-4efa-bdee-7d9d13fa9edc" @@ -61,41 +96,6 @@ sequence by process.pid, host.id with maxspan=5s not process.name in ("agentbeat", "packetbeat") ] with runs=10 ''' -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 Pspy Process Monitoring Detected - -Auditd is a Linux auditing system that tracks system calls, providing insights into process activities. Adversaries exploit tools like pspy to monitor processes via the /proc directory, seeking privilege escalation opportunities without root access. The detection rule identifies suspicious openat syscalls targeting /proc, excluding benign processes, to flag potential misuse of pspy for process discovery. - -### Possible investigation steps - -- Review the process details associated with the alert, focusing on the process.pid and process.name fields to identify the process attempting to access the /proc directory. -- Investigate the host.id to determine if this activity is isolated to a single host or part of a broader pattern across multiple systems. -- Examine the process tree and parent processes of the flagged process to understand how it was initiated and if it is part of a legitimate workflow or potentially malicious activity. -- Check for any recent changes or installations on the host that might explain the presence of a tool like pspy, such as new software installations or updates. -- Correlate the timing of the alert with any other suspicious activities or alerts on the same host to identify potential lateral movement or privilege escalation attempts. -- Verify if the process name is a known benign process that might have been mistakenly excluded from the query, ensuring that the exclusion list is up-to-date and accurate. - -### False positive analysis - -- Frequent scanning by legitimate monitoring tools can trigger the rule. Identify and whitelist these tools by adding their process names to the exclusion list. -- System management scripts that regularly access the /proc directory may cause false positives. Review these scripts and exclude their process names if they are verified as non-threatening. -- Automated backup or security software that interacts with the /proc directory might be flagged. Confirm their legitimacy and add them to the exception list to prevent unnecessary alerts. -- Custom applications developed in-house that require access to the /proc directory for performance monitoring should be reviewed and excluded if they are deemed safe. -- Regularly update the exclusion list to reflect changes in legitimate software and tools used within the organization to minimize false positives. - -### Response and remediation - -- Immediately isolate the affected host from the network to prevent potential lateral movement by the adversary. -- Terminate any suspicious processes identified as using the pspy utility to halt further unauthorized process monitoring. -- Conduct a thorough review of the affected system's /proc directory access logs to identify any other unauthorized access attempts or anomalies. -- Reset credentials and review permissions for any accounts that may have been compromised or used in the attack to prevent further unauthorized access. -- Apply patches and updates to the affected system to address any vulnerabilities that may have been exploited for privilege escalation. -- Enhance monitoring and logging on the affected host to detect any future attempts to access the /proc directory using similar methods. -- Escalate the incident to the security operations team for further investigation and to determine if additional systems may be affected.""" [[rule.threat]] framework = "MITRE ATT&CK" diff --git a/rules/linux/discovery_subnet_scanning_activity_from_compromised_host.toml b/rules/linux/discovery_subnet_scanning_activity_from_compromised_host.toml index 317592c9790..09fec8276d7 100644 --- a/rules/linux/discovery_subnet_scanning_activity_from_compromised_host.toml +++ b/rules/linux/discovery_subnet_scanning_activity_from_compromised_host.toml @@ -2,7 +2,7 @@ creation_date = "2025/03/04" integration = ["endpoint"] maturity = "production" -updated_date = "2025/09/02" +updated_date = "2025/12/18" [rule] author = ["Elastic"] @@ -54,7 +54,7 @@ Subnet scanning is a reconnaissance method used by attackers to map network topo - Monitor network traffic closely for any signs of continued scanning or other suspicious activities from other hosts, indicating potential further compromise. - Escalate the incident to the security operations center (SOC) or incident response team for a comprehensive investigation and to determine if additional hosts are affected. """ -risk_score = 21 +risk_score = 47 rule_id = "860f2a03-a1cf-48d6-a674-c6d62ae608a1" setup = """## Setup @@ -81,7 +81,7 @@ For more details on Elastic Agent configuration settings, refer to the [helper g - To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. For more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html). """ -severity = "low" +severity = "medium" tags = [ "Domain: Endpoint", "OS: Linux", @@ -93,34 +93,52 @@ tags = [ timestamp_override = "event.ingested" type = "esql" query = ''' -from logs-endpoint.events.network-* -| keep @timestamp, host.os.type, event.type, event.action, process.executable, destination.ip, agent.id, host.name +from logs-endpoint.events.network-* metadata _id, _index, _version +| mv_expand event.action | where - @timestamp > now() - 1 hours and host.os.type == "linux" and event.type == "start" and event.action == "connection_attempted" and not ( - process.executable in ("/usr/local/bin/prometheus", "/app/extra/chrome") or + process.executable in ("/usr/local/bin/prometheus", "/app/extra/chrome", "/usr/lib/virtualbox/VBoxHeadless", "/usr/bin/prometheus") or process.executable like "/usr/local/prometheus/*/prometheus" or process.executable like "/usr/share/elastic-agent/*" or process.executable like "/var/lib/docker/overlay*connectord" or process.executable like "/opt/rumble/bin/rumble-agent*" or process.executable like "/opt/gitlab/*" or - process.executable like "/opt/google/chrome/chrome*" + process.executable like "/opt/google/chrome/chrome*" or + process.executable like "/snap/firefox/*/firefox" or + process.executable like "/var/lib/docker/overlay2/*/qbittorrent-nox" ) +| keep + @timestamp, + _id, + _index, + _version, + host.os.type, + event.type, + event.action, + process.executable, + destination.ip, + agent.id, + host.name, + event.dataset, + data_stream.namespace + | stats Esql.event_count = count(), Esql.destination_ip_count_distinct = count_distinct(destination.ip), Esql.agent_id_count_distinct = count_distinct(agent.id), Esql.host_name_values = values(host.name), - Esql.agent_id_values = values(agent.id) + Esql.agent_id_values = values(agent.id), + Esql.event_dataset_values = values(event.dataset), + Esql.data_stream_namespace_values = values(data_stream.namespace) by process.executable + | where Esql.agent_id_count_distinct == 1 and Esql.destination_ip_count_distinct > 250 | sort Esql.event_count asc -| limit 100 ''' [[rule.threat]] diff --git a/rules/linux/discovery_suid_sguid_enumeration.toml b/rules/linux/discovery_suid_sguid_enumeration.toml index dbd83aa0b45..ce279082884 100644 --- a/rules/linux/discovery_suid_sguid_enumeration.toml +++ b/rules/linux/discovery_suid_sguid_enumeration.toml @@ -2,7 +2,7 @@ creation_date = "2023/07/24" integration = ["endpoint"] maturity = "production" -updated_date = "2025/02/04" +updated_date = "2025/12/18" [rule] author = ["Elastic"] @@ -18,8 +18,41 @@ index = ["logs-endpoint.events.process*"] language = "eql" license = "Elastic License v2" name = "SUID/SGUID Enumeration Detected" +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + +### Investigating SUID/SGUID Enumeration Detected + +In Linux, SUID and SGID permissions allow programs to execute with elevated privileges, potentially exposing systems to privilege escalation if misconfigured. Adversaries exploit this by searching for binaries with these permissions to gain unauthorized access. The detection rule identifies suspicious use of the "find" command to locate such binaries, flagging potential misuse by monitoring specific command arguments and execution contexts. + +### Possible investigation steps + +- Review the process execution details to confirm the use of the "find" command with SUID/SGID permission arguments by checking the process.name and process.args fields. +- Identify the user and group context in which the command was executed by examining the user.Ext.real.id and group.Ext.real.id fields to determine if the command was run by a non-root user. +- Analyze the command's arguments to understand the scope of the search, focusing on the process.args field to see if specific directories or files were targeted. +- Check for any other suspicious activities or commands executed by the same user or process around the same time to identify potential follow-up actions or privilege escalation attempts. +- Investigate the system for any newly created or modified files with SUID/SGID permissions that could indicate successful privilege escalation or preparation for future attacks. + +### False positive analysis + +- System administrators or security tools may use the find command with SUID/SGID arguments for legitimate audits. To handle this, create exceptions for known administrative users or specific scripts that regularly perform these checks. +- Automated scripts or cron jobs might execute the find command with these arguments as part of routine maintenance tasks. Identify these scripts and exclude them from monitoring by specifying their process paths or user IDs. +- Some legitimate software installations or updates might temporarily use the find command with SUID/SGID arguments. Monitor installation logs and exclude these processes by correlating them with known software update activities. +- Developers or testers might use the find command in development environments to test security configurations. Exclude these environments from the rule by specifying their hostnames or IP addresses in the exception list. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent potential lateral movement by the adversary. +- Terminate any suspicious processes identified by the detection rule, particularly those involving the "find" command with SUID/SGID arguments. +- Conduct a thorough review of the system's SUID/SGID binaries to identify any misconfigurations or unauthorized changes. Remove or correct permissions on any binaries that are not required to have elevated privileges. +- Implement additional monitoring on the affected system to detect any further attempts to exploit SUID/SGID binaries, focusing on process execution and permission changes. +- Escalate the incident to the security operations team for a deeper forensic analysis to determine the scope of the compromise and identify any other affected systems. +- Apply patches and updates to the system and any vulnerable applications to mitigate known vulnerabilities that could be exploited through SUID/SGID binaries. +- Review and enhance access controls and privilege management policies to minimize the risk of privilege escalation through misconfigured binaries in the future.""" references = ["https://www.elastic.co/security-labs/primer-on-persistence-mechanisms"] -risk_score = 21 +risk_score = 47 rule_id = "5b06a27f-ad72-4499-91db-0c69667bffa5" setup = """## Setup @@ -46,7 +79,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", @@ -58,7 +91,6 @@ 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 == "find" and process.args : "-perm" and process.args : ( @@ -68,70 +100,38 @@ process.name == "find" and process.args : "-perm" and process.args : ( (process.args : "/usr/bin/pkexec" and process.args : "-xdev" and process.args_count == 7) ) ''' -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 SUID/SGUID Enumeration Detected - -In Linux, SUID and SGID permissions allow programs to execute with elevated privileges, potentially exposing systems to privilege escalation if misconfigured. Adversaries exploit this by searching for binaries with these permissions to gain unauthorized access. The detection rule identifies suspicious use of the "find" command to locate such binaries, flagging potential misuse by monitoring specific command arguments and execution contexts. - -### Possible investigation steps - -- Review the process execution details to confirm the use of the "find" command with SUID/SGID permission arguments by checking the process.name and process.args fields. -- Identify the user and group context in which the command was executed by examining the user.Ext.real.id and group.Ext.real.id fields to determine if the command was run by a non-root user. -- Analyze the command's arguments to understand the scope of the search, focusing on the process.args field to see if specific directories or files were targeted. -- Check for any other suspicious activities or commands executed by the same user or process around the same time to identify potential follow-up actions or privilege escalation attempts. -- Investigate the system for any newly created or modified files with SUID/SGID permissions that could indicate successful privilege escalation or preparation for future attacks. - -### False positive analysis - -- System administrators or security tools may use the find command with SUID/SGID arguments for legitimate audits. To handle this, create exceptions for known administrative users or specific scripts that regularly perform these checks. -- Automated scripts or cron jobs might execute the find command with these arguments as part of routine maintenance tasks. Identify these scripts and exclude them from monitoring by specifying their process paths or user IDs. -- Some legitimate software installations or updates might temporarily use the find command with SUID/SGID arguments. Monitor installation logs and exclude these processes by correlating them with known software update activities. -- Developers or testers might use the find command in development environments to test security configurations. Exclude these environments from the rule by specifying their hostnames or IP addresses in the exception list. - -### Response and remediation - -- Immediately isolate the affected system from the network to prevent potential lateral movement by the adversary. -- Terminate any suspicious processes identified by the detection rule, particularly those involving the "find" command with SUID/SGID arguments. -- Conduct a thorough review of the system's SUID/SGID binaries to identify any misconfigurations or unauthorized changes. Remove or correct permissions on any binaries that are not required to have elevated privileges. -- Implement additional monitoring on the affected system to detect any further attempts to exploit SUID/SGID binaries, focusing on process execution and permission changes. -- Escalate the incident to the security operations team for a deeper forensic analysis to determine the scope of the compromise and identify any other affected systems. -- Apply patches and updates to the system and any vulnerable applications to mitigate known vulnerabilities that could be exploited through SUID/SGID binaries. -- Review and enhance access controls and privilege management policies to minimize the risk of privilege escalation through misconfigured binaries in the future.""" - [[rule.threat]] framework = "MITRE ATT&CK" + [[rule.threat.technique]] id = "T1083" name = "File and Directory Discovery" reference = "https://attack.mitre.org/techniques/T1083/" - [rule.threat.tactic] id = "TA0007" name = "Discovery" reference = "https://attack.mitre.org/tactics/TA0007/" + [[rule.threat]] framework = "MITRE ATT&CK" + [[rule.threat.technique]] id = "T1548" name = "Abuse Elevation Control Mechanism" reference = "https://attack.mitre.org/techniques/T1548/" + [[rule.threat.technique.subtechnique]] id = "T1548.001" name = "Setuid and Setgid" reference = "https://attack.mitre.org/techniques/T1548/001/" - - [rule.threat.tactic] id = "TA0004" name = "Privilege Escalation" reference = "https://attack.mitre.org/tactics/TA0004/" + [[rule.threat]] framework = "MITRE ATT&CK" @@ -139,4 +139,3 @@ framework = "MITRE ATT&CK" id = "TA0003" name = "Persistence" reference = "https://attack.mitre.org/tactics/TA0003/" - diff --git a/rules/linux/discovery_suspicious_memory_grep_activity.toml b/rules/linux/discovery_suspicious_memory_grep_activity.toml index b54e11128bc..56148d7dbb8 100644 --- a/rules/linux/discovery_suspicious_memory_grep_activity.toml +++ b/rules/linux/discovery_suspicious_memory_grep_activity.toml @@ -1,8 +1,8 @@ [metadata] creation_date = "2024/02/05" -integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"] +integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel", "auditd_manager"] maturity = "production" -updated_date = "2025/03/20" +updated_date = "2025/12/18" [rule] author = ["Elastic"] @@ -13,10 +13,12 @@ read a process's memory map to identify memory addresses for code injection or p """ 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" @@ -57,14 +59,15 @@ In Linux, the `/proc/*/maps` file reveals a process's memory layout, crucial for - Implement stricter access controls and monitoring on sensitive files and directories, such as `/proc/*/maps`, to prevent unauthorized access. - Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to assess the need for broader organizational response measures.""" references = ["https://github.com/arget13/DDexec"] -risk_score = 21 +risk_score = 73 rule_id = "d74d6506-427a-4790-b170-0c2a6ddac799" -severity = "low" +severity = "high" tags = [ "Domain: Endpoint", "OS: Linux", "Use Case: Threat Detection", "Tactic: Discovery", + "Data Source: Auditd Manager", "Data Source: Elastic Defend", "Data Source: Elastic Endgame", "Data Source: Crowdstrike", @@ -73,24 +76,21 @@ 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 ("grep", "egrep", "fgrep", "rgrep") and process.args in ("[stack]", "[vdso]", "[heap]") +event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and +process.name in ("grep", "egrep", "fgrep", "rgrep") and process.args in ("[stack]", "[vdso]", "[heap]") ''' - [[rule.threat]] framework = "MITRE ATT&CK" + [[rule.threat.technique]] id = "T1057" name = "Process Discovery" reference = "https://attack.mitre.org/techniques/T1057/" - [rule.threat.tactic] id = "TA0007" name = "Discovery" reference = "https://attack.mitre.org/tactics/TA0007/" - diff --git a/rules/linux/discovery_suspicious_network_tool_launched_inside_container.toml b/rules/linux/discovery_suspicious_network_tool_launched_inside_container.toml index aaaa526247c..e78382373b9 100644 --- a/rules/linux/discovery_suspicious_network_tool_launched_inside_container.toml +++ b/rules/linux/discovery_suspicious_network_tool_launched_inside_container.toml @@ -2,7 +2,7 @@ creation_date = "2025/03/12" integration = ["endpoint"] maturity = "production" -updated_date = "2025/03/12" +updated_date = "2025/12/18" [rule] author = ["Elastic"] @@ -24,6 +24,39 @@ index = ["logs-endpoint.events.process*"] language = "eql" license = "Elastic License v2" name = "Suspicious Network Tool Launched 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 Network Tool Launched Inside A Container + +Containers are lightweight, portable units that encapsulate applications and their dependencies, often used to ensure consistent environments across development and production. Adversaries exploit network tools within containers for reconnaissance or lateral movement, leveraging utilities like `nc` or `nmap` to map networks or intercept traffic. The detection rule identifies these tools' execution by monitoring process starts and arguments, flagging potential misuse for further investigation. + +### Possible investigation steps + +- Examine the process arguments to understand the specific command or options used, which may provide insight into the intent of the tool's execution. +- Check the container's creation and modification timestamps to determine if the container was recently deployed or altered, which could indicate suspicious activity. +- Investigate the user or service account associated with the process start event to assess if it aligns with expected behavior or if it might be compromised. +- Analyze network logs and traffic patterns from the container to identify any unusual outbound connections or data exfiltration attempts. +- Correlate the alert with other security events or logs from the same container or host to identify potential lateral movement or further malicious activity. + +### False positive analysis + +- Development and testing environments often use network tools for legitimate purposes such as debugging or network configuration. To manage this, create exceptions for containers identified as part of these environments by tagging them appropriately and excluding them from the rule. +- Automated scripts or orchestration tools may trigger network utilities for routine checks or maintenance tasks. Identify these scripts and whitelist their associated container IDs or process names to prevent false alerts. +- Some monitoring solutions deploy containers with built-in network tools for performance analysis. Verify the legitimacy of these containers and exclude them from the rule by using specific labels or container IDs. +- Containers used for educational or training purposes might intentionally run network tools. Ensure these containers are marked and excluded from detection by setting up rules based on their unique identifiers or labels. + +### Response and remediation + +- Immediately isolate the affected container to prevent further network reconnaissance or lateral movement. This can be done by restricting its network access or stopping the container entirely. +- Conduct a thorough review of the container's logs and process history to identify any unauthorized access or data exfiltration attempts. Focus on the execution of the flagged network utilities. +- Remove any unauthorized or suspicious network tools from the container to prevent further misuse. Ensure that only necessary and approved utilities are present. +- Patch and update the container image to address any vulnerabilities that may have been exploited. Rebuild and redeploy the container using the updated image. +- Implement network segmentation to limit the container's access to sensitive resources and reduce the potential impact of similar threats in the future. +- Enhance monitoring and alerting for the execution of network utilities within containers, ensuring that any future occurrences are detected promptly. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems or containers have been compromised.""" references = ["https://sysdig.com/blog/cve-2021-25741-kubelet-falco/"] risk_score = 21 rule_id = "7290be75-2e10-49ec-b387-d4ed55b920ff" @@ -69,43 +102,11 @@ 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 ( - "nc.traditional", "nc", "ncat", "netcat", "nmap", "dig", "nslookup", "tcpdump", "tshark", "ngrep", "telnet", + "nc.traditional", "nc", "ncat", "netcat", "nmap", "tcpdump", "tshark", "ngrep", "telnet", "mitmproxy", "socat", "zmap", "masscan", "zgrab" -) +) and +not (process.name in ("nc.traditional", "nc", "ncat", "netcat") and process.args like ("-*z*", "localhost", "127.0.0.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 Suspicious Network Tool Launched Inside A Container - -Containers are lightweight, portable units that encapsulate applications and their dependencies, often used to ensure consistent environments across development and production. Adversaries exploit network tools within containers for reconnaissance or lateral movement, leveraging utilities like `nc` or `nmap` to map networks or intercept traffic. The detection rule identifies these tools' execution by monitoring process starts and arguments, flagging potential misuse for further investigation. - -### Possible investigation steps - -- Examine the process arguments to understand the specific command or options used, which may provide insight into the intent of the tool's execution. -- Check the container's creation and modification timestamps to determine if the container was recently deployed or altered, which could indicate suspicious activity. -- Investigate the user or service account associated with the process start event to assess if it aligns with expected behavior or if it might be compromised. -- Analyze network logs and traffic patterns from the container to identify any unusual outbound connections or data exfiltration attempts. -- Correlate the alert with other security events or logs from the same container or host to identify potential lateral movement or further malicious activity. - -### False positive analysis - -- Development and testing environments often use network tools for legitimate purposes such as debugging or network configuration. To manage this, create exceptions for containers identified as part of these environments by tagging them appropriately and excluding them from the rule. -- Automated scripts or orchestration tools may trigger network utilities for routine checks or maintenance tasks. Identify these scripts and whitelist their associated container IDs or process names to prevent false alerts. -- Some monitoring solutions deploy containers with built-in network tools for performance analysis. Verify the legitimacy of these containers and exclude them from the rule by using specific labels or container IDs. -- Containers used for educational or training purposes might intentionally run network tools. Ensure these containers are marked and excluded from detection by setting up rules based on their unique identifiers or labels. - -### Response and remediation - -- Immediately isolate the affected container to prevent further network reconnaissance or lateral movement. This can be done by restricting its network access or stopping the container entirely. -- Conduct a thorough review of the container's logs and process history to identify any unauthorized access or data exfiltration attempts. Focus on the execution of the flagged network utilities. -- Remove any unauthorized or suspicious network tools from the container to prevent further misuse. Ensure that only necessary and approved utilities are present. -- Patch and update the container image to address any vulnerabilities that may have been exploited. Rebuild and redeploy the container using the updated image. -- Implement network segmentation to limit the container's access to sensitive resources and reduce the potential impact of similar threats in the future. -- Enhance monitoring and alerting for the execution of network utilities within containers, ensuring that any future occurrences are detected promptly. -- Escalate the incident to the security operations team for further investigation and to determine if additional systems or containers have been compromised.""" [[rule.threat]] framework = "MITRE ATT&CK" diff --git a/rules/linux/discovery_unusual_user_enumeration_via_id.toml b/rules/linux/discovery_unusual_user_enumeration_via_id.toml index e37017ee7a4..e855e9a3297 100644 --- a/rules/linux/discovery_unusual_user_enumeration_via_id.toml +++ b/rules/linux/discovery_unusual_user_enumeration_via_id.toml @@ -2,7 +2,7 @@ creation_date = "2023/08/29" integration = ["endpoint"] maturity = "production" -updated_date = "2025/02/04" +updated_date = "2025/12/18" [rule] author = ["Elastic"] @@ -16,7 +16,41 @@ index = ["logs-endpoint.events.process*"] language = "eql" license = "Elastic License v2" name = "Unusual User Privilege Enumeration via id" -risk_score = 21 +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 Unusual User Privilege Enumeration via id + +The `id` command in Linux environments is used to display user identity information, including user and group IDs. Adversaries may exploit this command in enumeration scripts to gather extensive user privilege data rapidly, which can aid in lateral movement or privilege escalation. The detection rule identifies suspicious activity by flagging rapid, repeated executions of the `id` command, suggesting potential misuse by scripts like LinPEAS or LinEnum. + +### Possible investigation steps + +- Review the alert details to identify the specific host.id and process.parent.entity_id associated with the suspicious activity. +- Examine the parent process of the 'id' command executions to determine if it is a known or legitimate process, and check for any unusual or unexpected parent process names or arguments. +- Investigate the timeline of events on the affected host around the time of the alert to identify any other suspicious activities or related processes that may indicate a broader attack or script execution. +- Check the user account associated with the process executions to verify if it has legitimate access and if there are any signs of compromise or misuse. +- Look for any additional indicators of compromise on the host, such as unauthorized file modifications, network connections, or other unusual command executions, to assess the scope of potential malicious activity. + +### False positive analysis + +- System management scripts or automated tasks may execute the id command frequently for legitimate purposes. Review the parent process to determine if it is a known management tool or script. +- Software installation or update processes might trigger the rule if they use the id command to verify user permissions. Consider excluding processes with parent names like rpm or similar package managers. +- Custom scripts developed in-house for system monitoring or auditing could inadvertently match the rule's criteria. Identify these scripts and add exceptions for their parent process entity IDs. +- Security tools or compliance checks that perform regular user enumeration might cause false positives. Verify the source of these tools and exclude them if they are part of a trusted security suite. +- In environments with high user account turnover, scripts that manage user accounts might execute the id command in rapid succession. Evaluate these scripts and exclude them if they are part of routine account management. + +### Response and remediation + +- Immediately isolate the affected host from the network to prevent potential lateral movement by the adversary. +- Terminate any suspicious processes associated with the parent process identified in the alert to halt further enumeration activities. +- Conduct a thorough review of the parent process and its associated scripts to determine if they are legitimate or malicious. +- If malicious activity is confirmed, perform a comprehensive scan of the system for additional indicators of compromise, such as unauthorized user accounts or altered system files. +- Reset credentials for any user accounts that may have been exposed or compromised during the enumeration activity. +- Escalate the incident to the security operations team for further investigation and to assess the potential impact on other systems within the network. +- Implement enhanced monitoring and logging for similar enumeration activities to improve detection and response capabilities for future incidents.""" +risk_score = 47 rule_id = "afa135c0-a365-43ab-aa35-fd86df314a47" setup = """## Setup @@ -43,7 +77,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", @@ -53,62 +87,29 @@ tags = [ "Resources: Investigation Guide", ] type = "eql" - query = ''' sequence by host.id, process.parent.entity_id with maxspan=1s [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and process.name == "id" and process.args_count == 2 and not ( process.parent.name in ("rpm", "snarftmp", "quota_copy", "java") or - process.parent.args : "/var/tmp/rpm-tmp*" - )] with runs=20 + process.parent.args like ( + "/var/tmp/rpm-tmp*", "/tmp/netdata-kickstart.sh", "./k8s-certifikator.sh", "/usr/local/bin/docker-entrypoint.sh", + "./set_quota.sh" + ) or + (process.parent.name == "java" and process.args == "oracle") + )] with runs=20 ''' -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 Unusual User Privilege Enumeration via id - -The `id` command in Linux environments is used to display user identity information, including user and group IDs. Adversaries may exploit this command in enumeration scripts to gather extensive user privilege data rapidly, which can aid in lateral movement or privilege escalation. The detection rule identifies suspicious activity by flagging rapid, repeated executions of the `id` command, suggesting potential misuse by scripts like LinPEAS or LinEnum. - -### Possible investigation steps - -- Review the alert details to identify the specific host.id and process.parent.entity_id associated with the suspicious activity. -- Examine the parent process of the 'id' command executions to determine if it is a known or legitimate process, and check for any unusual or unexpected parent process names or arguments. -- Investigate the timeline of events on the affected host around the time of the alert to identify any other suspicious activities or related processes that may indicate a broader attack or script execution. -- Check the user account associated with the process executions to verify if it has legitimate access and if there are any signs of compromise or misuse. -- Look for any additional indicators of compromise on the host, such as unauthorized file modifications, network connections, or other unusual command executions, to assess the scope of potential malicious activity. - -### False positive analysis - -- System management scripts or automated tasks may execute the id command frequently for legitimate purposes. Review the parent process to determine if it is a known management tool or script. -- Software installation or update processes might trigger the rule if they use the id command to verify user permissions. Consider excluding processes with parent names like rpm or similar package managers. -- Custom scripts developed in-house for system monitoring or auditing could inadvertently match the rule's criteria. Identify these scripts and add exceptions for their parent process entity IDs. -- Security tools or compliance checks that perform regular user enumeration might cause false positives. Verify the source of these tools and exclude them if they are part of a trusted security suite. -- In environments with high user account turnover, scripts that manage user accounts might execute the id command in rapid succession. Evaluate these scripts and exclude them if they are part of routine account management. - -### Response and remediation - -- Immediately isolate the affected host from the network to prevent potential lateral movement by the adversary. -- Terminate any suspicious processes associated with the parent process identified in the alert to halt further enumeration activities. -- Conduct a thorough review of the parent process and its associated scripts to determine if they are legitimate or malicious. -- If malicious activity is confirmed, perform a comprehensive scan of the system for additional indicators of compromise, such as unauthorized user accounts or altered system files. -- Reset credentials for any user accounts that may have been exposed or compromised during the enumeration activity. -- Escalate the incident to the security operations team for further investigation and to assess the potential impact on other systems within the network. -- Implement enhanced monitoring and logging for similar enumeration activities to improve detection and response capabilities for future incidents.""" - [[rule.threat]] framework = "MITRE ATT&CK" + [[rule.threat.technique]] id = "T1033" name = "System Owner/User Discovery" reference = "https://attack.mitre.org/techniques/T1033/" - [rule.threat.tactic] id = "TA0007" name = "Discovery" reference = "https://attack.mitre.org/tactics/TA0007/" - diff --git a/rules/linux/discovery_virtual_machine_fingerprinting.toml b/rules/linux/discovery_virtual_machine_fingerprinting.toml index 67706d07b72..db90a1ad7af 100644 --- a/rules/linux/discovery_virtual_machine_fingerprinting.toml +++ b/rules/linux/discovery_virtual_machine_fingerprinting.toml @@ -1,8 +1,8 @@ [metadata] creation_date = "2020/04/27" -integration = ["endpoint", "crowdstrike"] +integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel", "auditd_manager"] maturity = "production" -updated_date = "2025/10/17" +updated_date = "2025/12/18" [rule] author = ["Elastic"] @@ -18,10 +18,52 @@ false_positives = [ """, ] from = "now-9m" -index = ["auditbeat-*", "logs-endpoint.events.*", "endgame-*", "logs-crowdstrike.fdr*"] -language = "kuery" +index = [ + "auditbeat-*", + "endgame-*", + "logs-endpoint.events.*", + "logs-crowdstrike.fdr*", + "logs-sentinel_one_cloud_funnel.*", + "logs-auditd_manager.auditd-*", +] +language = "eql" license = "Elastic License v2" name = "Virtual Machine Fingerprinting" +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 Virtual Machine Fingerprinting + +Virtual Machine Fingerprinting involves identifying characteristics of a virtual environment, often to tailor attacks or evade detection. Adversaries exploit this by querying system files for hardware details, a tactic seen in malware like Pupy RAT. The detection rule flags non-root users accessing specific Linux paths indicative of VM queries, signaling potential reconnaissance activities. + +### Possible investigation steps + +- Review the process execution details to identify the non-root user involved in accessing the specified paths, focusing on the user.name field. +- Examine the process.args field to determine which specific file paths were accessed, as this can indicate the type of virtual machine information being targeted. +- Investigate the parent process and command line arguments to understand the context of the process initiation and whether it aligns with legitimate user activity. +- Check for any related alerts or logs around the same timeframe to identify potential patterns or repeated attempts at virtual machine fingerprinting. +- Assess the system for any signs of compromise or unauthorized access, particularly focusing on the presence of known malware like Pupy RAT or similar threats. +- Correlate the findings with MITRE ATT&CK framework references (TA0007, T1082) to understand the broader tactics and techniques potentially in use by the adversary. + +### False positive analysis + +- Non-root users running legitimate scripts or applications that query system files for hardware information may trigger the rule. Review the context of the process and user activity to determine if it aligns with expected behavior. +- System administrators or developers using automated tools for inventory or monitoring purposes might access these paths. Consider creating exceptions for known tools or scripts that are verified as safe. +- Security or compliance audits conducted by non-root users could inadvertently match the rule's criteria. Document and whitelist these activities if they are part of regular operations. +- Development environments where virtual machine detection is part of testing processes may cause false positives. Identify and exclude these environments from the rule's scope if they are consistently flagged. +- Regularly review and update the list of exceptions to ensure that only verified and necessary exclusions are maintained, minimizing the risk of overlooking genuine threats. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further reconnaissance or potential lateral movement by the adversary. +- Terminate any suspicious processes identified in the alert that are attempting to access the specified system files, especially those not initiated by the root user. +- Conduct a thorough review of recent user activity and process logs to identify any unauthorized access or anomalies that may indicate further compromise. +- Reset credentials for any non-root users involved in the alert to prevent unauthorized access, and review user permissions to ensure least privilege principles are enforced. +- Deploy endpoint detection and response (EDR) tools to monitor for similar suspicious activities and enhance visibility into system processes and user actions. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. +- Implement additional monitoring and alerting for the specific file paths and processes identified in the query to detect and respond to future attempts at virtual machine fingerprinting.""" risk_score = 73 rule_id = "5b03c9fb-9945-4d2f-9568-fd690fee3fba" setup = """## Setup @@ -69,68 +111,38 @@ tags = [ "Tactic: Discovery", "Data Source: Elastic Endgame", "Data Source: Elastic Defend", - "Resources: Investigation Guide", "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.args:("/sys/class/dmi/id/bios_version" or - "/sys/class/dmi/id/product_name" or - "/sys/class/dmi/id/chassis_vendor" or - "/proc/scsi/scsi" or - "/proc/ide/hd0/model") and - not user.name:root +process where host.os.type == "linux" and event.type == "start" and +event.action in ("exec", "exec_event", "start", "ProcessRollup2", "process_started") and +process.args in ( + "/sys/class/dmi/id/bios_version", "/sys/class/dmi/id/product_name", "/sys/class/dmi/id/chassis_vendor", + "/proc/scsi/scsi", "/proc/ide/hd0/model" +) and not ( + user.name == "root" or + ?process.parent.name in ("LinkManager.exe", "saposcol", "svc_snow_discovery") or + ?process.working_directory == "/home/qualys" or + ?process.parent.executable in ( + "/usr/sara/sbin/sys2prometheus", "/usr/sara/sbin/sys2ganglia", "/usr/libexec/valgrind/memcheck-amd64-linux", + "/var/lib/cfengine3/modules/init_node", "/opt/emby-server/system/EmbyServer" + ) +) ''' -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 Virtual Machine Fingerprinting - -Virtual Machine Fingerprinting involves identifying characteristics of a virtual environment, often to tailor attacks or evade detection. Adversaries exploit this by querying system files for hardware details, a tactic seen in malware like Pupy RAT. The detection rule flags non-root users accessing specific Linux paths indicative of VM queries, signaling potential reconnaissance activities. - -### Possible investigation steps - -- Review the process execution details to identify the non-root user involved in accessing the specified paths, focusing on the user.name field. -- Examine the process.args field to determine which specific file paths were accessed, as this can indicate the type of virtual machine information being targeted. -- Investigate the parent process and command line arguments to understand the context of the process initiation and whether it aligns with legitimate user activity. -- Check for any related alerts or logs around the same timeframe to identify potential patterns or repeated attempts at virtual machine fingerprinting. -- Assess the system for any signs of compromise or unauthorized access, particularly focusing on the presence of known malware like Pupy RAT or similar threats. -- Correlate the findings with MITRE ATT&CK framework references (TA0007, T1082) to understand the broader tactics and techniques potentially in use by the adversary. - -### False positive analysis - -- Non-root users running legitimate scripts or applications that query system files for hardware information may trigger the rule. Review the context of the process and user activity to determine if it aligns with expected behavior. -- System administrators or developers using automated tools for inventory or monitoring purposes might access these paths. Consider creating exceptions for known tools or scripts that are verified as safe. -- Security or compliance audits conducted by non-root users could inadvertently match the rule's criteria. Document and whitelist these activities if they are part of regular operations. -- Development environments where virtual machine detection is part of testing processes may cause false positives. Identify and exclude these environments from the rule's scope if they are consistently flagged. -- Regularly review and update the list of exceptions to ensure that only verified and necessary exclusions are maintained, minimizing the risk of overlooking genuine threats. - -### Response and remediation - -- Immediately isolate the affected system from the network to prevent further reconnaissance or potential lateral movement by the adversary. -- Terminate any suspicious processes identified in the alert that are attempting to access the specified system files, especially those not initiated by the root user. -- Conduct a thorough review of recent user activity and process logs to identify any unauthorized access or anomalies that may indicate further compromise. -- Reset credentials for any non-root users involved in the alert to prevent unauthorized access, and review user permissions to ensure least privilege principles are enforced. -- Deploy endpoint detection and response (EDR) tools to monitor for similar suspicious activities and enhance visibility into system processes and user actions. -- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. -- Implement additional monitoring and alerting for the specific file paths and processes identified in the query to detect and respond to future attempts at virtual machine fingerprinting.""" - [[rule.threat]] framework = "MITRE ATT&CK" + [[rule.threat.technique]] id = "T1082" name = "System Information Discovery" reference = "https://attack.mitre.org/techniques/T1082/" - [rule.threat.tactic] id = "TA0007" name = "Discovery" reference = "https://attack.mitre.org/tactics/TA0007/" - diff --git a/rules/linux/discovery_yum_dnf_plugin_detection.toml b/rules/linux/discovery_yum_dnf_plugin_detection.toml index b43625cf4a5..2d0397313ad 100644 --- a/rules/linux/discovery_yum_dnf_plugin_detection.toml +++ b/rules/linux/discovery_yum_dnf_plugin_detection.toml @@ -1,8 +1,8 @@ [metadata] creation_date = "2024/06/25" -integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"] +integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel", "auditd_manager"] maturity = "production" -updated_date = "2025/03/20" +updated_date = "2025/12/18" [rule] author = ["Elastic"] @@ -13,10 +13,12 @@ attempting to establish persistence in a YUM or DNF plugin. """ 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" @@ -88,6 +90,7 @@ tags = [ "OS: Linux", "Use Case: Threat Detection", "Tactic: Discovery", + "Data Source: Auditd Manager", "Data Source: Elastic Defend", "Data Source: Elastic Endgame", "Data Source: Crowdstrike", @@ -96,27 +99,25 @@ 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 == "grep" and process.args : "plugins*" and process.args : ( - "/etc/yum.conf", "/usr/lib/yum-plugins/*", "/etc/yum/pluginconf.d/*", - "/usr/lib/python*/site-packages/dnf-plugins/*", "/etc/dnf/plugins/*", "/etc/dnf/dnf.conf" - ) +event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and +process.name == "grep" and process.args : "plugins*" and process.args like ( + "/etc/yum.conf", "/usr/lib/yum-plugins/*", "/etc/yum/pluginconf.d/*", + "/usr/lib/python*/site-packages/dnf-plugins/*", "/etc/dnf/plugins/*", "/etc/dnf/dnf.conf" +) and +not ?process.parent.executable == "/usr/lib/venv-salt-minion/bin/python.original" ''' - [[rule.threat]] framework = "MITRE ATT&CK" + [[rule.threat.technique]] id = "T1082" name = "System Information Discovery" reference = "https://attack.mitre.org/techniques/T1082/" - [rule.threat.tactic] id = "TA0007" name = "Discovery" reference = "https://attack.mitre.org/tactics/TA0007/" -