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

[Rule Tuning] Dormant & Deprecated Rule Clean-Up (#5672)

Browse Source 
* Updated kubernetes.audit.requestObject.spec.containers.image type of text to Keyword

* [Rule Tuning] Dormant & Deprecated Rule Clean-Up

* [Rule Tuning] Dormant & Deprecated Rule Clean-Up

* Few more deprecations

* ++

* Update unit test syntax fix

* Update bad bytes

* ++
This commit is contained in:
Ruben Groenewoud
2026-02-05 13:24:21 +01:00
committed by GitHub
parent aff945cb70
commit 3cba3d7982
22 changed files with 320 additions and 260 deletions
Download Patch File Download Diff File Expand all files Collapse all files
rules/linux/command_and_control_linux_chisel_server_activity.toml → rules/_deprecated/command_and_control_linux_chisel_server_activity.toml
+9 -4
View File
@@ -1,8 +1,9 @@
[metadata]
creation_date = "2023/08/23"
deprecation_date = "2026/02/04"
integration = ["endpoint"]
maturity = "production"
updated_date = "2025/12/17"
maturity = "deprecated"
updated_date = "2026/02/04"
[transform]
[[transform.osquery]]
@@ -29,6 +30,7 @@ query = "SELECT pid, username, name FROM processes p JOIN users u ON u.uid = p.u
label = "Osquery - Retrieve Process Info"
query = "SELECT name, cmdline, parent, path, uid FROM processes"
[rule]
author = ["Elastic"]
description = """
@@ -85,7 +87,7 @@ This rule looks for a sequence of command line arguments that are consistent wit
### False positive analysis
- If this activity is related to new benign software installation activity, consider adding exceptions — preferably with a combination of user and command line conditions.
- If this activity is related to new benign software installation activity, consider adding exceptions - preferably with a combination of user and command line conditions.
- If this activity is related to a system administrator or developer who uses port tunneling for benign purposes, consider adding exceptions for specific user accounts or hosts.
- Try to understand the context of the execution by thinking about the user, machine, or business purpose. A small number of endpoints, such as servers with unique software, might appear unusual but satisfy a specific business need.
@@ -145,6 +147,7 @@ tags = [
"Resources: Investigation Guide",
]
type = "eql"
query = '''
sequence by host.id, process.entity_id with maxspan=1m
[process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and
@@ -157,15 +160,17 @@ sequence by host.id, process.entity_id with maxspan=1m
"ftp", "socat", "curl", "wget", "dpkg", "docker", "dockerd", "yum", "apt", "rpm", "dnf", "ssh", "sshd", "hugo")]
'''
[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1572"
name = "Protocol Tunneling"
reference = "https://attack.mitre.org/techniques/T1572/"
[rule.threat.tactic]
id = "TA0011"
name = "Command and Control"
reference = "https://attack.mitre.org/tactics/TA0011/"
rules_building_block/command_and_control_non_standard_http_port.toml → rules/_deprecated/command_and_control_non_standard_http_port.toml
+11 -6
View File
@@ -1,8 +1,9 @@
[metadata]
creation_date = "2023/07/10"
deprecation_date = "2026/02/04"
integration = ["endpoint"]
maturity = "production"
updated_date = "2025/12/24"
maturity = "deprecated"
updated_date = "2026/02/04"
[transform]
[[transform.osquery]]
@@ -29,6 +30,7 @@ query = "SELECT pid, username, name FROM processes p JOIN users u ON u.uid = p.u
label = "Osquery - Retrieve Process Info"
query = "SELECT name, cmdline, parent, path, uid FROM processes"
[rule]
author = ["Elastic"]
building_block_type = "default"
@@ -83,7 +85,7 @@ This rule looks for HTTP/HTTPS processes where the destination port is not any o
### False positive analysis
- If this activity is related to new benign software installation activity, consider adding exceptions — preferably with a combination of user and command line conditions.
- If this activity is related to new benign software installation activity, consider adding exceptions - preferably with a combination of user and command line conditions.
- Try to understand the context of the execution by thinking about the user, machine, or business purpose. A small number of endpoints, such as servers with unique software, might appear unusual but satisfy a specific business need.
### Response and remediation
@@ -117,25 +119,26 @@ tags = [
]
timestamp_override = "event.ingested"
type = "eql"
query = '''
network where process.name : ("http", "https") and destination.port not in (80, 443) and event.action in (
"connection_attempted", "ipv4_connection_attempt_event", "connection_accepted", "ipv4_connection_accept_event"
) and destination.ip != "127.0.0.1"
'''
[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1071"
name = "Application Layer Protocol"
reference = "https://attack.mitre.org/techniques/T1071/"
[[rule.threat.technique.subtechnique]]
id = "T1071.001"
name = "Web Protocols"
reference = "https://attack.mitre.org/techniques/T1071/001/"
[[rule.threat.technique]]
id = "T1571"
name = "Non-Standard Port"
@@ -145,7 +148,6 @@ reference = "https://attack.mitre.org/techniques/T1571/"
id = "T1573"
name = "Encrypted Channel"
reference = "https://attack.mitre.org/techniques/T1573/"
[[rule.threat.technique.subtechnique]]
id = "T1573.001"
name = "Symmetric Cryptography"
@@ -156,7 +158,10 @@ id = "T1573.002"
name = "Asymmetric Cryptography"
reference = "https://attack.mitre.org/techniques/T1573/002/"
[rule.threat.tactic]
id = "TA0011"
name = "Command and Control"
reference = "https://attack.mitre.org/tactics/TA0011/"
rules/cross-platform/command_and_control_non_standard_ssh_port.toml → rules/_deprecated/command_and_control_non_standard_ssh_port.toml
+41 -37
View File
@@ -1,8 +1,9 @@
[metadata]
creation_date = "2022/10/18"
deprecation_date = "2026/02/04"
integration = ["endpoint"]
maturity = "production"
updated_date = "2025/12/23"
maturity = "deprecated"
updated_date = "2026/02/04"
[rule]
author = ["Elastic"]
@@ -15,7 +16,7 @@ false_positives = [
"""
SSH over ports apart from the traditional port 22 is highly uncommon. This rule alerts the usage of the such
uncommon ports by the ssh service. Tuning is needed to have higher confidence. If this activity is expected and
noisy in your environment, consider adding exceptions — preferably with a combination whitelisted ports for such
noisy in your environment, consider adding exceptions - preferably with a combination whitelisted ports for such
legitimate ssh activities.
""",
]
@@ -24,39 +25,6 @@ index = ["logs-endpoint.events.*"]
language = "eql"
license = "Elastic License v2"
name = "Deprecated - Potential Non-Standard Port SSH connection"
references = ["https://attack.mitre.org/techniques/T1571/"]
risk_score = 21
rule_id = "bc8ca7e0-92fd-4b7c-b11e-ee0266b8d9c9"
severity = "low"
tags = [
"Domain: Endpoint",
"OS: Linux",
"Use Case: Threat Detection",
"Tactic: Command and Control",
"OS: macOS",
"Data Source: Elastic Defend",
"Resources: Investigation Guide",
]
type = "eql"
query = '''
sequence by process.entity_id with maxspan=1m
[process where event.action == "exec" and process.name in ("ssh", "sshd") and not process.parent.name in (
"rsync", "pyznap", "git", "ansible-playbook", "scp", "pgbackrest", "git-lfs", "expect", "Sourcetree", "ssh-copy-id",
"run"
)
]
[network where process.name:"ssh" and event.action in ("connection_attempted", "connection_accepted") and
destination.port != 22 and network.transport == "tcp" and not (
destination.ip == null or destination.ip == "0.0.0.0" or cidrmatch(
destination.ip, "10.0.0.0/8", "127.0.0.0/8", "169.254.0.0/16", "172.16.0.0/12", "192.0.0.0/24", "192.0.0.0/29",
"192.0.0.8/32", "192.0.0.9/32", "192.0.0.10/32", "192.0.0.170/32", "192.0.0.171/32", "192.0.2.0/24",
"192.31.196.0/24", "192.52.193.0/24", "192.168.0.0/16", "192.88.99.0/24", "224.0.0.0/4", "100.64.0.0/10",
"192.175.48.0/24","198.18.0.0/15", "198.51.100.0/24", "203.0.113.0/24", "240.0.0.0/4", "::1", "FE80::/10",
"FF00::/8"
)
)
]
'''
note = """## Triage and analysis
> **Disclaimer**:
@@ -91,16 +59,52 @@ SSH is a protocol used for secure remote access and management of systems. Typic
- Implement network-level controls to block SSH traffic on non-standard ports unless explicitly required and documented for legitimate use cases.
- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.
- Enhance monitoring and alerting for SSH connections on non-standard ports across the network to improve early detection of similar threats in the future."""
references = ["https://attack.mitre.org/techniques/T1571/"]
risk_score = 21
rule_id = "bc8ca7e0-92fd-4b7c-b11e-ee0266b8d9c9"
severity = "low"
tags = [
"Domain: Endpoint",
"OS: Linux",
"Use Case: Threat Detection",
"Tactic: Command and Control",
"OS: macOS",
"Data Source: Elastic Defend",
"Resources: Investigation Guide",
]
type = "eql"
query = '''
sequence by process.entity_id with maxspan=1m
[process where event.action == "exec" and process.name in ("ssh", "sshd") and not process.parent.name in (
"rsync", "pyznap", "git", "ansible-playbook", "scp", "pgbackrest", "git-lfs", "expect", "Sourcetree", "ssh-copy-id",
"run"
)
]
[network where process.name:"ssh" and event.action in ("connection_attempted", "connection_accepted") and
destination.port != 22 and network.transport == "tcp" and not (
destination.ip == null or destination.ip == "0.0.0.0" or cidrmatch(
destination.ip, "10.0.0.0/8", "127.0.0.0/8", "169.254.0.0/16", "172.16.0.0/12", "192.0.0.0/24", "192.0.0.0/29",
"192.0.0.8/32", "192.0.0.9/32", "192.0.0.10/32", "192.0.0.170/32", "192.0.0.171/32", "192.0.2.0/24",
"192.31.196.0/24", "192.52.193.0/24", "192.168.0.0/16", "192.88.99.0/24", "224.0.0.0/4", "100.64.0.0/10",
"192.175.48.0/24","198.18.0.0/15", "198.51.100.0/24", "203.0.113.0/24", "240.0.0.0/4", "::1", "FE80::/10",
"FF00::/8"
)
)
]
'''
[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1571"
name = "Non-Standard Port"
reference = "https://attack.mitre.org/techniques/T1571/"
[rule.threat.tactic]
id = "TA0011"
name = "Command and Control"
reference = "https://attack.mitre.org/tactics/TA0011/"
rules/linux/credential_access_potential_successful_linux_ftp_bruteforce.toml → rules/_deprecated/credential_access_potential_successful_linux_ftp_bruteforce.toml
+14 -10
View File
@@ -1,8 +1,9 @@
[metadata]
creation_date = "2023/07/06"
deprecation_date = "2026/02/04"
integration = ["auditd_manager"]
maturity = "production"
updated_date = "2025/12/17"
maturity = "deprecated"
updated_date = "2026/02/04"
[rule]
author = ["Elastic"]
@@ -68,20 +69,20 @@ Auditbeat is a lightweight shipper that you can install on your servers to audit
- To install the APT and YUM repositories follow the setup instructions in this [helper guide](https://www.elastic.co/guide/en/beats/auditbeat/current/setup-repositories.html).
- To run Auditbeat on Docker follow the setup instructions in the [helper guide](https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-docker.html).
- To run Auditbeat on Kubernetes follow the setup instructions in the [helper guide](https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-kubernetes.html).
- For complete “Setup and Run Auditbeat” information refer to the [helper guide](https://www.elastic.co/guide/en/beats/auditbeat/current/setting-up-and-running.html).
- For complete "Setup and Run Auditbeat" information refer to the [helper guide](https://www.elastic.co/guide/en/beats/auditbeat/current/setting-up-and-running.html).
### Auditd Manager Integration Setup
The Auditd Manager Integration receives audit events from the Linux Audit Framework which is a part of the Linux kernel.
Auditd Manager 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 add the Elastic Agent System integration "auditd_manager" on a Linux System:
- Go to the Kibana home page and click “Add integrations”.
- In the query bar, search for “Auditd Manager” and select the integration to see more details about it.
- Click “Add Auditd Manager”.
- Go to the Kibana home page and click "Add integrations".
- In the query bar, search for "Auditd Manager" and select the integration to see more details about it.
- Click "Add Auditd Manager".
- Configure the integration name and optionally add a description.
- Review optional and advanced settings accordingly.
- Add the newly installed “auditd manager” to an existing or a new agent policy, and deploy the agent on a Linux system from which auditd log files are desirable.
- Click “Save and Continue”.
- Add the newly installed "auditd manager" to an existing or a new agent policy, and deploy the agent on a Linux system from which auditd log files are desirable.
- Click "Save and Continue".
- For more details on the integration refer to the [helper guide](https://docs.elastic.co/integrations/auditd_manager).
#### Rule Specific Setup Note
@@ -99,6 +100,7 @@ tags = [
"Resources: Investigation Guide",
]
type = "eql"
query = '''
sequence by host.id, auditd.data.addr, related.user with maxspan=5s
[authentication where host.os.type == "linux" and event.action == "authenticated" and
@@ -109,14 +111,13 @@ sequence by host.id, auditd.data.addr, related.user with maxspan=5s
auditd.data.addr != "0.0.0.0" and auditd.data.addr != "::"] | tail 1
'''
[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1110"
name = "Brute Force"
reference = "https://attack.mitre.org/techniques/T1110/"
[[rule.threat.technique.subtechnique]]
id = "T1110.001"
name = "Password Guessing"
@@ -127,7 +128,10 @@ id = "T1110.003"
name = "Password Spraying"
reference = "https://attack.mitre.org/techniques/T1110/003/"
[rule.threat.tactic]
id = "TA0006"
name = "Credential Access"
reference = "https://attack.mitre.org/tactics/TA0006/"
rules/linux/credential_access_potential_successful_linux_rdp_bruteforce.toml → rules/_deprecated/credential_access_potential_successful_linux_rdp_bruteforce.toml
+13 -10
View File
@@ -1,8 +1,9 @@
[metadata]
creation_date = "2023/07/06"
deprecation_date = "2026/02/04"
integration = ["auditd_manager"]
maturity = "production"
updated_date = "2025/12/17"
maturity = "deprecated"
updated_date = "2026/02/04"
[rule]
author = ["Elastic"]
@@ -69,20 +70,20 @@ Auditbeat is a lightweight shipper that you can install on your servers to audit
- To install the APT and YUM repositories follow the setup instructions in this [helper guide](https://www.elastic.co/guide/en/beats/auditbeat/current/setup-repositories.html).
- To run Auditbeat on Docker follow the setup instructions in the [helper guide](https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-docker.html).
- To run Auditbeat on Kubernetes follow the setup instructions in the [helper guide](https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-kubernetes.html).
- For complete “Setup and Run Auditbeat” information refer to the [helper guide](https://www.elastic.co/guide/en/beats/auditbeat/current/setting-up-and-running.html).
- For complete "Setup and Run Auditbeat" information refer to the [helper guide](https://www.elastic.co/guide/en/beats/auditbeat/current/setting-up-and-running.html).
### Auditd Manager Integration Setup
The Auditd Manager Integration receives audit events from the Linux Audit Framework which is a part of the Linux kernel.
Auditd Manager 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 add the Elastic Agent System integration "auditd_manager" on a Linux System:
- Go to the Kibana home page and click “Add integrations”.
- In the query bar, search for “Auditd Manager” and select the integration to see more details about it.
- Click “Add Auditd Manager”.
- Go to the Kibana home page and click "Add integrations".
- In the query bar, search for "Auditd Manager" and select the integration to see more details about it.
- Click "Add Auditd Manager".
- Configure the integration name and optionally add a description.
- Review optional and advanced settings accordingly.
- Add the newly installed “auditd manager” to an existing or a new agent policy, and deploy the agent on a Linux system from which auditd log files are desirable.
- Click “Save and Continue”.
- Add the newly installed "auditd manager" to an existing or a new agent policy, and deploy the agent on a Linux system from which auditd log files are desirable.
- Click "Save and Continue".
- For more details on the integration refer to the [helper guide](https://docs.elastic.co/integrations/auditd_manager).
#### Rule Specific Setup Note
@@ -109,14 +110,13 @@ sequence by host.id, related.user with maxspan=5s
auditd.data.terminal : "*rdp*" and event.outcome == "success"] | tail 1
'''
[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1110"
name = "Brute Force"
reference = "https://attack.mitre.org/techniques/T1110/"
[[rule.threat.technique.subtechnique]]
id = "T1110.001"
name = "Password Guessing"
@@ -127,7 +127,10 @@ id = "T1110.003"
name = "Password Spraying"
reference = "https://attack.mitre.org/techniques/T1110/003/"
[rule.threat.tactic]
id = "TA0006"
name = "Credential Access"
reference = "https://attack.mitre.org/tactics/TA0006/"
rules/cross-platform/defense_evasion_agent_spoofing_mismatched_id.toml → rules/_deprecated/defense_evasion_agent_spoofing_mismatched_id.toml
+16 -13
View File
@@ -1,7 +1,8 @@
[metadata]
creation_date = "2021/07/14"
maturity = "production"
updated_date = "2026/01/12"
deprecation_date = "2026/02/04"
maturity = "deprecated"
updated_date = "2026/02/04"
[rule]
author = ["Elastic"]
@@ -21,16 +22,6 @@ index = ["logs-*", "metrics-*", "traces-*"]
language = "kuery"
license = "Elastic License v2"
name = "Deprecated - Agent Spoofing - Mismatched Agent ID"
risk_score = 73
rule_id = "3115bd2c-0baa-4df0-80ea-45e474b5ef93"
severity = "high"
tags = ["Use Case: Threat Detection", "Tactic: Defense Evasion", "Resources: Investigation Guide"]
timestamp_override = "event.ingested"
type = "query"
query = '''
event.agent_id_status:agent_id_mismatch and not host.name:agentless-*
'''
note = """## Triage and analysis
> **Disclaimer**:
@@ -66,16 +57,28 @@ In security environments, agent IDs uniquely identify software agents that repor
- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if the threat actor has compromised other parts of the network.
- Review and update access controls and authentication mechanisms to ensure that only legitimate agents can report events. Consider implementing multi-factor authentication for added security.
- Document the incident, including all actions taken, and conduct a post-incident review to identify any gaps in detection or response. Use this information to enhance future threat detection and response capabilities."""
risk_score = 73
rule_id = "3115bd2c-0baa-4df0-80ea-45e474b5ef93"
severity = "high"
tags = ["Use Case: Threat Detection", "Tactic: Defense Evasion", "Resources: Investigation Guide"]
timestamp_override = "event.ingested"
type = "query"
query = '''
event.agent_id_status:agent_id_mismatch and not host.name:agentless-*
'''
[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1036"
name = "Masquerading"
reference = "https://attack.mitre.org/techniques/T1036/"
[rule.threat.tactic]
id = "TA0005"
name = "Defense Evasion"
reference = "https://attack.mitre.org/tactics/TA0005/"
rules/windows/defense_evasion_process_termination_followed_by_deletion.toml → rules/_deprecated/defense_evasion_process_termination_followed_by_deletion.toml
+3 -2
View File
@@ -1,8 +1,9 @@
[metadata]
creation_date = "2020/11/04"
deprecation_date = "2026/02/04"
integration = ["endpoint"]
maturity = "production"
updated_date = "2025/12/11"
maturity = "deprecated"
updated_date = "2026/02/04"
[transform]
[[transform.osquery]]
rules/linux/defense_evasion_rename_esxi_index_file.toml → rules/_deprecated/defense_evasion_rename_esxi_index_file.toml
+42 -38
View File
@@ -1,8 +1,9 @@
[metadata]
creation_date = "2023/04/11"
deprecation_date = "2026/02/04"
integration = ["endpoint"]
maturity = "production"
updated_date = "2025/12/18"
maturity = "deprecated"
updated_date = "2026/02/04"
[rule]
author = ["Elastic"]
@@ -16,6 +17,41 @@ index = ["logs-endpoint.events.file*"]
language = "eql"
license = "Elastic License v2"
name = "Deprecated - Suspicious Renaming of ESXI index.html File"
note = """## Triage and analysis
> **Disclaimer**:
> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
### Investigating Deprecated - Suspicious Renaming of ESXI index.html File
VMware ESXi hosts use the index.html file within their web interface for management tasks. Adversaries may rename this file to evade detection or to replace it with a malicious version, facilitating unauthorized access or data exfiltration. The detection rule monitors Linux systems for renaming actions targeting this file in the VMware directory, flagging potential defense evasion attempts by correlating file path and event actions.
### Possible investigation steps
- Review the alert details to confirm the file path and event action, ensuring the "rename" action occurred on the "index.html" file within the "/usr/lib/vmware/*" directory.
- Check the timestamp of the rename event to determine when the activity occurred and correlate it with any other suspicious activities or alerts around the same time.
- Identify the user or process responsible for the rename action by examining the associated user account and process details in the event logs.
- Investigate the system's recent login history and user activity to identify any unauthorized access or anomalies that could be linked to the rename event.
- Analyze the renamed file and any new files in the directory for signs of tampering or malicious content, using file integrity monitoring tools or antivirus scans.
- Review network logs for any unusual outbound connections from the affected host that could indicate data exfiltration or communication with a command and control server.
- Consider isolating the affected host from the network to prevent further potential malicious activity while the investigation is ongoing.
### False positive analysis
- Routine maintenance or updates on VMware ESXi hosts may involve renaming the index.html file temporarily. Users can create exceptions for known maintenance windows to prevent unnecessary alerts.
- Automated scripts or backup processes might rename the index.html file as part of their operations. Identify and whitelist these scripts or processes to avoid false positives.
- System administrators may manually rename the index.html file for legitimate customization or troubleshooting purposes. Document and exclude these actions by specific user accounts or during specific time frames.
- Security tools or monitoring solutions might trigger renaming actions as part of their scanning or remediation tasks. Verify and exclude these tools from the rule to reduce false alerts.
### Response and remediation
- Immediately isolate the affected VMware ESXi host from the network to prevent further unauthorized access or data exfiltration.
- Verify the integrity of the index.html file by comparing it with a known good version from a trusted source to determine if it has been tampered with or replaced.
- Restore the original index.html file from a secure backup if it has been altered or replaced, ensuring that the backup is from a time before the suspicious activity was detected.
- Conduct a thorough review of recent access logs and system changes on the affected host to identify any unauthorized access or modifications that may have occurred.
- Escalate the incident to the security operations team for further investigation and to determine if additional systems may be compromised.
- Implement additional monitoring on the affected host and similar systems to detect any further attempts to rename or modify critical files.
- Review and update access controls and permissions on the VMware ESXi host to ensure that only authorized personnel have the ability to modify critical system files."""
references = [
"https://www.bleepingcomputer.com/news/security/massive-esxiargs-ransomware-attack-targets-vmware-esxi-servers-worldwide/",
]
@@ -57,60 +93,28 @@ tags = [
]
timestamp_override = "event.ingested"
type = "eql"
query = '''
file where host.os.type == "linux" and event.action == "rename" and file.name : "index.html" and
file.Ext.original.path : "/usr/lib/vmware/*"
'''
note = """## Triage and analysis
> **Disclaimer**:
> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
### Investigating Deprecated - Suspicious Renaming of ESXI index.html File
VMware ESXi hosts use the index.html file within their web interface for management tasks. Adversaries may rename this file to evade detection or to replace it with a malicious version, facilitating unauthorized access or data exfiltration. The detection rule monitors Linux systems for renaming actions targeting this file in the VMware directory, flagging potential defense evasion attempts by correlating file path and event actions.
### Possible investigation steps
- Review the alert details to confirm the file path and event action, ensuring the "rename" action occurred on the "index.html" file within the "/usr/lib/vmware/*" directory.
- Check the timestamp of the rename event to determine when the activity occurred and correlate it with any other suspicious activities or alerts around the same time.
- Identify the user or process responsible for the rename action by examining the associated user account and process details in the event logs.
- Investigate the system's recent login history and user activity to identify any unauthorized access or anomalies that could be linked to the rename event.
- Analyze the renamed file and any new files in the directory for signs of tampering or malicious content, using file integrity monitoring tools or antivirus scans.
- Review network logs for any unusual outbound connections from the affected host that could indicate data exfiltration or communication with a command and control server.
- Consider isolating the affected host from the network to prevent further potential malicious activity while the investigation is ongoing.
### False positive analysis
- Routine maintenance or updates on VMware ESXi hosts may involve renaming the index.html file temporarily. Users can create exceptions for known maintenance windows to prevent unnecessary alerts.
- Automated scripts or backup processes might rename the index.html file as part of their operations. Identify and whitelist these scripts or processes to avoid false positives.
- System administrators may manually rename the index.html file for legitimate customization or troubleshooting purposes. Document and exclude these actions by specific user accounts or during specific time frames.
- Security tools or monitoring solutions might trigger renaming actions as part of their scanning or remediation tasks. Verify and exclude these tools from the rule to reduce false alerts.
### Response and remediation
- Immediately isolate the affected VMware ESXi host from the network to prevent further unauthorized access or data exfiltration.
- Verify the integrity of the index.html file by comparing it with a known good version from a trusted source to determine if it has been tampered with or replaced.
- Restore the original index.html file from a secure backup if it has been altered or replaced, ensuring that the backup is from a time before the suspicious activity was detected.
- Conduct a thorough review of recent access logs and system changes on the affected host to identify any unauthorized access or modifications that may have occurred.
- Escalate the incident to the security operations team for further investigation and to determine if additional systems may be compromised.
- Implement additional monitoring on the affected host and similar systems to detect any further attempts to rename or modify critical files.
- Review and update access controls and permissions on the VMware ESXi host to ensure that only authorized personnel have the ability to modify critical system files."""
[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1036"
name = "Masquerading"
reference = "https://attack.mitre.org/techniques/T1036/"
[[rule.threat.technique.subtechnique]]
id = "T1036.003"
name = "Rename Legitimate Utilities"
reference = "https://attack.mitre.org/techniques/T1036/003/"
[rule.threat.tactic]
id = "TA0005"
name = "Defense Evasion"
reference = "https://attack.mitre.org/tactics/TA0005/"
rules/linux/discovery_pspy_process_monitoring_detected.toml → rules/_deprecated/discovery_pspy_process_monitoring_detected.toml
+12 -8
View File
@@ -1,8 +1,9 @@
[metadata]
creation_date = "2023/07/20"
deprecation_date = "2026/02/04"
integration = ["auditd_manager"]
maturity = "production"
updated_date = "2025/12/18"
maturity = "deprecated"
updated_date = "2026/02/04"
[rule]
author = ["Elastic"]
@@ -64,13 +65,13 @@ The Auditd Manager Integration receives audit events from the Linux Audit Framew
Auditd Manager 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 add the Elastic Agent System integration "auditd_manager" on a Linux System:
- Go to the Kibana home page and click “Add integrations”.
- In the query bar, search for “Auditd Manager” and select the integration to see more details about it.
- Click “Add Auditd Manager”.
- Go to the Kibana home page and click "Add integrations".
- In the query bar, search for "Auditd Manager" and select the integration to see more details about it.
- Click "Add Auditd Manager".
- Configure the integration name and optionally add a description.
- Review optional and advanced settings accordingly.
- Add the newly installed “auditd manager” to an existing or a new agent policy, and deploy the agent on a Linux system from which auditd log files are desirable.
- Click “Save and Continue”.
- Add the newly installed "auditd manager" to an existing or a new agent policy, and deploy the agent on a Linux system from which auditd log files are desirable.
- Click "Save and Continue".
- For more details on the integration refer to the [helper guide](https://docs.elastic.co/integrations/auditd_manager).
#### Rule Specific Setup Note
@@ -89,6 +90,7 @@ tags = [
"Resources: Investigation Guide",
]
type = "eql"
query = '''
sequence by process.pid, host.id with maxspan=5s
[file where host.os.type == "linux" and auditd.data.syscall == "openat" and file.path == "/proc" and
@@ -97,9 +99,9 @@ sequence by process.pid, host.id with maxspan=5s
] with runs=10
'''
[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1057"
name = "Process Discovery"
@@ -110,7 +112,9 @@ id = "T1082"
name = "System Information Discovery"
reference = "https://attack.mitre.org/techniques/T1082/"
[rule.threat.tactic]
id = "TA0007"
name = "Discovery"
reference = "https://attack.mitre.org/tactics/TA0007/"
rules/linux/execution_curl_cve_2023_38545_heap_overflow.toml → rules/_deprecated/execution_curl_cve_2023_38545_heap_overflow.toml
+12 -8
View File
@@ -1,8 +1,9 @@
[metadata]
creation_date = "2023/10/11"
deprecation_date = "2026/02/04"
integration = ["endpoint"]
maturity = "production"
updated_date = "2025/12/18"
maturity = "deprecated"
updated_date = "2026/02/04"
[rule]
author = ["Elastic"]
@@ -87,13 +88,13 @@ For more details on Elastic Defend refer to the [helper guide](https://www.elast
Elastic Defend integration does not collect environment variable logging by default.
In order to capture this behavior, this rule requires a specific configuration option set within the advanced settings of the Elastic Defend integration.
#### To set up environment variable capture for an Elastic Agent policy:
- Go to “Security → Manage → Policies”.
- Select an “Elastic Agent policy”.
- Click “Show advanced settings”.
- Scroll down or search for “linux.advanced.capture_env_vars”.
- Go to "Security --> Manage --> Policies".
- Select an "Elastic Agent policy".
- Click "Show advanced settings".
- Scroll down or search for "linux.advanced.capture_env_vars".
- Enter the names of environment variables you want to capture, separated by commas.
- For this rule the linux.advanced.capture_env_vars variable should be set to "http_proxy,HTTPS_PROXY,ALL_PROXY".
- Click “Save”.
- Click "Save".
After saving the integration change, the Elastic Agents running this policy will be updated and the rule will function properly.
For more information on capturing environment variables refer to the [helper guide](https://www.elastic.co/guide/en/security/current/environment-variable-capture.html).
"""
@@ -109,6 +110,7 @@ tags = [
]
timestamp_override = "event.ingested"
type = "eql"
query = '''
process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and process.name == "curl"
and (
@@ -121,15 +123,17 @@ and (
)
'''
[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1203"
name = "Exploitation for Client Execution"
reference = "https://attack.mitre.org/techniques/T1203/"
[rule.threat.tactic]
id = "TA0002"
name = "Execution"
reference = "https://attack.mitre.org/tactics/TA0002/"
rules/windows/execution_pdf_written_file.toml → rules/_deprecated/execution_pdf_written_file.toml
+3 -2
View File
@@ -1,8 +1,9 @@
[metadata]
creation_date = "2020/09/02"
deprecation_date = "2026/02/04"
integration = ["endpoint", "windows"]
maturity = "production"
updated_date = "2025/09/12"
maturity = "deprecated"
updated_date = "2026/02/04"
[rule]
author = ["Elastic"]
rules/linux/lateral_movement_ssh_process_launched_inside_container.toml → rules/_deprecated/lateral_movement_ssh_process_launched_inside_container.toml
+11 -8
View File
@@ -1,8 +1,9 @@
[metadata]
creation_date = "2025/03/12"
deprecation_date = "2026/02/04"
integration = ["endpoint"]
maturity = "production"
updated_date = "2025/12/19"
maturity = "deprecated"
updated_date = "2026/02/04"
[rule]
author = ["Elastic"]
@@ -22,13 +23,13 @@ from = "now-9m"
index = ["logs-endpoint.events.process*"]
language = "eql"
license = "Elastic License v2"
name = "Deprecated - SSH Process Launched From Inside A Container"
name = "Deprecated - SSH Process Launched From Inside A Container via Elastic Defend"
note = """## Triage and analysis
> **Disclaimer**:
> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
### Investigating Deprecated - SSH Process Launched From Inside A Container
### Investigating Deprecated - SSH Process Launched From Inside A Container via Elastic Defend
SSH (Secure Shell) is a protocol used for secure remote access and management of systems. Within container environments, SSH usage is atypical and can signal potential security risks. Adversaries may exploit SSH to move laterally between containers or escape to the host system. The detection rule identifies SSH processes initiated within containers, flagging potential unauthorized access or persistence attempts by monitoring process events and container identifiers.
@@ -101,38 +102,40 @@ tags = [
]
timestamp_override = "event.ingested"
type = "eql"
query = '''
process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and
process.entry_leader.entry_meta.type == "container" and process.name in ("sshd", "ssh", "autossh")
'''
[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1021"
name = "Remote Services"
reference = "https://attack.mitre.org/techniques/T1021/"
[[rule.threat.technique.subtechnique]]
id = "T1021.004"
name = "SSH"
reference = "https://attack.mitre.org/techniques/T1021/004/"
[rule.threat.tactic]
id = "TA0008"
name = "Lateral Movement"
reference = "https://attack.mitre.org/tactics/TA0008/"
[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1133"
name = "External Remote Services"
reference = "https://attack.mitre.org/techniques/T1133/"
[rule.threat.tactic]
id = "TA0003"
name = "Persistence"
reference = "https://attack.mitre.org/tactics/TA0003/"
rules_building_block/persistence_cap_sys_admin_added_to_new_binary.toml → rules/_deprecated/persistence_cap_sys_admin_added_to_new_binary.toml
+7 -3
View File
@@ -1,9 +1,10 @@
[metadata]
bypass_bbr_timing = true
creation_date = "2024/01/10"
deprecation_date = "2026/02/04"
integration = ["endpoint"]
maturity = "production"
updated_date = "2025/12/24"
maturity = "deprecated"
updated_date = "2026/02/04"
[rule]
author = ["Elastic"]
@@ -59,12 +60,14 @@ tags = [
]
timestamp_override = "event.ingested"
type = "new_terms"
query = '''
event.category:"process" and host.os.type:"linux" and event.type:"start" and event.action:"exec" and process.name:* and
(process.thread.capabilities.effective:"CAP_SYS_ADMIN" or process.thread.capabilities.permitted:"CAP_SYS_ADMIN") and
not user.id:"0"
'''
[[rule.threat]]
framework = "MITRE ATT&CK"
@@ -76,7 +79,8 @@ reference = "https://attack.mitre.org/tactics/TA0003/"
[rule.new_terms]
field = "new_terms_fields"
value = ["agent.id", "user.id", "process.executable"]
[[rule.new_terms.history_window_start]]
field = "history_window_start"
value = "now-5d"
rules/macos/persistence_creation_modif_launch_deamon_sequence.toml → rules/_deprecated/persistence_creation_modif_launch_deamon_sequence.toml
+38 -37
View File
@@ -1,8 +1,9 @@
[metadata]
creation_date = "2020/12/07"
deprecation_date = "2026/02/04"
integration = ["endpoint"]
maturity = "production"
updated_date = "2025/04/21"
maturity = "deprecated"
updated_date = "2026/02/04"
[rule]
author = ["Elastic"]
@@ -16,6 +17,41 @@ index = ["logs-endpoint.events.file*", "logs-endpoint.events.process*"]
language = "eql"
license = "Elastic License v2"
name = "Deprecated - LaunchDaemon Creation or Modification and Immediate Loading"
note = """## Triage and analysis
> **Disclaimer**:
> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
### Investigating Deprecated - LaunchDaemon Creation or Modification and Immediate Loading
LaunchDaemons in macOS are system-level services that start at boot and run in the background, often used for legitimate system tasks. However, adversaries can exploit this by creating or modifying LaunchDaemons to ensure persistent execution of malicious payloads. The detection rule identifies such activities by monitoring for new or altered LaunchDaemon files followed by their immediate loading using `launchctl`, indicating potential misuse for persistence.
### Possible investigation steps
- Review the file path of the newly created or modified LaunchDaemon to determine if it is located in a legitimate system directory such as /System/Library/LaunchDaemons/ or /Library/LaunchDaemons/.
- Examine the contents of the LaunchDaemon file to identify any suspicious or unexpected configurations or scripts that may indicate malicious intent.
- Investigate the process execution details of the launchctl command, including the user account that initiated it, to assess whether it aligns with expected administrative activities.
- Check the timestamp of the LaunchDaemon file creation or modification against known system updates or legitimate software installations to rule out false positives.
- Correlate the event with other security alerts or logs from the same host to identify any additional indicators of compromise or related malicious activities.
- Consult threat intelligence sources to determine if the identified LaunchDaemon or associated scripts are known to be used by specific threat actors or malware campaigns.
### False positive analysis
- System updates or software installations may create or modify LaunchDaemons as part of legitimate processes. Users can monitor the timing of these activities and correlate them with known update schedules to identify benign occurrences.
- Some third-party applications may use LaunchDaemons for legitimate background tasks. Users should maintain a list of trusted applications and their associated LaunchDaemons to quickly identify and exclude these from alerts.
- Administrative scripts or IT management tools might use launchctl to load LaunchDaemons for system management purposes. Users can create exceptions for known management tools by specifying their process names or paths in the monitoring system.
- Regular system maintenance tasks might involve the creation or modification of LaunchDaemons. Users should document routine maintenance activities and adjust monitoring rules to exclude these known tasks.
- Users can implement a baseline of normal LaunchDaemon activity on their systems to distinguish between expected and unexpected changes, allowing for more accurate identification of false positives.
### Response and remediation
- Immediately isolate the affected macOS host from the network to prevent further malicious activity and lateral movement.
- Terminate any suspicious processes associated with the newly created or modified LaunchDaemon using the `launchctl` command to unload the daemon.
- Review and remove any unauthorized or suspicious LaunchDaemon files from the directories `/System/Library/LaunchDaemons/` and `/Library/LaunchDaemons/`.
- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malicious payloads.
- Restore any altered system files or configurations from a known good backup to ensure system integrity.
- 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 LaunchDaemon activities and `launchctl` usage to detect similar threats in the future."""
references = [
"https://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPSystemStartup/Chapters/CreatingLaunchdJobs.html",
]
@@ -62,41 +98,6 @@ sequence by host.id with maxspan=1m
[file where host.os.type == "macos" and event.type != "deletion" and file.path : ("/System/Library/LaunchDaemons/*", "/Library/LaunchDaemons/*")]
[process where host.os.type == "macos" and event.type in ("start", "process_started") and process.name == "launchctl" and process.args == "load"]
'''
note = """## Triage and analysis
> **Disclaimer**:
> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
### Investigating Deprecated - LaunchDaemon Creation or Modification and Immediate Loading
LaunchDaemons in macOS are system-level services that start at boot and run in the background, often used for legitimate system tasks. However, adversaries can exploit this by creating or modifying LaunchDaemons to ensure persistent execution of malicious payloads. The detection rule identifies such activities by monitoring for new or altered LaunchDaemon files followed by their immediate loading using `launchctl`, indicating potential misuse for persistence.
### Possible investigation steps
- Review the file path of the newly created or modified LaunchDaemon to determine if it is located in a legitimate system directory such as /System/Library/LaunchDaemons/ or /Library/LaunchDaemons/.
- Examine the contents of the LaunchDaemon file to identify any suspicious or unexpected configurations or scripts that may indicate malicious intent.
- Investigate the process execution details of the launchctl command, including the user account that initiated it, to assess whether it aligns with expected administrative activities.
- Check the timestamp of the LaunchDaemon file creation or modification against known system updates or legitimate software installations to rule out false positives.
- Correlate the event with other security alerts or logs from the same host to identify any additional indicators of compromise or related malicious activities.
- Consult threat intelligence sources to determine if the identified LaunchDaemon or associated scripts are known to be used by specific threat actors or malware campaigns.
### False positive analysis
- System updates or software installations may create or modify LaunchDaemons as part of legitimate processes. Users can monitor the timing of these activities and correlate them with known update schedules to identify benign occurrences.
- Some third-party applications may use LaunchDaemons for legitimate background tasks. Users should maintain a list of trusted applications and their associated LaunchDaemons to quickly identify and exclude these from alerts.
- Administrative scripts or IT management tools might use launchctl to load LaunchDaemons for system management purposes. Users can create exceptions for known management tools by specifying their process names or paths in the monitoring system.
- Regular system maintenance tasks might involve the creation or modification of LaunchDaemons. Users should document routine maintenance activities and adjust monitoring rules to exclude these known tasks.
- Users can implement a baseline of normal LaunchDaemon activity on their systems to distinguish between expected and unexpected changes, allowing for more accurate identification of false positives.
### Response and remediation
- Immediately isolate the affected macOS host from the network to prevent further malicious activity and lateral movement.
- Terminate any suspicious processes associated with the newly created or modified LaunchDaemon using the `launchctl` command to unload the daemon.
- Review and remove any unauthorized or suspicious LaunchDaemon files from the directories `/System/Library/LaunchDaemons/` and `/Library/LaunchDaemons/`.
- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malicious payloads.
- Restore any altered system files or configurations from a known good backup to ensure system integrity.
- 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 LaunchDaemon activities and `launchctl` usage to detect similar threats in the future."""
[[rule.threat]]
rules_building_block/persistence_creation_of_kernel_module.toml → rules/_deprecated/persistence_creation_of_kernel_module.toml
+8 -4
View File
@@ -1,8 +1,9 @@
[metadata]
creation_date = "2023/08/23"
deprecation_date = "2026/02/04"
integration = ["endpoint"]
maturity = "production"
updated_date = "2025/12/24"
maturity = "deprecated"
updated_date = "2026/02/04"
[rule]
author = ["Elastic"]
@@ -28,6 +29,7 @@ tags = [
]
timestamp_override = "event.ingested"
type = "eql"
query = '''
file where host.os.type == "linux" and event.type in ("change", "creation") and file.path : "/lib/modules/*" and
file.extension == "ko" and not process.name : (
@@ -35,20 +37,22 @@ file.extension == "ko" and not process.name : (
)
'''
[[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/"
rules/cross-platform/persistence_credential_access_modify_auth_module_or_config.toml → rules/_deprecated/persistence_credential_access_modify_auth_module_or_config.toml
+54 -52
View File
@@ -1,8 +1,9 @@
[metadata]
creation_date = "2020/12/21"
deprecation_date = "2026/02/04"
integration = ["endpoint"]
maturity = "production"
updated_date = "2025/12/08"
maturity = "deprecated"
updated_date = "2026/02/04"
[rule]
author = ["Elastic"]
@@ -18,56 +19,6 @@ index = ["auditbeat-*", "logs-endpoint.events.*"]
language = "kuery"
license = "Elastic License v2"
name = "Deprecated - Modification of Standard Authentication Module or Configuration"
references = [
"https://github.com/zephrax/linux-pam-backdoor",
"https://github.com/eurialo/pambd",
"http://0x90909090.blogspot.com/2016/06/creating-backdoor-in-pam-in-5-line-of.html",
"https://www.trendmicro.com/en_us/research/19/i/skidmap-linux-malware-uses-rootkit-capabilities-to-hide-cryptocurrency-mining-payload.html",
]
risk_score = 47
rule_id = "93f47b6f-5728-4004-ba00-625083b3dcb0"
severity = "medium"
tags = [
"Domain: Endpoint",
"OS: macOS",
"OS: Linux",
"Use Case: Threat Detection",
"Tactic: Credential Access",
"Tactic: Persistence",
"Data Source: Elastic Defend",
"Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "new_terms"
query = '''
event.category:file and event.type:change and
(file.name:pam_*.so or file.path:(/etc/pam.d/* or /private/etc/pam.d/* or /usr/lib64/security/*)) and
process.executable:
(* and
not
(
/usr/libexec/packagekitd or
/usr/bin/vim or
/usr/libexec/xpcproxy or
/usr/bin/bsdtar or
/usr/local/bin/brew or
"/System/Library/PrivateFrameworks/PackageKit.framework/Versions/A/XPCServices/package_script_service.xpc/Contents/MacOS/package_script_service"
)
) and
not file.path:
(
/tmp/snap.rootfs_*/pam_*.so or
/tmp/newroot/lib/*/pam_*.so or
/private/var/folders/*/T/com.apple.fileprovider.ArchiveService/TemporaryItems/*/lib/security/pam_*.so or
/tmp/newroot/usr/lib64/security/pam_*.so
) and
not process.name:
(
yum or dnf or rsync or platform-python or authconfig or rpm or pdkg or apk or dnf-automatic or btrfs or
dpkg or pam-auth-update or steam or platform-python3.6 or pam-config or microdnf or yum_install or yum-cron or
systemd or containerd or pacman
)
'''
note = """## Triage and analysis
> **Disclaimer**:
@@ -103,6 +54,57 @@ Authentication modules, such as PAM (Pluggable Authentication Modules), are cruc
- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if other systems may be affected.
- Implement enhanced monitoring on the affected system and similar environments to detect any future unauthorized modifications to authentication modules or configurations.
- Review and update access controls and authentication policies to strengthen security measures and reduce the risk of similar attacks in the future."""
references = [
"https://github.com/zephrax/linux-pam-backdoor",
"https://github.com/eurialo/pambd",
"http://0x90909090.blogspot.com/2016/06/creating-backdoor-in-pam-in-5-line-of.html",
"https://www.trendmicro.com/en_us/research/19/i/skidmap-linux-malware-uses-rootkit-capabilities-to-hide-cryptocurrency-mining-payload.html",
]
risk_score = 47
rule_id = "93f47b6f-5728-4004-ba00-625083b3dcb0"
severity = "medium"
tags = [
"Domain: Endpoint",
"OS: macOS",
"OS: Linux",
"Use Case: Threat Detection",
"Tactic: Credential Access",
"Tactic: Persistence",
"Data Source: Elastic Defend",
"Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "new_terms"
query = '''
event.category:file and event.type:change and
(file.name:pam_*.so or file.path:(/etc/pam.d/* or /private/etc/pam.d/* or /usr/lib64/security/*)) and
process.executable:
(* and
not
(
/usr/libexec/packagekitd or
/usr/bin/vim or
/usr/libexec/xpcproxy or
/usr/bin/bsdtar or
/usr/local/bin/brew or
"/System/Library/PrivateFrameworks/PackageKit.framework/Versions/A/XPCServices/package_script_service.xpc/Contents/MacOS/package_script_service"
)
) and
not file.path:
(
/tmp/snap.rootfs_*/pam_*.so or
/tmp/newroot/lib/*/pam_*.so or
/private/var/folders/*/T/com.apple.fileprovider.ArchiveService/TemporaryItems/*/lib/security/pam_*.so or
/tmp/newroot/usr/lib64/security/pam_*.so
) and
not process.name:
(
yum or dnf or rsync or platform-python or authconfig or rpm or pdkg or apk or dnf-automatic or btrfs or
dpkg or pam-auth-update or steam or platform-python3.6 or pam-config or microdnf or yum_install or yum-cron or
systemd or containerd or pacman
)
'''
[[rule.threat]]
rules/linux/privilege_escalation_linux_uid_int_max_bug.toml → rules/_deprecated/privilege_escalation_linux_uid_int_max_bug.toml
+7 -3
View File
@@ -1,8 +1,9 @@
[metadata]
creation_date = "2023/07/27"
deprecation_date = "2026/02/04"
integration = ["endpoint", "crowdstrike"]
maturity = "production"
updated_date = "2025/12/23"
maturity = "deprecated"
updated_date = "2026/02/04"
[rule]
author = ["Elastic"]
@@ -95,21 +96,24 @@ tags = [
]
timestamp_override = "event.ingested"
type = "eql"
query = '''
process where host.os.type == "linux" and event.type == "start" and
event.action in ("exec", "exec_event", "ProcessRollup2") and
process.name == "systemd-run" and process.args == "-t" and process.args_count >= 3 and user.id >= "1000000000"
'''
[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1068"
name = "Exploitation for Privilege Escalation"
reference = "https://attack.mitre.org/techniques/T1068/"
[rule.threat.tactic]
id = "TA0004"
name = "Privilege Escalation"
reference = "https://attack.mitre.org/tactics/TA0004/"
rules/linux/privilege_escalation_netcon_via_sudo_binary.toml → rules/_deprecated/privilege_escalation_netcon_via_sudo_binary.toml
+9 -5
View File
@@ -1,8 +1,9 @@
[metadata]
creation_date = "2024/01/15"
deprecation_date = "2026/02/04"
integration = ["endpoint"]
maturity = "production"
updated_date = "2025/12/23"
maturity = "deprecated"
updated_date = "2026/02/04"
[rule]
author = ["Elastic"]
@@ -88,6 +89,7 @@ tags = [
"Resources: Investigation Guide",
]
type = "eql"
query = '''
sequence by host.id, process.entity_id with maxspan=5s
[process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and process.name == "sudo" and not (
@@ -106,30 +108,32 @@ sequence by host.id, process.entity_id with maxspan=5s
)]
'''
[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1055"
name = "Process Injection"
reference = "https://attack.mitre.org/techniques/T1055/"
[[rule.threat.technique.subtechnique]]
id = "T1055.008"
name = "Ptrace System Calls"
reference = "https://attack.mitre.org/techniques/T1055/008/"
[[rule.threat.technique]]
id = "T1548"
name = "Abuse Elevation Control Mechanism"
reference = "https://attack.mitre.org/techniques/T1548/"
[[rule.threat.technique.subtechnique]]
id = "T1548.003"
name = "Sudo and Sudo Caching"
reference = "https://attack.mitre.org/techniques/T1548/003/"
[rule.threat.tactic]
id = "TA0004"
name = "Privilege Escalation"
reference = "https://attack.mitre.org/tactics/TA0004/"
rules/cross-platform/execution_pentest_eggshell_remote_admin_tool.toml
+3 -3
View File
@@ -2,7 +2,7 @@
creation_date = "2021/01/12"
integration = ["endpoint"]
maturity = "production"
updated_date = "2025/01/15"
updated_date = "2026/02/04"
[rule]
author = ["Elastic"]
@@ -11,7 +11,7 @@ from = "now-9m"
index = ["auditbeat-*", "logs-endpoint.events.*"]
language = "kuery"
license = "Elastic License v2"
name = "EggShell Backdoor Execution"
name = "Deprecated - EggShell Backdoor Execution"
references = ["https://github.com/neoneggplant/EggShell"]
risk_score = 73
rule_id = "41824afb-d68c-4d0e-bfee-474dac1fa56e"
@@ -36,7 +36,7 @@ note = """## Triage and analysis
> **Disclaimer**:
> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
### Investigating EggShell Backdoor Execution
### Investigating Deprecated - EggShell Backdoor Execution
EggShell is a post-exploitation tool used on macOS and Linux systems, allowing adversaries to execute commands and scripts remotely. It leverages command and scripting interpreters to gain control over compromised systems. Attackers exploit this by executing malicious payloads, maintaining persistence, and exfiltrating data. The detection rule identifies suspicious process activities, specifically targeting the execution patterns and arguments associated with EggShell, to alert analysts of potential backdoor usage.
rules/cross-platform/privilege_escalation_sudo_buffer_overflow.toml
+3 -3
View File
@@ -2,7 +2,7 @@
creation_date = "2021/02/03"
integration = ["endpoint"]
maturity = "production"
updated_date = "2025/01/15"
updated_date = "2026/02/04"
[rule]
author = ["Elastic"]
@@ -21,7 +21,7 @@ from = "now-9m"
index = ["auditbeat-*", "logs-endpoint.events.*"]
language = "kuery"
license = "Elastic License v2"
name = "Sudo Heap-Based Buffer Overflow Attempt"
name = "Deprecated - Sudo Heap-Based Buffer Overflow Attempt"
references = [
"https://cve.mitre.org/cgi-bin/cvename.cgi?name=2021-3156",
"https://blog.qualys.com/vulnerabilities-research/2021/01/26/cve-2021-3156-heap-based-buffer-overflow-in-sudo-baron-samedit",
@@ -54,7 +54,7 @@ note = """## Triage and analysis
> **Disclaimer**:
> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
### Investigating Sudo Heap-Based Buffer Overflow Attempt
### Investigating Deprecated - Sudo Heap-Based Buffer Overflow Attempt
Sudo is a critical utility in Unix-like systems, allowing users to execute commands with elevated privileges. A heap-based buffer overflow in Sudo (CVE-2021-3156) can be exploited by attackers to gain root access. Adversaries may craft specific command-line arguments to trigger this vulnerability. The detection rule identifies suspicious Sudo or Sudoedit invocations with particular argument patterns, signaling potential exploitation attempts.
rules/integrations/github/defense_evasion_secret_scanning_disabled.toml
+2 -2
View File
@@ -1,8 +1,8 @@
[metadata]
creation_date = "2023/12/16"
creation_date = "2025/12/16"
integration = ["github"]
maturity = "production"
updated_date = "2026/01/12"
updated_date = "2026/02/04"
[rule]
author = ["Elastic"]
rules/integrations/github/exfiltration_github_private_repository_turned_public.toml
+2 -2
View File
@@ -1,8 +1,8 @@
[metadata]
creation_date = "2023/12/16"
creation_date = "2025/12/16"
integration = ["github"]
maturity = "production"
updated_date = "2026/01/12"
updated_date = "2026/02/04"
[rule]
author = ["Elastic"]