security-tools/sigma-rules
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

[Rule Tuning] Linux DR Tuning - 10 (#5510)

Browse Source 
* [Rule Tuning] Linux DR Tuning - 10

* Update persistence_udev_rule_creation.toml

* Refactor ESQL query for Linux process events

* Refactor query in persistence_web_server_sus_command_execution rule

Removed unnecessary fields from the query and added new fields for event dataset and data stream namespace.

* Update persistence_systemd_netcon.toml

* Update persistence_web_server_sus_child_spawned.toml

* Refactor process.parent.name conditions in TOML file

* Update persistence_web_server_unusual_command_execution.toml

* Update persistence_web_server_unusual_command_execution.toml

---------

Co-authored-by: Colson Wilhoit <48036388+DefSecSentinel@users.noreply.github.com>
This commit is contained in:
Ruben Groenewoud
2026-01-08 09:32:57 +01:00
committed by GitHub
parent f98f4e5a95
commit d968f62a5a
22 changed files with 670 additions and 646 deletions
Download Patch File Download Diff File Expand all files Collapse all files
rules/linux/persistence_suspicious_ssh_execution_xzbackdoor.toml
+43 -40
View File
@@ -2,7 +2,7 @@
creation_date = "2024/04/01"
integration = ["endpoint"]
maturity = "production"
updated_date = "2025/12/17"
updated_date = "2025/12/23"
[rule]
author = ["Elastic"]
@@ -14,51 +14,15 @@ from = "now-9m"
index = ["logs-endpoint.events.network*", "logs-endpoint.events.process*"]
language = "eql"
license = "Elastic License v2"
name = "Potential Execution via XZBackdoor"
references = [
"https://github.com/amlweems/xzbot",
"https://access.redhat.com/security/cve/CVE-2024-3094",
"https://www.elastic.co/security-labs/500ms-to-midnight",
]
risk_score = 73
rule_id = "7afc6cc9-8800-4c7f-be6b-b688d2dea248"
severity = "high"
tags = [
"Domain: Endpoint",
"OS: Linux",
"Use Case: Threat Detection",
"Tactic: Credential Access",
"Tactic: Persistence",
"Tactic: Lateral Movement",
"Data Source: Elastic Defend",
"Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"
query = '''
sequence by host.id with maxspan=1m
[process where host.os.type == "linux" and event.action == "end" and process.name == "sshd" and process.exit_code != 0 and
process.command_line == "/usr/sbin/sshd -D -R" and process.parent.command_line == "sshd: /usr/sbin/sshd -D [listener] 0 of 10-100 startups"] by process.entity_id
[process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and
process.parent.name == "sshd" and process.parent.command_line == "/usr/sbin/sshd -D -R" and
process.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and process.args == "-c" and
not process.executable in ("/usr/sbin/sshd", "/sbin/unix_chkpwd") and
not (
process.args like ("rsync*", "systemctl*", "/usr/sbin/unix_chkpwd", "/usr/bin/google_authorized_keys", "/usr/sbin/aad_certhandler*",
"bash -c bash -s", "/usr/lib/ssh/sftp-server", "stat /etc/is_upgrade_install > /dev/null 2>&1",
"stat /opt/qradar/ha/.*", "/usr/bin/env -i PATH=*", "/opt/gitlab/embedded/service/gitlab-shell/bin/gitlab-shell key*",
"test -e /*", "md5sum*", "check_mk_agent") or
process.command_line like ("sh -c /usr/bin/env -i PATH=*", "sh -c -- /usr/bin/env -i PATH=*", "*/root/.ansible/tmp/ansible-tmp*")
)] by process.parent.entity_id
'''
name = "Potential Execution via SSH Backdoor"
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 Execution via XZBackdoor
### Investigating Potential Execution via SSH Backdoor
The XZBackdoor leverages SSH, a secure protocol for remote access, to execute malicious commands stealthily. Adversaries exploit SSH by initiating sessions that mimic legitimate activity, then abruptly terminate them post-execution to evade detection. The detection rule identifies anomalies by tracking SSH processes that start and end unexpectedly, especially when non-standard executables are invoked, signaling potential backdoor activity.
Linux SSH backdoors, such as the XZBackdoor, leverage SSH, a secure protocol for remote access, to execute malicious commands stealthily. Adversaries exploit SSH by initiating sessions that mimic legitimate activity, then abruptly terminate them post-execution to evade detection. The detection rule identifies anomalies by tracking SSH processes that start and end unexpectedly, especially when non-standard executables are invoked, signaling potential backdoor activity.
### Possible investigation steps
@@ -85,6 +49,45 @@ The XZBackdoor leverages SSH, a secure protocol for remote access, to execute ma
- Restore the affected system from a known good backup if any unauthorized changes or malware are detected.
- Implement network segmentation to limit SSH access to critical systems and reduce the attack surface.
- Escalate the incident to the security operations center (SOC) for further investigation and to determine if additional systems are compromised."""
references = [
"https://github.com/amlweems/xzbot",
"https://access.redhat.com/security/cve/CVE-2024-3094",
"https://www.elastic.co/security-labs/500ms-to-midnight",
]
risk_score = 47
rule_id = "7afc6cc9-8800-4c7f-be6b-b688d2dea248"
severity = "medium"
tags = [
"Domain: Endpoint",
"OS: Linux",
"Use Case: Threat Detection",
"Tactic: Credential Access",
"Tactic: Persistence",
"Tactic: Lateral Movement",
"Data Source: Elastic Defend",
"Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"
query = '''
sequence by host.id with maxspan=1m
[process where host.os.type == "linux" and event.action == "end" and process.name == "sshd" and process.exit_code != 0 and
process.command_line == "/usr/sbin/sshd -D -R" and process.parent.command_line == "sshd: /usr/sbin/sshd -D [listener] 0 of 10-100 startups"] by process.entity_id
[process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and
process.parent.name == "sshd" and process.parent.command_line == "/usr/sbin/sshd -D -R" and
process.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and process.args == "-c" and not (
process.args like (
"rsync*", "systemctl*", "/usr/sbin/unix_chkpwd", "/usr/bin/google_authorized_keys", "/usr/sbin/aad_certhandler*",
"bash -c bash -s", "/usr/lib/ssh/sftp-server", "stat /etc/is_upgrade_install > /dev/null 2>&1",
"stat /opt/qradar/ha/.*", "/usr/bin/env -i PATH=*", "/opt/gitlab/*", "clamdscan*", "wc*", "export*",
"test*", "md5sum*", "check_mk_agent", "/usr/bin/env*", "/usr/bin/check_mk_agent", "timeout*", "/usr/sbin/haproxy*",
"/usr/libexec/openssh/sftp-server", "command*", "find*", "cd *", "scp*", "while*", "pvesh*", "/bin/true",
"/usr/sbin/qm mtunnel", "multipath*", "/usr/lib/openssh/sftp-server"
) or
process.command_line like ("sh -c /usr/bin/env -i PATH=*", "sh -c -- /usr/bin/env -i PATH=*", "*ansible*", "*BECOME-SUCCESS*")
)
] by process.parent.entity_id
'''
[[rule.threat]]
framework = "MITRE ATT&CK"
rules/linux/persistence_systemd_generator_creation.toml
+41 -36
View File
@@ -2,7 +2,7 @@
creation_date = "2024/06/19"
integration = ["endpoint"]
maturity = "production"
updated_date = "2025/01/24"
updated_date = "2025/12/23"
[rule]
author = ["Elastic"]
@@ -18,6 +18,40 @@ index = ["logs-endpoint.events.file*"]
language = "eql"
license = "Elastic License v2"
name = "Systemd Generator Created"
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 Systemd Generator Created
Systemd generators are scripts that systemd runs at boot or during configuration reloads to convert non-native configurations into unit files. Adversaries can exploit this by creating malicious generators to execute arbitrary code, ensuring persistence or escalating privileges. The detection rule identifies suspicious generator file creations or renames, excluding benign processes and file types, to flag potential abuse.
### Possible investigation steps
- Review the file path where the generator was created or renamed to determine if it is located in a standard systemd generator directory, such as /run/systemd/system-generators/ or /etc/systemd/user-generators/.
- Identify the process that created or renamed the generator file by examining the process.executable field, and determine if it is a known benign process or potentially malicious.
- Check the file extension and original extension fields to ensure the file is not a temporary or expected system file, such as those with extensions like "swp" or "dpkg-new".
- Investigate the history and behavior of the process that created the generator file, including any associated network connections or file modifications, to assess if it exhibits signs of malicious activity.
- Correlate the event with other security alerts or logs from the same host to identify any patterns or additional indicators of compromise that might suggest persistence or privilege escalation attempts.
### False positive analysis
- Package managers like dpkg, rpm, and yum can trigger false positives when they create or rename files in systemd generator directories during software installations or updates. To handle these, exclude processes associated with these package managers as specified in the rule.
- Automated system management tools such as Puppet and Chef may also create or modify generator files as part of their configuration management tasks. Exclude these processes by adding them to the exception list if they are part of your environment.
- Temporary files with extensions like swp, swpx, and swx, often created by text editors, can be mistakenly flagged. Ensure these extensions are included in the exclusion list to prevent unnecessary alerts.
- System updates or maintenance scripts that run as part of regular operations might create or modify generator files. Identify these scripts and add their executables to the exclusion list to reduce false positives.
- Custom scripts or tools that are part of legitimate administrative tasks may also trigger alerts. Review these scripts and consider excluding their executables if they are verified as non-malicious.
### Response and remediation
- Immediately isolate the affected system from the network to prevent further execution of potentially malicious code and lateral movement.
- Terminate any suspicious processes associated with the creation or modification of systemd generator files to halt any ongoing malicious activity.
- Conduct a thorough review of the systemd generator directories to identify and remove any unauthorized or suspicious generator files.
- Restore any modified or deleted legitimate systemd generator files from a known good backup to ensure system integrity.
- Implement file integrity monitoring on systemd generator directories to detect unauthorized changes in the future.
- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected.
- Review and update access controls and permissions for systemd generator directories to limit the ability to create or modify files to authorized users only."""
references = [
"https://pberba.github.io/security/2022/02/07/linux-threat-hunting-for-persistence-systemd-generators/",
"https://www.elastic.co/security-labs/primer-on-persistence-mechanisms",
@@ -77,7 +111,12 @@ file where host.os.type == "linux" and event.action in ("rename", "creation") an
"/usr/local/sbin/apk", "/usr/bin/apt", "/usr/sbin/pacman", "/bin/podman", "/usr/bin/podman", "/usr/bin/puppet",
"/bin/puppet", "/opt/puppetlabs/puppet/bin/puppet", "/usr/bin/chef-client", "/bin/chef-client", "/usr/sbin/sshd",
"/bin/autossl_check", "/usr/bin/autossl_check", "/proc/self/exe", "/dev/fd/*", "/usr/bin/pamac-daemon",
"/bin/pamac-daemon", "/usr/lib/snapd/snapd", "/usr/local/bin/dockerd", "/usr/libexec/platform-python"
"/bin/pamac-daemon", "/usr/lib/snapd/snapd", "/usr/local/bin/dockerd", "/usr/libexec/platform-python",
"./usr/bin/podman", "/usr/lib/dracut/dracut-install", "/usr/bin/dnf5", "/usr/libexec/packagekitd", "/usr/sbin/dnf",
"/kaniko/executor", "/dev/fd/3", "/usr/local/bin/defender", "./usr/bin/qemu-aarch64-static", "/usr/sbin/yum"
) or
process.executable like (
"/snap/docker/*/bin/dockerd", "/var/lib/docker/overlay2/*/dockerd", "/var/lib/containers/storage/overlay/*/dockerd"
) or
process.name like~ ("ssm-agent-worker", "crio", "docker-init", "systemd", "pacman", "python*", "platform-python*") or
file.extension in ("swp", "swpx", "swx", "dpkg-remove") or
@@ -85,40 +124,6 @@ file where host.os.type == "linux" and event.action in ("rename", "creation") an
process.executable == null
)
'''
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 Systemd Generator Created
Systemd generators are scripts that systemd runs at boot or during configuration reloads to convert non-native configurations into unit files. Adversaries can exploit this by creating malicious generators to execute arbitrary code, ensuring persistence or escalating privileges. The detection rule identifies suspicious generator file creations or renames, excluding benign processes and file types, to flag potential abuse.
### Possible investigation steps
- Review the file path where the generator was created or renamed to determine if it is located in a standard systemd generator directory, such as /run/systemd/system-generators/ or /etc/systemd/user-generators/.
- Identify the process that created or renamed the generator file by examining the process.executable field, and determine if it is a known benign process or potentially malicious.
- Check the file extension and original extension fields to ensure the file is not a temporary or expected system file, such as those with extensions like "swp" or "dpkg-new".
- Investigate the history and behavior of the process that created the generator file, including any associated network connections or file modifications, to assess if it exhibits signs of malicious activity.
- Correlate the event with other security alerts or logs from the same host to identify any patterns or additional indicators of compromise that might suggest persistence or privilege escalation attempts.
### False positive analysis
- Package managers like dpkg, rpm, and yum can trigger false positives when they create or rename files in systemd generator directories during software installations or updates. To handle these, exclude processes associated with these package managers as specified in the rule.
- Automated system management tools such as Puppet and Chef may also create or modify generator files as part of their configuration management tasks. Exclude these processes by adding them to the exception list if they are part of your environment.
- Temporary files with extensions like swp, swpx, and swx, often created by text editors, can be mistakenly flagged. Ensure these extensions are included in the exclusion list to prevent unnecessary alerts.
- System updates or maintenance scripts that run as part of regular operations might create or modify generator files. Identify these scripts and add their executables to the exclusion list to reduce false positives.
- Custom scripts or tools that are part of legitimate administrative tasks may also trigger alerts. Review these scripts and consider excluding their executables if they are verified as non-malicious.
### Response and remediation
- Immediately isolate the affected system from the network to prevent further execution of potentially malicious code and lateral movement.
- Terminate any suspicious processes associated with the creation or modification of systemd generator files to halt any ongoing malicious activity.
- Conduct a thorough review of the systemd generator directories to identify and remove any unauthorized or suspicious generator files.
- Restore any modified or deleted legitimate systemd generator files from a known good backup to ensure system integrity.
- Implement file integrity monitoring on systemd generator directories to detect unauthorized changes in the future.
- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected.
- Review and update access controls and permissions for systemd generator directories to limit the ability to create or modify files to authorized users only."""
[[rule.threat]]
framework = "MITRE ATT&CK"
rules/linux/persistence_systemd_netcon.toml
+42 -38
View File
@@ -2,7 +2,7 @@
creation_date = "2024/02/01"
integration = ["endpoint"]
maturity = "production"
updated_date = "2025/12/09"
updated_date = "2025/12/23"
[rule]
author = ["Elastic"]
@@ -18,6 +18,41 @@ index = ["logs-endpoint.events.network*", "logs-endpoint.events.process*"]
language = "eql"
license = "Elastic License v2"
name = "Suspicious Network Connection via systemd"
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 Connection via systemd
Systemd is a critical component in Linux, managing system processes and services. Adversaries exploit it by altering unit files or replacing binaries to ensure malicious scripts run at startup, achieving persistence. The detection rule identifies unusual network activities initiated by systemd, flagging potential backdoor usage by monitoring specific processes and network attempts, thus aiding in early threat detection.
### Possible investigation steps
- Review the process details to identify the specific script or command executed by systemd, focusing on the process names such as "python*", "php*", "perl", "ruby", "lua*", "openssl", "nc", "netcat", "ncat", "telnet", "awk".
- Examine the parent process information to confirm that the suspicious process was indeed initiated by systemd, ensuring the parent process name is "systemd".
- Investigate the network connection attempt details, including the destination IP address and port, to determine if the connection is to a known malicious or suspicious endpoint.
- Check the process executable path to ensure it is not a known legitimate path, especially looking for unusual paths that might indicate a compromised binary, excluding "/tmp/newroot/bin/curl".
- Analyze the systemd unit files on the host to identify any unauthorized modifications or additions that could indicate persistence mechanisms.
- Correlate the event with other security alerts or logs from the same host to identify any patterns or additional indicators of compromise.
- Consult threat intelligence sources to gather more context on the IP addresses or domains involved in the network connection attempt.
### False positive analysis
- Legitimate administrative scripts or maintenance tasks that use scripting languages like Python, PHP, or Perl may trigger the rule. To handle this, identify and document these scripts, then create exceptions for their specific process names or paths.
- Automated system monitoring tools that perform network checks using utilities like netcat or telnet might be flagged. Review these tools and whitelist their process names or executable paths to prevent false alerts.
- Custom applications or services that are legitimately started by systemd and initiate network connections could be misidentified. Verify these applications and add them to an allowlist based on their process names or parent entity IDs.
- Development or testing environments where developers frequently use scripting languages for network operations may cause false positives. Consider excluding these environments from monitoring or creating specific rules that account for their unique behaviors.
### Response and remediation
- Isolate the affected host immediately from the network to prevent further malicious activity and lateral movement.
- Terminate any suspicious processes identified in the alert, particularly those initiated by systemd that match the specified process names (e.g., python, php, perl).
- Review and restore any modified or suspicious systemd unit files to their original state, ensuring no unauthorized scripts or commands are set to execute at startup.
- Conduct a thorough scan of the affected system for additional indicators of compromise, focusing on persistence mechanisms and unauthorized network connections.
- Reinstall or verify the integrity of systemd binaries to ensure they have not been replaced or tampered with by malicious actors.
- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected.
- Implement enhanced monitoring and logging for systemd-related activities and network connections to detect similar threats in the future."""
risk_score = 47
rule_id = "f3818c85-2207-4b51-8a28-d70fb156ee87"
setup = """## Setup
@@ -64,7 +99,7 @@ sequence by host.id with maxspan=5s
process.parent.name == "systemd" and (
process.name in (
"openssl", "nc", "ncat", "netcat", "nc.openbsd", "nc.traditional", "socat", "busybox", "mkfifo",
"nohup", "setsid", "xterm", "telnet", "awk"
"nohup", "setsid", "xterm", "telnet"
) or
(process.name : "python*" and process.args : "-c" and process.args : (
"*import*pty*spawn*", "*import*subprocess*call*"
@@ -85,47 +120,16 @@ sequence by host.id with maxspan=5s
) and
not (
process.args in ("/usr/bin/pg_ctlcluster", "/usr/bin/pveproxy", "/usr/sbin/pveum", "/usr/bin/pveupdate") or
process.executable like ("/usr/local/cpanel/*/bin/perl", "/opt/puppetlabs/puppet/bin/ruby")
process.executable like ("/usr/local/cpanel/*/bin/perl", "/opt/puppetlabs/puppet/bin/ruby") or
process.command_line in (
"/usr/bin/perl /usr/sbin/pveum realm sync planet",
"/usr/bin/perl -T /usr/bin/pveproxy start", "/usr/bin/perl /usr/bin/pveupdate"
)
)
] by process.entity_id
[network where host.os.type == "linux" and event.action == "connection_attempted" and event.type == "start" and
not process.executable == "/tmp/newroot/bin/curl"] by process.parent.entity_id
'''
note = """## Triage and analysis
> **Disclaimer**:
> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
### Investigating Suspicious Network Connection via systemd
Systemd is a critical component in Linux, managing system processes and services. Adversaries exploit it by altering unit files or replacing binaries to ensure malicious scripts run at startup, achieving persistence. The detection rule identifies unusual network activities initiated by systemd, flagging potential backdoor usage by monitoring specific processes and network attempts, thus aiding in early threat detection.
### Possible investigation steps
- Review the process details to identify the specific script or command executed by systemd, focusing on the process names such as "python*", "php*", "perl", "ruby", "lua*", "openssl", "nc", "netcat", "ncat", "telnet", "awk".
- Examine the parent process information to confirm that the suspicious process was indeed initiated by systemd, ensuring the parent process name is "systemd".
- Investigate the network connection attempt details, including the destination IP address and port, to determine if the connection is to a known malicious or suspicious endpoint.
- Check the process executable path to ensure it is not a known legitimate path, especially looking for unusual paths that might indicate a compromised binary, excluding "/tmp/newroot/bin/curl".
- Analyze the systemd unit files on the host to identify any unauthorized modifications or additions that could indicate persistence mechanisms.
- Correlate the event with other security alerts or logs from the same host to identify any patterns or additional indicators of compromise.
- Consult threat intelligence sources to gather more context on the IP addresses or domains involved in the network connection attempt.
### False positive analysis
- Legitimate administrative scripts or maintenance tasks that use scripting languages like Python, PHP, or Perl may trigger the rule. To handle this, identify and document these scripts, then create exceptions for their specific process names or paths.
- Automated system monitoring tools that perform network checks using utilities like netcat or telnet might be flagged. Review these tools and whitelist their process names or executable paths to prevent false alerts.
- Custom applications or services that are legitimately started by systemd and initiate network connections could be misidentified. Verify these applications and add them to an allowlist based on their process names or parent entity IDs.
- Development or testing environments where developers frequently use scripting languages for network operations may cause false positives. Consider excluding these environments from monitoring or creating specific rules that account for their unique behaviors.
### Response and remediation
- Isolate the affected host immediately from the network to prevent further malicious activity and lateral movement.
- Terminate any suspicious processes identified in the alert, particularly those initiated by systemd that match the specified process names (e.g., python, php, perl).
- Review and restore any modified or suspicious systemd unit files to their original state, ensuring no unauthorized scripts or commands are set to execute at startup.
- Conduct a thorough scan of the affected system for additional indicators of compromise, focusing on persistence mechanisms and unauthorized network connections.
- Reinstall or verify the integrity of systemd binaries to ensure they have not been replaced or tampered with by malicious actors.
- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected.
- Implement enhanced monitoring and logging for systemd-related activities and network connections to detect similar threats in the future."""
[[rule.threat]]
framework = "MITRE ATT&CK"
rules/linux/persistence_systemd_scheduled_timer_created.toml
+10 -6
View File
@@ -2,7 +2,7 @@
creation_date = "2023/02/24"
integration = ["endpoint"]
maturity = "production"
updated_date = "2025/02/03"
updated_date = "2025/12/23"
[transform]
[[transform.osquery]]
@@ -169,19 +169,23 @@ file where host.os.type == "linux" and event.action in ("rename", "creation") an
"/bin/pacman", "/usr/bin/pacman", "/usr/bin/dpkg-divert", "/bin/dpkg-divert", "/sbin/apk", "/usr/sbin/apk",
"/usr/local/sbin/apk", "/usr/bin/apt", "/usr/sbin/pacman", "/bin/podman", "/usr/bin/podman", "/usr/bin/puppet",
"/bin/puppet", "/opt/puppetlabs/puppet/bin/puppet", "/usr/bin/chef-client", "/bin/chef-client",
"/bin/autossl_check", "/usr/bin/autossl_check", "/proc/self/exe", "/dev/fd/*", "/usr/bin/pamac-daemon",
"/bin/autossl_check", "/usr/bin/autossl_check", "/proc/self/exe", "/usr/bin/pamac-daemon", "./usr/bin/podman",
"/bin/pamac-daemon", "/usr/lib/snapd/snapd", "/usr/local/bin/dockerd", "/usr/bin/crio", "/usr/sbin/crond",
"/opt/puppetlabs/puppet/bin/ruby", "/usr/libexec/platform-python", "/kaniko/kaniko-executor",
"/usr/local/bin/dockerd", "/usr/bin/podman", "/bin/install", "/proc/self/exe", "/kaniko/executor"
"/usr/local/bin/dockerd", "/usr/bin/podman", "/bin/install", "/proc/self/exe", "/kaniko/executor",
"/etc/checkpoint/common/install.sh", "/usr/bin/dnf5", "/usr/libexec/packagekitd", "/usr/sbin/dnf",
"/opt/kaniko/executor", "/usr/bin/env", "/usr/local/bin/teleport-update", "/usr/bin/buildah",
"/usr/lib/systemd/systemd", "/usr/local/bin/defender"
) or
process.name like (
"python*", "crio", "apt-get", "install", "snapd", "cloudflared", "sshd", "convert-usrmerge", "docker-init",
"google_metadata_script_runner", "ssm-agent-worker", "pacman", "convert2rhel", "platform-python"
"google_metadata_script_runner", "ssm-agent-worker", "pacman", "convert2rhel", "platform-python*"
) or
file.extension in ("swp", "swpx", "swx", "dpkg-remove") or
file.Ext.original.extension == "dpkg-new" or
process.executable : (
"/nix/store/*", "/var/lib/dpkg/*", "/tmp/vmis.*", "/snap/*", "/dev/fd/*", "/usr/lib/virtualbox/*"
process.executable like (
"/nix/store/*", "/var/lib/dpkg/*", "/tmp/vmis.*", "/snap/*", "/dev/fd/*", "/usr/lib/virtualbox/*",
"/var/lib/docker/overlay2/*/dockerd", "/home/*/bin/dockerd", "/var/lib/containers/storage/overlay/*/dockerd"
) or
process.executable == null or
(process.name == "sed" and file.name : "sed*") or
rules/linux/persistence_systemd_service_creation.toml
+12 -4
View File
@@ -2,7 +2,7 @@
creation_date = "2023/06/09"
integration = ["endpoint"]
maturity = "production"
updated_date = "2025/02/03"
updated_date = "2025/12/23"
[transform]
[[transform.osquery]]
@@ -200,17 +200,25 @@ file where host.os.type == "linux" and event.action in ("rename", "creation") an
"/usr/bin/dpkg-divert", "/bin/dpkg-divert", "/sbin/apk", "/usr/sbin/apk",
"/usr/local/sbin/apk", "/usr/bin/apt", "/bin/podman", "/usr/bin/podman", "/usr/bin/puppet",
"/bin/puppet", "/opt/puppetlabs/puppet/bin/puppet", "/usr/bin/chef-client", "/bin/chef-client",
"/bin/autossl_check", "/usr/bin/autossl_check", "/proc/self/exe", "/dev/fd/*", "/usr/bin/pamac-daemon",
"/bin/autossl_check", "/usr/bin/autossl_check", "/proc/self/exe", "/usr/bin/pamac-daemon",
"/bin/pamac-daemon", "/usr/lib/snapd/snapd", "/usr/local/bin/dockerd", "/usr/bin/crio", "/usr/sbin/crond",
"/opt/puppetlabs/puppet/bin/ruby", "/usr/libexec/platform-python", "/kaniko/kaniko-executor",
"/usr/local/bin/dockerd", "/usr/bin/podman", "/bin/install", "/proc/self/exe", "/usr/lib/systemd/systemd",
"/usr/sbin/sshd", "/usr/bin/gitlab-runner", "/opt/gitlab/embedded/bin/ruby", "/usr/sbin/gdm", "/usr/bin/install",
"/usr/local/manageengine/uems_agent/bin/dcregister"
"/usr/local/manageengine/uems_agent/bin/dcregister", "/usr/local/bin/defender", "./usr/bin/podman",
"/etc/checkpoint/common/install.sh", "/usr/bin/dnf5", "/usr/lib/dracut/dracut-install", "/usr/bin/buildah",
"/opt/msp-agent/msp-agent-core", "/opt/sysmon/sysmon", "/opt/datadog-agent/embedded/bin/installer", "/usr/bin/tdnf",
"/opt/teleport/system/bin/teleport-update", "/opt/gitlab/embedded/bin/cinc-client", "/usr/libexec/snapd/snapd",
"/usr/sbin/yum-cron", "/sbin/yum-cron", "/opt/splunkforwarder/bin/splunk"
) or
file.extension in ("swp", "swpx", "swx", "dpkg-remove") or
file.Ext.original.extension == "dpkg-new" or
process.executable : (
"/nix/store/*", "/var/lib/dpkg/*", "/tmp/vmis.*", "/snap/*", "/dev/fd/*", "/usr/lib/virtualbox/*"
"/nix/store/*", "/var/lib/dpkg/*", "/tmp/vmis.*", "/snap/*", "/dev/fd/*", "/usr/lib/virtualbox/*",
"/usr/share/elastic-agent/data/*/components/endpoint-security", "/opt/Elastic/Agent/data/*/components/endpoint-security",
"/opt/TrendMicro/EndpointBasecamp/*", "/var/lib/docker/overlay2/*dockerd", "/var/lib/containers/storage/overlay/*/dockerd",
"/var/opt/kaspersky/kesl/*/opt/kaspersky/kesl/libexec/launcher"
) or
process.executable == null or
process.name like (
rules/linux/persistence_systemd_service_started.toml
+16 -15
View File
@@ -2,7 +2,7 @@
creation_date = "2024/05/17"
integration = ["endpoint"]
maturity = "production"
updated_date = "2025/02/03"
updated_date = "2025/12/23"
[transform]
[[transform.osquery]]
@@ -47,7 +47,6 @@ query = "SELECT * FROM users WHERE username = {{user.name}}"
label = "Osquery - Investigate the Account Authentication Status"
query = "SELECT * FROM logged_in_users WHERE user = {{user.name}}"
[rule]
author = ["Elastic"]
description = """
@@ -137,7 +136,7 @@ references = [
"https://pberba.github.io/security/2022/01/30/linux-threat-hunting-for-persistence-systemd-timers-cron/",
"https://www.elastic.co/security-labs/primer-on-persistence-mechanisms",
]
risk_score = 47
risk_score = 21
rule_id = "b605f262-f7dc-41b5-9ebc-06bafe7a83b6"
setup = """## Setup
@@ -164,7 +163,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",
@@ -176,7 +175,6 @@ tags = [
]
timestamp_override = "event.ingested"
type = "new_terms"
query = '''
host.os.type:linux and event.category:process and event.type:start and event.action:exec and
process.executable:/usr/bin/systemctl and process.args:(enable or reenable or start) and
@@ -189,43 +187,47 @@ not (
/bin/podman or /bin/rpm or /bin/snapd or /bin/sudo or /bin/useradd or /bin/yum or /usr/bin/dnf or
/usr/bin/dnf-automatic or /usr/bin/dockerd or /usr/bin/dpkg or /usr/bin/microdnf or /usr/bin/pacman or
/usr/bin/podman or /usr/bin/rpm or /usr/bin/snapd or /usr/bin/sudo or /usr/bin/yum or /usr/sbin/adduser or
/usr/sbin/invoke-rc.d or /usr/sbin/useradd or /var/lib/dpkg/*
/usr/sbin/invoke-rc.d or /usr/sbin/useradd or /var/lib/dpkg/* or /opt/datadog-agent/embedded/bin/installer or
/opt/saltstack/salt/bin/python* or /opt/puppetlabs/puppet/bin/puppet or /opt/splunkforwarder/bin/splunk or
/opt/puppetlabs/puppet/bin/ruby or /opt/kaspersky/kesl/shared/kesl or /usr/local/bin/cloudflared or
/usr/bin/puppet or /opt/sentinelone/bin/sentinelctl
) or
process.args_count >= 5
process.args_count >= 5 or
process.parent.command_line:*ansible*
)
'''
[[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.technique.subtechnique]]
id = "T1543.002"
name = "Systemd Service"
reference = "https://attack.mitre.org/techniques/T1543/002/"
[rule.threat.tactic]
id = "TA0003"
name = "Persistence"
reference = "https://attack.mitre.org/tactics/TA0003/"
[[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.technique.subtechnique]]
id = "T1543.002"
name = "Systemd Service"
reference = "https://attack.mitre.org/techniques/T1543/002/"
[rule.threat.tactic]
id = "TA0004"
name = "Privilege Escalation"
@@ -234,8 +236,7 @@ reference = "https://attack.mitre.org/tactics/TA0004/"
[rule.new_terms]
field = "new_terms_fields"
value = ["process.parent.executable"]
[[rule.new_terms.history_window_start]]
field = "history_window_start"
value = "now-7d"
value = "now-5d"
rules/linux/persistence_systemd_shell_execution.toml
+45 -45
View File
@@ -2,7 +2,7 @@
creation_date = "2025/01/16"
integration = ["endpoint"]
maturity = "production"
updated_date = "2025/01/22"
updated_date = "2025/12/23"
[rule]
author = ["Elastic"]
@@ -17,50 +17,6 @@ index = ["logs-endpoint.events.process*"]
language = "eql"
license = "Elastic License v2"
name = "Systemd Shell Execution During Boot"
risk_score = 47
rule_id = "0b76ad27-c3f3-4769-9e7e-3237137fdf06"
setup = """## Setup
This rule requires data coming in from Elastic Defend.
### Elastic Defend Integration Setup
Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app.
#### Prerequisite Requirements:
- Fleet is required for Elastic Defend.
- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).
#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:
- Go to the Kibana home page and click "Add integrations".
- In the query bar, search for "Elastic Defend" and select the integration to see more details about it.
- Click "Add Elastic Defend".
- Configure the integration name and optionally add a description.
- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads".
- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. [Helper guide](https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html).
- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions"
- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead.
For more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).
- Click "Save and Continue".
- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts.
For more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).
"""
severity = "medium"
tags = [
"Domain: Endpoint",
"OS: Linux",
"Use Case: Threat Detection",
"Tactic: Persistence",
"Tactic: Privilege Escalation",
"Data Source: Elastic Defend",
"Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"
query = '''
process where host.os.type == "linux" and event.type == "info" and event.action == "already_running" and
process.parent.name == "systemd" and process.name in ("bash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and
process.parent.command_line == "/sbin/init" and process.args_count >= 2
'''
note = """## Triage and analysis
> **Disclaimer**:
@@ -94,6 +50,50 @@ Systemd is a critical component in Linux, managing system and service initializa
- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected.
- Implement enhanced monitoring on the affected system and similar environments to detect any recurrence of the threat.
- Review and update access controls and permissions to limit the ability of unauthorized users to modify systemd configurations or execute shell commands during boot."""
risk_score = 21
rule_id = "0b76ad27-c3f3-4769-9e7e-3237137fdf06"
setup = """## Setup
This rule requires data coming in from Elastic Defend.
### Elastic Defend Integration Setup
Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app.
#### Prerequisite Requirements:
- Fleet is required for Elastic Defend.
- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).
#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:
- Go to the Kibana home page and click "Add integrations".
- In the query bar, search for "Elastic Defend" and select the integration to see more details about it.
- Click "Add Elastic Defend".
- Configure the integration name and optionally add a description.
- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads".
- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. [Helper guide](https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html).
- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions"
- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead.
For more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).
- Click "Save and Continue".
- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts.
For more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).
"""
severity = "low"
tags = [
"Domain: Endpoint",
"OS: Linux",
"Use Case: Threat Detection",
"Tactic: Persistence",
"Tactic: Privilege Escalation",
"Data Source: Elastic Defend",
"Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"
query = '''
process where host.os.type == "linux" and event.type == "info" and event.action == "already_running" and
process.parent.name == "systemd" and process.name in ("bash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and
process.parent.command_line == "/sbin/init" and process.args_count >= 2
'''
[[rule.threat]]
framework = "MITRE ATT&CK"
rules/linux/persistence_tainted_kernel_module_load.toml
+42 -44
View File
@@ -2,7 +2,7 @@
creation_date = "2023/10/23"
integration = ["system"]
maturity = "production"
updated_date = "2025/01/15"
updated_date = "2025/12/23"
[rule]
author = ["Elastic"]
@@ -17,45 +17,6 @@ index = ["logs-system.syslog-*"]
language = "kuery"
license = "Elastic License v2"
name = "Tainted Kernel Module Load"
risk_score = 21
rule_id = "05cad2fb-200c-407f-b472-02ea8c9e5e4a"
setup = """## Setup
This rule requires data coming in from one of the following integrations:
- Filebeat
### Filebeat Setup
Filebeat is a lightweight shipper for forwarding and centralizing log data. Installed as an agent on your servers, Filebeat monitors the log files or locations that you specify, collects log events, and forwards them either to Elasticsearch or Logstash for indexing.
#### The following steps should be executed in order to add the Filebeat for the Linux System:
- Elastic provides repositories available for APT and YUM-based distributions. Note that we provide binary packages, but no source packages.
- To install the APT and YUM repositories follow the setup instructions in this [helper guide](https://www.elastic.co/guide/en/beats/filebeat/current/setup-repositories.html).
- To run Filebeat on Docker follow the setup instructions in the [helper guide](https://www.elastic.co/guide/en/beats/filebeat/current/running-on-docker.html).
- To run Filebeat on Kubernetes follow the setup instructions in the [helper guide](https://www.elastic.co/guide/en/beats/filebeat/current/running-on-kubernetes.html).
- For quick start information for Filebeat refer to the [helper guide](https://www.elastic.co/guide/en/beats/filebeat/8.11/filebeat-installation-configuration.html).
- For complete Setup and Run Filebeat information refer to the [helper guide](https://www.elastic.co/guide/en/beats/filebeat/current/setting-up-and-running.html).
#### Rule Specific Setup Note
- This rule requires the Filebeat System Module to be enabled.
- The system module collects and parses logs created by the system logging service of common Unix/Linux based distributions.
- To run the system module of Filebeat on Linux follow the setup instructions in the [helper guide](https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-module-system.html).
"""
severity = "low"
tags = [
"Domain: Endpoint",
"OS: Linux",
"Use Case: Threat Detection",
"Tactic: Persistence",
"Tactic: Defense Evasion",
"Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "query"
query = '''
host.os.type:linux and event.dataset:"system.syslog" and process.name:kernel and
message:"module verification failed: signature and/or required key missing - tainting kernel"
'''
note = """## Triage and analysis
> **Disclaimer**:
@@ -90,35 +51,72 @@ Kernel modules extend the functionality of the Linux kernel, allowing dynamic lo
- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if other systems are affected.
- Implement enhanced monitoring and logging for kernel module loads and other critical system activities to detect similar threats in the future.
- Review and update system and network access controls to ensure only authorized personnel can load kernel modules, reducing the risk of unauthorized changes."""
risk_score = 47
rule_id = "05cad2fb-200c-407f-b472-02ea8c9e5e4a"
setup = """## Setup
This rule requires data coming in from one of the following integrations:
- Filebeat
### Filebeat Setup
Filebeat is a lightweight shipper for forwarding and centralizing log data. Installed as an agent on your servers, Filebeat monitors the log files or locations that you specify, collects log events, and forwards them either to Elasticsearch or Logstash for indexing.
#### The following steps should be executed in order to add the Filebeat for the Linux System:
- Elastic provides repositories available for APT and YUM-based distributions. Note that we provide binary packages, but no source packages.
- To install the APT and YUM repositories follow the setup instructions in this [helper guide](https://www.elastic.co/guide/en/beats/filebeat/current/setup-repositories.html).
- To run Filebeat on Docker follow the setup instructions in the [helper guide](https://www.elastic.co/guide/en/beats/filebeat/current/running-on-docker.html).
- To run Filebeat on Kubernetes follow the setup instructions in the [helper guide](https://www.elastic.co/guide/en/beats/filebeat/current/running-on-kubernetes.html).
- For quick start information for Filebeat refer to the [helper guide](https://www.elastic.co/guide/en/beats/filebeat/8.11/filebeat-installation-configuration.html).
- For complete Setup and Run Filebeat information refer to the [helper guide](https://www.elastic.co/guide/en/beats/filebeat/current/setting-up-and-running.html).
#### Rule Specific Setup Note
- This rule requires the Filebeat System Module to be enabled.
- The system module collects and parses logs created by the system logging service of common Unix/Linux based distributions.
- To run the system module of Filebeat on Linux follow the setup instructions in the [helper guide](https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-module-system.html).
"""
severity = "medium"
tags = [
"Domain: Endpoint",
"OS: Linux",
"Use Case: Threat Detection",
"Tactic: Persistence",
"Tactic: Defense Evasion",
"Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "query"
query = '''
host.os.type:linux and event.dataset:"system.syslog" and process.name:kernel and
message:"module verification failed: signature and/or required key missing - tainting kernel"
'''
[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1547"
name = "Boot or Logon Autostart Execution"
reference = "https://attack.mitre.org/techniques/T1547/"
[[rule.threat.technique.subtechnique]]
id = "T1547.006"
name = "Kernel Modules and Extensions"
reference = "https://attack.mitre.org/techniques/T1547/006/"
[rule.threat.tactic]
id = "TA0003"
name = "Persistence"
reference = "https://attack.mitre.org/tactics/TA0003/"
[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1014"
name = "Rootkit"
reference = "https://attack.mitre.org/techniques/T1014/"
[rule.threat.tactic]
id = "TA0005"
name = "Defense Evasion"
reference = "https://attack.mitre.org/tactics/TA0005/"
rules/linux/persistence_tainted_kernel_module_out_of_tree_load.toml
+43 -44
View File
@@ -2,7 +2,7 @@
creation_date = "2023/10/26"
integration = ["system"]
maturity = "production"
updated_date = "2025/01/15"
updated_date = "2025/12/23"
[rule]
author = ["Elastic"]
@@ -17,45 +17,6 @@ index = ["logs-system.syslog-*"]
language = "kuery"
license = "Elastic License v2"
name = "Tainted Out-Of-Tree Kernel Module Load"
risk_score = 21
rule_id = "51a09737-80f7-4551-a3be-dac8ef5d181a"
setup = """## Setup
This rule requires data coming in from one of the following integrations:
- Filebeat
### Filebeat Setup
Filebeat is a lightweight shipper for forwarding and centralizing log data. Installed as an agent on your servers, Filebeat monitors the log files or locations that you specify, collects log events, and forwards them either to Elasticsearch or Logstash for indexing.
#### The following steps should be executed in order to add the Filebeat for the Linux System:
- Elastic provides repositories available for APT and YUM-based distributions. Note that we provide binary packages, but no source packages.
- To install the APT and YUM repositories follow the setup instructions in this [helper guide](https://www.elastic.co/guide/en/beats/filebeat/current/setup-repositories.html).
- To run Filebeat on Docker follow the setup instructions in the [helper guide](https://www.elastic.co/guide/en/beats/filebeat/current/running-on-docker.html).
- To run Filebeat on Kubernetes follow the setup instructions in the [helper guide](https://www.elastic.co/guide/en/beats/filebeat/current/running-on-kubernetes.html).
- For quick start information for Filebeat refer to the [helper guide](https://www.elastic.co/guide/en/beats/filebeat/8.11/filebeat-installation-configuration.html).
- For complete Setup and Run Filebeat information refer to the [helper guide](https://www.elastic.co/guide/en/beats/filebeat/current/setting-up-and-running.html).
#### Rule Specific Setup Note
- This rule requires the Filebeat System Module to be enabled.
- The system module collects and parses logs created by the system logging service of common Unix/Linux based distributions.
- To run the system module of Filebeat on Linux follow the setup instructions in the [helper guide](https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-module-system.html).
"""
severity = "low"
tags = [
"Domain: Endpoint",
"OS: Linux",
"Use Case: Threat Detection",
"Tactic: Persistence",
"Tactic: Defense Evasion",
"Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "query"
query = '''
host.os.type:linux and event.dataset:"system.syslog" and process.name:kernel and
message:"loading out-of-tree module taints kernel."
'''
note = """## Triage and analysis
> **Disclaimer**:
@@ -91,35 +52,73 @@ Kernel modules extend the functionality of the Linux kernel without rebooting th
- Restore the system from a known good backup if the integrity of the system cannot be assured after module removal.
- Implement stricter access controls and monitoring for kernel module loading to prevent unauthorized module loads in the future.
- Escalate the incident to the security operations team for further investigation and to assess the need for broader organizational response measures."""
risk_score = 47
rule_id = "51a09737-80f7-4551-a3be-dac8ef5d181a"
setup = """## Setup
This rule requires data coming in from one of the following integrations:
- Filebeat
### Filebeat Setup
Filebeat is a lightweight shipper for forwarding and centralizing log data. Installed as an agent on your servers, Filebeat monitors the log files or locations that you specify, collects log events, and forwards them either to Elasticsearch or Logstash for indexing.
#### The following steps should be executed in order to add the Filebeat for the Linux System:
- Elastic provides repositories available for APT and YUM-based distributions. Note that we provide binary packages, but no source packages.
- To install the APT and YUM repositories follow the setup instructions in this [helper guide](https://www.elastic.co/guide/en/beats/filebeat/current/setup-repositories.html).
- To run Filebeat on Docker follow the setup instructions in the [helper guide](https://www.elastic.co/guide/en/beats/filebeat/current/running-on-docker.html).
- To run Filebeat on Kubernetes follow the setup instructions in the [helper guide](https://www.elastic.co/guide/en/beats/filebeat/current/running-on-kubernetes.html).
- For quick start information for Filebeat refer to the [helper guide](https://www.elastic.co/guide/en/beats/filebeat/8.11/filebeat-installation-configuration.html).
- For complete Setup and Run Filebeat information refer to the [helper guide](https://www.elastic.co/guide/en/beats/filebeat/current/setting-up-and-running.html).
#### Rule Specific Setup Note
- This rule requires the Filebeat System Module to be enabled.
- The system module collects and parses logs created by the system logging service of common Unix/Linux based distributions.
- To run the system module of Filebeat on Linux follow the setup instructions in the [helper guide](https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-module-system.html).
"""
severity = "medium"
tags = [
"Domain: Endpoint",
"OS: Linux",
"Use Case: Threat Detection",
"Tactic: Persistence",
"Tactic: Defense Evasion",
"Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "query"
query = '''
host.os.type:linux and event.dataset:"system.syslog" and process.name:kernel and
message:"loading out-of-tree module taints kernel."
'''
[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1547"
name = "Boot or Logon Autostart Execution"
reference = "https://attack.mitre.org/techniques/T1547/"
[[rule.threat.technique.subtechnique]]
id = "T1547.006"
name = "Kernel Modules and Extensions"
reference = "https://attack.mitre.org/techniques/T1547/006/"
[rule.threat.tactic]
id = "TA0003"
name = "Persistence"
reference = "https://attack.mitre.org/tactics/TA0003/"
[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1014"
name = "Rootkit"
reference = "https://attack.mitre.org/techniques/T1014/"
[rule.threat.tactic]
id = "TA0005"
name = "Defense Evasion"
reference = "https://attack.mitre.org/tactics/TA0005/"
rules/linux/persistence_udev_rule_creation.toml
+47 -45
View File
@@ -2,7 +2,7 @@
creation_date = "2023/10/26"
integration = ["endpoint"]
maturity = "production"
updated_date = "2025/01/24"
updated_date = "2025/12/23"
[rule]
author = ["Elastic"]
@@ -17,6 +17,43 @@ index = ["logs-endpoint.events.file*"]
language = "eql"
license = "Elastic License v2"
name = "Systemd-udevd Rule File Creation"
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 Systemd-udevd Rule File Creation
Systemd-udevd manages device nodes and handles kernel device events in Linux, using rule files to automate responses to hardware changes. Adversaries can exploit this by creating malicious rules that execute commands when specific devices are connected. The detection rule monitors the creation of these rule files, excluding legitimate processes, to identify potential abuse and ensure system integrity.
### Possible investigation steps
- Review the file path and name to determine if the rule file is located in a directory commonly used for udev rules, such as /etc/udev/rules.d/ or /lib/udev/.
- Examine the process executable that created or renamed the rule file to identify if it is a known legitimate process or an unexpected one, as specified in the query.
- Check the file extension and ensure it is .rules, confirming it is intended for udev rule configuration.
- Investigate the process name and path to determine if it matches any of the excluded legitimate processes or paths, which could indicate a false positive.
- Analyze the contents of the newly created or modified rule file to identify any suspicious or malicious commands that could be executed when a device is connected.
- Correlate the event with other system logs to identify any related activities or anomalies around the time of the rule file creation or modification.
- Assess the risk and impact of the rule file creation by considering the context of the system and any potential persistence mechanisms it might enable for an adversary.
### False positive analysis
- System updates and package installations can trigger rule file creations. Exclude processes like dpkg, rpm, and yum by adding them to the exception list to prevent false positives during legitimate system maintenance.
- Container management tools such as Docker and Podman may create or modify udev rules. Exclude these processes to avoid alerts when containers are being managed.
- Automated system configuration tools like Puppet and Chef can modify udev rules as part of their operations. Add these tools to the exception list to reduce noise from routine configuration changes.
- Snap package installations and updates can lead to rule file changes. Exclude snapd and related processes to prevent false positives during snap operations.
- Netplan and systemd processes may generate or modify udev rules as part of network configuration or system initialization. Exclude these processes to avoid unnecessary alerts during legitimate system activities.
### Response and remediation
- Immediately isolate the affected system from the network to prevent further execution of malicious udev rules and potential lateral movement.
- Identify and review the newly created or modified udev rule files in the specified directories to determine if they contain malicious commands or payloads.
- Remove any unauthorized or malicious udev rule files to prevent them from executing on device connection events.
- Restore any affected system configurations or files from a known good backup to ensure system integrity.
- Conduct a thorough scan of the system using updated antivirus or endpoint detection tools to identify and remove any additional malware or persistence mechanisms.
- Monitor the system for any further suspicious activity or attempts to recreate malicious udev rules, adjusting detection mechanisms as necessary.
- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected, ensuring comprehensive threat containment and remediation."""
references = ["https://www.elastic.co/security-labs/sequel-on-persistence-mechanisms"]
risk_score = 21
rule_id = "054db96b-fd34-43b3-9af2-587b3bd33964"
@@ -58,9 +95,9 @@ tags = [
timestamp_override = "event.ingested"
type = "eql"
query = '''
file where host.os.type == "linux" and event.action in ("rename", "creation") and
file where host.os.type == "linux" and event.action == "creation" and
process.executable != null and file.extension == "rules" and
file.path : (
file.path like (
"/lib/udev/*", "/etc/udev/rules.d/*", "/usr/lib/udev/rules.d/*", "/run/udev/rules.d/*", "/usr/local/lib/udev/rules.d/*"
) and not (
process.executable in (
@@ -70,58 +107,23 @@ file.path : (
"/bin/pacman", "/usr/bin/pacman", "/usr/bin/dpkg-divert", "/bin/dpkg-divert", "/sbin/apk", "/usr/sbin/apk",
"/usr/local/sbin/apk", "/usr/bin/apt", "/usr/sbin/pacman", "/bin/podman", "/usr/bin/podman", "/usr/bin/puppet",
"/bin/puppet", "/opt/puppetlabs/puppet/bin/puppet", "/usr/bin/chef-client", "/bin/chef-client",
"/bin/autossl_check", "/usr/bin/autossl_check", "/proc/self/exe", "/dev/fd/*", "/usr/bin/pamac-daemon",
"/bin/autossl_check", "/usr/bin/autossl_check", "/proc/self/exe", "/usr/bin/pamac-daemon", "./usr/bin/podman",
"/bin/pamac-daemon", "/usr/lib/snapd/snapd", "/usr/local/bin/dockerd", "/usr/libexec/netplan/generate",
"/lib/systemd/system-generators/netplan", "/lib/systemd/systemd", "/usr/bin/containerd", "/usr/sbin/sshd",
"/kaniko/executor"
"/kaniko/executor", "/usr/local/bin/defender", "/usr/bin/dnf5", "/opt/kaniko/executor", "/lib/netplan/generate",
) or
file.Ext.original.extension == "dpkg-new" or
process.executable : (
"/nix/store/*", "/var/lib/dpkg/*", "/snap/*", "/dev/fd/*", "/usr/lib/*", "/usr/libexec/*"
process.executable like (
"/nix/store/*", "/var/lib/dpkg/*", "/snap/*", "/dev/fd/*", "/usr/lib/*", "/usr/libexec/*",
"/var/lib/docker/overlay2/*/dockerd", "/var/lib/containers/storage/overlay*/dockerd"
) or
process.name in (
"systemd", "netplan", "apt-get", "vmware-config-tools.pl", "systemd-hwdb", "ssm-agent-worker", "crio", "cloud-init", "convert2rhel"
) or
(process.name == "sed" and file.name : "sed*") or
(process.name == "perl" and file.name : "e2scrub_all.tmp*")
process.name like ("python*", "perl*") or
(process.name == "sed" and file.name : "sed*")
)
'''
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 Systemd-udevd Rule File Creation
Systemd-udevd manages device nodes and handles kernel device events in Linux, using rule files to automate responses to hardware changes. Adversaries can exploit this by creating malicious rules that execute commands when specific devices are connected. The detection rule monitors the creation of these rule files, excluding legitimate processes, to identify potential abuse and ensure system integrity.
### Possible investigation steps
- Review the file path and name to determine if the rule file is located in a directory commonly used for udev rules, such as /etc/udev/rules.d/ or /lib/udev/.
- Examine the process executable that created or renamed the rule file to identify if it is a known legitimate process or an unexpected one, as specified in the query.
- Check the file extension and ensure it is .rules, confirming it is intended for udev rule configuration.
- Investigate the process name and path to determine if it matches any of the excluded legitimate processes or paths, which could indicate a false positive.
- Analyze the contents of the newly created or modified rule file to identify any suspicious or malicious commands that could be executed when a device is connected.
- Correlate the event with other system logs to identify any related activities or anomalies around the time of the rule file creation or modification.
- Assess the risk and impact of the rule file creation by considering the context of the system and any potential persistence mechanisms it might enable for an adversary.
### False positive analysis
- System updates and package installations can trigger rule file creations. Exclude processes like dpkg, rpm, and yum by adding them to the exception list to prevent false positives during legitimate system maintenance.
- Container management tools such as Docker and Podman may create or modify udev rules. Exclude these processes to avoid alerts when containers are being managed.
- Automated system configuration tools like Puppet and Chef can modify udev rules as part of their operations. Add these tools to the exception list to reduce noise from routine configuration changes.
- Snap package installations and updates can lead to rule file changes. Exclude snapd and related processes to prevent false positives during snap operations.
- Netplan and systemd processes may generate or modify udev rules as part of network configuration or system initialization. Exclude these processes to avoid unnecessary alerts during legitimate system activities.
### Response and remediation
- Immediately isolate the affected system from the network to prevent further execution of malicious udev rules and potential lateral movement.
- Identify and review the newly created or modified udev rule files in the specified directories to determine if they contain malicious commands or payloads.
- Remove any unauthorized or malicious udev rule files to prevent them from executing on device connection events.
- Restore any affected system configurations or files from a known good backup to ensure system integrity.
- Conduct a thorough scan of the system using updated antivirus or endpoint detection tools to identify and remove any additional malware or persistence mechanisms.
- Monitor the system for any further suspicious activity or attempts to recreate malicious udev rules, adjusting detection mechanisms as necessary.
- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected, ensuring comprehensive threat containment and remediation."""
[[rule.threat]]
framework = "MITRE ATT&CK"
rules/linux/persistence_unpack_initramfs_via_unmkinitramfs.toml
+13 -11
View File
@@ -2,14 +2,14 @@
creation_date = "2025/01/16"
integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_funnel"]
maturity = "production"
updated_date = "2025/03/20"
updated_date = "2025/12/23"
[rule]
author = ["Elastic"]
description = """
This rule detects the unpacking of an initramfs image using the `unmkinitramfs` command on Linux systems. The
`unmkinitramfs` command is used to extract the contents of an initramfs image, which is used to boot the system.
Attackers may use `unmkinitramfs` to unpack an initramfs image and modify its contents to include malicious code or
This rule detects the unpacking of an initramfs image using the "unmkinitramfs" command on Linux systems. The
"unmkinitramfs" command is used to extract the contents of an initramfs image, which is used to boot the system.
Attackers may use "unmkinitramfs" to unpack an initramfs image and modify its contents to include malicious code or
backdoors, allowing them to maintain persistence on the system.
"""
from = "now-9m"
@@ -95,16 +95,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", "executed") and
process.name == "unmkinitramfs"
process.name == "unmkinitramfs" and not (
?process.parent.executable == "/usr/bin/lsinitramfs" or
?process.working_directory == "/usr/local/nutanix/ngt/python/bin"
)
'''
[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1542"
name = "Pre-OS Boot"
@@ -120,28 +122,29 @@ id = "T1574"
name = "Hijack Execution Flow"
reference = "https://attack.mitre.org/techniques/T1574/"
[rule.threat.tactic]
id = "TA0003"
name = "Persistence"
reference = "https://attack.mitre.org/tactics/TA0003/"
[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1059"
name = "Command and Scripting Interpreter"
reference = "https://attack.mitre.org/techniques/T1059/"
[[rule.threat.technique.subtechnique]]
id = "T1059.004"
name = "Unix Shell"
reference = "https://attack.mitre.org/techniques/T1059/004/"
[rule.threat.tactic]
id = "TA0002"
name = "Execution"
reference = "https://attack.mitre.org/tactics/TA0002/"
[[rule.threat]]
framework = "MITRE ATT&CK"
@@ -149,4 +152,3 @@ framework = "MITRE ATT&CK"
id = "TA0005"
name = "Defense Evasion"
reference = "https://attack.mitre.org/tactics/TA0005/"
rules/linux/persistence_unusual_exim4_child_process.toml
+2 -2
View File
@@ -2,7 +2,7 @@
creation_date = "2025/04/30"
integration = ["endpoint"]
maturity = "production"
updated_date = "2025/07/07"
updated_date = "2025/12/23"
[rule]
author = ["Elastic"]
@@ -100,4 +100,4 @@ value = ["process.executable"]
[[rule.new_terms.history_window_start]]
field = "history_window_start"
value = "now-14d"
value = "now-5d"
rules/linux/persistence_unusual_pam_grantor.toml
+37 -39
View File
@@ -2,7 +2,7 @@
creation_date = "2024/03/06"
integration = ["auditd_manager"]
maturity = "production"
updated_date = "2025/01/15"
updated_date = "2025/12/23"
[rule]
author = ["Elastic"]
@@ -16,37 +16,6 @@ index = ["auditbeat-*", "logs-auditd_manager.auditd-*"]
language = "kuery"
license = "Elastic License v2"
name = "Authentication via Unusual PAM Grantor"
risk_score = 47
rule_id = "a8aaa49d-9834-462d-bf8f-b1255cebc004"
setup = """## Setup
This rule requires the use of the `auditd_manager` integration. `Auditd_manager` is a tool designed to simplify and enhance the management of the audit subsystem in Linux systems. It provides a user-friendly interface and automation capabilities for configuring and monitoring system auditing through the auditd daemon. With `auditd_manager`, administrators can easily define audit rules, track system events, and generate comprehensive audit reports, improving overall security and compliance in the system. The following steps should be executed in order to install and deploy `auditd_manager` on a Linux system.
```
Kibana -->
Management -->
Integrations -->
Auditd Manager -->
Add Auditd Manager
```
`Auditd_manager` subscribes to the kernel and receives events as they occur without any additional configuration. However, if more advanced configuration is required to detect specific behavior, audit rules can be added to the integration in either the "audit rules" configuration box or the "auditd rule files" box by specifying a file to read the audit rules from.
For this detection rule to trigger, no additional configuration is required.
"""
severity = "medium"
tags = [
"Domain: Endpoint",
"OS: Linux",
"Use Case: Threat Detection",
"Tactic: Credential Access",
"Tactic: Persistence",
"Data Source: Auditd Manager",
"Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "new_terms"
query = '''
event.category:authentication and host.os.type:linux and event.action:authenticated and event.outcome:success and
auditd.data.grantors:(* and not (pam_rootok or *pam_cap* or *pam_permit*))
'''
note = """## Triage and analysis
> **Disclaimer**:
@@ -81,28 +50,58 @@ Pluggable Authentication Modules (PAM) are integral to Linux systems, managing a
- Restore the affected system from a known good backup if unauthorized changes cannot be easily reverted or if the system's integrity is in question.
- 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 enhanced monitoring and logging for PAM-related activities across the network to detect similar threats in the future, ensuring that alerts are promptly reviewed and acted upon."""
risk_score = 47
rule_id = "a8aaa49d-9834-462d-bf8f-b1255cebc004"
setup = """## Setup
This rule requires the use of the `auditd_manager` integration. `Auditd_manager` is a tool designed to simplify and enhance the management of the audit subsystem in Linux systems. It provides a user-friendly interface and automation capabilities for configuring and monitoring system auditing through the auditd daemon. With `auditd_manager`, administrators can easily define audit rules, track system events, and generate comprehensive audit reports, improving overall security and compliance in the system. The following steps should be executed in order to install and deploy `auditd_manager` on a Linux system.
```
Kibana -->
Management -->
Integrations -->
Auditd Manager -->
Add Auditd Manager
```
`Auditd_manager` subscribes to the kernel and receives events as they occur without any additional configuration. However, if more advanced configuration is required to detect specific behavior, audit rules can be added to the integration in either the "audit rules" configuration box or the "auditd rule files" box by specifying a file to read the audit rules from.
For this detection rule to trigger, no additional configuration is required.
"""
severity = "medium"
tags = [
"Domain: Endpoint",
"OS: Linux",
"Use Case: Threat Detection",
"Tactic: Credential Access",
"Tactic: Persistence",
"Data Source: Auditd Manager",
"Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "new_terms"
query = '''
event.category:authentication and host.os.type:linux and event.action:authenticated and event.outcome:success and
auditd.data.grantors:(* and not (pam_rootok or *pam_cap* or *pam_permit*))
'''
[[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"
@@ -110,9 +109,8 @@ reference = "https://attack.mitre.org/tactics/TA0006/"
[rule.new_terms]
field = "new_terms_fields"
value = ["auditd.data.grantors", "agent.id"]
value = ["auditd.data.grantors"]
[[rule.new_terms.history_window_start]]
field = "history_window_start"
value = "now-14d"
value = "now-5d"
rules/linux/persistence_unusual_sshd_child_process.toml
+27 -26
View File
@@ -2,12 +2,12 @@
creation_date = "2024/12/16"
integration = ["endpoint", "crowdstrike"]
maturity = "production"
updated_date = "2025/10/17"
updated_date = "2025/12/23"
[rule]
author = ["Elastic"]
description = """
This rule detects the creation of an unusual SSHD child process through the usage of the `new_terms` rule type.
This rule detects the creation of an unusual SSHD child process through the usage of the "new_terms" rule type.
Attackers may abuse SSH to maintain persistence on a compromised system, or to establish a backdoor for remote access,
potentially resulting in an unusual SSHD child process being created.
"""
@@ -16,29 +16,6 @@ index = ["logs-endpoint.events.process*", "logs-crowdstrike.fdr*"]
language = "kuery"
license = "Elastic License v2"
name = "Unusual SSHD Child Process"
references = ["https://hadess.io/the-art-of-linux-persistence/"]
risk_score = 47
rule_id = "4c3c6c47-e38f-4944-be27-5c80be973bd7"
severity = "medium"
tags = [
"Domain: Endpoint",
"OS: Linux",
"Use Case: Threat Detection",
"Tactic: Persistence",
"Data Source: Elastic Defend",
"Resources: Investigation Guide",
"Data Source: Crowdstrike",
]
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 ProcessRollup2) and
process.parent.name:(ssh or sshd) and process.args_count:2 and
not (
process.command_line:(-bash or -zsh or -sh) or
process.name:(ractrans or exectask or tty or tput or ferny-askpass or id or ip)
)
'''
note = """## Triage and analysis
> **Disclaimer**:
@@ -72,6 +49,30 @@ Secure Shell (SSH) is a protocol used to securely access remote systems. Adversa
- Implement additional monitoring on the affected system and related network segments to detect any further suspicious activities or attempts to re-establish persistence.
- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if other systems may be affected.
- Review and update firewall rules and access controls to restrict SSH access to only trusted IP addresses and users, reducing the attack surface for future incidents."""
references = ["https://hadess.io/the-art-of-linux-persistence/"]
risk_score = 21
rule_id = "4c3c6c47-e38f-4944-be27-5c80be973bd7"
severity = "low"
tags = [
"Domain: Endpoint",
"OS: Linux",
"Use Case: Threat Detection",
"Tactic: Persistence",
"Data Source: Elastic Defend",
"Resources: Investigation Guide",
"Data Source: Crowdstrike",
]
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 ProcessRollup2) and
process.parent.name:sshd and process.args_count:2 and process.parent.args:"-D" and
not (
process.command_line:(-bash or -zsh or -sh) or
process.name:(ractrans or exectask or tty or tput or ferny-askpass or id or ip) or
process.executable:/var/tmp/foreman-ssh-cmd*/script
)
'''
[[rule.threat]]
framework = "MITRE ATT&CK"
@@ -133,4 +134,4 @@ value = ["process.executable"]
[[rule.new_terms.history_window_start]]
field = "history_window_start"
value = "now-14d"
value = "now-5d"
rules/linux/persistence_user_credential_modification_via_echo.toml
+9 -6
View File
@@ -2,14 +2,14 @@
creation_date = "2025/02/21"
integration = ["endpoint"]
maturity = "production"
updated_date = "2025/04/07"
updated_date = "2025/12/23"
[rule]
author = ["Elastic"]
description = """
This rule detects Linux user account credential modification events where the echo command is
used to directly echo a password into the passwd utility. This technique is used by malware
to automate the process of user account credential modification on Linux systems post-infection.
used to directly echo a password into the passwd or shadow utilities. This technique is used by
malware to automate the process of user account credential modification on Linux systems post-infection.
"""
from = "now-9m"
index = ["logs-endpoint.events.process*"]
@@ -51,7 +51,7 @@ In Linux environments, user account credentials are crucial for system access an
- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected.
- Implement additional monitoring and alerting for similar command patterns to enhance detection and prevent recurrence of this threat.
"""
risk_score = 21
risk_score = 47
rule_id = "79e7291f-9e3b-4a4b-9823-800daa89c8f9"
setup = """## Setup
This rule requires data coming in from Elastic Defend.
@@ -74,7 +74,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",
@@ -88,7 +88,10 @@ type = "eql"
query = '''
process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and
process.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and
process.command_line like~ "*echo*passwd*" and
process.command_line like (
"*echo*> /etc/passwd*", "*echo*>/etc/passwd*",
"*echo*> /etc/shadow*", "*echo*>/etc/shadow*"
) and
not (
process.parent.command_line == "runc init" or
process.parent.executable in ("/usr/bin/make", "/bin/make")
rules/linux/persistence_user_or_group_creation_or_modification.toml
+38 -41
View File
@@ -2,12 +2,12 @@
creation_date = "2024/06/20"
integration = ["auditd_manager"]
maturity = "production"
updated_date = "2025/01/24"
updated_date = "2025/12/23"
[rule]
author = ["Elastic"]
description = """
This rule leverages the `auditd_manager` integration to detect user or group creation or modification events on Linux
This rule leverages the "auditd_manager" integration to detect user or group creation or modification events on Linux
systems. Threat actors may attempt to create or modify users or groups to establish persistence on the system.
"""
from = "now-9m"
@@ -15,6 +15,40 @@ index = ["auditbeat-*", "logs-auditd_manager.auditd-*"]
language = "eql"
license = "Elastic License v2"
name = "User or Group Creation/Modification"
note = """## Triage and analysis
> **Disclaimer**:
> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
### Investigating User or Group Creation/Modification
In Linux environments, user and group management is crucial for access control and system administration. Adversaries may exploit this by creating or modifying accounts to maintain unauthorized access. The detection rule utilizes audit logs to monitor successful user or group changes, flagging potential persistence tactics by correlating specific actions with known threat behaviors.
### Possible investigation steps
- Review the audit logs to identify the specific user or group account that was created or modified, focusing on the event.action field values such as "changed-password", "added-user-account", or "added-group-account-to".
- Check the timestamp of the event to determine when the account change occurred and correlate it with any other suspicious activities or alerts around the same time.
- Investigate the source of the event by examining the host information, particularly the host.os.type field, to understand which system the changes were made on.
- Identify the user or process that initiated the account change by reviewing the associated user information in the audit logs, which may provide insights into whether the action was authorized or potentially malicious.
- Cross-reference the identified user or group changes with known threat actor behaviors or recent incidents to assess if the activity aligns with any known persistence tactics.
### False positive analysis
- Routine administrative tasks may trigger alerts when system administrators create or modify user or group accounts as part of regular maintenance. To manage this, consider creating exceptions for known administrative accounts or scheduled maintenance windows.
- Automated scripts or configuration management tools that manage user accounts can generate false positives. Identify these tools and exclude their actions from triggering alerts by whitelisting their processes or user accounts.
- System updates or software installations that require user or group modifications might be flagged. Review the context of these changes and exclude specific update processes or installation scripts from the rule.
- Temporary user accounts created for short-term projects or testing purposes can be mistaken for unauthorized access attempts. Implement a naming convention for temporary accounts and exclude them from the rule to reduce noise.
- Changes made by trusted third-party services or applications that integrate with the system may appear suspicious. Verify these services and add them to an exception list to prevent unnecessary alerts.
### Response and remediation
- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary.
- Review the audit logs to identify the specific user or group accounts that were created or modified, and disable or remove any unauthorized accounts.
- Reset passwords for any compromised or suspicious accounts to prevent further unauthorized access.
- Conduct a thorough review of system and application logs to identify any additional unauthorized changes or suspicious activities that may have occurred.
- Escalate the incident to the security operations team for further investigation and to determine if additional systems have been compromised.
- Implement additional monitoring on the affected system and similar systems to detect any further unauthorized account activities.
- Review and update access control policies and procedures to prevent similar incidents in the future, ensuring that only authorized personnel have the ability to create or modify user and group accounts."""
references = ["https://www.elastic.co/security-labs/primer-on-persistence-mechanisms"]
risk_score = 21
rule_id = "fcf733d5-7801-4eb0-92ac-8ffacf3658f2"
@@ -68,62 +102,25 @@ tags = [
]
timestamp_override = "event.ingested"
type = "eql"
query = '''
iam where host.os.type == "linux" and event.type in ("creation", "change") and auditd.result == "success" and
event.action in ("changed-password", "added-user-account", "added-group-account-to") and process.name != null
'''
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 User or Group Creation/Modification
In Linux environments, user and group management is crucial for access control and system administration. Adversaries may exploit this by creating or modifying accounts to maintain unauthorized access. The detection rule utilizes audit logs to monitor successful user or group changes, flagging potential persistence tactics by correlating specific actions with known threat behaviors.
### Possible investigation steps
- Review the audit logs to identify the specific user or group account that was created or modified, focusing on the event.action field values such as "changed-password", "added-user-account", or "added-group-account-to".
- Check the timestamp of the event to determine when the account change occurred and correlate it with any other suspicious activities or alerts around the same time.
- Investigate the source of the event by examining the host information, particularly the host.os.type field, to understand which system the changes were made on.
- Identify the user or process that initiated the account change by reviewing the associated user information in the audit logs, which may provide insights into whether the action was authorized or potentially malicious.
- Cross-reference the identified user or group changes with known threat actor behaviors or recent incidents to assess if the activity aligns with any known persistence tactics.
### False positive analysis
- Routine administrative tasks may trigger alerts when system administrators create or modify user or group accounts as part of regular maintenance. To manage this, consider creating exceptions for known administrative accounts or scheduled maintenance windows.
- Automated scripts or configuration management tools that manage user accounts can generate false positives. Identify these tools and exclude their actions from triggering alerts by whitelisting their processes or user accounts.
- System updates or software installations that require user or group modifications might be flagged. Review the context of these changes and exclude specific update processes or installation scripts from the rule.
- Temporary user accounts created for short-term projects or testing purposes can be mistaken for unauthorized access attempts. Implement a naming convention for temporary accounts and exclude them from the rule to reduce noise.
- Changes made by trusted third-party services or applications that integrate with the system may appear suspicious. Verify these services and add them to an exception list to prevent unnecessary alerts.
### Response and remediation
- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary.
- Review the audit logs to identify the specific user or group accounts that were created or modified, and disable or remove any unauthorized accounts.
- Reset passwords for any compromised or suspicious accounts to prevent further unauthorized access.
- Conduct a thorough review of system and application logs to identify any additional unauthorized changes or suspicious activities that may have occurred.
- Escalate the incident to the security operations team for further investigation and to determine if additional systems have been compromised.
- Implement additional monitoring on the affected system and similar systems to detect any further unauthorized account activities.
- Review and update access control policies and procedures to prevent similar incidents in the future, ensuring that only authorized personnel have the ability to create or modify user and group accounts."""
[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1136"
name = "Create Account"
reference = "https://attack.mitre.org/techniques/T1136/"
[[rule.threat.technique.subtechnique]]
id = "T1136.001"
name = "Local Account"
reference = "https://attack.mitre.org/techniques/T1136/001/"
[rule.threat.tactic]
id = "TA0003"
name = "Persistence"
reference = "https://attack.mitre.org/tactics/TA0003/"
rules/linux/persistence_web_server_sus_child_spawned.toml
+42 -42
View File
@@ -2,7 +2,7 @@
creation_date = "2025/03/04"
integration = ["endpoint"]
maturity = "production"
updated_date = "2025/09/02"
updated_date = "2025/12/23"
[rule]
author = ["Elastic"]
@@ -54,7 +54,7 @@ Web servers like Apache, Nginx, and others are crucial for hosting applications
- Monitor network traffic from the affected host for any signs of command and control communication, and block any identified malicious IP addresses or domains.
- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are compromised.
"""
risk_score = 47
risk_score = 21
rule_id = "976b2391-413f-4a94-acb4-7911f3803346"
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 = "medium"
severity = "low"
tags = [
"Domain: Endpoint",
"OS: Linux",
@@ -95,50 +95,24 @@ tags = [
timestamp_override = "event.ingested"
type = "esql"
query = '''
from logs-endpoint.events.process-*
| keep
@timestamp,
host.os.type,
event.type,
event.action,
process.parent.name,
user.name,
user.id,
process.working_directory,
process.name,
process.executable,
process.command_line,
process.parent.executable,
agent.id,
host.name
from logs-endpoint.events.process-* 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 == "exec" and (
(
process.parent.name in (
"apache", "nginx", "apache2", "httpd", "lighttpd", "caddy", "node", "mongrel_rails", "java", "gunicorn",
"apache", "nginx", "apache2", "httpd", "lighttpd", "caddy", "mongrel_rails", "gunicorn",
"uwsgi", "openresty", "cherokee", "h2o", "resin", "puma", "unicorn", "traefik", "tornado", "hypercorn",
"daphne", "twistd", "yaws", "webfsd", "httpd.worker", "flask", "rails", "mongrel"
"daphne", "twistd", "yaws", "webfsd", "httpd.worker", "flask", "rails", "mongrel", "php-cgi",
"php-fcgi", "php-cgi.cagefs", "catalina.sh", "hiawatha", "lswsctrl"
) or
user.name in (
"apache", "www-data", "httpd", "nginx", "lighttpd", "tomcat", "tomcat8", "tomcat9", "ftp", "ftpuser", "ftpd"
) or
user.id in ("99", "33", "498", "48") or
process.working_directory like "/var/www/*"
) or
(
(
process.parent.name like "php-*" or
process.parent.name like "python*" or
process.parent.name like "ruby*" or
process.parent.name like "perl*"
) and (
process.working_directory like "/var/www/*" or
process.working_directory like "/srv/www/*" or
process.working_directory like "/usr/share/nginx/*"
)
process.parent.name like "php-fpm*" or
user.name in ("apache", "www-data", "httpd", "nginx", "lighttpd", "tomcat", "tomcat8", "tomcat9") or
user.id in ("33", "498", "48") or
(process.parent.name == "java" and process.parent.working_directory like "/u0?/*") or
process.parent.working_directory like "/var/www/*"
)
) and (
process.name in (
@@ -171,17 +145,43 @@ from logs-endpoint.events.process-*
process.working_directory like "/var/www/*.ch" or
process.parent.executable like "/vscode/vscode-server/*"
)
| keep
@timestamp,
_id,
_index,
_version,
host.os.type,
event.type,
event.action,
process.parent.name,
user.name,
user.id,
process.working_directory,
process.parent.working_directory,
process.name,
process.executable,
process.command_line,
process.parent.executable,
agent.id,
host.name,
event.dataset,
data_stream.namespace
| stats
Esql.event_count = count(),
Esql.agent_id_count_distinct = count_distinct(agent.id),
Esql.host_name_values = values(host.name),
Esql.agent_id_values = values(agent.id)
by process.executable, process.working_directory, process.parent.executable
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, process.working_directory, process.parent.executable
| where
Esql.agent_id_count_distinct == 1 and
Esql.event_count < 5
| sort Esql.event_count asc
| limit 100
'''
[[rule.threat]]
rules/linux/persistence_web_server_sus_command_execution.toml
+41 -40
View File
@@ -2,7 +2,7 @@
creation_date = "2025/03/04"
integration = ["endpoint"]
maturity = "production"
updated_date = "2025/09/02"
updated_date = "2025/12/23"
[rule]
author = ["Elastic"]
@@ -61,7 +61,7 @@ Web servers, such as Apache or Nginx, are crucial for hosting web applications,
- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if the attack is part of a larger campaign. Provide them with all relevant data and findings from the initial containment and remediation steps.
"""
risk_score = 47
risk_score = 21
rule_id = "8a7933b4-9d0a-4c1c-bda5-e39fb045ff1d"
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 = "medium"
severity = "low"
tags = [
"Domain: Endpoint",
"OS: Linux",
@@ -102,49 +102,24 @@ tags = [
timestamp_override = "event.ingested"
type = "esql"
query = '''
from logs-endpoint.events.process-*
| keep
@timestamp,
host.os.type,
event.type,
event.action,
process.parent.name,
user.name,
user.id,
process.working_directory,
process.name,
process.command_line,
process.parent.executable,
agent.id,
host.name
from logs-endpoint.events.process-* 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 == "exec" and (
(
process.parent.name in (
"apache", "nginx", "apache2", "httpd", "lighttpd", "caddy", "node", "mongrel_rails", "java", "gunicorn",
"apache", "nginx", "apache2", "httpd", "lighttpd", "caddy", "mongrel_rails", "gunicorn",
"uwsgi", "openresty", "cherokee", "h2o", "resin", "puma", "unicorn", "traefik", "tornado", "hypercorn",
"daphne", "twistd", "yaws", "webfsd", "httpd.worker", "flask", "rails", "mongrel"
"daphne", "twistd", "yaws", "webfsd", "httpd.worker", "flask", "rails", "mongrel", "php-cgi",
"php-fcgi", "php-cgi.cagefs", "catalina.sh", "hiawatha", "lswsctrl"
) or
user.name in (
"apache", "www-data", "httpd", "nginx", "lighttpd", "tomcat", "tomcat8", "tomcat9", "ftp", "ftpuser", "ftpd"
) or
user.id in ("99", "33", "498", "48") or
process.working_directory like "/var/www/*"
) or
(
(
process.parent.name like "php-*" or
process.parent.name like "python*" or
process.parent.name like "ruby*" or
process.parent.name like "perl*"
) and (
process.working_directory like "/var/www/*" or
process.working_directory like "/srv/www/*" or
process.working_directory like "/usr/share/nginx/*"
)
process.parent.name like "php-fpm*" or
user.name in ("apache", "www-data", "httpd", "nginx", "lighttpd", "tomcat", "tomcat8", "tomcat9") or
user.id in ("33", "498", "48") or
(process.parent.name == "java" and process.parent.working_directory like "/u0?/*") or
process.parent.working_directory like "/var/www/*"
)
) and
process.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and
@@ -155,17 +130,43 @@ from logs-endpoint.events.process-*
process.parent.executable like "/vscode/vscode-server/*" or
process.parent.executable == "/usr/bin/xfce4-terminal"
)
| keep
@timestamp,
_id,
_index,
_version,
host.os.type,
event.type,
event.action,
process.parent.name,
user.name,
user.id,
process.working_directory,
process.parent.working_directory,
process.name,
process.executable,
process.command_line,
process.parent.executable,
agent.id,
host.name,
event.dataset,
data_stream.namespace
| stats
Esql.event_count = count(),
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.command_line, process.working_directory, process.parent.executable
| where
Esql.agent_id_count_distinct == 1 and
Esql.event_count < 5
| sort Esql.event_count asc
| limit 100
'''
[[rule.threat]]
rules/linux/persistence_web_server_sus_destination_port.toml
+7 -8
View File
@@ -2,7 +2,7 @@
creation_date = "2025/03/05"
integration = ["endpoint"]
maturity = "production"
updated_date = "2025/12/17"
updated_date = "2025/12/23"
[rule]
author = ["Elastic"]
@@ -95,18 +95,17 @@ type = "eql"
query = '''
network where host.os.type == "linux" and event.type == "start" and event.action == "connection_attempted" and (
process.name like (
"apache", "nginx", "apache2", "httpd", "lighttpd", "caddy", "php-fpm*", "mongrel_rails", "haproxy",
"gunicorn", "uwsgi", "openresty", "cherokee", "h2o", "resin", "puma", "unicorn", "traefik", "uvicorn",
"tornado", "hypercorn", "daphne", "twistd", "yaws", "webfsd", "httpd.worker", "flask", "rails", "mongrel",
"php-cgi", "php-fcgi", "php-cgi.cagefs"
"apache", "nginx", "apache2", "httpd", "lighttpd", "caddy", "mongrel_rails", "gunicorn",
"uwsgi", "openresty", "cherokee", "h2o", "resin", "puma", "unicorn", "traefik", "tornado", "hypercorn",
"daphne", "twistd", "yaws", "webfsd", "httpd.worker", "flask", "rails", "mongrel", "php-fpm*", "php-cgi",
"php-fcgi", "php-cgi.cagefs", "catalina.sh", "hiawatha", "lswsctrl"
) or
user.name in ("apache", "www-data", "httpd", "nginx", "lighttpd", "tomcat", "tomcat8", "tomcat9", "ftp", "ftpuser", "ftpd") or
user.id in ("54321", "33", "498", "48") or
user.name in ("apache", "www-data", "httpd", "nginx", "lighttpd", "tomcat", "tomcat8", "tomcat9") or
user.id in ("33", "498", "48") or
(process.name == "java" and process.working_directory like "/u0?/*")
) and
network.direction == "egress" and destination.ip != null and
not destination.port in (80, 443, 8080, 8443, 8000, 8888, 3128, 3306, 5432, 8220, 8082) and
not cidrmatch(destination.ip, "127.0.0.0/8", "::1","FE80::/10", "FF00::/8", "10.0.0.0/8", "169.254.0.0/16", "172.16.0.0/12", "192.0.0.0/24", "192.0.0.0/29", "192.0.0.8/32", "192.0.0.9/32",
"192.0.0.10/32", "192.0.0.170/32", "192.0.0.171/32", "192.0.2.0/24", "192.31.196.0/24", "192.52.193.0/24", "192.168.0.0/16", "192.88.99.0/24",
"224.0.0.0/4", "100.64.0.0/10", "192.175.48.0/24","198.18.0.0/15", "198.51.100.0/24", "203.0.113.0/24", "224.0.0.0/4", "240.0.0.0/4")
rules/linux/persistence_web_server_unusual_command_execution.toml
+4 -4
View File
@@ -2,7 +2,7 @@
creation_date = "2025/12/02"
integration = ["endpoint"]
maturity = "production"
updated_date = "2025/12/23"
updated_date = "2025/12/24"
[rule]
author = ["Elastic"]
@@ -89,8 +89,8 @@ not (
(process.parent.name:node and process.parent.executable:(/home/*/.vscode-server/* or /users/*/.vscode-server/* or /bin/node or /usr/bin/node or /usr/local/bin/node or /opt/plesk/node/*/bin/node)) or
process.working_directory:(/u0*/*/sysman/emd or /u0*/app/oracle/product/*/dbhome_* or /u0*/app/oracle/product/*/db_* or /var/www/*edoc*) or
process.parent.executable:/tmp/* or
process.args:/usr/local/bin/wkhtmltopdf* or
process.parent.name:php
process.args:(/usr/local/bin/wkhtmltopdf* or /usr/bin/rsvg-convert*) or
process.command_line:*/opt/sc/bin/showvulns*
)
'''
@@ -149,4 +149,4 @@ value = ["process.command_line"]
[[rule.new_terms.history_window_start]]
field = "history_window_start"
value = "now-14d"
value = "now-5d"
rules/linux/persistence_xdg_autostart_netcon.toml
+39 -41
View File
@@ -2,7 +2,7 @@
creation_date = "2024/06/03"
integration = ["endpoint"]
maturity = "production"
updated_date = "2025/02/04"
updated_date = "2025/12/23"
[rule]
author = ["Elastic"]
@@ -17,6 +17,40 @@ index = ["logs-endpoint.events.network*", "logs-endpoint.events.process*"]
language = "eql"
license = "Elastic License v2"
name = "Network Connections Initiated Through XDG Autostart 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 Network Connections Initiated Through XDG Autostart Entry
XDG Autostart entries are used in GNOME and XFCE Linux environments to automatically execute scripts or applications upon user login, facilitating user convenience. However, adversaries can exploit this feature to maintain persistence by modifying these entries to initiate unauthorized network connections. The detection rule identifies such malicious activity by monitoring processes linked to XDG autostart and subsequent suspicious network connections, excluding known benign processes and internal IP ranges.
### Possible investigation steps
- Review the process details from the alert, focusing on the process.entity_id and process.executable fields to identify the specific application or script that was executed through the XDG autostart entry.
- Examine the parent process information, particularly the process.parent.executable field, to confirm if the process was initiated by a legitimate session manager like /usr/bin/xfce4-session.
- Investigate the network connection details, paying attention to the destination.ip field to determine if the connection was attempted to an external or suspicious IP address not covered by the internal IP ranges specified in the query.
- Check the process.args field for any unusual or unexpected command-line arguments that might indicate malicious intent or unauthorized modifications to the autostart entry.
- Correlate the alert with other security events or logs from the same host.id to identify any additional suspicious activities or patterns that might suggest a broader compromise or persistence mechanism.
- Validate the legitimacy of the process.executable by comparing it against known benign applications listed in the query, such as /usr/lib64/firefox/firefox, to rule out false positives.
### False positive analysis
- Network connections from legitimate applications like Firefox or FortiClient may trigger false positives. To handle this, add these applications to the exclusion list in the detection rule.
- Internal network traffic within known safe IP ranges can be mistakenly flagged. Ensure these IP ranges are included in the exclusion criteria to prevent unnecessary alerts.
- Custom scripts or applications that are part of the user's normal login process might be misidentified. Review and whitelist these processes if they are verified as non-threatening.
- Regular updates or maintenance tasks that initiate network connections during login can cause false alerts. Identify these tasks and adjust the rule to exclude them if they are part of routine operations.
### Response and remediation
- Immediately isolate the affected host from the network to prevent further unauthorized network connections and potential lateral movement.
- Terminate any suspicious processes identified as being initiated through XDG autostart entries to halt any ongoing malicious activity.
- Review and remove any unauthorized or suspicious XDG autostart entries to eliminate persistence mechanisms established by the attacker.
- Conduct a thorough scan of the affected system for additional indicators of compromise, such as unauthorized user accounts or modified system files, to ensure comprehensive remediation.
- Restore any altered system configurations or files from a known good backup to ensure system integrity and functionality.
- Escalate the incident to the security operations team for further analysis and to determine if additional systems may be affected.
- Implement enhanced monitoring and logging for XDG autostart entries and network connections to detect similar threats in the future and improve overall security posture."""
references = [
"https://specifications.freedesktop.org/autostart-spec/autostart-spec-latest.html",
"https://hadess.io/the-art-of-linux-persistence/",
@@ -75,7 +109,6 @@ tags = [
]
timestamp_override = "event.ingested"
type = "eql"
query = '''
sequence by host.id, process.entity_id with maxspan=1s
[process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and (
@@ -94,62 +127,27 @@ sequence by host.id, process.entity_id with maxspan=1s
) or
process.name in (
"telegram-desktop", "firefox", "gnome-calculator", "remmina", "spotify", "librewolf", "fortitraylauncher",
"flameshot", "thunderbird", "update-manager", "warp-terminal", "obs", "transmission-gtk"
"flameshot", "thunderbird", "update-manager", "warp-terminal", "obs", "transmission-gtk", "telegram",
"mintupdate-launcher", "firefox-bin", "xbrlapi", "gnome-software"
)
)
]
'''
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 Network Connections Initiated Through XDG Autostart Entry
XDG Autostart entries are used in GNOME and XFCE Linux environments to automatically execute scripts or applications upon user login, facilitating user convenience. However, adversaries can exploit this feature to maintain persistence by modifying these entries to initiate unauthorized network connections. The detection rule identifies such malicious activity by monitoring processes linked to XDG autostart and subsequent suspicious network connections, excluding known benign processes and internal IP ranges.
### Possible investigation steps
- Review the process details from the alert, focusing on the process.entity_id and process.executable fields to identify the specific application or script that was executed through the XDG autostart entry.
- Examine the parent process information, particularly the process.parent.executable field, to confirm if the process was initiated by a legitimate session manager like /usr/bin/xfce4-session.
- Investigate the network connection details, paying attention to the destination.ip field to determine if the connection was attempted to an external or suspicious IP address not covered by the internal IP ranges specified in the query.
- Check the process.args field for any unusual or unexpected command-line arguments that might indicate malicious intent or unauthorized modifications to the autostart entry.
- Correlate the alert with other security events or logs from the same host.id to identify any additional suspicious activities or patterns that might suggest a broader compromise or persistence mechanism.
- Validate the legitimacy of the process.executable by comparing it against known benign applications listed in the query, such as /usr/lib64/firefox/firefox, to rule out false positives.
### False positive analysis
- Network connections from legitimate applications like Firefox or FortiClient may trigger false positives. To handle this, add these applications to the exclusion list in the detection rule.
- Internal network traffic within known safe IP ranges can be mistakenly flagged. Ensure these IP ranges are included in the exclusion criteria to prevent unnecessary alerts.
- Custom scripts or applications that are part of the user's normal login process might be misidentified. Review and whitelist these processes if they are verified as non-threatening.
- Regular updates or maintenance tasks that initiate network connections during login can cause false alerts. Identify these tasks and adjust the rule to exclude them if they are part of routine operations.
### Response and remediation
- Immediately isolate the affected host from the network to prevent further unauthorized network connections and potential lateral movement.
- Terminate any suspicious processes identified as being initiated through XDG autostart entries to halt any ongoing malicious activity.
- Review and remove any unauthorized or suspicious XDG autostart entries to eliminate persistence mechanisms established by the attacker.
- Conduct a thorough scan of the affected system for additional indicators of compromise, such as unauthorized user accounts or modified system files, to ensure comprehensive remediation.
- Restore any altered system configurations or files from a known good backup to ensure system integrity and functionality.
- Escalate the incident to the security operations team for further analysis and to determine if additional systems may be affected.
- Implement enhanced monitoring and logging for XDG autostart entries and network connections to detect similar threats in the future and improve overall security posture."""
[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1547"
name = "Boot or Logon Autostart Execution"
reference = "https://attack.mitre.org/techniques/T1547/"
[[rule.threat.technique.subtechnique]]
id = "T1547.013"
name = "XDG Autostart Entries"
reference = "https://attack.mitre.org/techniques/T1547/013/"
[rule.threat.tactic]
id = "TA0003"
name = "Persistence"
reference = "https://attack.mitre.org/tactics/TA0003/"
rules/linux/persistence_yum_package_manager_plugin_file_creation.toml
+70 -69
View File
@@ -2,7 +2,7 @@
creation_date = "2024/06/25"
integration = ["endpoint"]
maturity = "production"
updated_date = "2025/01/24"
updated_date = "2025/12/23"
[rule]
author = ["Elastic"]
@@ -18,74 +18,6 @@ index = ["logs-endpoint.events.file*"]
language = "eql"
license = "Elastic License v2"
name = "Yum Package Manager Plugin File Creation"
references = [
"https://github.com/rapid7/metasploit-framework/blob/master/modules/exploits/linux/local/yum_package_manager_persistence.rb",
"https://www.elastic.co/security-labs/sequel-on-persistence-mechanisms",
]
risk_score = 21
rule_id = "0b15bcad-aff1-4250-a5be-5d1b7eb56d07"
setup = """## Setup
This rule requires data coming in from Elastic Defend.
### Elastic Defend Integration Setup
Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app.
#### Prerequisite Requirements:
- Fleet is required for Elastic Defend.
- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).
#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:
- Go to the Kibana home page and click "Add integrations".
- In the query bar, search for "Elastic Defend" and select the integration to see more details about it.
- Click "Add Elastic Defend".
- Configure the integration name and optionally add a description.
- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads".
- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. [Helper guide](https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html).
- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions"
- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead.
For more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).
- Click "Save and Continue".
- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts.
For more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).
"""
severity = "low"
tags = [
"Domain: Endpoint",
"OS: Linux",
"Use Case: Threat Detection",
"Tactic: Persistence",
"Tactic: Defense Evasion",
"Data Source: Elastic Defend",
"Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"
query = '''
file where host.os.type == "linux" and event.action in ("rename", "creation") and
file.path : ("/usr/lib/yum-plugins/*", "/etc/yum/pluginconf.d/*") and not (
process.executable in (
"/bin/dockerd", "/usr/bin/dockerd", "/usr/sbin/dockerd", "/bin/microdnf", "/usr/bin/microdnf", "/bin/rpm",
"/usr/bin/rpm", "/bin/snapd", "/usr/bin/snapd", "/bin/yum", "/usr/bin/yum", "/bin/dnf", "/usr/bin/dnf",
"/bin/podman", "/usr/bin/podman", "/bin/dnf-automatic", "/usr/bin/dnf-automatic", "/sbin/apk", "/usr/sbin/apk",
"/usr/local/sbin/apk", "/bin/podman", "/usr/bin/podman", "/usr/bin/puppet", "/bin/puppet",
"/opt/puppetlabs/puppet/bin/puppet", "/usr/bin/chef-client", "/bin/chef-client", "/bin/autossl_check",
"/usr/bin/autossl_check", "/proc/self/exe", "/dev/fd/*", "/usr/lib/snapd/snapd", "/usr/local/bin/dockerd",
"/usr/libexec/netplan/generate"
) or
process.name in ("yumBackend.py", "crio") or
file.extension in ("swp", "swpx", "swx") or
file.Ext.original.name like ".ansible*" or
file.name like ".ansible_tmp*" or
process.executable : (
"/nix/store/*", "/var/lib/dpkg/*", "/tmp/vmis.*", "/snap/*", "/dev/fd/*", "/usr/lib/*", "/usr/libexec/*",
"/etc/kernel/*"
) or
process.executable == null or
(process.name == "sed" and file.name : "sed*") or
(process.name == "perl" and file.name : "e2scrub_all.tmp*")
)
'''
note = """## Triage and analysis
> **Disclaimer**:
@@ -121,6 +53,75 @@ The Yum package manager is integral to managing software on Fedora-based Linux s
- Implement file integrity monitoring on the Yum plugin directories to detect any future unauthorized modifications promptly.
- Escalate the incident to the security operations team for further investigation and to determine if additional systems may be affected.
- Update and patch the system to the latest security standards to mitigate any vulnerabilities that may have been exploited by the adversary."""
references = [
"https://github.com/rapid7/metasploit-framework/blob/master/modules/exploits/linux/local/yum_package_manager_persistence.rb",
"https://www.elastic.co/security-labs/sequel-on-persistence-mechanisms",
]
risk_score = 47
rule_id = "0b15bcad-aff1-4250-a5be-5d1b7eb56d07"
setup = """## Setup
This rule requires data coming in from Elastic Defend.
### Elastic Defend Integration Setup
Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app.
#### Prerequisite Requirements:
- Fleet is required for Elastic Defend.
- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).
#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:
- Go to the Kibana home page and click "Add integrations".
- In the query bar, search for "Elastic Defend" and select the integration to see more details about it.
- Click "Add Elastic Defend".
- Configure the integration name and optionally add a description.
- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads".
- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. [Helper guide](https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html).
- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions"
- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead.
For more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).
- Click "Save and Continue".
- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts.
For more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).
"""
severity = "medium"
tags = [
"Domain: Endpoint",
"OS: Linux",
"Use Case: Threat Detection",
"Tactic: Persistence",
"Tactic: Defense Evasion",
"Data Source: Elastic Defend",
"Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"
query = '''
file where host.os.type == "linux" and event.action in ("rename", "creation") and
file.path : ("/usr/lib/yum-plugins/*", "/etc/yum/pluginconf.d/*") and not (
process.executable in (
"/bin/dockerd", "/usr/bin/dockerd", "/usr/sbin/dockerd", "/bin/microdnf", "/usr/bin/microdnf", "/bin/rpm",
"/usr/bin/rpm", "/bin/snapd", "/usr/bin/snapd", "/bin/yum", "/usr/bin/yum", "/bin/dnf", "/usr/bin/dnf",
"/bin/podman", "/usr/bin/podman", "/bin/dnf-automatic", "/usr/bin/dnf-automatic", "/sbin/apk", "/usr/sbin/apk",
"/usr/local/sbin/apk", "/bin/podman", "/usr/bin/podman", "/usr/bin/puppet", "/bin/puppet",
"/opt/puppetlabs/puppet/bin/puppet", "/usr/bin/chef-client", "/bin/chef-client", "/bin/autossl_check",
"/usr/bin/autossl_check", "/proc/self/exe", "/usr/lib/snapd/snapd", "/usr/local/bin/dockerd",
"/usr/libexec/netplan/generate", "./usr/bin/podman",
) or
process.name in ("yumBackend.py", "crio", "dockerd") or
file.extension in ("swp", "swpx", "swx") or
file.Ext.original.name like ".ansible*" or
file.name like ".ansible_tmp*" or
process.executable : (
"/nix/store/*", "/var/lib/dpkg/*", "/tmp/vmis.*", "/snap/*", "/dev/fd/*", "/usr/lib/*", "/usr/libexec/*",
"/etc/kernel/*"
) or
process.executable == null or
(process.name == "sed" and file.name : "sed*") or
(process.name == "perl" and file.name : "e2scrub_all.tmp*")
)
'''
[[rule.threat]]
framework = "MITRE ATT&CK"