Prep for Release 9.0 (#4550)

rules/linux/command_and_control_frequent_egress_netcon_from_sus_executable.toml

@@ -2,17 +2,15 @@
 creation_date = "2025/02/20"
 integration = ["endpoint"]
 maturity = "production"
-min_stack_comments = "ES|QL rule type in technical preview as of 8.13"
-min_stack_version = "8.13.0"
-updated_date = "2025/02/20"
+updated_date = "2025/03/20"
 
 [rule]
 author = ["Elastic"]
 description = """
-This rule detects a high number of egress network connections from an unusual executable on a Linux system.
-This could indicate a command and control (C2) communication attempt, a brute force attack via a malware
-infection, or other malicious activity. ES|QL rules have limited fields available in its alert documents.
-Make sure to review the original documents to aid in the investigation of this alert.
+This rule detects a high number of egress network connections from an unusual executable on a Linux system. This could
+indicate a command and control (C2) communication attempt, a brute force attack via a malware infection, or other
+malicious activity. ES|QL rules have limited fields available in its alert documents. Make sure to review the original
+documents to aid in the investigation of this alert.
 """
 from = "now-61m"
 interval = "1h"
@@ -56,6 +54,7 @@ tags = [
 ]
 timestamp_override = "event.ingested"
 type = "esql"
+
 query = '''
 from logs-endpoint.events.network-*
 | keep @timestamp, host.os.type, event.type, event.action, process.name, process.executable, destination.ip, agent.id
@@ -85,15 +84,17 @@ from logs-endpoint.events.network-*
 | limit 100
 '''
 
+
 [[rule.threat]]
 framework = "MITRE ATT&CK"
-
 [[rule.threat.technique]]
 id = "T1071"
 name = "Application Layer Protocol"
 reference = "https://attack.mitre.org/techniques/T1071/"
 
+
 [rule.threat.tactic]
 id = "TA0011"
 name = "Command and Control"
 reference = "https://attack.mitre.org/tactics/TA0011/"
+

rules/linux/command_and_control_ip_forwarding_activity.toml

@@ -2,9 +2,7 @@
 creation_date = "2024/11/04"
 integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
-min_stack_version = "8.13.0"
-min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/02/04"
+updated_date = "2025/03/20"
 
 [rule]
 author = ["Elastic"]
@@ -18,35 +16,6 @@ index = ["endgame-*", "logs-endpoint.events.process*", "logs-sentinel_one_cloud_
 language = "eql"
 license = "Elastic License v2"
 name = "IPv4/IPv6 Forwarding Activity"
-risk_score = 21
-rule_id = "5a138e2e-aec3-4240-9843-56825d0bc569"
-severity = "low"
-tags = [
-    "Domain: Endpoint",
-    "OS: Linux",
-    "Use Case: Threat Detection",
-    "Tactic: Command and Control",
-    "Data Source: Elastic Defend",
-    "Data Source: SentinelOne",
-    "Data Source: Elastic Endgame",
-    "Resources: Investigation Guide",
-]
-timestamp_override = "event.ingested"
-type = "eql"
-query = '''
-process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "start", "exec_event") and
-process.parent.executable != null and process.command_line like (
-  "*net.ipv4.ip_forward*", "*/proc/sys/net/ipv4/ip_forward*", "*net.ipv6.conf.all.forwarding*",
-  "*/proc/sys/net/ipv6/conf/all/forwarding*"
-) and (
-  (process.name == "sysctl" and process.args like ("*-w*", "*--write*", "*=*")) or
-  (
-    process.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and process.args == "-c" and
-    process.command_line like "*echo *"
-  )
-) and
-not process.parent.name like~ ("privsep-helper", "platform-python*", "init.ipv6-global", "wsl-bootstrap")
-'''
 note = """## Triage and analysis
 
 > **Disclaimer**:
@@ -82,16 +51,48 @@ IPv4/IPv6 forwarding allows a Linux system to route traffic between network inte
 - Escalate the incident to the security operations team for further investigation and to determine if additional systems are compromised.
 - Implement network segmentation to limit the ability of attackers to pivot between networks in the future.
 - Enhance monitoring and alerting for similar suspicious activities by tuning detection systems to recognize patterns associated with IP forwarding misuse."""
+risk_score = 21
+rule_id = "5a138e2e-aec3-4240-9843-56825d0bc569"
+severity = "low"
+tags = [
+    "Domain: Endpoint",
+    "OS: Linux",
+    "Use Case: Threat Detection",
+    "Tactic: Command and Control",
+    "Data Source: Elastic Defend",
+    "Data Source: SentinelOne",
+    "Data Source: Elastic Endgame",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "eql"
+
+query = '''
+process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "start", "exec_event") and
+process.parent.executable != null and process.command_line like (
+  "*net.ipv4.ip_forward*", "*/proc/sys/net/ipv4/ip_forward*", "*net.ipv6.conf.all.forwarding*",
+  "*/proc/sys/net/ipv6/conf/all/forwarding*"
+) and (
+  (process.name == "sysctl" and process.args like ("*-w*", "*--write*", "*=*")) or
+  (
+    process.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and process.args == "-c" and
+    process.command_line like "*echo *"
+  )
+) and
+not process.parent.name like~ ("privsep-helper", "platform-python*", "init.ipv6-global", "wsl-bootstrap")
+'''
+
 
 [[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/linux/command_and_control_linux_proxychains_activity.toml

@@ -2,9 +2,7 @@
 creation_date = "2023/08/23"
 integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
-min_stack_version = "8.13.0"
-min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/02/04"
+updated_date = "2025/03/20"
 
 [transform]
 [[transform.osquery]]
@@ -41,7 +39,14 @@ resources. Attackers can exploit the ProxyChains utility to hide their true sour
 perform malicious activities through a chain of proxy servers, potentially masking their identity and intentions.
 """
 from = "now-9m"
-index = ["auditbeat-*", "endgame-*", "logs-auditd_manager.auditd-*", "logs-crowdstrike.fdr*", "logs-endpoint.events.process*", "logs-sentinel_one_cloud_funnel.*"]
+index = [
+    "auditbeat-*",
+    "endgame-*",
+    "logs-auditd_manager.auditd-*",
+    "logs-crowdstrike.fdr*",
+    "logs-endpoint.events.process*",
+    "logs-sentinel_one_cloud_funnel.*",
+]
 language = "eql"
 license = "Elastic License v2"
 name = "ProxyChains Activity"

rules/linux/command_and_control_linux_ssh_x11_forwarding.toml

@@ -2,9 +2,7 @@
 creation_date = "2023/08/23"
 integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
-min_stack_version = "8.13.0"
-min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/02/04"
+updated_date = "2025/03/20"
 
 [transform]
 [[transform.osquery]]
@@ -41,7 +39,12 @@ can abuse X11 forwarding for tunneling their GUI-based tools, pivot through comp
 communication channels, enabling lateral movement and facilitating remote control of systems within a network.
 """
 from = "now-9m"
-index = ["endgame-*", "logs-crowdstrike.fdr*", "logs-endpoint.events.process*", "logs-sentinel_one_cloud_funnel.*"]
+index = [
+    "endgame-*",
+    "logs-crowdstrike.fdr*",
+    "logs-endpoint.events.process*",
+    "logs-sentinel_one_cloud_funnel.*",
+]
 language = "eql"
 license = "Elastic License v2"
 name = "Linux SSH X11 Forwarding"
@@ -121,21 +124,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", "start", "ProcessRollup2") and
 process.name in ("ssh", "sshd") and process.args in ("-X", "-Y") and process.args_count >= 3 and
 process.parent.name in ("bash", "dash", "ash", "sh", "tcsh", "csh", "zsh", "ksh", "fish")
 '''
 
+
 [[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/linux/command_and_control_linux_suspicious_proxychains_activity.toml

@@ -2,9 +2,7 @@
 creation_date = "2023/08/23"
 integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
-min_stack_version = "8.13.0"
-min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/02/04"
+updated_date = "2025/03/20"
 
 [transform]
 [[transform.osquery]]
@@ -42,7 +40,14 @@ detection, and perform malicious activities through a chain of proxy servers, po
 intentions.
 """
 from = "now-9m"
-index = ["auditbeat-*", "endgame-*", "logs-auditd_manager.auditd-*", "logs-crowdstrike.fdr*", "logs-endpoint.events.process*", "logs-sentinel_one_cloud_funnel.*"]
+index = [
+    "auditbeat-*",
+    "endgame-*",
+    "logs-auditd_manager.auditd-*",
+    "logs-crowdstrike.fdr*",
+    "logs-endpoint.events.process*",
+    "logs-sentinel_one_cloud_funnel.*",
+]
 language = "eql"
 license = "Elastic License v2"
 name = "Suspicious Utility Launched via ProxyChains"

rules/linux/command_and_control_linux_tunneling_and_port_forwarding.toml

@@ -2,9 +2,7 @@
 creation_date = "2023/08/23"
 integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
-min_stack_version = "8.13.0"
-min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/02/04"
+updated_date = "2025/03/20"
 
 [transform]
 [[transform.osquery]]
@@ -41,7 +39,12 @@ and gain unauthorized access to internal resources, facilitating data exfiltrati
 control.
 """
 from = "now-9m"
-index = ["endgame-*", "logs-crowdstrike.fdr*", "logs-endpoint.events.process*", "logs-sentinel_one_cloud_funnel.*"]
+index = [
+    "endgame-*",
+    "logs-crowdstrike.fdr*",
+    "logs-endpoint.events.process*",
+    "logs-sentinel_one_cloud_funnel.*",
+]
 language = "eql"
 license = "Elastic License v2"
 name = "Potential Linux Tunneling and/or Port Forwarding"

rules/linux/command_and_control_tunneling_via_earthworm.toml

@@ -2,9 +2,7 @@
 creation_date = "2021/04/12"
 integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
-min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-min_stack_version = "8.13.0"
-updated_date = "2025/02/04"
+updated_date = "2025/03/20"
 
 [transform]
 [[transform.osquery]]
@@ -40,7 +38,13 @@ system within a separate protocol to avoid detection and network filtering, or t
 systems.
 """
 from = "now-9m"
-index = ["auditbeat-*", "endgame-*", "logs-crowdstrike.fdr*", "logs-endpoint.events.process*", "logs-sentinel_one_cloud_funnel.*"]
+index = [
+    "auditbeat-*",
+    "endgame-*",
+    "logs-crowdstrike.fdr*",
+    "logs-endpoint.events.process*",
+    "logs-sentinel_one_cloud_funnel.*",
+]
 language = "eql"
 license = "Elastic License v2"
 name = "Potential Protocol Tunneling via EarthWorm"

rules/linux/credential_access_credential_dumping.toml

@@ -2,9 +2,7 @@
 creation_date = "2023/02/27"
 integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
-min_stack_version = "8.13.0"
-min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/02/04"
+updated_date = "2025/03/20"
 
 [rule]
 author = ["Elastic"]
@@ -16,10 +14,49 @@ password-cracking utilities or prepare themselves for future operations by gathe
 victim.
 """
 from = "now-9m"
-index = ["endgame-*", "logs-crowdstrike.fdr*", "logs-endpoint.events.process*", "logs-sentinel_one_cloud_funnel.*"]
+index = [
+    "endgame-*",
+    "logs-crowdstrike.fdr*",
+    "logs-endpoint.events.process*",
+    "logs-sentinel_one_cloud_funnel.*",
+]
 language = "eql"
 license = "Elastic License v2"
 name = "Potential Linux Credential Dumping via Unshadow"
+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 Linux Credential Dumping via Unshadow
+
+Unshadow is a utility within the John the Ripper suite, used to merge `/etc/shadow` and `/etc/passwd` files, making them vulnerable to password cracking. Adversaries exploit this to extract and crack user credentials, gaining unauthorized access. The detection rule identifies suspicious execution of Unshadow by monitoring process activities, focusing on specific execution patterns and argument counts, thus flagging potential credential dumping attempts.
+
+### Possible investigation steps
+
+- Review the process execution details to confirm the presence of the unshadow utility by checking the process name and arguments, ensuring that the process.args_count is 3 or more.
+- Investigate the user account under which the unshadow process was executed to determine if it aligns with expected administrative activities or if it indicates potential unauthorized access.
+- Examine the command line arguments used with the unshadow process to identify the specific files targeted, such as /etc/shadow and /etc/passwd, and verify if these files were accessed or modified.
+- Check for any subsequent processes or activities that might indicate password cracking attempts, such as the execution of John the Ripper or similar tools, following the unshadow execution.
+- Correlate the event with other security alerts or logs from the same host or user to identify any patterns or additional suspicious activities that might suggest a broader attack campaign.
+- Assess the risk and impact by determining if any sensitive credentials were potentially exposed and consider implementing additional monitoring or access controls to prevent future incidents.
+
+### False positive analysis
+
+- System administrators or security teams may use the unshadow utility for legitimate auditing or recovery purposes. To handle this, create exceptions for known administrative accounts or specific maintenance windows.
+- Automated scripts or backup processes might invoke unshadow as part of routine operations. Identify these scripts and exclude their execution paths or associated user accounts from triggering alerts.
+- Security testing or penetration testing activities could involve the use of unshadow. Coordinate with the testing team to whitelist their activities during the testing period to avoid false positives.
+- Development or testing environments might have unshadow executed as part of security tool evaluations. Exclude these environments from monitoring or adjust the rule to focus on production systems only.
+
+### Response and remediation
+
+- Immediately isolate the affected host from the network to prevent further unauthorized access or data exfiltration.
+- Terminate any suspicious processes related to the unshadow utility to halt ongoing credential dumping activities.
+- Conduct a thorough review of the affected system's `/etc/shadow` and `/etc/passwd` files to identify any unauthorized modifications or access.
+- Change passwords for all user accounts on the affected system, prioritizing those with elevated privileges, to mitigate the risk of compromised credentials.
+- Review and update access controls and permissions for sensitive files, ensuring that only authorized users have access to `/etc/shadow` and `/etc/passwd`.
+- 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 similar activities across the network to detect and respond to future credential dumping attempts promptly."""
 references = ["https://www.cyberciti.biz/faq/unix-linux-password-cracking-john-the-ripper/"]
 risk_score = 47
 rule_id = "e7cb3cfd-aaa3-4d7b-af18-23b89955062c"
@@ -67,40 +104,6 @@ query = '''
 process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start", "ProcessRollup2") and
 process.name == "unshadow" and process.args_count >= 3
 '''
-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 Linux Credential Dumping via Unshadow
-
-Unshadow is a utility within the John the Ripper suite, used to merge `/etc/shadow` and `/etc/passwd` files, making them vulnerable to password cracking. Adversaries exploit this to extract and crack user credentials, gaining unauthorized access. The detection rule identifies suspicious execution of Unshadow by monitoring process activities, focusing on specific execution patterns and argument counts, thus flagging potential credential dumping attempts.
-
-### Possible investigation steps
-
-- Review the process execution details to confirm the presence of the unshadow utility by checking the process name and arguments, ensuring that the process.args_count is 3 or more.
-- Investigate the user account under which the unshadow process was executed to determine if it aligns with expected administrative activities or if it indicates potential unauthorized access.
-- Examine the command line arguments used with the unshadow process to identify the specific files targeted, such as /etc/shadow and /etc/passwd, and verify if these files were accessed or modified.
-- Check for any subsequent processes or activities that might indicate password cracking attempts, such as the execution of John the Ripper or similar tools, following the unshadow execution.
-- Correlate the event with other security alerts or logs from the same host or user to identify any patterns or additional suspicious activities that might suggest a broader attack campaign.
-- Assess the risk and impact by determining if any sensitive credentials were potentially exposed and consider implementing additional monitoring or access controls to prevent future incidents.
-
-### False positive analysis
-
-- System administrators or security teams may use the unshadow utility for legitimate auditing or recovery purposes. To handle this, create exceptions for known administrative accounts or specific maintenance windows.
-- Automated scripts or backup processes might invoke unshadow as part of routine operations. Identify these scripts and exclude their execution paths or associated user accounts from triggering alerts.
-- Security testing or penetration testing activities could involve the use of unshadow. Coordinate with the testing team to whitelist their activities during the testing period to avoid false positives.
-- Development or testing environments might have unshadow executed as part of security tool evaluations. Exclude these environments from monitoring or adjust the rule to focus on production systems only.
-
-### Response and remediation
-
-- Immediately isolate the affected host from the network to prevent further unauthorized access or data exfiltration.
-- Terminate any suspicious processes related to the unshadow utility to halt ongoing credential dumping activities.
-- Conduct a thorough review of the affected system's `/etc/shadow` and `/etc/passwd` files to identify any unauthorized modifications or access.
-- Change passwords for all user accounts on the affected system, prioritizing those with elevated privileges, to mitigate the risk of compromised credentials.
-- Review and update access controls and permissions for sensitive files, ensuring that only authorized users have access to `/etc/shadow` and `/etc/passwd`.
-- 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 similar activities across the network to detect and respond to future credential dumping attempts promptly."""
 
 
 [[rule.threat]]

rules/linux/credential_access_gdb_init_process_hooking.toml

@@ -2,9 +2,7 @@
 creation_date = "2023/08/30"
 integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
-min_stack_version = "8.13.0"
-min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/02/04"
+updated_date = "2025/03/20"
 
 [rule]
 author = ["Elastic"]
@@ -14,10 +12,49 @@ dumping techniques to attempt secret extraction from privileged processes. Tools
 "truffleproc" and "bash-memory-dump". This behavior should not happen by default, and should be investigated thoroughly.
 """
 from = "now-9m"
-index = ["endgame-*", "logs-crowdstrike.fdr*", "logs-endpoint.events.process*", "logs-sentinel_one_cloud_funnel.*"]
+index = [
+    "endgame-*",
+    "logs-crowdstrike.fdr*",
+    "logs-endpoint.events.process*",
+    "logs-sentinel_one_cloud_funnel.*",
+]
 language = "eql"
 license = "Elastic License v2"
 name = "Linux init (PID 1) Secret Dump via GDB"
+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 Linux init (PID 1) Secret Dump via GDB
+
+In Linux, the init process (PID 1) is the first process started by the kernel and is responsible for initializing the system. Adversaries may exploit debugging tools like GDB to dump memory from this process, potentially extracting sensitive information. The detection rule identifies suspicious GDB executions targeting PID 1, flagging unauthorized memory access attempts for further investigation.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the process name is "gdb" and the process arguments include "--pid" or "-p" with a target of PID "1".
+- Check the user account associated with the gdb process execution to determine if it is authorized to perform debugging tasks on the system.
+- Investigate the parent process of the gdb execution to understand how it was initiated and whether it was part of a legitimate workflow or script.
+- Examine system logs around the time of the alert to identify any other suspicious activities or related events that might indicate a broader attack.
+- Assess the system for any unauthorized changes or anomalies, such as new user accounts, modified configurations, or unexpected network connections.
+- If possible, capture and analyze memory dumps or other forensic artifacts to identify any sensitive information that may have been accessed or exfiltrated.
+
+### False positive analysis
+
+- System administrators or developers may use GDB for legitimate debugging purposes on the init process. To handle this, create exceptions for known maintenance windows or specific user accounts that are authorized to perform such actions.
+- Automated scripts or monitoring tools might inadvertently trigger this rule if they include GDB commands targeting PID 1 for health checks. Review and adjust these scripts to avoid unnecessary memory access or exclude them from the rule if they are verified as safe.
+- Security tools or forensic analysis software might use GDB as part of their operations. Identify these tools and whitelist their processes to prevent false positives while ensuring they are from trusted sources.
+- Training or testing environments may simulate attacks or debugging scenarios involving GDB and PID 1. Exclude these environments from the rule to avoid noise, ensuring they are isolated from production systems.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Terminate the suspicious gdb process targeting PID 1 to stop any ongoing memory dumping activity.
+- Conduct a thorough review of system logs and process execution history to identify any additional unauthorized access attempts or related suspicious activities.
+- Change all credentials and secrets that may have been exposed or accessed during the memory dump, focusing on those used by the init process and other privileged accounts.
+- Implement stricter access controls and monitoring for debugging tools like gdb, ensuring only authorized personnel can execute such tools on critical systems.
+- Escalate the incident to the security operations team for a comprehensive investigation and to determine if further forensic analysis is required.
+- Update and enhance detection rules and monitoring systems to better identify and alert on similar unauthorized memory access attempts in the future."""
 references = ["https://github.com/controlplaneio/truffleproc", "https://github.com/hajzer/bash-memory-dump"]
 risk_score = 47
 rule_id = "d4ff2f53-c802-4d2e-9fb9-9ecc08356c3f"
@@ -65,40 +102,6 @@ query = '''
 process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start", "ProcessRollup2") and
 process.name == "gdb" and process.args in ("--pid", "-p") and process.args == "1"
 '''
-note = """## Triage and analysis
-
-> **Disclaimer**:
-> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
-
-### Investigating Linux init (PID 1) Secret Dump via GDB
-
-In Linux, the init process (PID 1) is the first process started by the kernel and is responsible for initializing the system. Adversaries may exploit debugging tools like GDB to dump memory from this process, potentially extracting sensitive information. The detection rule identifies suspicious GDB executions targeting PID 1, flagging unauthorized memory access attempts for further investigation.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the process name is "gdb" and the process arguments include "--pid" or "-p" with a target of PID "1".
-- Check the user account associated with the gdb process execution to determine if it is authorized to perform debugging tasks on the system.
-- Investigate the parent process of the gdb execution to understand how it was initiated and whether it was part of a legitimate workflow or script.
-- Examine system logs around the time of the alert to identify any other suspicious activities or related events that might indicate a broader attack.
-- Assess the system for any unauthorized changes or anomalies, such as new user accounts, modified configurations, or unexpected network connections.
-- If possible, capture and analyze memory dumps or other forensic artifacts to identify any sensitive information that may have been accessed or exfiltrated.
-
-### False positive analysis
-
-- System administrators or developers may use GDB for legitimate debugging purposes on the init process. To handle this, create exceptions for known maintenance windows or specific user accounts that are authorized to perform such actions.
-- Automated scripts or monitoring tools might inadvertently trigger this rule if they include GDB commands targeting PID 1 for health checks. Review and adjust these scripts to avoid unnecessary memory access or exclude them from the rule if they are verified as safe.
-- Security tools or forensic analysis software might use GDB as part of their operations. Identify these tools and whitelist their processes to prevent false positives while ensuring they are from trusted sources.
-- Training or testing environments may simulate attacks or debugging scenarios involving GDB and PID 1. Exclude these environments from the rule to avoid noise, ensuring they are isolated from production systems.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
-- Terminate the suspicious gdb process targeting PID 1 to stop any ongoing memory dumping activity.
-- Conduct a thorough review of system logs and process execution history to identify any additional unauthorized access attempts or related suspicious activities.
-- Change all credentials and secrets that may have been exposed or accessed during the memory dump, focusing on those used by the init process and other privileged accounts.
-- Implement stricter access controls and monitoring for debugging tools like gdb, ensuring only authorized personnel can execute such tools on critical systems.
-- Escalate the incident to the security operations team for a comprehensive investigation and to determine if further forensic analysis is required.
-- Update and enhance detection rules and monitoring systems to better identify and alert on similar unauthorized memory access attempts in the future."""
 
 
 [[rule.threat]]

rules/linux/credential_access_gdb_process_hooking.toml

@@ -2,9 +2,7 @@
 creation_date = "2023/08/30"
 integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
-min_stack_version = "8.13.0"
-min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/02/04"
+updated_date = "2025/03/20"
 
 [rule]
 author = ["Elastic"]
@@ -14,35 +12,17 @@ secret extraction from privileged processes. Tools that display this behavior in
 "bash-memory-dump". This behavior should not happen by default, and should be investigated thoroughly.
 """
 from = "now-9m"
-index = ["auditbeat-*", "endgame-*", "logs-auditd_manager.auditd-*", "logs-crowdstrike.fdr*", "logs-endpoint.events.process*", "logs-sentinel_one_cloud_funnel.*"]
+index = [
+    "auditbeat-*",
+    "endgame-*",
+    "logs-auditd_manager.auditd-*",
+    "logs-crowdstrike.fdr*",
+    "logs-endpoint.events.process*",
+    "logs-sentinel_one_cloud_funnel.*",
+]
 language = "eql"
 license = "Elastic License v2"
 name = "Linux Process Hooking via GDB"
-references = ["https://github.com/controlplaneio/truffleproc", "https://github.com/hajzer/bash-memory-dump"]
-risk_score = 21
-rule_id = "66c058f3-99f4-4d18-952b-43348f2577a0"
-severity = "low"
-tags = [
-    "Domain: Endpoint",
-    "OS: Linux",
-    "Use Case: Threat Detection",
-    "Tactic: Credential Access",
-    "Data Source: Elastic Defend",
-    "Data Source: Elastic Endgame",
-    "Data Source: Auditd Manager",
-    "Data Source: Crowdstrike",
-    "Data Source: SentinelOne",
-    "Resources: Investigation Guide",
-]
-timestamp_override = "event.ingested"
-type = "eql"
-
-query = '''
-process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started")
- and process.name == "gdb" and process.args in ("--pid", "-p") and
-/* Covered by d4ff2f53-c802-4d2e-9fb9-9ecc08356c3f */
-process.args != "1"
-'''
 note = """## Triage and analysis
 
 > **Disclaimer**:
@@ -78,6 +58,31 @@ GDB, the GNU Debugger, is a powerful tool used for debugging applications by ins
 - Change credentials for any accounts that may have been exposed or accessed during the incident to prevent unauthorized use.
 - Implement stricter access controls and monitoring for systems that handle sensitive information to prevent similar incidents.
 - Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected."""
+references = ["https://github.com/controlplaneio/truffleproc", "https://github.com/hajzer/bash-memory-dump"]
+risk_score = 21
+rule_id = "66c058f3-99f4-4d18-952b-43348f2577a0"
+severity = "low"
+tags = [
+    "Domain: Endpoint",
+    "OS: Linux",
+    "Use Case: Threat Detection",
+    "Tactic: Credential Access",
+    "Data Source: Elastic Defend",
+    "Data Source: Elastic Endgame",
+    "Data Source: Auditd Manager",
+    "Data Source: Crowdstrike",
+    "Data Source: SentinelOne",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "eql"
+
+query = '''
+process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started")
+ and process.name == "gdb" and process.args in ("--pid", "-p") and
+/* Covered by d4ff2f53-c802-4d2e-9fb9-9ecc08356c3f */
+process.args != "1"
+'''
 
 
 [[rule.threat]]

rules/linux/credential_access_proc_credential_dumping.toml

@@ -2,9 +2,7 @@
 creation_date = "2023/04/26"
 integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
-min_stack_version = "8.13.0"
-min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/02/04"
+updated_date = "2025/03/20"
 
 [rule]
 author = ["Elastic"]
@@ -19,6 +17,42 @@ index = ["endgame-*", "logs-endpoint.events.process*", "logs-sentinel_one_cloud_
 language = "eql"
 license = "Elastic License v2"
 name = "Potential Linux Credential Dumping via Proc Filesystem"
+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 Linux Credential Dumping via Proc Filesystem
+
+The /proc filesystem in Linux provides a window into the system's processes, offering details like memory usage and command-line arguments. Adversaries exploit this by using tools like mimipenguin to extract plaintext credentials from memory, leveraging vulnerabilities such as CVE-2018-20781. The detection rule identifies suspicious sequences involving the 'ps' and 'strings' commands, which are indicative of attempts to access and parse sensitive data from the /proc filesystem.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific host.id where the suspicious activity was detected, focusing on the processes involved.
+- Examine the process execution history on the affected host to confirm the presence of the 'ps' and 'strings' commands executed in sequence, as indicated by the query.
+- Investigate the command-line arguments used with the 'ps' and 'strings' commands to determine if they match the suspicious patterns specified in the query, such as '-eo pid command' and '/tmp/*'.
+- Check for any recent modifications or suspicious files in the /tmp directory on the affected host, as this is a common location for temporary files used in attacks.
+- Analyze the system logs and any available network traffic data to identify potential lateral movement or data exfiltration attempts following the credential dumping activity.
+- Assess the system for any signs of compromise or additional malicious activity, such as unauthorized user accounts or unexpected network connections.
+- Consider isolating the affected host from the network to prevent further credential exposure and initiate a comprehensive forensic analysis to understand the full scope of the incident.
+
+### False positive analysis
+
+- System administrators or monitoring tools may use the 'ps' and 'strings' commands for legitimate system diagnostics and performance monitoring. To mitigate this, create exceptions for known administrative scripts or tools that regularly execute these commands.
+- Automated scripts for system health checks might trigger the rule if they use 'ps' and 'strings' to gather process information. Identify and whitelist these scripts by their specific command patterns or execution paths.
+- Security tools that perform regular scans or audits might mimic the behavior detected by the rule. Review and exclude these tools by their process names or execution context to prevent false alerts.
+- Developers or testers running debugging sessions may inadvertently trigger the rule when analyzing process memory. Establish a process to temporarily disable the rule or exclude specific user accounts during known testing periods.
+- Custom monitoring solutions that log process details for analysis could match the rule's criteria. Document and exclude these solutions by their unique execution characteristics or host identifiers.
+
+### Response and remediation
+
+- Immediately isolate the affected host from the network to prevent further credential exposure and potential lateral movement by the adversary.
+- Terminate any suspicious processes identified by the detection rule, specifically those involving the 'ps' and 'strings' commands with the specified arguments.
+- Conduct a thorough review of the affected system's process memory and logs to identify any additional unauthorized access or data exfiltration attempts.
+- Change passwords for all user accounts on the affected system, prioritizing those with elevated privileges, to mitigate the risk of credential misuse.
+- Apply patches and updates to address CVE-2018-20781 and any other known vulnerabilities on the affected system to prevent future exploitation.
+- Enhance monitoring and logging on the affected host and similar systems to detect any recurrence of the exploit or similar suspicious activities.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to assess the potential impact on the broader network."""
 references = [
     "https://github.com/huntergregal/mimipenguin",
     "https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-20781",
@@ -71,42 +105,6 @@ sequence by host.id, process.parent.name with maxspan=1m
   [process where host.os.type == "linux" and process.name == "strings" and event.action in ("exec", "start", "exec_event")
    and process.args : "/tmp/*"]
 '''
-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 Linux Credential Dumping via Proc Filesystem
-
-The /proc filesystem in Linux provides a window into the system's processes, offering details like memory usage and command-line arguments. Adversaries exploit this by using tools like mimipenguin to extract plaintext credentials from memory, leveraging vulnerabilities such as CVE-2018-20781. The detection rule identifies suspicious sequences involving the 'ps' and 'strings' commands, which are indicative of attempts to access and parse sensitive data from the /proc filesystem.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific host.id where the suspicious activity was detected, focusing on the processes involved.
-- Examine the process execution history on the affected host to confirm the presence of the 'ps' and 'strings' commands executed in sequence, as indicated by the query.
-- Investigate the command-line arguments used with the 'ps' and 'strings' commands to determine if they match the suspicious patterns specified in the query, such as '-eo pid command' and '/tmp/*'.
-- Check for any recent modifications or suspicious files in the /tmp directory on the affected host, as this is a common location for temporary files used in attacks.
-- Analyze the system logs and any available network traffic data to identify potential lateral movement or data exfiltration attempts following the credential dumping activity.
-- Assess the system for any signs of compromise or additional malicious activity, such as unauthorized user accounts or unexpected network connections.
-- Consider isolating the affected host from the network to prevent further credential exposure and initiate a comprehensive forensic analysis to understand the full scope of the incident.
-
-### False positive analysis
-
-- System administrators or monitoring tools may use the 'ps' and 'strings' commands for legitimate system diagnostics and performance monitoring. To mitigate this, create exceptions for known administrative scripts or tools that regularly execute these commands.
-- Automated scripts for system health checks might trigger the rule if they use 'ps' and 'strings' to gather process information. Identify and whitelist these scripts by their specific command patterns or execution paths.
-- Security tools that perform regular scans or audits might mimic the behavior detected by the rule. Review and exclude these tools by their process names or execution context to prevent false alerts.
-- Developers or testers running debugging sessions may inadvertently trigger the rule when analyzing process memory. Establish a process to temporarily disable the rule or exclude specific user accounts during known testing periods.
-- Custom monitoring solutions that log process details for analysis could match the rule's criteria. Document and exclude these solutions by their unique execution characteristics or host identifiers.
-
-### Response and remediation
-
-- Immediately isolate the affected host from the network to prevent further credential exposure and potential lateral movement by the adversary.
-- Terminate any suspicious processes identified by the detection rule, specifically those involving the 'ps' and 'strings' commands with the specified arguments.
-- Conduct a thorough review of the affected system's process memory and logs to identify any additional unauthorized access or data exfiltration attempts.
-- Change passwords for all user accounts on the affected system, prioritizing those with elevated privileges, to mitigate the risk of credential misuse.
-- Apply patches and updates to address CVE-2018-20781 and any other known vulnerabilities on the affected system to prevent future exploitation.
-- Enhance monitoring and logging on the affected host and similar systems to detect any recurrence of the exploit or similar suspicious activities.
-- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to assess the potential impact on the broader network."""
 
 
 [[rule.threat]]

rules/linux/credential_access_ssh_backdoor_log.toml

@@ -2,9 +2,7 @@
 creation_date = "2020/12/21"
 integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
-min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-min_stack_version = "8.13.0"
-updated_date = "2025/01/29"
+updated_date = "2025/03/20"
 
 [rule]
 author = ["Elastic"]
@@ -19,6 +17,41 @@ index = ["auditbeat-*", "logs-endpoint.events.file-*", "endgame-*", "logs-sentin
 language = "eql"
 license = "Elastic License v2"
 name = "Potential OpenSSH Backdoor Logging Activity"
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
+
+### Investigating Potential OpenSSH Backdoor Logging Activity
+
+OpenSSH is a widely used protocol for secure remote administration and file transfers. Adversaries may exploit OpenSSH by modifying its binaries to log credentials or maintain unauthorized access. The detection rule identifies suspicious file changes linked to SSH processes, focusing on unusual file names, extensions, and paths indicative of backdoor activity, thus helping to uncover potential security breaches.
+
+### Possible investigation steps
+
+- Review the file change event details to identify the specific file name, extension, and path involved in the alert. Pay particular attention to unusual file names or extensions and paths listed in the query, such as "/usr/lib/*.so.*" or "/private/etc/ssh/.sshd_auth".
+- Examine the process executable that triggered the alert, either "/usr/sbin/sshd" or "/usr/bin/ssh", to determine if it has been modified or replaced. Check the integrity of these binaries using hash comparisons against known good versions.
+- Investigate the user account associated with the process that made the file change. Determine if the account has a history of suspicious activity or if it has been compromised.
+- Check for any recent or unusual login attempts or sessions related to the SSH service on the host. Look for patterns that might indicate unauthorized access or credential harvesting.
+- Analyze system logs, such as auth.log or secure.log, for any anomalies or entries that coincide with the time of the file change event. This can provide additional context or evidence of malicious activity.
+- If a backdoor is suspected, consider isolating the affected system from the network to prevent further unauthorized access and begin remediation efforts, such as restoring from a clean backup or reinstalling the affected services.
+
+### False positive analysis
+
+- Routine system updates or package installations may trigger file changes in SSH-related directories. Users can create exceptions for known update processes to prevent false alerts.
+- Custom scripts or administrative tasks that modify SSH configuration files for legitimate purposes might be flagged. Users should whitelist these scripts or processes if they are verified as non-malicious.
+- Backup or synchronization tools that create temporary files with unusual extensions or names in SSH directories can cause false positives. Exclude these tools from monitoring if they are part of regular operations.
+- Development or testing environments where SSH binaries are frequently modified for testing purposes may generate alerts. Implement exclusions for these environments to reduce noise.
+- Automated configuration management tools like Ansible or Puppet that modify SSH settings as part of their operations can be excluded if they are part of authorized workflows.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Terminate any suspicious SSH processes identified in the alert to halt potential backdoor activity.
+- Conduct a thorough review of the modified files and binaries, particularly those listed in the query, to assess the extent of the compromise and identify any malicious code or unauthorized changes.
+- Restore affected files and binaries from a known good backup to ensure system integrity and remove any backdoor modifications.
+- Change all SSH credentials and keys associated with the compromised system to prevent unauthorized access using potentially logged credentials.
+- Implement additional monitoring on the affected system and network for any signs of persistence or further malicious activity, focusing on the paths and file types highlighted in the detection query.
+- Escalate the incident to the security operations team for further investigation and to determine if additional systems may be affected, ensuring a coordinated response to the threat."""
 references = [
     "https://github.com/eset/malware-ioc/tree/master/sshdoor",
     "https://www.welivesecurity.com/wp-content/uploads/2021/01/ESET_Kobalos.pdf",
@@ -112,41 +145,6 @@ file where host.os.type == "linux" and event.type == "change" and process.execut
     )
   )
 '''
-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 OpenSSH Backdoor Logging Activity
-
-OpenSSH is a widely used protocol for secure remote administration and file transfers. Adversaries may exploit OpenSSH by modifying its binaries to log credentials or maintain unauthorized access. The detection rule identifies suspicious file changes linked to SSH processes, focusing on unusual file names, extensions, and paths indicative of backdoor activity, thus helping to uncover potential security breaches.
-
-### Possible investigation steps
-
-- Review the file change event details to identify the specific file name, extension, and path involved in the alert. Pay particular attention to unusual file names or extensions and paths listed in the query, such as "/usr/lib/*.so.*" or "/private/etc/ssh/.sshd_auth".
-- Examine the process executable that triggered the alert, either "/usr/sbin/sshd" or "/usr/bin/ssh", to determine if it has been modified or replaced. Check the integrity of these binaries using hash comparisons against known good versions.
-- Investigate the user account associated with the process that made the file change. Determine if the account has a history of suspicious activity or if it has been compromised.
-- Check for any recent or unusual login attempts or sessions related to the SSH service on the host. Look for patterns that might indicate unauthorized access or credential harvesting.
-- Analyze system logs, such as auth.log or secure.log, for any anomalies or entries that coincide with the time of the file change event. This can provide additional context or evidence of malicious activity.
-- If a backdoor is suspected, consider isolating the affected system from the network to prevent further unauthorized access and begin remediation efforts, such as restoring from a clean backup or reinstalling the affected services.
-
-### False positive analysis
-
-- Routine system updates or package installations may trigger file changes in SSH-related directories. Users can create exceptions for known update processes to prevent false alerts.
-- Custom scripts or administrative tasks that modify SSH configuration files for legitimate purposes might be flagged. Users should whitelist these scripts or processes if they are verified as non-malicious.
-- Backup or synchronization tools that create temporary files with unusual extensions or names in SSH directories can cause false positives. Exclude these tools from monitoring if they are part of regular operations.
-- Development or testing environments where SSH binaries are frequently modified for testing purposes may generate alerts. Implement exclusions for these environments to reduce noise.
-- Automated configuration management tools like Ansible or Puppet that modify SSH settings as part of their operations can be excluded if they are part of authorized workflows.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
-- Terminate any suspicious SSH processes identified in the alert to halt potential backdoor activity.
-- Conduct a thorough review of the modified files and binaries, particularly those listed in the query, to assess the extent of the compromise and identify any malicious code or unauthorized changes.
-- Restore affected files and binaries from a known good backup to ensure system integrity and remove any backdoor modifications.
-- Change all SSH credentials and keys associated with the compromised system to prevent unauthorized access using potentially logged credentials.
-- Implement additional monitoring on the affected system and network for any signs of persistence or further malicious activity, focusing on the paths and file types highlighted in the detection query.
-- Escalate the incident to the security operations team for further investigation and to determine if additional systems may be affected, ensuring a coordinated response to the threat."""
 
 
 [[rule.threat]]

rules/linux/defense_evasion_acl_modification_via_setfacl.toml

@@ -2,48 +2,23 @@
 creation_date = "2024/08/23"
 integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
-min_stack_version = "8.13.0"
-min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/02/04"
+updated_date = "2025/03/20"
 
 [rule]
 author = ["Elastic"]
-description = """
-This rule detects Linux Access Control List (ACL) modification via the setfacl command.
-"""
+description = "This rule detects Linux Access Control List (ACL) modification via the setfacl command.\n"
 from = "now-9m"
-index = ["auditbeat-*", "endgame-*", "logs-auditd_manager.auditd-*", "logs-crowdstrike.fdr*", "logs-endpoint.events.process*", "logs-sentinel_one_cloud_funnel.*"]
+index = [
+    "auditbeat-*",
+    "endgame-*",
+    "logs-auditd_manager.auditd-*",
+    "logs-crowdstrike.fdr*",
+    "logs-endpoint.events.process*",
+    "logs-sentinel_one_cloud_funnel.*",
+]
 language = "eql"
 license = "Elastic License v2"
 name = "Access Control List Modification via setfacl"
-references = ["https://www.uptycs.com/blog/threat-research-report-team/evasive-techniques-used-by-malicious-linux-shell-scripts"]
-risk_score = 21
-rule_id = "999565a2-fc52-4d72-91e4-ba6712c0377e"
-severity = "low"
-tags = [
-    "Domain: Endpoint",
-    "OS: Linux",
-    "Use Case: Threat Detection",
-    "Tactic: Defense Evasion",
-    "Data Source: Elastic Defend",
-    "Data Source: Elastic Endgame",
-    "Data Source: Auditd Manager",
-    "Data Source: Crowdstrike",
-    "Data Source: SentinelOne",
-    "Resources: Investigation Guide",
-]
-timestamp_override = "event.ingested"
-type = "eql"
-query = '''
-process where host.os.type == "linux" and event.type == "start" and
-event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and
-process.name == "setfacl" and not (
-  process.command_line == "/bin/setfacl --restore=-" or
-  process.args == "/var/log/journal/" or
-  process.parent.name in ("stats.pl", "perl", "find") or
-  process.parent.command_line like~ "/bin/sh -c *ansible*"
-)
-'''
 note = """## Triage and analysis
 
 > **Disclaimer**:
@@ -77,21 +52,54 @@ Access Control Lists (ACLs) in Linux enhance file permission management by allow
 - Update and patch the system to address any vulnerabilities that may have been exploited to gain access.
 - Implement stricter access controls and monitoring on critical systems to detect and prevent unauthorized ACL modifications in the future.
 - Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected."""
+references = [
+    "https://www.uptycs.com/blog/threat-research-report-team/evasive-techniques-used-by-malicious-linux-shell-scripts",
+]
+risk_score = 21
+rule_id = "999565a2-fc52-4d72-91e4-ba6712c0377e"
+severity = "low"
+tags = [
+    "Domain: Endpoint",
+    "OS: Linux",
+    "Use Case: Threat Detection",
+    "Tactic: Defense Evasion",
+    "Data Source: Elastic Defend",
+    "Data Source: Elastic Endgame",
+    "Data Source: Auditd Manager",
+    "Data Source: Crowdstrike",
+    "Data Source: SentinelOne",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "eql"
+
+query = '''
+process where host.os.type == "linux" and event.type == "start" and
+event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and
+process.name == "setfacl" and not (
+  process.command_line == "/bin/setfacl --restore=-" or
+  process.args == "/var/log/journal/" or
+  process.parent.name in ("stats.pl", "perl", "find") or
+  process.parent.command_line like~ "/bin/sh -c *ansible*"
+)
+'''
+
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
-
 [[rule.threat.technique]]
 id = "T1222"
 name = "File and Directory Permissions Modification"
 reference = "https://attack.mitre.org/techniques/T1222/"
-
 [[rule.threat.technique.subtechnique]]
 id = "T1222.002"
 name = "Linux and Mac File and Directory Permissions Modification"
 reference = "https://attack.mitre.org/techniques/T1222/002/"
 
+
+
 [rule.threat.tactic]
 id = "TA0005"
 name = "Defense Evasion"
 reference = "https://attack.mitre.org/tactics/TA0005/"
+

rules/linux/defense_evasion_attempt_to_disable_auditd_service.toml

@@ -2,22 +2,58 @@
 creation_date = "2024/08/28"
 integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
-min_stack_version = "8.13.0"
-min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/24"
+updated_date = "2025/03/20"
 
 [rule]
 author = ["Elastic"]
 description = """
-Adversaries may attempt to disable the Auditd service to evade detection. Auditd is a Linux service that
-provides system auditing and logging. Disabling the Auditd service can prevent the system from logging important
-security events, which can be used to detect malicious activity.
+Adversaries may attempt to disable the Auditd service to evade detection. Auditd is a Linux service that provides system
+auditing and logging. Disabling the Auditd service can prevent the system from logging important security events, which
+can be used to detect malicious activity.
 """
 from = "now-9m"
-index = ["logs-endpoint.events.process*", "endgame-*", "logs-crowdstrike.fdr*", "logs-sentinel_one_cloud_funnel.*"]
+index = [
+    "logs-endpoint.events.process*",
+    "endgame-*",
+    "logs-crowdstrike.fdr*",
+    "logs-sentinel_one_cloud_funnel.*",
+]
 language = "eql"
 license = "Elastic License v2"
 name = "Attempt to Disable Auditd Service"
+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 Attempt to Disable Auditd Service
+
+Auditd is a critical Linux service responsible for system auditing and logging, capturing security-relevant events. Adversaries may target this service to evade detection by disabling it, thus preventing the logging of their activities. The detection rule identifies suspicious processes attempting to stop or disable Auditd, such as using commands like `service stop` or `systemctl disable`, signaling potential defense evasion tactics.
+
+### Possible investigation steps
+
+- Review the process details to identify the user account associated with the suspicious command execution, focusing on the process fields such as process.name and process.args.
+- Check the system logs for any preceding or subsequent suspicious activities around the time of the alert, particularly looking for other defense evasion tactics or unauthorized access attempts.
+- Investigate the command history of the user identified to determine if there are any other unauthorized or suspicious commands executed.
+- Verify the current status of the Auditd service on the affected host to ensure it is running and properly configured.
+- Correlate the alert with any other security events or alerts from the same host or user to identify potential patterns or broader attack campaigns.
+
+### False positive analysis
+
+- System administrators may intentionally stop or disable the Auditd service during maintenance or troubleshooting. To handle this, create exceptions for known maintenance windows or specific administrator accounts.
+- Automated scripts or configuration management tools might stop or disable Auditd as part of routine system updates or deployments. Identify these scripts and whitelist their activities to prevent false alerts.
+- Some Linux distributions or custom setups might have alternative methods for managing services that could trigger this rule. Review and adjust the detection criteria to align with the specific service management practices of your environment.
+- In environments where Auditd is not used or is replaced by another logging service, the rule might trigger unnecessarily. Consider disabling the rule or adjusting its scope in such cases.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further malicious activity and potential lateral movement by the adversary.
+- Terminate any suspicious processes identified in the alert that are attempting to disable the Auditd service to stop the adversary's actions.
+- Re-enable and restart the Auditd service on the affected system to ensure that auditing and logging are resumed, capturing any further suspicious activities.
+- Conduct a thorough review of the system logs and audit records to identify any unauthorized changes or additional indicators of compromise that may have occurred prior to the alert.
+- Apply any necessary security patches or updates to the affected system to address vulnerabilities that may have been exploited by the adversary.
+- Escalate the incident to the security operations team for further investigation and to determine if additional systems may be affected.
+- Implement enhanced monitoring and alerting for similar activities across the network to detect and respond to future attempts to disable critical security services."""
 risk_score = 21
 rule_id = "6a058ed6-4e9f-49f3-8f8e-f32165ae7ebf"
 setup = """## Setup
@@ -59,6 +95,7 @@ tags = [
 ]
 timestamp_override = "event.ingested"
 type = "eql"
+
 query = '''
 process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start", "ProcessRollup2") and (
   (process.name == "service" and process.args == "stop") or
@@ -68,54 +105,23 @@ process where host.os.type == "linux" and event.type == "start" and event.action
 process.args in ("auditd", "auditd.service") and 
 not process.parent.name == "auditd.prerm"
 '''
-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 Attempt to Disable Auditd Service
-
-Auditd is a critical Linux service responsible for system auditing and logging, capturing security-relevant events. Adversaries may target this service to evade detection by disabling it, thus preventing the logging of their activities. The detection rule identifies suspicious processes attempting to stop or disable Auditd, such as using commands like `service stop` or `systemctl disable`, signaling potential defense evasion tactics.
-
-### Possible investigation steps
-
-- Review the process details to identify the user account associated with the suspicious command execution, focusing on the process fields such as process.name and process.args.
-- Check the system logs for any preceding or subsequent suspicious activities around the time of the alert, particularly looking for other defense evasion tactics or unauthorized access attempts.
-- Investigate the command history of the user identified to determine if there are any other unauthorized or suspicious commands executed.
-- Verify the current status of the Auditd service on the affected host to ensure it is running and properly configured.
-- Correlate the alert with any other security events or alerts from the same host or user to identify potential patterns or broader attack campaigns.
-
-### False positive analysis
-
-- System administrators may intentionally stop or disable the Auditd service during maintenance or troubleshooting. To handle this, create exceptions for known maintenance windows or specific administrator accounts.
-- Automated scripts or configuration management tools might stop or disable Auditd as part of routine system updates or deployments. Identify these scripts and whitelist their activities to prevent false alerts.
-- Some Linux distributions or custom setups might have alternative methods for managing services that could trigger this rule. Review and adjust the detection criteria to align with the specific service management practices of your environment.
-- In environments where Auditd is not used or is replaced by another logging service, the rule might trigger unnecessarily. Consider disabling the rule or adjusting its scope in such cases.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further malicious activity and potential lateral movement by the adversary.
-- Terminate any suspicious processes identified in the alert that are attempting to disable the Auditd service to stop the adversary's actions.
-- Re-enable and restart the Auditd service on the affected system to ensure that auditing and logging are resumed, capturing any further suspicious activities.
-- Conduct a thorough review of the system logs and audit records to identify any unauthorized changes or additional indicators of compromise that may have occurred prior to the alert.
-- Apply any necessary security patches or updates to the affected system to address vulnerabilities that may have been exploited by the adversary.
-- Escalate the incident to the security operations team for further investigation and to determine if additional systems may be affected.
-- Implement enhanced monitoring and alerting for similar activities across the network to detect and respond to future attempts to disable critical security services."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
-
 [[rule.threat.technique]]
 id = "T1562"
 name = "Impair Defenses"
 reference = "https://attack.mitre.org/techniques/T1562/"
-
 [[rule.threat.technique.subtechnique]]
 id = "T1562.001"
 name = "Disable or Modify Tools"
 reference = "https://attack.mitre.org/techniques/T1562/001/"
 
+
+
 [rule.threat.tactic]
 id = "TA0005"
 name = "Defense Evasion"
 reference = "https://attack.mitre.org/tactics/TA0005/"
+

rules/linux/defense_evasion_attempt_to_disable_iptables_or_firewall.toml

@@ -2,9 +2,7 @@
 creation_date = "2023/02/22"
 integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
-min_stack_version = "8.13.0"
-min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/02/04"
+updated_date = "2025/03/20"
 
 [rule]
 author = ["Elastic"]
@@ -17,6 +15,41 @@ index = ["endgame-*", "logs-endpoint.events.process*", "logs-sentinel_one_cloud_
 language = "eql"
 license = "Elastic License v2"
 name = "Attempt to Disable IPTables or Firewall"
+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 Attempt to Disable IPTables or Firewall
+
+Firewalls like IPTables on Linux systems are crucial for controlling network traffic and protecting against unauthorized access. Adversaries may attempt to disable these firewalls to bypass security measures and facilitate malicious activities. The detection rule identifies suspicious processes that attempt to disable or stop firewall services, such as using commands to flush IPTables rules or halt firewall services, indicating potential defense evasion tactics.
+
+### Possible investigation steps
+
+- Review the process details, including process.name and process.args, to confirm if the command was intended to disable or stop firewall services.
+- Check the process.parent.args to understand the context in which the suspicious process was executed, especially if it was triggered by a parent process with arguments like "force-stop".
+- Investigate the user account associated with the process execution to determine if it was an authorized user or potentially compromised.
+- Examine the host's recent activity logs for any other suspicious behavior or anomalies around the time of the alert, focusing on event.type "start" and event.action "exec" or "exec_event".
+- Assess the network traffic logs to identify any unusual inbound or outbound connections that might have occurred after the firewall was disabled or stopped.
+- Correlate this event with other alerts or incidents involving the same host or user to identify potential patterns or coordinated attack attempts.
+
+### False positive analysis
+
+- Routine system maintenance or updates may trigger the rule when legitimate processes like systemctl or service are used to stop or restart firewall services. To manage this, create exceptions for known maintenance scripts or scheduled tasks that perform these actions.
+- Network troubleshooting activities often involve temporarily disabling firewalls to diagnose connectivity issues. Users can exclude specific user accounts or IP addresses associated with network administrators from triggering the rule during these activities.
+- Automated deployment scripts that configure or reconfigure firewall settings might match the rule's criteria. Identify and whitelist these scripts by their process names or execution paths to prevent false positives.
+- Security software updates or installations may require temporary firewall adjustments, which could be flagged by the rule. Consider excluding processes associated with trusted security software vendors during update windows.
+- Development or testing environments often have different security requirements, leading to frequent firewall changes. Implement environment-specific exceptions to avoid false positives in these contexts.
+
+### Response and remediation
+
+- Immediately isolate the affected host from the network to prevent further unauthorized access or potential lateral movement by the adversary.
+- Terminate any suspicious processes identified in the alert, such as those attempting to disable or stop firewall services, to halt ongoing malicious activities.
+- Review and restore the firewall configurations to their last known good state to ensure that network traffic is properly controlled and unauthorized access is blocked.
+- Conduct a thorough examination of the affected system for any signs of compromise or additional malicious activity, focusing on logs and system changes around the time of the alert.
+- Escalate the incident to the security operations team for further analysis and to determine if the threat is part of a larger attack campaign.
+- Implement additional monitoring and alerting for similar activities across the network to detect and respond to future attempts to disable firewall services promptly.
+- Review and update firewall policies and configurations to enhance security measures and prevent similar defense evasion tactics in the future."""
 references = ["https://www.elastic.co/security-labs/detecting-log4j2-with-elastic-security"]
 risk_score = 21
 rule_id = "83e9c2b3-24ef-4c1d-a8cd-5ebafb5dfa2f"
@@ -78,41 +111,6 @@ process where host.os.type == "linux" and event.type == "start" and event.action
     )
   )
 '''
-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 Attempt to Disable IPTables or Firewall
-
-Firewalls like IPTables on Linux systems are crucial for controlling network traffic and protecting against unauthorized access. Adversaries may attempt to disable these firewalls to bypass security measures and facilitate malicious activities. The detection rule identifies suspicious processes that attempt to disable or stop firewall services, such as using commands to flush IPTables rules or halt firewall services, indicating potential defense evasion tactics.
-
-### Possible investigation steps
-
-- Review the process details, including process.name and process.args, to confirm if the command was intended to disable or stop firewall services.
-- Check the process.parent.args to understand the context in which the suspicious process was executed, especially if it was triggered by a parent process with arguments like "force-stop".
-- Investigate the user account associated with the process execution to determine if it was an authorized user or potentially compromised.
-- Examine the host's recent activity logs for any other suspicious behavior or anomalies around the time of the alert, focusing on event.type "start" and event.action "exec" or "exec_event".
-- Assess the network traffic logs to identify any unusual inbound or outbound connections that might have occurred after the firewall was disabled or stopped.
-- Correlate this event with other alerts or incidents involving the same host or user to identify potential patterns or coordinated attack attempts.
-
-### False positive analysis
-
-- Routine system maintenance or updates may trigger the rule when legitimate processes like systemctl or service are used to stop or restart firewall services. To manage this, create exceptions for known maintenance scripts or scheduled tasks that perform these actions.
-- Network troubleshooting activities often involve temporarily disabling firewalls to diagnose connectivity issues. Users can exclude specific user accounts or IP addresses associated with network administrators from triggering the rule during these activities.
-- Automated deployment scripts that configure or reconfigure firewall settings might match the rule's criteria. Identify and whitelist these scripts by their process names or execution paths to prevent false positives.
-- Security software updates or installations may require temporary firewall adjustments, which could be flagged by the rule. Consider excluding processes associated with trusted security software vendors during update windows.
-- Development or testing environments often have different security requirements, leading to frequent firewall changes. Implement environment-specific exceptions to avoid false positives in these contexts.
-
-### Response and remediation
-
-- Immediately isolate the affected host from the network to prevent further unauthorized access or potential lateral movement by the adversary.
-- Terminate any suspicious processes identified in the alert, such as those attempting to disable or stop firewall services, to halt ongoing malicious activities.
-- Review and restore the firewall configurations to their last known good state to ensure that network traffic is properly controlled and unauthorized access is blocked.
-- Conduct a thorough examination of the affected system for any signs of compromise or additional malicious activity, focusing on logs and system changes around the time of the alert.
-- Escalate the incident to the security operations team for further analysis and to determine if the threat is part of a larger attack campaign.
-- Implement additional monitoring and alerting for similar activities across the network to detect and respond to future attempts to disable firewall services promptly.
-- Review and update firewall policies and configurations to enhance security measures and prevent similar defense evasion tactics in the future."""
 
 
 [[rule.threat]]

rules/linux/defense_evasion_attempt_to_disable_syslog_service.toml

@@ -2,9 +2,7 @@
 creation_date = "2020/04/27"
 integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
-min_stack_version = "8.13.0"
-min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/02/04"
+updated_date = "2025/03/20"
 
 [rule]
 author = ["Elastic"]
@@ -13,10 +11,50 @@ Adversaries may attempt to disable the syslog service in an attempt to an attemp
 detection by security controls.
 """
 from = "now-9m"
-index = ["auditbeat-*", "endgame-*", "logs-crowdstrike.fdr*", "logs-endpoint.events.process*", "logs-sentinel_one_cloud_funnel.*"]
+index = [
+    "auditbeat-*",
+    "endgame-*",
+    "logs-crowdstrike.fdr*",
+    "logs-endpoint.events.process*",
+    "logs-sentinel_one_cloud_funnel.*",
+]
 language = "eql"
 license = "Elastic License v2"
 name = "Attempt to Disable Syslog Service"
+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 Attempt to Disable Syslog Service
+
+Syslog is a critical component in Linux environments, responsible for logging system events and activities. Adversaries may target syslog to disable logging, thereby evading detection and obscuring their malicious actions. The detection rule identifies attempts to stop or disable syslog services by monitoring specific process actions and arguments, flagging suspicious commands that could indicate an attempt to impair logging defenses.
+
+### Possible investigation steps
+
+- Review the process details to identify the user account associated with the command execution, focusing on the process.name and process.args fields to determine if the action was legitimate or suspicious.
+- Check the system's recent login history and user activity to identify any unauthorized access attempts or anomalies around the time the syslog service was targeted.
+- Investigate the parent process of the flagged command to understand the context of its execution and determine if it was initiated by a legitimate application or script.
+- Examine other logs and alerts from the same host around the time of the event to identify any correlated suspicious activities or patterns that might indicate a broader attack.
+- Assess the system for any signs of compromise, such as unexpected changes in configuration files, unauthorized software installations, or unusual network connections, to determine if the attempt to disable syslog is part of a larger attack.
+
+### False positive analysis
+
+- Routine maintenance activities may trigger this rule, such as scheduled service restarts or system updates. To manage this, create exceptions for known maintenance windows or specific administrative accounts performing these tasks.
+- Automated scripts or configuration management tools like Ansible or Puppet might stop or disable syslog services as part of their operations. Identify these scripts and whitelist their execution paths or associated user accounts.
+- Testing environments often simulate service disruptions, including syslog, for resilience testing. Exclude these environments from the rule or adjust the rule to ignore specific test-related processes.
+- Some legitimate software installations or updates may require stopping syslog services temporarily. Monitor installation logs and exclude these processes if they are verified as non-threatening.
+- In environments with multiple syslog implementations, ensure that the rule is not overly broad by refining the process arguments to match only the specific syslog services in use.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further malicious activity and potential lateral movement by the adversary.
+- Terminate any suspicious processes identified in the alert, specifically those attempting to stop or disable syslog services, to restore normal logging functionality.
+- Restart the syslog service on the affected system to ensure that logging is re-enabled and operational, using commands like `systemctl start syslog` or `service syslog start`.
+- Conduct a thorough review of recent logs, if available, to identify any additional suspicious activities or indicators of compromise that may have occurred prior to the syslog service being disabled.
+- Escalate the incident to the security operations team for further investigation and to determine if the attack is part of a larger campaign or if other systems are affected.
+- Implement additional monitoring on the affected system and similar systems to detect any further attempts to disable logging services, using enhanced logging and alerting mechanisms.
+- Review and update access controls and permissions to ensure that only authorized personnel have the ability to modify or stop critical services like syslog, reducing the risk of future incidents."""
 references = ["https://www.elastic.co/security-labs/detecting-log4j2-with-elastic-security"]
 risk_score = 47
 rule_id = "2f8a1226-5720-437d-9c20-e0029deb6194"
@@ -80,40 +118,6 @@ process where host.os.type == "linux" and event.action in ("exec", "exec_event",
  ) and process.args in ("syslog", "rsyslog", "syslog-ng", "syslog.service", "rsyslog.service", "syslog-ng.service") and
 not process.parent.name == "rsyslog-rotate"
 '''
-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 Attempt to Disable Syslog Service
-
-Syslog is a critical component in Linux environments, responsible for logging system events and activities. Adversaries may target syslog to disable logging, thereby evading detection and obscuring their malicious actions. The detection rule identifies attempts to stop or disable syslog services by monitoring specific process actions and arguments, flagging suspicious commands that could indicate an attempt to impair logging defenses.
-
-### Possible investigation steps
-
-- Review the process details to identify the user account associated with the command execution, focusing on the process.name and process.args fields to determine if the action was legitimate or suspicious.
-- Check the system's recent login history and user activity to identify any unauthorized access attempts or anomalies around the time the syslog service was targeted.
-- Investigate the parent process of the flagged command to understand the context of its execution and determine if it was initiated by a legitimate application or script.
-- Examine other logs and alerts from the same host around the time of the event to identify any correlated suspicious activities or patterns that might indicate a broader attack.
-- Assess the system for any signs of compromise, such as unexpected changes in configuration files, unauthorized software installations, or unusual network connections, to determine if the attempt to disable syslog is part of a larger attack.
-
-### False positive analysis
-
-- Routine maintenance activities may trigger this rule, such as scheduled service restarts or system updates. To manage this, create exceptions for known maintenance windows or specific administrative accounts performing these tasks.
-- Automated scripts or configuration management tools like Ansible or Puppet might stop or disable syslog services as part of their operations. Identify these scripts and whitelist their execution paths or associated user accounts.
-- Testing environments often simulate service disruptions, including syslog, for resilience testing. Exclude these environments from the rule or adjust the rule to ignore specific test-related processes.
-- Some legitimate software installations or updates may require stopping syslog services temporarily. Monitor installation logs and exclude these processes if they are verified as non-threatening.
-- In environments with multiple syslog implementations, ensure that the rule is not overly broad by refining the process arguments to match only the specific syslog services in use.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further malicious activity and potential lateral movement by the adversary.
-- Terminate any suspicious processes identified in the alert, specifically those attempting to stop or disable syslog services, to restore normal logging functionality.
-- Restart the syslog service on the affected system to ensure that logging is re-enabled and operational, using commands like `systemctl start syslog` or `service syslog start`.
-- Conduct a thorough review of recent logs, if available, to identify any additional suspicious activities or indicators of compromise that may have occurred prior to the syslog service being disabled.
-- Escalate the incident to the security operations team for further investigation and to determine if the attack is part of a larger campaign or if other systems are affected.
-- Implement additional monitoring on the affected system and similar systems to detect any further attempts to disable logging services, using enhanced logging and alerting mechanisms.
-- Review and update access controls and permissions to ensure that only authorized personnel have the ability to modify or stop critical services like syslog, reducing the risk of future incidents."""
 
 
 [[rule.threat]]

rules/linux/defense_evasion_base16_or_base32_encoding_or_decoding_activity.toml

@@ -2,9 +2,7 @@
 creation_date = "2020/04/17"
 integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
-min_stack_version = "8.13.0"
-min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/02/04"
+updated_date = "2025/03/20"
 
 [rule]
 author = ["Elastic"]
@@ -16,10 +14,52 @@ false_positives = [
     """,
 ]
 from = "now-9m"
-index = ["auditbeat-*", "endgame-*", "logs-auditd_manager.auditd-*", "logs-crowdstrike.fdr*", "logs-endpoint.events.process*", "logs-sentinel_one_cloud_funnel.*"]
+index = [
+    "auditbeat-*",
+    "endgame-*",
+    "logs-auditd_manager.auditd-*",
+    "logs-crowdstrike.fdr*",
+    "logs-endpoint.events.process*",
+    "logs-sentinel_one_cloud_funnel.*",
+]
 language = "eql"
 license = "Elastic License v2"
 name = "Base16 or Base32 Encoding/Decoding Activity"
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
+
+### Investigating Base16 or Base32 Encoding/Decoding Activity
+
+Base16 and Base32 are encoding schemes used to convert binary data into text, facilitating data transmission and storage. Adversaries exploit these encodings to obfuscate malicious payloads, evading detection by security systems. The detection rule identifies suspicious encoding/decoding activities on Linux systems by monitoring specific processes and actions, excluding benign uses like help or version checks.
+
+### Possible investigation steps
+
+- Review the process name and arguments to confirm if the activity is related to encoding/decoding using base16 or base32, ensuring it is not a benign use case like help or version checks.
+- Examine the user account associated with the process to determine if the activity aligns with their typical behavior or if it appears suspicious.
+- Check the parent process of the encoding/decoding activity to identify if it was initiated by a legitimate application or a potentially malicious script or program.
+- Investigate the timing and frequency of the encoding/decoding events to assess if they coincide with other suspicious activities or known attack patterns.
+- Correlate the event with network activity logs to see if there is any data exfiltration attempt or communication with known malicious IP addresses or domains.
+- Look into any recent changes or anomalies in the system that might indicate a compromise, such as unauthorized file modifications or new user accounts.
+
+### False positive analysis
+
+- Routine administrative tasks may trigger the rule if administrators use base16 or base32 commands for legitimate data encoding or decoding. To manage this, create exceptions for specific user accounts or scripts known to perform these tasks regularly.
+- Automated backup or data transfer processes might use base16 or base32 encoding as part of their operations. Identify these processes and exclude them by specifying their unique process arguments or execution paths.
+- Development and testing environments often involve encoding and decoding operations for debugging or data manipulation. Exclude these environments by filtering based on hostnames or IP addresses associated with non-production systems.
+- Security tools or scripts that perform regular encoding checks for data integrity or compliance purposes can also trigger false positives. Whitelist these tools by their process names or execution contexts to prevent unnecessary alerts.
+- Educational or research activities involving encoding techniques may inadvertently match the rule criteria. Consider excluding known educational user groups or specific research project identifiers to reduce false positives.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent potential lateral movement or data exfiltration by the adversary.
+- Terminate any suspicious processes identified by the detection rule, specifically those involving base16 or base32 encoding/decoding without benign arguments.
+- Conduct a thorough review of recent system logs and process execution history to identify any additional suspicious activities or related processes.
+- Remove any malicious files or payloads that have been identified as part of the encoding/decoding activity.
+- Restore any affected files or systems from known good backups to ensure system integrity and data accuracy.
+- Update and patch the affected system to close any vulnerabilities that may have been exploited by the adversary.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected."""
 risk_score = 21
 rule_id = "debff20a-46bc-4a4d-bae5-5cdd14222795"
 setup = """## Setup
@@ -81,41 +121,6 @@ process where host.os.type == "linux" and event.type == "start" and
  process.name in ("base16", "base32", "base32plain", "base32hex") and
 not process.args in ("--help", "--version")
 '''
-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 Base16 or Base32 Encoding/Decoding Activity
-
-Base16 and Base32 are encoding schemes used to convert binary data into text, facilitating data transmission and storage. Adversaries exploit these encodings to obfuscate malicious payloads, evading detection by security systems. The detection rule identifies suspicious encoding/decoding activities on Linux systems by monitoring specific processes and actions, excluding benign uses like help or version checks.
-
-### Possible investigation steps
-
-- Review the process name and arguments to confirm if the activity is related to encoding/decoding using base16 or base32, ensuring it is not a benign use case like help or version checks.
-- Examine the user account associated with the process to determine if the activity aligns with their typical behavior or if it appears suspicious.
-- Check the parent process of the encoding/decoding activity to identify if it was initiated by a legitimate application or a potentially malicious script or program.
-- Investigate the timing and frequency of the encoding/decoding events to assess if they coincide with other suspicious activities or known attack patterns.
-- Correlate the event with network activity logs to see if there is any data exfiltration attempt or communication with known malicious IP addresses or domains.
-- Look into any recent changes or anomalies in the system that might indicate a compromise, such as unauthorized file modifications or new user accounts.
-
-### False positive analysis
-
-- Routine administrative tasks may trigger the rule if administrators use base16 or base32 commands for legitimate data encoding or decoding. To manage this, create exceptions for specific user accounts or scripts known to perform these tasks regularly.
-- Automated backup or data transfer processes might use base16 or base32 encoding as part of their operations. Identify these processes and exclude them by specifying their unique process arguments or execution paths.
-- Development and testing environments often involve encoding and decoding operations for debugging or data manipulation. Exclude these environments by filtering based on hostnames or IP addresses associated with non-production systems.
-- Security tools or scripts that perform regular encoding checks for data integrity or compliance purposes can also trigger false positives. Whitelist these tools by their process names or execution contexts to prevent unnecessary alerts.
-- Educational or research activities involving encoding techniques may inadvertently match the rule criteria. Consider excluding known educational user groups or specific research project identifiers to reduce false positives.
-
-### Response and remediation
-
-- Isolate the affected system from the network to prevent potential lateral movement or data exfiltration by the adversary.
-- Terminate any suspicious processes identified by the detection rule, specifically those involving base16 or base32 encoding/decoding without benign arguments.
-- Conduct a thorough review of recent system logs and process execution history to identify any additional suspicious activities or related processes.
-- Remove any malicious files or payloads that have been identified as part of the encoding/decoding activity.
-- Restore any affected files or systems from known good backups to ensure system integrity and data accuracy.
-- Update and patch the affected system to close any vulnerabilities that may have been exploited by the adversary.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected."""
 
 
 [[rule.threat]]

rules/linux/defense_evasion_base64_decoding_activity.toml

@@ -2,17 +2,15 @@
 creation_date = "2025/02/21"
 integration = ["endpoint"]
 maturity = "production"
-min_stack_comments = "ES|QL rule type in technical preview as of 8.13"
-min_stack_version = "8.13.0"
-updated_date = "2025/02/21"
+updated_date = "2025/03/20"
 
 [rule]
 author = ["Elastic"]
 description = """
-This rule leverages ES|QL to detect unusual base64 encoding/decoding activity on Linux systems. Attackers may
-use base64 encoding/decoding to obfuscate data, such as command and control traffic or payloads, to evade
-detection by host- or network-based security controls. ES|QL rules have limited fields available in its alert
-documents. Make sure to review the original documents to aid in the investigation of this alert.
+This rule leverages ES|QL to detect unusual base64 encoding/decoding activity on Linux systems. Attackers may use base64
+encoding/decoding to obfuscate data, such as command and control traffic or payloads, to evade detection by host- or
+network-based security controls. ES|QL rules have limited fields available in its alert documents. Make sure to review
+the original documents to aid in the investigation of this alert.
 """
 from = "now-61m"
 interval = "1h"
@@ -57,6 +55,7 @@ tags = [
 ]
 timestamp_override = "event.ingested"
 type = "esql"
+
 query = '''
 from logs-endpoint.events.process-*
 | keep @timestamp, host.os.type, event.type, event.action, process.name, process.args, process.command_line, agent.id
@@ -77,48 +76,49 @@ from logs-endpoint.events.process-*
 | limit 100
 '''
 
-[[rule.threat]]
-framework = "MITRE ATT&CK"
-
-  [rule.threat.tactic]
-  name = "Defense Evasion"
-  id = "TA0005"
-  reference = "https://attack.mitre.org/tactics/TA0005/"
-
-    [[rule.threat.technique]]
-    name = "Obfuscated Files or Information"
-    id = "T1027"
-    reference = "https://attack.mitre.org/techniques/T1027/"
-
-    [[rule.threat.technique]]
-    name = "Deobfuscate/Decode Files or Information"
-    id = "T1140"
-    reference = "https://attack.mitre.org/techniques/T1140/"
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1027"
+name = "Obfuscated Files or Information"
+reference = "https://attack.mitre.org/techniques/T1027/"
 
-  [rule.threat.tactic]
-  name = "Execution"
-  id = "TA0002"
-  reference = "https://attack.mitre.org/tactics/TA0002/"
+[[rule.threat.technique]]
+id = "T1140"
+name = "Deobfuscate/Decode Files or Information"
+reference = "https://attack.mitre.org/techniques/T1140/"
 
-    [[rule.threat.technique]]
-    id = "T1059"
-    name = "Command and Scripting Interpreter"
-    reference = "https://attack.mitre.org/techniques/T1059/"
 
-      [[rule.threat.technique.subtechnique]]
-      name = "Unix Shell"
-      id = "T1059.004"
-      reference = "https://attack.mitre.org/techniques/T1059/004/"
+[rule.threat.tactic]
+id = "TA0005"
+name = "Defense Evasion"
+reference = "https://attack.mitre.org/tactics/TA0005/"
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1059"
+name = "Command and Scripting Interpreter"
+reference = "https://attack.mitre.org/techniques/T1059/"
+[[rule.threat.technique.subtechnique]]
+id = "T1059.004"
+name = "Unix Shell"
+reference = "https://attack.mitre.org/techniques/T1059/004/"
 
-    [[rule.threat.technique]]
-    name = "User Execution"
-    id = "T1204"
-    reference = "https://attack.mitre.org/techniques/T1204/"
 
-      [[rule.threat.technique.subtechnique]]
-      name = "Malicious File"
-      id = "T1204.002"
-      reference = "https://attack.mitre.org/techniques/T1204/002/"
+[[rule.threat.technique]]
+id = "T1204"
+name = "User Execution"
+reference = "https://attack.mitre.org/techniques/T1204/"
+[[rule.threat.technique.subtechnique]]
+id = "T1204.002"
+name = "Malicious File"
+reference = "https://attack.mitre.org/techniques/T1204/002/"
+
+
+
+[rule.threat.tactic]
+id = "TA0002"
+name = "Execution"
+reference = "https://attack.mitre.org/tactics/TA0002/"
+

rules/linux/defense_evasion_chattr_immutable_file.toml

@@ -2,9 +2,7 @@
 creation_date = "2022/07/22"
 integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
-min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-min_stack_version = "8.13.0"
-updated_date = "2025/02/04"
+updated_date = "2025/03/20"
 
 [rule]
 author = ["Elastic"]
@@ -20,6 +18,40 @@ language = "eql"
 license = "Elastic License v2"
 max_signals = 33
 name = "File made Immutable by Chattr"
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
+
+### Investigating File made Immutable by Chattr
+
+The `chattr` command in Linux is used to change file attributes, including making files immutable, which prevents modifications or deletions. Adversaries exploit this to secure malicious files or altered system files against tampering, aiding persistence. The detection rule identifies suspicious use of `chattr` by monitoring process executions, filtering out benign parent processes, and focusing on those altering immutability attributes, thus highlighting potential misuse.
+
+### Possible investigation steps
+
+- Review the process execution details to confirm the use of the chattr command with arguments altering immutability, specifically looking for "+i" or "-i" in process.args.
+- Identify the file(s) targeted by the chattr command to determine if they are critical system files or files commonly targeted by threat actors, such as .ssh or /etc/passwd.
+- Investigate the parent process of the chattr execution by examining process.parent.executable and process.parent.name to determine if it is a known benign process or potentially malicious.
+- Check the user context under which the chattr command was executed to assess if it aligns with expected administrative activity or if it indicates unauthorized access.
+- Correlate the event with other security alerts or logs to identify any related suspicious activities, such as unauthorized access attempts or changes to other system files.
+- Evaluate the risk and impact of the immutable file(s) on system operations and security posture, considering the potential for persistence or defense evasion by threat actors.
+
+### False positive analysis
+
+- System processes like systemd and cf-agent may invoke chattr for legitimate reasons, such as system maintenance or configuration management. To handle these, exclude these processes by adding them to the exception list in the detection rule.
+- Scheduled tasks or scripts that use chattr to manage file attributes for security or operational purposes can trigger false positives. Identify these tasks and exclude their parent processes from the rule.
+- Administrative actions performed by authorized users, such as securing configuration files, might be flagged. Regularly review and update the list of known benign parent processes to prevent unnecessary alerts.
+- Security tools or agents that modify file attributes as part of their protection mechanisms can cause false positives. Ensure these tools are recognized and excluded by their executable paths or parent process names.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further spread or communication with potential command and control servers.
+- Identify and terminate any malicious processes associated with the `chattr` command to stop further unauthorized file modifications.
+- Restore the affected files from a known good backup, ensuring that any immutable attributes set by the attacker are removed.
+- Conduct a thorough review of user accounts and permissions on the affected system to ensure no unauthorized access or privilege escalation has occurred.
+- Implement file integrity monitoring to detect unauthorized changes to critical system files, enhancing detection capabilities for similar threats.
+- Escalate the incident to the security operations team for further investigation and to determine if additional systems are compromised.
+- Review and update security policies and configurations to prevent unauthorized use of the `chattr` command, such as restricting its execution to trusted administrators only."""
 risk_score = 47
 rule_id = "968ccab9-da51-4a87-9ce2-d3c9782fd759"
 setup = """## Setup
@@ -75,6 +107,7 @@ tags = [
 ]
 timestamp_override = "event.ingested"
 type = "eql"
+
 query = '''
 process where host.os.type == "linux" and event.type == "start" and process.parent.executable != null and
 process.executable : "/usr/bin/chattr" and process.args : ("-*i*", "+*i*") and not (
@@ -85,55 +118,23 @@ process.executable : "/usr/bin/chattr" and process.args : ("-*i*", "+*i*") and n
   )
 )
 '''
-note = """## Triage and analysis
 
-> **Disclaimer**:
-> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
-
-### Investigating File made Immutable by Chattr
-
-The `chattr` command in Linux is used to change file attributes, including making files immutable, which prevents modifications or deletions. Adversaries exploit this to secure malicious files or altered system files against tampering, aiding persistence. The detection rule identifies suspicious use of `chattr` by monitoring process executions, filtering out benign parent processes, and focusing on those altering immutability attributes, thus highlighting potential misuse.
-
-### Possible investigation steps
-
-- Review the process execution details to confirm the use of the chattr command with arguments altering immutability, specifically looking for "+i" or "-i" in process.args.
-- Identify the file(s) targeted by the chattr command to determine if they are critical system files or files commonly targeted by threat actors, such as .ssh or /etc/passwd.
-- Investigate the parent process of the chattr execution by examining process.parent.executable and process.parent.name to determine if it is a known benign process or potentially malicious.
-- Check the user context under which the chattr command was executed to assess if it aligns with expected administrative activity or if it indicates unauthorized access.
-- Correlate the event with other security alerts or logs to identify any related suspicious activities, such as unauthorized access attempts or changes to other system files.
-- Evaluate the risk and impact of the immutable file(s) on system operations and security posture, considering the potential for persistence or defense evasion by threat actors.
-
-### False positive analysis
-
-- System processes like systemd and cf-agent may invoke chattr for legitimate reasons, such as system maintenance or configuration management. To handle these, exclude these processes by adding them to the exception list in the detection rule.
-- Scheduled tasks or scripts that use chattr to manage file attributes for security or operational purposes can trigger false positives. Identify these tasks and exclude their parent processes from the rule.
-- Administrative actions performed by authorized users, such as securing configuration files, might be flagged. Regularly review and update the list of known benign parent processes to prevent unnecessary alerts.
-- Security tools or agents that modify file attributes as part of their protection mechanisms can cause false positives. Ensure these tools are recognized and excluded by their executable paths or parent process names.
-
-### Response and remediation
-
-- Isolate the affected system from the network to prevent further spread or communication with potential command and control servers.
-- Identify and terminate any malicious processes associated with the `chattr` command to stop further unauthorized file modifications.
-- Restore the affected files from a known good backup, ensuring that any immutable attributes set by the attacker are removed.
-- Conduct a thorough review of user accounts and permissions on the affected system to ensure no unauthorized access or privilege escalation has occurred.
-- Implement file integrity monitoring to detect unauthorized changes to critical system files, enhancing detection capabilities for similar threats.
-- Escalate the incident to the security operations team for further investigation and to determine if additional systems are compromised.
-- Review and update security policies and configurations to prevent unauthorized use of the `chattr` command, such as restricting its execution to trusted administrators only."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
-
 [[rule.threat.technique]]
 id = "T1222"
 name = "File and Directory Permissions Modification"
 reference = "https://attack.mitre.org/techniques/T1222/"
-
 [[rule.threat.technique.subtechnique]]
 id = "T1222.002"
 name = "Linux and Mac File and Directory Permissions Modification"
 reference = "https://attack.mitre.org/techniques/T1222/002/"
 
+
+
 [rule.threat.tactic]
 id = "TA0005"
 name = "Defense Evasion"
 reference = "https://attack.mitre.org/tactics/TA0005/"
+

rules/linux/defense_evasion_clear_kernel_ring_buffer.toml

@@ -2,9 +2,7 @@
 creation_date = "2023/10/24"
 integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
-min_stack_version = "8.13.0"
-min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/02/04"
+updated_date = "2025/03/20"
 
 [rule]
 author = ["Elastic"]
@@ -13,10 +11,50 @@ Monitors for the deletion of the kernel ring buffer events through dmesg. Attack
 to evade detection after installing a Linux kernel module (LKM).
 """
 from = "now-9m"
-index = ["auditbeat-*", "endgame-*", "logs-auditd_manager.auditd-*", "logs-crowdstrike.fdr*", "logs-endpoint.events.process*", "logs-sentinel_one_cloud_funnel.*"]
+index = [
+    "auditbeat-*",
+    "endgame-*",
+    "logs-auditd_manager.auditd-*",
+    "logs-crowdstrike.fdr*",
+    "logs-endpoint.events.process*",
+    "logs-sentinel_one_cloud_funnel.*",
+]
 language = "eql"
 license = "Elastic License v2"
 name = "Attempt to Clear Kernel Ring Buffer"
+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 Attempt to Clear Kernel Ring Buffer
+
+The kernel ring buffer logs system messages, crucial for diagnosing issues. Adversaries may clear these logs using the `dmesg -c` command to hide traces of malicious activities, such as installing unauthorized kernel modules. The detection rule identifies this behavior by monitoring the execution of `dmesg` with specific arguments, flagging potential evasion attempts for further investigation.
+
+### Possible investigation steps
+
+- Review the process execution details to confirm the presence of the `dmesg -c` command, focusing on the process name and arguments to ensure the alert is valid.
+- Investigate the user account associated with the execution of the `dmesg -c` command to determine if it is a known and authorized user or potentially compromised.
+- Check for any recent installations or modifications of Linux kernel modules (LKMs) on the host to identify unauthorized changes that may coincide with the log clearing attempt.
+- Examine other system logs and security alerts around the same timeframe to identify any suspicious activities or patterns that may indicate a broader attack or compromise.
+- Assess the host's network activity for any unusual outbound connections or data exfiltration attempts that could suggest further malicious intent.
+
+### False positive analysis
+
+- Routine system maintenance activities may trigger the rule if administrators use the dmesg -c command to clear logs for legitimate purposes. To handle this, create exceptions for known maintenance scripts or processes that regularly execute this command.
+- Automated scripts or monitoring tools that include dmesg -c as part of their log management routine can cause false positives. Identify these scripts and exclude them from the rule by specifying their process IDs or user accounts.
+- Development and testing environments where kernel modules are frequently installed and removed might generate alerts. Consider excluding these environments from the rule or adjusting the risk score to reflect the lower threat level in these contexts.
+- System administrators may use dmesg -c during troubleshooting to clear logs and view new messages. Document these activities and create exceptions for specific user accounts or roles that perform this task regularly.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further malicious activity or lateral movement.
+- Conduct a thorough review of the system to identify any unauthorized kernel modules or other suspicious changes, and remove them if found.
+- Restore the system from a known good backup if unauthorized changes are detected and cannot be easily reversed.
+- Review and update access controls and permissions to ensure that only authorized users have the ability to execute commands like `dmesg -c`.
+- Implement enhanced monitoring and logging for the affected system to detect any future attempts to clear the kernel ring buffer or similar evasion tactics.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.
+- Conduct a post-incident review to identify gaps in detection and response, and update security policies and procedures to prevent recurrence."""
 risk_score = 21
 rule_id = "2724808c-ba5d-48b2-86d2-0002103df753"
 setup = """## Setup
@@ -64,64 +102,33 @@ query = '''
 process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started")
  and process.name == "dmesg" and process.args in ("-c", "--clear")
 '''
-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 Attempt to Clear Kernel Ring Buffer
-
-The kernel ring buffer logs system messages, crucial for diagnosing issues. Adversaries may clear these logs using the `dmesg -c` command to hide traces of malicious activities, such as installing unauthorized kernel modules. The detection rule identifies this behavior by monitoring the execution of `dmesg` with specific arguments, flagging potential evasion attempts for further investigation.
-
-### Possible investigation steps
-
-- Review the process execution details to confirm the presence of the `dmesg -c` command, focusing on the process name and arguments to ensure the alert is valid.
-- Investigate the user account associated with the execution of the `dmesg -c` command to determine if it is a known and authorized user or potentially compromised.
-- Check for any recent installations or modifications of Linux kernel modules (LKMs) on the host to identify unauthorized changes that may coincide with the log clearing attempt.
-- Examine other system logs and security alerts around the same timeframe to identify any suspicious activities or patterns that may indicate a broader attack or compromise.
-- Assess the host's network activity for any unusual outbound connections or data exfiltration attempts that could suggest further malicious intent.
-
-### False positive analysis
-
-- Routine system maintenance activities may trigger the rule if administrators use the dmesg -c command to clear logs for legitimate purposes. To handle this, create exceptions for known maintenance scripts or processes that regularly execute this command.
-- Automated scripts or monitoring tools that include dmesg -c as part of their log management routine can cause false positives. Identify these scripts and exclude them from the rule by specifying their process IDs or user accounts.
-- Development and testing environments where kernel modules are frequently installed and removed might generate alerts. Consider excluding these environments from the rule or adjusting the risk score to reflect the lower threat level in these contexts.
-- System administrators may use dmesg -c during troubleshooting to clear logs and view new messages. Document these activities and create exceptions for specific user accounts or roles that perform this task regularly.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further malicious activity or lateral movement.
-- Conduct a thorough review of the system to identify any unauthorized kernel modules or other suspicious changes, and remove them if found.
-- Restore the system from a known good backup if unauthorized changes are detected and cannot be easily reversed.
-- Review and update access controls and permissions to ensure that only authorized users have the ability to execute commands like `dmesg -c`.
-- Implement enhanced monitoring and logging for the affected system to detect any future attempts to clear the kernel ring buffer or similar evasion tactics.
-- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.
-- Conduct a post-incident review to identify gaps in detection and response, and update security policies and procedures to prevent recurrence."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
-
 [[rule.threat.technique]]
 id = "T1070"
 name = "Indicator Removal"
 reference = "https://attack.mitre.org/techniques/T1070/"
-
 [[rule.threat.technique.subtechnique]]
 id = "T1070.002"
 name = "Clear Linux or Mac System Logs"
 reference = "https://attack.mitre.org/techniques/T1070/002/"
 
+
 [[rule.threat.technique]]
 id = "T1562"
 name = "Impair Defenses"
 reference = "https://attack.mitre.org/techniques/T1562/"
-
 [[rule.threat.technique.subtechnique]]
 id = "T1562.001"
 name = "Disable or Modify Tools"
 reference = "https://attack.mitre.org/techniques/T1562/001/"
 
+
+
 [rule.threat.tactic]
 id = "TA0005"
 name = "Defense Evasion"
 reference = "https://attack.mitre.org/tactics/TA0005/"
+

rules/linux/defense_evasion_creation_of_hidden_files_directories.toml

@@ -2,9 +2,7 @@
 creation_date = "2023/08/23"
 integration = ["endpoint", "auditd_manager", "sentinel_one_cloud_funnel"]
 maturity = "production"
-min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-min_stack_version = "8.13.0"
-updated_date = "2025/02/04"
+updated_date = "2025/03/20"
 
 [rule]
 author = ["Elastic"]
@@ -13,30 +11,16 @@ Identify activity related where adversaries can add the 'hidden' flag to files t
 to evade detection.
 """
 from = "now-9m"
-index = ["auditbeat-*", "endgame-*", "logs-auditd_manager.auditd-*", "logs-endpoint.events.file*", "logs-sentinel_one_cloud_funnel.*"]
+index = [
+    "auditbeat-*",
+    "endgame-*",
+    "logs-auditd_manager.auditd-*",
+    "logs-endpoint.events.file*",
+    "logs-sentinel_one_cloud_funnel.*",
+]
 language = "eql"
 license = "Elastic License v2"
 name = "Hidden Files and Directories via Hidden Flag"
-risk_score = 21
-rule_id = "5124e65f-df97-4471-8dcb-8e3953b3ea97"
-severity = "low"
-tags = [
-    "Domain: Endpoint",
-    "OS: Linux",
-    "OS: macOS",
-    "Use Case: Threat Detection",
-    "Tactic: Defense Evasion",
-    "Data Source: Elastic Defend",
-    "Data Source: Elastic Endgame",
-    "Data Source: Auditd Manager",
-    "Data Source: SentinelOne",
-    "Resources: Investigation Guide",
-]
-timestamp_override = "event.ingested"
-type = "eql"
-query = '''
-file where host.os.type == "linux" and event.type == "creation" and process.name == "chflags"
-'''
 note = """## Triage and analysis
 
 > **Disclaimer**:
@@ -72,21 +56,44 @@ In Unix-like systems, the 'hidden' flag can be set on files to conceal them from
 - Implement file integrity monitoring to detect unauthorized changes to file attributes, including the hidden flag, on critical systems.
 - Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected.
 - Update and enhance endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats in the future."""
+risk_score = 21
+rule_id = "5124e65f-df97-4471-8dcb-8e3953b3ea97"
+severity = "low"
+tags = [
+    "Domain: Endpoint",
+    "OS: Linux",
+    "OS: macOS",
+    "Use Case: Threat Detection",
+    "Tactic: Defense Evasion",
+    "Data Source: Elastic Defend",
+    "Data Source: Elastic Endgame",
+    "Data Source: Auditd Manager",
+    "Data Source: SentinelOne",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "eql"
+
+query = '''
+file where host.os.type == "linux" and event.type == "creation" and process.name == "chflags"
+'''
+
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
-
 [[rule.threat.technique]]
 id = "T1564"
 name = "Hide Artifacts"
 reference = "https://attack.mitre.org/techniques/T1564/"
-
 [[rule.threat.technique.subtechnique]]
 id = "T1564.001"
 name = "Hidden Files and Directories"
 reference = "https://attack.mitre.org/techniques/T1564/001/"
 
+
+
 [rule.threat.tactic]
 id = "TA0005"
 name = "Defense Evasion"
 reference = "https://attack.mitre.org/tactics/TA0005/"
+

rules/linux/defense_evasion_directory_creation_in_bin.toml

@@ -2,9 +2,7 @@
 creation_date = "2024/11/01"
 integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
-min_stack_version = "8.13.0"
-min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/02/04"
+updated_date = "2025/03/20"
 
 [rule]
 author = ["Elastic"]
@@ -14,10 +12,49 @@ files that are required for the system to function properly. The creation of dir
 attempt to hide malicious files or executables, as these /bin directories usually just contain binaries.
 """
 from = "now-9m"
-index = ["endgame-*", "logs-crowdstrike.fdr*", "logs-endpoint.events.process*", "logs-sentinel_one_cloud_funnel.*"]
+index = [
+    "endgame-*",
+    "logs-crowdstrike.fdr*",
+    "logs-endpoint.events.process*",
+    "logs-sentinel_one_cloud_funnel.*",
+]
 language = "eql"
 license = "Elastic License v2"
 name = "Directory Creation in /bin directory"
+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 Directory Creation in /bin directory
+
+The /bin directory is crucial for Linux systems, housing essential binaries for system operations. Adversaries may exploit this by creating directories here to conceal malicious files, leveraging the directory's trusted status. The detection rule identifies suspicious directory creation by monitoring 'mkdir' executions in critical binary paths, excluding legitimate system operations, thus flagging potential threats for further investigation.
+
+### Possible investigation steps
+
+- Review the process details to confirm the execution of 'mkdir' in the specified critical binary paths such as /bin, /usr/bin, /usr/local/bin, /sbin, /usr/sbin, and /usr/local/sbin.
+- Check the parent process of the 'mkdir' command to determine if it was initiated by a legitimate system process or a potentially malicious one.
+- Investigate the user account associated with the 'mkdir' process to assess if it has the necessary permissions and if the activity aligns with the user's typical behavior.
+- Examine the system logs around the time of the directory creation for any other suspicious activities or anomalies that might indicate a broader attack.
+- Verify if any files or executables have been placed in the newly created directory and assess their legitimacy and potential threat level.
+- Cross-reference the event with threat intelligence sources to identify if the activity matches any known malicious patterns or indicators of compromise.
+
+### False positive analysis
+
+- System updates or package installations may trigger directory creation in the /bin directory as part of legitimate operations. Users can mitigate this by creating exceptions for known package management processes like apt, yum, or rpm.
+- Custom scripts or administrative tasks that require creating directories in the /bin directory for temporary storage or testing purposes can also lead to false positives. Users should document and exclude these specific scripts or tasks from the detection rule.
+- Automated deployment tools or configuration management systems such as Ansible, Puppet, or Chef might create directories in the /bin directory as part of their setup routines. Users should identify these tools and add them to the exclusion list to prevent unnecessary alerts.
+- Development or testing environments where developers have permissions to create directories in the /bin directory for application testing can result in false positives. Users should differentiate between production and non-production environments and apply the rule accordingly.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent potential lateral movement or data exfiltration by the adversary.
+- Terminate any suspicious processes related to the directory creation in the /bin directory to halt any ongoing malicious activity.
+- Conduct a thorough review of the newly created directories and files within the /bin directory to identify and remove any malicious binaries or scripts.
+- Restore any altered or deleted legitimate binaries from a known good backup to ensure system integrity and functionality.
+- Implement file integrity monitoring on critical system directories, including /bin, to detect unauthorized changes in real-time.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are compromised.
+- Review and update access controls and permissions for the /bin directory to restrict unauthorized directory creation and enhance security posture."""
 risk_score = 21
 rule_id = "3302835b-0049-4004-a325-660b1fba1f67"
 setup = """## Setup
@@ -60,65 +97,32 @@ tags = [
 ]
 timestamp_override = "event.ingested"
 type = "eql"
+
 query = '''
 process where host.os.type == "linux" and event.type == "start" and
   event.action in ("exec", "start", "ProcessRollup2", "exec_event") and process.name == "mkdir" and
   process.args like ("/bin/*", "/usr/bin/*", "/usr/local/bin/*", "/sbin/*", "/usr/sbin/*", "/usr/local/sbin/*") and
 not process.args in ("/bin/mkdir", "/usr/bin/mkdir", "/usr/local/bin/mkdir")
 '''
-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 Directory Creation in /bin directory
-
-The /bin directory is crucial for Linux systems, housing essential binaries for system operations. Adversaries may exploit this by creating directories here to conceal malicious files, leveraging the directory's trusted status. The detection rule identifies suspicious directory creation by monitoring 'mkdir' executions in critical binary paths, excluding legitimate system operations, thus flagging potential threats for further investigation.
-
-### Possible investigation steps
-
-- Review the process details to confirm the execution of 'mkdir' in the specified critical binary paths such as /bin, /usr/bin, /usr/local/bin, /sbin, /usr/sbin, and /usr/local/sbin.
-- Check the parent process of the 'mkdir' command to determine if it was initiated by a legitimate system process or a potentially malicious one.
-- Investigate the user account associated with the 'mkdir' process to assess if it has the necessary permissions and if the activity aligns with the user's typical behavior.
-- Examine the system logs around the time of the directory creation for any other suspicious activities or anomalies that might indicate a broader attack.
-- Verify if any files or executables have been placed in the newly created directory and assess their legitimacy and potential threat level.
-- Cross-reference the event with threat intelligence sources to identify if the activity matches any known malicious patterns or indicators of compromise.
-
-### False positive analysis
-
-- System updates or package installations may trigger directory creation in the /bin directory as part of legitimate operations. Users can mitigate this by creating exceptions for known package management processes like apt, yum, or rpm.
-- Custom scripts or administrative tasks that require creating directories in the /bin directory for temporary storage or testing purposes can also lead to false positives. Users should document and exclude these specific scripts or tasks from the detection rule.
-- Automated deployment tools or configuration management systems such as Ansible, Puppet, or Chef might create directories in the /bin directory as part of their setup routines. Users should identify these tools and add them to the exclusion list to prevent unnecessary alerts.
-- Development or testing environments where developers have permissions to create directories in the /bin directory for application testing can result in false positives. Users should differentiate between production and non-production environments and apply the rule accordingly.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent potential lateral movement or data exfiltration by the adversary.
-- Terminate any suspicious processes related to the directory creation in the /bin directory to halt any ongoing malicious activity.
-- Conduct a thorough review of the newly created directories and files within the /bin directory to identify and remove any malicious binaries or scripts.
-- Restore any altered or deleted legitimate binaries from a known good backup to ensure system integrity and functionality.
-- Implement file integrity monitoring on critical system directories, including /bin, to detect unauthorized changes in real-time.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are compromised.
-- Review and update access controls and permissions for the /bin directory to restrict unauthorized directory creation and enhance security posture."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
-
 [[rule.threat.technique]]
 id = "T1564"
 name = "Hide Artifacts"
 reference = "https://attack.mitre.org/techniques/T1564/"
-
 [[rule.threat.technique.subtechnique]]
 id = "T1564.001"
 name = "Hidden Files and Directories"
 reference = "https://attack.mitre.org/techniques/T1564/001/"
 
+
+
 [rule.threat.tactic]
 id = "TA0005"
 name = "Defense Evasion"
 reference = "https://attack.mitre.org/tactics/TA0005/"
-
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 
@@ -126,3 +130,4 @@ framework = "MITRE ATT&CK"
 id = "TA0003"
 name = "Persistence"
 reference = "https://attack.mitre.org/tactics/TA0003/"
+

rules/linux/defense_evasion_disable_apparmor_attempt.toml

@@ -2,9 +2,7 @@
 creation_date = "2023/08/28"
 integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
-min_stack_version = "8.13.0"
-min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/02/04"
+updated_date = "2025/03/20"
 
 [rule]
 author = ["Elastic"]
@@ -14,10 +12,52 @@ fine-grained access control policies to restrict the actions and resources that
 access. Adversaries may disable security tools to avoid possible detection of their tools and activities.
 """
 from = "now-9m"
-index = ["auditbeat-*", "endgame-*", "logs-auditd_manager.auditd-*", "logs-crowdstrike.fdr*", "logs-endpoint.events.process*", "logs-sentinel_one_cloud_funnel.*"]
+index = [
+    "auditbeat-*",
+    "endgame-*",
+    "logs-auditd_manager.auditd-*",
+    "logs-crowdstrike.fdr*",
+    "logs-endpoint.events.process*",
+    "logs-sentinel_one_cloud_funnel.*",
+]
 language = "eql"
 license = "Elastic License v2"
 name = "Potential Disabling of AppArmor"
+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 Disabling of AppArmor
+
+AppArmor is a Linux security module that enforces strict access controls, limiting what applications can do. Adversaries may attempt to disable AppArmor to evade detection and freely execute malicious activities. The detection rule identifies suspicious processes attempting to stop or disable AppArmor services, such as using commands like `systemctl` or `service` with specific arguments, indicating potential tampering with security defenses.
+
+### Possible investigation steps
+
+- Review the process details to confirm the command used, focusing on the process name and arguments, such as "systemctl", "service", "chkconfig", or "ln" with arguments related to AppArmor.
+- Check the user account associated with the process execution to determine if it is a legitimate user or potentially compromised.
+- Investigate the host's recent activity logs to identify any other suspicious behavior or anomalies around the time the alert was triggered.
+- Examine the system's AppArmor status to verify if it has been disabled or tampered with, and assess any potential impact on system security.
+- Correlate this event with other alerts or logs from the same host or user to identify patterns or a broader attack campaign.
+- Consult threat intelligence sources to determine if there are known adversaries or malware that commonly attempt to disable AppArmor in similar ways.
+
+### False positive analysis
+
+- Routine system maintenance activities may trigger this rule, such as administrators stopping AppArmor for legitimate updates or configuration changes. To manage this, create exceptions for known maintenance windows or specific administrator accounts.
+- Automated scripts or configuration management tools like Ansible or Puppet might stop or disable AppArmor as part of their deployment processes. Identify these scripts and whitelist their execution paths or associated user accounts.
+- Testing environments where security modules are frequently enabled and disabled for testing purposes can generate false positives. Consider excluding these environments from the rule or adjusting the rule's sensitivity for these specific hosts.
+- Some legitimate software installations may require temporarily disabling AppArmor. Monitor installation logs and correlate them with the rule triggers to identify and exclude these benign activities.
+- In environments where AppArmor is not actively used or managed, the rule may trigger on default system actions. Evaluate the necessity of monitoring AppArmor in such environments and adjust the rule scope accordingly.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or potential lateral movement by the adversary.
+- Terminate any suspicious processes identified by the detection rule, specifically those attempting to disable AppArmor, to halt any ongoing malicious activities.
+- Conduct a thorough review of system logs and process execution history to identify any additional indicators of compromise or related malicious activities.
+- Restore AppArmor to its intended operational state by re-enabling the service and ensuring all security policies are correctly applied.
+- Escalate the incident to the security operations team for further analysis and to determine if additional systems may be affected.
+- Implement enhanced monitoring on the affected system and similar environments to detect any future attempts to disable AppArmor or other security controls.
+- Review and update access controls and permissions to ensure that only authorized personnel can modify security settings, reducing the risk of similar incidents."""
 risk_score = 21
 rule_id = "fac52c69-2646-4e79-89c0-fd7653461010"
 setup = """## Setup
@@ -60,6 +100,7 @@ tags = [
 ]
 timestamp_override = "event.ingested"
 type = "eql"
+
 query = '''
 process where host.os.type == "linux" and event.type == "start" and
  event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and
@@ -70,56 +111,23 @@ process where host.os.type == "linux" and event.type == "start" and
   (process.name == "ln" and process.args : "/etc/apparmor.d/*" and process.args == "/etc/apparmor.d/disable/")
 )
 '''
-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 Disabling of AppArmor
-
-AppArmor is a Linux security module that enforces strict access controls, limiting what applications can do. Adversaries may attempt to disable AppArmor to evade detection and freely execute malicious activities. The detection rule identifies suspicious processes attempting to stop or disable AppArmor services, such as using commands like `systemctl` or `service` with specific arguments, indicating potential tampering with security defenses.
-
-### Possible investigation steps
-
-- Review the process details to confirm the command used, focusing on the process name and arguments, such as "systemctl", "service", "chkconfig", or "ln" with arguments related to AppArmor.
-- Check the user account associated with the process execution to determine if it is a legitimate user or potentially compromised.
-- Investigate the host's recent activity logs to identify any other suspicious behavior or anomalies around the time the alert was triggered.
-- Examine the system's AppArmor status to verify if it has been disabled or tampered with, and assess any potential impact on system security.
-- Correlate this event with other alerts or logs from the same host or user to identify patterns or a broader attack campaign.
-- Consult threat intelligence sources to determine if there are known adversaries or malware that commonly attempt to disable AppArmor in similar ways.
-
-### False positive analysis
-
-- Routine system maintenance activities may trigger this rule, such as administrators stopping AppArmor for legitimate updates or configuration changes. To manage this, create exceptions for known maintenance windows or specific administrator accounts.
-- Automated scripts or configuration management tools like Ansible or Puppet might stop or disable AppArmor as part of their deployment processes. Identify these scripts and whitelist their execution paths or associated user accounts.
-- Testing environments where security modules are frequently enabled and disabled for testing purposes can generate false positives. Consider excluding these environments from the rule or adjusting the rule's sensitivity for these specific hosts.
-- Some legitimate software installations may require temporarily disabling AppArmor. Monitor installation logs and correlate them with the rule triggers to identify and exclude these benign activities.
-- In environments where AppArmor is not actively used or managed, the rule may trigger on default system actions. Evaluate the necessity of monitoring AppArmor in such environments and adjust the rule scope accordingly.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or potential lateral movement by the adversary.
-- Terminate any suspicious processes identified by the detection rule, specifically those attempting to disable AppArmor, to halt any ongoing malicious activities.
-- Conduct a thorough review of system logs and process execution history to identify any additional indicators of compromise or related malicious activities.
-- Restore AppArmor to its intended operational state by re-enabling the service and ensuring all security policies are correctly applied.
-- Escalate the incident to the security operations team for further analysis and to determine if additional systems may be affected.
-- Implement enhanced monitoring on the affected system and similar environments to detect any future attempts to disable AppArmor or other security controls.
-- Review and update access controls and permissions to ensure that only authorized personnel can modify security settings, reducing the risk of similar incidents."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
-
 [[rule.threat.technique]]
 id = "T1562"
 name = "Impair Defenses"
 reference = "https://attack.mitre.org/techniques/T1562/"
-
 [[rule.threat.technique.subtechnique]]
 id = "T1562.001"
 name = "Disable or Modify Tools"
 reference = "https://attack.mitre.org/techniques/T1562/001/"
 
+
+
 [rule.threat.tactic]
 id = "TA0005"
 name = "Defense Evasion"
 reference = "https://attack.mitre.org/tactics/TA0005/"
+

rules/linux/defense_evasion_disable_selinux_attempt.toml

@@ -2,9 +2,7 @@
 creation_date = "2020/04/22"
 integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
-min_stack_version = "8.13.0"
-min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/02/04"
+updated_date = "2025/03/20"
 
 [rule]
 author = ["Elastic"]
@@ -14,10 +12,51 @@ support access control policies. Adversaries may disable security tools to avoid
 activities.
 """
 from = "now-9m"
-index = ["auditbeat-*", "endgame-*", "logs-auditd_manager.auditd-*", "logs-crowdstrike.fdr*", "logs-endpoint.events.process*", "logs-sentinel_one_cloud_funnel.*"]
+index = [
+    "auditbeat-*",
+    "endgame-*",
+    "logs-auditd_manager.auditd-*",
+    "logs-crowdstrike.fdr*",
+    "logs-endpoint.events.process*",
+    "logs-sentinel_one_cloud_funnel.*",
+]
 language = "eql"
 license = "Elastic License v2"
 name = "Potential Disabling of SELinux"
+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 Disabling of SELinux
+
+SELinux is a critical security feature in Linux environments, enforcing access control policies to protect against unauthorized access. Adversaries may attempt to disable SELinux to evade detection and carry out malicious activities undetected. The detection rule identifies such attempts by monitoring for the execution of the 'setenforce 0' command, which switches SELinux to permissive mode, effectively disabling its enforcement capabilities. This rule leverages process monitoring to alert security teams of potential defense evasion tactics.
+
+### Possible investigation steps
+
+- Review the process execution details to confirm the presence of the 'setenforce 0' command, ensuring that the process name is 'setenforce' and the argument is '0'.
+- Check the user account associated with the process execution to determine if it is a legitimate administrative user or a potential compromised account.
+- Investigate the timeline of events leading up to and following the execution of the 'setenforce 0' command to identify any related suspicious activities or processes.
+- Examine system logs and audit logs for any other unusual or unauthorized changes to SELinux settings or other security configurations.
+- Assess the system for any signs of compromise or malicious activity, such as unexpected network connections, file modifications, or the presence of known malware indicators.
+- Verify the current SELinux status and configuration to ensure it has been restored to enforcing mode if it was indeed set to permissive mode.
+
+### False positive analysis
+
+- System administrators may execute the 'setenforce 0' command during routine maintenance or troubleshooting, leading to false positives. To manage this, create exceptions for known maintenance windows or specific administrator accounts.
+- Some automated scripts or configuration management tools might temporarily set SELinux to permissive mode for deployment purposes. Identify these scripts and exclude their execution context from triggering alerts.
+- Development environments might require SELinux to be set to permissive mode for testing purposes. Consider excluding specific development hosts or environments from the rule to prevent unnecessary alerts.
+- In certain cases, SELinux might be disabled as part of a controlled security audit or penetration test. Coordinate with security teams to whitelist these activities during the audit period.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary.
+- Verify the current SELinux status on the affected system using the command `sestatus` to confirm if it has been switched to permissive mode.
+- If SELinux is in permissive mode, re-enable it by executing `setenforce 1` and ensure that the SELinux policy is correctly enforced.
+- Conduct a thorough review of system logs and process execution history to identify any unauthorized changes or suspicious activities that occurred while SELinux was disabled.
+- Scan the affected system for malware or unauthorized software installations using a trusted antivirus or endpoint detection and response (EDR) tool.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are compromised.
+- Implement additional monitoring and alerting for similar SELinux-related events to enhance detection capabilities and prevent recurrence."""
 risk_score = 47
 rule_id = "eb9eb8ba-a983-41d9-9c93-a1c05112ca5e"
 setup = """## Setup
@@ -78,40 +117,6 @@ process where host.os.type == "linux" and event.type == "start" and
  event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and
  process.name == "setenforce" and process.args == "0"
 '''
-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 Disabling of SELinux
-
-SELinux is a critical security feature in Linux environments, enforcing access control policies to protect against unauthorized access. Adversaries may attempt to disable SELinux to evade detection and carry out malicious activities undetected. The detection rule identifies such attempts by monitoring for the execution of the 'setenforce 0' command, which switches SELinux to permissive mode, effectively disabling its enforcement capabilities. This rule leverages process monitoring to alert security teams of potential defense evasion tactics.
-
-### Possible investigation steps
-
-- Review the process execution details to confirm the presence of the 'setenforce 0' command, ensuring that the process name is 'setenforce' and the argument is '0'.
-- Check the user account associated with the process execution to determine if it is a legitimate administrative user or a potential compromised account.
-- Investigate the timeline of events leading up to and following the execution of the 'setenforce 0' command to identify any related suspicious activities or processes.
-- Examine system logs and audit logs for any other unusual or unauthorized changes to SELinux settings or other security configurations.
-- Assess the system for any signs of compromise or malicious activity, such as unexpected network connections, file modifications, or the presence of known malware indicators.
-- Verify the current SELinux status and configuration to ensure it has been restored to enforcing mode if it was indeed set to permissive mode.
-
-### False positive analysis
-
-- System administrators may execute the 'setenforce 0' command during routine maintenance or troubleshooting, leading to false positives. To manage this, create exceptions for known maintenance windows or specific administrator accounts.
-- Some automated scripts or configuration management tools might temporarily set SELinux to permissive mode for deployment purposes. Identify these scripts and exclude their execution context from triggering alerts.
-- Development environments might require SELinux to be set to permissive mode for testing purposes. Consider excluding specific development hosts or environments from the rule to prevent unnecessary alerts.
-- In certain cases, SELinux might be disabled as part of a controlled security audit or penetration test. Coordinate with security teams to whitelist these activities during the audit period.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary.
-- Verify the current SELinux status on the affected system using the command `sestatus` to confirm if it has been switched to permissive mode.
-- If SELinux is in permissive mode, re-enable it by executing `setenforce 1` and ensure that the SELinux policy is correctly enforced.
-- Conduct a thorough review of system logs and process execution history to identify any unauthorized changes or suspicious activities that occurred while SELinux was disabled.
-- Scan the affected system for malware or unauthorized software installations using a trusted antivirus or endpoint detection and response (EDR) tool.
-- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are compromised.
-- Implement additional monitoring and alerting for similar SELinux-related events to enhance detection capabilities and prevent recurrence."""
 
 
 [[rule.threat]]

rules/linux/defense_evasion_doas_configuration_creation_or_rename.toml

@@ -2,22 +2,54 @@
 creation_date = "2024/08/28"
 integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
-min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-min_stack_version = "8.13.0"
-updated_date = "2025/01/15"
+updated_date = "2025/03/20"
 
 [rule]
 author = ["Elastic"]
 description = """
-This rule detects the creation or rename of the Doas configuration file on a Linux system. Adversaries may create
-or modify the Doas configuration file to elevate privileges and execute commands as other users while attempting to
-evade detection.
+This rule detects the creation or rename of the Doas configuration file on a Linux system. Adversaries may create or
+modify the Doas configuration file to elevate privileges and execute commands as other users while attempting to evade
+detection.
 """
 from = "now-9m"
 index = ["logs-endpoint.events.file*", "endgame-*", "logs-sentinel_one_cloud_funnel.*"]
 language = "eql"
 license = "Elastic License v2"
 name = "Potential Defense Evasion via Doas"
+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 Defense Evasion via Doas
+
+Doas is a command-line utility on Linux systems that allows users to execute commands as another user, typically with elevated privileges. Adversaries may exploit this by altering the Doas configuration file to gain unauthorized access or escalate privileges, bypassing security measures. The detection rule identifies suspicious activities by monitoring changes to the Doas configuration file, signaling potential misuse aimed at evading defenses.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the file path involved is "/etc/doas.conf" and the event type is not "deletion", as specified in the query.
+- Check the timestamp of the alert to determine when the configuration file was created or modified, and correlate this with any known scheduled changes or maintenance activities.
+- Investigate the user account associated with the event to determine if they have legitimate reasons to modify the Doas configuration file, and verify their access permissions.
+- Examine system logs and command history around the time of the alert to identify any suspicious activities or commands executed by the user.
+- Assess the current Doas configuration file for unauthorized changes or entries that could indicate privilege escalation attempts.
+- Cross-reference the alert with other security events or alerts from the same host to identify potential patterns or related activities that could suggest a broader attack.
+
+### False positive analysis
+
+- Routine administrative updates to the Doas configuration file can trigger alerts. To manage this, create exceptions for known maintenance windows or specific user accounts responsible for legitimate updates.
+- Automated configuration management tools may modify the Doas configuration file as part of their normal operation. Identify these tools and exclude their activities from triggering alerts by specifying their process names or user accounts.
+- System backups or restoration processes might involve creating or renaming the Doas configuration file. Exclude these processes by identifying the backup software and adding it to the exception list.
+- Development or testing environments where frequent changes to the Doas configuration file are expected can generate false positives. Consider excluding these environments from monitoring or adjusting the rule to account for their unique activity patterns.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary.
+- Review and revert any unauthorized changes to the Doas configuration file located at /etc/doas.conf to its last known good state.
+- Conduct a thorough audit of user accounts and permissions on the affected system to identify and remove any unauthorized accounts or privilege escalations.
+- Implement additional monitoring on the affected system to detect any further attempts to modify the Doas configuration file or other critical system files.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if the threat has spread to other systems.
+- Apply patches and updates to the affected system to address any vulnerabilities that may have been exploited by the adversary.
+- Review and enhance access controls and authentication mechanisms to prevent unauthorized privilege escalation attempts in the future."""
 references = ["https://wiki.archlinux.org/title/Doas"]
 risk_score = 21
 rule_id = "26a726d7-126e-4267-b43d-e9a70bfdee1e"
@@ -59,58 +91,27 @@ tags = [
 ]
 timestamp_override = "event.ingested"
 type = "eql"
+
 query = '''
 file where host.os.type == "linux" and event.type != "deletion" and file.path == "/etc/doas.conf"
 '''
-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 Defense Evasion via Doas
-
-Doas is a command-line utility on Linux systems that allows users to execute commands as another user, typically with elevated privileges. Adversaries may exploit this by altering the Doas configuration file to gain unauthorized access or escalate privileges, bypassing security measures. The detection rule identifies suspicious activities by monitoring changes to the Doas configuration file, signaling potential misuse aimed at evading defenses.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the file path involved is "/etc/doas.conf" and the event type is not "deletion", as specified in the query.
-- Check the timestamp of the alert to determine when the configuration file was created or modified, and correlate this with any known scheduled changes or maintenance activities.
-- Investigate the user account associated with the event to determine if they have legitimate reasons to modify the Doas configuration file, and verify their access permissions.
-- Examine system logs and command history around the time of the alert to identify any suspicious activities or commands executed by the user.
-- Assess the current Doas configuration file for unauthorized changes or entries that could indicate privilege escalation attempts.
-- Cross-reference the alert with other security events or alerts from the same host to identify potential patterns or related activities that could suggest a broader attack.
-
-### False positive analysis
-
-- Routine administrative updates to the Doas configuration file can trigger alerts. To manage this, create exceptions for known maintenance windows or specific user accounts responsible for legitimate updates.
-- Automated configuration management tools may modify the Doas configuration file as part of their normal operation. Identify these tools and exclude their activities from triggering alerts by specifying their process names or user accounts.
-- System backups or restoration processes might involve creating or renaming the Doas configuration file. Exclude these processes by identifying the backup software and adding it to the exception list.
-- Development or testing environments where frequent changes to the Doas configuration file are expected can generate false positives. Consider excluding these environments from monitoring or adjusting the rule to account for their unique activity patterns.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary.
-- Review and revert any unauthorized changes to the Doas configuration file located at /etc/doas.conf to its last known good state.
-- Conduct a thorough audit of user accounts and permissions on the affected system to identify and remove any unauthorized accounts or privilege escalations.
-- Implement additional monitoring on the affected system to detect any further attempts to modify the Doas configuration file or other critical system files.
-- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if the threat has spread to other systems.
-- Apply patches and updates to the affected system to address any vulnerabilities that may have been exploited by the adversary.
-- Review and enhance access controls and authentication mechanisms to prevent unauthorized privilege escalation attempts in the future."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
-
 [[rule.threat.technique]]
 id = "T1548"
 name = "Abuse Elevation Control Mechanism"
 reference = "https://attack.mitre.org/techniques/T1548/"
-
 [[rule.threat.technique.subtechnique]]
 id = "T1548.003"
 name = "Sudo and Sudo Caching"
 reference = "https://attack.mitre.org/techniques/T1548/003/"
 
+
+
 [rule.threat.tactic]
 id = "TA0005"
 name = "Defense Evasion"
 reference = "https://attack.mitre.org/tactics/TA0005/"
+

rules/linux/defense_evasion_esxi_suspicious_timestomp_touch.toml

@@ -2,9 +2,7 @@
 creation_date = "2023/04/11"
 integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
-min_stack_version = "8.13.0"
-min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/02/04"
+updated_date = "2025/03/20"
 
 [rule]
 author = ["Elastic"]
@@ -16,10 +14,52 @@ their presence in the touch command arguments may indicate that a threat actor i
 of VM-related files and configurations on the system.
 """
 from = "now-9m"
-index = ["auditbeat-*", "endgame-*", "logs-auditd_manager.auditd-*", "logs-crowdstrike.fdr*", "logs-endpoint.events.process*", "logs-sentinel_one_cloud_funnel.*"]
+index = [
+    "auditbeat-*",
+    "endgame-*",
+    "logs-auditd_manager.auditd-*",
+    "logs-crowdstrike.fdr*",
+    "logs-endpoint.events.process*",
+    "logs-sentinel_one_cloud_funnel.*",
+]
 language = "eql"
 license = "Elastic License v2"
 name = "ESXI Timestomping using Touch Command"
+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 ESXI Timestomping using Touch Command
+
+VMware ESXi is a hypervisor used to manage virtual machines. Adversaries may exploit the 'touch' command with the "-r" flag to alter file timestamps, masking unauthorized changes in VM-related directories. The detection rule identifies such activities by monitoring the execution of 'touch' with specific arguments, signaling potential timestamp tampering in critical VMware paths.
+
+### Possible investigation steps
+
+- Review the process execution details to confirm the presence of the 'touch' command with the "-r" flag and verify the specific VM-related paths involved, such as "/etc/vmware/", "/usr/lib/vmware/", or "/vmfs/*".
+- Check the user account associated with the process execution to determine if it is a legitimate user or potentially compromised account.
+- Investigate the parent process of the 'touch' command to understand the context of its execution and identify any related suspicious activities.
+- Examine recent changes to the files in the specified paths to identify any unauthorized modifications or anomalies.
+- Correlate the event with other security alerts or logs from the same host to identify patterns or additional indicators of compromise.
+- Assess the system for any signs of unauthorized access or other defense evasion techniques that may have been employed by the threat actor.
+
+### False positive analysis
+
+- Routine administrative tasks in VMware environments may trigger the rule if administrators use the touch command with the -r flag for legitimate purposes. To manage this, create exceptions for known administrative scripts or processes that regularly perform these actions.
+- Automated backup or synchronization tools that update file timestamps as part of their normal operation can cause false positives. Identify these tools and exclude their processes from the rule to prevent unnecessary alerts.
+- System maintenance activities, such as updates or patches, might involve timestamp modifications in VMware directories. Coordinate with IT teams to whitelist these activities during scheduled maintenance windows.
+- Custom scripts developed in-house for managing VMware environments might use the touch command with the -r flag. Review these scripts and, if verified as safe, add them to an exception list to avoid false positives.
+- Security tools or monitoring solutions that perform integrity checks on VMware files may inadvertently alter timestamps. Ensure these tools are recognized and excluded from the rule to maintain accurate threat detection.
+
+### Response and remediation
+
+- Immediately isolate the affected host from the network to prevent further unauthorized access or tampering with VMware-related files.
+- Conduct a thorough review of the affected system's logs and processes to identify any unauthorized changes or additional malicious activities.
+- Restore the original timestamps of the affected files using verified backups to ensure the integrity of the VMware-related configurations.
+- Revert any unauthorized changes to the VMware environment by restoring from a known good backup or snapshot.
+- Update and patch the VMware ESXi and associated software to the latest versions to mitigate any known vulnerabilities that could be exploited.
+- Implement stricter access controls and monitoring on critical VMware directories to prevent unauthorized modifications in the future.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected."""
 references = [
     "https://www.bleepingcomputer.com/news/security/massive-esxiargs-ransomware-attack-targets-vmware-esxi-servers-worldwide/",
 ]
@@ -71,41 +111,6 @@ process where host.os.type == "linux" and event.type == "start" and
  event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and
  process.name == "touch" and process.args == "-r" and process.args : ("/etc/vmware/*", "/usr/lib/vmware/*", "/vmfs/*")
 '''
-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 ESXI Timestomping using Touch Command
-
-VMware ESXi is a hypervisor used to manage virtual machines. Adversaries may exploit the 'touch' command with the "-r" flag to alter file timestamps, masking unauthorized changes in VM-related directories. The detection rule identifies such activities by monitoring the execution of 'touch' with specific arguments, signaling potential timestamp tampering in critical VMware paths.
-
-### Possible investigation steps
-
-- Review the process execution details to confirm the presence of the 'touch' command with the "-r" flag and verify the specific VM-related paths involved, such as "/etc/vmware/", "/usr/lib/vmware/", or "/vmfs/*".
-- Check the user account associated with the process execution to determine if it is a legitimate user or potentially compromised account.
-- Investigate the parent process of the 'touch' command to understand the context of its execution and identify any related suspicious activities.
-- Examine recent changes to the files in the specified paths to identify any unauthorized modifications or anomalies.
-- Correlate the event with other security alerts or logs from the same host to identify patterns or additional indicators of compromise.
-- Assess the system for any signs of unauthorized access or other defense evasion techniques that may have been employed by the threat actor.
-
-### False positive analysis
-
-- Routine administrative tasks in VMware environments may trigger the rule if administrators use the touch command with the -r flag for legitimate purposes. To manage this, create exceptions for known administrative scripts or processes that regularly perform these actions.
-- Automated backup or synchronization tools that update file timestamps as part of their normal operation can cause false positives. Identify these tools and exclude their processes from the rule to prevent unnecessary alerts.
-- System maintenance activities, such as updates or patches, might involve timestamp modifications in VMware directories. Coordinate with IT teams to whitelist these activities during scheduled maintenance windows.
-- Custom scripts developed in-house for managing VMware environments might use the touch command with the -r flag. Review these scripts and, if verified as safe, add them to an exception list to avoid false positives.
-- Security tools or monitoring solutions that perform integrity checks on VMware files may inadvertently alter timestamps. Ensure these tools are recognized and excluded from the rule to maintain accurate threat detection.
-
-### Response and remediation
-
-- Immediately isolate the affected host from the network to prevent further unauthorized access or tampering with VMware-related files.
-- Conduct a thorough review of the affected system's logs and processes to identify any unauthorized changes or additional malicious activities.
-- Restore the original timestamps of the affected files using verified backups to ensure the integrity of the VMware-related configurations.
-- Revert any unauthorized changes to the VMware environment by restoring from a known good backup or snapshot.
-- Update and patch the VMware ESXi and associated software to the latest versions to mitigate any known vulnerabilities that could be exploited.
-- Implement stricter access controls and monitoring on critical VMware directories to prevent unauthorized modifications in the future.
-- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected."""
 
 
 [[rule.threat]]

rules/linux/defense_evasion_file_deletion_via_shred.toml

@@ -2,9 +2,7 @@
 creation_date = "2020/04/27"
 integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
-min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-min_stack_version = "8.13.0"
-updated_date = "2025/02/04"
+updated_date = "2025/03/20"
 
 [rule]
 author = ["Elastic"]
@@ -14,10 +12,49 @@ a network and how. Adversaries may remove these files over the course of an intr
 remove them at the end as part of the post-intrusion cleanup process.
 """
 from = "now-9m"
-index = ["endgame-*", "logs-crowdstrike.fdr*", "logs-endpoint.events.process*", "logs-sentinel_one_cloud_funnel.*"]
+index = [
+    "endgame-*",
+    "logs-crowdstrike.fdr*",
+    "logs-endpoint.events.process*",
+    "logs-sentinel_one_cloud_funnel.*",
+]
 language = "eql"
 license = "Elastic License v2"
 name = "File Deletion via Shred"
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
+
+### Investigating File Deletion via Shred
+
+The `shred` command in Linux is used to securely delete files by overwriting them, making recovery difficult. Adversaries exploit this to erase traces of malicious activity, hindering forensic analysis. The detection rule identifies suspicious use of `shred` by monitoring its execution with specific arguments, excluding benign processes like `logrotate`, to flag potential defense evasion attempts.
+
+### Possible investigation steps
+
+- Review the process execution details to confirm the use of the `shred` command with suspicious arguments such as "-u", "--remove", "-z", or "--zero".
+- Identify the user account associated with the `shred` process to determine if the activity aligns with expected behavior for that user.
+- Investigate the parent process of `shred` to ensure it is not `logrotate` and assess whether the parent process is legitimate or potentially malicious.
+- Examine the timeline of events leading up to and following the `shred` execution to identify any related suspicious activities or file modifications.
+- Check for any other alerts or logs related to the same host or user to identify patterns or additional indicators of compromise.
+- Assess the impact of the file deletion by determining which files were targeted and whether they are critical to system operations or security.
+
+### False positive analysis
+
+- Logrotate processes may trigger false positives as they use shred for legitimate log file management. Exclude logrotate as a parent process in detection rules to prevent these alerts.
+- System maintenance scripts that securely delete temporary files using shred can cause false positives. Identify and whitelist these scripts to reduce unnecessary alerts.
+- Backup or cleanup operations that involve shredding old data might be flagged. Review and exclude these operations if they are part of routine system management.
+- User-initiated file deletions for privacy or space management can appear suspicious. Educate users on the implications of using shred and consider excluding known user actions if they are frequent and benign.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further malicious activity or data exfiltration.
+- Terminate any active `shred` processes that are not associated with legitimate applications like `logrotate` to halt ongoing file deletion.
+- Conduct a thorough review of recent system logs and file access records to identify any additional malicious activities or files that may have been created or modified by the adversary.
+- Restore any critical files that were deleted using `shred` from the most recent backup, ensuring the integrity and security of the backup source.
+- 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 on the affected system and similar environments to detect any future unauthorized use of `shred` or similar file deletion tools.
+- Review and update endpoint security configurations to prevent unauthorized execution of file deletion commands by non-administrative users."""
 risk_score = 21
 rule_id = "a1329140-8de3-4445-9f87-908fb6d824f4"
 setup = """## Setup
@@ -65,40 +102,6 @@ process where host.os.type == "linux" and event.type == "start" and process.name
   "-u", "--remove", "-z", "--zero"
 ) and not process.parent.name == "logrotate"
 '''
-note = """## Triage and analysis
-
-> **Disclaimer**:
-> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
-
-### Investigating File Deletion via Shred
-
-The `shred` command in Linux is used to securely delete files by overwriting them, making recovery difficult. Adversaries exploit this to erase traces of malicious activity, hindering forensic analysis. The detection rule identifies suspicious use of `shred` by monitoring its execution with specific arguments, excluding benign processes like `logrotate`, to flag potential defense evasion attempts.
-
-### Possible investigation steps
-
-- Review the process execution details to confirm the use of the `shred` command with suspicious arguments such as "-u", "--remove", "-z", or "--zero".
-- Identify the user account associated with the `shred` process to determine if the activity aligns with expected behavior for that user.
-- Investigate the parent process of `shred` to ensure it is not `logrotate` and assess whether the parent process is legitimate or potentially malicious.
-- Examine the timeline of events leading up to and following the `shred` execution to identify any related suspicious activities or file modifications.
-- Check for any other alerts or logs related to the same host or user to identify patterns or additional indicators of compromise.
-- Assess the impact of the file deletion by determining which files were targeted and whether they are critical to system operations or security.
-
-### False positive analysis
-
-- Logrotate processes may trigger false positives as they use shred for legitimate log file management. Exclude logrotate as a parent process in detection rules to prevent these alerts.
-- System maintenance scripts that securely delete temporary files using shred can cause false positives. Identify and whitelist these scripts to reduce unnecessary alerts.
-- Backup or cleanup operations that involve shredding old data might be flagged. Review and exclude these operations if they are part of routine system management.
-- User-initiated file deletions for privacy or space management can appear suspicious. Educate users on the implications of using shred and consider excluding known user actions if they are frequent and benign.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further malicious activity or data exfiltration.
-- Terminate any active `shred` processes that are not associated with legitimate applications like `logrotate` to halt ongoing file deletion.
-- Conduct a thorough review of recent system logs and file access records to identify any additional malicious activities or files that may have been created or modified by the adversary.
-- Restore any critical files that were deleted using `shred` from the most recent backup, ensuring the integrity and security of the backup source.
-- 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 on the affected system and similar environments to detect any future unauthorized use of `shred` or similar file deletion tools.
-- Review and update endpoint security configurations to prevent unauthorized execution of file deletion commands by non-administrative users."""
 
 
 [[rule.threat]]

rules/linux/defense_evasion_hex_payload_execution.toml

@@ -2,21 +2,59 @@
 creation_date = "2024/11/04"
 integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
-min_stack_version = "8.13.0"
-min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/15"
+updated_date = "2025/03/20"
 
 [rule]
 author = ["Elastic"]
 description = """
-This rule detects potential hex payload execution on Linux systems. Adversaries may use hex encoding to obfuscate payloads
-and evade detection mechanisms.
+This rule detects potential hex payload execution on Linux systems. Adversaries may use hex encoding to obfuscate
+payloads and evade detection mechanisms.
 """
 from = "now-9m"
-index = ["logs-endpoint.events.process*", "logs-crowdstrike.fdr*", "logs-sentinel_one_cloud_funnel.*", "endgame-*"]
+index = [
+    "logs-endpoint.events.process*",
+    "logs-crowdstrike.fdr*",
+    "logs-sentinel_one_cloud_funnel.*",
+    "endgame-*",
+]
 language = "eql"
 license = "Elastic License v2"
 name = "Potential Hex Payload Execution"
+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 Hex Payload Execution
+
+Hex encoding is often used in Linux environments to obfuscate data, making it harder for security tools to detect malicious payloads. Adversaries exploit this by encoding their payloads in hex to bypass security measures. The detection rule identifies suspicious processes like `xxd`, `python`, `php`, and others that use hex-related functions, signaling potential obfuscation attempts. By monitoring these patterns, the rule helps uncover hidden threats.
+
+### Possible investigation steps
+
+- Review the process details, including the process name and command line arguments, to confirm if the execution aligns with typical hex decoding or encoding activities.
+- Check the parent process of the suspicious process to understand the context of how the process was initiated and whether it was expected or part of a legitimate workflow.
+- Investigate the user account associated with the process execution to determine if the activity is consistent with the user's normal behavior or if the account may have been compromised.
+- Examine the network activity associated with the process to identify any potential data exfiltration or communication with known malicious IP addresses.
+- Look for any related file modifications or creations around the time of the process execution to identify if the decoded payload was written to disk or executed further.
+- Cross-reference the alert with other security tools or logs, such as Crowdstrike or SentinelOne, to gather additional context or corroborating evidence of malicious activity.
+
+### False positive analysis
+
+- Development and testing environments may frequently use hex encoding functions for legitimate purposes. To reduce noise, consider excluding processes running on known development servers from the rule.
+- System administrators might use hex encoding tools like `xxd` for data conversion tasks. Identify and whitelist these routine administrative scripts to prevent false alerts.
+- Automated scripts or applications that process data in hex format for encoding or decoding purposes can trigger this rule. Review and exclude these scripts if they are verified as non-malicious.
+- Security tools or monitoring solutions themselves might use hex encoding for data analysis. Ensure these tools are recognized and excluded from triggering the rule.
+- Regularly review and update the exclusion list to adapt to changes in the environment and ensure that only verified non-threatening behaviors are excluded.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further spread of potentially malicious payloads.
+- Terminate any suspicious processes identified by the detection rule, such as those involving `xxd`, `python`, `php`, `ruby`, `perl`, or `lua` with hex-related functions.
+- Conduct a thorough scan of the isolated system using updated antivirus and anti-malware tools to identify and remove any malicious payloads or remnants.
+- Review and analyze system logs and process execution history to determine the scope of the compromise and identify any additional affected systems.
+- Restore the system from a known good backup if malicious activity is confirmed and cannot be fully remediated.
+- Implement additional monitoring on the affected system and network to detect any recurrence of similar obfuscation attempts.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to assess the need for broader organizational response measures."""
 risk_score = 21
 rule_id = "0c1e8fda-4f09-451e-bc77-a192b6cbfc32"
 setup = """## Setup
@@ -59,6 +97,7 @@ tags = [
 ]
 timestamp_override = "event.ingested"
 type = "eql"
+
 query = '''
 process where host.os.type == "linux" and event.type == "start" and
   event.action in ("exec", "exec_event", "start", "ProcessRollup2") and
@@ -71,84 +110,50 @@ process where host.os.type == "linux" and event.type == "start" and
     (process.name like "lua*" and process.command_line like "*tonumber(cc, 16)*")
   )
 '''
-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 Hex Payload Execution
-
-Hex encoding is often used in Linux environments to obfuscate data, making it harder for security tools to detect malicious payloads. Adversaries exploit this by encoding their payloads in hex to bypass security measures. The detection rule identifies suspicious processes like `xxd`, `python`, `php`, and others that use hex-related functions, signaling potential obfuscation attempts. By monitoring these patterns, the rule helps uncover hidden threats.
-
-### Possible investigation steps
-
-- Review the process details, including the process name and command line arguments, to confirm if the execution aligns with typical hex decoding or encoding activities.
-- Check the parent process of the suspicious process to understand the context of how the process was initiated and whether it was expected or part of a legitimate workflow.
-- Investigate the user account associated with the process execution to determine if the activity is consistent with the user's normal behavior or if the account may have been compromised.
-- Examine the network activity associated with the process to identify any potential data exfiltration or communication with known malicious IP addresses.
-- Look for any related file modifications or creations around the time of the process execution to identify if the decoded payload was written to disk or executed further.
-- Cross-reference the alert with other security tools or logs, such as Crowdstrike or SentinelOne, to gather additional context or corroborating evidence of malicious activity.
-
-### False positive analysis
-
-- Development and testing environments may frequently use hex encoding functions for legitimate purposes. To reduce noise, consider excluding processes running on known development servers from the rule.
-- System administrators might use hex encoding tools like `xxd` for data conversion tasks. Identify and whitelist these routine administrative scripts to prevent false alerts.
-- Automated scripts or applications that process data in hex format for encoding or decoding purposes can trigger this rule. Review and exclude these scripts if they are verified as non-malicious.
-- Security tools or monitoring solutions themselves might use hex encoding for data analysis. Ensure these tools are recognized and excluded from triggering the rule.
-- Regularly review and update the exclusion list to adapt to changes in the environment and ensure that only verified non-threatening behaviors are excluded.
-
-### Response and remediation
-
-- Isolate the affected system from the network to prevent further spread of potentially malicious payloads.
-- Terminate any suspicious processes identified by the detection rule, such as those involving `xxd`, `python`, `php`, `ruby`, `perl`, or `lua` with hex-related functions.
-- Conduct a thorough scan of the isolated system using updated antivirus and anti-malware tools to identify and remove any malicious payloads or remnants.
-- Review and analyze system logs and process execution history to determine the scope of the compromise and identify any additional affected systems.
-- Restore the system from a known good backup if malicious activity is confirmed and cannot be fully remediated.
-- Implement additional monitoring on the affected system and network to detect any recurrence of similar obfuscation attempts.
-- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to assess the need for broader organizational response measures."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1027"
+name = "Obfuscated Files or Information"
+reference = "https://attack.mitre.org/techniques/T1027/"
 
-  [rule.threat.tactic]
-  name = "Defense Evasion"
-  id = "TA0005"
-  reference = "https://attack.mitre.org/tactics/TA0005/"
+[[rule.threat.technique]]
+id = "T1140"
+name = "Deobfuscate/Decode Files or Information"
+reference = "https://attack.mitre.org/techniques/T1140/"
 
-    [[rule.threat.technique]]
-    name = "Obfuscated Files or Information"
-    id = "T1027"
-    reference = "https://attack.mitre.org/techniques/T1027/"
-
-    [[rule.threat.technique]]
-    name = "Deobfuscate/Decode Files or Information"
-    id = "T1140"
-    reference = "https://attack.mitre.org/techniques/T1140/"
 
+[rule.threat.tactic]
+id = "TA0005"
+name = "Defense Evasion"
+reference = "https://attack.mitre.org/tactics/TA0005/"
 [[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]
-  name = "Execution"
-  id = "TA0002"
-  reference = "https://attack.mitre.org/tactics/TA0002/"
 
-    [[rule.threat.technique]]
-    id = "T1059"
-    name = "Command and Scripting Interpreter"
-    reference = "https://attack.mitre.org/techniques/T1059/"
+[[rule.threat.technique]]
+id = "T1204"
+name = "User Execution"
+reference = "https://attack.mitre.org/techniques/T1204/"
+[[rule.threat.technique.subtechnique]]
+id = "T1204.002"
+name = "Malicious File"
+reference = "https://attack.mitre.org/techniques/T1204/002/"
 
-      [[rule.threat.technique.subtechnique]]
-      name = "Unix Shell"
-      id = "T1059.004"
-      reference = "https://attack.mitre.org/techniques/T1059/004/"
 
-    [[rule.threat.technique]]
-    name = "User Execution"
-    id = "T1204"
-    reference = "https://attack.mitre.org/techniques/T1204/"
 
-      [[rule.threat.technique.subtechnique]]
-      name = "Malicious File"
-      id = "T1204.002"
-      reference = "https://attack.mitre.org/techniques/T1204/002/"
+[rule.threat.tactic]
+id = "TA0002"
+name = "Execution"
+reference = "https://attack.mitre.org/tactics/TA0002/"
+

rules/linux/defense_evasion_hidden_directory_creation.toml

@@ -2,9 +2,7 @@
 creation_date = "2024/11/01"
 integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
-min_stack_version = "8.13.0"
-min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/02/04"
+updated_date = "2025/03/20"
 
 [rule]
 author = ["Elastic"]
@@ -15,8 +13,8 @@ tools.
 """
 false_positives = [
     """
-    Certain tools may create hidden temporary directories upon installation or as part of their normal
-    behavior. These events can be filtered by the process arguments, username, or process name values.
+    Certain tools may create hidden temporary directories upon installation or as part of their normal behavior. These
+    events can be filtered by the process arguments, username, or process name values.
     """,
 ]
 from = "now-9m"
@@ -24,6 +22,41 @@ index = ["endgame-*", "logs-endpoint.events.process*", "logs-sentinel_one_cloud_
 language = "eql"
 license = "Elastic License v2"
 name = "Hidden Directory Creation via Unusual Parent"
+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 Hidden Directory Creation via Unusual Parent
+
+In Linux environments, hidden directories, often prefixed with a dot, are typically used for configuration files but can be exploited by attackers to conceal malicious activities. Adversaries may create these directories using unexpected parent processes in sensitive locations. The detection rule identifies such anomalies by monitoring directory creation commands executed by unusual parent executables, focusing on specific directories and excluding known benign patterns.
+
+### Possible investigation steps
+
+- Review the process.parent.executable field to identify the parent process that initiated the directory creation and assess its legitimacy based on its typical behavior and location.
+- Examine the process.args field to understand the specific arguments used with the mkdir command, focusing on the directory path and any patterns that may indicate malicious intent.
+- Check the process.command_line field for any unusual or suspicious command-line patterns that might suggest an attempt to evade detection.
+- Investigate the context of the parent process by reviewing recent activities or logs associated with it, especially if it originates from sensitive directories like /dev/shm, /tmp, or /var/tmp.
+- Correlate the alert with other security events or logs from the same host to identify any related suspicious activities or patterns that could indicate a broader attack or compromise.
+- Consult threat intelligence sources or databases to determine if the parent executable or directory path has been associated with known malicious activities or threat actors.
+
+### False positive analysis
+
+- Temporary directories used by legitimate applications can trigger false positives. Exclude known benign parent executables like those in "/tmp/newroot/*" or "/run/containerd/*" to reduce noise.
+- Automated build processes may create hidden directories during software compilation. Add exceptions for parent executables such as "/var/tmp/buildah*" or "/tmp/python-build.*" to prevent unnecessary alerts.
+- Development tools and scripts might create hidden directories for caching or temporary storage. Consider excluding parent executables like "/tmp/pear/temp/*" or "/tmp/cliphist-wofi-img" if they are part of regular development activities.
+- Ensure that the command line patterns like "mkdir -p ." or "mkdir ./*" are excluded, as these are common in scripts and do not typically indicate malicious intent.
+- Regularly review and update the list of excluded patterns and parent executables to align with changes in the environment and reduce false positives effectively.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further malicious activity and lateral movement.
+- Terminate any suspicious processes associated with the unusual parent executable identified in the alert to halt potential malicious operations.
+- Conduct a thorough review of the hidden directory and its contents to identify and remove any malicious files or tools.
+- Restore any affected files or configurations from a known good backup to ensure system integrity.
+- Implement stricter access controls and monitoring on sensitive directories to prevent unauthorized directory creation.
+- Escalate the incident to the security operations team for further investigation and to determine if additional systems are compromised.
+- Update and enhance endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats in the future."""
 risk_score = 21
 rule_id = "b15a15f2-becf-475d-aa69-45c9e0ff1c49"
 setup = """## Setup
@@ -65,6 +98,7 @@ tags = [
 ]
 timestamp_override = "event.ingested"
 type = "eql"
+
 query = '''
 process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "start", "exec_event") and
 process.name == "mkdir" and process.parent.executable like (
@@ -78,60 +112,25 @@ process.name == "mkdir" and process.parent.executable like (
   )
 )
 '''
-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 Hidden Directory Creation via Unusual Parent
-
-In Linux environments, hidden directories, often prefixed with a dot, are typically used for configuration files but can be exploited by attackers to conceal malicious activities. Adversaries may create these directories using unexpected parent processes in sensitive locations. The detection rule identifies such anomalies by monitoring directory creation commands executed by unusual parent executables, focusing on specific directories and excluding known benign patterns.
-
-### Possible investigation steps
-
-- Review the process.parent.executable field to identify the parent process that initiated the directory creation and assess its legitimacy based on its typical behavior and location.
-- Examine the process.args field to understand the specific arguments used with the mkdir command, focusing on the directory path and any patterns that may indicate malicious intent.
-- Check the process.command_line field for any unusual or suspicious command-line patterns that might suggest an attempt to evade detection.
-- Investigate the context of the parent process by reviewing recent activities or logs associated with it, especially if it originates from sensitive directories like /dev/shm, /tmp, or /var/tmp.
-- Correlate the alert with other security events or logs from the same host to identify any related suspicious activities or patterns that could indicate a broader attack or compromise.
-- Consult threat intelligence sources or databases to determine if the parent executable or directory path has been associated with known malicious activities or threat actors.
-
-### False positive analysis
-
-- Temporary directories used by legitimate applications can trigger false positives. Exclude known benign parent executables like those in "/tmp/newroot/*" or "/run/containerd/*" to reduce noise.
-- Automated build processes may create hidden directories during software compilation. Add exceptions for parent executables such as "/var/tmp/buildah*" or "/tmp/python-build.*" to prevent unnecessary alerts.
-- Development tools and scripts might create hidden directories for caching or temporary storage. Consider excluding parent executables like "/tmp/pear/temp/*" or "/tmp/cliphist-wofi-img" if they are part of regular development activities.
-- Ensure that the command line patterns like "mkdir -p ." or "mkdir ./*" are excluded, as these are common in scripts and do not typically indicate malicious intent.
-- Regularly review and update the list of excluded patterns and parent executables to align with changes in the environment and reduce false positives effectively.
-
-### Response and remediation
-
-- Isolate the affected system from the network to prevent further malicious activity and lateral movement.
-- Terminate any suspicious processes associated with the unusual parent executable identified in the alert to halt potential malicious operations.
-- Conduct a thorough review of the hidden directory and its contents to identify and remove any malicious files or tools.
-- Restore any affected files or configurations from a known good backup to ensure system integrity.
-- Implement stricter access controls and monitoring on sensitive directories to prevent unauthorized directory creation.
-- Escalate the incident to the security operations team for further investigation and to determine if additional systems are compromised.
-- Update and enhance endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats in the future."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
-
 [[rule.threat.technique]]
 id = "T1564"
 name = "Hide Artifacts"
 reference = "https://attack.mitre.org/techniques/T1564/"
-
 [[rule.threat.technique.subtechnique]]
 id = "T1564.001"
 name = "Hidden Files and Directories"
 reference = "https://attack.mitre.org/techniques/T1564/001/"
 
+
+
 [rule.threat.tactic]
 id = "TA0005"
 name = "Defense Evasion"
 reference = "https://attack.mitre.org/tactics/TA0005/"
-
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 
@@ -139,3 +138,4 @@ framework = "MITRE ATT&CK"
 id = "TA0003"
 name = "Persistence"
 reference = "https://attack.mitre.org/tactics/TA0003/"
+

rules/linux/defense_evasion_hidden_shared_object.toml

@@ -2,9 +2,7 @@
 creation_date = "2022/07/20"
 integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
-min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-min_stack_version = "8.13.0"
-updated_date = "2025/02/04"
+updated_date = "2025/03/20"
 
 [rule]
 author = ["Elastic"]
@@ -19,6 +17,40 @@ language = "eql"
 license = "Elastic License v2"
 max_signals = 33
 name = "Creation of Hidden Shared Object 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 Creation of Hidden Shared Object File
+
+Shared object files (.so) are dynamic libraries used in Linux environments to provide reusable code. Adversaries may exploit the ability to hide files by prefixing them with a dot, concealing malicious .so files for persistence and evasion. The detection rule identifies the creation of such hidden files, excluding benign processes like Docker, to flag potential threats.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific hidden shared object file (.so) that was created, noting its full path and filename.
+- Investigate the process that created the file by examining the process name and its parent process, excluding "dockerd" as per the query, to determine if the process is legitimate or potentially malicious.
+- Check the file creation timestamp and correlate it with other system activities or logs to identify any suspicious behavior or patterns around the time of creation.
+- Analyze the contents of the hidden .so file, if accessible, to determine its purpose and whether it contains any malicious code or indicators of compromise.
+- Investigate the user account associated with the file creation event to assess if the account has been compromised or is involved in unauthorized activities.
+- Search for any other hidden files or suspicious activities on the system that may indicate a broader compromise or persistence mechanism.
+
+### False positive analysis
+
+- Development and testing environments may frequently create hidden .so files as part of routine operations. Users can mitigate this by excluding specific directories or processes known to be part of development workflows.
+- Backup or system maintenance scripts might generate hidden .so files temporarily. Identify and exclude these scripts or their associated processes to prevent false alerts.
+- Some legitimate software installations or updates may create hidden .so files as part of their setup process. Users should monitor installation logs and whitelist these processes if they are verified as non-threatening.
+- Custom applications or services that use hidden .so files for legitimate purposes should be documented, and their creation processes should be excluded from detection to avoid unnecessary alerts.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further spread or communication with potential command and control servers.
+- Terminate any suspicious processes associated with the creation of the hidden .so file, except for known benign processes like Docker.
+- Remove the hidden .so file from the system to eliminate the immediate threat. Ensure that the file is securely deleted to prevent recovery.
+- Conduct a thorough scan of the system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malicious files or artifacts.
+- Review system logs and process execution history to identify any unauthorized access or changes made around the time of the file creation. This can help in understanding the scope of the compromise.
+- 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 alerting for similar activities, such as the creation of hidden files, to improve detection and response times for future incidents."""
 risk_score = 47
 rule_id = "766d3f91-3f12-448c-b65f-20123e9e9e8c"
 setup = """## Setup
@@ -79,40 +111,6 @@ query = '''
 file where host.os.type == "linux" and event.type == "creation" and file.extension == "so" and file.name : ".*.so" and
 not process.name in ("dockerd", "azcopy", "podman")
 '''
-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 Creation of Hidden Shared Object File
-
-Shared object files (.so) are dynamic libraries used in Linux environments to provide reusable code. Adversaries may exploit the ability to hide files by prefixing them with a dot, concealing malicious .so files for persistence and evasion. The detection rule identifies the creation of such hidden files, excluding benign processes like Docker, to flag potential threats.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific hidden shared object file (.so) that was created, noting its full path and filename.
-- Investigate the process that created the file by examining the process name and its parent process, excluding "dockerd" as per the query, to determine if the process is legitimate or potentially malicious.
-- Check the file creation timestamp and correlate it with other system activities or logs to identify any suspicious behavior or patterns around the time of creation.
-- Analyze the contents of the hidden .so file, if accessible, to determine its purpose and whether it contains any malicious code or indicators of compromise.
-- Investigate the user account associated with the file creation event to assess if the account has been compromised or is involved in unauthorized activities.
-- Search for any other hidden files or suspicious activities on the system that may indicate a broader compromise or persistence mechanism.
-
-### False positive analysis
-
-- Development and testing environments may frequently create hidden .so files as part of routine operations. Users can mitigate this by excluding specific directories or processes known to be part of development workflows.
-- Backup or system maintenance scripts might generate hidden .so files temporarily. Identify and exclude these scripts or their associated processes to prevent false alerts.
-- Some legitimate software installations or updates may create hidden .so files as part of their setup process. Users should monitor installation logs and whitelist these processes if they are verified as non-threatening.
-- Custom applications or services that use hidden .so files for legitimate purposes should be documented, and their creation processes should be excluded from detection to avoid unnecessary alerts.
-
-### Response and remediation
-
-- Isolate the affected system from the network to prevent further spread or communication with potential command and control servers.
-- Terminate any suspicious processes associated with the creation of the hidden .so file, except for known benign processes like Docker.
-- Remove the hidden .so file from the system to eliminate the immediate threat. Ensure that the file is securely deleted to prevent recovery.
-- Conduct a thorough scan of the system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malicious files or artifacts.
-- Review system logs and process execution history to identify any unauthorized access or changes made around the time of the file creation. This can help in understanding the scope of the compromise.
-- 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 alerting for similar activities, such as the creation of hidden files, to improve detection and response times for future incidents."""
 
 
 [[rule.threat]]

rules/linux/defense_evasion_kernel_module_removal.toml

@@ -2,9 +2,7 @@
 creation_date = "2020/04/24"
 integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
-min_stack_version = "8.13.0"
-min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/02/04"
+updated_date = "2025/03/20"
 
 [rule]
 author = ["Elastic"]
@@ -20,10 +18,50 @@ false_positives = [
     """,
 ]
 from = "now-9m"
-index = ["endgame-*", "logs-crowdstrike.fdr*", "logs-endpoint.events.process*", "logs-sentinel_one_cloud_funnel.*"]
+index = [
+    "endgame-*",
+    "logs-crowdstrike.fdr*",
+    "logs-endpoint.events.process*",
+    "logs-sentinel_one_cloud_funnel.*",
+]
 language = "eql"
 license = "Elastic License v2"
 name = "Kernel Module Removal"
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
+
+### Investigating Kernel Module Removal
+
+Kernel modules dynamically extend a Linux kernel's capabilities without rebooting. Adversaries may exploit this by removing modules to disable security features or hide malicious activities. The detection rule identifies suspicious module removal attempts by monitoring processes like `rmmod` or `modprobe` with removal arguments, especially when initiated by common shell environments, indicating potential defense evasion tactics.
+
+### Possible investigation steps
+
+- Review the process details to confirm the execution of `rmmod` or `modprobe` with removal arguments. Check the command line arguments to ensure they match the suspicious activity criteria.
+- Identify the parent process of the suspicious activity, focusing on shell environments like `sudo`, `bash`, `dash`, `ash`, `sh`, `tcsh`, `csh`, `zsh`, `ksh`, or `fish`, to understand the context in which the module removal was initiated.
+- Investigate the user account associated with the process to determine if the activity aligns with expected behavior or if it indicates potential unauthorized access.
+- Check system logs and audit logs for any preceding or subsequent suspicious activities that might correlate with the module removal attempt, such as privilege escalation or other defense evasion tactics.
+- Assess the impact of the module removal on system security features and functionality, and determine if any critical security modules were targeted.
+- Review recent changes or updates to the system that might explain the module removal, such as legitimate maintenance or updates, to rule out false positives.
+
+### False positive analysis
+
+- Routine administrative tasks may trigger the rule when system administrators use `rmmod` or `modprobe` for legitimate maintenance. To handle this, create exceptions for specific user accounts or scripts known to perform these tasks regularly.
+- Automated scripts or configuration management tools that manage kernel modules might cause false positives. Identify these tools and exclude their processes from the rule to prevent unnecessary alerts.
+- Some Linux distributions or custom setups might use shell scripts that invoke `rmmod` or `modprobe` during system updates or package installations. Monitor these activities and whitelist the associated parent processes if they are verified as non-threatening.
+- Development environments where kernel module testing is frequent can generate alerts. Exclude specific development machines or user accounts involved in module testing to reduce noise.
+- Security tools that perform regular checks or updates on kernel modules might inadvertently trigger the rule. Verify these tools and add them to the exception list to avoid false positives.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or potential lateral movement by the adversary.
+- Terminate any suspicious processes identified as attempting to remove kernel modules, such as those initiated by `rmmod` or `modprobe` with removal arguments.
+- Conduct a thorough review of user accounts and privileges on the affected system to ensure no unauthorized access or privilege escalation has occurred.
+- Restore any disabled security features or kernel modules to their original state to ensure the system's defenses are intact.
+- Analyze system logs and audit trails to identify any additional indicators of compromise or related malicious activities.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if the threat is part of a larger attack campaign.
+- Implement enhanced monitoring and alerting for similar activities across the network to detect and respond to future attempts promptly."""
 references = ["http://man7.org/linux/man-pages/man8/modprobe.8.html"]
 risk_score = 47
 rule_id = "cd66a5af-e34b-4bb0-8931-57d0a043f2ef"
@@ -66,6 +104,7 @@ tags = [
 ]
 timestamp_override = "event.ingested"
 type = "eql"
+
 query = '''
 process where host.os.type == "linux" and event.type == "start" and
   event.action in ("exec", "exec_event", "start", "ProcessRollup2") and
@@ -75,74 +114,40 @@ process where host.os.type == "linux" and event.type == "start" and
   ) and
   process.parent.name in ("sudo", "bash", "dash", "ash", "sh", "tcsh", "csh", "zsh", "ksh", "fish")
 '''
-note = """## Triage and analysis
 
-> **Disclaimer**:
-> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
-
-### Investigating Kernel Module Removal
-
-Kernel modules dynamically extend a Linux kernel's capabilities without rebooting. Adversaries may exploit this by removing modules to disable security features or hide malicious activities. The detection rule identifies suspicious module removal attempts by monitoring processes like `rmmod` or `modprobe` with removal arguments, especially when initiated by common shell environments, indicating potential defense evasion tactics.
-
-### Possible investigation steps
-
-- Review the process details to confirm the execution of `rmmod` or `modprobe` with removal arguments. Check the command line arguments to ensure they match the suspicious activity criteria.
-- Identify the parent process of the suspicious activity, focusing on shell environments like `sudo`, `bash`, `dash`, `ash`, `sh`, `tcsh`, `csh`, `zsh`, `ksh`, or `fish`, to understand the context in which the module removal was initiated.
-- Investigate the user account associated with the process to determine if the activity aligns with expected behavior or if it indicates potential unauthorized access.
-- Check system logs and audit logs for any preceding or subsequent suspicious activities that might correlate with the module removal attempt, such as privilege escalation or other defense evasion tactics.
-- Assess the impact of the module removal on system security features and functionality, and determine if any critical security modules were targeted.
-- Review recent changes or updates to the system that might explain the module removal, such as legitimate maintenance or updates, to rule out false positives.
-
-### False positive analysis
-
-- Routine administrative tasks may trigger the rule when system administrators use `rmmod` or `modprobe` for legitimate maintenance. To handle this, create exceptions for specific user accounts or scripts known to perform these tasks regularly.
-- Automated scripts or configuration management tools that manage kernel modules might cause false positives. Identify these tools and exclude their processes from the rule to prevent unnecessary alerts.
-- Some Linux distributions or custom setups might use shell scripts that invoke `rmmod` or `modprobe` during system updates or package installations. Monitor these activities and whitelist the associated parent processes if they are verified as non-threatening.
-- Development environments where kernel module testing is frequent can generate alerts. Exclude specific development machines or user accounts involved in module testing to reduce noise.
-- Security tools that perform regular checks or updates on kernel modules might inadvertently trigger the rule. Verify these tools and add them to the exception list to avoid false positives.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or potential lateral movement by the adversary.
-- Terminate any suspicious processes identified as attempting to remove kernel modules, such as those initiated by `rmmod` or `modprobe` with removal arguments.
-- Conduct a thorough review of user accounts and privileges on the affected system to ensure no unauthorized access or privilege escalation has occurred.
-- Restore any disabled security features or kernel modules to their original state to ensure the system's defenses are intact.
-- Analyze system logs and audit trails to identify any additional indicators of compromise or related malicious activities.
-- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if the threat is part of a larger attack campaign.
-- Implement enhanced monitoring and alerting for similar activities across the network to detect and respond to future attempts promptly."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
-
 [[rule.threat.technique]]
 id = "T1562"
 name = "Impair Defenses"
 reference = "https://attack.mitre.org/techniques/T1562/"
-
 [[rule.threat.technique.subtechnique]]
 id = "T1562.001"
 name = "Disable or Modify Tools"
 reference = "https://attack.mitre.org/techniques/T1562/001/"
 
+
+
 [rule.threat.tactic]
 id = "TA0005"
 name = "Defense Evasion"
 reference = "https://attack.mitre.org/tactics/TA0005/"
-
 [[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/linux/defense_evasion_kthreadd_masquerading.toml

@@ -2,9 +2,7 @@
 creation_date = "2024/02/01"
 integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
-min_stack_version = "8.13.0"
-min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/02/04"
+updated_date = "2025/03/20"
 
 [rule]
 author = ["Elastic"]
@@ -14,10 +12,49 @@ as kthreadd and kworker typically do not have process.executable fields associat
 hide their malicious programs by masquerading as legitimate kernel processes.
 """
 from = "now-9m"
-index = ["endgame-*", "logs-crowdstrike.fdr*", "logs-endpoint.events.process*", "logs-sentinel_one_cloud_funnel.*"]
+index = [
+    "endgame-*",
+    "logs-crowdstrike.fdr*",
+    "logs-endpoint.events.process*",
+    "logs-sentinel_one_cloud_funnel.*",
+]
 language = "eql"
 license = "Elastic License v2"
 name = "Executable Masquerading as Kernel Process"
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
+
+### Investigating Executable Masquerading as Kernel Process
+
+In Linux environments, kernel processes like `kthreadd` and `kworker` typically run without associated executable paths. Adversaries exploit this by naming malicious executables after these processes to evade detection. The detection rule identifies anomalies by flagging kernel-named processes with non-empty executable fields, indicating potential masquerading attempts. This helps in uncovering stealthy threats that mimic legitimate system activities.
+
+### Possible investigation steps
+
+- Review the process details for the flagged process, focusing on the process.executable field to identify the path and name of the executable. This can provide initial insights into whether the executable is legitimate or potentially malicious.
+- Check the process's parent process (process.parent) to understand the context in which the process was started. This can help determine if the process was spawned by a legitimate system process or a suspicious one.
+- Investigate the file at the path specified in the process.executable field. Verify its legitimacy by checking its hash against known malware databases or using a file reputation service.
+- Examine the process's command line arguments (process.command_line) for any unusual or suspicious parameters that might indicate malicious activity.
+- Review recent system logs and events around the time the process was started to identify any related activities or anomalies that could provide additional context or evidence of compromise.
+- If available, use threat intelligence sources to check for any known indicators of compromise (IOCs) related to the process name or executable path.
+
+### False positive analysis
+
+- Custom scripts or administrative tools may be named similarly to kernel processes for convenience or organizational standards. Review these scripts and tools to ensure they are legitimate and consider adding them to an exception list if verified.
+- Some legitimate software or monitoring tools might use kernel-like names for their processes to integrate closely with system operations. Verify the source and purpose of these processes and exclude them if they are confirmed to be non-malicious.
+- System updates or patches might temporarily create processes with kernel-like names that have executable paths. Monitor these occurrences and exclude them if they are part of a verified update process.
+- Development or testing environments may intentionally use kernel-like names for process simulation. Ensure these environments are isolated and add exceptions for these processes if they are part of controlled testing scenarios.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further spread of the potential threat and to contain any malicious activity.
+- Terminate the suspicious process immediately to stop any ongoing malicious actions. Use process management tools to kill the process identified by the alert.
+- Conduct a forensic analysis of the affected system to identify any additional indicators of compromise (IOCs) and assess the extent of the intrusion.
+- Remove any malicious executables or files associated with the masquerading process from the system to ensure complete remediation.
+- Restore the system from a known good backup if the integrity of the system is compromised, ensuring that the backup is free from any malicious artifacts.
+- Update and patch the system to close any vulnerabilities that may have been exploited by the attacker, ensuring all software and security tools are up to date.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected."""
 references = ["https://sandflysecurity.com/blog/linux-stealth-rootkit-malware-with-edr-evasion-analyzed/"]
 risk_score = 21
 rule_id = "202829f6-0271-4e88-b882-11a655c590d4"
@@ -66,40 +103,6 @@ query = '''
 process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start", "ProcessRollup2") and
 process.name : ("kworker*", "kthread*") and 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 Executable Masquerading as Kernel Process
-
-In Linux environments, kernel processes like `kthreadd` and `kworker` typically run without associated executable paths. Adversaries exploit this by naming malicious executables after these processes to evade detection. The detection rule identifies anomalies by flagging kernel-named processes with non-empty executable fields, indicating potential masquerading attempts. This helps in uncovering stealthy threats that mimic legitimate system activities.
-
-### Possible investigation steps
-
-- Review the process details for the flagged process, focusing on the process.executable field to identify the path and name of the executable. This can provide initial insights into whether the executable is legitimate or potentially malicious.
-- Check the process's parent process (process.parent) to understand the context in which the process was started. This can help determine if the process was spawned by a legitimate system process or a suspicious one.
-- Investigate the file at the path specified in the process.executable field. Verify its legitimacy by checking its hash against known malware databases or using a file reputation service.
-- Examine the process's command line arguments (process.command_line) for any unusual or suspicious parameters that might indicate malicious activity.
-- Review recent system logs and events around the time the process was started to identify any related activities or anomalies that could provide additional context or evidence of compromise.
-- If available, use threat intelligence sources to check for any known indicators of compromise (IOCs) related to the process name or executable path.
-
-### False positive analysis
-
-- Custom scripts or administrative tools may be named similarly to kernel processes for convenience or organizational standards. Review these scripts and tools to ensure they are legitimate and consider adding them to an exception list if verified.
-- Some legitimate software or monitoring tools might use kernel-like names for their processes to integrate closely with system operations. Verify the source and purpose of these processes and exclude them if they are confirmed to be non-malicious.
-- System updates or patches might temporarily create processes with kernel-like names that have executable paths. Monitor these occurrences and exclude them if they are part of a verified update process.
-- Development or testing environments may intentionally use kernel-like names for process simulation. Ensure these environments are isolated and add exceptions for these processes if they are part of controlled testing scenarios.
-
-### Response and remediation
-
-- Isolate the affected system from the network to prevent further spread of the potential threat and to contain any malicious activity.
-- Terminate the suspicious process immediately to stop any ongoing malicious actions. Use process management tools to kill the process identified by the alert.
-- Conduct a forensic analysis of the affected system to identify any additional indicators of compromise (IOCs) and assess the extent of the intrusion.
-- Remove any malicious executables or files associated with the masquerading process from the system to ensure complete remediation.
-- Restore the system from a known good backup if the integrity of the system is compromised, ensuring that the backup is free from any malicious artifacts.
-- Update and patch the system to close any vulnerabilities that may have been exploited by the attacker, ensuring all software and security tools are up to date.
-- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected."""
 
 
 [[rule.threat]]

rules/linux/defense_evasion_ld_so_creation.toml

@@ -2,9 +2,7 @@
 creation_date = "2024/12/16"
 integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
-min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-min_stack_version = "8.13.0"
-updated_date = "2025/01/15"
+updated_date = "2025/03/20"
 
 [rule]
 author = ["Elastic"]
@@ -18,6 +16,42 @@ index = ["logs-endpoint.events.file*", "logs-sentinel_one_cloud_funnel.*", "endg
 language = "eql"
 license = "Elastic License v2"
 name = "Dynamic Linker (ld.so) 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 Dynamic Linker (ld.so) Creation
+
+The dynamic linker, ld.so, is crucial in Linux environments for loading shared libraries required by executables. Adversaries may exploit this by replacing it with a malicious version to execute unauthorized code, achieving persistence or evading defenses. The detection rule identifies suspicious creation of ld.so files, excluding benign processes, to flag potential threats.
+
+### Possible investigation steps
+
+- Review the process that triggered the alert by examining the process.executable field to understand which application attempted to create the ld.so file.
+- Check the process.name field to ensure the process is not one of the benign processes listed in the exclusion criteria, such as "dockerd", "yum", "dnf", "microdnf", or "pacman".
+- Investigate the file.path to confirm the location of the newly created ld.so file and verify if it matches any of the specified directories like "/lib", "/lib64", "/usr/lib", or "/usr/lib64".
+- Analyze the parent process of the suspicious executable to determine if it was initiated by a legitimate or potentially malicious source.
+- Look for any recent changes or anomalies in the system logs around the time of the file creation event to identify any related suspicious activities.
+- Cross-reference the event with other security tools or logs, such as Elastic Defend or SentinelOne, to gather additional context or corroborating evidence of malicious activity.
+- Assess the risk and impact of the event by considering the system's role and the potential consequences of a compromised dynamic linker on that system.
+
+### False positive analysis
+
+- Package managers like yum, dnf, microdnf, and pacman can trigger false positives when they update or install packages that involve the dynamic linker. These processes are already excluded in the rule, but ensure any custom package managers or scripts are also considered for exclusion.
+- Container management tools such as dockerd may create or modify ld.so files during container operations. If you use other container tools, consider adding them to the exclusion list to prevent false positives.
+- System updates or maintenance scripts that involve library updates might create ld.so files. Review these scripts and add them to the exclusion list if they are verified as non-threatening.
+- Custom administrative scripts or automation tools that interact with shared libraries could inadvertently trigger the rule. Identify these scripts and exclude them if they are part of regular, secure operations.
+- Development environments where ld.so files are frequently created or modified during testing and compilation processes may need specific exclusions for development tools or environments to avoid false positives.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
+- Verify the integrity of the dynamic linker (ld.so) on the affected system by comparing it with a known good version from a trusted source or repository.
+- If the dynamic linker has been tampered with, replace it with the verified version and ensure all system binaries are intact.
+- Conduct a thorough scan of the system using updated antivirus or endpoint detection tools to identify and remove any additional malicious files or processes.
+- Review system logs and the process creation history to identify the source of the unauthorized ld.so creation and any associated malicious activity.
+- 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 additional monitoring and alerting for similar suspicious activities, such as unauthorized file creations in critical system directories, to enhance future detection capabilities."""
 risk_score = 21
 rule_id = "06d555e4-c8ce-4d90-90e1-ec7f66df5a6a"
 setup = """## Setup
@@ -60,93 +94,58 @@ tags = [
 ]
 timestamp_override = "event.ingested"
 type = "eql"
+
 query = '''
 file where host.os.type == "linux" and event.type == "creation" and process.executable != null and
 file.path like~ ("/lib/ld-linux*.so*", "/lib64/ld-linux*.so*", "/usr/lib/ld-linux*.so*", "/usr/lib64/ld-linux*.so*") and
 not process.name in ("dockerd", "yum", "dnf", "microdnf", "pacman")
 '''
-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 Dynamic Linker (ld.so) Creation
-
-The dynamic linker, ld.so, is crucial in Linux environments for loading shared libraries required by executables. Adversaries may exploit this by replacing it with a malicious version to execute unauthorized code, achieving persistence or evading defenses. The detection rule identifies suspicious creation of ld.so files, excluding benign processes, to flag potential threats.
-
-### Possible investigation steps
-
-- Review the process that triggered the alert by examining the process.executable field to understand which application attempted to create the ld.so file.
-- Check the process.name field to ensure the process is not one of the benign processes listed in the exclusion criteria, such as "dockerd", "yum", "dnf", "microdnf", or "pacman".
-- Investigate the file.path to confirm the location of the newly created ld.so file and verify if it matches any of the specified directories like "/lib", "/lib64", "/usr/lib", or "/usr/lib64".
-- Analyze the parent process of the suspicious executable to determine if it was initiated by a legitimate or potentially malicious source.
-- Look for any recent changes or anomalies in the system logs around the time of the file creation event to identify any related suspicious activities.
-- Cross-reference the event with other security tools or logs, such as Elastic Defend or SentinelOne, to gather additional context or corroborating evidence of malicious activity.
-- Assess the risk and impact of the event by considering the system's role and the potential consequences of a compromised dynamic linker on that system.
-
-### False positive analysis
-
-- Package managers like yum, dnf, microdnf, and pacman can trigger false positives when they update or install packages that involve the dynamic linker. These processes are already excluded in the rule, but ensure any custom package managers or scripts are also considered for exclusion.
-- Container management tools such as dockerd may create or modify ld.so files during container operations. If you use other container tools, consider adding them to the exclusion list to prevent false positives.
-- System updates or maintenance scripts that involve library updates might create ld.so files. Review these scripts and add them to the exclusion list if they are verified as non-threatening.
-- Custom administrative scripts or automation tools that interact with shared libraries could inadvertently trigger the rule. Identify these scripts and exclude them if they are part of regular, secure operations.
-- Development environments where ld.so files are frequently created or modified during testing and compilation processes may need specific exclusions for development tools or environments to avoid false positives.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
-- Verify the integrity of the dynamic linker (ld.so) on the affected system by comparing it with a known good version from a trusted source or repository.
-- If the dynamic linker has been tampered with, replace it with the verified version and ensure all system binaries are intact.
-- Conduct a thorough scan of the system using updated antivirus or endpoint detection tools to identify and remove any additional malicious files or processes.
-- Review system logs and the process creation history to identify the source of the unauthorized ld.so creation and any associated malicious activity.
-- 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 additional monitoring and alerting for similar suspicious activities, such as unauthorized file creations in critical system directories, to enhance future detection capabilities."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1218"
+name = "System Binary Proxy Execution"
+reference = "https://attack.mitre.org/techniques/T1218/"
 
-  [rule.threat.tactic]
-  name = "Defense Evasion"
-  id = "TA0005"
-  reference = "https://attack.mitre.org/tactics/TA0005/"
-
-    [[rule.threat.technique]]
-    id = "T1218"
-    name = "System Binary Proxy Execution"
-    reference = "https://attack.mitre.org/techniques/T1218/"
 
+[rule.threat.tactic]
+id = "TA0005"
+name = "Defense Evasion"
+reference = "https://attack.mitre.org/tactics/TA0005/"
 [[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]
-  name = "Execution"
-  id = "TA0002"
-  reference = "https://attack.mitre.org/tactics/TA0002/"
 
-    [[rule.threat.technique]]
-    id = "T1059"
-    name = "Command and Scripting Interpreter"
-    reference = "https://attack.mitre.org/techniques/T1059/"
-
-      [[rule.threat.technique.subtechnique]]
-      name = "Unix Shell"
-      id = "T1059.004"
-      reference = "https://attack.mitre.org/techniques/T1059/004/"
 
+[rule.threat.tactic]
+id = "TA0002"
+name = "Execution"
+reference = "https://attack.mitre.org/tactics/TA0002/"
 [[rule.threat]]
 framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1574"
+name = "Hijack Execution Flow"
+reference = "https://attack.mitre.org/techniques/T1574/"
+[[rule.threat.technique.subtechnique]]
+id = "T1574.006"
+name = "Dynamic Linker Hijacking"
+reference = "https://attack.mitre.org/techniques/T1574/006/"
 
-  [rule.threat.tactic]
-  name = "Persistence"
-  id = "TA0003"
-  reference = "https://attack.mitre.org/tactics/TA0003/"
 
-    [[rule.threat.technique]]
-    name = "Hijack Execution Flow"
-    id = "T1574"
-    reference = "https://attack.mitre.org/techniques/T1574/"
 
-      [[rule.threat.technique.subtechnique]]
-      name = "Dynamic Linker Hijacking"
-      id = "T1574.006"
-      reference = "https://attack.mitre.org/techniques/T1574/006/"
+[rule.threat.tactic]
+id = "TA0003"
+name = "Persistence"
+reference = "https://attack.mitre.org/tactics/TA0003/"
+

rules/linux/defense_evasion_log_files_deleted.toml

@@ -2,9 +2,7 @@
 creation_date = "2020/11/03"
 integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
-min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-min_stack_version = "8.13.0"
-updated_date = "2025/02/04"
+updated_date = "2025/03/20"
 
 [rule]
 author = ["Elastic"]
@@ -17,6 +15,41 @@ index = ["auditbeat-*", "endgame-*", "logs-endpoint.events.file*", "logs-sentine
 language = "eql"
 license = "Elastic License v2"
 name = "System Log File Deletion"
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
+
+### Investigating System Log File Deletion
+
+System logs are crucial for monitoring and auditing activities on Linux systems, providing insights into system events and user actions. Adversaries may delete these logs to cover their tracks, hindering forensic investigations. The detection rule identifies suspicious deletions of key log files, excluding benign processes like compression tools, to flag potential evasion attempts. This helps security analysts quickly respond to and investigate unauthorized log deletions.
+
+### Possible investigation steps
+
+- Review the specific file path involved in the deletion event to determine which log file was targeted, using the file.path field from the alert.
+- Investigate the process responsible for the deletion by examining the process.name and related process metadata to identify any suspicious or unauthorized activity.
+- Check for any recent login or session activity around the time of the log deletion by reviewing other logs or authentication records, focusing on the /var/log/auth.log and /var/log/secure files if they are still available.
+- Analyze the user account associated with the deletion event to determine if it has a history of suspicious activity or if it was potentially compromised.
+- Correlate the deletion event with other security alerts or anomalies in the system to identify any patterns or related incidents that might indicate a broader attack or compromise.
+- Assess the impact of the log deletion on the system's security posture and determine if any critical forensic evidence has been lost, considering the importance of the deleted log file.
+
+### False positive analysis
+
+- Compression tools like gzip may trigger false positives when they temporarily delete log files during compression. To mitigate this, ensure gzip is included in the exclusion list within the detection rule.
+- Automated system maintenance scripts might delete or rotate log files as part of routine operations. Review these scripts and add their process names to the exclusion list if they are verified as non-threatening.
+- Docker-related processes, such as dockerd, can also cause false positives when managing container logs. Confirm these activities are legitimate and include dockerd in the exclusion list to prevent unnecessary alerts.
+- Custom backup or log management tools may delete logs as part of their normal function. Identify these tools and add their process names to the exclusion list after verifying their benign nature.
+- Scheduled tasks or cron jobs that manage log files should be reviewed. If they are confirmed to be safe, their associated process names should be added to the exclusion list to avoid false positives.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or data tampering.
+- Conduct a thorough review of user accounts and permissions on the affected system to identify any unauthorized access or privilege escalation.
+- Restore deleted log files from backups if available, to aid in further forensic analysis and to maintain system integrity.
+- Implement enhanced monitoring on the affected system and similar systems to detect any further unauthorized log deletions or suspicious activities.
+- Escalate the incident to the security operations center (SOC) or incident response team for a comprehensive investigation and to determine the scope of the breach.
+- Review and update security policies and configurations to ensure that only authorized processes can delete critical log files, leveraging access controls and audit policies.
+- Consider deploying additional endpoint detection and response (EDR) solutions to improve visibility and detection capabilities for similar threats in the future."""
 references = [
     "https://www.fireeye.com/blog/threat-research/2020/11/live-off-the-land-an-overview-of-unc1945.html",
     "https://www.elastic.co/security-labs/detecting-log4j2-with-elastic-security",
@@ -96,41 +129,6 @@ file where host.os.type == "linux" and event.type == "deletion" and
     ) and
     not process.name in ("gzip", "executor", "dockerd")
 '''
-note = """## Triage and analysis
-
-> **Disclaimer**:
-> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
-
-### Investigating System Log File Deletion
-
-System logs are crucial for monitoring and auditing activities on Linux systems, providing insights into system events and user actions. Adversaries may delete these logs to cover their tracks, hindering forensic investigations. The detection rule identifies suspicious deletions of key log files, excluding benign processes like compression tools, to flag potential evasion attempts. This helps security analysts quickly respond to and investigate unauthorized log deletions.
-
-### Possible investigation steps
-
-- Review the specific file path involved in the deletion event to determine which log file was targeted, using the file.path field from the alert.
-- Investigate the process responsible for the deletion by examining the process.name and related process metadata to identify any suspicious or unauthorized activity.
-- Check for any recent login or session activity around the time of the log deletion by reviewing other logs or authentication records, focusing on the /var/log/auth.log and /var/log/secure files if they are still available.
-- Analyze the user account associated with the deletion event to determine if it has a history of suspicious activity or if it was potentially compromised.
-- Correlate the deletion event with other security alerts or anomalies in the system to identify any patterns or related incidents that might indicate a broader attack or compromise.
-- Assess the impact of the log deletion on the system's security posture and determine if any critical forensic evidence has been lost, considering the importance of the deleted log file.
-
-### False positive analysis
-
-- Compression tools like gzip may trigger false positives when they temporarily delete log files during compression. To mitigate this, ensure gzip is included in the exclusion list within the detection rule.
-- Automated system maintenance scripts might delete or rotate log files as part of routine operations. Review these scripts and add their process names to the exclusion list if they are verified as non-threatening.
-- Docker-related processes, such as dockerd, can also cause false positives when managing container logs. Confirm these activities are legitimate and include dockerd in the exclusion list to prevent unnecessary alerts.
-- Custom backup or log management tools may delete logs as part of their normal function. Identify these tools and add their process names to the exclusion list after verifying their benign nature.
-- Scheduled tasks or cron jobs that manage log files should be reviewed. If they are confirmed to be safe, their associated process names should be added to the exclusion list to avoid false positives.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or data tampering.
-- Conduct a thorough review of user accounts and permissions on the affected system to identify any unauthorized access or privilege escalation.
-- Restore deleted log files from backups if available, to aid in further forensic analysis and to maintain system integrity.
-- Implement enhanced monitoring on the affected system and similar systems to detect any further unauthorized log deletions or suspicious activities.
-- Escalate the incident to the security operations center (SOC) or incident response team for a comprehensive investigation and to determine the scope of the breach.
-- Review and update security policies and configurations to ensure that only authorized processes can delete critical log files, leveraging access controls and audit policies.
-- Consider deploying additional endpoint detection and response (EDR) solutions to improve visibility and detection capabilities for similar threats in the future."""
 
 
 [[rule.threat]]

rules/linux/defense_evasion_mount_execution.toml

@@ -2,9 +2,7 @@
 creation_date = "2023/04/11"
 integration = ["endpoint", "auditd_manager", "sentinel_one_cloud_funnel"]
 maturity = "production"
-min_stack_version = "8.13.0"
-min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/02/04"
+updated_date = "2025/03/20"
 
 [rule]
 author = ["Elastic"]
@@ -18,10 +16,51 @@ hidepid option all the user has to do is remount the /proc filesystem with the o
 detected.
 """
 from = "now-9m"
-index = ["auditbeat-*", "endgame-*", "logs-auditd_manager.auditd-*", "logs-endpoint.events.process*", "logs-sentinel_one_cloud_funnel.*"]
+index = [
+    "auditbeat-*",
+    "endgame-*",
+    "logs-auditd_manager.auditd-*",
+    "logs-endpoint.events.process*",
+    "logs-sentinel_one_cloud_funnel.*",
+]
 language = "eql"
 license = "Elastic License v2"
 name = "Potential Hidden Process via Mount Hidepid"
+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 Hidden Process via Mount Hidepid
+
+The 'hidepid' mount option in Linux allows users to restrict visibility of process information in the /proc filesystem, enhancing privacy by limiting process visibility to the owner. Adversaries exploit this by remounting /proc with 'hidepid=2', concealing their processes from non-root users and evading detection tools like ps or top. The detection rule identifies such activity by monitoring for the execution of the mount command with specific arguments, flagging potential misuse for further investigation.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of the 'mount' process execution with arguments indicating '/proc' and 'hidepid=2'.
+- Check the user account associated with the process execution to determine if it is a legitimate administrative user or a potential adversary.
+- Investigate the parent process of the 'mount' command to understand the context and origin of the execution, ensuring it is not part of a known or legitimate administrative script.
+- Examine recent login activity and user sessions on the host to identify any unauthorized access or suspicious behavior around the time of the alert.
+- Analyze other processes running on the system to identify any hidden or suspicious activities that might be related to the use of 'hidepid=2'.
+- Review system logs and audit logs for any additional indicators of compromise or related suspicious activities that coincide with the alert.
+
+### False positive analysis
+
+- System administrators or automated scripts may remount /proc with hidepid=2 for legitimate privacy or security reasons. To handle this, create exceptions for known administrative scripts or users by excluding their specific command lines or user IDs.
+- Some security tools or monitoring solutions might use hidepid=2 as part of their normal operation to enhance system security. Identify these tools and exclude their processes from triggering alerts by adding them to an allowlist.
+- Cloud environments or containerized applications might use hidepid=2 to isolate processes for multi-tenant security. Review the environment's standard operating procedures and exclude these known behaviors from detection.
+- Regular system updates or maintenance scripts might temporarily use hidepid=2. Document these occurrences and adjust the detection rule to ignore these specific maintenance windows or scripts.
+- If using a specific Linux distribution that employs hidepid=2 by default for certain operations, verify these defaults and configure the detection rule to exclude them.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
+- Use root privileges to remount the /proc filesystem without the 'hidepid=2' option to restore visibility of all processes.
+- Conduct a thorough review of running processes and system logs to identify any unauthorized or suspicious activities that may have been concealed.
+- Terminate any identified malicious processes and remove any associated files or scripts from the system.
+- Change all system and user passwords to prevent unauthorized access, especially if credential theft is suspected.
+- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected.
+- Implement enhanced monitoring and alerting for future attempts to use the 'hidepid' option, ensuring rapid detection and response."""
 references = ["https://www.cyberciti.biz/faq/linux-hide-processes-from-other-users/"]
 risk_score = 47
 rule_id = "dc71c186-9fe4-4437-a4d0-85ebb32b8204"
@@ -64,57 +103,25 @@ tags = [
 ]
 timestamp_override = "event.ingested"
 type = "eql"
+
 query = '''
 process where host.os.type == "linux" and event.type == "start" and
   event.action in ("exec", "exec_event", "start", "executed", "process_started") and
   process.name == "mount" and process.args == "/proc" and process.args == "-o" and process.args : "*hidepid=2*" and
   not process.parent.command_line like "/opt/cloudlinux/*"
 '''
-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 Hidden Process via Mount Hidepid
-
-The 'hidepid' mount option in Linux allows users to restrict visibility of process information in the /proc filesystem, enhancing privacy by limiting process visibility to the owner. Adversaries exploit this by remounting /proc with 'hidepid=2', concealing their processes from non-root users and evading detection tools like ps or top. The detection rule identifies such activity by monitoring for the execution of the mount command with specific arguments, flagging potential misuse for further investigation.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the presence of the 'mount' process execution with arguments indicating '/proc' and 'hidepid=2'.
-- Check the user account associated with the process execution to determine if it is a legitimate administrative user or a potential adversary.
-- Investigate the parent process of the 'mount' command to understand the context and origin of the execution, ensuring it is not part of a known or legitimate administrative script.
-- Examine recent login activity and user sessions on the host to identify any unauthorized access or suspicious behavior around the time of the alert.
-- Analyze other processes running on the system to identify any hidden or suspicious activities that might be related to the use of 'hidepid=2'.
-- Review system logs and audit logs for any additional indicators of compromise or related suspicious activities that coincide with the alert.
-
-### False positive analysis
-
-- System administrators or automated scripts may remount /proc with hidepid=2 for legitimate privacy or security reasons. To handle this, create exceptions for known administrative scripts or users by excluding their specific command lines or user IDs.
-- Some security tools or monitoring solutions might use hidepid=2 as part of their normal operation to enhance system security. Identify these tools and exclude their processes from triggering alerts by adding them to an allowlist.
-- Cloud environments or containerized applications might use hidepid=2 to isolate processes for multi-tenant security. Review the environment's standard operating procedures and exclude these known behaviors from detection.
-- Regular system updates or maintenance scripts might temporarily use hidepid=2. Document these occurrences and adjust the detection rule to ignore these specific maintenance windows or scripts.
-- If using a specific Linux distribution that employs hidepid=2 by default for certain operations, verify these defaults and configure the detection rule to exclude them.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
-- Use root privileges to remount the /proc filesystem without the 'hidepid=2' option to restore visibility of all processes.
-- Conduct a thorough review of running processes and system logs to identify any unauthorized or suspicious activities that may have been concealed.
-- Terminate any identified malicious processes and remove any associated files or scripts from the system.
-- Change all system and user passwords to prevent unauthorized access, especially if credential theft is suspected.
-- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected.
-- Implement enhanced monitoring and alerting for future attempts to use the 'hidepid' option, ensuring rapid detection and response."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
-
 [[rule.threat.technique]]
 id = "T1564"
 name = "Hide Artifacts"
 reference = "https://attack.mitre.org/techniques/T1564/"
 
+
 [rule.threat.tactic]
 id = "TA0005"
 name = "Defense Evasion"
 reference = "https://attack.mitre.org/tactics/TA0005/"
+

rules/linux/defense_evasion_potential_proot_exploits.toml

@@ -2,9 +2,7 @@
 creation_date = "2023/03/07"
 integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
-min_stack_version = "8.13.0"
-min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/02/04"
+updated_date = "2025/03/20"
 
 [rule]
 author = ["Elastic"]
@@ -20,10 +18,48 @@ malicious payload or elevate privileges or perform network scans or orchestrate
 Although PRoot was originally not developed with malicious intent it can be easily tuned to work for one.
 """
 from = "now-9m"
-index = ["endgame-*", "logs-crowdstrike.fdr*", "logs-endpoint.events.process*", "logs-sentinel_one_cloud_funnel.*"]
+index = [
+    "endgame-*",
+    "logs-crowdstrike.fdr*",
+    "logs-endpoint.events.process*",
+    "logs-sentinel_one_cloud_funnel.*",
+]
 language = "eql"
 license = "Elastic License v2"
 name = "Potential Defense Evasion via PRoot"
+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 Defense Evasion via PRoot
+
+PRoot is a versatile tool that emulates a chroot-like environment, allowing users to run applications across different Linux distributions seamlessly. Adversaries exploit PRoot to create consistent environments for executing malicious payloads, bypassing traditional defenses. The detection rule identifies suspicious PRoot activity by monitoring process executions initiated by PRoot, flagging potential misuse for defense evasion.
+
+### Possible investigation steps
+
+- Review the process tree to identify the parent process of PRoot and any child processes it spawned, focusing on the process.parent.name field to confirm PRoot as the parent.
+- Examine the command line arguments used with PRoot to understand the context of its execution and identify any potentially malicious payloads or scripts being executed.
+- Check the user account associated with the PRoot process to determine if it aligns with expected usage patterns or if it indicates potential compromise.
+- Investigate the network activity associated with the PRoot process to identify any unusual connections or data transfers that could suggest malicious intent.
+- Correlate the PRoot activity with other security alerts or logs to identify any related suspicious behavior or indicators of compromise within the same timeframe.
+
+### False positive analysis
+
+- Legitimate use of PRoot for cross-distribution development or testing environments may trigger alerts. Users can create exceptions for known development teams or specific projects that require PRoot for legitimate purposes.
+- System administrators using PRoot for system maintenance or migration tasks might be flagged. To mitigate this, document and whitelist these activities by correlating them with scheduled maintenance windows or specific administrator accounts.
+- Security researchers or penetration testers employing PRoot for controlled testing scenarios could cause false positives. Establish a process to identify and exclude these activities by verifying the involved personnel and their testing scope.
+- Automated scripts or tools that utilize PRoot for non-malicious purposes, such as software compatibility testing, should be reviewed. Implement a tagging system to differentiate these benign activities from potential threats, allowing for easier exclusion in future detections.
+
+### Response and remediation
+
+- Isolate the affected system immediately to prevent further spread of the threat across the network. Disconnect it from the network and any shared resources.
+- Terminate any suspicious processes initiated by PRoot to halt any ongoing malicious activities. Use process management tools to identify and kill these processes.
+- Conduct a thorough examination of the filesystem for any unauthorized changes or suspicious files that may have been introduced by the adversary using PRoot.
+- Restore the system from a known good backup if any malicious modifications are detected, ensuring that the backup is free from compromise.
+- Update and patch the affected system to the latest security standards to close any vulnerabilities that may have been exploited.
+- Implement enhanced monitoring for PRoot activity across the environment to detect any future unauthorized use. This includes setting up alerts for any process executions with PRoot as the parent process.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected."""
 references = ["https://proot-me.github.io/"]
 risk_score = 47
 rule_id = "5c9ec990-37fa-4d5c-abfc-8d432f3dedd0"
@@ -71,39 +107,6 @@ query = '''
 process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start", "ProcessRollup2") and
 process.parent.name == "proot"
 '''
-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 Defense Evasion via PRoot
-
-PRoot is a versatile tool that emulates a chroot-like environment, allowing users to run applications across different Linux distributions seamlessly. Adversaries exploit PRoot to create consistent environments for executing malicious payloads, bypassing traditional defenses. The detection rule identifies suspicious PRoot activity by monitoring process executions initiated by PRoot, flagging potential misuse for defense evasion.
-
-### Possible investigation steps
-
-- Review the process tree to identify the parent process of PRoot and any child processes it spawned, focusing on the process.parent.name field to confirm PRoot as the parent.
-- Examine the command line arguments used with PRoot to understand the context of its execution and identify any potentially malicious payloads or scripts being executed.
-- Check the user account associated with the PRoot process to determine if it aligns with expected usage patterns or if it indicates potential compromise.
-- Investigate the network activity associated with the PRoot process to identify any unusual connections or data transfers that could suggest malicious intent.
-- Correlate the PRoot activity with other security alerts or logs to identify any related suspicious behavior or indicators of compromise within the same timeframe.
-
-### False positive analysis
-
-- Legitimate use of PRoot for cross-distribution development or testing environments may trigger alerts. Users can create exceptions for known development teams or specific projects that require PRoot for legitimate purposes.
-- System administrators using PRoot for system maintenance or migration tasks might be flagged. To mitigate this, document and whitelist these activities by correlating them with scheduled maintenance windows or specific administrator accounts.
-- Security researchers or penetration testers employing PRoot for controlled testing scenarios could cause false positives. Establish a process to identify and exclude these activities by verifying the involved personnel and their testing scope.
-- Automated scripts or tools that utilize PRoot for non-malicious purposes, such as software compatibility testing, should be reviewed. Implement a tagging system to differentiate these benign activities from potential threats, allowing for easier exclusion in future detections.
-
-### Response and remediation
-
-- Isolate the affected system immediately to prevent further spread of the threat across the network. Disconnect it from the network and any shared resources.
-- Terminate any suspicious processes initiated by PRoot to halt any ongoing malicious activities. Use process management tools to identify and kill these processes.
-- Conduct a thorough examination of the filesystem for any unauthorized changes or suspicious files that may have been introduced by the adversary using PRoot.
-- Restore the system from a known good backup if any malicious modifications are detected, ensuring that the backup is free from compromise.
-- Update and patch the affected system to the latest security standards to close any vulnerabilities that may have been exploited.
-- Implement enhanced monitoring for PRoot activity across the environment to detect any future unauthorized use. This includes setting up alerts for any process executions with PRoot as the parent process.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected."""
 
 
 [[rule.threat]]

rules/linux/defense_evasion_root_certificate_installation.toml

@@ -2,9 +2,7 @@
 creation_date = "2024/08/28"
 integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
-min_stack_version = "8.13.0"
-min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/24"
+updated_date = "2025/03/20"
 
 [rule]
 author = ["Elastic"]
@@ -12,14 +10,52 @@ description = """
 This rule detects the installation of root certificates on a Linux system. Adversaries may install a root certificate on
 a compromised system to avoid warnings when connecting to their command and control servers. Root certificates are used
 in public key cryptography to identify a root certificate authority (CA). When a root certificate is installed, the
-system or application will trust certificates in the root's chain of trust that have been signed by the root certificate.
+system or application will trust certificates in the root's chain of trust that have been signed by the root
+certificate.
 """
 from = "now-9m"
 index = ["logs-endpoint.events.process*", "logs-sentinel_one_cloud_funnel.*", "endgame-*"]
 language = "eql"
 license = "Elastic License v2"
 name = "Root Certificate Installation"
-references = ["https://github.com/redcanaryco/atomic-red-team/blob/f339e7da7d05f6057fdfcdd3742bfcf365fee2a9/atomics/T1553.004/T1553.004.md"]
+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 Root Certificate Installation
+
+Root certificates are pivotal in establishing trust within public key infrastructures, enabling secure communications by verifying the authenticity of entities. Adversaries exploit this by installing rogue root certificates on compromised Linux systems, thus bypassing security warnings and facilitating undetected command and control communications. The detection rule identifies suspicious certificate installations by monitoring specific processes and excluding legitimate parent processes, thereby highlighting potential unauthorized activities.
+
+### Possible investigation steps
+
+- Review the process details to confirm the execution of "update-ca-trust" or "update-ca-certificates" on the Linux host, focusing on the event type "start" and action "exec" or "exec_event".
+- Examine the parent process name and arguments to ensure they do not match any of the legitimate exclusions such as "ca-certificates.postinst", "pacman", or "/var/tmp/rpm*".
+- Investigate the user account associated with the process to determine if it is a known or expected user for such operations.
+- Check the system logs and recent changes to identify any unauthorized modifications or installations that coincide with the alert.
+- Correlate the alert with other security events or logs to identify any potential command and control communications or other suspicious activities on the host.
+- Assess the network connections from the host around the time of the alert to detect any unusual or unauthorized outbound traffic.
+
+### False positive analysis
+
+- Legitimate system updates or package installations may trigger the rule when processes like "update-ca-trust" or "update-ca-certificates" are executed by trusted package managers such as "pacman" or "pamac-daemon". To mitigate this, ensure these parent processes are included in the exclusion list.
+- Automated scripts or system maintenance tasks that use shell scripts (e.g., "sh", "bash", "zsh") to update certificates might be flagged. If these scripts are verified as safe, consider adding specific script names or paths to the exclusion criteria.
+- Custom applications or services that require certificate updates and are known to be safe can be excluded by adding their parent process names to the exclusion list, ensuring they do not trigger false alerts.
+- Security tools or agents like "kesl" or "execd" that manage certificates as part of their operations may cause false positives. Verify their activities and include them in the exclusion list if they are part of legitimate security operations.
+- Temporary files or scripts located in directories like "/var/tmp/rpm*" used during legitimate installations should be reviewed and excluded if they are part of routine system operations.
+
+### Response and remediation
+
+- Immediately isolate the affected Linux system from the network to prevent further unauthorized communications with potential command and control servers.
+- Revoke any unauthorized root certificates installed on the system by removing them from the trusted certificate store to restore the integrity of the system's trust chain.
+- Conduct a thorough review of system logs and process execution history to identify any additional unauthorized activities or changes made by the adversary.
+- Restore the system from a known good backup if unauthorized changes or persistent threats are detected that cannot be easily remediated.
+- Update and patch the system to the latest security standards to close any vulnerabilities that may have been exploited by the adversary.
+- Implement enhanced monitoring and alerting for similar suspicious activities, focusing on process executions related to certificate management.
+- Escalate the incident to the security operations center (SOC) or relevant incident response team for further investigation and to assess the potential impact on other systems within the network."""
+references = [
+    "https://github.com/redcanaryco/atomic-red-team/blob/f339e7da7d05f6057fdfcdd3742bfcf365fee2a9/atomics/T1553.004/T1553.004.md",
+]
 risk_score = 47
 rule_id = "6ded0996-7d4b-40f2-bf4a-6913e7591795"
 setup = """## Setup
@@ -60,6 +96,7 @@ tags = [
 ]
 timestamp_override = "event.ingested"
 type = "eql"
+
 query = '''
 process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start") and
 process.name in ("update-ca-trust", "update-ca-certificates") and not (
@@ -71,56 +108,23 @@ process.name in ("update-ca-trust", "update-ca-certificates") and not (
   (process.parent.name in ("sh", "bash", "zsh") and process.args == "-e")
 )
 '''
-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 Root Certificate Installation
-
-Root certificates are pivotal in establishing trust within public key infrastructures, enabling secure communications by verifying the authenticity of entities. Adversaries exploit this by installing rogue root certificates on compromised Linux systems, thus bypassing security warnings and facilitating undetected command and control communications. The detection rule identifies suspicious certificate installations by monitoring specific processes and excluding legitimate parent processes, thereby highlighting potential unauthorized activities.
-
-### Possible investigation steps
-
-- Review the process details to confirm the execution of "update-ca-trust" or "update-ca-certificates" on the Linux host, focusing on the event type "start" and action "exec" or "exec_event".
-- Examine the parent process name and arguments to ensure they do not match any of the legitimate exclusions such as "ca-certificates.postinst", "pacman", or "/var/tmp/rpm*".
-- Investigate the user account associated with the process to determine if it is a known or expected user for such operations.
-- Check the system logs and recent changes to identify any unauthorized modifications or installations that coincide with the alert.
-- Correlate the alert with other security events or logs to identify any potential command and control communications or other suspicious activities on the host.
-- Assess the network connections from the host around the time of the alert to detect any unusual or unauthorized outbound traffic.
-
-### False positive analysis
-
-- Legitimate system updates or package installations may trigger the rule when processes like "update-ca-trust" or "update-ca-certificates" are executed by trusted package managers such as "pacman" or "pamac-daemon". To mitigate this, ensure these parent processes are included in the exclusion list.
-- Automated scripts or system maintenance tasks that use shell scripts (e.g., "sh", "bash", "zsh") to update certificates might be flagged. If these scripts are verified as safe, consider adding specific script names or paths to the exclusion criteria.
-- Custom applications or services that require certificate updates and are known to be safe can be excluded by adding their parent process names to the exclusion list, ensuring they do not trigger false alerts.
-- Security tools or agents like "kesl" or "execd" that manage certificates as part of their operations may cause false positives. Verify their activities and include them in the exclusion list if they are part of legitimate security operations.
-- Temporary files or scripts located in directories like "/var/tmp/rpm*" used during legitimate installations should be reviewed and excluded if they are part of routine system operations.
-
-### Response and remediation
-
-- Immediately isolate the affected Linux system from the network to prevent further unauthorized communications with potential command and control servers.
-- Revoke any unauthorized root certificates installed on the system by removing them from the trusted certificate store to restore the integrity of the system's trust chain.
-- Conduct a thorough review of system logs and process execution history to identify any additional unauthorized activities or changes made by the adversary.
-- Restore the system from a known good backup if unauthorized changes or persistent threats are detected that cannot be easily remediated.
-- Update and patch the system to the latest security standards to close any vulnerabilities that may have been exploited by the adversary.
-- Implement enhanced monitoring and alerting for similar suspicious activities, focusing on process executions related to certificate management.
-- Escalate the incident to the security operations center (SOC) or relevant incident response team for further investigation and to assess the potential impact on other systems within the network."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
-
 [[rule.threat.technique]]
 id = "T1553"
 name = "Subvert Trust Controls"
 reference = "https://attack.mitre.org/techniques/T1553/"
-
 [[rule.threat.technique.subtechnique]]
 id = "T1553.004"
 name = "Install Root Certificate"
 reference = "https://attack.mitre.org/techniques/T1553/004/"
 
+
+
 [rule.threat.tactic]
 id = "TA0005"
 name = "Defense Evasion"
 reference = "https://attack.mitre.org/tactics/TA0005/"
+

rules/linux/defense_evasion_ssl_certificate_deletion.toml

@@ -2,9 +2,7 @@
 creation_date = "2024/08/28"
 integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
-min_stack_version = "8.13.0"
-min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/15"
+updated_date = "2025/03/20"
 
 [rule]
 author = ["Elastic"]
@@ -17,6 +15,40 @@ index = ["logs-endpoint.events.file*", "logs-sentinel_one_cloud_funnel.*", "endg
 language = "eql"
 license = "Elastic License v2"
 name = "SSL Certificate Deletion"
+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 SSL Certificate Deletion
+SSL certificates are crucial for establishing secure communications in Linux environments. Adversaries may delete these certificates to undermine trust and disrupt system operations, often as part of defense evasion tactics. The detection rule identifies suspicious deletions by monitoring specific directories for certificate files, excluding benign processes, thus highlighting potential malicious activity.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the file path and extension of the deleted SSL certificate, ensuring it matches the pattern "/etc/ssl/certs/*" with extensions "pem" or "crt".
+- Identify the process responsible for the deletion by examining the process name and compare it against the exclusion list (e.g., "dockerd", "pacman") to determine if the process is potentially malicious.
+- Investigate the user account associated with the process that performed the deletion to assess if the account has a history of suspicious activity or unauthorized access.
+- Check system logs and audit trails around the time of the deletion event to identify any related activities or anomalies that could indicate a broader attack or compromise.
+- Assess the impact of the certificate deletion on system operations and security, including any disruptions to secure communications or trust relationships.
+- If the deletion is deemed suspicious, consider restoring the deleted certificate from backups and implementing additional monitoring to detect further unauthorized deletions.
+
+### False positive analysis
+
+- Routine system updates or package installations may trigger certificate deletions. Exclude processes like package managers or update services that are known to perform these actions.
+- Automated certificate renewal services might delete old certificates as part of their renewal process. Identify and exclude these services to prevent false alerts.
+- Custom scripts or maintenance tasks that manage SSL certificates could be flagged. Review and whitelist these scripts if they are verified as non-malicious.
+- Backup or cleanup operations that involve certificate files might cause false positives. Ensure these operations are recognized and excluded from monitoring.
+- Development or testing environments where certificates are frequently added and removed can generate alerts. Consider excluding these environments if they are isolated and secure.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or damage.
+- Verify the deletion of SSL certificates by checking the specified directories and confirm the absence of expected certificate files.
+- Restore deleted SSL certificates from a secure backup to re-establish secure communications and trust controls.
+- Conduct a thorough review of system logs and process activity to identify the source of the deletion and any associated malicious activity.
+- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected.
+- Implement additional monitoring on the affected system and similar environments to detect any further unauthorized deletions or related suspicious activities.
+- Review and update access controls and permissions to ensure only authorized processes and users can modify or delete SSL certificates."""
 risk_score = 21
 rule_id = "7957f3b9-f590-4062-b9f9-003c32bfc7d6"
 setup = """## Setup
@@ -58,77 +90,45 @@ tags = [
 ]
 timestamp_override = "event.ingested"
 type = "eql"
+
 query = '''
 file where host.os.type == "linux" and event.type == "deletion" and file.path : "/etc/ssl/certs/*" and
 file.extension in ("pem", "crt") and not process.name in ("dockerd", "pacman")
 '''
-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 SSL Certificate Deletion
-SSL certificates are crucial for establishing secure communications in Linux environments. Adversaries may delete these certificates to undermine trust and disrupt system operations, often as part of defense evasion tactics. The detection rule identifies suspicious deletions by monitoring specific directories for certificate files, excluding benign processes, thus highlighting potential malicious activity.
-
-### Possible investigation steps
-
-- Review the alert details to confirm the file path and extension of the deleted SSL certificate, ensuring it matches the pattern "/etc/ssl/certs/*" with extensions "pem" or "crt".
-- Identify the process responsible for the deletion by examining the process name and compare it against the exclusion list (e.g., "dockerd", "pacman") to determine if the process is potentially malicious.
-- Investigate the user account associated with the process that performed the deletion to assess if the account has a history of suspicious activity or unauthorized access.
-- Check system logs and audit trails around the time of the deletion event to identify any related activities or anomalies that could indicate a broader attack or compromise.
-- Assess the impact of the certificate deletion on system operations and security, including any disruptions to secure communications or trust relationships.
-- If the deletion is deemed suspicious, consider restoring the deleted certificate from backups and implementing additional monitoring to detect further unauthorized deletions.
-
-### False positive analysis
-
-- Routine system updates or package installations may trigger certificate deletions. Exclude processes like package managers or update services that are known to perform these actions.
-- Automated certificate renewal services might delete old certificates as part of their renewal process. Identify and exclude these services to prevent false alerts.
-- Custom scripts or maintenance tasks that manage SSL certificates could be flagged. Review and whitelist these scripts if they are verified as non-malicious.
-- Backup or cleanup operations that involve certificate files might cause false positives. Ensure these operations are recognized and excluded from monitoring.
-- Development or testing environments where certificates are frequently added and removed can generate alerts. Consider excluding these environments if they are isolated and secure.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or damage.
-- Verify the deletion of SSL certificates by checking the specified directories and confirm the absence of expected certificate files.
-- Restore deleted SSL certificates from a secure backup to re-establish secure communications and trust controls.
-- Conduct a thorough review of system logs and process activity to identify the source of the deletion and any associated malicious activity.
-- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected.
-- Implement additional monitoring on the affected system and similar environments to detect any further unauthorized deletions or related suspicious activities.
-- Review and update access controls and permissions to ensure only authorized processes and users can modify or delete SSL certificates."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
-
 [[rule.threat.technique]]
 id = "T1070"
 name = "Indicator Removal"
 reference = "https://attack.mitre.org/techniques/T1070/"
-
 [[rule.threat.technique.subtechnique]]
 id = "T1070.004"
 name = "File Deletion"
 reference = "https://attack.mitre.org/techniques/T1070/004/"
 
+
 [[rule.threat.technique]]
 id = "T1553"
 name = "Subvert Trust Controls"
 reference = "https://attack.mitre.org/techniques/T1553/"
 
+
 [rule.threat.tactic]
 id = "TA0005"
 name = "Defense Evasion"
 reference = "https://attack.mitre.org/tactics/TA0005/"
-
 [[rule.threat]]
 framework = "MITRE ATT&CK"
-
 [[rule.threat.technique]]
 id = "T1485"
 name = "Data Destruction"
 reference = "https://attack.mitre.org/techniques/T1485/"
 
+
 [rule.threat.tactic]
 id = "TA0040"
 name = "Impact"
 reference = "https://attack.mitre.org/tactics/TA0040/"
+

rules/linux/defense_evasion_sus_utility_executed_via_tmux_or_screen.toml

@@ -2,9 +2,7 @@
 creation_date = "2023/09/04"
 integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
-min_stack_version = "8.13.0"
-min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/02/04"
+updated_date = "2025/03/20"
 
 [rule]
 author = ["Elastic"]
@@ -14,34 +12,15 @@ directly, the commands will be executed in the background via its parent process
 to execute commands while attempting to evade detection.
 """
 from = "now-9m"
-index = ["endgame-*", "logs-crowdstrike.fdr*", "logs-endpoint.events.process*", "logs-sentinel_one_cloud_funnel.*"]
+index = [
+    "endgame-*",
+    "logs-crowdstrike.fdr*",
+    "logs-endpoint.events.process*",
+    "logs-sentinel_one_cloud_funnel.*",
+]
 language = "eql"
 license = "Elastic License v2"
 name = "Potentially Suspicious Process Started via tmux or screen"
-risk_score = 21
-rule_id = "e0cc3807-e108-483c-bf66-5a4fbe0d7e89"
-severity = "low"
-tags = [
-    "Domain: Endpoint",
-    "OS: Linux",
-    "Use Case: Threat Detection",
-    "Tactic: Defense Evasion",
-    "Data Source: Elastic Defend",
-    "Data Source: Elastic Endgame",
-    "Data Source: Crowdstrike",
-    "Data Source: SentinelOne",
-    "Resources: Investigation Guide",
-]
-timestamp_override = "event.ingested"
-type = "eql"
-query = '''
-process where host.os.type == "linux" and event.type == "start" and
-  event.action in ("exec", "exec_event", "start", "ProcessRollup2") and
-  process.parent.name in ("screen", "tmux") and process.name like (
-    "nmap", "nc", "ncat", "netcat", "socat", "nc.openbsd", "ngrok", "ping", "java", "php*", "perl", "ruby", "lua*",
-    "openssl", "telnet", "wget", "curl", "id"
-  )
-'''
 note = """## Triage and analysis
 
 > **Disclaimer**:
@@ -76,16 +55,43 @@ Tmux and screen are terminal multiplexers that allow users to manage multiple te
 - Escalate the incident to the security operations team for further investigation and to determine if additional systems are compromised.
 - Implement network monitoring to detect any unusual outbound connections or data exfiltration attempts from the affected host.
 - Update and enhance detection rules to include additional suspicious command patterns or behaviors observed during the investigation."""
+risk_score = 21
+rule_id = "e0cc3807-e108-483c-bf66-5a4fbe0d7e89"
+severity = "low"
+tags = [
+    "Domain: Endpoint",
+    "OS: Linux",
+    "Use Case: Threat Detection",
+    "Tactic: Defense Evasion",
+    "Data Source: Elastic Defend",
+    "Data Source: Elastic Endgame",
+    "Data Source: Crowdstrike",
+    "Data Source: SentinelOne",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "eql"
+
+query = '''
+process where host.os.type == "linux" and event.type == "start" and
+  event.action in ("exec", "exec_event", "start", "ProcessRollup2") and
+  process.parent.name in ("screen", "tmux") and process.name like (
+    "nmap", "nc", "ncat", "netcat", "socat", "nc.openbsd", "ngrok", "ping", "java", "php*", "perl", "ruby", "lua*",
+    "openssl", "telnet", "wget", "curl", "id"
+  )
+'''
+
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
-
 [[rule.threat.technique]]
 id = "T1218"
 name = "System Binary Proxy Execution"
 reference = "https://attack.mitre.org/techniques/T1218/"
 
+
 [rule.threat.tactic]
 id = "TA0005"
 name = "Defense Evasion"
 reference = "https://attack.mitre.org/tactics/TA0005/"
+

rules/linux/discovery_docker_socket_discovery.toml

@@ -2,21 +2,26 @@
 creation_date = "2025/03/04"
 integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
-min_stack_version = "8.13.0"
-min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/03/04"
+updated_date = "2025/03/20"
 
 [rule]
 author = ["Elastic"]
 description = """
-This rule detects potential Docker socket enumeration activity by monitoring processes that attempt to interact with
-the Docker socket file (/var/run/docker.sock). Docker socket enumeration is a common technique used by attackers to
-interact with the Docker daemon and perform various operations, such as creating, starting, stopping, and removing
-containers. Attackers may abuse Docker socket enumeration to gain unauthorized access to the host system, escalate
-privileges, or move laterally within the environment.
+This rule detects potential Docker socket enumeration activity by monitoring processes that attempt to interact with the
+Docker socket file (/var/run/docker.sock). Docker socket enumeration is a common technique used by attackers to interact
+with the Docker daemon and perform various operations, such as creating, starting, stopping, and removing containers.
+Attackers may abuse Docker socket enumeration to gain unauthorized access to the host system, escalate privileges, or
+move laterally within the environment.
 """
 from = "now-9m"
-index = ["auditbeat-*", "endgame-*", "logs-auditd_manager.auditd-*", "logs-crowdstrike.fdr*", "logs-endpoint.events.process*", "logs-sentinel_one_cloud_funnel.*"]
+index = [
+    "auditbeat-*",
+    "endgame-*",
+    "logs-auditd_manager.auditd-*",
+    "logs-crowdstrike.fdr*",
+    "logs-endpoint.events.process*",
+    "logs-sentinel_one_cloud_funnel.*",
+]
 language = "eql"
 license = "Elastic License v2"
 name = "Docker Socket Enumeration"
@@ -58,10 +63,11 @@ tags = [
     "Data Source: Elastic Endgame",
     "Data Source: Auditd Manager",
     "Data Source: Crowdstrike",
-    "Data Source: SentinelOne"
+    "Data Source: SentinelOne",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
+
 query = '''
 process where host.os.type == "linux" and event.type == "start" and
 event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and
@@ -69,15 +75,17 @@ process.name in ("curl", "socat", "nc", "netcat", "ncat", "nc.traditional") and
 process.command_line like ("*/var/run/docker.sock*", "*/run/docker.sock*")
 '''
 
+
 [[rule.threat]]
 framework = "MITRE ATT&CK"
-
 [[rule.threat.technique]]
 id = "T1613"
 name = "Container and Resource Discovery"
 reference = "https://attack.mitre.org/techniques/T1613/"
 
+
 [rule.threat.tactic]
 id = "TA0007"
 name = "Discovery"
 reference = "https://attack.mitre.org/tactics/TA0007/"
+

rules/linux/discovery_dynamic_linker_via_od.toml

@@ -2,9 +2,7 @@
 creation_date = "2024/02/01"
 integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
-min_stack_version = "8.13.0"
-min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/02/04"
+updated_date = "2025/03/20"
 
 [rule]
 author = ["Elastic"]
@@ -15,10 +13,50 @@ for examining and debugging binary files or data streams. Attackers can leverage
 identifying injection points and craft exploits based on the observed behaviors and structures within these files.
 """
 from = "now-9m"
-index = ["auditbeat-*", "endgame-*", "logs-auditd_manager.auditd-*", "logs-crowdstrike.fdr*", "logs-endpoint.events.process*", "logs-sentinel_one_cloud_funnel.*"]
+index = [
+    "auditbeat-*",
+    "endgame-*",
+    "logs-auditd_manager.auditd-*",
+    "logs-crowdstrike.fdr*",
+    "logs-endpoint.events.process*",
+    "logs-sentinel_one_cloud_funnel.*",
+]
 language = "eql"
 license = "Elastic License v2"
 name = "Suspicious Dynamic Linker Discovery via od"
+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 Dynamic Linker Discovery via od
+
+The dynamic linker in Linux environments is crucial for loading shared libraries needed by programs. Attackers may exploit the `od` utility to inspect these linkers, seeking vulnerabilities for code injection. The detection rule identifies suspicious use of `od` targeting specific linker files, flagging potential reconnaissance activities that could precede an exploit attempt.
+
+### Possible investigation steps
+
+- Review the process execution details to confirm the use of the 'od' utility, focusing on the process name and arguments to ensure they match the suspicious patterns identified in the query.
+- Investigate the user account associated with the process execution to determine if the activity aligns with their typical behavior or if it appears anomalous.
+- Check the system's process execution history for any other unusual or related activities around the same time, such as attempts to access or modify linker files.
+- Analyze any network connections or data transfers initiated by the host around the time of the alert to identify potential data exfiltration or communication with known malicious IPs.
+- Correlate this event with other security alerts or logs from the same host to identify patterns or sequences of actions that could indicate a broader attack campaign.
+
+### False positive analysis
+
+- System administrators or developers may use the od utility to inspect dynamic linker files for legitimate debugging or system maintenance purposes. To handle this, create exceptions for known user accounts or processes that regularly perform these activities.
+- Automated scripts or monitoring tools might invoke od on dynamic linker files as part of routine system checks. Identify these scripts and whitelist their execution paths to prevent unnecessary alerts.
+- Security researchers or penetration testers could use od during authorized security assessments. Establish a process to temporarily disable the rule or add exceptions for the duration of the assessment to avoid false positives.
+- Some software installations or updates might involve the use of od to verify linker integrity. Monitor installation logs and correlate with od usage to determine if the activity is benign, and consider adding exceptions for these specific scenarios.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent potential lateral movement or further exploitation.
+- Terminate any suspicious processes associated with the `od` utility that are targeting dynamic linker files to halt any ongoing reconnaissance or exploitation attempts.
+- Conduct a thorough review of system logs and process execution history to identify any unauthorized access or modifications to the dynamic linker files.
+- Restore any altered or compromised dynamic linker files from a known good backup to ensure system integrity.
+- Implement stricter access controls and monitoring on critical system files, including dynamic linkers, to prevent unauthorized access and modifications.
+- Escalate the incident to the security operations team for further analysis and to determine if additional systems are affected or if there is a broader threat campaign.
+- Update detection and monitoring systems to enhance visibility and alerting for similar suspicious activities involving the `od` utility and critical system files."""
 references = ["https://github.com/arget13/DDexec"]
 risk_score = 21
 rule_id = "0369e8a6-0fa7-4e7a-961a-53180a4c966e"
@@ -71,39 +109,6 @@ process where host.os.type == "linux" and event.type == "start" and event.action
   "/usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2", "/usr/lib64/ld-linux-x86-64.so.2"
 )
 '''
-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 Dynamic Linker Discovery via od
-
-The dynamic linker in Linux environments is crucial for loading shared libraries needed by programs. Attackers may exploit the `od` utility to inspect these linkers, seeking vulnerabilities for code injection. The detection rule identifies suspicious use of `od` targeting specific linker files, flagging potential reconnaissance activities that could precede an exploit attempt.
-
-### Possible investigation steps
-
-- Review the process execution details to confirm the use of the 'od' utility, focusing on the process name and arguments to ensure they match the suspicious patterns identified in the query.
-- Investigate the user account associated with the process execution to determine if the activity aligns with their typical behavior or if it appears anomalous.
-- Check the system's process execution history for any other unusual or related activities around the same time, such as attempts to access or modify linker files.
-- Analyze any network connections or data transfers initiated by the host around the time of the alert to identify potential data exfiltration or communication with known malicious IPs.
-- Correlate this event with other security alerts or logs from the same host to identify patterns or sequences of actions that could indicate a broader attack campaign.
-
-### False positive analysis
-
-- System administrators or developers may use the od utility to inspect dynamic linker files for legitimate debugging or system maintenance purposes. To handle this, create exceptions for known user accounts or processes that regularly perform these activities.
-- Automated scripts or monitoring tools might invoke od on dynamic linker files as part of routine system checks. Identify these scripts and whitelist their execution paths to prevent unnecessary alerts.
-- Security researchers or penetration testers could use od during authorized security assessments. Establish a process to temporarily disable the rule or add exceptions for the duration of the assessment to avoid false positives.
-- Some software installations or updates might involve the use of od to verify linker integrity. Monitor installation logs and correlate with od usage to determine if the activity is benign, and consider adding exceptions for these specific scenarios.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent potential lateral movement or further exploitation.
-- Terminate any suspicious processes associated with the `od` utility that are targeting dynamic linker files to halt any ongoing reconnaissance or exploitation attempts.
-- Conduct a thorough review of system logs and process execution history to identify any unauthorized access or modifications to the dynamic linker files.
-- Restore any altered or compromised dynamic linker files from a known good backup to ensure system integrity.
-- Implement stricter access controls and monitoring on critical system files, including dynamic linkers, to prevent unauthorized access and modifications.
-- Escalate the incident to the security operations team for further analysis and to determine if additional systems are affected or if there is a broader threat campaign.
-- Update detection and monitoring systems to enhance visibility and alerting for similar suspicious activities involving the `od` utility and critical system files."""
 
 
 [[rule.threat]]

rules/linux/discovery_esxi_software_via_find.toml

@@ -2,9 +2,7 @@
 creation_date = "2023/04/11"
 integration = ["endpoint", "auditd_manager", "sentinel_one_cloud_funnel"]
 maturity = "production"
-min_stack_version = "8.13.0"
-min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/02/04"
+updated_date = "2025/03/20"
 
 [rule]
 author = ["Elastic"]
@@ -15,10 +13,50 @@ software, and their presence in the find command arguments may indicate that a t
 analyze, or manipulate VM-related files and configurations on the system.
 """
 from = "now-9m"
-index = ["auditbeat-*", "endgame-*", "logs-auditd_manager.auditd-*", "logs-endpoint.events.process*", "logs-sentinel_one_cloud_funnel.*"]
+index = [
+    "auditbeat-*",
+    "endgame-*",
+    "logs-auditd_manager.auditd-*",
+    "logs-endpoint.events.process*",
+    "logs-sentinel_one_cloud_funnel.*",
+]
 language = "eql"
 license = "Elastic License v2"
 name = "ESXI Discovery via Find"
+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 ESXI Discovery via Find
+
+VMware ESXi is a hypervisor used to deploy and manage virtual machines. Adversaries may exploit the 'find' command on Linux systems to locate VM-related files, potentially to gather information or manipulate configurations. The detection rule identifies suspicious 'find' command executions targeting VMware paths, excluding legitimate processes, to flag potential reconnaissance activities.
+
+### Possible investigation steps
+
+- Review the process execution details to confirm the 'find' command was executed with arguments targeting VMware paths such as "/etc/vmware/*", "/usr/lib/vmware/*", or "/vmfs/*".
+- Check the parent process of the 'find' command to ensure it is not "/usr/lib/vmware/viewagent/bin/uninstall_viewagent.sh", which is excluded from the rule as a legitimate process.
+- Investigate the user account associated with the 'find' command execution to determine if it is a known and authorized user for VMware management tasks.
+- Examine recent login and access logs for the user account to identify any unusual or unauthorized access patterns.
+- Correlate this event with other security alerts or logs to identify if there are additional signs of reconnaissance or unauthorized activity on the system.
+- Assess the system's current state and configuration to ensure no unauthorized changes have been made to VMware-related files or settings.
+
+### False positive analysis
+
+- Legitimate administrative tasks may trigger the rule if system administrators use the 'find' command to audit or manage VMware-related files. To handle this, create exceptions for known administrative scripts or user accounts that regularly perform these tasks.
+- Automated backup or monitoring scripts that scan VMware directories can also cause false positives. Identify these scripts and exclude their parent processes from the detection rule.
+- Software updates or maintenance activities involving VMware components might execute the 'find' command in a non-threatening manner. Consider scheduling these activities during known maintenance windows and temporarily adjusting the rule to prevent unnecessary alerts.
+- If the 'find' command is part of a legitimate software installation or uninstallation process, such as the VMware View Agent uninstallation, ensure these processes are whitelisted by adding their parent executable paths to the exception list.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Terminate any suspicious 'find' processes identified in the alert to halt potential reconnaissance activities.
+- Conduct a thorough review of the system's recent command history and logs to identify any unauthorized access or changes made to VM-related files.
+- Restore any altered or deleted VM-related files from a known good backup to ensure system integrity.
+- Update and patch the VMware ESXi and related software to the latest versions to mitigate any known vulnerabilities.
+- Implement stricter access controls and monitoring on VMware-related directories to prevent unauthorized access in the future.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected."""
 references = [
     "https://www.bleepingcomputer.com/news/security/massive-esxiargs-ransomware-attack-targets-vmware-esxi-servers-worldwide/",
 ]
@@ -63,56 +101,25 @@ tags = [
 ]
 timestamp_override = "event.ingested"
 type = "eql"
+
 query = '''
 process where host.os.type == "linux" and event.type == "start" and
   event.action in ("exec", "exec_event", "start", "executed", "process_started") and
   process.name == "find" and process.args : ("/etc/vmware/*", "/usr/lib/vmware/*", "/vmfs/*") and
   not process.parent.executable == "/usr/lib/vmware/viewagent/bin/uninstall_viewagent.sh"
 '''
-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 ESXI Discovery via Find
-
-VMware ESXi is a hypervisor used to deploy and manage virtual machines. Adversaries may exploit the 'find' command on Linux systems to locate VM-related files, potentially to gather information or manipulate configurations. The detection rule identifies suspicious 'find' command executions targeting VMware paths, excluding legitimate processes, to flag potential reconnaissance activities.
-
-### Possible investigation steps
-
-- Review the process execution details to confirm the 'find' command was executed with arguments targeting VMware paths such as "/etc/vmware/*", "/usr/lib/vmware/*", or "/vmfs/*".
-- Check the parent process of the 'find' command to ensure it is not "/usr/lib/vmware/viewagent/bin/uninstall_viewagent.sh", which is excluded from the rule as a legitimate process.
-- Investigate the user account associated with the 'find' command execution to determine if it is a known and authorized user for VMware management tasks.
-- Examine recent login and access logs for the user account to identify any unusual or unauthorized access patterns.
-- Correlate this event with other security alerts or logs to identify if there are additional signs of reconnaissance or unauthorized activity on the system.
-- Assess the system's current state and configuration to ensure no unauthorized changes have been made to VMware-related files or settings.
-
-### False positive analysis
-
-- Legitimate administrative tasks may trigger the rule if system administrators use the 'find' command to audit or manage VMware-related files. To handle this, create exceptions for known administrative scripts or user accounts that regularly perform these tasks.
-- Automated backup or monitoring scripts that scan VMware directories can also cause false positives. Identify these scripts and exclude their parent processes from the detection rule.
-- Software updates or maintenance activities involving VMware components might execute the 'find' command in a non-threatening manner. Consider scheduling these activities during known maintenance windows and temporarily adjusting the rule to prevent unnecessary alerts.
-- If the 'find' command is part of a legitimate software installation or uninstallation process, such as the VMware View Agent uninstallation, ensure these processes are whitelisted by adding their parent executable paths to the exception list.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
-- Terminate any suspicious 'find' processes identified in the alert to halt potential reconnaissance activities.
-- Conduct a thorough review of the system's recent command history and logs to identify any unauthorized access or changes made to VM-related files.
-- Restore any altered or deleted VM-related files from a known good backup to ensure system integrity.
-- Update and patch the VMware ESXi and related software to the latest versions to mitigate any known vulnerabilities.
-- Implement stricter access controls and monitoring on VMware-related directories to prevent unauthorized access in the future.
-- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
-
 [[rule.threat.technique]]
 id = "T1518"
 name = "Software Discovery"
 reference = "https://attack.mitre.org/techniques/T1518/"
 
+
 [rule.threat.tactic]
 id = "TA0007"
 name = "Discovery"
 reference = "https://attack.mitre.org/tactics/TA0007/"
+

rules/linux/discovery_esxi_software_via_grep.toml

@@ -2,9 +2,7 @@
 creation_date = "2023/04/11"
 integration = ["endpoint", "auditd_manager", "sentinel_one_cloud_funnel"]
 maturity = "production"
-min_stack_version = "8.13.0"
-min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/02/04"
+updated_date = "2025/03/20"
 
 [rule]
 author = ["Elastic"]
@@ -15,10 +13,49 @@ related to virtual machine (VM) files, such as "vmdk", "vmx", "vmxf", "vmsd", "v
 may indicate that a threat actor is attempting to search for, analyze, or manipulate VM files on the system.
 """
 from = "now-9m"
-index = ["auditbeat-*", "endgame-*", "logs-auditd_manager.auditd-*", "logs-endpoint.events.process*", "logs-sentinel_one_cloud_funnel.*"]
+index = [
+    "auditbeat-*",
+    "endgame-*",
+    "logs-auditd_manager.auditd-*",
+    "logs-endpoint.events.process*",
+    "logs-sentinel_one_cloud_funnel.*",
+]
 language = "eql"
 license = "Elastic License v2"
 name = "ESXI Discovery via Grep"
+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 ESXI Discovery via Grep
+
+In Linux environments, tools like 'grep' are used to search through files for specific patterns. Adversaries may exploit these tools to locate and analyze virtual machine files, which are crucial for ESXi environments. The detection rule identifies suspicious use of 'grep' variants targeting VM file extensions, signaling potential reconnaissance or manipulation attempts by threat actors. This rule helps in early detection of such malicious activities by monitoring process execution patterns.
+
+### Possible investigation steps
+
+- Review the process execution details to confirm the presence of 'grep', 'egrep', or 'pgrep' with arguments related to VM file extensions such as "vmdk", "vmx", "vmxf", "vmsd", "vmsn", "vswp", "vmss", "nvram", or "vmem".
+- Check the parent process of the suspicious 'grep' command to determine if it is a legitimate process or potentially malicious, ensuring it is not "/usr/share/qemu/init/qemu-kvm-init".
+- Investigate the user account associated with the process execution to assess if the activity aligns with their typical behavior or if it appears anomalous.
+- Examine recent system logs and other security alerts for additional indicators of compromise or related suspicious activities on the host.
+- Assess the network activity from the host to identify any unusual connections or data exfiltration attempts that may correlate with the discovery activity.
+
+### False positive analysis
+
+- System administrators or automated scripts may use grep to search for VM-related files as part of routine maintenance or monitoring tasks. To handle this, create exceptions for known administrative scripts or processes by excluding specific parent processes or user accounts.
+- Backup or snapshot management tools might invoke grep to verify the presence of VM files. Identify these tools and exclude their process names or paths from the detection rule to prevent false alerts.
+- Developers or IT staff conducting legitimate audits or inventory checks on VM files may trigger this rule. Consider excluding specific user accounts or groups that are authorized to perform such activities.
+- Security tools or monitoring solutions that perform regular checks on VM files could also cause false positives. Whitelist these tools by excluding their executable paths or process names from the rule.
+
+### Response and remediation
+
+- Isolate the affected Linux system from the network to prevent further unauthorized access or data exfiltration.
+- Terminate any suspicious processes identified by the detection rule, specifically those involving 'grep', 'egrep', or 'pgrep' with VM-related file extensions.
+- Conduct a thorough review of the system's recent process execution history and file access logs to identify any unauthorized access or changes to VM files.
+- Restore any compromised or altered VM files from a known good backup to ensure system integrity and continuity.
+- Implement stricter access controls and permissions on VM-related files to limit exposure to unauthorized users or processes.
+- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected.
+- Update and enhance monitoring rules to detect similar patterns of suspicious activity, ensuring early detection of future threats."""
 references = [
     "https://www.bleepingcomputer.com/news/security/massive-esxiargs-ransomware-attack-targets-vmware-esxi-servers-worldwide/",
 ]
@@ -63,6 +100,7 @@ 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", "executed", "process_started") and
@@ -70,49 +108,18 @@ process where host.os.type == "linux" and event.type == "start" and
   process.args in ("vmdk", "vmx", "vmxf", "vmsd", "vmsn", "vswp", "vmss", "nvram", "vmem") and
   not process.parent.executable == "/usr/share/qemu/init/qemu-kvm-init"
 '''
-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 ESXI Discovery via Grep
-
-In Linux environments, tools like 'grep' are used to search through files for specific patterns. Adversaries may exploit these tools to locate and analyze virtual machine files, which are crucial for ESXi environments. The detection rule identifies suspicious use of 'grep' variants targeting VM file extensions, signaling potential reconnaissance or manipulation attempts by threat actors. This rule helps in early detection of such malicious activities by monitoring process execution patterns.
-
-### Possible investigation steps
-
-- Review the process execution details to confirm the presence of 'grep', 'egrep', or 'pgrep' with arguments related to VM file extensions such as "vmdk", "vmx", "vmxf", "vmsd", "vmsn", "vswp", "vmss", "nvram", or "vmem".
-- Check the parent process of the suspicious 'grep' command to determine if it is a legitimate process or potentially malicious, ensuring it is not "/usr/share/qemu/init/qemu-kvm-init".
-- Investigate the user account associated with the process execution to assess if the activity aligns with their typical behavior or if it appears anomalous.
-- Examine recent system logs and other security alerts for additional indicators of compromise or related suspicious activities on the host.
-- Assess the network activity from the host to identify any unusual connections or data exfiltration attempts that may correlate with the discovery activity.
-
-### False positive analysis
-
-- System administrators or automated scripts may use grep to search for VM-related files as part of routine maintenance or monitoring tasks. To handle this, create exceptions for known administrative scripts or processes by excluding specific parent processes or user accounts.
-- Backup or snapshot management tools might invoke grep to verify the presence of VM files. Identify these tools and exclude their process names or paths from the detection rule to prevent false alerts.
-- Developers or IT staff conducting legitimate audits or inventory checks on VM files may trigger this rule. Consider excluding specific user accounts or groups that are authorized to perform such activities.
-- Security tools or monitoring solutions that perform regular checks on VM files could also cause false positives. Whitelist these tools by excluding their executable paths or process names from the rule.
-
-### Response and remediation
-
-- Isolate the affected Linux system from the network to prevent further unauthorized access or data exfiltration.
-- Terminate any suspicious processes identified by the detection rule, specifically those involving 'grep', 'egrep', or 'pgrep' with VM-related file extensions.
-- Conduct a thorough review of the system's recent process execution history and file access logs to identify any unauthorized access or changes to VM files.
-- Restore any compromised or altered VM files from a known good backup to ensure system integrity and continuity.
-- Implement stricter access controls and permissions on VM-related files to limit exposure to unauthorized users or processes.
-- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected.
-- Update and enhance monitoring rules to detect similar patterns of suspicious activity, ensuring early detection of future threats."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
-
 [[rule.threat.technique]]
 id = "T1518"
 name = "Software Discovery"
 reference = "https://attack.mitre.org/techniques/T1518/"
 
+
 [rule.threat.tactic]
 id = "TA0007"
 name = "Discovery"
 reference = "https://attack.mitre.org/tactics/TA0007/"
+

rules/linux/discovery_linux_hping_activity.toml

@@ -2,9 +2,7 @@
 creation_date = "2020/02/18"
 integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
-min_stack_version = "8.13.0"
-min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/02/04"
+updated_date = "2025/03/20"
 
 [rule]
 author = ["Elastic"]
@@ -19,10 +17,52 @@ false_positives = [
     """,
 ]
 from = "now-9m"
-index = ["auditbeat-*", "endgame-*", "logs-auditd_manager.auditd-*", "logs-crowdstrike.fdr*", "logs-endpoint.events.process*", "logs-sentinel_one_cloud_funnel.*"]
+index = [
+    "auditbeat-*",
+    "endgame-*",
+    "logs-auditd_manager.auditd-*",
+    "logs-crowdstrike.fdr*",
+    "logs-endpoint.events.process*",
+    "logs-sentinel_one_cloud_funnel.*",
+]
 language = "eql"
 license = "Elastic License v2"
 name = "Hping Process Activity"
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
+
+### Investigating Hping Process Activity
+
+Hping is a versatile command-line tool used for crafting and analyzing network packets, often employed in network security testing. Adversaries may exploit Hping to perform reconnaissance, such as scanning networks or probing firewalls, to gather system information. The detection rule identifies Hping's execution on Linux systems by monitoring specific process start events, helping to flag potential misuse indicative of discovery tactics.
+
+### Possible investigation steps
+
+- Review the process start event details to confirm the execution of Hping, focusing on the process.name field to ensure it matches "hping", "hping2", or "hping3".
+- Identify the user account associated with the Hping process by examining the user context in the event data to determine if the activity aligns with expected behavior for that user.
+- Analyze the command line arguments used with the Hping process to understand the intent of the execution, such as specific network targets or options that indicate scanning or probing activities.
+- Check the timing and frequency of the Hping process execution to assess whether it aligns with routine network testing schedules or if it appears anomalous.
+- Investigate the source and destination IP addresses involved in the Hping activity to identify potential targets and assess whether they are internal or external to the organization.
+- Correlate the Hping activity with other security events or alerts from the same host or network segment to identify any related suspicious activities or patterns.
+- Consult with the system owner or network security team to verify if the Hping activity was authorized as part of legitimate security testing or if it requires further investigation.
+
+### False positive analysis
+
+- Routine network testing by IT teams may trigger the rule when using Hping for legitimate purposes. To manage this, create exceptions for known IP addresses or user accounts involved in regular network audits.
+- Automated scripts or cron jobs that utilize Hping for monitoring network performance can lead to false positives. Identify these scripts and exclude their execution paths or associated user accounts from the detection rule.
+- Security training exercises or penetration testing activities might involve Hping usage. Coordinate with security teams to whitelist these activities by specifying time windows or specific user roles.
+- Development or testing environments where Hping is used for application testing can cause alerts. Exclude these environments by filtering based on hostnames or network segments associated with non-production systems.
+
+### Response and remediation
+
+- Immediately isolate the affected Linux host from the network to prevent further reconnaissance or potential lateral movement by the adversary.
+- Terminate any active Hping processes on the affected host to stop ongoing packet crafting or network probing activities.
+- Conduct a thorough review of network logs and firewall configurations to identify any unauthorized access or anomalies that may have been exploited using Hping.
+- Perform a comprehensive scan of the affected system for additional indicators of compromise, such as unauthorized user accounts or unexpected changes to system files.
+- Reset credentials and review access permissions for accounts on the affected host to ensure no unauthorized access persists.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.
+- Update detection and monitoring systems to enhance visibility and alerting for similar reconnaissance activities, ensuring rapid response to future threats."""
 references = ["https://en.wikipedia.org/wiki/Hping"]
 risk_score = 47
 rule_id = "90169566-2260-4824-b8e4-8615c3b4ed52"
@@ -84,41 +124,6 @@ process where host.os.type == "linux" and event.type == "start" and
  event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and
  process.name in ("hping", "hping2", "hping3")
 '''
-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 Hping Process Activity
-
-Hping is a versatile command-line tool used for crafting and analyzing network packets, often employed in network security testing. Adversaries may exploit Hping to perform reconnaissance, such as scanning networks or probing firewalls, to gather system information. The detection rule identifies Hping's execution on Linux systems by monitoring specific process start events, helping to flag potential misuse indicative of discovery tactics.
-
-### Possible investigation steps
-
-- Review the process start event details to confirm the execution of Hping, focusing on the process.name field to ensure it matches "hping", "hping2", or "hping3".
-- Identify the user account associated with the Hping process by examining the user context in the event data to determine if the activity aligns with expected behavior for that user.
-- Analyze the command line arguments used with the Hping process to understand the intent of the execution, such as specific network targets or options that indicate scanning or probing activities.
-- Check the timing and frequency of the Hping process execution to assess whether it aligns with routine network testing schedules or if it appears anomalous.
-- Investigate the source and destination IP addresses involved in the Hping activity to identify potential targets and assess whether they are internal or external to the organization.
-- Correlate the Hping activity with other security events or alerts from the same host or network segment to identify any related suspicious activities or patterns.
-- Consult with the system owner or network security team to verify if the Hping activity was authorized as part of legitimate security testing or if it requires further investigation.
-
-### False positive analysis
-
-- Routine network testing by IT teams may trigger the rule when using Hping for legitimate purposes. To manage this, create exceptions for known IP addresses or user accounts involved in regular network audits.
-- Automated scripts or cron jobs that utilize Hping for monitoring network performance can lead to false positives. Identify these scripts and exclude their execution paths or associated user accounts from the detection rule.
-- Security training exercises or penetration testing activities might involve Hping usage. Coordinate with security teams to whitelist these activities by specifying time windows or specific user roles.
-- Development or testing environments where Hping is used for application testing can cause alerts. Exclude these environments by filtering based on hostnames or network segments associated with non-production systems.
-
-### Response and remediation
-
-- Immediately isolate the affected Linux host from the network to prevent further reconnaissance or potential lateral movement by the adversary.
-- Terminate any active Hping processes on the affected host to stop ongoing packet crafting or network probing activities.
-- Conduct a thorough review of network logs and firewall configurations to identify any unauthorized access or anomalies that may have been exploited using Hping.
-- Perform a comprehensive scan of the affected system for additional indicators of compromise, such as unauthorized user accounts or unexpected changes to system files.
-- Reset credentials and review access permissions for accounts on the affected host to ensure no unauthorized access persists.
-- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.
-- Update detection and monitoring systems to enhance visibility and alerting for similar reconnaissance activities, ensuring rapid response to future threats."""
 
 
 [[rule.threat]]

rules/linux/discovery_linux_nping_activity.toml

@@ -2,9 +2,7 @@
 creation_date = "2020/02/18"
 integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
-min_stack_version = "8.13.0"
-min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/02/04"
+updated_date = "2025/03/20"
 
 [rule]
 author = ["Elastic"]
@@ -19,10 +17,52 @@ false_positives = [
     """,
 ]
 from = "now-9m"
-index = ["auditbeat-*", "endgame-*", "logs-auditd_manager.auditd-*", "logs-crowdstrike.fdr*", "logs-endpoint.events.process*", "logs-sentinel_one_cloud_funnel.*"]
+index = [
+    "auditbeat-*",
+    "endgame-*",
+    "logs-auditd_manager.auditd-*",
+    "logs-crowdstrike.fdr*",
+    "logs-endpoint.events.process*",
+    "logs-sentinel_one_cloud_funnel.*",
+]
 language = "eql"
 license = "Elastic License v2"
 name = "Nping Process Activity"
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
+
+### Investigating Nping Process Activity
+
+Nping, a component of the Nmap suite, is used for crafting raw packets, aiding in network diagnostics and security testing. Adversaries may exploit Nping to perform network reconnaissance or denial-of-service attacks by sending crafted packets to probe network services. The detection rule identifies Nping's execution on Linux systems by monitoring process start events, helping to flag potential misuse for malicious network discovery activities.
+
+### Possible investigation steps
+
+- Review the process start event details to confirm the execution of Nping, focusing on the process name field to ensure it matches "nping".
+- Identify the user account associated with the Nping process execution to determine if it aligns with expected or authorized usage patterns.
+- Examine the command line arguments used with Nping to understand the intent of the execution, such as specific network targets or packet types.
+- Check the timing and frequency of the Nping execution to assess if it correlates with any known maintenance windows or unusual activity patterns.
+- Investigate network logs or traffic data to identify any unusual or unauthorized network scanning or probing activities originating from the host where Nping was executed.
+- Correlate the Nping activity with other security alerts or logs from the same host to identify potential indicators of compromise or broader attack patterns.
+
+### False positive analysis
+
+- Routine network diagnostics by IT teams using Nping for legitimate purposes can trigger alerts. To manage this, create exceptions for specific user accounts or IP addresses known to perform regular network testing.
+- Automated scripts or monitoring tools that incorporate Nping for network health checks may cause false positives. Identify these scripts and whitelist their execution paths or associated processes.
+- Security assessments or penetration tests conducted by authorized personnel might involve Nping usage. Coordinate with security teams to schedule these activities and temporarily adjust detection rules or add exceptions for the duration of the tests.
+- Development or testing environments where Nping is used for application testing can generate alerts. Exclude these environments from monitoring or adjust the rule to ignore specific hostnames or network segments.
+- Training sessions or workshops that include Nping demonstrations can lead to false positives. Notify the security team in advance and apply temporary exceptions for the event duration.
+
+### Response and remediation
+
+- Immediately isolate the affected Linux host from the network to prevent further reconnaissance or potential denial-of-service attacks.
+- Terminate the Nping process on the affected host to stop any ongoing malicious activity.
+- Conduct a thorough review of recent network traffic logs from the affected host to identify any unusual or unauthorized network service discovery attempts.
+- Check for any unauthorized changes or installations on the affected host that may indicate further compromise or persistence mechanisms.
+- Update and apply network security policies to restrict the use of network diagnostic tools like Nping to authorized personnel only.
+- Escalate the incident to the security operations team for further investigation and to determine if the activity is part of a larger attack campaign.
+- Enhance monitoring and alerting for similar activities across the network by ensuring that detection rules are in place for unauthorized use of network diagnostic tools."""
 references = ["https://en.wikipedia.org/wiki/Nmap"]
 risk_score = 47
 rule_id = "0d69150b-96f8-467c-a86d-a67a3378ce77"
@@ -84,41 +124,6 @@ process where host.os.type == "linux" and event.type == "start" and
  event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and
  process.name == "nping"
 '''
-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 Nping Process Activity
-
-Nping, a component of the Nmap suite, is used for crafting raw packets, aiding in network diagnostics and security testing. Adversaries may exploit Nping to perform network reconnaissance or denial-of-service attacks by sending crafted packets to probe network services. The detection rule identifies Nping's execution on Linux systems by monitoring process start events, helping to flag potential misuse for malicious network discovery activities.
-
-### Possible investigation steps
-
-- Review the process start event details to confirm the execution of Nping, focusing on the process name field to ensure it matches "nping".
-- Identify the user account associated with the Nping process execution to determine if it aligns with expected or authorized usage patterns.
-- Examine the command line arguments used with Nping to understand the intent of the execution, such as specific network targets or packet types.
-- Check the timing and frequency of the Nping execution to assess if it correlates with any known maintenance windows or unusual activity patterns.
-- Investigate network logs or traffic data to identify any unusual or unauthorized network scanning or probing activities originating from the host where Nping was executed.
-- Correlate the Nping activity with other security alerts or logs from the same host to identify potential indicators of compromise or broader attack patterns.
-
-### False positive analysis
-
-- Routine network diagnostics by IT teams using Nping for legitimate purposes can trigger alerts. To manage this, create exceptions for specific user accounts or IP addresses known to perform regular network testing.
-- Automated scripts or monitoring tools that incorporate Nping for network health checks may cause false positives. Identify these scripts and whitelist their execution paths or associated processes.
-- Security assessments or penetration tests conducted by authorized personnel might involve Nping usage. Coordinate with security teams to schedule these activities and temporarily adjust detection rules or add exceptions for the duration of the tests.
-- Development or testing environments where Nping is used for application testing can generate alerts. Exclude these environments from monitoring or adjust the rule to ignore specific hostnames or network segments.
-- Training sessions or workshops that include Nping demonstrations can lead to false positives. Notify the security team in advance and apply temporary exceptions for the event duration.
-
-### Response and remediation
-
-- Immediately isolate the affected Linux host from the network to prevent further reconnaissance or potential denial-of-service attacks.
-- Terminate the Nping process on the affected host to stop any ongoing malicious activity.
-- Conduct a thorough review of recent network traffic logs from the affected host to identify any unusual or unauthorized network service discovery attempts.
-- Check for any unauthorized changes or installations on the affected host that may indicate further compromise or persistence mechanisms.
-- Update and apply network security policies to restrict the use of network diagnostic tools like Nping to authorized personnel only.
-- Escalate the incident to the security operations team for further investigation and to determine if the activity is part of a larger attack campaign.
-- Enhance monitoring and alerting for similar activities across the network by ensuring that detection rules are in place for unauthorized use of network diagnostic tools."""
 
 
 [[rule.threat]]

rules/linux/discovery_pam_version_discovery.toml

@@ -2,9 +2,7 @@
 creation_date = "2024/12/16"
 integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
-min_stack_version = "8.13.0"
-min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/02/04"
+updated_date = "2025/03/20"
 
 [rule]
 author = ["Elastic"]
@@ -13,10 +11,49 @@ This rule detects PAM version discovery activity on Linux systems. PAM version d
 attacker attempting to backdoor the authentication process through malicious PAM modules.
 """
 from = "now-9m"
-index = ["endgame-*", "logs-crowdstrike.fdr*", "logs-endpoint.events.process*", "logs-sentinel_one_cloud_funnel.*"]
+index = [
+    "endgame-*",
+    "logs-crowdstrike.fdr*",
+    "logs-endpoint.events.process*",
+    "logs-sentinel_one_cloud_funnel.*",
+]
 language = "eql"
 license = "Elastic License v2"
 name = "Pluggable Authentication Module (PAM) Version Discovery"
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
+
+### Investigating Pluggable Authentication Module (PAM) Version Discovery
+
+Pluggable Authentication Modules (PAM) provide a flexible mechanism for authenticating users on Linux systems. Adversaries may exploit PAM by discovering its version to identify vulnerabilities or backdoor the authentication process with malicious modules. The detection rule identifies suspicious processes querying PAM-related packages, indicating potential reconnaissance or tampering attempts, thus alerting security teams to possible threats.
+
+### Possible investigation steps
+
+- Review the process details to confirm the presence of suspicious activity, focusing on processes with names "dpkg", "dpkg-query", or "rpm" and their arguments "libpam-modules" or "pam".
+- Check the user account associated with the process to determine if it is a legitimate user or potentially compromised.
+- Investigate the parent process to understand the origin of the command execution and assess if it aligns with normal user behavior.
+- Analyze recent login attempts and authentication logs to identify any unusual patterns or failed attempts that may indicate unauthorized access attempts.
+- Correlate this activity with other alerts or logs from the same host to identify if there are additional indicators of compromise or related suspicious activities.
+
+### False positive analysis
+
+- Routine system updates or package management activities may trigger the rule when legitimate processes like dpkg or rpm query PAM-related packages. To manage this, consider creating exceptions for known maintenance windows or trusted administrative scripts.
+- Automated configuration management tools, such as Ansible or Puppet, might execute commands that match the rule's criteria. Identify these tools and exclude their processes from triggering alerts by specifying their execution context.
+- Security compliance checks or vulnerability assessments often involve querying system packages, including PAM. If these are regularly scheduled and verified, whitelist the associated processes to prevent unnecessary alerts.
+- Developers or system administrators testing PAM configurations might inadvertently trigger the rule. Establish a protocol for notifying the security team of such activities in advance, allowing for temporary exceptions during testing periods.
+- Custom scripts used for system monitoring or auditing may include commands that match the rule. Review these scripts and, if deemed safe, add them to an exclusion list to reduce false positives.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary.
+- Terminate any suspicious processes identified by the detection rule, specifically those involving 'dpkg', 'dpkg-query', or 'rpm' with arguments related to PAM.
+- Conduct a thorough review of PAM configuration files and modules on the affected system to identify and remove any unauthorized or malicious modifications.
+- Restore any compromised PAM modules from a known good backup to ensure the integrity of the authentication process.
+- Monitor for any additional suspicious activity on the affected system and related systems, focusing on unusual authentication attempts or process executions.
+- 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 PAM-related activities across the network to detect similar threats in the future."""
 references = [
     "https://www.group-ib.com/blog/pluggable-authentication-module/",
     "https://embracethered.com/blog/posts/2022/post-exploit-pam-ssh-password-grabbing/",
@@ -64,6 +101,7 @@ tags = [
 ]
 timestamp_override = "event.ingested"
 type = "eql"
+
 query = '''
 process where host.os.type == "linux" and event.type == "start" and
   event.action in ("exec", "exec_event", "start", "ProcessRollup2") and process.parent.name != null and
@@ -73,76 +111,42 @@ process where host.os.type == "linux" and event.type == "start" and
   ) and
 not process.parent.name in ("dcservice", "inspectorssmplugin")
 '''
-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 Pluggable Authentication Module (PAM) Version Discovery
-
-Pluggable Authentication Modules (PAM) provide a flexible mechanism for authenticating users on Linux systems. Adversaries may exploit PAM by discovering its version to identify vulnerabilities or backdoor the authentication process with malicious modules. The detection rule identifies suspicious processes querying PAM-related packages, indicating potential reconnaissance or tampering attempts, thus alerting security teams to possible threats.
-
-### Possible investigation steps
-
-- Review the process details to confirm the presence of suspicious activity, focusing on processes with names "dpkg", "dpkg-query", or "rpm" and their arguments "libpam-modules" or "pam".
-- Check the user account associated with the process to determine if it is a legitimate user or potentially compromised.
-- Investigate the parent process to understand the origin of the command execution and assess if it aligns with normal user behavior.
-- Analyze recent login attempts and authentication logs to identify any unusual patterns or failed attempts that may indicate unauthorized access attempts.
-- Correlate this activity with other alerts or logs from the same host to identify if there are additional indicators of compromise or related suspicious activities.
-
-### False positive analysis
-
-- Routine system updates or package management activities may trigger the rule when legitimate processes like dpkg or rpm query PAM-related packages. To manage this, consider creating exceptions for known maintenance windows or trusted administrative scripts.
-- Automated configuration management tools, such as Ansible or Puppet, might execute commands that match the rule's criteria. Identify these tools and exclude their processes from triggering alerts by specifying their execution context.
-- Security compliance checks or vulnerability assessments often involve querying system packages, including PAM. If these are regularly scheduled and verified, whitelist the associated processes to prevent unnecessary alerts.
-- Developers or system administrators testing PAM configurations might inadvertently trigger the rule. Establish a protocol for notifying the security team of such activities in advance, allowing for temporary exceptions during testing periods.
-- Custom scripts used for system monitoring or auditing may include commands that match the rule. Review these scripts and, if deemed safe, add them to an exclusion list to reduce false positives.
-
-### Response and remediation
-
-- Isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary.
-- Terminate any suspicious processes identified by the detection rule, specifically those involving 'dpkg', 'dpkg-query', or 'rpm' with arguments related to PAM.
-- Conduct a thorough review of PAM configuration files and modules on the affected system to identify and remove any unauthorized or malicious modifications.
-- Restore any compromised PAM modules from a known good backup to ensure the integrity of the authentication process.
-- Monitor for any additional suspicious activity on the affected system and related systems, focusing on unusual authentication attempts or process executions.
-- 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 PAM-related activities across the network to detect similar threats in the future."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
-
 [[rule.threat.technique]]
 id = "T1082"
 name = "System Information Discovery"
 reference = "https://attack.mitre.org/techniques/T1082/"
 
+
 [rule.threat.tactic]
 id = "TA0007"
 name = "Discovery"
 reference = "https://attack.mitre.org/tactics/TA0007/"
-
 [[rule.threat]]
 framework = "MITRE ATT&CK"
-
 [[rule.threat.technique]]
 id = "T1543"
 name = "Create or Modify System Process"
 reference = "https://attack.mitre.org/techniques/T1543/"
 
+
 [rule.threat.tactic]
 id = "TA0003"
 name = "Persistence"
 reference = "https://attack.mitre.org/tactics/TA0003/"
-
 [[rule.threat]]
 framework = "MITRE ATT&CK"
-
 [[rule.threat.technique]]
 id = "T1556"
 name = "Modify Authentication Process"
 reference = "https://attack.mitre.org/techniques/T1556/"
 
+
 [rule.threat.tactic]
 id = "TA0006"
 name = "Credential Access"
 reference = "https://attack.mitre.org/tactics/TA0006/"
+

rules/linux/discovery_polkit_version_discovery.toml

@@ -2,21 +2,57 @@
 creation_date = "2025/01/16"
 integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
-min_stack_version = "8.13.0"
-min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/02/04"
+updated_date = "2025/03/20"
 
 [rule]
 author = ["Elastic"]
 description = """
-This rule detects Polkit version discovery activity on Linux systems. Polkit version discovery can be an
-indication of an attacker attempting to exploit misconfigurations or vulnerabilities in the Polkit service.
+This rule detects Polkit version discovery activity on Linux systems. Polkit version discovery can be an indication of
+an attacker attempting to exploit misconfigurations or vulnerabilities in the Polkit service.
 """
 from = "now-9m"
-index = ["endgame-*", "logs-crowdstrike.fdr*", "logs-endpoint.events.process*", "logs-sentinel_one_cloud_funnel.*"]
+index = [
+    "endgame-*",
+    "logs-crowdstrike.fdr*",
+    "logs-endpoint.events.process*",
+    "logs-sentinel_one_cloud_funnel.*",
+]
 language = "eql"
 license = "Elastic License v2"
 name = "Polkit Version Discovery"
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
+
+### Investigating Polkit Version Discovery
+
+Polkit, a system service in Linux, manages system-wide privileges, enabling non-privileged processes to communicate with privileged ones. Adversaries may exploit Polkit by discovering its version to identify vulnerabilities or misconfigurations. The detection rule identifies suspicious activities by monitoring specific command executions related to Polkit version checks, signaling potential reconnaissance efforts by attackers.
+
+### Possible investigation steps
+
+- Review the process execution details to confirm the command used for Polkit version discovery, focusing on the process name and arguments such as "dnf", "rpm", "apt", or "pkaction".
+- Check the user account associated with the process execution to determine if it is a legitimate user or potentially compromised.
+- Investigate the host from which the command was executed to assess if it has a history of suspicious activities or if it is a high-value target.
+- Correlate the event with other logs or alerts to identify if there are additional indicators of compromise or related reconnaissance activities.
+- Evaluate the necessity and frequency of Polkit version checks in the environment to determine if this behavior is expected or anomalous.
+
+### False positive analysis
+
+- Routine system updates or package management activities may trigger the rule when administrators use package managers like dnf, rpm, or apt to check for updates or verify installed packages. To mitigate this, create exceptions for known administrative scripts or user accounts that regularly perform these actions.
+- Automated system monitoring tools that check software versions for compliance or inventory purposes might also cause false positives. Identify these tools and exclude their processes from triggering the rule.
+- Developers or system administrators testing Polkit configurations or updates might execute version checks as part of their workflow. Consider excluding specific user accounts or process paths associated with development and testing environments.
+- Security audits or vulnerability assessments conducted by internal teams may involve version checks as part of their procedures. Coordinate with these teams to whitelist their activities during scheduled assessments.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent potential lateral movement by the attacker.
+- Terminate any suspicious processes identified in the alert, such as those involving the execution of Polkit version discovery commands.
+- Conduct a thorough review of system logs and command history to identify any unauthorized access or further malicious activities.
+- Apply any available security patches or updates to the Polkit service to address known vulnerabilities.
+- Implement stricter access controls and monitoring on systems running Polkit to prevent unauthorized version checks and other reconnaissance activities.
+- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected.
+- Enhance detection capabilities by configuring alerts for similar reconnaissance activities across the network to ensure early detection of potential threats."""
 risk_score = 21
 rule_id = "ca3bcacc-9285-4452-a742-5dae77538f61"
 setup = """## Setup
@@ -54,6 +90,7 @@ tags = [
 ]
 timestamp_override = "event.ingested"
 type = "eql"
+
 query = '''
 process where host.os.type == "linux" and event.type == "start" and
 event.action in ("exec", "exec_event", "start", "ProcessRollup2") and (
@@ -63,49 +100,18 @@ event.action in ("exec", "exec_event", "start", "ProcessRollup2") and (
   (process.name == "pkaction" and process.args == "--version")
 )
 '''
-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 Polkit Version Discovery
-
-Polkit, a system service in Linux, manages system-wide privileges, enabling non-privileged processes to communicate with privileged ones. Adversaries may exploit Polkit by discovering its version to identify vulnerabilities or misconfigurations. The detection rule identifies suspicious activities by monitoring specific command executions related to Polkit version checks, signaling potential reconnaissance efforts by attackers.
-
-### Possible investigation steps
-
-- Review the process execution details to confirm the command used for Polkit version discovery, focusing on the process name and arguments such as "dnf", "rpm", "apt", or "pkaction".
-- Check the user account associated with the process execution to determine if it is a legitimate user or potentially compromised.
-- Investigate the host from which the command was executed to assess if it has a history of suspicious activities or if it is a high-value target.
-- Correlate the event with other logs or alerts to identify if there are additional indicators of compromise or related reconnaissance activities.
-- Evaluate the necessity and frequency of Polkit version checks in the environment to determine if this behavior is expected or anomalous.
-
-### False positive analysis
-
-- Routine system updates or package management activities may trigger the rule when administrators use package managers like dnf, rpm, or apt to check for updates or verify installed packages. To mitigate this, create exceptions for known administrative scripts or user accounts that regularly perform these actions.
-- Automated system monitoring tools that check software versions for compliance or inventory purposes might also cause false positives. Identify these tools and exclude their processes from triggering the rule.
-- Developers or system administrators testing Polkit configurations or updates might execute version checks as part of their workflow. Consider excluding specific user accounts or process paths associated with development and testing environments.
-- Security audits or vulnerability assessments conducted by internal teams may involve version checks as part of their procedures. Coordinate with these teams to whitelist their activities during scheduled assessments.
-
-### Response and remediation
-
-- Isolate the affected system from the network to prevent potential lateral movement by the attacker.
-- Terminate any suspicious processes identified in the alert, such as those involving the execution of Polkit version discovery commands.
-- Conduct a thorough review of system logs and command history to identify any unauthorized access or further malicious activities.
-- Apply any available security patches or updates to the Polkit service to address known vulnerabilities.
-- Implement stricter access controls and monitoring on systems running Polkit to prevent unauthorized version checks and other reconnaissance activities.
-- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected.
-- Enhance detection capabilities by configuring alerts for similar reconnaissance activities across the network to ensure early detection of potential threats."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
-
 [[rule.threat.technique]]
 id = "T1082"
 name = "System Information Discovery"
 reference = "https://attack.mitre.org/techniques/T1082/"
 
+
 [rule.threat.tactic]
 id = "TA0007"
 name = "Discovery"
 reference = "https://attack.mitre.org/tactics/TA0007/"
+

rules/linux/discovery_port_scanning_activity_from_compromised_host.toml

@@ -2,21 +2,17 @@
 creation_date = "2025/03/04"
 integration = ["endpoint"]
 maturity = "production"
-min_stack_comments = "ES|QL rule type in technical preview as of 8.13"
-min_stack_version = "8.13.0"
-updated_date = "2025/03/04"
+updated_date = "2025/03/20"
 
 [rule]
 author = ["Elastic"]
 description = """
-This rule detects potential port scanning activity from a compromised host. Port scanning is a
-common reconnaissance technique used by attackers to identify open ports and services on a target
-system. A compromised host may exhibit port scanning behavior when an attacker is attempting to
-map out the network topology, identify vulnerable services, or prepare for further exploitation.
-This rule identifies potential port scanning activity by monitoring network connection attempts
-from a single host to a large number of ports within a short time frame. ES|QL rules have limited
-fields available in its alert documents. Make sure to review the original documents to aid in the
-investigation of this alert.
+This rule detects potential port scanning activity from a compromised host. Port scanning is a common reconnaissance
+technique used by attackers to identify open ports and services on a target system. A compromised host may exhibit port
+scanning behavior when an attacker is attempting to map out the network topology, identify vulnerable services, or
+prepare for further exploitation. This rule identifies potential port scanning activity by monitoring network connection
+attempts from a single host to a large number of ports within a short time frame. ES|QL rules have limited fields
+available in its alert documents. Make sure to review the original documents to aid in the investigation of this alert.
 """
 from = "now-61m"
 interval = "1h"
@@ -60,6 +56,7 @@ tags = [
 ]
 timestamp_override = "event.ingested"
 type = "esql"
+
 query = '''
 from logs-endpoint.events.network-*
 | keep @timestamp, host.os.type, event.type, event.action, destination.port, process.executable, destination.ip, agent.id
@@ -71,15 +68,17 @@ from logs-endpoint.events.network-*
 | limit 100
 '''
 
+
 [[rule.threat]]
 framework = "MITRE ATT&CK"
-
 [[rule.threat.technique]]
 id = "T1046"
 name = "Network Service Discovery"
 reference = "https://attack.mitre.org/techniques/T1046/"
 
+
 [rule.threat.tactic]
 id = "TA0007"
 name = "Discovery"
 reference = "https://attack.mitre.org/tactics/TA0007/"
+

rules/linux/discovery_private_key_password_searching_activity.toml

@@ -2,9 +2,7 @@
 creation_date = "2024/11/04"
 integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
-min_stack_version = "8.13.0"
-min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/02/04"
+updated_date = "2025/03/20"
 
 [rule]
 author = ["Elastic"]
@@ -13,57 +11,15 @@ This rule detects private key searching activity on Linux systems. Searching for
 attacker attempting to escalate privileges or exfiltrate sensitive information.
 """
 from = "now-9m"
-index = ["endgame-*", "logs-crowdstrike.fdr*", "logs-endpoint.events.process*", "logs-sentinel_one_cloud_funnel.*"]
+index = [
+    "endgame-*",
+    "logs-crowdstrike.fdr*",
+    "logs-endpoint.events.process*",
+    "logs-sentinel_one_cloud_funnel.*",
+]
 language = "eql"
 license = "Elastic License v2"
 name = "Private Key Searching Activity"
-risk_score = 21
-rule_id = "627374ab-7080-4e4d-8316-bef1122444af"
-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: Discovery",
-        "Data Source: Elastic Defend",
-        "Data Source: Crowdstrike",
-        "Data Source: SentinelOne",
-        "Data Source: Elastic Endgame",
-        "Resources: Investigation Guide"
-        ]
-timestamp_override = "event.ingested"
-type = "eql"
-query = '''
-process where host.os.type == "linux" and event.type == "start" and
-  event.action in ("exec", "exec_event", "start", "ProcessRollup2") and process.name == "find" and
-  process.command_line like ("*id_dsa*", "*id_rsa*", "*id_ed*", "*id_ecdsa*", "*id_xmss*", "*id_dh*") and
-  process.command_line like ("*/home/*", "*/etc/ssh*", "*/root/*", "/")
-'''
 note = """## Triage and analysis
 
 > **Disclaimer**:
@@ -98,6 +54,55 @@ In Linux environments, private keys are crucial for secure communications and au
 - Implement stricter access controls and permissions on directories containing private keys to limit exposure to unauthorized users.
 - Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected.
 - Enhance monitoring and alerting for similar activities by ensuring that detection rules are tuned to capture variations of the 'find' command targeting sensitive files."""
+risk_score = 21
+rule_id = "627374ab-7080-4e4d-8316-bef1122444af"
+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: Discovery",
+    "Data Source: Elastic Defend",
+    "Data Source: Crowdstrike",
+    "Data Source: SentinelOne",
+    "Data Source: Elastic Endgame",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "eql"
+
+query = '''
+process where host.os.type == "linux" and event.type == "start" and
+  event.action in ("exec", "exec_event", "start", "ProcessRollup2") and process.name == "find" and
+  process.command_line like ("*id_dsa*", "*id_rsa*", "*id_ed*", "*id_ecdsa*", "*id_xmss*", "*id_dh*") and
+  process.command_line like ("*/home/*", "*/etc/ssh*", "*/root/*", "/")
+'''
+
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
@@ -106,3 +111,4 @@ framework = "MITRE ATT&CK"
 id = "TA0007"
 name = "Discovery"
 reference = "https://attack.mitre.org/tactics/TA0007/"
+

rules/linux/discovery_security_file_access_via_common_utility.toml

@@ -2,9 +2,7 @@
 creation_date = "2024/11/04"
 integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
-min_stack_version = "8.13.0"
-min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/02/04"
+updated_date = "2025/03/20"
 
 [rule]
 author = ["Elastic"]
@@ -13,64 +11,15 @@ This rule detects sensitive security file access via common utilities on Linux s
 from sensitive files using common utilities to gather information about the system and its security configuration.
 """
 from = "now-9m"
-index = ["endgame-*", "logs-crowdstrike.fdr*", "logs-endpoint.events.process*", "logs-sentinel_one_cloud_funnel.*"]
+index = [
+    "endgame-*",
+    "logs-crowdstrike.fdr*",
+    "logs-endpoint.events.process*",
+    "logs-sentinel_one_cloud_funnel.*",
+]
 language = "eql"
 license = "Elastic License v2"
 name = "Security File Access via Common Utilities"
-risk_score = 21
-rule_id = "7efca3ad-a348-43b2-b544-c93a78a0ef92"
-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: Discovery",
-        "Data Source: Elastic Defend",
-        "Data Source: Crowdstrike",
-        "Data Source: SentinelOne",
-        "Data Source: Elastic Endgame",
-        "Resources: Investigation Guide"
-        ]
-timestamp_override = "event.ingested"
-type = "eql"
-query = '''
-process where host.os.type == "linux" and event.type == "start" and
-  event.action in ("exec", "exec_event", "start", "ProcessRollup2") and
-  process.name in ("cat", "grep", "less", "more", "strings", "awk", "find", "xargs") and
-  process.args like (
-    "/etc/security/*", "/etc/pam.d/*", "/etc/login.defs", "/lib/security/*", "/lib64/security/*",
-    "/usr/lib/security/*", "/usr/lib64/security/*", "/usr/lib/x86_64-linux-gnu/security/*",
-    "/home/*/.aws/credentials", "/home/*/.aws/config", "/home/*/.config/gcloud/*credentials.json",
-    "/home/*/.config/gcloud/configurations/config_default", "/home/*/.azure/accessTokens.json",
-    "/home/*/.azure/azureProfile.json"
-  ) and 
-not process.parent.name in ("wazuh-modulesd", "lynis")
-'''
 note = """## Triage and analysis
 
 > **Disclaimer**:
@@ -106,6 +55,62 @@ In Linux environments, common utilities like `cat`, `grep`, and `less` are essen
 - Implement stricter access controls and permissions on sensitive security files to limit exposure to only necessary users and processes.
 - Escalate the incident to the security operations team for further investigation and to assess the potential impact on the broader network.
 - Enhance monitoring and logging for similar activities to improve detection and response times for future incidents."""
+risk_score = 21
+rule_id = "7efca3ad-a348-43b2-b544-c93a78a0ef92"
+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: Discovery",
+    "Data Source: Elastic Defend",
+    "Data Source: Crowdstrike",
+    "Data Source: SentinelOne",
+    "Data Source: Elastic Endgame",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "eql"
+
+query = '''
+process where host.os.type == "linux" and event.type == "start" and
+  event.action in ("exec", "exec_event", "start", "ProcessRollup2") and
+  process.name in ("cat", "grep", "less", "more", "strings", "awk", "find", "xargs") and
+  process.args like (
+    "/etc/security/*", "/etc/pam.d/*", "/etc/login.defs", "/lib/security/*", "/lib64/security/*",
+    "/usr/lib/security/*", "/usr/lib64/security/*", "/usr/lib/x86_64-linux-gnu/security/*",
+    "/home/*/.aws/credentials", "/home/*/.aws/config", "/home/*/.config/gcloud/*credentials.json",
+    "/home/*/.config/gcloud/configurations/config_default", "/home/*/.azure/accessTokens.json",
+    "/home/*/.azure/azureProfile.json"
+  ) and 
+not process.parent.name in ("wazuh-modulesd", "lynis")
+'''
+
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
@@ -114,3 +119,4 @@ framework = "MITRE ATT&CK"
 id = "TA0007"
 name = "Discovery"
 reference = "https://attack.mitre.org/tactics/TA0007/"
+

rules/linux/discovery_subnet_scanning_activity_from_compromised_host.toml

@@ -2,21 +2,17 @@
 creation_date = "2025/03/04"
 integration = ["endpoint"]
 maturity = "production"
-min_stack_comments = "ES|QL rule type in technical preview as of 8.13"
-min_stack_version = "8.13.0"
-updated_date = "2025/03/04"
+updated_date = "2025/03/20"
 
 [rule]
 author = ["Elastic"]
 description = """
-This rule detects potential subnet scanning activity from a compromised host. Subnet scanning is
-a common reconnaissance technique used by attackers to identify live hosts within a network range.
-A compromised host may exhibit subnet scanning behavior when an attacker is attempting to map out
-the network topology, identify vulnerable hosts, or prepare for further exploitation. This rule
-identifies potential subnet scanning activity by monitoring network connection attempts from a
-single host to a large number of hosts within a short time frame. ES|QL rules have limited fields
-available in its alert documents. Make sure to review the original documents to aid in the
-investigation of this alert.
+This rule detects potential subnet scanning activity from a compromised host. Subnet scanning is a common reconnaissance
+technique used by attackers to identify live hosts within a network range. A compromised host may exhibit subnet
+scanning behavior when an attacker is attempting to map out the network topology, identify vulnerable hosts, or prepare
+for further exploitation. This rule identifies potential subnet scanning activity by monitoring network connection
+attempts from a single host to a large number of hosts within a short time frame. ES|QL rules have limited fields
+available in its alert documents. Make sure to review the original documents to aid in the investigation of this alert.
 """
 from = "now-61m"
 interval = "1h"
@@ -60,6 +56,7 @@ tags = [
 ]
 timestamp_override = "event.ingested"
 type = "esql"
+
 query = '''
 from logs-endpoint.events.network-*
 | keep @timestamp, host.os.type, event.type, event.action, process.executable, destination.ip, agent.id
@@ -71,15 +68,17 @@ from logs-endpoint.events.network-*
 | limit 100
 '''
 
+
 [[rule.threat]]
 framework = "MITRE ATT&CK"
-
 [[rule.threat.technique]]
 id = "T1046"
 name = "Network Service Discovery"
 reference = "https://attack.mitre.org/techniques/T1046/"
 
+
 [rule.threat.tactic]
 id = "TA0007"
 name = "Discovery"
 reference = "https://attack.mitre.org/tactics/TA0007/"
+

rules/linux/discovery_sudo_allowed_command_enumeration.toml

@@ -2,9 +2,7 @@
 creation_date = "2023/08/30"
 integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
-min_stack_version = "8.13.0"
-min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/02/04"
+updated_date = "2025/03/20"
 
 [rule]
 author = ["Elastic"]
@@ -14,10 +12,48 @@ the invoking user. Attackers may execute this command to enumerate commands allo
 permissions, potentially allowing to escalate privileges to root.
 """
 from = "now-9m"
-index = ["endgame-*", "logs-crowdstrike.fdr*", "logs-endpoint.events.process*", "logs-sentinel_one_cloud_funnel.*"]
+index = [
+    "endgame-*",
+    "logs-crowdstrike.fdr*",
+    "logs-endpoint.events.process*",
+    "logs-sentinel_one_cloud_funnel.*",
+]
 language = "eql"
 license = "Elastic License v2"
 name = "Sudo Command Enumeration Detected"
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
+
+### Investigating Sudo Command Enumeration Detected
+
+The sudo command in Linux environments allows users to execute commands with elevated privileges, typically as the root user. Attackers may exploit this by using the `sudo -l` command to list permissible commands, potentially identifying paths to escalate privileges. The detection rule identifies this behavior by monitoring for the execution of `sudo -l` from common shell environments, flagging potential misuse for privilege escalation.
+
+### Possible investigation steps
+
+- Review the process execution details to confirm the presence of the `sudo -l` command, ensuring the process name is "sudo" and the arguments include "-l" with an argument count of 2.
+- Identify the parent process of the `sudo` command to determine the shell environment used, checking if it matches any of the specified shells like "bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", or "fish".
+- Investigate the user account that executed the `sudo -l` command to assess if the activity aligns with their typical behavior or if it appears suspicious.
+- Check for any recent changes in user permissions or sudoers configuration that might indicate unauthorized modifications.
+- Correlate this event with other logs or alerts to identify any subsequent suspicious activities that might suggest privilege escalation attempts.
+
+### False positive analysis
+
+- System administrators frequently use the sudo -l command to verify their permissions. To reduce noise, consider excluding specific user accounts or groups known for legitimate use.
+- Automated scripts or configuration management tools may execute sudo -l as part of routine checks. Identify these scripts and exclude their execution paths or parent processes from the rule.
+- Some software installations or updates might invoke sudo -l to check permissions. Monitor and document these processes, then create exceptions for known benign software.
+- Developers or testers might use sudo -l during debugging or testing phases. Coordinate with development teams to identify and exclude these activities when they are part of approved workflows.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent potential lateral movement by the attacker.
+- Review the sudoers file on the affected system to identify any unauthorized or suspicious entries that may have been added or modified, and revert any changes to their original state.
+- Terminate any suspicious processes initiated by the user who executed the `sudo -l` command, especially if they are not part of normal operations.
+- Reset the password of the user account involved in the alert to prevent further unauthorized access.
+- Conduct a thorough review of system logs to identify any additional suspicious activity or commands executed by the user, and assess the scope of potential compromise.
+- Escalate the incident to the security operations team for further investigation and to determine if additional systems may be affected.
+- Implement additional monitoring and alerting for similar `sudo -l` command executions across the environment to enhance detection and response capabilities."""
 risk_score = 21
 rule_id = "28d39238-0c01-420a-b77a-24e5a7378663"
 setup = """## Setup
@@ -59,55 +95,25 @@ tags = [
 ]
 timestamp_override = "event.ingested"
 type = "eql"
+
 query = '''
 process where host.os.type == "linux" and event.type == "start" and
   event.action in ("exec", "exec_event", "start", "ProcessRollup2") and process.name == "sudo" and process.args == "-l" and
   process.args_count == 2 and process.parent.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and
   not process.args == "dpkg"
 '''
-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 Command Enumeration Detected
-
-The sudo command in Linux environments allows users to execute commands with elevated privileges, typically as the root user. Attackers may exploit this by using the `sudo -l` command to list permissible commands, potentially identifying paths to escalate privileges. The detection rule identifies this behavior by monitoring for the execution of `sudo -l` from common shell environments, flagging potential misuse for privilege escalation.
-
-### Possible investigation steps
-
-- Review the process execution details to confirm the presence of the `sudo -l` command, ensuring the process name is "sudo" and the arguments include "-l" with an argument count of 2.
-- Identify the parent process of the `sudo` command to determine the shell environment used, checking if it matches any of the specified shells like "bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", or "fish".
-- Investigate the user account that executed the `sudo -l` command to assess if the activity aligns with their typical behavior or if it appears suspicious.
-- Check for any recent changes in user permissions or sudoers configuration that might indicate unauthorized modifications.
-- Correlate this event with other logs or alerts to identify any subsequent suspicious activities that might suggest privilege escalation attempts.
-
-### False positive analysis
-
-- System administrators frequently use the sudo -l command to verify their permissions. To reduce noise, consider excluding specific user accounts or groups known for legitimate use.
-- Automated scripts or configuration management tools may execute sudo -l as part of routine checks. Identify these scripts and exclude their execution paths or parent processes from the rule.
-- Some software installations or updates might invoke sudo -l to check permissions. Monitor and document these processes, then create exceptions for known benign software.
-- Developers or testers might use sudo -l during debugging or testing phases. Coordinate with development teams to identify and exclude these activities when they are part of approved workflows.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent potential lateral movement by the attacker.
-- Review the sudoers file on the affected system to identify any unauthorized or suspicious entries that may have been added or modified, and revert any changes to their original state.
-- Terminate any suspicious processes initiated by the user who executed the `sudo -l` command, especially if they are not part of normal operations.
-- Reset the password of the user account involved in the alert to prevent further unauthorized access.
-- Conduct a thorough review of system logs to identify any additional suspicious activity or commands executed by the user, and assess the scope of potential compromise.
-- Escalate the incident to the security operations team for further investigation and to determine if additional systems may be affected.
-- Implement additional monitoring and alerting for similar `sudo -l` command executions across the environment to enhance detection and response capabilities."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
-
 [[rule.threat.technique]]
 id = "T1033"
 name = "System Owner/User Discovery"
 reference = "https://attack.mitre.org/techniques/T1033/"
 
+
 [rule.threat.tactic]
 id = "TA0007"
 name = "Discovery"
 reference = "https://attack.mitre.org/tactics/TA0007/"
+

rules/linux/discovery_suspicious_memory_grep_activity.toml

@@ -2,9 +2,7 @@
 creation_date = "2024/02/05"
 integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
-min_stack_version = "8.13.0"
-min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/02/04"
+updated_date = "2025/03/20"
 
 [rule]
 author = ["Elastic"]
@@ -14,32 +12,15 @@ specific process, detailing the memory segments, permissions, and what files are
 read a process's memory map to identify memory addresses for code injection or process hijacking.
 """
 from = "now-9m"
-index = ["endgame-*", "logs-crowdstrike.fdr*", "logs-endpoint.events.process*", "logs-sentinel_one_cloud_funnel.*"]
+index = [
+    "endgame-*",
+    "logs-crowdstrike.fdr*",
+    "logs-endpoint.events.process*",
+    "logs-sentinel_one_cloud_funnel.*",
+]
 language = "eql"
 license = "Elastic License v2"
 name = "Suspicious Memory grep Activity"
-references = ["https://github.com/arget13/DDexec"]
-risk_score = 21
-rule_id = "d74d6506-427a-4790-b170-0c2a6ddac799"
-severity = "low"
-tags = [
-    "Domain: Endpoint",
-    "OS: Linux",
-    "Use Case: Threat Detection",
-    "Tactic: Discovery",
-    "Data Source: Elastic Defend",
-    "Data Source: Elastic Endgame",
-    "Data Source: Crowdstrike",
-    "Data Source: SentinelOne",
-    "Resources: Investigation Guide",
-]
-timestamp_override = "event.ingested"
-type = "eql"
-query = '''
-process where host.os.type == "linux" and event.type == "start" and
-  event.action in ("exec", "exec_event", "start", "ProcessRollup2") and
-  process.name in ("grep", "egrep", "fgrep", "rgrep") and process.args in ("[stack]", "[vdso]", "[heap]")
-'''
 note = """## Triage and analysis
 
 > **Disclaimer**:
@@ -75,16 +56,41 @@ In Linux, the `/proc/*/maps` file reveals a process's memory layout, crucial for
 - Apply patches and updates to the operating system and applications to mitigate known vulnerabilities that could be exploited for similar attacks.
 - Implement stricter access controls and monitoring on sensitive files and directories, such as `/proc/*/maps`, to prevent unauthorized access.
 - Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to assess the need for broader organizational response measures."""
+references = ["https://github.com/arget13/DDexec"]
+risk_score = 21
+rule_id = "d74d6506-427a-4790-b170-0c2a6ddac799"
+severity = "low"
+tags = [
+    "Domain: Endpoint",
+    "OS: Linux",
+    "Use Case: Threat Detection",
+    "Tactic: Discovery",
+    "Data Source: Elastic Defend",
+    "Data Source: Elastic Endgame",
+    "Data Source: Crowdstrike",
+    "Data Source: SentinelOne",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "eql"
+
+query = '''
+process where host.os.type == "linux" and event.type == "start" and
+  event.action in ("exec", "exec_event", "start", "ProcessRollup2") and
+  process.name in ("grep", "egrep", "fgrep", "rgrep") and process.args in ("[stack]", "[vdso]", "[heap]")
+'''
+
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
-
 [[rule.threat.technique]]
 id = "T1057"
 name = "Process Discovery"
 reference = "https://attack.mitre.org/techniques/T1057/"
 
+
 [rule.threat.tactic]
 id = "TA0007"
 name = "Discovery"
 reference = "https://attack.mitre.org/tactics/TA0007/"
+

rules/linux/discovery_suspicious_which_command_execution.toml

@@ -2,9 +2,7 @@
 creation_date = "2023/08/30"
 integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
-min_stack_version = "8.13.0"
-min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/02/04"
+updated_date = "2025/03/20"
 
 [rule]
 author = ["Elastic"]
@@ -18,35 +16,6 @@ index = ["endgame-*", "logs-endpoint.events.process*", "logs-sentinel_one_cloud_
 language = "eql"
 license = "Elastic License v2"
 name = "Suspicious which Enumeration"
-risk_score = 21
-rule_id = "5b18eef4-842c-4b47-970f-f08d24004bde"
-severity = "low"
-tags = [
-    "Domain: Endpoint",
-    "OS: Linux",
-    "Use Case: Threat Detection",
-    "Tactic: Discovery",
-    "Data Source: Elastic Defend",
-    "Data Source: Elastic Endgame",
-    "Data Source: SentinelOne",
-    "Resources: Investigation Guide",
-]
-timestamp_override = "event.ingested"
-type = "eql"
-query = '''
-process where host.os.type == "linux" and event.type == "start" and
-  event.action in ("exec", "exec_event", "start") and
-  process.name == "which" and process.args_count >= 10 and not (
-    process.parent.name == "jem" or
-    process.parent.executable like ("/vz/root/*", "/var/lib/docker/*") or
-    process.args == "--tty-only"
-  )
-
-/* potential tuning if rule would turn out to be noisy
-and process.args in ("nmap", "nc", "ncat", "netcat", nc.traditional", "gcc", "g++", "socat") and
-process.parent.name in ("bash", "dash", "ash", "sh", "tcsh", "csh", "zsh", "ksh", "fish")
-*/
-'''
 note = """## Triage and analysis
 
 > **Disclaimer**:
@@ -81,16 +50,48 @@ The `which` command in Linux environments is typically used to locate the execut
 - Escalate the incident to the security operations team for further investigation and to determine if additional systems have been compromised.
 - Implement enhanced monitoring and logging for the `which` command and similar enumeration tools to detect future misuse.
 - Review and update access controls and permissions to ensure that only authorized users have the ability to execute potentially sensitive commands and utilities."""
+risk_score = 21
+rule_id = "5b18eef4-842c-4b47-970f-f08d24004bde"
+severity = "low"
+tags = [
+    "Domain: Endpoint",
+    "OS: Linux",
+    "Use Case: Threat Detection",
+    "Tactic: Discovery",
+    "Data Source: Elastic Defend",
+    "Data Source: Elastic Endgame",
+    "Data Source: SentinelOne",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "eql"
+
+query = '''
+process where host.os.type == "linux" and event.type == "start" and
+  event.action in ("exec", "exec_event", "start") and
+  process.name == "which" and process.args_count >= 10 and not (
+    process.parent.name == "jem" or
+    process.parent.executable like ("/vz/root/*", "/var/lib/docker/*") or
+    process.args == "--tty-only"
+  )
+
+/* potential tuning if rule would turn out to be noisy
+and process.args in ("nmap", "nc", "ncat", "netcat", nc.traditional", "gcc", "g++", "socat") and
+process.parent.name in ("bash", "dash", "ash", "sh", "tcsh", "csh", "zsh", "ksh", "fish")
+*/
+'''
+
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
-
 [[rule.threat.technique]]
 id = "T1082"
 name = "System Information Discovery"
 reference = "https://attack.mitre.org/techniques/T1082/"
 
+
 [rule.threat.tactic]
 id = "TA0007"
 name = "Discovery"
 reference = "https://attack.mitre.org/tactics/TA0007/"
+

rules/linux/discovery_yum_dnf_plugin_detection.toml

@@ -2,9 +2,7 @@
 creation_date = "2024/06/25"
 integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
-min_stack_version = "8.13.0"
-min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/02/04"
+updated_date = "2025/03/20"
 
 [rule]
 author = ["Elastic"]
@@ -14,10 +12,48 @@ to search for YUM/DNF configurations and/or plugins with an enabled state. This
 attempting to establish persistence in a YUM or DNF plugin.
 """
 from = "now-9m"
-index = ["endgame-*", "logs-crowdstrike.fdr*", "logs-endpoint.events.process*", "logs-sentinel_one_cloud_funnel.*"]
+index = [
+    "endgame-*",
+    "logs-crowdstrike.fdr*",
+    "logs-endpoint.events.process*",
+    "logs-sentinel_one_cloud_funnel.*",
+]
 language = "eql"
 license = "Elastic License v2"
 name = "Yum/DNF Plugin Status Discovery"
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
+
+### Investigating Yum/DNF Plugin Status Discovery
+
+Yum and DNF are package managers for Linux, managing software installations and updates. They support plugins to extend functionality, which can be targeted by attackers to maintain persistence. Adversaries may use commands to identify active plugins, potentially altering them for malicious purposes. The detection rule identifies suspicious use of the `grep` command to search for plugin configurations, signaling possible reconnaissance or tampering attempts.
+
+### Possible investigation steps
+
+- Review the process execution details to confirm the presence of the `grep` command with arguments related to plugin configurations, such as `/etc/yum.conf` or `/etc/dnf/dnf.conf`, to verify the alert's accuracy.
+- Examine the user account associated with the process execution to determine if it is a legitimate user or potentially compromised account.
+- Check the system's command history for any preceding or subsequent commands executed by the same user to identify potential patterns or further suspicious activity.
+- Investigate any recent changes to the plugin configuration files located in directories like `/etc/yum/pluginconf.d/` or `/etc/dnf/plugins/` to detect unauthorized modifications.
+- Correlate the alert with other security events or logs from the same host to identify any additional indicators of compromise or related malicious activity.
+
+### False positive analysis
+
+- System administrators or automated scripts may use the grep command to verify plugin configurations during routine maintenance. To handle this, create exceptions for known administrative scripts or user accounts that regularly perform these checks.
+- Security audits or compliance checks might involve scanning for plugin configurations to ensure they are correctly set up. Exclude these activities by identifying and whitelisting the specific processes or tools used for such audits.
+- Developers or IT staff might search for plugin configurations while troubleshooting or developing new features. Consider excluding processes initiated by trusted development environments or specific user groups involved in these activities.
+- Monitoring tools that perform regular checks on system configurations could trigger this rule. Identify these tools and add them to an exclusion list to prevent false alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent potential lateral movement by the attacker.
+- Terminate any suspicious processes related to the `grep` command that are actively searching for YUM/DNF plugin configurations.
+- Conduct a thorough review of the YUM and DNF plugin configuration files and directories for unauthorized changes or additions, specifically in the paths `/etc/yum.conf`, `/usr/lib/yum-plugins/*`, `/etc/yum/pluginconf.d/*`, `/usr/lib/python*/site-packages/dnf-plugins/*`, `/etc/dnf/plugins/*`, and `/etc/dnf/dnf.conf`.
+- Restore any altered plugin configurations from a known good backup to ensure system integrity.
+- Implement file integrity monitoring on the YUM and DNF configuration directories to detect future unauthorized changes.
+- Escalate the incident to the security operations team for further investigation and to determine if additional systems have been compromised.
+- Review and update access controls and permissions for users and processes interacting with YUM and DNF configurations to minimize the risk of unauthorized access."""
 references = [
     "https://github.com/rapid7/metasploit-framework/blob/master/modules/exploits/linux/local/yum_package_manager_persistence.rb",
     "https://pwnshift.github.io/2020/10/01/persistence.html",
@@ -69,39 +105,6 @@ process where host.os.type == "linux" and event.type == "start" and
     "/usr/lib/python*/site-packages/dnf-plugins/*", "/etc/dnf/plugins/*", "/etc/dnf/dnf.conf"
   )
 '''
-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 Yum/DNF Plugin Status Discovery
-
-Yum and DNF are package managers for Linux, managing software installations and updates. They support plugins to extend functionality, which can be targeted by attackers to maintain persistence. Adversaries may use commands to identify active plugins, potentially altering them for malicious purposes. The detection rule identifies suspicious use of the `grep` command to search for plugin configurations, signaling possible reconnaissance or tampering attempts.
-
-### Possible investigation steps
-
-- Review the process execution details to confirm the presence of the `grep` command with arguments related to plugin configurations, such as `/etc/yum.conf` or `/etc/dnf/dnf.conf`, to verify the alert's accuracy.
-- Examine the user account associated with the process execution to determine if it is a legitimate user or potentially compromised account.
-- Check the system's command history for any preceding or subsequent commands executed by the same user to identify potential patterns or further suspicious activity.
-- Investigate any recent changes to the plugin configuration files located in directories like `/etc/yum/pluginconf.d/` or `/etc/dnf/plugins/` to detect unauthorized modifications.
-- Correlate the alert with other security events or logs from the same host to identify any additional indicators of compromise or related malicious activity.
-
-### False positive analysis
-
-- System administrators or automated scripts may use the grep command to verify plugin configurations during routine maintenance. To handle this, create exceptions for known administrative scripts or user accounts that regularly perform these checks.
-- Security audits or compliance checks might involve scanning for plugin configurations to ensure they are correctly set up. Exclude these activities by identifying and whitelisting the specific processes or tools used for such audits.
-- Developers or IT staff might search for plugin configurations while troubleshooting or developing new features. Consider excluding processes initiated by trusted development environments or specific user groups involved in these activities.
-- Monitoring tools that perform regular checks on system configurations could trigger this rule. Identify these tools and add them to an exclusion list to prevent false alerts.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent potential lateral movement by the attacker.
-- Terminate any suspicious processes related to the `grep` command that are actively searching for YUM/DNF plugin configurations.
-- Conduct a thorough review of the YUM and DNF plugin configuration files and directories for unauthorized changes or additions, specifically in the paths `/etc/yum.conf`, `/usr/lib/yum-plugins/*`, `/etc/yum/pluginconf.d/*`, `/usr/lib/python*/site-packages/dnf-plugins/*`, `/etc/dnf/plugins/*`, and `/etc/dnf/dnf.conf`.
-- Restore any altered plugin configurations from a known good backup to ensure system integrity.
-- Implement file integrity monitoring on the YUM and DNF configuration directories to detect future unauthorized changes.
-- Escalate the incident to the security operations team for further investigation and to determine if additional systems have been compromised.
-- Review and update access controls and permissions for users and processes interacting with YUM and DNF configurations to minimize the risk of unauthorized access."""
 
 
 [[rule.threat]]

rules/linux/execution_cupsd_foomatic_rip_file_creation.toml

@@ -2,9 +2,7 @@
 creation_date = "2024/09/27"
 integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
-min_stack_version = "8.13.0"
-min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/02/04"
+updated_date = "2025/03/20"
 
 [rule]
 author = ["Elastic"]
@@ -110,6 +108,7 @@ tags = [
     "Resources: Investigation Guide",
 ]
 type = "eql"
+
 query = '''
 sequence by host.id with maxspan=10s
   [process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "start") and
@@ -119,15 +118,17 @@ sequence by host.id with maxspan=10s
    not (process.name == "gs" and file.path like "/tmp/gs_*")] by process.parent.entity_id
 '''
 
+
 [[rule.threat]]
 framework = "MITRE ATT&CK"
-
 [[rule.threat.technique]]
 id = "T1203"
 name = "Exploitation for Client Execution"
 reference = "https://attack.mitre.org/techniques/T1203/"
 
+
 [rule.threat.tactic]
 id = "TA0002"
 name = "Execution"
 reference = "https://attack.mitre.org/tactics/TA0002/"
+

rules/linux/execution_cupsd_foomatic_rip_shell_execution.toml

@@ -2,21 +2,24 @@
 creation_date = "2024/09/27"
 integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
-min_stack_version = "8.13.0"
-min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/02/04"
+updated_date = "2025/03/20"
 
 [rule]
 author = ["Elastic"]
 description = """
 This detection rule addresses multiple vulnerabilities in the CUPS printing system, including CVE-2024-47176,
-CVE-2024-47076, CVE-2024-47175, and CVE-2024-47177. Specifically, this rule detects shell executions from the foomatic-rip
-parent process. These flaws impact components like cups-browsed, libcupsfilters, libppd, and foomatic-rip, allowing
-remote unauthenticated attackers to manipulate IPP URLs or inject malicious data through crafted UDP packets or network
-spoofing. This can result in arbitrary command execution when a print job is initiated.
+CVE-2024-47076, CVE-2024-47175, and CVE-2024-47177. Specifically, this rule detects shell executions from the
+foomatic-rip parent process. These flaws impact components like cups-browsed, libcupsfilters, libppd, and foomatic-rip,
+allowing remote unauthenticated attackers to manipulate IPP URLs or inject malicious data through crafted UDP packets or
+network spoofing. This can result in arbitrary command execution when a print job is initiated.
 """
 from = "now-9m"
-index = ["endgame-*", "logs-crowdstrike.fdr*", "logs-endpoint.events.process*", "logs-sentinel_one_cloud_funnel.*"]
+index = [
+    "endgame-*",
+    "logs-crowdstrike.fdr*",
+    "logs-endpoint.events.process*",
+    "logs-sentinel_one_cloud_funnel.*",
+]
 language = "eql"
 license = "Elastic License v2"
 name = "Cupsd or Foomatic-rip Shell Execution"
@@ -113,6 +116,7 @@ tags = [
 ]
 timestamp_override = "event.ingested"
 type = "eql"
+
 query = '''
 process where host.os.type == "linux" and event.type == "start" and
   event.action in ("exec", "exec_event", "start", "ProcessRollup2") and process.parent.name == "foomatic-rip" and
@@ -125,15 +129,17 @@ process where host.os.type == "linux" and event.type == "start" 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/linux/execution_cupsd_foomatic_rip_suspicious_child_execution.toml

@@ -2,9 +2,7 @@
 creation_date = "2024/09/27"
 integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
-min_stack_version = "8.13.0"
-min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/02/04"
+updated_date = "2025/03/20"
 
 [rule]
 author = ["Elastic"]
@@ -17,7 +15,12 @@ through crafted UDP packets or network spoofing. This can result in arbitrary co
 initiated.
 """
 from = "now-9m"
-index = ["endgame-*", "logs-crowdstrike.fdr*", "logs-endpoint.events.process*", "logs-sentinel_one_cloud_funnel.*"]
+index = [
+    "endgame-*",
+    "logs-crowdstrike.fdr*",
+    "logs-endpoint.events.process*",
+    "logs-sentinel_one_cloud_funnel.*",
+]
 language = "eql"
 license = "Elastic License v2"
 name = "Suspicious Execution from Foomatic-rip or Cupsd Parent"
@@ -114,6 +117,7 @@ tags = [
 ]
 timestamp_override = "event.ingested"
 type = "eql"
+
 query = '''
 process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start", "ProcessRollup2") and
 process.parent.name in ("foomatic-rip", "cupsd") and process.command_line like (
@@ -141,15 +145,17 @@ process.parent.name in ("foomatic-rip", "cupsd") and process.command_line like (
 ) and not process.args like "gs*"
 '''
 
+
 [[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/linux/execution_file_transfer_or_listener_established_via_netcat.toml

@@ -2,9 +2,7 @@
 creation_date = "2020/02/18"
 integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
-min_stack_version = "8.13.0"
-min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/02/04"
+updated_date = "2025/03/20"
 
 [rule]
 author = ["Elastic"]
@@ -21,7 +19,12 @@ false_positives = [
     """,
 ]
 from = "now-9m"
-index = ["auditbeat-*", "logs-endpoint.events.network*", "logs-endpoint.events.process*", "logs-sentinel_one_cloud_funnel.*"]
+index = [
+    "auditbeat-*",
+    "logs-endpoint.events.network*",
+    "logs-endpoint.events.process*",
+    "logs-sentinel_one_cloud_funnel.*",
+]
 language = "eql"
 license = "Elastic License v2"
 name = "File Transfer or Listener Established via Netcat"

rules/linux/execution_interpreter_tty_upgrade.toml

@@ -2,9 +2,7 @@
 creation_date = "2023/09/20"
 integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
-min_stack_version = "8.13.0"
-min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/02/04"
+updated_date = "2025/03/20"
 
 [rule]
 author = ["Elastic"]
@@ -14,10 +12,48 @@ simple reverse shell to a fully interactive tty after obtaining initial access t
 stable connection.
 """
 from = "now-9m"
-index = ["endgame-*", "logs-crowdstrike.fdr*", "logs-endpoint.events.process*", "logs-sentinel_one_cloud_funnel.*"]
+index = [
+    "endgame-*",
+    "logs-crowdstrike.fdr*",
+    "logs-endpoint.events.process*",
+    "logs-sentinel_one_cloud_funnel.*",
+]
 language = "eql"
 license = "Elastic License v2"
 name = "Potential Upgrade of Non-interactive Shell"
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
+
+### Investigating Potential Upgrade of Non-interactive Shell
+
+In Linux environments, attackers often seek to enhance a basic reverse shell to a fully interactive shell to gain a more robust foothold. This involves using tools like `stty` or `script` to manipulate terminal settings, enabling features like command history and job control. The detection rule identifies such activities by monitoring specific process executions and arguments, flagging potential misuse indicative of an upgrade attempt.
+
+### Possible investigation steps
+
+- Review the process execution details to confirm the presence of `stty` or `script` commands with the specific arguments outlined in the detection rule, such as `stty raw -echo` or `script -qc /dev/null`.
+- Examine the parent process of the flagged `stty` or `script` command to determine how the shell was initially spawned and identify any potentially malicious scripts or binaries.
+- Check the user account associated with the process execution to assess if it aligns with expected user behavior or if it indicates potential compromise.
+- Investigate the network connections associated with the host at the time of the alert to identify any suspicious remote connections that could be indicative of a reverse shell.
+- Review historical process execution and login records for the user and host to identify any patterns of suspicious activity or previous attempts to establish a reverse shell.
+
+### False positive analysis
+
+- System administrators or legitimate users may use stty or script commands for routine maintenance or troubleshooting, which can trigger the rule. To manage this, create exceptions for known user accounts or specific maintenance windows.
+- Automated scripts or cron jobs that utilize stty or script for legitimate purposes might be flagged. Review these scripts and whitelist them by process hash or command line pattern to prevent false positives.
+- Development environments where developers frequently use stty or script for testing purposes can generate alerts. Consider excluding specific development machines or user groups from the rule to reduce noise.
+- Monitoring tools or security solutions that simulate shell upgrades for testing or auditing purposes may inadvertently trigger the rule. Identify these tools and add them to an exception list based on their process name or execution path.
+
+### Response and remediation
+
+- Immediately isolate the affected host from the network to prevent further unauthorized access or lateral movement by the attacker.
+- Terminate any suspicious processes identified by the detection rule, specifically those involving `stty` or `script` with the flagged arguments, to disrupt the attacker's attempt to upgrade the shell.
+- Conduct a thorough review of the affected system's logs and process history to identify any additional malicious activities or compromised accounts.
+- Reset credentials for any user accounts that were active during the time of the alert to prevent unauthorized access using potentially compromised credentials.
+- Apply security patches and updates to the affected system to address any vulnerabilities that may have been exploited by the attacker.
+- Enhance monitoring and logging on the affected host and similar systems to detect any future attempts to upgrade non-interactive shells or other suspicious activities.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems may be affected."""
 risk_score = 47
 rule_id = "84d1f8db-207f-45ab-a578-921d91c23eb2"
 setup = """## Setup
@@ -69,39 +105,6 @@ process where host.os.type == "linux" and event.type == "start" and
     process.args_count == 4)
   )
 '''
-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 Upgrade of Non-interactive Shell
-
-In Linux environments, attackers often seek to enhance a basic reverse shell to a fully interactive shell to gain a more robust foothold. This involves using tools like `stty` or `script` to manipulate terminal settings, enabling features like command history and job control. The detection rule identifies such activities by monitoring specific process executions and arguments, flagging potential misuse indicative of an upgrade attempt.
-
-### Possible investigation steps
-
-- Review the process execution details to confirm the presence of `stty` or `script` commands with the specific arguments outlined in the detection rule, such as `stty raw -echo` or `script -qc /dev/null`.
-- Examine the parent process of the flagged `stty` or `script` command to determine how the shell was initially spawned and identify any potentially malicious scripts or binaries.
-- Check the user account associated with the process execution to assess if it aligns with expected user behavior or if it indicates potential compromise.
-- Investigate the network connections associated with the host at the time of the alert to identify any suspicious remote connections that could be indicative of a reverse shell.
-- Review historical process execution and login records for the user and host to identify any patterns of suspicious activity or previous attempts to establish a reverse shell.
-
-### False positive analysis
-
-- System administrators or legitimate users may use stty or script commands for routine maintenance or troubleshooting, which can trigger the rule. To manage this, create exceptions for known user accounts or specific maintenance windows.
-- Automated scripts or cron jobs that utilize stty or script for legitimate purposes might be flagged. Review these scripts and whitelist them by process hash or command line pattern to prevent false positives.
-- Development environments where developers frequently use stty or script for testing purposes can generate alerts. Consider excluding specific development machines or user groups from the rule to reduce noise.
-- Monitoring tools or security solutions that simulate shell upgrades for testing or auditing purposes may inadvertently trigger the rule. Identify these tools and add them to an exception list based on their process name or execution path.
-
-### Response and remediation
-
-- Immediately isolate the affected host from the network to prevent further unauthorized access or lateral movement by the attacker.
-- Terminate any suspicious processes identified by the detection rule, specifically those involving `stty` or `script` with the flagged arguments, to disrupt the attacker's attempt to upgrade the shell.
-- Conduct a thorough review of the affected system's logs and process history to identify any additional malicious activities or compromised accounts.
-- Reset credentials for any user accounts that were active during the time of the alert to prevent unauthorized access using potentially compromised credentials.
-- Apply security patches and updates to the affected system to address any vulnerabilities that may have been exploited by the attacker.
-- Enhance monitoring and logging on the affected host and similar systems to detect any future attempts to upgrade non-interactive shells or other suspicious activities.
-- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems may be affected."""
 
 
 [[rule.threat]]

rules/linux/execution_nc_listener_via_rlwrap.toml

@@ -2,9 +2,7 @@
 creation_date = "2023/09/22"
 integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
-min_stack_version = "8.13.0"
-min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/02/04"
+updated_date = "2025/03/20"
 
 [rule]
 author = ["Elastic"]
@@ -21,10 +19,49 @@ false_positives = [
     """,
 ]
 from = "now-9m"
-index = ["endgame-*", "logs-crowdstrike.fdr*", "logs-endpoint.events.process*", "logs-sentinel_one_cloud_funnel.*"]
+index = [
+    "endgame-*",
+    "logs-crowdstrike.fdr*",
+    "logs-endpoint.events.process*",
+    "logs-sentinel_one_cloud_funnel.*",
+]
 language = "eql"
 license = "Elastic License v2"
 name = "Netcat Listener Established via rlwrap"
+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 Netcat Listener Established via rlwrap
+
+Netcat, a versatile networking tool, can establish connections for data transfer or remote shell access. When combined with rlwrap, which enhances command-line input, it can create a more stable reverse shell environment. Adversaries exploit this to maintain persistent access. The detection rule identifies such misuse by monitoring rlwrap's execution with netcat-related arguments, signaling potential unauthorized activity.
+
+### Possible investigation steps
+
+- Review the process execution details to confirm the presence of rlwrap with netcat-related arguments by examining the process.name and process.args fields.
+- Check the process start time and correlate it with any known scheduled tasks or user activity to determine if the execution was expected or authorized.
+- Investigate the source IP address and port used in the netcat connection to identify potential external connections or data exfiltration attempts.
+- Analyze the user account associated with the process execution to verify if the account has a history of similar activities or if it has been compromised.
+- Examine any related network traffic logs to identify unusual patterns or connections that coincide with the alert, focusing on the host where the process was executed.
+- Look for any additional processes spawned by the netcat listener to detect further malicious activity or persistence mechanisms.
+
+### False positive analysis
+
+- Development and testing environments may frequently use rlwrap with netcat for legitimate purposes, such as testing network applications or scripts. To manage this, create exceptions for specific user accounts or IP addresses known to be involved in development activities.
+- System administrators might use rlwrap with netcat for troubleshooting or network diagnostics. Identify and exclude these activities by setting up rules that recognize the specific command patterns or user roles associated with administrative tasks.
+- Automated scripts or cron jobs that utilize rlwrap and netcat for routine maintenance or monitoring can trigger false positives. Review and whitelist these scripts by their unique process identifiers or command structures to prevent unnecessary alerts.
+- Educational or training environments where rlwrap and netcat are used for learning purposes can generate alerts. Implement exceptions based on the environment's network segment or user group to reduce noise from these benign activities.
+
+### Response and remediation
+
+- Immediately isolate the affected host from the network to prevent further unauthorized access or data exfiltration.
+- Terminate the rlwrap and netcat processes on the affected host to disrupt the reverse shell connection.
+- Conduct a forensic analysis of the affected system to identify any additional malicious activities or persistence mechanisms.
+- Review and secure any compromised accounts or credentials that may have been used or accessed during the incident.
+- Apply security patches and updates to the affected system to mitigate any exploited vulnerabilities.
+- Enhance monitoring and logging on the affected host and network to detect similar activities in the future.
+- Report the incident to the appropriate internal security team or external authorities if required, following organizational protocols."""
 risk_score = 21
 rule_id = "0f56369f-eb3d-459c-a00b-87c2bf7bdfc5"
 setup = """## Setup
@@ -74,40 +111,6 @@ process where host.os.type == "linux" and event.type == "start" and
   process.name == "rlwrap" and process.args in ("nc", "ncat", "netcat", "nc.openbsd", "socat") and
   process.args : "*l*" and process.args_count >= 4
 '''
-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 Netcat Listener Established via rlwrap
-
-Netcat, a versatile networking tool, can establish connections for data transfer or remote shell access. When combined with rlwrap, which enhances command-line input, it can create a more stable reverse shell environment. Adversaries exploit this to maintain persistent access. The detection rule identifies such misuse by monitoring rlwrap's execution with netcat-related arguments, signaling potential unauthorized activity.
-
-### Possible investigation steps
-
-- Review the process execution details to confirm the presence of rlwrap with netcat-related arguments by examining the process.name and process.args fields.
-- Check the process start time and correlate it with any known scheduled tasks or user activity to determine if the execution was expected or authorized.
-- Investigate the source IP address and port used in the netcat connection to identify potential external connections or data exfiltration attempts.
-- Analyze the user account associated with the process execution to verify if the account has a history of similar activities or if it has been compromised.
-- Examine any related network traffic logs to identify unusual patterns or connections that coincide with the alert, focusing on the host where the process was executed.
-- Look for any additional processes spawned by the netcat listener to detect further malicious activity or persistence mechanisms.
-
-### False positive analysis
-
-- Development and testing environments may frequently use rlwrap with netcat for legitimate purposes, such as testing network applications or scripts. To manage this, create exceptions for specific user accounts or IP addresses known to be involved in development activities.
-- System administrators might use rlwrap with netcat for troubleshooting or network diagnostics. Identify and exclude these activities by setting up rules that recognize the specific command patterns or user roles associated with administrative tasks.
-- Automated scripts or cron jobs that utilize rlwrap and netcat for routine maintenance or monitoring can trigger false positives. Review and whitelist these scripts by their unique process identifiers or command structures to prevent unnecessary alerts.
-- Educational or training environments where rlwrap and netcat are used for learning purposes can generate alerts. Implement exceptions based on the environment's network segment or user group to reduce noise from these benign activities.
-
-### Response and remediation
-
-- Immediately isolate the affected host from the network to prevent further unauthorized access or data exfiltration.
-- Terminate the rlwrap and netcat processes on the affected host to disrupt the reverse shell connection.
-- Conduct a forensic analysis of the affected system to identify any additional malicious activities or persistence mechanisms.
-- Review and secure any compromised accounts or credentials that may have been used or accessed during the incident.
-- Apply security patches and updates to the affected system to mitigate any exploited vulnerabilities.
-- Enhance monitoring and logging on the affected host and network to detect similar activities in the future.
-- Report the incident to the appropriate internal security team or external authorities if required, following organizational protocols."""
 
 
 [[rule.threat]]

rules/linux/execution_potential_hack_tool_executed.toml

@@ -2,9 +2,7 @@
 creation_date = "2023/09/22"
 integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
-min_stack_version = "8.13.0"
-min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/02/04"
+updated_date = "2025/03/20"
 
 [rule]
 author = ["Elastic"]
@@ -14,10 +12,52 @@ this rule should be investigated further, as hack tools are commonly used by blu
 well.
 """
 from = "now-9m"
-index = ["auditbeat-*", "endgame-*", "logs-auditd_manager.auditd-*", "logs-crowdstrike.fdr*", "logs-endpoint.events.process*", "logs-sentinel_one_cloud_funnel.*"]
+index = [
+    "auditbeat-*",
+    "endgame-*",
+    "logs-auditd_manager.auditd-*",
+    "logs-crowdstrike.fdr*",
+    "logs-endpoint.events.process*",
+    "logs-sentinel_one_cloud_funnel.*",
+]
 language = "eql"
 license = "Elastic License v2"
 name = "Potential Linux Hack Tool Launched"
+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 Linux Hack Tool Launched
+
+Linux environments often utilize various tools for system administration and security testing. While these tools serve legitimate purposes, adversaries can exploit them for malicious activities, such as unauthorized access or data exfiltration. The detection rule identifies suspicious process executions linked to known hacking tools, flagging potential misuse by monitoring specific process names and actions indicative of exploitation attempts.
+
+### Possible investigation steps
+
+- Review the process name that triggered the alert to determine if it matches any known hacking tools listed in the query, such as "crackmapexec" or "sqlmap".
+- Check the user account associated with the process execution to assess if it is a legitimate user or potentially compromised.
+- Investigate the source and destination IP addresses involved in the process execution to identify any unusual or unauthorized network activity.
+- Examine the command line arguments used during the process execution to understand the intent and scope of the activity.
+- Correlate the event with other logs or alerts from the same host to identify any patterns or additional suspicious activities.
+- Verify if the process execution aligns with any scheduled tasks or known administrative activities to rule out false positives.
+
+### False positive analysis
+
+- System administrators and security teams often use tools like "john", "hashcat", and "hydra" for legitimate security testing and password recovery. To reduce false positives, create exceptions for these tools when used by authorized personnel or during scheduled security assessments.
+- Blue team exercises may involve the use of exploitation frameworks such as "msfconsole" and "msfvenom". Implement a process to whitelist these activities when they are part of a sanctioned security drill.
+- Network scanning tools like "zenmap" and "nuclei" are frequently used for network mapping and vulnerability assessments. Establish a baseline of normal usage patterns and exclude these from alerts when they match expected behavior.
+- Web enumeration tools such as "gobuster" and "dirbuster" might be used by web developers for testing purposes. Coordinate with development teams to identify legitimate use cases and exclude these from triggering alerts.
+- Regularly review and update the list of excluded processes to ensure that only non-threatening activities are exempted, maintaining a balance between security and operational efficiency.
+
+### Response and remediation
+
+- Immediately isolate the affected Linux host from the network to prevent further unauthorized access or data exfiltration.
+- Terminate any suspicious processes identified by the alert, such as those listed in the detection query, to halt potential malicious activities.
+- Conduct a thorough review of system logs and process execution history to identify any additional indicators of compromise or lateral movement attempts.
+- Restore the affected system from a known good backup if any unauthorized changes or data exfiltration are confirmed.
+- Update and patch all software and applications on the affected host to mitigate vulnerabilities that could be exploited by the identified tools.
+- Implement stricter access controls and monitoring on the affected host to prevent unauthorized execution of potentially malicious tools in the future.
+- Escalate the incident to the security operations team for further analysis and to determine if additional systems may be affected."""
 risk_score = 47
 rule_id = "1df1152b-610a-4f48-9d7a-504f6ee5d9da"
 setup = """## Setup
@@ -61,6 +101,7 @@ tags = [
 ]
 timestamp_override = "event.ingested"
 type = "eql"
+
 query = '''
 process where host.os.type == "linux" and event.type == "start" and
 event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and
@@ -82,41 +123,7 @@ process.name in~ (
   "linux-exploit-suggester-2.pl", "linux-exploit-suggester.sh", "panix.sh"
 )
 '''
-note = """## Triage and analysis
 
-> **Disclaimer**:
-> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
-
-### Investigating Potential Linux Hack Tool Launched
-
-Linux environments often utilize various tools for system administration and security testing. While these tools serve legitimate purposes, adversaries can exploit them for malicious activities, such as unauthorized access or data exfiltration. The detection rule identifies suspicious process executions linked to known hacking tools, flagging potential misuse by monitoring specific process names and actions indicative of exploitation attempts.
-
-### Possible investigation steps
-
-- Review the process name that triggered the alert to determine if it matches any known hacking tools listed in the query, such as "crackmapexec" or "sqlmap".
-- Check the user account associated with the process execution to assess if it is a legitimate user or potentially compromised.
-- Investigate the source and destination IP addresses involved in the process execution to identify any unusual or unauthorized network activity.
-- Examine the command line arguments used during the process execution to understand the intent and scope of the activity.
-- Correlate the event with other logs or alerts from the same host to identify any patterns or additional suspicious activities.
-- Verify if the process execution aligns with any scheduled tasks or known administrative activities to rule out false positives.
-
-### False positive analysis
-
-- System administrators and security teams often use tools like "john", "hashcat", and "hydra" for legitimate security testing and password recovery. To reduce false positives, create exceptions for these tools when used by authorized personnel or during scheduled security assessments.
-- Blue team exercises may involve the use of exploitation frameworks such as "msfconsole" and "msfvenom". Implement a process to whitelist these activities when they are part of a sanctioned security drill.
-- Network scanning tools like "zenmap" and "nuclei" are frequently used for network mapping and vulnerability assessments. Establish a baseline of normal usage patterns and exclude these from alerts when they match expected behavior.
-- Web enumeration tools such as "gobuster" and "dirbuster" might be used by web developers for testing purposes. Coordinate with development teams to identify legitimate use cases and exclude these from triggering alerts.
-- Regularly review and update the list of excluded processes to ensure that only non-threatening activities are exempted, maintaining a balance between security and operational efficiency.
-
-### Response and remediation
-
-- Immediately isolate the affected Linux host from the network to prevent further unauthorized access or data exfiltration.
-- Terminate any suspicious processes identified by the alert, such as those listed in the detection query, to halt potential malicious activities.
-- Conduct a thorough review of system logs and process execution history to identify any additional indicators of compromise or lateral movement attempts.
-- Restore the affected system from a known good backup if any unauthorized changes or data exfiltration are confirmed.
-- Update and patch all software and applications on the affected host to mitigate vulnerabilities that could be exploited by the identified tools.
-- Implement stricter access controls and monitoring on the affected host to prevent unauthorized execution of potentially malicious tools in the future.
-- Escalate the incident to the security operations team for further analysis and to determine if additional systems may be affected."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
@@ -125,3 +132,4 @@ framework = "MITRE ATT&CK"
 id = "TA0002"
 name = "Execution"
 reference = "https://attack.mitre.org/tactics/TA0002/"
+

rules/linux/execution_process_backgrounded_by_unusual_parent.toml

@@ -2,18 +2,21 @@
 creation_date = "2025/01/29"
 integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2025/01/29"
-min_stack_version = "8.13.0"
-min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
+updated_date = "2025/03/20"
 
 [rule]
 author = ["Elastic"]
 description = """
-This rule identifies processes that are backgrounded by an unusual parent process. This behavior may indicate
-a process attempting to evade detection by hiding its parent process.
+This rule identifies processes that are backgrounded by an unusual parent process. This behavior may indicate a process
+attempting to evade detection by hiding its parent process.
 """
 from = "now-9m"
-index = ["logs-endpoint.events.process*", "endgame-*", "logs-crowdstrike.fdr*", "logs-sentinel_one_cloud_funnel.*"]
+index = [
+    "logs-endpoint.events.process*",
+    "endgame-*",
+    "logs-crowdstrike.fdr*",
+    "logs-sentinel_one_cloud_funnel.*",
+]
 language = "kuery"
 license = "Elastic License v2"
 name = "Process Backgrounded by Unusual Parent"
@@ -105,6 +108,7 @@ tags = [
 ]
 timestamp_override = "event.ingested"
 type = "new_terms"
+
 query = '''
 event.category:process and host.os.type:linux and event.type:start and
 event.action:(ProcessRollup2 or exec or exec_event or start) and
@@ -112,36 +116,37 @@ process.name:(bash or csh or dash or fish or ksh or sh or tcsh or zsh) and
 process.args:(-c and *&)
 '''
 
+
 [[rule.threat]]
 framework = "MITRE ATT&CK"
-
 [[rule.threat.technique]]
 id = "T1059"
 name = "Command and Scripting Interpreter"
 reference = "https://attack.mitre.org/techniques/T1059/"
 
+
 [rule.threat.tactic]
 id = "TA0002"
 name = "Execution"
 reference = "https://attack.mitre.org/tactics/TA0002/"
-
 [[rule.threat]]
 framework = "MITRE ATT&CK"
-
-[rule.threat.tactic]
-name = "Defense Evasion"
-id = "TA0005"
-reference = "https://attack.mitre.org/tactics/TA0005/"
-
 [[rule.threat.technique]]
 id = "T1564"
 name = "Hide Artifacts"
 reference = "https://attack.mitre.org/techniques/T1564/"
 
+
+[rule.threat.tactic]
+id = "TA0005"
+name = "Defense Evasion"
+reference = "https://attack.mitre.org/tactics/TA0005/"
+
 [rule.new_terms]
 field = "new_terms_fields"
 value = ["process.parent.name"]
-
 [[rule.new_terms.history_window_start]]
 field = "history_window_start"
 value = "now-14d"
+
+

rules/linux/execution_python_tty_shell.toml

@@ -2,9 +2,7 @@
 creation_date = "2020/04/15"
 integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
-min_stack_version = "8.13.0"
-min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/02/04"
+updated_date = "2025/03/20"
 
 [rule]
 author = ["Elastic"]
@@ -17,6 +15,40 @@ index = ["endgame-*", "logs-endpoint.events.process*", "logs-sentinel_one_cloud_
 language = "eql"
 license = "Elastic License v2"
 name = "Interactive Terminal Spawned via Python"
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
+
+### Investigating Interactive Terminal Spawned via Python
+
+Python's ability to spawn interactive terminals is a powerful feature often used for legitimate administrative tasks. However, adversaries can exploit this to escalate a basic reverse shell into a fully interactive terminal, enhancing their control over a compromised system. The detection rule identifies such abuse by monitoring processes where Python spawns a shell, focusing on specific patterns in process arguments and parent-child process relationships, indicating potential malicious activity.
+
+### Possible investigation steps
+
+- Review the process tree to understand the parent-child relationship, focusing on the parent process named "python*" and the child process that is a shell (e.g., bash, sh, zsh).
+- Examine the command-line arguments of the parent Python process to identify the use of "pty.spawn" and the presence of the "-c" flag, which may indicate an attempt to spawn an interactive terminal.
+- Check the process start event details, including the timestamp and user context, to determine if the activity aligns with expected administrative tasks or if it appears suspicious.
+- Investigate the source IP address and user account associated with the process to assess if they are known and authorized entities within the network.
+- Look for any related alerts or logs that might indicate prior suspicious activity, such as initial access vectors or other execution attempts, to build a timeline of events.
+- Correlate this activity with any recent changes or incidents reported on the host to determine if this is part of a larger attack or an isolated event.
+
+### False positive analysis
+
+- Administrative scripts or automation tools that use Python to manage system processes may trigger this rule. To handle this, identify and whitelist specific scripts or tools that are known to perform legitimate tasks.
+- Developers or system administrators using Python for interactive debugging or system management might inadvertently match the rule's criteria. Consider excluding processes initiated by trusted user accounts or within specific directories associated with development or administration.
+- Scheduled tasks or cron jobs that utilize Python to execute shell commands could be mistaken for malicious activity. Review and exclude these tasks by specifying their unique process arguments or parent-child process relationships.
+- Security tools or monitoring solutions that leverage Python for executing shell commands as part of their normal operation may also trigger this rule. Identify these tools and create exceptions based on their process signatures or execution context.
+
+### Response and remediation
+
+- Immediately isolate the affected host from the network to prevent further unauthorized access or lateral movement.
+- Terminate any suspicious Python processes identified in the alert, especially those spawning shell processes, to disrupt the attacker's control.
+- Conduct a thorough review of the affected system for any additional signs of compromise, such as unauthorized user accounts, scheduled tasks, or modified system files.
+- Reset credentials for any accounts accessed from the compromised host to prevent further unauthorized access.
+- Apply security patches and updates to the affected system to address any vulnerabilities that may have been exploited.
+- Enhance monitoring and logging on the affected host and network to detect any similar activities in the future, focusing on process creation and network connections.
+- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected."""
 risk_score = 73
 rule_id = "d76b02ef-fc95-4001-9297-01cb7412232f"
 setup = """## Setup
@@ -67,40 +99,6 @@ process where host.os.type == "linux" and event.type == "start" and event.action
    "fish") and process.args : "*sh" and process.args_count == 1 and process.parent.args_count == 1)
 )
 '''
-note = """## Triage and analysis
-
-> **Disclaimer**:
-> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
-
-### Investigating Interactive Terminal Spawned via Python
-
-Python's ability to spawn interactive terminals is a powerful feature often used for legitimate administrative tasks. However, adversaries can exploit this to escalate a basic reverse shell into a fully interactive terminal, enhancing their control over a compromised system. The detection rule identifies such abuse by monitoring processes where Python spawns a shell, focusing on specific patterns in process arguments and parent-child process relationships, indicating potential malicious activity.
-
-### Possible investigation steps
-
-- Review the process tree to understand the parent-child relationship, focusing on the parent process named "python*" and the child process that is a shell (e.g., bash, sh, zsh).
-- Examine the command-line arguments of the parent Python process to identify the use of "pty.spawn" and the presence of the "-c" flag, which may indicate an attempt to spawn an interactive terminal.
-- Check the process start event details, including the timestamp and user context, to determine if the activity aligns with expected administrative tasks or if it appears suspicious.
-- Investigate the source IP address and user account associated with the process to assess if they are known and authorized entities within the network.
-- Look for any related alerts or logs that might indicate prior suspicious activity, such as initial access vectors or other execution attempts, to build a timeline of events.
-- Correlate this activity with any recent changes or incidents reported on the host to determine if this is part of a larger attack or an isolated event.
-
-### False positive analysis
-
-- Administrative scripts or automation tools that use Python to manage system processes may trigger this rule. To handle this, identify and whitelist specific scripts or tools that are known to perform legitimate tasks.
-- Developers or system administrators using Python for interactive debugging or system management might inadvertently match the rule's criteria. Consider excluding processes initiated by trusted user accounts or within specific directories associated with development or administration.
-- Scheduled tasks or cron jobs that utilize Python to execute shell commands could be mistaken for malicious activity. Review and exclude these tasks by specifying their unique process arguments or parent-child process relationships.
-- Security tools or monitoring solutions that leverage Python for executing shell commands as part of their normal operation may also trigger this rule. Identify these tools and create exceptions based on their process signatures or execution context.
-
-### Response and remediation
-
-- Immediately isolate the affected host from the network to prevent further unauthorized access or lateral movement.
-- Terminate any suspicious Python processes identified in the alert, especially those spawning shell processes, to disrupt the attacker's control.
-- Conduct a thorough review of the affected system for any additional signs of compromise, such as unauthorized user accounts, scheduled tasks, or modified system files.
-- Reset credentials for any accounts accessed from the compromised host to prevent further unauthorized access.
-- Apply security patches and updates to the affected system to address any vulnerabilities that may have been exploited.
-- Enhance monitoring and logging on the affected host and network to detect any similar activities in the future, focusing on process creation and network connections.
-- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected."""
 
 
 [[rule.threat]]

rules/linux/execution_python_webserver_spawned.toml

@@ -2,9 +2,7 @@
 creation_date = "2024/11/04"
 integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
-min_stack_version = "8.13.0"
-min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/02/04"
+updated_date = "2025/03/20"
 
 [rule]
 author = ["Elastic"]
@@ -13,10 +11,50 @@ This rule identifies when a web server is spawned via Python. Attackers may use
 exfiltrate/infiltrate data or to move laterally within a network.
 """
 from = "now-9m"
-index = ["endgame-*", "logs-crowdstrike.fdr*", "logs-endpoint.events.process*", "logs-sentinel_one_cloud_funnel.*"]
+index = [
+    "endgame-*",
+    "logs-crowdstrike.fdr*",
+    "logs-endpoint.events.process*",
+    "logs-sentinel_one_cloud_funnel.*",
+]
 language = "eql"
 license = "Elastic License v2"
 name = "Web Server Spawned via Python"
+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 Web Server Spawned via Python
+
+Python's built-in HTTP server module allows quick web server deployment, often used for testing or file sharing. Adversaries exploit this to exfiltrate data or facilitate lateral movement within networks. The detection rule identifies processes starting a Python-based server, focusing on command patterns and shell usage, to flag potential misuse on Linux systems.
+
+### Possible investigation steps
+
+- Review the process details to confirm the presence of a Python-based web server by checking the process name and arguments, specifically looking for "python" with "http.server" or "SimpleHTTPServer".
+- Investigate the user account associated with the process to determine if it is a known or expected user for running such services.
+- Examine the command line used to start the process for any unusual or suspicious patterns, especially if it involves shell usage like "bash" or "sh" with the command line containing "python -m http.server".
+- Check the network activity from the host to identify any unusual outbound connections or data transfers that could indicate data exfiltration.
+- Correlate the event with other logs or alerts from the same host to identify any preceding or subsequent suspicious activities that might suggest lateral movement or further exploitation attempts.
+- Assess the host's security posture and recent changes to determine if there are any vulnerabilities or misconfigurations that could have been exploited to spawn the web server.
+
+### False positive analysis
+
+- Development and testing environments often use Python's HTTP server for legitimate purposes such as serving static files or testing web applications. To manage this, create exceptions for known development servers by excluding specific hostnames or IP addresses.
+- Automated scripts or cron jobs may start a Python web server for routine tasks like file distribution within a controlled environment. Identify these scripts and exclude their execution paths or user accounts from the detection rule.
+- Educational or training sessions might involve participants using Python's HTTP server to learn web technologies. Exclude these activities by setting time-based exceptions during scheduled training periods.
+- System administrators might use Python's HTTP server for quick file transfers or troubleshooting. Document these use cases and exclude the associated user accounts or process command lines from triggering alerts.
+- Internal tools or utilities developed in-house may rely on Python's HTTP server for functionality. Review these tools and exclude their specific command patterns or execution contexts from the detection rule.
+
+### Response and remediation
+
+- Immediately isolate the affected host from the network to prevent further data exfiltration or lateral movement.
+- Terminate the suspicious Python process identified by the detection rule to stop the unauthorized web server.
+- Conduct a forensic analysis of the affected system to identify any data that may have been accessed or exfiltrated and to determine the initial access vector.
+- Review and secure any exposed credentials or sensitive data that may have been compromised during the incident.
+- Apply patches and updates to the affected system and any related software to mitigate vulnerabilities that may have been exploited.
+- Implement network segmentation to limit the ability of unauthorized processes to communicate across the network.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to ensure comprehensive remediation and recovery actions are taken."""
 risk_score = 21
 rule_id = "99c2b626-de44-4322-b1f9-157ca408c17e"
 setup = """## Setup
@@ -58,6 +96,7 @@ tags = [
 ]
 timestamp_override = "event.ingested"
 type = "eql"
+
 query = '''
 process where host.os.type == "linux" and event.type == "start" and
   event.action in ("exec", "exec_event", "start", "ProcessRollup2") and
@@ -69,69 +108,35 @@ process where host.os.type == "linux" and event.type == "start" and
     )
   )
 '''
-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 Web Server Spawned via Python
-
-Python's built-in HTTP server module allows quick web server deployment, often used for testing or file sharing. Adversaries exploit this to exfiltrate data or facilitate lateral movement within networks. The detection rule identifies processes starting a Python-based server, focusing on command patterns and shell usage, to flag potential misuse on Linux systems.
-
-### Possible investigation steps
-
-- Review the process details to confirm the presence of a Python-based web server by checking the process name and arguments, specifically looking for "python" with "http.server" or "SimpleHTTPServer".
-- Investigate the user account associated with the process to determine if it is a known or expected user for running such services.
-- Examine the command line used to start the process for any unusual or suspicious patterns, especially if it involves shell usage like "bash" or "sh" with the command line containing "python -m http.server".
-- Check the network activity from the host to identify any unusual outbound connections or data transfers that could indicate data exfiltration.
-- Correlate the event with other logs or alerts from the same host to identify any preceding or subsequent suspicious activities that might suggest lateral movement or further exploitation attempts.
-- Assess the host's security posture and recent changes to determine if there are any vulnerabilities or misconfigurations that could have been exploited to spawn the web server.
-
-### False positive analysis
-
-- Development and testing environments often use Python's HTTP server for legitimate purposes such as serving static files or testing web applications. To manage this, create exceptions for known development servers by excluding specific hostnames or IP addresses.
-- Automated scripts or cron jobs may start a Python web server for routine tasks like file distribution within a controlled environment. Identify these scripts and exclude their execution paths or user accounts from the detection rule.
-- Educational or training sessions might involve participants using Python's HTTP server to learn web technologies. Exclude these activities by setting time-based exceptions during scheduled training periods.
-- System administrators might use Python's HTTP server for quick file transfers or troubleshooting. Document these use cases and exclude the associated user accounts or process command lines from triggering alerts.
-- Internal tools or utilities developed in-house may rely on Python's HTTP server for functionality. Review these tools and exclude their specific command patterns or execution contexts from the detection rule.
-
-### Response and remediation
-
-- Immediately isolate the affected host from the network to prevent further data exfiltration or lateral movement.
-- Terminate the suspicious Python process identified by the detection rule to stop the unauthorized web server.
-- Conduct a forensic analysis of the affected system to identify any data that may have been accessed or exfiltrated and to determine the initial access vector.
-- Review and secure any exposed credentials or sensitive data that may have been compromised during the incident.
-- Apply patches and updates to the affected system and any related software to mitigate vulnerabilities that may have been exploited.
-- Implement network segmentation to limit the ability of unauthorized processes to communicate across the network.
-- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to ensure comprehensive remediation and recovery actions are taken."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
-
 [[rule.threat.technique]]
 id = "T1059"
 name = "Command and Scripting Interpreter"
 reference = "https://attack.mitre.org/techniques/T1059/"
-
 [[rule.threat.technique.subtechnique]]
 id = "T1059.006"
 name = "Python"
 reference = "https://attack.mitre.org/techniques/T1059/006/"
 
+
+
 [rule.threat.tactic]
 id = "TA0002"
 name = "Execution"
 reference = "https://attack.mitre.org/tactics/TA0002/"
-
 [[rule.threat]]
 framework = "MITRE ATT&CK"
-
-[rule.threat.tactic]
-name = "Lateral Movement"
-id = "TA0008"
-reference = "https://attack.mitre.org/tactics/TA0008/"
-
 [[rule.threat.technique]]
 id = "T1570"
 name = "Lateral Tool Transfer"
 reference = "https://attack.mitre.org/techniques/T1570/"
+
+
+[rule.threat.tactic]
+id = "TA0008"
+name = "Lateral Movement"
+reference = "https://attack.mitre.org/tactics/TA0008/"
+

rules/linux/execution_shell_openssl_client_or_server.toml

@@ -2,22 +2,54 @@
 creation_date = "2024/07/30"
 integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
-min_stack_version = "8.13.0"
-min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/02/04"
+updated_date = "2025/03/20"
 
 [rule]
 author = ["Elastic"]
 description = """
 This rule identifies when the openssl client or server is used to establish a connection. Attackers may use openssl to
-establish a secure connection to a remote server or to create a secure server to receive connections. This activity
-may be used to exfiltrate data or establish a command and control channel.
+establish a secure connection to a remote server or to create a secure server to receive connections. This activity may
+be used to exfiltrate data or establish a command and control channel.
 """
 from = "now-9m"
 index = ["endgame-*", "logs-endpoint.events.process*", "logs-sentinel_one_cloud_funnel.*"]
 language = "eql"
 license = "Elastic License v2"
 name = "Openssl Client or Server Activity"
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
+
+### Investigating Openssl Client or Server Activity
+
+OpenSSL is a widely-used toolkit for implementing secure communication via SSL/TLS protocols. In Linux environments, it can function as a client or server to encrypt data transmissions. Adversaries may exploit OpenSSL to establish encrypted channels for data exfiltration or command and control. The detection rule identifies suspicious OpenSSL usage by monitoring process execution patterns, specifically targeting atypical client-server interactions, while excluding known benign processes.
+
+### Possible investigation steps
+
+- Review the process execution details to confirm the presence of the "openssl" process with arguments indicating client or server activity, such as "s_client" with "-connect" or "s_server" with "-port".
+- Check the parent process of the "openssl" execution to determine if it is a known benign process or if it is potentially suspicious, especially if it is not in the excluded list (e.g., "/pro/xymon/client/ext/awsXymonCheck.sh", "/opt/antidot-svc/nrpe/plugins/check_cert").
+- Investigate the network connections established by the "openssl" process to identify the remote server's IP address and port, and assess whether these are known or potentially malicious.
+- Analyze the timing and frequency of the "openssl" executions to determine if they align with normal operational patterns or if they suggest unusual or unauthorized activity.
+- Correlate the "openssl" activity with other security events or logs to identify any related suspicious behavior, such as data exfiltration attempts or command and control communications.
+
+### False positive analysis
+
+- Known benign processes such as "/pro/xymon/client/ext/awsXymonCheck.sh" and "/opt/antidot-svc/nrpe/plugins/check_cert" are already excluded to reduce false positives. Ensure these paths are accurate and up-to-date in your environment.
+- Regularly review and update the list of excluded parent processes to include any additional internal scripts or monitoring tools that frequently use OpenSSL for legitimate purposes.
+- Monitor for any internal applications or services that may use OpenSSL in a similar manner and consider adding them to the exclusion list if they are verified as non-threatening.
+- Implement logging and alerting to track the frequency and context of OpenSSL usage, which can help identify patterns that are consistently benign and warrant exclusion.
+- Engage with system administrators to understand routine OpenSSL usage patterns in your environment, which can inform further refinement of the detection rule to minimize false positives.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further data exfiltration or command and control activities.
+- Terminate the suspicious OpenSSL process identified by the alert to halt any ongoing unauthorized encrypted communications.
+- Conduct a forensic analysis of the affected system to identify any additional indicators of compromise, such as unusual network connections or unauthorized file access.
+- Review and update firewall rules to block unauthorized outbound connections from the affected system, focusing on the ports and IP addresses involved in the suspicious activity.
+- Reset credentials and review access permissions for accounts on the affected system to prevent unauthorized access.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if the threat has spread to other systems.
+- Implement enhanced monitoring and logging for OpenSSL usage across the network to detect similar activities in the future, ensuring that alerts are promptly reviewed and acted upon."""
 references = ["https://gtfobins.github.io/gtfobins/openssl/"]
 risk_score = 21
 rule_id = "ad5a3757-c872-4719-8c72-12d3f08db655"
@@ -55,10 +87,11 @@ tags = [
     "Data Source: Elastic Defend",
     "Data Source: Elastic Endgame",
     "Data Source: SentinelOne",
-    "Resources: Investigation Guide"
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
+
 query = '''
 process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start") and
   process.name == "openssl" and (
@@ -69,68 +102,35 @@ process where host.os.type == "linux" and event.type == "start" and event.action
     "/pro/xymon/client/ext/awsXymonCheck.sh", "/opt/antidot-svc/nrpe/plugins/check_cert", "/etc/zabbix/scripts/check_dane_tlsa.sh"
   )
 '''
-note = """## Triage and analysis
 
-> **Disclaimer**:
-> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
-
-### Investigating Openssl Client or Server Activity
-
-OpenSSL is a widely-used toolkit for implementing secure communication via SSL/TLS protocols. In Linux environments, it can function as a client or server to encrypt data transmissions. Adversaries may exploit OpenSSL to establish encrypted channels for data exfiltration or command and control. The detection rule identifies suspicious OpenSSL usage by monitoring process execution patterns, specifically targeting atypical client-server interactions, while excluding known benign processes.
-
-### Possible investigation steps
-
-- Review the process execution details to confirm the presence of the "openssl" process with arguments indicating client or server activity, such as "s_client" with "-connect" or "s_server" with "-port".
-- Check the parent process of the "openssl" execution to determine if it is a known benign process or if it is potentially suspicious, especially if it is not in the excluded list (e.g., "/pro/xymon/client/ext/awsXymonCheck.sh", "/opt/antidot-svc/nrpe/plugins/check_cert").
-- Investigate the network connections established by the "openssl" process to identify the remote server's IP address and port, and assess whether these are known or potentially malicious.
-- Analyze the timing and frequency of the "openssl" executions to determine if they align with normal operational patterns or if they suggest unusual or unauthorized activity.
-- Correlate the "openssl" activity with other security events or logs to identify any related suspicious behavior, such as data exfiltration attempts or command and control communications.
-
-### False positive analysis
-
-- Known benign processes such as "/pro/xymon/client/ext/awsXymonCheck.sh" and "/opt/antidot-svc/nrpe/plugins/check_cert" are already excluded to reduce false positives. Ensure these paths are accurate and up-to-date in your environment.
-- Regularly review and update the list of excluded parent processes to include any additional internal scripts or monitoring tools that frequently use OpenSSL for legitimate purposes.
-- Monitor for any internal applications or services that may use OpenSSL in a similar manner and consider adding them to the exclusion list if they are verified as non-threatening.
-- Implement logging and alerting to track the frequency and context of OpenSSL usage, which can help identify patterns that are consistently benign and warrant exclusion.
-- Engage with system administrators to understand routine OpenSSL usage patterns in your environment, which can inform further refinement of the detection rule to minimize false positives.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further data exfiltration or command and control activities.
-- Terminate the suspicious OpenSSL process identified by the alert to halt any ongoing unauthorized encrypted communications.
-- Conduct a forensic analysis of the affected system to identify any additional indicators of compromise, such as unusual network connections or unauthorized file access.
-- Review and update firewall rules to block unauthorized outbound connections from the affected system, focusing on the ports and IP addresses involved in the suspicious activity.
-- Reset credentials and review access permissions for accounts on the affected system to prevent unauthorized access.
-- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if the threat has spread to other systems.
-- Implement enhanced monitoring and logging for OpenSSL usage across the network to detect similar activities in the future, ensuring that alerts are promptly reviewed and acted upon."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
-
 [[rule.threat.technique]]
 id = "T1059"
 name = "Command and Scripting Interpreter"
 reference = "https://attack.mitre.org/techniques/T1059/"
-
 [[rule.threat.technique.subtechnique]]
 id = "T1059.004"
 name = "Unix Shell"
 reference = "https://attack.mitre.org/techniques/T1059/004/"
 
+
+
 [rule.threat.tactic]
 id = "TA0002"
 name = "Execution"
 reference = "https://attack.mitre.org/tactics/TA0002/"
-
 [[rule.threat]]
 framework = "MITRE ATT&CK"
-
 [[rule.threat.technique]]
 id = "T1071"
 name = "Application Layer Protocol"
 reference = "https://attack.mitre.org/techniques/T1071/"
 
+
 [rule.threat.tactic]
 id = "TA0011"
 name = "Command and Control"
 reference = "https://attack.mitre.org/tactics/TA0011/"
+

rules/linux/execution_shell_via_background_process.toml

@@ -2,9 +2,7 @@
 creation_date = "2023/09/20"
 integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
-min_stack_version = "8.13.0"
-min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/02/04"
+updated_date = "2025/03/20"
 
 [rule]
 author = ["Elastic"]
@@ -13,10 +11,50 @@ Monitors for the execution of background processes with process arguments capabl
 channel. This may indicate the creation of a backdoor reverse connection, and should be investigated further.
 """
 from = "now-9m"
-index = ["endgame-*", "logs-crowdstrike.fdr*", "logs-endpoint.events.process*", "logs-sentinel_one_cloud_funnel.*"]
+index = [
+    "endgame-*",
+    "logs-crowdstrike.fdr*",
+    "logs-endpoint.events.process*",
+    "logs-sentinel_one_cloud_funnel.*",
+]
 language = "eql"
 license = "Elastic License v2"
 name = "Potential Reverse Shell via Background Process"
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
+
+### Investigating Potential Reverse Shell via Background Process
+
+In Linux environments, background processes can be manipulated to establish reverse shells, allowing adversaries to gain remote access. By exploiting shell commands to open network sockets, attackers can create backdoor connections. The detection rule identifies suspicious executions of background processes, like 'setsid' or 'nohup', with arguments indicating socket activity in '/dev/tcp', often initiated by common shell interpreters. This helps in flagging potential reverse shell activities for further investigation.
+
+### Possible investigation steps
+
+- Review the process details to confirm the presence of suspicious arguments, specifically looking for '/dev/tcp' in the process.args field, which indicates an attempt to open a network socket.
+- Identify the parent process by examining the process.parent.name field to determine if it is one of the common shell interpreters like 'bash', 'dash', 'sh', etc., which could suggest a script-based execution.
+- Check the user context under which the process was executed to assess if it aligns with expected user behavior or if it indicates potential compromise of a user account.
+- Investigate the network activity associated with the host to identify any unusual outbound connections that could correlate with the reverse shell attempt.
+- Correlate the event with other security alerts or logs from the same host to identify any preceding or subsequent suspicious activities that might indicate a broader attack pattern.
+- Review historical data for similar process executions on the host to determine if this is an isolated incident or part of a recurring pattern.
+
+### False positive analysis
+
+- Legitimate administrative scripts may use background processes with network socket activity for maintenance tasks. Review the script's purpose and source to determine if it is authorized.
+- Automated monitoring tools might execute commands that match the rule's criteria. Identify these tools and consider excluding their specific process names or paths from the rule.
+- Development environments often run test scripts that open network connections. Verify the development context and exclude known development-related processes to reduce noise.
+- Backup or synchronization software may use similar techniques to transfer data. Confirm the software's legitimacy and add exceptions for its processes if necessary.
+- System updates or package management tools might trigger alerts when installing or updating software. Monitor these activities and whitelist trusted update processes.
+
+### Response and remediation
+
+- Immediately isolate the affected host from the network to prevent further unauthorized access or data exfiltration.
+- Terminate any suspicious background processes identified by the alert, specifically those involving 'setsid' or 'nohup' with '/dev/tcp' in their arguments.
+- Conduct a thorough review of the affected system's process and network activity logs to identify any additional indicators of compromise or lateral movement.
+- Reset credentials for any accounts that were active on the affected system to prevent unauthorized access using potentially compromised credentials.
+- Apply security patches and updates to the affected system to address any vulnerabilities that may have been exploited.
+- Implement network segmentation to limit the ability of compromised systems to communicate with critical infrastructure or sensitive data repositories.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected."""
 risk_score = 47
 rule_id = "259be2d8-3b1a-4c2c-a0eb-0c8e77f35e39"
 setup = """## Setup
@@ -65,41 +103,6 @@ process where host.os.type == "linux" and event.type == "start" and
   process.name in ("setsid", "nohup") and process.args : "*/dev/tcp/*0>&1*" and
   process.parent.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish")
 '''
-note = """## Triage and analysis
-
-> **Disclaimer**:
-> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
-
-### Investigating Potential Reverse Shell via Background Process
-
-In Linux environments, background processes can be manipulated to establish reverse shells, allowing adversaries to gain remote access. By exploiting shell commands to open network sockets, attackers can create backdoor connections. The detection rule identifies suspicious executions of background processes, like 'setsid' or 'nohup', with arguments indicating socket activity in '/dev/tcp', often initiated by common shell interpreters. This helps in flagging potential reverse shell activities for further investigation.
-
-### Possible investigation steps
-
-- Review the process details to confirm the presence of suspicious arguments, specifically looking for '/dev/tcp' in the process.args field, which indicates an attempt to open a network socket.
-- Identify the parent process by examining the process.parent.name field to determine if it is one of the common shell interpreters like 'bash', 'dash', 'sh', etc., which could suggest a script-based execution.
-- Check the user context under which the process was executed to assess if it aligns with expected user behavior or if it indicates potential compromise of a user account.
-- Investigate the network activity associated with the host to identify any unusual outbound connections that could correlate with the reverse shell attempt.
-- Correlate the event with other security alerts or logs from the same host to identify any preceding or subsequent suspicious activities that might indicate a broader attack pattern.
-- Review historical data for similar process executions on the host to determine if this is an isolated incident or part of a recurring pattern.
-
-### False positive analysis
-
-- Legitimate administrative scripts may use background processes with network socket activity for maintenance tasks. Review the script's purpose and source to determine if it is authorized.
-- Automated monitoring tools might execute commands that match the rule's criteria. Identify these tools and consider excluding their specific process names or paths from the rule.
-- Development environments often run test scripts that open network connections. Verify the development context and exclude known development-related processes to reduce noise.
-- Backup or synchronization software may use similar techniques to transfer data. Confirm the software's legitimacy and add exceptions for its processes if necessary.
-- System updates or package management tools might trigger alerts when installing or updating software. Monitor these activities and whitelist trusted update processes.
-
-### Response and remediation
-
-- Immediately isolate the affected host from the network to prevent further unauthorized access or data exfiltration.
-- Terminate any suspicious background processes identified by the alert, specifically those involving 'setsid' or 'nohup' with '/dev/tcp' in their arguments.
-- Conduct a thorough review of the affected system's process and network activity logs to identify any additional indicators of compromise or lateral movement.
-- Reset credentials for any accounts that were active on the affected system to prevent unauthorized access using potentially compromised credentials.
-- Apply security patches and updates to the affected system to address any vulnerabilities that may have been exploited.
-- Implement network segmentation to limit the ability of compromised systems to communicate with critical infrastructure or sensitive data repositories.
-- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected."""
 
 
 [[rule.threat]]

rules/linux/execution_sus_extraction_or_decrompression_via_funzip.toml

@@ -2,9 +2,7 @@
 creation_date = "2023/06/26"
 integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
-min_stack_version = "8.13.0"
-min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/02/04"
+updated_date = "2025/03/20"
 
 [rule]
 author = ["Elastic"]
@@ -19,6 +17,40 @@ index = ["endgame-*", "logs-endpoint.events.process*", "logs-sentinel_one_cloud_
 language = "eql"
 license = "Elastic License v2"
 name = "Suspicious Content Extracted or Decompressed via Funzip"
+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 Content Extracted or Decompressed via Funzip
+
+Funzip is a utility used to decompress files directly from a stream, often employed in legitimate data processing tasks. However, adversaries can exploit this by combining it with the 'tail' command to extract and execute malicious payloads stealthily. The detection rule identifies this misuse by monitoring specific command sequences and excluding benign processes, thus flagging potential threats for further investigation.
+
+### Possible investigation steps
+
+- Review the process details to confirm the presence of the 'tail' and 'funzip' command sequence, focusing on the specific arguments used, such as "-c", to understand the context of the command execution.
+- Examine the parent process information to determine if the process was initiated by any known benign executables or scripts, specifically checking against the exclusion list like "/usr/bin/dracut" or "/sbin/dracut".
+- Investigate the command line history and execution context of the parent process, especially if it involves "sh" or "sudo", to identify any suspicious patterns or unauthorized script executions.
+- Check the file path and content being accessed by the 'tail' command to ensure it is not targeting sensitive or unexpected files, excluding known benign paths like "/var/log/messages".
+- Correlate the event with other security alerts or logs from the same host to identify any related suspicious activities or patterns that might indicate a broader compromise.
+- Assess the risk and impact by determining if the decompressed content was executed or if it led to any subsequent suspicious processes or network connections.
+
+### False positive analysis
+
+- Legitimate system maintenance tasks may trigger this rule if they involve decompressing logs or data files using funzip. To manage this, identify and exclude specific maintenance scripts or processes that are known to use funzip in a non-threatening manner.
+- Automated backup or data processing operations might use funzip in combination with tail for legitimate purposes. Review these operations and add exceptions for known benign processes or scripts that match this pattern.
+- Security tools or monitoring solutions like Nessus may inadvertently trigger this rule if they use similar command sequences for scanning or data collection. Exclude these tools by adding exceptions for their specific command lines or parent processes.
+- Custom scripts developed in-house for data analysis or processing might use funzip and tail together. Document these scripts and exclude them from the rule to prevent false positives, ensuring they are reviewed and approved by security teams.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further spread of the potential malware.
+- Terminate any suspicious processes identified by the detection rule, specifically those involving the 'tail' and 'funzip' command sequence.
+- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any malicious payloads.
+- Review and analyze system logs and command history to identify any unauthorized access or additional malicious activities that may have occurred.
+- Restore any compromised files or systems from known good backups to ensure integrity and availability of data.
+- Implement application whitelisting to prevent unauthorized execution of utilities like 'funzip' and 'tail' by non-administrative users.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to assess the need for broader organizational response measures."""
 references = ["https://attack.mitre.org/software/S0482/"]
 risk_score = 47
 rule_id = "dc0b7782-0df0-47ff-8337-db0d678bdb66"
@@ -68,40 +100,6 @@ not process.args : "/var/log/messages" and
 not process.parent.executable : ("/usr/bin/dracut", "/sbin/dracut", "/usr/bin/xargs") and
 not (process.parent.name in ("sh", "sudo") and process.parent.command_line : "*nessus_su*")
 '''
-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 Content Extracted or Decompressed via Funzip
-
-Funzip is a utility used to decompress files directly from a stream, often employed in legitimate data processing tasks. However, adversaries can exploit this by combining it with the 'tail' command to extract and execute malicious payloads stealthily. The detection rule identifies this misuse by monitoring specific command sequences and excluding benign processes, thus flagging potential threats for further investigation.
-
-### Possible investigation steps
-
-- Review the process details to confirm the presence of the 'tail' and 'funzip' command sequence, focusing on the specific arguments used, such as "-c", to understand the context of the command execution.
-- Examine the parent process information to determine if the process was initiated by any known benign executables or scripts, specifically checking against the exclusion list like "/usr/bin/dracut" or "/sbin/dracut".
-- Investigate the command line history and execution context of the parent process, especially if it involves "sh" or "sudo", to identify any suspicious patterns or unauthorized script executions.
-- Check the file path and content being accessed by the 'tail' command to ensure it is not targeting sensitive or unexpected files, excluding known benign paths like "/var/log/messages".
-- Correlate the event with other security alerts or logs from the same host to identify any related suspicious activities or patterns that might indicate a broader compromise.
-- Assess the risk and impact by determining if the decompressed content was executed or if it led to any subsequent suspicious processes or network connections.
-
-### False positive analysis
-
-- Legitimate system maintenance tasks may trigger this rule if they involve decompressing logs or data files using funzip. To manage this, identify and exclude specific maintenance scripts or processes that are known to use funzip in a non-threatening manner.
-- Automated backup or data processing operations might use funzip in combination with tail for legitimate purposes. Review these operations and add exceptions for known benign processes or scripts that match this pattern.
-- Security tools or monitoring solutions like Nessus may inadvertently trigger this rule if they use similar command sequences for scanning or data collection. Exclude these tools by adding exceptions for their specific command lines or parent processes.
-- Custom scripts developed in-house for data analysis or processing might use funzip and tail together. Document these scripts and exclude them from the rule to prevent false positives, ensuring they are reviewed and approved by security teams.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further spread of the potential malware.
-- Terminate any suspicious processes identified by the detection rule, specifically those involving the 'tail' and 'funzip' command sequence.
-- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any malicious payloads.
-- Review and analyze system logs and command history to identify any unauthorized access or additional malicious activities that may have occurred.
-- Restore any compromised files or systems from known good backups to ensure integrity and availability of data.
-- Implement application whitelisting to prevent unauthorized execution of utilities like 'funzip' and 'tail' by non-administrative users.
-- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to assess the need for broader organizational response measures."""
 
 
 [[rule.threat]]

rules/linux/execution_suspicious_mining_process_creation_events.toml

@@ -2,9 +2,7 @@
 creation_date = "2023/02/08"
 integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
-min_stack_version = "8.13.0"
-min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/02/04"
+updated_date = "2025/03/20"
 
 [rule]
 author = ["Elastic"]
@@ -17,6 +15,40 @@ index = ["endgame-*", "logs-crowdstrike.fdr*", "logs-endpoint.events.file*", "lo
 language = "eql"
 license = "Elastic License v2"
 name = "Suspicious Mining Process Creation Event"
+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 Mining Process Creation Event
+
+Cryptomining exploits system resources to mine cryptocurrency, often without user consent, impacting performance and security. Adversaries may deploy mining services on Linux systems, disguising them as legitimate processes. The detection rule identifies the creation of known mining service files, signaling potential unauthorized mining activity. By monitoring these specific file creation events, security teams can swiftly respond to and mitigate cryptomining threats.
+
+### Possible investigation steps
+
+- Review the alert details to identify which specific mining service file was created, focusing on the file names listed in the query such as "aliyun.service" or "moneroocean_miner.service".
+- Check the creation timestamp of the suspicious file to determine when the potential unauthorized mining activity began.
+- Investigate the process that created the file by examining system logs or using process monitoring tools to identify the parent process and any associated command-line arguments.
+- Analyze the system for additional indicators of compromise, such as unexpected network connections or high CPU usage, which may suggest active cryptomining.
+- Verify the legitimacy of the file by comparing it against known hashes of legitimate services or using threat intelligence sources to identify known malicious files.
+- Assess the system for any other suspicious activities or anomalies that may indicate further compromise or persistence mechanisms.
+
+### False positive analysis
+
+- Legitimate administrative scripts or services may create files with names similar to known mining services. Verify the origin and purpose of such files before taking action.
+- System administrators might deploy custom monitoring or management services that inadvertently match the file names in the detection rule. Review and whitelist these services if they are confirmed to be non-threatening.
+- Automated deployment tools or scripts could create service files as part of routine operations. Ensure these tools are properly documented and exclude them from the detection rule if they are verified as safe.
+- Some legitimate software installations might use generic service names that overlap with those flagged by the rule. Cross-check with software documentation and exclude these from alerts if they are confirmed to be benign.
+
+### Response and remediation
+
+- Isolate the affected Linux system from the network to prevent further unauthorized mining activity and potential lateral movement by the adversary.
+- Terminate any suspicious processes associated with the identified mining services, such as aliyun.service, moneroocean_miner.service, or others listed in the detection query.
+- Remove the malicious service files from the system to prevent them from being restarted or reused by the attacker.
+- Conduct a thorough scan of the system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malware or persistence mechanisms.
+- Review and update system and application patches to close any vulnerabilities that may have been exploited to deploy the mining services.
+- Monitor network traffic for unusual outbound connections that may indicate communication with mining pools or command and control servers, and block these connections if detected.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to assess the potential impact on other systems within the network."""
 risk_score = 47
 rule_id = "e2258f48-ba75-4248-951b-7c885edf18c2"
 setup = """## Setup
@@ -63,40 +95,6 @@ query = '''
 file where host.os.type == "linux" and event.type == "creation" and event.action : ("creation", "file_create_event") and
 file.name : ("aliyun.service", "moneroocean_miner.service", "c3pool_miner.service", "pnsd.service", "apache4.service", "pastebin.service", "xvf.service")
 '''
-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 Mining Process Creation Event
-
-Cryptomining exploits system resources to mine cryptocurrency, often without user consent, impacting performance and security. Adversaries may deploy mining services on Linux systems, disguising them as legitimate processes. The detection rule identifies the creation of known mining service files, signaling potential unauthorized mining activity. By monitoring these specific file creation events, security teams can swiftly respond to and mitigate cryptomining threats.
-
-### Possible investigation steps
-
-- Review the alert details to identify which specific mining service file was created, focusing on the file names listed in the query such as "aliyun.service" or "moneroocean_miner.service".
-- Check the creation timestamp of the suspicious file to determine when the potential unauthorized mining activity began.
-- Investigate the process that created the file by examining system logs or using process monitoring tools to identify the parent process and any associated command-line arguments.
-- Analyze the system for additional indicators of compromise, such as unexpected network connections or high CPU usage, which may suggest active cryptomining.
-- Verify the legitimacy of the file by comparing it against known hashes of legitimate services or using threat intelligence sources to identify known malicious files.
-- Assess the system for any other suspicious activities or anomalies that may indicate further compromise or persistence mechanisms.
-
-### False positive analysis
-
-- Legitimate administrative scripts or services may create files with names similar to known mining services. Verify the origin and purpose of such files before taking action.
-- System administrators might deploy custom monitoring or management services that inadvertently match the file names in the detection rule. Review and whitelist these services if they are confirmed to be non-threatening.
-- Automated deployment tools or scripts could create service files as part of routine operations. Ensure these tools are properly documented and exclude them from the detection rule if they are verified as safe.
-- Some legitimate software installations might use generic service names that overlap with those flagged by the rule. Cross-check with software documentation and exclude these from alerts if they are confirmed to be benign.
-
-### Response and remediation
-
-- Isolate the affected Linux system from the network to prevent further unauthorized mining activity and potential lateral movement by the adversary.
-- Terminate any suspicious processes associated with the identified mining services, such as aliyun.service, moneroocean_miner.service, or others listed in the detection query.
-- Remove the malicious service files from the system to prevent them from being restarted or reused by the attacker.
-- Conduct a thorough scan of the system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malware or persistence mechanisms.
-- Review and update system and application patches to close any vulnerabilities that may have been exploited to deploy the mining services.
-- Monitor network traffic for unusual outbound connections that may indicate communication with mining pools or command and control servers, and block these connections if detected.
-- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to assess the potential impact on other systems within the network."""
 
 
 [[rule.threat]]

rules/linux/execution_tc_bpf_filter.toml

@@ -2,9 +2,7 @@
 creation_date = "2022/07/11"
 integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
-min_stack_version = "8.13.0"
-min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/02/07"
+updated_date = "2025/03/20"
 
 [rule]
 author = ["Elastic"]
@@ -19,6 +17,40 @@ index = ["endgame-*", "logs-endpoint.events.process*", "logs-sentinel_one_cloud_
 language = "eql"
 license = "Elastic License v2"
 name = "BPF filter applied using TC"
+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 BPF filter applied using TC
+
+BPF (Berkeley Packet Filter) is a powerful tool for network traffic analysis and control, often used with the `tc` command to manage traffic on Linux systems. Adversaries may exploit this by setting BPF filters to manipulate or monitor network traffic covertly. The detection rule identifies suspicious use of `tc` to apply BPF filters, flagging potential misuse by checking for specific command patterns and excluding legitimate processes.
+
+### Possible investigation steps
+
+- Review the process execution details to confirm the presence of the `/usr/sbin/tc` command with arguments "filter", "add", and "bpf" to ensure the alert is not a false positive.
+- Investigate the parent process of the `tc` command to determine if it is a known legitimate process or if it appears suspicious, especially since the rule excludes `/usr/sbin/libvirtd`.
+- Check the user account associated with the process execution to assess if it is a privileged account and whether the activity aligns with the user's typical behavior.
+- Analyze network traffic logs around the time of the alert to identify any unusual patterns or connections that may indicate malicious activity.
+- Correlate this event with other security alerts or logs to identify if this is part of a broader attack pattern or campaign, such as the use of the TripleCross threat.
+- Review system logs for any other suspicious activities or anomalies that occurred before or after the alert to gather additional context.
+
+### False positive analysis
+
+- Legitimate use of tc by virtualization software like libvirtd can trigger the rule. To handle this, exclude processes where the parent executable is /usr/sbin/libvirtd, as indicated in the rule.
+- Network administrators may use tc with BPF filters for legitimate traffic management tasks. Identify and document these use cases, then create exceptions for specific command patterns or user accounts involved in these activities.
+- Automated scripts or system management tools that configure network interfaces might use tc with BPF filters. Review these scripts and tools, and if they are verified as safe, exclude their process signatures from triggering the rule.
+- Regular audits of network configurations can help distinguish between legitimate and suspicious use of BPF filters. Implement a process to regularly review and update exceptions based on these audits to minimize false positives.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further manipulation or monitoring of network traffic by the adversary.
+- Terminate the suspicious `tc` process to stop any ongoing malicious activity related to the BPF filter application.
+- Conduct a thorough review of network traffic logs to identify any unauthorized data exfiltration or communication with known malicious IP addresses.
+- Restore the affected system from a known good backup to ensure that no malicious configurations or software persist.
+- Implement network segmentation to limit the potential impact of similar threats in the future, ensuring critical systems are isolated from less secure areas.
+- Escalate the incident to the security operations center (SOC) for further investigation and to determine if additional systems are compromised.
+- Update and enhance endpoint detection and response (EDR) solutions to improve monitoring and alerting for similar suspicious activities involving `tc` and BPF filters."""
 references = [
     "https://github.com/h3xduck/TripleCross/blob/master/src/helpers/deployer.sh",
     "https://man7.org/linux/man-pages/man8/tc.8.html",
@@ -70,40 +102,6 @@ process where host.os.type == "linux" and event.type == "start" and process.exec
 process.args == "filter" and process.args == "add" and process.args == "bpf" and
 not process.parent.executable == "/usr/sbin/libvirtd"
 '''
-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 BPF filter applied using TC
-
-BPF (Berkeley Packet Filter) is a powerful tool for network traffic analysis and control, often used with the `tc` command to manage traffic on Linux systems. Adversaries may exploit this by setting BPF filters to manipulate or monitor network traffic covertly. The detection rule identifies suspicious use of `tc` to apply BPF filters, flagging potential misuse by checking for specific command patterns and excluding legitimate processes.
-
-### Possible investigation steps
-
-- Review the process execution details to confirm the presence of the `/usr/sbin/tc` command with arguments "filter", "add", and "bpf" to ensure the alert is not a false positive.
-- Investigate the parent process of the `tc` command to determine if it is a known legitimate process or if it appears suspicious, especially since the rule excludes `/usr/sbin/libvirtd`.
-- Check the user account associated with the process execution to assess if it is a privileged account and whether the activity aligns with the user's typical behavior.
-- Analyze network traffic logs around the time of the alert to identify any unusual patterns or connections that may indicate malicious activity.
-- Correlate this event with other security alerts or logs to identify if this is part of a broader attack pattern or campaign, such as the use of the TripleCross threat.
-- Review system logs for any other suspicious activities or anomalies that occurred before or after the alert to gather additional context.
-
-### False positive analysis
-
-- Legitimate use of tc by virtualization software like libvirtd can trigger the rule. To handle this, exclude processes where the parent executable is /usr/sbin/libvirtd, as indicated in the rule.
-- Network administrators may use tc with BPF filters for legitimate traffic management tasks. Identify and document these use cases, then create exceptions for specific command patterns or user accounts involved in these activities.
-- Automated scripts or system management tools that configure network interfaces might use tc with BPF filters. Review these scripts and tools, and if they are verified as safe, exclude their process signatures from triggering the rule.
-- Regular audits of network configurations can help distinguish between legitimate and suspicious use of BPF filters. Implement a process to regularly review and update exceptions based on these audits to minimize false positives.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further manipulation or monitoring of network traffic by the adversary.
-- Terminate the suspicious `tc` process to stop any ongoing malicious activity related to the BPF filter application.
-- Conduct a thorough review of network traffic logs to identify any unauthorized data exfiltration or communication with known malicious IP addresses.
-- Restore the affected system from a known good backup to ensure that no malicious configurations or software persist.
-- Implement network segmentation to limit the potential impact of similar threats in the future, ensuring critical systems are isolated from less secure areas.
-- Escalate the incident to the security operations center (SOC) for further investigation and to determine if additional systems are compromised.
-- Update and enhance endpoint detection and response (EDR) solutions to improve monitoring and alerting for similar suspicious activities involving `tc` and BPF filters."""
 
 
 [[rule.threat]]

rules/linux/execution_unix_socket_communication.toml

@@ -2,9 +2,7 @@
 creation_date = "2023/09/04"
 integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
-min_stack_version = "8.13.0"
-min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/03/04"
+updated_date = "2025/03/20"
 
 [rule]
 author = ["Elastic"]
@@ -15,42 +13,17 @@ privileges or set up malicious communication channels via Unix sockets for inter
 evade detection.
 """
 from = "now-9m"
-index = ["auditbeat-*", "endgame-*", "logs-auditd_manager.auditd-*", "logs-crowdstrike.fdr*", "logs-endpoint.events.process*", "logs-sentinel_one_cloud_funnel.*"]
+index = [
+    "auditbeat-*",
+    "endgame-*",
+    "logs-auditd_manager.auditd-*",
+    "logs-crowdstrike.fdr*",
+    "logs-endpoint.events.process*",
+    "logs-sentinel_one_cloud_funnel.*",
+]
 language = "eql"
 license = "Elastic License v2"
 name = "Unix Socket Connection"
-risk_score = 21
-rule_id = "41284ba3-ed1a-4598-bfba-a97f75d9aba2"
-severity = "low"
-tags = [
-    "Domain: Endpoint",
-    "OS: Linux",
-    "Use Case: Threat Detection",
-    "Tactic: Execution",
-    "Data Source: Elastic Defend",
-    "Data Source: Elastic Endgame",
-    "Data Source: Auditd Manager",
-    "Data Source: Crowdstrike",
-    "Data Source: SentinelOne",
-    "Resources: Investigation Guide",
-]
-timestamp_override = "event.ingested"
-type = "eql"
-query = '''
-process where host.os.type == "linux" and event.type == "start" and
- event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and
- (
-  (process.name in ("nc", "ncat", "netcat", "nc.openbsd") and
-   process.args == "-U" and process.args : ("/usr/local/*", "/run/*", "/var/run/*")) or
-  (process.name == "socat" and
-   process.args == "-" and process.args : ("UNIX-CLIENT:/usr/local/*", "UNIX-CLIENT:/run/*", "UNIX-CLIENT:/var/run/*")) or
-  (process.name == "curl" and process.args : ("--unix-socket", "--abstract-unix-socket"))
-) and
-not (
-  process.args == "/var/run/libvirt/libvirt-sock" or
-  process.parent.name in ("bundle", "ruby", "haproxystatus.sh")
-)
-'''
 note = """## Triage and analysis
 
 > **Disclaimer**:
@@ -86,16 +59,51 @@ Unix sockets facilitate efficient inter-process communication (IPC) on the same
 - Apply patches or configuration changes to address any vulnerabilities or misconfigurations identified during the investigation.
 - Monitor the affected system and network for any signs of recurring suspicious activity, focusing on Unix socket connections.
 - Escalate the incident to the security operations team for further analysis and to determine if additional systems may be affected."""
+risk_score = 21
+rule_id = "41284ba3-ed1a-4598-bfba-a97f75d9aba2"
+severity = "low"
+tags = [
+    "Domain: Endpoint",
+    "OS: Linux",
+    "Use Case: Threat Detection",
+    "Tactic: Execution",
+    "Data Source: Elastic Defend",
+    "Data Source: Elastic Endgame",
+    "Data Source: Auditd Manager",
+    "Data Source: Crowdstrike",
+    "Data Source: SentinelOne",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "eql"
+
+query = '''
+process where host.os.type == "linux" and event.type == "start" and
+ event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and
+ (
+  (process.name in ("nc", "ncat", "netcat", "nc.openbsd") and
+   process.args == "-U" and process.args : ("/usr/local/*", "/run/*", "/var/run/*")) or
+  (process.name == "socat" and
+   process.args == "-" and process.args : ("UNIX-CLIENT:/usr/local/*", "UNIX-CLIENT:/run/*", "UNIX-CLIENT:/var/run/*")) or
+  (process.name == "curl" and process.args : ("--unix-socket", "--abstract-unix-socket"))
+) and
+not (
+  process.args == "/var/run/libvirt/libvirt-sock" or
+  process.parent.name in ("bundle", "ruby", "haproxystatus.sh")
+)
+'''
+
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
-
 [[rule.threat.technique]]
 id = "T1559"
 name = "Inter-Process Communication"
 reference = "https://attack.mitre.org/techniques/T1559/"
 
+
 [rule.threat.tactic]
 id = "TA0002"
 name = "Execution"
 reference = "https://attack.mitre.org/tactics/TA0002/"
+

rules/linux/execution_unusual_pkexec_execution.toml

@@ -2,23 +2,60 @@
 creation_date = "2025/01/16"
 integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
-updated_date = "2025/01/23"
-min_stack_version = "8.13.0"
-min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
+updated_date = "2025/03/20"
 
 [rule]
 author = ["Elastic"]
 description = """
-This rule detects the execution of the `pkexec` command by a shell process. The `pkexec` command is used to
-execute programs as another user, typically as the superuser. Through the `new_terms` rule type, unusual 
-executions of `pkexec` are identified, and may indicate an attempt to escalate privileges or perform
-unauthorized actions on the system.
+This rule detects the execution of the `pkexec` command by a shell process. The `pkexec` command is used to execute
+programs as another user, typically as the superuser. Through the `new_terms` rule type, unusual executions of `pkexec`
+are identified, and may indicate an attempt to escalate privileges or perform unauthorized actions on the system.
 """
 from = "now-9m"
-index = ["logs-endpoint.events.process*", "endgame-*", "logs-crowdstrike.fdr*", "logs-sentinel_one_cloud_funnel.*"]
+index = [
+    "logs-endpoint.events.process*",
+    "endgame-*",
+    "logs-crowdstrike.fdr*",
+    "logs-sentinel_one_cloud_funnel.*",
+]
 language = "kuery"
 license = "Elastic License v2"
 name = "Unusual Pkexec Execution"
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
+
+### Investigating Unusual Pkexec Execution
+
+`Pkexec` is a command-line utility in Linux environments that allows users to execute commands as another user, often with elevated privileges. Adversaries may exploit `pkexec` to escalate privileges or execute unauthorized actions by invoking it through shell processes. The detection rule identifies atypical `pkexec` executions initiated by common shell interpreters, flagging potential misuse by monitoring specific process attributes and execution patterns.
+
+### Possible investigation steps
+
+- Review the process tree to understand the context of the pkexec execution, focusing on the parent process names such as bash, dash, sh, tcsh, csh, zsh, ksh, or fish, as these are indicative of shell-based invocations.
+- Examine the command-line arguments passed to pkexec to determine the intended action and assess whether it aligns with expected administrative tasks or appears suspicious.
+- Check the user account associated with the pkexec execution to verify if the account has legitimate reasons to perform such actions, and investigate any anomalies in user behavior or account activity.
+- Investigate the timing and frequency of the pkexec executions to identify patterns or correlations with other suspicious activities or known attack timelines.
+- Cross-reference the alert with other security logs and alerts from data sources like Elastic Endgame, Elastic Defend, Crowdstrike, or SentinelOne to gather additional context and corroborate findings.
+- Assess the system's current state for signs of compromise, such as unauthorized changes, unexpected network connections, or the presence of known malicious files or processes.
+
+### False positive analysis
+
+- Routine administrative tasks: System administrators may use pkexec for legitimate purposes, such as performing maintenance tasks. To handle this, create exceptions for known administrator accounts or specific maintenance scripts that regularly invoke pkexec.
+- Automated scripts: Some automated scripts or cron jobs might use pkexec to perform scheduled tasks. Identify these scripts and exclude their specific process names or paths from the rule to prevent false alerts.
+- Software updates: Certain software update processes might use pkexec to apply patches or updates. Monitor and document these processes, then configure exceptions for recognized update mechanisms.
+- Development environments: Developers might use pkexec during testing or development. Establish a list of development machines or user accounts and exclude them from the rule to reduce noise.
+- Custom user applications: Users may have custom applications that require pkexec for legitimate functionality. Review these applications and whitelist their specific execution patterns to avoid unnecessary alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent potential lateral movement by the adversary.
+- Terminate any suspicious `pkexec` processes identified by the alert to halt unauthorized actions or privilege escalation attempts.
+- Review and analyze the parent shell process and its command history to understand the context and origin of the `pkexec` execution.
+- Reset credentials and review permissions for the user accounts involved to mitigate any unauthorized access or privilege escalation.
+- Conduct a thorough scan of the affected system for additional indicators of compromise or persistence mechanisms that may have been deployed.
+- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected.
+- Update and enhance monitoring rules to detect similar `pkexec` misuse attempts in the future, ensuring comprehensive coverage of shell processes and privilege escalation activities."""
 risk_score = 21
 rule_id = "3ca81a95-d5af-4b77-b0ad-b02bc746f640"
 setup = """## Setup
@@ -72,68 +109,34 @@ tags = [
 ]
 timestamp_override = "event.ingested"
 type = "new_terms"
+
 query = '''
 event.category:process and host.os.type:linux and event.type:start and
 event.action:(exec or exec_event or start or ProcessRollup2) and process.name:pkexec and
 process.args:pkexec and process.parent.name:(bash or dash or sh or tcsh or csh or zsh or ksh or fish)
 '''
-note = """## Triage and analysis
 
-> **Disclaimer**:
-> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
-
-### Investigating Unusual Pkexec Execution
-
-`Pkexec` is a command-line utility in Linux environments that allows users to execute commands as another user, often with elevated privileges. Adversaries may exploit `pkexec` to escalate privileges or execute unauthorized actions by invoking it through shell processes. The detection rule identifies atypical `pkexec` executions initiated by common shell interpreters, flagging potential misuse by monitoring specific process attributes and execution patterns.
-
-### Possible investigation steps
-
-- Review the process tree to understand the context of the pkexec execution, focusing on the parent process names such as bash, dash, sh, tcsh, csh, zsh, ksh, or fish, as these are indicative of shell-based invocations.
-- Examine the command-line arguments passed to pkexec to determine the intended action and assess whether it aligns with expected administrative tasks or appears suspicious.
-- Check the user account associated with the pkexec execution to verify if the account has legitimate reasons to perform such actions, and investigate any anomalies in user behavior or account activity.
-- Investigate the timing and frequency of the pkexec executions to identify patterns or correlations with other suspicious activities or known attack timelines.
-- Cross-reference the alert with other security logs and alerts from data sources like Elastic Endgame, Elastic Defend, Crowdstrike, or SentinelOne to gather additional context and corroborate findings.
-- Assess the system's current state for signs of compromise, such as unauthorized changes, unexpected network connections, or the presence of known malicious files or processes.
-
-### False positive analysis
-
-- Routine administrative tasks: System administrators may use pkexec for legitimate purposes, such as performing maintenance tasks. To handle this, create exceptions for known administrator accounts or specific maintenance scripts that regularly invoke pkexec.
-- Automated scripts: Some automated scripts or cron jobs might use pkexec to perform scheduled tasks. Identify these scripts and exclude their specific process names or paths from the rule to prevent false alerts.
-- Software updates: Certain software update processes might use pkexec to apply patches or updates. Monitor and document these processes, then configure exceptions for recognized update mechanisms.
-- Development environments: Developers might use pkexec during testing or development. Establish a list of development machines or user accounts and exclude them from the rule to reduce noise.
-- Custom user applications: Users may have custom applications that require pkexec for legitimate functionality. Review these applications and whitelist their specific execution patterns to avoid unnecessary alerts.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent potential lateral movement by the adversary.
-- Terminate any suspicious `pkexec` processes identified by the alert to halt unauthorized actions or privilege escalation attempts.
-- Review and analyze the parent shell process and its command history to understand the context and origin of the `pkexec` execution.
-- Reset credentials and review permissions for the user accounts involved to mitigate any unauthorized access or privilege escalation.
-- Conduct a thorough scan of the affected system for additional indicators of compromise or persistence mechanisms that may have been deployed.
-- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected.
-- Update and enhance monitoring rules to detect similar `pkexec` misuse attempts in the future, ensuring comprehensive coverage of shell processes and privilege escalation activities."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
-
 [[rule.threat.technique]]
 id = "T1059"
 name = "Command and Scripting Interpreter"
 reference = "https://attack.mitre.org/techniques/T1059/"
 
+
 [rule.threat.tactic]
 id = "TA0002"
 name = "Execution"
 reference = "https://attack.mitre.org/tactics/TA0002/"
-
 [[rule.threat]]
 framework = "MITRE ATT&CK"
-
 [[rule.threat.technique]]
 id = "T1543"
 name = "Create or Modify System Process"
 reference = "https://attack.mitre.org/techniques/T1543/"
 
+
 [rule.threat.tactic]
 id = "TA0003"
 name = "Persistence"
@@ -142,7 +145,8 @@ reference = "https://attack.mitre.org/tactics/TA0003/"
 [rule.new_terms]
 field = "new_terms_fields"
 value = ["process.parent.command_line"]
-
 [[rule.new_terms.history_window_start]]
 field = "history_window_start"
 value = "now-14d"
+
+

rules/linux/exfiltration_potential_data_splitting_for_exfiltration.toml

@@ -2,9 +2,7 @@
 creation_date = "2024/11/04"
 integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
-min_stack_version = "8.13.0"
-min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/02/04"
+updated_date = "2025/03/20"
 
 [rule]
 author = ["Elastic"]
@@ -14,10 +12,50 @@ for exfiltration on Linux systems. Data splitting is a technique used by adversa
 avoid detection and exfiltrate data.
 """
 from = "now-9m"
-index = ["endgame-*", "logs-crowdstrike.fdr*", "logs-endpoint.events.process*", "logs-sentinel_one_cloud_funnel.*"]
+index = [
+    "endgame-*",
+    "logs-crowdstrike.fdr*",
+    "logs-endpoint.events.process*",
+    "logs-sentinel_one_cloud_funnel.*",
+]
 language = "eql"
 license = "Elastic License v2"
 name = "Potential Data Splitting Detected"
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
+
+### Investigating Potential Data Splitting Detected
+
+Data splitting utilities on Linux, such as `dd` and `split`, are typically used for managing large files by dividing them into smaller, more manageable parts. Adversaries exploit these tools to covertly exfiltrate data by splitting it into inconspicuous segments. The detection rule identifies suspicious use of these utilities by monitoring specific command-line arguments and excluding benign processes, thereby flagging potential exfiltration activities.
+
+### Possible investigation steps
+
+- Review the process details to confirm the use of data splitting utilities like 'dd', 'split', or 'rsplit' with suspicious arguments such as 'bs=*', 'if=*', '-b', or '--bytes*'.
+- Examine the parent process name to ensure it is not a benign process like 'apport' or 'overlayroot', which are excluded in the rule.
+- Investigate the source and destination paths specified in the process arguments to determine if they involve sensitive or unusual locations, excluding paths like '/tmp/nvim*', '/boot/*', or '/dev/urandom'.
+- Check the user account associated with the process to assess if it has a history of legitimate use of these utilities or if it might be compromised.
+- Analyze recent network activity from the host to identify any potential data exfiltration attempts, especially if the process involves external connections.
+- Correlate this alert with other security events or logs from the same host to identify any patterns or additional indicators of compromise.
+
+### False positive analysis
+
+- Processes related to system maintenance or updates, such as those initiated by the 'apport' or 'overlayroot' processes, may trigger false positives. Users can mitigate this by ensuring these parent processes are included in the exclusion list.
+- Backup operations that use 'dd' or 'split' for legitimate data management tasks can be mistaken for exfiltration attempts. Exclude specific backup scripts or processes by adding their unique identifiers or arguments to the exclusion criteria.
+- Development or testing environments where 'dd' or 'split' are used for creating test data or simulating data transfer can generate false alerts. Identify and exclude these environments by specifying their process names or argument patterns.
+- Automated scripts that use 'dd' or 'split' for routine data processing tasks should be reviewed and, if benign, added to the exclusion list to prevent unnecessary alerts.
+- Regular system operations involving '/dev/random', '/dev/urandom', or similar sources should be excluded, as these are common in non-malicious contexts and are already partially covered by the rule's exclusions.
+
+### Response and remediation
+
+- Immediately isolate the affected Linux system from the network to prevent further data exfiltration.
+- Terminate any suspicious processes identified by the detection rule, specifically those involving the `dd`, `split`, or `rsplit` utilities with the flagged arguments.
+- Conduct a thorough review of recent file access and modification logs to identify any unauthorized data handling or exfiltration attempts.
+- Restore any potentially compromised data from secure backups, ensuring that the restored data is free from any malicious alterations.
+- Implement stricter access controls and monitoring on sensitive data directories to prevent unauthorized access and manipulation.
+- Escalate the incident to the security operations center (SOC) for further investigation and to determine if additional systems are affected.
+- Enhance monitoring and alerting for similar suspicious activities by integrating additional threat intelligence sources and refining detection capabilities."""
 risk_score = 21
 rule_id = "e302e6c3-448c-4243-8d9b-d41da70db582"
 setup = """## Setup
@@ -55,10 +93,11 @@ tags = [
     "Data Source: Crowdstrike",
     "Data Source: SentinelOne",
     "Data Source: Elastic Endgame",
-    "Resources: Investigation Guide"
+    "Resources: Investigation Guide",
 ]
 timestamp_override = "event.ingested"
 type = "eql"
+
 query = '''
 process where host.os.type == "linux" and event.type == "start" and
   event.action in ("exec", "exec_event", "start", "ProcessRollup2") and
@@ -80,46 +119,13 @@ process where host.os.type == "linux" and event.type == "start" and
     )
   )
 '''
-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 Data Splitting Detected
-
-Data splitting utilities on Linux, such as `dd` and `split`, are typically used for managing large files by dividing them into smaller, more manageable parts. Adversaries exploit these tools to covertly exfiltrate data by splitting it into inconspicuous segments. The detection rule identifies suspicious use of these utilities by monitoring specific command-line arguments and excluding benign processes, thereby flagging potential exfiltration activities.
-
-### Possible investigation steps
-
-- Review the process details to confirm the use of data splitting utilities like 'dd', 'split', or 'rsplit' with suspicious arguments such as 'bs=*', 'if=*', '-b', or '--bytes*'.
-- Examine the parent process name to ensure it is not a benign process like 'apport' or 'overlayroot', which are excluded in the rule.
-- Investigate the source and destination paths specified in the process arguments to determine if they involve sensitive or unusual locations, excluding paths like '/tmp/nvim*', '/boot/*', or '/dev/urandom'.
-- Check the user account associated with the process to assess if it has a history of legitimate use of these utilities or if it might be compromised.
-- Analyze recent network activity from the host to identify any potential data exfiltration attempts, especially if the process involves external connections.
-- Correlate this alert with other security events or logs from the same host to identify any patterns or additional indicators of compromise.
-
-### False positive analysis
-
-- Processes related to system maintenance or updates, such as those initiated by the 'apport' or 'overlayroot' processes, may trigger false positives. Users can mitigate this by ensuring these parent processes are included in the exclusion list.
-- Backup operations that use 'dd' or 'split' for legitimate data management tasks can be mistaken for exfiltration attempts. Exclude specific backup scripts or processes by adding their unique identifiers or arguments to the exclusion criteria.
-- Development or testing environments where 'dd' or 'split' are used for creating test data or simulating data transfer can generate false alerts. Identify and exclude these environments by specifying their process names or argument patterns.
-- Automated scripts that use 'dd' or 'split' for routine data processing tasks should be reviewed and, if benign, added to the exclusion list to prevent unnecessary alerts.
-- Regular system operations involving '/dev/random', '/dev/urandom', or similar sources should be excluded, as these are common in non-malicious contexts and are already partially covered by the rule's exclusions.
-
-### Response and remediation
-
-- Immediately isolate the affected Linux system from the network to prevent further data exfiltration.
-- Terminate any suspicious processes identified by the detection rule, specifically those involving the `dd`, `split`, or `rsplit` utilities with the flagged arguments.
-- Conduct a thorough review of recent file access and modification logs to identify any unauthorized data handling or exfiltration attempts.
-- Restore any potentially compromised data from secure backups, ensuring that the restored data is free from any malicious alterations.
-- Implement stricter access controls and monitoring on sensitive data directories to prevent unauthorized access and manipulation.
-- Escalate the incident to the security operations center (SOC) for further investigation and to determine if additional systems are affected.
-- Enhance monitoring and alerting for similar suspicious activities by integrating additional threat intelligence sources and refining detection capabilities."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 
-  [rule.threat.tactic]
-  name = "Exfiltration"
-  id = "TA0010"
-  reference = "https://attack.mitre.org/tactics/TA0010/"
+[rule.threat.tactic]
+id = "TA0010"
+name = "Exfiltration"
+reference = "https://attack.mitre.org/tactics/TA0010/"
+

rules/linux/exfiltration_unusual_file_transfer_utility_launched.toml

@@ -2,17 +2,14 @@
 creation_date = "2025/02/21"
 integration = ["endpoint"]
 maturity = "production"
-min_stack_comments = "ES|QL rule type in technical preview as of 8.13"
-min_stack_version = "8.13.0"
-updated_date = "2025/02/21"
+updated_date = "2025/03/20"
 
 [rule]
 author = ["Elastic"]
 description = """
-This rule leverages ES|QL to detect the execution of unusual file transfer utilities on Linux systems.
-Attackers may use these utilities to exfiltrate data from a compromised system. ES|QL rules have
-limited fields available in its alert documents. Make sure to review the original documents to aid
-in the investigation of this alert.
+This rule leverages ES|QL to detect the execution of unusual file transfer utilities on Linux systems. Attackers may use
+these utilities to exfiltrate data from a compromised system. ES|QL rules have limited fields available in its alert
+documents. Make sure to review the original documents to aid in the investigation of this alert.
 """
 from = "now-61m"
 interval = "1h"
@@ -58,6 +55,7 @@ tags = [
 ]
 timestamp_override = "event.ingested"
 type = "esql"
+
 query = '''
 from logs-endpoint.events.process-*
 | keep @timestamp, host.os.type, event.type, event.action, process.name, process.executable, process.parent.executable, process.command_line, agent.id
@@ -70,18 +68,19 @@ from logs-endpoint.events.process-*
 | limit 100
 '''
 
-[[rule.threat]]
-framework = "MITRE ATT&CK"
-
-  [rule.threat.tactic]
-  name = "Exfiltration"
-  id = "TA0010"
-  reference = "https://attack.mitre.org/tactics/TA0010/"
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
 
-  [rule.threat.tactic]
-  name = "Execution"
-  id = "TA0002"
-  reference = "https://attack.mitre.org/tactics/TA0002/"
+[rule.threat.tactic]
+id = "TA0010"
+name = "Exfiltration"
+reference = "https://attack.mitre.org/tactics/TA0010/"
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+
+[rule.threat.tactic]
+id = "TA0002"
+name = "Execution"
+reference = "https://attack.mitre.org/tactics/TA0002/"
+

rules/linux/impact_memory_swap_modification.toml

@@ -2,9 +2,7 @@
 creation_date = "2024/11/04"
 integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
-min_stack_version = "8.13.0"
-min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/02/04"
+updated_date = "2025/03/20"
 
 [rule]
 author = ["Elastic"]
@@ -18,6 +16,41 @@ index = ["endgame-*", "logs-endpoint.events.process*", "logs-sentinel_one_cloud_
 language = "eql"
 license = "Elastic License v2"
 name = "Memory Swap 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 Memory Swap Modification
+
+Memory swap in Linux systems manages RAM by moving inactive pages to disk, freeing up memory for active processes. Adversaries exploit this by altering swap settings to degrade performance or deploy resource-intensive malware like cryptominers. The detection rule identifies suspicious activities by monitoring processes that modify swap settings or execute related commands, flagging potential misuse for further investigation.
+
+### Possible investigation steps
+
+- Review the process details to identify the parent process using the field process.parent.executable. This can help determine if the swap modification was initiated by a legitimate or suspicious parent process.
+- Examine the command line arguments captured in process.command_line to understand the specific changes made to swap settings, such as modifications to vm.swappiness.
+- Check the user account associated with the process to determine if the action was performed by a privileged or unauthorized user.
+- Investigate any recent system performance issues or anomalies that could be linked to swap modifications, such as increased CPU or memory usage.
+- Correlate the event with other security alerts or logs to identify if this activity is part of a larger pattern of suspicious behavior, such as the presence of cryptomining software like XMRig.
+- Assess the system for any unauthorized software installations or configurations that could indicate a compromise, focusing on resource-intensive applications.
+
+### False positive analysis
+
+- System administrators may frequently modify swap settings during routine maintenance or performance tuning. To handle this, create exceptions for known administrator accounts or specific maintenance scripts.
+- Automated configuration management tools like Ansible or Puppet might execute commands that alter swap settings. Identify these tools and exclude their processes from triggering alerts.
+- Some legitimate applications may adjust swap settings to optimize their performance. Monitor and whitelist these applications to prevent unnecessary alerts.
+- Development environments often experiment with system settings, including swap configurations. Consider excluding processes from known development environments or specific user accounts associated with development activities.
+- Scheduled tasks or cron jobs might include swap modification commands for system optimization. Review and whitelist these tasks if they are verified as non-threatening.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further spread or impact of the potential malware.
+- Terminate any suspicious processes identified by the detection rule, such as those involving "swapon", "swapoff", or unauthorized modifications to "vm.swappiness".
+- Conduct a thorough scan of the isolated system using updated antivirus or anti-malware tools to identify and remove any malicious software, particularly cryptominers like XMRig.
+- Review and restore swap settings to their default or secure configurations to ensure system stability and performance.
+- Implement monitoring for any further unauthorized changes to swap settings or related processes to detect and respond to similar threats promptly.
+- Escalate the incident to the security operations team for a detailed forensic analysis to understand the scope and origin of the attack.
+- Update system and security patches to close any vulnerabilities that may have been exploited by the adversary."""
 risk_score = 21
 rule_id = "5e4023e7-6357-4061-ae1c-9df33e78c674"
 setup = """## Setup
@@ -61,6 +94,7 @@ tags = [
 ]
 timestamp_override = "event.ingested"
 type = "eql"
+
 query = '''
 process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start") and
 process.parent.executable != null and
@@ -75,69 +109,35 @@ process.name in ("swapon", "swapoff") or (
 ) and
 not process.parent.name in ("lynis", "systemd", "end-zram-swapping", "SyxsenseResponder", "tuned", "platform-python", "timeout")
 '''
-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 Memory Swap Modification
-
-Memory swap in Linux systems manages RAM by moving inactive pages to disk, freeing up memory for active processes. Adversaries exploit this by altering swap settings to degrade performance or deploy resource-intensive malware like cryptominers. The detection rule identifies suspicious activities by monitoring processes that modify swap settings or execute related commands, flagging potential misuse for further investigation.
-
-### Possible investigation steps
-
-- Review the process details to identify the parent process using the field process.parent.executable. This can help determine if the swap modification was initiated by a legitimate or suspicious parent process.
-- Examine the command line arguments captured in process.command_line to understand the specific changes made to swap settings, such as modifications to vm.swappiness.
-- Check the user account associated with the process to determine if the action was performed by a privileged or unauthorized user.
-- Investigate any recent system performance issues or anomalies that could be linked to swap modifications, such as increased CPU or memory usage.
-- Correlate the event with other security alerts or logs to identify if this activity is part of a larger pattern of suspicious behavior, such as the presence of cryptomining software like XMRig.
-- Assess the system for any unauthorized software installations or configurations that could indicate a compromise, focusing on resource-intensive applications.
-
-### False positive analysis
-
-- System administrators may frequently modify swap settings during routine maintenance or performance tuning. To handle this, create exceptions for known administrator accounts or specific maintenance scripts.
-- Automated configuration management tools like Ansible or Puppet might execute commands that alter swap settings. Identify these tools and exclude their processes from triggering alerts.
-- Some legitimate applications may adjust swap settings to optimize their performance. Monitor and whitelist these applications to prevent unnecessary alerts.
-- Development environments often experiment with system settings, including swap configurations. Consider excluding processes from known development environments or specific user accounts associated with development activities.
-- Scheduled tasks or cron jobs might include swap modification commands for system optimization. Review and whitelist these tasks if they are verified as non-threatening.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further spread or impact of the potential malware.
-- Terminate any suspicious processes identified by the detection rule, such as those involving "swapon", "swapoff", or unauthorized modifications to "vm.swappiness".
-- Conduct a thorough scan of the isolated system using updated antivirus or anti-malware tools to identify and remove any malicious software, particularly cryptominers like XMRig.
-- Review and restore swap settings to their default or secure configurations to ensure system stability and performance.
-- Implement monitoring for any further unauthorized changes to swap settings or related processes to detect and respond to similar threats promptly.
-- Escalate the incident to the security operations team for a detailed forensic analysis to understand the scope and origin of the attack.
-- Update system and security patches to close any vulnerabilities that may have been exploited by the adversary."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1496"
+name = "Resource Hijacking"
+reference = "https://attack.mitre.org/techniques/T1496/"
 
-  [rule.threat.tactic]
-  name = "Impact"
-  id = "TA0040"
-  reference = "https://attack.mitre.org/tactics/TA0040/"
-
-  [[rule.threat.technique]]
-  name = "Resource Hijacking"
-  id = "T1496"
-  reference = "https://attack.mitre.org/techniques/T1496/"
 
+[rule.threat.tactic]
+id = "TA0040"
+name = "Impact"
+reference = "https://attack.mitre.org/tactics/TA0040/"
 [[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]
-  name = "Execution"
-  id = "TA0002"
-  reference = "https://attack.mitre.org/tactics/TA0002/"
 
-  [[rule.threat.technique]]
-  name = "Command and Scripting Interpreter"
-  id = "T1059"
-  reference = "https://attack.mitre.org/techniques/T1059/"
 
-    [[rule.threat.technique.subtechnique]]
-    name = "Unix Shell"
-    id = "T1059.004"
-    reference = "https://attack.mitre.org/techniques/T1059/004/"
+[rule.threat.tactic]
+id = "TA0002"
+name = "Execution"
+reference = "https://attack.mitre.org/tactics/TA0002/"
+

rules/linux/impact_potential_bruteforce_malware_infection.toml

@@ -2,20 +2,18 @@
 creation_date = "2025/02/20"
 integration = ["endpoint"]
 maturity = "production"
-min_stack_comments = "ES|QL rule type in technical preview as of 8.13"
-min_stack_version = "8.13.0"
-updated_date = "2025/02/20"
+updated_date = "2025/03/20"
 
 [rule]
 author = ["Elastic"]
 description = """
 This detection identifies a Linux host that has potentially been infected with malware and is being used to conduct
-brute-force attacks against external systems over SSH (port 22 and common alternative SSH ports). The detection
-looks for a high volume of outbound connection attempts to non-private IP addresses from a single process. A
-compromised host may be part of a botnet or controlled by an attacker, attempting to gain unauthorized access
-to remote systems. This behavior is commonly observed in SSH brute-force campaigns where malware hijacks
-vulnerable machines to expand its attack surface. ES|QL rules have limited fields available in its alert documents.
-Make sure to review the original documents to aid in the investigation of this alert.
+brute-force attacks against external systems over SSH (port 22 and common alternative SSH ports). The detection looks
+for a high volume of outbound connection attempts to non-private IP addresses from a single process. A compromised host
+may be part of a botnet or controlled by an attacker, attempting to gain unauthorized access to remote systems. This
+behavior is commonly observed in SSH brute-force campaigns where malware hijacks vulnerable machines to expand its
+attack surface. ES|QL rules have limited fields available in its alert documents. Make sure to review the original
+documents to aid in the investigation of this alert.
 """
 from = "now-61m"
 interval = "1h"
@@ -61,6 +59,7 @@ tags = [
 ]
 timestamp_override = "event.ingested"
 type = "esql"
+
 query = '''
 from logs-endpoint.events.network-*
 | keep @timestamp, host.os.type, event.type, event.action, destination.port, process.executable, destination.ip, agent.id
@@ -79,46 +78,46 @@ from logs-endpoint.events.network-*
 | limit 100
 '''
 
-[[rule.threat]]
-framework = "MITRE ATT&CK"
-
-  [rule.threat.tactic]
-  name = "Impact"
-  id = "TA0040"
-  reference = "https://attack.mitre.org/tactics/TA0040/"
-
-  [[rule.threat.technique]]
-  name = "Resource Hijacking"
-  id = "T1496"
-  reference = "https://attack.mitre.org/techniques/T1496/"
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1496"
+name = "Resource Hijacking"
+reference = "https://attack.mitre.org/techniques/T1496/"
 
-  [rule.threat.tactic]
-  name = "Execution"
-  id = "TA0002"
-  reference = "https://attack.mitre.org/tactics/TA0002/"
-
-  [[rule.threat.technique]]
-  name = "Command and Scripting Interpreter"
-  id = "T1059"
-  reference = "https://attack.mitre.org/techniques/T1059/"
-
-    [[rule.threat.technique.subtechnique]]
-    name = "Unix Shell"
-    id = "T1059.004"
-    reference = "https://attack.mitre.org/techniques/T1059/004/"
 
+[rule.threat.tactic]
+id = "TA0040"
+name = "Impact"
+reference = "https://attack.mitre.org/tactics/TA0040/"
 [[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 = "TA0011"
-  name = "Command and Control"
-  reference = "https://attack.mitre.org/tactics/TA0011/"
 
-  [[rule.threat.technique]]
-  id = "T1071"
-  name = "Application Layer Protocol"
-  reference = "https://attack.mitre.org/techniques/T1071/"
+
+[rule.threat.tactic]
+id = "TA0002"
+name = "Execution"
+reference = "https://attack.mitre.org/tactics/TA0002/"
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1071"
+name = "Application Layer Protocol"
+reference = "https://attack.mitre.org/techniques/T1071/"
+
+
+[rule.threat.tactic]
+id = "TA0011"
+name = "Command and Control"
+reference = "https://attack.mitre.org/tactics/TA0011/"
+

rules/linux/lateral_movement_ssh_it_worm_download.toml

@@ -2,9 +2,7 @@
 creation_date = "2023/09/21"
 integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
-min_stack_version = "8.13.0"
-min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/02/04"
+updated_date = "2025/03/20"
 
 [rule]
 author = ["Elastic"]
@@ -13,10 +11,51 @@ Identifies processes that are capable of downloading files with command line arg
 autonomous SSH worm. This worm intercepts outgoing SSH connections every time a user uses ssh.
 """
 from = "now-9m"
-index = ["auditbeat-*", "endgame-*", "logs-auditd_manager.auditd-*", "logs-crowdstrike.fdr*", "logs-endpoint.events.process*", "logs-sentinel_one_cloud_funnel.*"]
+index = [
+    "auditbeat-*",
+    "endgame-*",
+    "logs-auditd_manager.auditd-*",
+    "logs-crowdstrike.fdr*",
+    "logs-endpoint.events.process*",
+    "logs-sentinel_one_cloud_funnel.*",
+]
 language = "eql"
 license = "Elastic License v2"
 name = "Potential SSH-IT SSH Worm Downloaded"
+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 SSH-IT SSH Worm Downloaded
+
+SSH-IT is an autonomous worm that exploits SSH connections to propagate across networks. It hijacks outgoing SSH sessions, allowing adversaries to move laterally within a compromised environment. Attackers often use tools like curl or wget to download the worm from specific URLs. The detection rule identifies these download attempts by monitoring process activities on Linux systems, focusing on command-line arguments that match known malicious URLs, thereby alerting security teams to potential threats.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific process name (either curl or wget) and the URL involved in the download attempt to confirm it matches one of the known malicious URLs listed in the query.
+- Check the process execution context, including the user account under which the process was executed, to determine if it was initiated by a legitimate user or potentially compromised account.
+- Investigate the source IP address and hostname of the affected Linux system to understand its role within the network and assess the potential impact of lateral movement.
+- Examine the system's SSH logs to identify any unusual or unauthorized SSH connections that may indicate further compromise or lateral movement attempts.
+- Analyze the network traffic logs for any outbound connections to the identified malicious URLs to confirm whether the download attempt was successful and if any additional payloads were retrieved.
+- Review historical alerts and logs for any previous similar activities on the same host or user account to identify patterns or repeated attempts that may indicate a persistent threat.
+
+### False positive analysis
+
+- Legitimate administrative tasks using curl or wget to download files from the internet may trigger the rule. To manage this, security teams can create exceptions for specific URLs or IP addresses known to be safe and frequently accessed by administrators.
+- Automated scripts or cron jobs that use curl or wget to download updates or configuration files from trusted internal or external sources might be flagged. Users can whitelist these scripts or the specific URLs they access to prevent unnecessary alerts.
+- Development or testing environments where developers frequently download open-source tools or libraries using curl or wget could generate false positives. Implementing a policy to exclude these environments from the rule or setting up a separate monitoring profile for them can help reduce noise.
+- Security tools or monitoring solutions that use curl or wget for health checks or data collection might be mistakenly identified. Identifying these tools and excluding their known benign activities from the rule can help maintain focus on genuine threats.
+
+### Response and remediation
+
+- Immediately isolate the affected host from the network to prevent further lateral movement by the SSH-IT worm.
+- Terminate any suspicious processes identified as using curl or wget with the malicious URLs to stop the download and execution of the worm.
+- Conduct a thorough scan of the isolated host using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any instances of the SSH-IT worm.
+- Review and reset credentials for any SSH accounts that may have been compromised, ensuring the use of strong, unique passwords and considering the implementation of multi-factor authentication (MFA).
+- Analyze network logs and SSH access logs to identify any lateral movement or unauthorized access attempts, and take steps to secure any other potentially compromised systems.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.
+- Update firewall and intrusion detection/prevention system (IDS/IPS) rules to block the known malicious URLs and monitor for any future attempts to access them."""
 references = ["https://www.thc.org/ssh-it/"]
 risk_score = 47
 rule_id = "2ddc468e-b39b-4f5b-9825-f3dcb0e998ea"
@@ -70,40 +109,6 @@ process where host.os.type == "linux" and event.type == "start" and
   "https://thc.org/ssh-it/bs", "http://nossl.segfault.net/bs"
 )
 '''
-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 SSH-IT SSH Worm Downloaded
-
-SSH-IT is an autonomous worm that exploits SSH connections to propagate across networks. It hijacks outgoing SSH sessions, allowing adversaries to move laterally within a compromised environment. Attackers often use tools like curl or wget to download the worm from specific URLs. The detection rule identifies these download attempts by monitoring process activities on Linux systems, focusing on command-line arguments that match known malicious URLs, thereby alerting security teams to potential threats.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific process name (either curl or wget) and the URL involved in the download attempt to confirm it matches one of the known malicious URLs listed in the query.
-- Check the process execution context, including the user account under which the process was executed, to determine if it was initiated by a legitimate user or potentially compromised account.
-- Investigate the source IP address and hostname of the affected Linux system to understand its role within the network and assess the potential impact of lateral movement.
-- Examine the system's SSH logs to identify any unusual or unauthorized SSH connections that may indicate further compromise or lateral movement attempts.
-- Analyze the network traffic logs for any outbound connections to the identified malicious URLs to confirm whether the download attempt was successful and if any additional payloads were retrieved.
-- Review historical alerts and logs for any previous similar activities on the same host or user account to identify patterns or repeated attempts that may indicate a persistent threat.
-
-### False positive analysis
-
-- Legitimate administrative tasks using curl or wget to download files from the internet may trigger the rule. To manage this, security teams can create exceptions for specific URLs or IP addresses known to be safe and frequently accessed by administrators.
-- Automated scripts or cron jobs that use curl or wget to download updates or configuration files from trusted internal or external sources might be flagged. Users can whitelist these scripts or the specific URLs they access to prevent unnecessary alerts.
-- Development or testing environments where developers frequently download open-source tools or libraries using curl or wget could generate false positives. Implementing a policy to exclude these environments from the rule or setting up a separate monitoring profile for them can help reduce noise.
-- Security tools or monitoring solutions that use curl or wget for health checks or data collection might be mistakenly identified. Identifying these tools and excluding their known benign activities from the rule can help maintain focus on genuine threats.
-
-### Response and remediation
-
-- Immediately isolate the affected host from the network to prevent further lateral movement by the SSH-IT worm.
-- Terminate any suspicious processes identified as using curl or wget with the malicious URLs to stop the download and execution of the worm.
-- Conduct a thorough scan of the isolated host using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any instances of the SSH-IT worm.
-- Review and reset credentials for any SSH accounts that may have been compromised, ensuring the use of strong, unique passwords and considering the implementation of multi-factor authentication (MFA).
-- Analyze network logs and SSH access logs to identify any lateral movement or unauthorized access attempts, and take steps to secure any other potentially compromised systems.
-- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.
-- Update firewall and intrusion detection/prevention system (IDS/IPS) rules to block the known malicious URLs and monitor for any future attempts to access them."""
 
 
 [[rule.threat]]

rules/linux/lateral_movement_telnet_network_activity_external.toml

@@ -2,9 +2,7 @@
 creation_date = "2020/04/23"
 integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
-min_stack_version = "8.13.0"
-min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/02/04"
+updated_date = "2025/03/20"
 
 [rule]
 author = ["Elastic"]
@@ -25,6 +23,40 @@ index = ["logs-endpoint.events.network*", "logs-endpoint.events.process*", "logs
 language = "eql"
 license = "Elastic License v2"
 name = "Connection to External Network via Telnet"
+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 Connection to External Network via Telnet
+
+Telnet is a protocol offering a command-line interface for remote communication, often used for device management. However, its lack of encryption makes it vulnerable to interception, allowing adversaries to exploit it for unauthorized access or data exfiltration. The detection rule identifies Telnet connections to external IPs, flagging potential lateral movement by excluding known internal and reserved IP ranges.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific process.entity_id and destination IP address involved in the Telnet connection.
+- Verify the legitimacy of the destination IP address by checking if it belongs to a known or trusted external entity, using threat intelligence sources or IP reputation services.
+- Investigate the process details associated with the process.entity_id to determine the user account and command line arguments used during the Telnet session.
+- Check the system logs and user activity on the host to identify any unusual behavior or unauthorized access attempts around the time of the Telnet connection.
+- Assess whether the Telnet connection aligns with expected business operations or if it indicates potential lateral movement or data exfiltration attempts.
+
+### False positive analysis
+
+- Internal device management using Telnet may trigger false positives if the destination IPs are not included in the known internal ranges. Users should verify and update the list of internal IP ranges to include any additional internal networks used for legitimate Telnet connections.
+- Automated scripts or monitoring tools that use Telnet for legitimate purposes can cause false positives. Identify these scripts and consider creating exceptions for their specific IP addresses or process names to prevent unnecessary alerts.
+- Testing environments that simulate external connections for development purposes might be flagged. Ensure that IP addresses used in these environments are documented and excluded from the detection rule to avoid false positives.
+- Legacy systems that rely on Telnet for communication with external partners or services may be mistakenly flagged. Review these systems and, if deemed secure, add their IP addresses to an exception list to reduce false alerts.
+- Misconfigured network devices that inadvertently use Telnet for external communication can trigger alerts. Regularly audit network configurations and update the detection rule to exclude known benign IPs associated with these devices.
+
+### Response and remediation
+
+- Immediately isolate the affected Linux host from the network to prevent further unauthorized access or data exfiltration.
+- Terminate any active Telnet sessions on the affected host to stop ongoing malicious activity.
+- Conduct a thorough review of the affected system's logs and processes to identify any unauthorized changes or additional compromised accounts.
+- Change all passwords associated with the affected system and any other systems that may have been accessed using Telnet.
+- Apply security patches and updates to the affected system to address any vulnerabilities that may have been exploited.
+- Implement network segmentation to limit Telnet access to only necessary internal systems and block Telnet traffic to external networks.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected."""
 references = ["https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml"]
 risk_score = 47
 rule_id = "e19e64ee-130e-4c07-961f-8a339f0b8362"
@@ -89,40 +121,6 @@ sequence by process.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 Connection to External Network via Telnet
-
-Telnet is a protocol offering a command-line interface for remote communication, often used for device management. However, its lack of encryption makes it vulnerable to interception, allowing adversaries to exploit it for unauthorized access or data exfiltration. The detection rule identifies Telnet connections to external IPs, flagging potential lateral movement by excluding known internal and reserved IP ranges.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific process.entity_id and destination IP address involved in the Telnet connection.
-- Verify the legitimacy of the destination IP address by checking if it belongs to a known or trusted external entity, using threat intelligence sources or IP reputation services.
-- Investigate the process details associated with the process.entity_id to determine the user account and command line arguments used during the Telnet session.
-- Check the system logs and user activity on the host to identify any unusual behavior or unauthorized access attempts around the time of the Telnet connection.
-- Assess whether the Telnet connection aligns with expected business operations or if it indicates potential lateral movement or data exfiltration attempts.
-
-### False positive analysis
-
-- Internal device management using Telnet may trigger false positives if the destination IPs are not included in the known internal ranges. Users should verify and update the list of internal IP ranges to include any additional internal networks used for legitimate Telnet connections.
-- Automated scripts or monitoring tools that use Telnet for legitimate purposes can cause false positives. Identify these scripts and consider creating exceptions for their specific IP addresses or process names to prevent unnecessary alerts.
-- Testing environments that simulate external connections for development purposes might be flagged. Ensure that IP addresses used in these environments are documented and excluded from the detection rule to avoid false positives.
-- Legacy systems that rely on Telnet for communication with external partners or services may be mistakenly flagged. Review these systems and, if deemed secure, add their IP addresses to an exception list to reduce false alerts.
-- Misconfigured network devices that inadvertently use Telnet for external communication can trigger alerts. Regularly audit network configurations and update the detection rule to exclude known benign IPs associated with these devices.
-
-### Response and remediation
-
-- Immediately isolate the affected Linux host from the network to prevent further unauthorized access or data exfiltration.
-- Terminate any active Telnet sessions on the affected host to stop ongoing malicious activity.
-- Conduct a thorough review of the affected system's logs and processes to identify any unauthorized changes or additional compromised accounts.
-- Change all passwords associated with the affected system and any other systems that may have been accessed using Telnet.
-- Apply security patches and updates to the affected system to address any vulnerabilities that may have been exploited.
-- Implement network segmentation to limit Telnet access to only necessary internal systems and block Telnet traffic to external networks.
-- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected."""
 
 
 [[rule.threat]]

rules/linux/lateral_movement_telnet_network_activity_internal.toml

@@ -2,9 +2,7 @@
 creation_date = "2020/04/23"
 integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
-min_stack_version = "8.13.0"
-min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/02/04"
+updated_date = "2025/03/20"
 
 [rule]
 author = ["Elastic"]
@@ -25,6 +23,41 @@ index = ["logs-endpoint.events.network*", "logs-endpoint.events.process*", "logs
 language = "eql"
 license = "Elastic License v2"
 name = "Connection to Internal Network via Telnet"
+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 Connection to Internal Network via Telnet
+
+Telnet is a protocol offering a command-line interface for remote device management, often used in network environments. Adversaries may exploit Telnet to move laterally within a network, accessing non-public IPs to execute commands or exfiltrate data. The detection rule identifies Telnet connections to internal IP ranges, flagging potential unauthorized access attempts, thus aiding in early threat detection and response.
+
+### Possible investigation steps
+
+- Review the process details to confirm the Telnet connection initiation by examining the process.entity_id and process.name fields to ensure the process is indeed Telnet.
+- Analyze the destination IP address to determine if it falls within the specified non-public IP ranges, indicating an internal network connection attempt.
+- Check the event.type field to verify that the Telnet process event is of type "start", confirming the initiation of a connection.
+- Investigate the source host by reviewing host.os.type and other relevant host details to understand the context and legitimacy of the connection attempt.
+- Correlate the Telnet activity with any other suspicious network or process activities on the same host to identify potential lateral movement or data exfiltration attempts.
+- Consult historical logs and alerts to determine if there have been previous similar Telnet connection attempts from the same source, which might indicate a pattern or ongoing threat.
+
+### False positive analysis
+
+- Routine administrative tasks using Telnet within internal networks can trigger false positives. To manage this, create exceptions for known IP addresses or specific user accounts that regularly perform these tasks.
+- Automated scripts or monitoring tools that use Telnet for legitimate purposes may be flagged. Identify these scripts and whitelist their associated processes or IP addresses to prevent unnecessary alerts.
+- Internal testing environments often simulate network activities, including Telnet connections. Exclude IP ranges associated with these environments to reduce false positives.
+- Legacy systems that rely on Telnet for communication might generate alerts. Document these systems and apply exceptions based on their IP addresses or hostnames to avoid repeated false positives.
+- Regularly review and update the list of excluded IPs and processes to ensure that only legitimate activities are exempted, maintaining the effectiveness of the detection rule.
+
+### Response and remediation
+
+- Immediately isolate the affected host from the network to prevent further lateral movement or data exfiltration.
+- Terminate any active Telnet sessions on the affected host to stop unauthorized access.
+- Conduct a thorough review of the affected host's system logs and Telnet session logs to identify any unauthorized commands executed or data accessed.
+- Change all credentials that may have been exposed or used during the unauthorized Telnet sessions to prevent further unauthorized access.
+- Apply security patches and updates to the affected host and any other systems that may be vulnerable to similar exploitation.
+- Implement network segmentation to limit Telnet access to only necessary systems and ensure that Telnet is disabled on systems where it is not required.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems have been compromised."""
 references = ["https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml"]
 risk_score = 47
 rule_id = "1b21abcc-4d9f-4b08-a7f5-316f5f94b973"
@@ -89,41 +122,6 @@ sequence by process.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 Connection to Internal Network via Telnet
-
-Telnet is a protocol offering a command-line interface for remote device management, often used in network environments. Adversaries may exploit Telnet to move laterally within a network, accessing non-public IPs to execute commands or exfiltrate data. The detection rule identifies Telnet connections to internal IP ranges, flagging potential unauthorized access attempts, thus aiding in early threat detection and response.
-
-### Possible investigation steps
-
-- Review the process details to confirm the Telnet connection initiation by examining the process.entity_id and process.name fields to ensure the process is indeed Telnet.
-- Analyze the destination IP address to determine if it falls within the specified non-public IP ranges, indicating an internal network connection attempt.
-- Check the event.type field to verify that the Telnet process event is of type "start", confirming the initiation of a connection.
-- Investigate the source host by reviewing host.os.type and other relevant host details to understand the context and legitimacy of the connection attempt.
-- Correlate the Telnet activity with any other suspicious network or process activities on the same host to identify potential lateral movement or data exfiltration attempts.
-- Consult historical logs and alerts to determine if there have been previous similar Telnet connection attempts from the same source, which might indicate a pattern or ongoing threat.
-
-### False positive analysis
-
-- Routine administrative tasks using Telnet within internal networks can trigger false positives. To manage this, create exceptions for known IP addresses or specific user accounts that regularly perform these tasks.
-- Automated scripts or monitoring tools that use Telnet for legitimate purposes may be flagged. Identify these scripts and whitelist their associated processes or IP addresses to prevent unnecessary alerts.
-- Internal testing environments often simulate network activities, including Telnet connections. Exclude IP ranges associated with these environments to reduce false positives.
-- Legacy systems that rely on Telnet for communication might generate alerts. Document these systems and apply exceptions based on their IP addresses or hostnames to avoid repeated false positives.
-- Regularly review and update the list of excluded IPs and processes to ensure that only legitimate activities are exempted, maintaining the effectiveness of the detection rule.
-
-### Response and remediation
-
-- Immediately isolate the affected host from the network to prevent further lateral movement or data exfiltration.
-- Terminate any active Telnet sessions on the affected host to stop unauthorized access.
-- Conduct a thorough review of the affected host's system logs and Telnet session logs to identify any unauthorized commands executed or data accessed.
-- Change all credentials that may have been exposed or used during the unauthorized Telnet sessions to prevent further unauthorized access.
-- Apply security patches and updates to the affected host and any other systems that may be vulnerable to similar exploitation.
-- Implement network segmentation to limit Telnet access to only necessary systems and ensure that Telnet is disabled on systems where it is not required.
-- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems have been compromised."""
 
 
 [[rule.threat]]

rules/linux/persistence_apt_package_manager_execution.toml

@@ -2,9 +2,7 @@
 creation_date = "2024/02/01"
 integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
-min_stack_version = "8.13.0"
-min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/02/04"
+updated_date = "2025/03/20"
 
 [rule]
 author = ["Elastic"]
@@ -20,6 +18,41 @@ index = ["logs-endpoint.events.process*", "logs-sentinel_one_cloud_funnel.*"]
 language = "eql"
 license = "Elastic License v2"
 name = "Suspicious APT Package Manager Execution"
+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 APT Package Manager Execution
+
+The APT package manager is a vital tool for managing software on Debian-based Linux systems, handling tasks like installation and updates. Adversaries may exploit APT by embedding malicious scripts to maintain persistence and control. The detection rule identifies unusual shell or script executions initiated by APT, signaling potential backdoor activities, thus aiding in early threat detection and response.
+
+### Possible investigation steps
+
+- Review the process execution details to identify the specific shell or script that was executed with APT as the parent process. Pay attention to the process names and arguments, such as "bash", "dash", "sh", etc., and the presence of the "-c" argument.
+- Examine the command-line arguments and scripts executed by the suspicious process to determine if they contain any malicious or unexpected commands.
+- Check the parent process details, specifically the APT process, to understand the context in which the shell or script was executed. This includes reviewing any recent package installations or updates that might have triggered the execution.
+- Investigate the user account under which the suspicious process was executed to assess if it has been compromised or if it has elevated privileges that could be exploited.
+- Correlate the event with other security logs or alerts from the same host to identify any additional indicators of compromise or related suspicious activities.
+- Review the system's package management logs to identify any recent changes or anomalies in package installations or updates that could be linked to the suspicious execution.
+
+### False positive analysis
+
+- Legitimate administrative scripts executed by system administrators using APT may trigger the rule. To handle this, identify and document routine administrative tasks and create exceptions for these specific scripts or commands.
+- Automated system maintenance scripts that use APT for updates or installations can be mistaken for suspicious activity. Review and whitelist these scripts by their specific command patterns or script names.
+- Custom software deployment processes that involve APT and shell scripts might be flagged. Analyze these processes and exclude them by defining clear criteria for legitimate deployment activities.
+- Security tools or monitoring solutions that interact with APT for scanning or auditing purposes may cause false positives. Verify these tools' operations and exclude their known benign processes from triggering the rule.
+- Development environments where developers frequently use APT and shell scripts for testing and building software can lead to alerts. Establish a baseline of normal development activities and exclude these from the detection rule.
+
+### Response and remediation
+
+- Isolate the affected host immediately to prevent further unauthorized access or lateral movement within the network.
+- Terminate any suspicious processes identified in the alert, particularly those initiated by the APT package manager that match the query criteria.
+- Conduct a thorough review of the APT configuration files and scripts to identify and remove any injected malicious code or unauthorized modifications.
+- Restore the affected system from a known good backup if malicious modifications are extensive or if the integrity of the system cannot be assured.
+- Update all system packages and apply security patches to mitigate vulnerabilities that may have been exploited by the adversary.
+- Monitor the affected host and network for any signs of re-infection or further suspicious activity, focusing on the execution of shell scripts and unauthorized network connections.
+- Escalate the incident to the security operations team for further investigation and to determine if additional systems have been compromised."""
 references = ["https://www.elastic.co/security-labs/sequel-on-persistence-mechanisms"]
 risk_score = 47
 rule_id = "ad959eeb-2b7b-4722-ba08-a45f6622f005"
@@ -76,41 +109,6 @@ sequence by host.id with maxspan=5s
    )
   ] 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 APT Package Manager Execution
-
-The APT package manager is a vital tool for managing software on Debian-based Linux systems, handling tasks like installation and updates. Adversaries may exploit APT by embedding malicious scripts to maintain persistence and control. The detection rule identifies unusual shell or script executions initiated by APT, signaling potential backdoor activities, thus aiding in early threat detection and response.
-
-### Possible investigation steps
-
-- Review the process execution details to identify the specific shell or script that was executed with APT as the parent process. Pay attention to the process names and arguments, such as "bash", "dash", "sh", etc., and the presence of the "-c" argument.
-- Examine the command-line arguments and scripts executed by the suspicious process to determine if they contain any malicious or unexpected commands.
-- Check the parent process details, specifically the APT process, to understand the context in which the shell or script was executed. This includes reviewing any recent package installations or updates that might have triggered the execution.
-- Investigate the user account under which the suspicious process was executed to assess if it has been compromised or if it has elevated privileges that could be exploited.
-- Correlate the event with other security logs or alerts from the same host to identify any additional indicators of compromise or related suspicious activities.
-- Review the system's package management logs to identify any recent changes or anomalies in package installations or updates that could be linked to the suspicious execution.
-
-### False positive analysis
-
-- Legitimate administrative scripts executed by system administrators using APT may trigger the rule. To handle this, identify and document routine administrative tasks and create exceptions for these specific scripts or commands.
-- Automated system maintenance scripts that use APT for updates or installations can be mistaken for suspicious activity. Review and whitelist these scripts by their specific command patterns or script names.
-- Custom software deployment processes that involve APT and shell scripts might be flagged. Analyze these processes and exclude them by defining clear criteria for legitimate deployment activities.
-- Security tools or monitoring solutions that interact with APT for scanning or auditing purposes may cause false positives. Verify these tools' operations and exclude their known benign processes from triggering the rule.
-- Development environments where developers frequently use APT and shell scripts for testing and building software can lead to alerts. Establish a baseline of normal development activities and exclude these from the detection rule.
-
-### Response and remediation
-
-- Isolate the affected host immediately to prevent further unauthorized access or lateral movement within the network.
-- Terminate any suspicious processes identified in the alert, particularly those initiated by the APT package manager that match the query criteria.
-- Conduct a thorough review of the APT configuration files and scripts to identify and remove any injected malicious code or unauthorized modifications.
-- Restore the affected system from a known good backup if malicious modifications are extensive or if the integrity of the system cannot be assured.
-- Update all system packages and apply security patches to mitigate vulnerabilities that may have been exploited by the adversary.
-- Monitor the affected host and network for any signs of re-infection or further suspicious activity, focusing on the execution of shell scripts and unauthorized network connections.
-- Escalate the incident to the security operations team for further investigation and to determine if additional systems have been compromised."""
 
 
 [[rule.threat]]

rules/linux/persistence_boot_file_copy.toml

@@ -2,17 +2,15 @@
 creation_date = "2025/01/16"
 integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
-min_stack_version = "8.13.0"
-min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/24"
+updated_date = "2025/03/20"
 
 [rule]
 author = ["Elastic"]
 description = """
-This rule detects the process of copying or moving files from or to the `/boot` directory on Linux systems. The
-`/boot` directory contains files that are essential for the system to boot, such as the kernel and initramfs
-images. Attackers may copy or move files to the `/boot` directory to modify the boot process, which can be
-leveraged to maintain access to the system.
+This rule detects the process of copying or moving files from or to the `/boot` directory on Linux systems. The `/boot`
+directory contains files that are essential for the system to boot, such as the kernel and initramfs images. Attackers
+may copy or move files to the `/boot` directory to modify the boot process, which can be leveraged to maintain access to
+the system.
 """
 from = "now-9m"
 index = [
@@ -21,11 +19,44 @@ index = [
     "auditbeat-*",
     "logs-auditd_manager.auditd-*",
     "logs-crowdstrike.fdr*",
-    "logs-sentinel_one_cloud_funnel.*"
+    "logs-sentinel_one_cloud_funnel.*",
 ]
 language = "eql"
 license = "Elastic License v2"
 name = "Boot File Copy"
+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 Boot File Copy
+The `/boot` directory in Linux systems is crucial for storing files necessary for booting, such as the kernel. Adversaries may exploit this by copying or moving files to alter the boot process, potentially gaining persistent access. The 'Boot File Copy' detection rule identifies suspicious file operations in this directory, excluding legitimate processes, to flag potential unauthorized modifications.
+
+### Possible investigation steps
+
+- Review the process details to identify the specific file operation by examining the process name and arguments, particularly focusing on the use of 'cp' or 'mv' commands with paths involving '/boot/*'.
+- Investigate the parent process executable and name to determine if the operation was initiated by a known legitimate process or script, ensuring it is not one of the excluded processes like 'update-initramfs' or 'grub-mkconfig'.
+- Check the user account associated with the process to assess whether it is a privileged account and if the activity aligns with typical user behavior.
+- Analyze recent system logs and audit records for any other suspicious activities or anomalies around the time of the alert to identify potential patterns or related events.
+- Verify the integrity and authenticity of the files in the /boot directory to ensure no unauthorized modifications have been made, focusing on critical files like the kernel and initramfs images.
+- If possible, correlate the alert with other data sources such as Elastic Endgame or Crowdstrike to gather additional context and confirm whether this is part of a broader attack pattern.
+
+### False positive analysis
+
+- System updates and maintenance tasks often involve legitimate processes that interact with the /boot directory. Processes like update-initramfs, dracut, and grub-mkconfig are common during these operations. Users can exclude these processes by adding them to the exception list in the detection rule.
+- Custom scripts or administrative tasks that require copying or moving files to the /boot directory may trigger false positives. Identify these scripts and add their parent process names or paths to the exclusion criteria.
+- Package management operations, such as those involving dpkg or rpm, may also interact with the /boot directory. Exclude paths like /var/lib/dpkg/info/* and /var/tmp/rpm-tmp.* to prevent these from being flagged.
+- Temporary system recovery or installation processes might use directories like /tmp/newroot. Exclude these paths to avoid unnecessary alerts during legitimate recovery operations.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or potential lateral movement by the adversary.
+- Terminate any suspicious processes identified by the detection rule, specifically those involving unauthorized 'cp' or 'mv' operations in the /boot directory.
+- Conduct a thorough review of the /boot directory to identify and remove any unauthorized files or modifications. Restore any altered files from a known good backup if necessary.
+- Check for any unauthorized changes to boot configuration files, such as GRUB or LILO, and restore them to their original state.
+- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected.
+- Implement additional monitoring on the affected system and similar systems to detect any further unauthorized access attempts or modifications.
+- Review and update access controls and permissions for the /boot directory to ensure only authorized processes and users can make changes."""
 risk_score = 21
 rule_id = "5bda8597-69a6-4b9e-87a2-69a7c963ea83"
 setup = """## Setup
@@ -64,6 +95,7 @@ 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
@@ -73,43 +105,10 @@ process.name in ("cp", "mv") and process.parent.executable != null and process.a
   process.parent.args like~ ("/usr/bin/mkinitcpio", "/var/tmp/rpm-tmp.*")
 )
 '''
-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 Boot File Copy
-The `/boot` directory in Linux systems is crucial for storing files necessary for booting, such as the kernel. Adversaries may exploit this by copying or moving files to alter the boot process, potentially gaining persistent access. The 'Boot File Copy' detection rule identifies suspicious file operations in this directory, excluding legitimate processes, to flag potential unauthorized modifications.
-
-### Possible investigation steps
-
-- Review the process details to identify the specific file operation by examining the process name and arguments, particularly focusing on the use of 'cp' or 'mv' commands with paths involving '/boot/*'.
-- Investigate the parent process executable and name to determine if the operation was initiated by a known legitimate process or script, ensuring it is not one of the excluded processes like 'update-initramfs' or 'grub-mkconfig'.
-- Check the user account associated with the process to assess whether it is a privileged account and if the activity aligns with typical user behavior.
-- Analyze recent system logs and audit records for any other suspicious activities or anomalies around the time of the alert to identify potential patterns or related events.
-- Verify the integrity and authenticity of the files in the /boot directory to ensure no unauthorized modifications have been made, focusing on critical files like the kernel and initramfs images.
-- If possible, correlate the alert with other data sources such as Elastic Endgame or Crowdstrike to gather additional context and confirm whether this is part of a broader attack pattern.
-
-### False positive analysis
-
-- System updates and maintenance tasks often involve legitimate processes that interact with the /boot directory. Processes like update-initramfs, dracut, and grub-mkconfig are common during these operations. Users can exclude these processes by adding them to the exception list in the detection rule.
-- Custom scripts or administrative tasks that require copying or moving files to the /boot directory may trigger false positives. Identify these scripts and add their parent process names or paths to the exclusion criteria.
-- Package management operations, such as those involving dpkg or rpm, may also interact with the /boot directory. Exclude paths like /var/lib/dpkg/info/* and /var/tmp/rpm-tmp.* to prevent these from being flagged.
-- Temporary system recovery or installation processes might use directories like /tmp/newroot. Exclude these paths to avoid unnecessary alerts during legitimate recovery operations.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or potential lateral movement by the adversary.
-- Terminate any suspicious processes identified by the detection rule, specifically those involving unauthorized 'cp' or 'mv' operations in the /boot directory.
-- Conduct a thorough review of the /boot directory to identify and remove any unauthorized files or modifications. Restore any altered files from a known good backup if necessary.
-- Check for any unauthorized changes to boot configuration files, such as GRUB or LILO, and restore them to their original state.
-- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected.
-- Implement additional monitoring on the affected system and similar systems to detect any further unauthorized access attempts or modifications.
-- Review and update access controls and permissions for the /boot directory to ensure only authorized processes and users can make changes."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
-
 [[rule.threat.technique]]
 id = "T1542"
 name = "Pre-OS Boot"
@@ -125,29 +124,28 @@ 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"
 
@@ -155,3 +153,4 @@ framework = "MITRE ATT&CK"
 id = "TA0005"
 name = "Defense Evasion"
 reference = "https://attack.mitre.org/tactics/TA0005/"
+

rules/linux/persistence_chkconfig_service_add.toml

@@ -2,9 +2,7 @@
 creation_date = "2022/07/22"
 integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
-min_stack_version = "8.13.0"
-min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/02/04"
+updated_date = "2025/03/20"
 
 [transform]
 [[transform.osquery]]
@@ -176,6 +174,7 @@ tags = [
 ]
 timestamp_override = "event.ingested"
 type = "eql"
+
 query = '''
 process where host.os.type == "linux" and event.action in ("exec", "exec_event", "start") and
 ( 
@@ -188,15 +187,17 @@ process where host.os.type == "linux" and event.action in ("exec", "exec_event",
 )
 '''
 
+
 [[rule.threat]]
 framework = "MITRE ATT&CK"
-
 [[rule.threat.technique]]
 id = "T1037"
 name = "Boot or Logon Initialization Scripts"
 reference = "https://attack.mitre.org/techniques/T1037/"
 
+
 [rule.threat.tactic]
 id = "TA0003"
 name = "Persistence"
 reference = "https://attack.mitre.org/tactics/TA0003/"
+

rules/linux/persistence_dbus_service_creation.toml

@@ -2,24 +2,57 @@
 creation_date = "2025/01/16"
 integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
-min_stack_version = "8.13.0"
-min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/22"
+updated_date = "2025/03/20"
 
 [rule]
 author = ["Elastic"]
 description = """
-This rule detects the creation of D-Bus service files on Linux systems. D-Bus is a message bus system that provides
-a way for applications to talk to one another. D-Bus services are defined in service files that are typically
-located in default directories. The rule looks for the creation of service files that are not associated with
-known package managers or system services. Attackers may create malicious D-Bus services to establish persistence
-or escalate privileges on a system.
+This rule detects the creation of D-Bus service files on Linux systems. D-Bus is a message bus system that provides a
+way for applications to talk to one another. D-Bus services are defined in service files that are typically located in
+default directories. The rule looks for the creation of service files that are not associated with known package
+managers or system services. Attackers may create malicious D-Bus services to establish persistence or escalate
+privileges on a system.
 """
 from = "now-9m"
 index = ["logs-endpoint.events.file*", "logs-sentinel_one_cloud_funnel.*", "endgame-*"]
 language = "eql"
 license = "Elastic License v2"
 name = "D-Bus Service 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 D-Bus Service Created
+
+D-Bus is an inter-process communication system in Linux, enabling applications to communicate. Adversaries may exploit D-Bus by creating unauthorized service files to maintain persistence or escalate privileges. The detection rule identifies suspicious service file creations in key directories, excluding known legitimate processes, to flag potential malicious activity.
+
+### Possible investigation steps
+
+- Review the file path and extension to confirm if the created file is located in one of the monitored directories such as /usr/share/dbus-1/system-services/ or /etc/dbus-1/system.d/, and ensure it has a .service or .conf extension.
+- Examine the process executable that created the file to determine if it is listed as a known legitimate process in the exclusion list. If not, investigate the process further to understand its origin and purpose.
+- Check the process name and path for any unusual or unexpected patterns, especially if it is not part of the known exclusions like ssm-agent-worker or platform-python*.
+- Investigate the file creation time and correlate it with other system activities or logs to identify any suspicious behavior or patterns around the time of the alert.
+- Look into the user account associated with the process that created the file to determine if it has the necessary permissions and if the activity aligns with the user's typical behavior.
+- Search for any related alerts or logs that might indicate a broader attack pattern, such as other unauthorized file creations or modifications in the system.
+
+### False positive analysis
+
+- Package manager operations can trigger false positives when legitimate service files are created during software installations or updates. To manage this, exclude processes associated with known package managers like dpkg, rpm, and yum from the detection rule.
+- System service updates may also result in false positives. Exclude processes such as systemd and crond that are responsible for legitimate system service management.
+- Development and testing environments often involve the creation of temporary or test service files. Exclude paths and processes specific to these environments, such as those under /tmp or /dev/fd, to reduce noise.
+- Automation tools like Puppet and Chef can create service files as part of their configuration management tasks. Exclude these tools by adding their executable paths to the exception list.
+- Custom scripts or tools that mimic package manager behavior might also cause false positives. Identify and exclude these specific scripts or tools by their process names or paths if they are known to be benign.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary.
+- Terminate any suspicious processes associated with the creation of unauthorized D-Bus service files to halt potential malicious activity.
+- Remove any unauthorized D-Bus service files identified in the specified directories to eliminate persistence mechanisms.
+- Conduct a thorough review of user accounts and privileges on the affected system to ensure no unauthorized privilege escalation has occurred.
+- Restore the system from a known good backup if unauthorized changes or damage to the system are detected.
+- Monitor the system and network for any signs of re-infection or similar suspicious activities, using enhanced logging and alerting mechanisms.
+- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected."""
 risk_score = 21
 rule_id = "952c92af-d67f-4f01-8a9c-725efefa7e07"
 setup = """## Setup
@@ -61,6 +94,7 @@ tags = [
 ]
 timestamp_override = "event.ingested"
 type = "eql"
+
 query = '''
 file where host.os.type == "linux" and event.type == "creation" and process.executable != null and
 file.extension in ("service", "conf") and file.path like~ (
@@ -96,64 +130,30 @@ file.extension in ("service", "conf") and file.path like~ (
   (process.name == "perl" and file.name : "e2scrub_all.tmp*") 
 )
 '''
-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 D-Bus Service Created
-
-D-Bus is an inter-process communication system in Linux, enabling applications to communicate. Adversaries may exploit D-Bus by creating unauthorized service files to maintain persistence or escalate privileges. The detection rule identifies suspicious service file creations in key directories, excluding known legitimate processes, to flag potential malicious activity.
-
-### Possible investigation steps
-
-- Review the file path and extension to confirm if the created file is located in one of the monitored directories such as /usr/share/dbus-1/system-services/ or /etc/dbus-1/system.d/, and ensure it has a .service or .conf extension.
-- Examine the process executable that created the file to determine if it is listed as a known legitimate process in the exclusion list. If not, investigate the process further to understand its origin and purpose.
-- Check the process name and path for any unusual or unexpected patterns, especially if it is not part of the known exclusions like ssm-agent-worker or platform-python*.
-- Investigate the file creation time and correlate it with other system activities or logs to identify any suspicious behavior or patterns around the time of the alert.
-- Look into the user account associated with the process that created the file to determine if it has the necessary permissions and if the activity aligns with the user's typical behavior.
-- Search for any related alerts or logs that might indicate a broader attack pattern, such as other unauthorized file creations or modifications in the system.
-
-### False positive analysis
-
-- Package manager operations can trigger false positives when legitimate service files are created during software installations or updates. To manage this, exclude processes associated with known package managers like dpkg, rpm, and yum from the detection rule.
-- System service updates may also result in false positives. Exclude processes such as systemd and crond that are responsible for legitimate system service management.
-- Development and testing environments often involve the creation of temporary or test service files. Exclude paths and processes specific to these environments, such as those under /tmp or /dev/fd, to reduce noise.
-- Automation tools like Puppet and Chef can create service files as part of their configuration management tasks. Exclude these tools by adding their executable paths to the exception list.
-- Custom scripts or tools that mimic package manager behavior might also cause false positives. Identify and exclude these specific scripts or tools by their process names or paths if they are known to be benign.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary.
-- Terminate any suspicious processes associated with the creation of unauthorized D-Bus service files to halt potential malicious activity.
-- Remove any unauthorized D-Bus service files identified in the specified directories to eliminate persistence mechanisms.
-- Conduct a thorough review of user accounts and privileges on the affected system to ensure no unauthorized privilege escalation has occurred.
-- Restore the system from a known good backup if unauthorized changes or damage to the system are detected.
-- Monitor the system and network for any signs of re-infection or similar suspicious activities, using enhanced logging and alerting mechanisms.
-- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected."""
 
 [[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 = "T1543"
 name = "Create or Modify System Process"
 reference = "https://attack.mitre.org/techniques/T1543/"
 
+
 [rule.threat.tactic]
 id = "TA0004"
 name = "Privilege Escalation"
 reference = "https://attack.mitre.org/tactics/TA0004/"
+

rules/linux/persistence_dbus_unsual_daemon_parent_execution.toml

@@ -2,22 +2,55 @@
 creation_date = "2025/01/21"
 integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
-min_stack_version = "8.13.0"
-min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/22"
+updated_date = "2025/03/20"
 
 [rule]
 author = ["Elastic"]
 description = """
 This rule detects when an unusual child process is spawned from the `dbus-daemon` parent process. The `dbus-daemon`
-process is a message bus system that provides a way for applications to talk to each other. Attackers may abuse
-this process to execute malicious code or escalate privileges.
+process is a message bus system that provides a way for applications to talk to each other. Attackers may abuse this
+process to execute malicious code or escalate privileges.
 """
 from = "now-9m"
 index = ["logs-endpoint.events.process*", "endgame-*", "logs-sentinel_one_cloud_funnel.*"]
 language = "eql"
 license = "Elastic License v2"
 name = "Unusual D-Bus Daemon Child Process"
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
+
+### Investigating Unusual D-Bus Daemon Child Process
+
+The D-Bus daemon is a crucial component in Linux environments, facilitating inter-process communication by allowing applications to exchange information. Adversaries may exploit this by spawning unauthorized child processes to execute malicious code or gain elevated privileges. The detection rule identifies anomalies by monitoring child processes of the D-Bus daemon, excluding known benign processes and paths, thus highlighting potential threats.
+
+### Possible investigation steps
+
+- Review the process details to identify the unusual child process spawned from the dbus-daemon, focusing on the process name and executable path to determine if it is known or potentially malicious.
+- Examine the command-line arguments (process.args) of the unusual child process to understand its intended function and assess if it aligns with typical usage patterns.
+- Investigate the parent process arguments (process.parent.args) to confirm whether the dbus-daemon was running in a session context or another mode that might explain the unusual child process.
+- Check the process start time and correlate it with other system events or logs to identify any related activities or anomalies occurring around the same time.
+- Look into the user context under which the unusual child process was executed to determine if it was initiated by a legitimate user or potentially compromised account.
+- Search for any network connections or file modifications associated with the unusual child process to identify potential data exfiltration or lateral movement activities.
+
+### False positive analysis
+
+- Known benign processes such as gnome-keyring-daemon and abrt-dbus may trigger the rule. Users can exclude these processes by adding them to the exception list in the detection rule.
+- Processes executed from common library paths like /usr/lib/ or /usr/local/lib/ are typically non-threatening. Users should review these paths and consider excluding them if they are consistently generating false positives.
+- The dbus-daemon with the --session argument is generally safe. Users can ensure this argument is included in the exception criteria to prevent unnecessary alerts.
+- Specific applications like software-properties-dbus and serviceHelper.py are known to be benign. Users should verify these applications' legitimacy in their environment and exclude them if they are frequently flagged.
+- Regularly review and update the exception list to include any new benign processes or paths that are identified over time, ensuring the rule remains effective without generating excessive false positives.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent potential lateral movement by the adversary.
+- Terminate any suspicious child processes spawned by the dbus-daemon that are not recognized as legitimate or necessary for system operations.
+- Conduct a thorough review of the affected system's logs to identify any unauthorized access or changes made by the suspicious process.
+- Restore any altered or compromised system files from a known good backup to ensure system integrity.
+- Update and patch the affected system and any related software to close vulnerabilities that may have been exploited.
+- Implement stricter access controls and monitoring on the dbus-daemon to prevent unauthorized process execution in the future.
+- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected."""
 risk_score = 21
 rule_id = "9705b458-689a-4ec6-afe8-b4648d090612"
 setup = """## Setup
@@ -60,6 +93,7 @@ tags = [
 ]
 timestamp_override = "event.ingested"
 type = "eql"
+
 query = '''
 process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start") and
 process.parent.name == "dbus-daemon" and process.args_count > 1 and not (
@@ -69,82 +103,47 @@ process.parent.name == "dbus-daemon" and process.args_count > 1 and not (
   process.executable like~ ("/usr/lib/*", "/usr/local/lib/*", "/usr/libexec/*", "/tmp/newroot/*")
 )
 '''
-note = """## Triage and analysis
 
-> **Disclaimer**:
-> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
-
-### Investigating Unusual D-Bus Daemon Child Process
-
-The D-Bus daemon is a crucial component in Linux environments, facilitating inter-process communication by allowing applications to exchange information. Adversaries may exploit this by spawning unauthorized child processes to execute malicious code or gain elevated privileges. The detection rule identifies anomalies by monitoring child processes of the D-Bus daemon, excluding known benign processes and paths, thus highlighting potential threats.
-
-### Possible investigation steps
-
-- Review the process details to identify the unusual child process spawned from the dbus-daemon, focusing on the process name and executable path to determine if it is known or potentially malicious.
-- Examine the command-line arguments (process.args) of the unusual child process to understand its intended function and assess if it aligns with typical usage patterns.
-- Investigate the parent process arguments (process.parent.args) to confirm whether the dbus-daemon was running in a session context or another mode that might explain the unusual child process.
-- Check the process start time and correlate it with other system events or logs to identify any related activities or anomalies occurring around the same time.
-- Look into the user context under which the unusual child process was executed to determine if it was initiated by a legitimate user or potentially compromised account.
-- Search for any network connections or file modifications associated with the unusual child process to identify potential data exfiltration or lateral movement activities.
-
-### False positive analysis
-
-- Known benign processes such as gnome-keyring-daemon and abrt-dbus may trigger the rule. Users can exclude these processes by adding them to the exception list in the detection rule.
-- Processes executed from common library paths like /usr/lib/ or /usr/local/lib/ are typically non-threatening. Users should review these paths and consider excluding them if they are consistently generating false positives.
-- The dbus-daemon with the --session argument is generally safe. Users can ensure this argument is included in the exception criteria to prevent unnecessary alerts.
-- Specific applications like software-properties-dbus and serviceHelper.py are known to be benign. Users should verify these applications' legitimacy in their environment and exclude them if they are frequently flagged.
-- Regularly review and update the exception list to include any new benign processes or paths that are identified over time, ensuring the rule remains effective without generating excessive false positives.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent potential lateral movement by the adversary.
-- Terminate any suspicious child processes spawned by the dbus-daemon that are not recognized as legitimate or necessary for system operations.
-- Conduct a thorough review of the affected system's logs to identify any unauthorized access or changes made by the suspicious process.
-- Restore any altered or compromised system files from a known good backup to ensure system integrity.
-- Update and patch the affected system and any related software to close vulnerabilities that may have been exploited.
-- Implement stricter access controls and monitoring on the dbus-daemon to prevent unauthorized process execution in the future.
-- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected."""
 
 [[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 = "T1543"
 name = "Create or Modify System Process"
 reference = "https://attack.mitre.org/techniques/T1543/"
 
+
 [rule.threat.tactic]
 id = "TA0004"
 name = "Privilege Escalation"
 reference = "https://attack.mitre.org/tactics/TA0004/"
-
 [[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/"
+

rules/linux/persistence_dnf_package_manager_plugin_file_creation.toml

@@ -2,9 +2,7 @@
 creation_date = "2024/06/25"
 integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
-min_stack_version = "8.13.0"
-min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/24"
+updated_date = "2025/03/20"
 
 [rule]
 author = ["Elastic"]
@@ -20,6 +18,42 @@ index = ["logs-endpoint.events.file*", "logs-sentinel_one_cloud_funnel.*", "endg
 language = "eql"
 license = "Elastic License v2"
 name = "DNF Package Manager Plugin 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 DNF Package Manager Plugin File Creation
+
+DNF, a package manager for Fedora-based Linux systems, manages software installations and updates. It uses plugins to extend functionality, which can be targeted by attackers to insert malicious code, ensuring persistence and evasion. The detection rule monitors file creation in plugin directories, excluding legitimate processes, to identify unauthorized modifications indicative of potential backdoor activities.
+
+### Possible investigation steps
+
+- Review the file creation event details, focusing on the file path to confirm if it matches the monitored plugin directories: "/usr/lib/python*/site-packages/dnf-plugins/*" or "/etc/dnf/plugins/*".
+- Identify the process responsible for the file creation by examining the process.executable field, ensuring it is not one of the legitimate processes listed in the exclusion criteria.
+- Check the file extension of the newly created file to ensure it is not one of the excluded extensions like "swp", "swpx", or "swx".
+- Investigate the origin and legitimacy of the process by reviewing its parent process and command line arguments to determine if it aligns with expected behavior.
+- Correlate the event with any recent changes or updates in the system that might explain the file creation, such as package installations or system updates.
+- Search for any additional suspicious activity or anomalies in the system logs around the time of the alert to identify potential indicators of compromise.
+- If the file creation is deemed suspicious, consider isolating the affected system and conducting a deeper forensic analysis to assess the scope and impact of the potential threat.
+
+### False positive analysis
+
+- Legitimate software updates or installations may trigger file creation events in the DNF plugin directories. Users can mitigate this by ensuring that the processes involved in these updates are included in the exclusion list of the detection rule.
+- System maintenance scripts or automated tasks that modify or create files in the plugin directories can be mistaken for malicious activity. To handle this, identify these scripts and add their executables to the exclusion list.
+- Temporary files created by text editors or system processes, such as those with extensions like "swp", "swpx", or "swx", can be excluded by ensuring these extensions are part of the rule's exclusion criteria.
+- Custom scripts or tools that interact with DNF plugins for legitimate purposes should be reviewed and, if deemed safe, their executables should be added to the exclusion list to prevent false positives.
+- Processes running from directories like "/nix/store/*" or "/var/lib/dpkg/*" may be part of legitimate package management activities. Users should verify these processes and include them in the exclusion list if they are non-threatening.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the attacker.
+- Conduct a thorough review of the newly created or modified files in the DNF plugin directories to identify any malicious code or unauthorized changes.
+- Remove any identified malicious files or code from the DNF plugin directories to eliminate the backdoor and restore the integrity of the package manager.
+- Revert any unauthorized changes to the system configuration or software settings to their original state using verified backups or system snapshots.
+- Update all system packages and plugins to the latest versions to patch any vulnerabilities that may have been exploited by the attacker.
+- Monitor the affected system and network for any signs of continued unauthorized access or suspicious activity, using enhanced logging and alerting mechanisms.
+- Escalate the incident to the appropriate internal security team or external cybersecurity experts for further investigation and to ensure comprehensive remediation."""
 references = [
     "https://pwnshift.github.io/2020/10/01/persistence.html",
     "https://www.elastic.co/security-labs/sequel-on-persistence-mechanisms",
@@ -91,42 +125,6 @@ file.path : ("/usr/lib/python*/site-packages/dnf-plugins/*", "/etc/dnf/plugins/*
   process.name like~ ("ssm-agent-worker, NinjaOrbit", "python*")
 )
 '''
-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 DNF Package Manager Plugin File Creation
-
-DNF, a package manager for Fedora-based Linux systems, manages software installations and updates. It uses plugins to extend functionality, which can be targeted by attackers to insert malicious code, ensuring persistence and evasion. The detection rule monitors file creation in plugin directories, excluding legitimate processes, to identify unauthorized modifications indicative of potential backdoor activities.
-
-### Possible investigation steps
-
-- Review the file creation event details, focusing on the file path to confirm if it matches the monitored plugin directories: "/usr/lib/python*/site-packages/dnf-plugins/*" or "/etc/dnf/plugins/*".
-- Identify the process responsible for the file creation by examining the process.executable field, ensuring it is not one of the legitimate processes listed in the exclusion criteria.
-- Check the file extension of the newly created file to ensure it is not one of the excluded extensions like "swp", "swpx", or "swx".
-- Investigate the origin and legitimacy of the process by reviewing its parent process and command line arguments to determine if it aligns with expected behavior.
-- Correlate the event with any recent changes or updates in the system that might explain the file creation, such as package installations or system updates.
-- Search for any additional suspicious activity or anomalies in the system logs around the time of the alert to identify potential indicators of compromise.
-- If the file creation is deemed suspicious, consider isolating the affected system and conducting a deeper forensic analysis to assess the scope and impact of the potential threat.
-
-### False positive analysis
-
-- Legitimate software updates or installations may trigger file creation events in the DNF plugin directories. Users can mitigate this by ensuring that the processes involved in these updates are included in the exclusion list of the detection rule.
-- System maintenance scripts or automated tasks that modify or create files in the plugin directories can be mistaken for malicious activity. To handle this, identify these scripts and add their executables to the exclusion list.
-- Temporary files created by text editors or system processes, such as those with extensions like "swp", "swpx", or "swx", can be excluded by ensuring these extensions are part of the rule's exclusion criteria.
-- Custom scripts or tools that interact with DNF plugins for legitimate purposes should be reviewed and, if deemed safe, their executables should be added to the exclusion list to prevent false positives.
-- Processes running from directories like "/nix/store/*" or "/var/lib/dpkg/*" may be part of legitimate package management activities. Users should verify these processes and include them in the exclusion list if they are non-threatening.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the attacker.
-- Conduct a thorough review of the newly created or modified files in the DNF plugin directories to identify any malicious code or unauthorized changes.
-- Remove any identified malicious files or code from the DNF plugin directories to eliminate the backdoor and restore the integrity of the package manager.
-- Revert any unauthorized changes to the system configuration or software settings to their original state using verified backups or system snapshots.
-- Update all system packages and plugins to the latest versions to patch any vulnerabilities that may have been exploited by the attacker.
-- Monitor the affected system and network for any signs of continued unauthorized access or suspicious activity, using enhanced logging and alerting mechanisms.
-- Escalate the incident to the appropriate internal security team or external cybersecurity experts for further investigation and to ensure comprehensive remediation."""
 
 
 [[rule.threat]]

rules/linux/persistence_dracut_module_creation.toml

@@ -2,23 +2,56 @@
 creation_date = "2025/01/16"
 integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
-min_stack_version = "8.13.0"
-min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/22"
+updated_date = "2025/03/20"
 
 [rule]
 author = ["Elastic"]
 description = """
-This rule detects the creation of Dracut module files on Linux systems. Dracut is a tool used to generate an
-initramfs image that is used to boot the system. Dracut modules are scripts that are executed during the
-initramfs image generation process. Attackers may create malicious Dracut modules to execute arbitrary code
-at boot time, which can be leveraged to maintain persistence on a Linux system.
+This rule detects the creation of Dracut module files on Linux systems. Dracut is a tool used to generate an initramfs
+image that is used to boot the system. Dracut modules are scripts that are executed during the initramfs image
+generation process. Attackers may create malicious Dracut modules to execute arbitrary code at boot time, which can be
+leveraged to maintain persistence on a Linux system.
 """
 from = "now-9m"
 index = ["logs-endpoint.events.file*", "logs-sentinel_one_cloud_funnel.*", "endgame-*"]
 language = "eql"
 license = "Elastic License v2"
 name = "Dracut Module 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 Dracut Module Creation
+
+Dracut is a utility for generating initramfs images, crucial for booting Linux systems. It uses modules, which are scripts executed during image creation. Adversaries may exploit this by crafting malicious modules to execute code at boot, ensuring persistence. The detection rule identifies unauthorized module creation by monitoring file paths and excluding known legitimate processes, helping to flag potential threats.
+
+### Possible investigation steps
+
+- Review the file path of the created Dracut module to determine if it matches known legitimate paths or if it appears suspicious, focusing on paths like "/lib/dracut/modules.d/*" and "/usr/lib/dracut/modules.d/*".
+- Identify the process that created the Dracut module by examining the process.executable field, and verify if it is listed in the known legitimate processes or if it is an unexpected process.
+- Check the file extension of the created module to ensure it is not one of the excluded extensions such as "swp", "swpx", "swx", or "dpkg-remove".
+- Investigate the history and behavior of the process that created the module, including its parent process and any associated network activity, to assess if it has been involved in other suspicious activities.
+- Correlate the alert with other security events or logs from the same host to identify any patterns or additional indicators of compromise that might suggest malicious activity.
+- Consult threat intelligence sources to determine if there are any known threats or campaigns associated with the process or file path involved in the alert.
+
+### False positive analysis
+
+- Package managers like dpkg, rpm, and yum may trigger false positives when they update or install packages. To handle this, ensure these processes are included in the exclusion list within the detection rule.
+- Automated system management tools such as Puppet, Chef, and Ansible can create or modify Dracut modules as part of their configuration management tasks. Add these tools to the exclusion list to prevent false alerts.
+- System updates or maintenance scripts that run as part of regular system operations might be flagged. Review these scripts and add their executables to the exclusion list if they are verified as non-threatening.
+- Custom scripts or applications that interact with Dracut modules for legitimate purposes should be reviewed and, if deemed safe, added to the exclusion list to avoid unnecessary alerts.
+- Temporary files or backup files with extensions like swp or dpkg-remove may be mistakenly flagged. Ensure these extensions are included in the exclusion criteria to reduce false positives.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further spread or communication with potential command and control servers.
+- Conduct a thorough review of the Dracut module files located in the specified directories (/lib/dracut/modules.d/*, /usr/lib/dracut/modules.d/*) to identify and remove any unauthorized or suspicious modules.
+- Restore the system from a known good backup if malicious Dracut modules are confirmed, ensuring that the backup predates the unauthorized changes.
+- Implement additional monitoring on the affected system to detect any further unauthorized Dracut module creation or other suspicious activities.
+- Review and tighten access controls and permissions for the directories and processes involved in Dracut module creation to prevent unauthorized modifications.
+- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected.
+- Update and enhance detection capabilities to include alerts for any future unauthorized Dracut module creation attempts, leveraging the specific indicators identified in this incident."""
 risk_score = 21
 rule_id = "dc765fb2-0c99-4e57-8c11-dafdf1992b66"
 setup = """## Setup
@@ -57,6 +90,7 @@ tags = [
 ]
 timestamp_override = "event.ingested"
 type = "eql"
+
 query = '''
 file where host.os.type == "linux" and event.type == "creation" and process.executable != null and
 file.path like~ ("/lib/dracut/modules.d/*", "/usr/lib/dracut/modules.d/*") and not (
@@ -81,45 +115,10 @@ file.path like~ ("/lib/dracut/modules.d/*", "/usr/lib/dracut/modules.d/*") and n
   (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 Dracut Module Creation
-
-Dracut is a utility for generating initramfs images, crucial for booting Linux systems. It uses modules, which are scripts executed during image creation. Adversaries may exploit this by crafting malicious modules to execute code at boot, ensuring persistence. The detection rule identifies unauthorized module creation by monitoring file paths and excluding known legitimate processes, helping to flag potential threats.
-
-### Possible investigation steps
-
-- Review the file path of the created Dracut module to determine if it matches known legitimate paths or if it appears suspicious, focusing on paths like "/lib/dracut/modules.d/*" and "/usr/lib/dracut/modules.d/*".
-- Identify the process that created the Dracut module by examining the process.executable field, and verify if it is listed in the known legitimate processes or if it is an unexpected process.
-- Check the file extension of the created module to ensure it is not one of the excluded extensions such as "swp", "swpx", "swx", or "dpkg-remove".
-- Investigate the history and behavior of the process that created the module, including its parent process and any associated network activity, to assess if it has been involved in other suspicious activities.
-- Correlate the alert with other security events or logs from the same host to identify any patterns or additional indicators of compromise that might suggest malicious activity.
-- Consult threat intelligence sources to determine if there are any known threats or campaigns associated with the process or file path involved in the alert.
-
-### False positive analysis
-
-- Package managers like dpkg, rpm, and yum may trigger false positives when they update or install packages. To handle this, ensure these processes are included in the exclusion list within the detection rule.
-- Automated system management tools such as Puppet, Chef, and Ansible can create or modify Dracut modules as part of their configuration management tasks. Add these tools to the exclusion list to prevent false alerts.
-- System updates or maintenance scripts that run as part of regular system operations might be flagged. Review these scripts and add their executables to the exclusion list if they are verified as non-threatening.
-- Custom scripts or applications that interact with Dracut modules for legitimate purposes should be reviewed and, if deemed safe, added to the exclusion list to avoid unnecessary alerts.
-- Temporary files or backup files with extensions like swp or dpkg-remove may be mistakenly flagged. Ensure these extensions are included in the exclusion criteria to reduce false positives.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further spread or communication with potential command and control servers.
-- Conduct a thorough review of the Dracut module files located in the specified directories (/lib/dracut/modules.d/*, /usr/lib/dracut/modules.d/*) to identify and remove any unauthorized or suspicious modules.
-- Restore the system from a known good backup if malicious Dracut modules are confirmed, ensuring that the backup predates the unauthorized changes.
-- Implement additional monitoring on the affected system to detect any further unauthorized Dracut module creation or other suspicious activities.
-- Review and tighten access controls and permissions for the directories and processes involved in Dracut module creation to prevent unauthorized modifications.
-- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected.
-- Update and enhance detection capabilities to include alerts for any future unauthorized Dracut module creation attempts, leveraging the specific indicators identified in this incident."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
-
 [[rule.threat.technique]]
 id = "T1542"
 name = "Pre-OS Boot"
@@ -135,29 +134,28 @@ 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"
 
@@ -165,3 +163,4 @@ framework = "MITRE ATT&CK"
 id = "TA0005"
 name = "Defense Evasion"
 reference = "https://attack.mitre.org/tactics/TA0005/"
+

rules/linux/persistence_dynamic_linker_backup.toml

@@ -2,9 +2,7 @@
 creation_date = "2022/07/12"
 integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
-min_stack_version = "8.13.0"
-min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/02/04"
+updated_date = "2025/03/20"
 
 [transform]
 [[transform.osquery]]

rules/linux/persistence_extract_initramfs_via_cpio.toml

@@ -2,16 +2,14 @@
 creation_date = "2025/01/16"
 integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
-min_stack_version = "8.13.0"
-min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/22"
+updated_date = "2025/03/20"
 
 [rule]
 author = ["Elastic"]
 description = """
-This rule detects the extraction of an initramfs image using the `cpio` command on Linux systems. The
-`cpio` command is used to create or extract cpio archives. Attackers may extract the initramfs image to
-modify the contents or add malicious files, which can be leveraged to maintain persistence on the system.
+This rule detects the extraction of an initramfs image using the `cpio` command on Linux systems. The `cpio` command is
+used to create or extract cpio archives. Attackers may extract the initramfs image to modify the contents or add
+malicious files, which can be leveraged to maintain persistence on the system.
 """
 from = "now-9m"
 index = [
@@ -20,11 +18,45 @@ index = [
     "auditbeat-*",
     "logs-auditd_manager.auditd-*",
     "logs-crowdstrike.fdr*",
-    "logs-sentinel_one_cloud_funnel.*"
+    "logs-sentinel_one_cloud_funnel.*",
 ]
 language = "eql"
 license = "Elastic License v2"
 name = "Initramfs Extraction via CPIO"
+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 Initramfs Extraction via CPIO
+
+Initramfs is a temporary filesystem used during the Linux boot process, containing essential drivers and scripts. Attackers may exploit the `cpio` command to extract and modify initramfs, embedding malicious files to ensure persistence. The detection rule identifies suspicious `cpio` usage by monitoring process execution patterns, excluding legitimate parent processes, to flag potential threats.
+
+### Possible investigation steps
+
+- Review the process execution details to confirm the presence of the cpio command with arguments "-H" or "--format" and "newc" to ensure the alert is not a false positive.
+- Investigate the parent process of the cpio command to determine if it is an unexpected or unauthorized process, as legitimate processes like mkinitramfs or dracut should be excluded.
+- Check the execution path of the parent process to verify if it matches any known legitimate paths such as "/usr/share/initramfs-tools/*" or "/nix/store/*".
+- Analyze the timeline of events around the cpio execution to identify any preceding or subsequent suspicious activities that might indicate a broader attack or persistence mechanism.
+- Examine the system for any unauthorized modifications or additions to the initramfs image that could indicate tampering or the presence of malicious files.
+- Correlate the alert with other security data sources like Elastic Endgame, Elastic Defend, or Crowdstrike to gather additional context and assess the scope of the potential threat.
+
+### False positive analysis
+
+- Legitimate system updates or maintenance activities may trigger the rule when tools like mkinitramfs or dracut are used. To handle this, ensure these processes are excluded by verifying that the parent process is mkinitramfs or dracut.
+- Custom scripts or automation tools that manage initramfs might use cpio in a non-malicious context. Review these scripts and add their parent process names or paths to the exclusion list if they are verified as safe.
+- Systems using non-standard initramfs management tools located in directories like /usr/share/initramfs-tools or /nix/store may cause false positives. Confirm these tools' legitimacy and update the exclusion paths accordingly.
+- Development or testing environments where initramfs is frequently modified for legitimate reasons can generate alerts. Consider creating environment-specific exceptions to reduce noise while maintaining security in production systems.
+
+### Response and remediation
+
+- Isolate the affected system from the network to prevent further unauthorized access or spread of potential malware.
+- Terminate any suspicious processes related to the `cpio` command that do not have legitimate parent processes, such as `mkinitramfs` or `dracut`.
+- Conduct a thorough review of the extracted initramfs contents to identify and remove any unauthorized or malicious files.
+- Restore the initramfs from a known good backup to ensure system integrity and remove any potential persistence mechanisms.
+- Monitor the system for any further suspicious activity, particularly related to the `cpio` command, to ensure the threat has been fully mitigated.
+- Escalate the incident to the security operations team for further analysis and to determine if additional systems may be affected.
+- Update security policies and procedures to include specific checks for unauthorized `cpio` usage and enhance detection capabilities for similar threats."""
 risk_score = 21
 rule_id = "17b3fcd1-90fb-4f5d-858c-dc1d998fa368"
 setup = """## Setup
@@ -63,6 +95,7 @@ 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
@@ -71,44 +104,10 @@ process.name == "cpio" and process.args in ("-H", "--format") and process.args =
   process.parent.executable like~ ("/usr/share/initramfs-tools/*", "/nix/store/*")
 )
 '''
-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 Initramfs Extraction via CPIO
-
-Initramfs is a temporary filesystem used during the Linux boot process, containing essential drivers and scripts. Attackers may exploit the `cpio` command to extract and modify initramfs, embedding malicious files to ensure persistence. The detection rule identifies suspicious `cpio` usage by monitoring process execution patterns, excluding legitimate parent processes, to flag potential threats.
-
-### Possible investigation steps
-
-- Review the process execution details to confirm the presence of the cpio command with arguments "-H" or "--format" and "newc" to ensure the alert is not a false positive.
-- Investigate the parent process of the cpio command to determine if it is an unexpected or unauthorized process, as legitimate processes like mkinitramfs or dracut should be excluded.
-- Check the execution path of the parent process to verify if it matches any known legitimate paths such as "/usr/share/initramfs-tools/*" or "/nix/store/*".
-- Analyze the timeline of events around the cpio execution to identify any preceding or subsequent suspicious activities that might indicate a broader attack or persistence mechanism.
-- Examine the system for any unauthorized modifications or additions to the initramfs image that could indicate tampering or the presence of malicious files.
-- Correlate the alert with other security data sources like Elastic Endgame, Elastic Defend, or Crowdstrike to gather additional context and assess the scope of the potential threat.
-
-### False positive analysis
-
-- Legitimate system updates or maintenance activities may trigger the rule when tools like mkinitramfs or dracut are used. To handle this, ensure these processes are excluded by verifying that the parent process is mkinitramfs or dracut.
-- Custom scripts or automation tools that manage initramfs might use cpio in a non-malicious context. Review these scripts and add their parent process names or paths to the exclusion list if they are verified as safe.
-- Systems using non-standard initramfs management tools located in directories like /usr/share/initramfs-tools or /nix/store may cause false positives. Confirm these tools' legitimacy and update the exclusion paths accordingly.
-- Development or testing environments where initramfs is frequently modified for legitimate reasons can generate alerts. Consider creating environment-specific exceptions to reduce noise while maintaining security in production systems.
-
-### Response and remediation
-
-- Isolate the affected system from the network to prevent further unauthorized access or spread of potential malware.
-- Terminate any suspicious processes related to the `cpio` command that do not have legitimate parent processes, such as `mkinitramfs` or `dracut`.
-- Conduct a thorough review of the extracted initramfs contents to identify and remove any unauthorized or malicious files.
-- Restore the initramfs from a known good backup to ensure system integrity and remove any potential persistence mechanisms.
-- Monitor the system for any further suspicious activity, particularly related to the `cpio` command, to ensure the threat has been fully mitigated.
-- Escalate the incident to the security operations team for further analysis and to determine if additional systems may be affected.
-- Update security policies and procedures to include specific checks for unauthorized `cpio` usage and enhance detection capabilities for similar threats."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
-
 [[rule.threat.technique]]
 id = "T1542"
 name = "Pre-OS Boot"
@@ -124,7 +123,9 @@ 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/"
+

rules/linux/persistence_git_hook_execution.toml

@@ -2,9 +2,7 @@
 creation_date = "2024/07/15"
 integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
-min_stack_version = "8.13.0"
-min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/15"
+updated_date = "2025/03/20"
 
 [rule]
 author = ["Elastic"]
@@ -18,6 +16,41 @@ index = ["logs-endpoint.events.process*", "logs-sentinel_one_cloud_funnel.*"]
 language = "eql"
 license = "Elastic License v2"
 name = "Git Hook Command Execution"
+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 Git Hook Command Execution
+
+Git hooks are scripts that automate tasks by executing before or after Git events like commits or pushes. While useful for developers, adversaries can exploit them to run malicious commands, gaining persistence or evading defenses. The detection rule identifies suspicious processes initiated by Git hooks, focusing on shell executions, to flag potential abuse on Linux systems.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific Git hook script path and the suspicious process name that was executed, as indicated by the process.args and process.name fields.
+- Examine the process tree to understand the parent-child relationship, focusing on the process.parent.name and process.entity_id fields, to determine how the suspicious process was initiated.
+- Check the Git repository's history and recent changes to the .git/hooks directory to identify any unauthorized modifications or additions to the hook scripts.
+- Investigate the user account associated with the process execution to determine if the activity aligns with their typical behavior or if it indicates potential compromise.
+- Analyze the command-line arguments and environment variables of the suspicious process to gather more context on the nature of the executed command.
+- Correlate this event with other security alerts or logs from the same host.id to identify any patterns or additional indicators of compromise.
+- If possible, isolate the affected system and conduct a deeper forensic analysis to uncover any further malicious activity or persistence mechanisms.
+
+### False positive analysis
+
+- Developers using Git hooks for legitimate automation tasks may trigger this rule. To manage this, identify and document common scripts used in your development environment and create exceptions for these known benign processes.
+- Continuous integration and deployment (CI/CD) systems often utilize Git hooks to automate workflows. Review the processes initiated by these systems and exclude them from detection if they are verified as non-malicious.
+- Custom scripts executed via Git hooks for project-specific tasks can also cause false positives. Collaborate with development teams to catalog these scripts and adjust the detection rule to exclude them.
+- Frequent updates or changes in Git repositories might lead to repeated triggering of the rule. Monitor these activities and, if consistent and verified as safe, consider adding them to an allowlist to reduce noise.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
+- Terminate any suspicious processes identified as being executed from Git hooks, especially those involving shell executions.
+- Conduct a thorough review of the .git/hooks directory on the affected system to identify and remove any unauthorized or malicious scripts.
+- Restore any modified or deleted files from a known good backup to ensure system integrity.
+- Implement monitoring for any future modifications to the .git/hooks directory to detect unauthorized changes promptly.
+- 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 Git repositories to limit the ability to modify hooks to trusted users only."""
 references = [
     "https://swisskyrepo.github.io/InternalAllTheThings/redteam/persistence/linux-persistence/#backdooring-git",
     "https://www.elastic.co/security-labs/sequel-on-persistence-mechanisms",
@@ -72,41 +105,6 @@ sequence by host.id with maxspan=3s
   [process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "start") and
    process.parent.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish")] 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 Git Hook Command Execution
-
-Git hooks are scripts that automate tasks by executing before or after Git events like commits or pushes. While useful for developers, adversaries can exploit them to run malicious commands, gaining persistence or evading defenses. The detection rule identifies suspicious processes initiated by Git hooks, focusing on shell executions, to flag potential abuse on Linux systems.
-
-### Possible investigation steps
-
-- Review the alert details to identify the specific Git hook script path and the suspicious process name that was executed, as indicated by the process.args and process.name fields.
-- Examine the process tree to understand the parent-child relationship, focusing on the process.parent.name and process.entity_id fields, to determine how the suspicious process was initiated.
-- Check the Git repository's history and recent changes to the .git/hooks directory to identify any unauthorized modifications or additions to the hook scripts.
-- Investigate the user account associated with the process execution to determine if the activity aligns with their typical behavior or if it indicates potential compromise.
-- Analyze the command-line arguments and environment variables of the suspicious process to gather more context on the nature of the executed command.
-- Correlate this event with other security alerts or logs from the same host.id to identify any patterns or additional indicators of compromise.
-- If possible, isolate the affected system and conduct a deeper forensic analysis to uncover any further malicious activity or persistence mechanisms.
-
-### False positive analysis
-
-- Developers using Git hooks for legitimate automation tasks may trigger this rule. To manage this, identify and document common scripts used in your development environment and create exceptions for these known benign processes.
-- Continuous integration and deployment (CI/CD) systems often utilize Git hooks to automate workflows. Review the processes initiated by these systems and exclude them from detection if they are verified as non-malicious.
-- Custom scripts executed via Git hooks for project-specific tasks can also cause false positives. Collaborate with development teams to catalog these scripts and adjust the detection rule to exclude them.
-- Frequent updates or changes in Git repositories might lead to repeated triggering of the rule. Monitor these activities and, if consistent and verified as safe, consider adding them to an allowlist to reduce noise.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
-- Terminate any suspicious processes identified as being executed from Git hooks, especially those involving shell executions.
-- Conduct a thorough review of the .git/hooks directory on the affected system to identify and remove any unauthorized or malicious scripts.
-- Restore any modified or deleted files from a known good backup to ensure system integrity.
-- Implement monitoring for any future modifications to the .git/hooks directory to detect unauthorized changes promptly.
-- 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 Git repositories to limit the ability to modify hooks to trusted users only."""
 
 
 [[rule.threat]]

rules/linux/persistence_git_hook_file_creation.toml

@@ -2,9 +2,7 @@
 creation_date = "2024/06/26"
 integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
-min_stack_version = "8.13.0"
-min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/15"
+updated_date = "2025/03/20"
 
 [rule]
 author = ["Elastic"]
@@ -19,6 +17,41 @@ index = ["logs-endpoint.events.file*", "logs-sentinel_one_cloud_funnel.*", "endg
 language = "eql"
 license = "Elastic License v2"
 name = "Git Hook Created or Modified"
+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 Git Hook Created or Modified
+
+Git hooks are scripts that automate tasks by executing before or after Git events like commits or pushes. While beneficial for developers, adversaries can exploit them to execute malicious code, maintaining persistence on a system. The detection rule identifies suspicious creation or modification of Git hooks on Linux, excluding benign processes, to flag potential abuse.
+
+### Possible investigation steps
+
+- Review the file path to confirm the location of the modified or created Git hook file and determine if it aligns with known repositories or projects on the system.
+- Identify the process executable responsible for the creation or modification of the Git hook file and verify if it is a known and legitimate process, excluding those listed in the query.
+- Check the timestamp of the event to correlate with any known user activities or scheduled tasks that might explain the modification or creation of the Git hook.
+- Investigate the user account associated with the process that triggered the alert to determine if the activity aligns with their typical behavior or if it appears suspicious.
+- Examine the contents of the modified or newly created Git hook file to identify any potentially malicious code or unexpected changes.
+- Cross-reference the event with other security logs or alerts to identify any related suspicious activities or patterns that might indicate a broader attack or compromise.
+
+### False positive analysis
+
+- System package managers like dpkg, rpm, and yum can trigger false positives when they create or modify Git hooks during package installations or updates. To manage this, ensure these executables are included in the exclusion list within the detection rule.
+- Automated deployment tools such as Puppet and Chef may modify Git hooks as part of their configuration management processes. Exclude these tools by adding their executables to the exception list to prevent false alerts.
+- Continuous integration and deployment systems like Jenkins or GitLab runners might modify Git hooks as part of their build processes. Identify and exclude these processes by adding their specific executables or paths to the exclusion criteria.
+- Custom scripts or internal tools that are known to modify Git hooks for legitimate purposes should be identified and their executables added to the exclusion list to avoid unnecessary alerts.
+- Consider excluding specific directories or paths that are known to be used by trusted applications or processes for Git hook modifications, ensuring these are not flagged as suspicious.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent potential lateral movement or further execution of malicious code.
+- Terminate any suspicious processes associated with the creation or modification of Git hooks that are not part of the known benign processes listed in the detection rule.
+- Conduct a thorough review of the modified or newly created Git hook scripts to identify and remove any malicious code or unauthorized changes.
+- Restore any affected Git repositories from a known good backup to ensure integrity and remove any persistence mechanisms.
+- Implement file integrity monitoring on the .git/hooks directory 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 Git repositories to limit the ability to modify hook scripts to only trusted users."""
 references = [
     "https://git-scm.com/docs/githooks/2.26.0",
     "https://www.elastic.co/security-labs/sequel-on-persistence-mechanisms",
@@ -85,45 +118,10 @@ file.extension == null and process.executable != null and not (
   (process.name == "perl" and file.name : "e2scrub_all.tmp*")
 )
 '''
-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 Git Hook Created or Modified
-
-Git hooks are scripts that automate tasks by executing before or after Git events like commits or pushes. While beneficial for developers, adversaries can exploit them to execute malicious code, maintaining persistence on a system. The detection rule identifies suspicious creation or modification of Git hooks on Linux, excluding benign processes, to flag potential abuse.
-
-### Possible investigation steps
-
-- Review the file path to confirm the location of the modified or created Git hook file and determine if it aligns with known repositories or projects on the system.
-- Identify the process executable responsible for the creation or modification of the Git hook file and verify if it is a known and legitimate process, excluding those listed in the query.
-- Check the timestamp of the event to correlate with any known user activities or scheduled tasks that might explain the modification or creation of the Git hook.
-- Investigate the user account associated with the process that triggered the alert to determine if the activity aligns with their typical behavior or if it appears suspicious.
-- Examine the contents of the modified or newly created Git hook file to identify any potentially malicious code or unexpected changes.
-- Cross-reference the event with other security logs or alerts to identify any related suspicious activities or patterns that might indicate a broader attack or compromise.
-
-### False positive analysis
-
-- System package managers like dpkg, rpm, and yum can trigger false positives when they create or modify Git hooks during package installations or updates. To manage this, ensure these executables are included in the exclusion list within the detection rule.
-- Automated deployment tools such as Puppet and Chef may modify Git hooks as part of their configuration management processes. Exclude these tools by adding their executables to the exception list to prevent false alerts.
-- Continuous integration and deployment systems like Jenkins or GitLab runners might modify Git hooks as part of their build processes. Identify and exclude these processes by adding their specific executables or paths to the exclusion criteria.
-- Custom scripts or internal tools that are known to modify Git hooks for legitimate purposes should be identified and their executables added to the exclusion list to avoid unnecessary alerts.
-- Consider excluding specific directories or paths that are known to be used by trusted applications or processes for Git hook modifications, ensuring these are not flagged as suspicious.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent potential lateral movement or further execution of malicious code.
-- Terminate any suspicious processes associated with the creation or modification of Git hooks that are not part of the known benign processes listed in the detection rule.
-- Conduct a thorough review of the modified or newly created Git hook scripts to identify and remove any malicious code or unauthorized changes.
-- Restore any affected Git repositories from a known good backup to ensure integrity and remove any persistence mechanisms.
-- Implement file integrity monitoring on the .git/hooks directory 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 Git repositories to limit the ability to modify hook scripts to only trusted users."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
-
 [[rule.threat.technique]]
 id = "T1543"
 name = "Create or Modify System Process"
@@ -134,29 +132,28 @@ 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"
 
@@ -164,3 +161,4 @@ framework = "MITRE ATT&CK"
 id = "TA0005"
 name = "Defense Evasion"
 reference = "https://attack.mitre.org/tactics/TA0005/"
+

rules/linux/persistence_git_hook_process_execution.toml

@@ -2,9 +2,7 @@
 creation_date = "2024/06/26"
 integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
-min_stack_version = "8.13.0"
-min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/15"
+updated_date = "2025/03/20"
 
 [rule]
 author = ["Elastic"]
@@ -15,10 +13,50 @@ spawned by the Git process itself. This behavior may indicate an attacker attemp
 leveraging the legitimate Git process to execute unauthorized commands.
 """
 from = "now-9m"
-index = ["logs-endpoint.events.process*", "logs-crowdstrike.fdr*", "logs-sentinel_one_cloud_funnel.*", "endgame-*"]
+index = [
+    "logs-endpoint.events.process*",
+    "logs-crowdstrike.fdr*",
+    "logs-sentinel_one_cloud_funnel.*",
+    "endgame-*",
+]
 language = "eql"
 license = "Elastic License v2"
 name = "Git Hook Child Process"
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
+
+### Investigating Git Hook Child Process
+
+Git hooks are scripts that automate tasks during Git operations like commits or pushes. Adversaries may exploit these hooks to execute unauthorized commands, masking malicious activities under legitimate processes. The detection rule identifies unusual child processes spawned by Git hooks, focusing on atypical scripts or executables in suspicious directories, signaling potential misuse.
+
+### Possible investigation steps
+
+- Review the process tree to understand the parent-child relationship, focusing on the parent process names listed in the query, such as "pre-commit" or "post-update", to determine the context of the spawned child process.
+- Examine the command line arguments and environment variables of the suspicious child process to identify any potentially malicious or unauthorized commands being executed.
+- Check the file paths of the executables involved, especially those in unusual directories like "/tmp/*" or "/var/tmp/*", to assess if they are legitimate or potentially harmful.
+- Investigate the user account under which the suspicious process is running to determine if it has been compromised or is being used in an unauthorized manner.
+- Correlate the event with other security logs or alerts from the same host to identify any patterns or additional indicators of compromise.
+- Review recent Git activity on the repository to identify any unauthorized changes or suspicious commits that might indicate tampering with Git hooks.
+
+### False positive analysis
+
+- Legitimate development scripts: Developers may use scripts in directories like /tmp or /var/tmp for testing purposes. To handle this, create exceptions for known scripts or directories used by trusted developers.
+- Custom shell usage: Developers might use shells like bash or zsh for legitimate automation tasks. Identify and whitelist these specific shell scripts if they are part of regular development workflows.
+- Temporary file execution: Some applications may temporarily execute files from directories like /dev/shm or /run. Monitor these applications and exclude them if they are verified as non-threatening.
+- Non-standard interpreters: Developers might use interpreters like php or perl for legitimate tasks. Review and whitelist these processes if they are part of approved development activities.
+- System maintenance scripts: Scheduled tasks or maintenance scripts might run from /etc/cron.* or /etc/init.d. Verify these scripts and exclude them if they are part of routine system operations.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or execution of malicious commands.
+- Terminate any suspicious processes identified by the detection rule, especially those originating from unusual directories or involving unexpected scripts or executables.
+- Conduct a thorough review of the Git hooks on the affected system to identify and remove any unauthorized or malicious scripts.
+- Restore any modified or deleted files from a known good backup to ensure system integrity and continuity of operations.
+- Implement stricter access controls and permissions for Git repositories and associated directories to prevent unauthorized modifications to Git hooks.
+- Monitor the affected system and related network activity closely for any signs of persistence or further compromise, using enhanced logging and alerting mechanisms.
+- Escalate the incident to the security operations team for further investigation and to determine if additional systems or data have been affected."""
 references = [
     "https://git-scm.com/docs/githooks/2.26.0",
     "https://www.elastic.co/security-labs/sequel-on-persistence-mechanisms",
@@ -86,41 +124,6 @@ process where host.os.type == "linux" and event.type == "start" and
   ) and
   not process.name in ("git", "dirname")
 '''
-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 Git Hook Child Process
-
-Git hooks are scripts that automate tasks during Git operations like commits or pushes. Adversaries may exploit these hooks to execute unauthorized commands, masking malicious activities under legitimate processes. The detection rule identifies unusual child processes spawned by Git hooks, focusing on atypical scripts or executables in suspicious directories, signaling potential misuse.
-
-### Possible investigation steps
-
-- Review the process tree to understand the parent-child relationship, focusing on the parent process names listed in the query, such as "pre-commit" or "post-update", to determine the context of the spawned child process.
-- Examine the command line arguments and environment variables of the suspicious child process to identify any potentially malicious or unauthorized commands being executed.
-- Check the file paths of the executables involved, especially those in unusual directories like "/tmp/*" or "/var/tmp/*", to assess if they are legitimate or potentially harmful.
-- Investigate the user account under which the suspicious process is running to determine if it has been compromised or is being used in an unauthorized manner.
-- Correlate the event with other security logs or alerts from the same host to identify any patterns or additional indicators of compromise.
-- Review recent Git activity on the repository to identify any unauthorized changes or suspicious commits that might indicate tampering with Git hooks.
-
-### False positive analysis
-
-- Legitimate development scripts: Developers may use scripts in directories like /tmp or /var/tmp for testing purposes. To handle this, create exceptions for known scripts or directories used by trusted developers.
-- Custom shell usage: Developers might use shells like bash or zsh for legitimate automation tasks. Identify and whitelist these specific shell scripts if they are part of regular development workflows.
-- Temporary file execution: Some applications may temporarily execute files from directories like /dev/shm or /run. Monitor these applications and exclude them if they are verified as non-threatening.
-- Non-standard interpreters: Developers might use interpreters like php or perl for legitimate tasks. Review and whitelist these processes if they are part of approved development activities.
-- System maintenance scripts: Scheduled tasks or maintenance scripts might run from /etc/cron.* or /etc/init.d. Verify these scripts and exclude them if they are part of routine system operations.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further unauthorized access or execution of malicious commands.
-- Terminate any suspicious processes identified by the detection rule, especially those originating from unusual directories or involving unexpected scripts or executables.
-- Conduct a thorough review of the Git hooks on the affected system to identify and remove any unauthorized or malicious scripts.
-- Restore any modified or deleted files from a known good backup to ensure system integrity and continuity of operations.
-- Implement stricter access controls and permissions for Git repositories and associated directories to prevent unauthorized modifications to Git hooks.
-- Monitor the affected system and related network activity closely for any signs of persistence or further compromise, using enhanced logging and alerting mechanisms.
-- Escalate the incident to the security operations team for further investigation and to determine if additional systems or data have been affected."""
 
 
 [[rule.threat]]

rules/linux/persistence_grub_configuration_creation.toml

@@ -2,23 +2,56 @@
 creation_date = "2025/01/16"
 integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
-min_stack_version = "8.13.0"
-min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/22"
+updated_date = "2025/03/20"
 
 [rule]
 author = ["Elastic"]
 description = """
 This rule detects the creation of GRUB configuration files on Linux systems. The GRUB configuration file is used to
-configure the boot loader, which is responsible for loading the operating system. Attackers may create malicious
-GRUB configuration files to execute arbitrary code or escalate privileges during the boot process, which can be
-leveraged to maintain persistence on the system.
+configure the boot loader, which is responsible for loading the operating system. Attackers may create malicious GRUB
+configuration files to execute arbitrary code or escalate privileges during the boot process, which can be leveraged to
+maintain persistence on the system.
 """
 from = "now-9m"
 index = ["logs-endpoint.events.file*", "logs-sentinel_one_cloud_funnel.*", "endgame-*"]
 language = "eql"
 license = "Elastic License v2"
 name = "GRUB Configuration 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 GRUB Configuration File Creation
+
+GRUB (Grand Unified Bootloader) is crucial for booting Linux systems, managing the boot process, and loading the OS. Adversaries may exploit GRUB by creating or altering configuration files to execute unauthorized code or gain elevated privileges, ensuring persistence. The detection rule identifies suspicious creation of GRUB files, excluding legitimate processes, to flag potential security threats.
+
+### Possible investigation steps
+
+- Review the file path and name to determine if it matches any known GRUB configuration files, as specified in the query (e.g., "/etc/default/grub", "/boot/grub2/grub.cfg").
+- Identify the process that created the file by examining the process.executable field, ensuring it is not one of the excluded legitimate processes.
+- Check the timestamp of the file creation event to correlate it with any other suspicious activities or changes in the system around the same time.
+- Investigate the user account associated with the process that created the file to determine if it has the necessary permissions and if the activity aligns with the user's typical behavior.
+- Analyze the contents of the newly created or modified GRUB configuration file for any unauthorized or suspicious entries that could indicate malicious intent.
+- Cross-reference the event with other security logs or alerts to identify any related activities or patterns that could suggest a broader attack or compromise.
+
+### False positive analysis
+
+- System package managers like dpkg, rpm, and yum may trigger false positives when they update or modify GRUB configuration files during routine package installations or updates. To handle this, ensure these processes are included in the exclusion list within the detection rule.
+- Automated system management tools such as Puppet, Chef, and Ansible can also cause false positives when they manage GRUB configurations as part of their configuration management tasks. Consider adding these tools to the exclusion list if they are part of your environment.
+- Virtualization and containerization tools like Docker, Podman, and VirtualBox might modify GRUB files as part of their operations. Verify these processes and exclude them if they are legitimate in your setup.
+- Temporary files created by text editors or system processes, such as those with extensions like swp or swx, can be mistaken for GRUB configuration files. Ensure these extensions are part of the exclusion criteria to prevent unnecessary alerts.
+- Custom scripts or administrative tasks that modify GRUB configurations for legitimate reasons should be reviewed and, if deemed safe, added to the exclusion list to avoid repeated false positives.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent potential lateral movement or further unauthorized access.
+- Review the GRUB configuration files identified in the alert to confirm unauthorized modifications or creations. Restore any altered files from a known good backup if necessary.
+- Conduct a thorough scan of the system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any malicious code or backdoors that may have been introduced.
+- Change all system and user passwords on the affected machine to prevent unauthorized access using potentially compromised credentials.
+- Monitor the system for any further suspicious activity, particularly focusing on processes attempting to modify GRUB configuration files.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.
+- Implement additional logging and monitoring for GRUB configuration changes to enhance detection capabilities and prevent future unauthorized modifications."""
 risk_score = 21
 rule_id = "ce4a32e5-32aa-47e6-80da-ced6d234387d"
 setup = """## Setup
@@ -57,6 +90,7 @@ tags = [
 ]
 timestamp_override = "event.ingested"
 type = "eql"
+
 query = '''
 file where host.os.type == "linux" and event.type == "creation" and process.executable != null and file.path like~ (
   "/etc/default/grub.d/*", "/etc/default/grub", "/etc/grub.d/*",
@@ -84,45 +118,10 @@ file where host.os.type == "linux" and event.type == "creation" and process.exec
   (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 GRUB Configuration File Creation
-
-GRUB (Grand Unified Bootloader) is crucial for booting Linux systems, managing the boot process, and loading the OS. Adversaries may exploit GRUB by creating or altering configuration files to execute unauthorized code or gain elevated privileges, ensuring persistence. The detection rule identifies suspicious creation of GRUB files, excluding legitimate processes, to flag potential security threats.
-
-### Possible investigation steps
-
-- Review the file path and name to determine if it matches any known GRUB configuration files, as specified in the query (e.g., "/etc/default/grub", "/boot/grub2/grub.cfg").
-- Identify the process that created the file by examining the process.executable field, ensuring it is not one of the excluded legitimate processes.
-- Check the timestamp of the file creation event to correlate it with any other suspicious activities or changes in the system around the same time.
-- Investigate the user account associated with the process that created the file to determine if it has the necessary permissions and if the activity aligns with the user's typical behavior.
-- Analyze the contents of the newly created or modified GRUB configuration file for any unauthorized or suspicious entries that could indicate malicious intent.
-- Cross-reference the event with other security logs or alerts to identify any related activities or patterns that could suggest a broader attack or compromise.
-
-### False positive analysis
-
-- System package managers like dpkg, rpm, and yum may trigger false positives when they update or modify GRUB configuration files during routine package installations or updates. To handle this, ensure these processes are included in the exclusion list within the detection rule.
-- Automated system management tools such as Puppet, Chef, and Ansible can also cause false positives when they manage GRUB configurations as part of their configuration management tasks. Consider adding these tools to the exclusion list if they are part of your environment.
-- Virtualization and containerization tools like Docker, Podman, and VirtualBox might modify GRUB files as part of their operations. Verify these processes and exclude them if they are legitimate in your setup.
-- Temporary files created by text editors or system processes, such as those with extensions like swp or swx, can be mistaken for GRUB configuration files. Ensure these extensions are part of the exclusion criteria to prevent unnecessary alerts.
-- Custom scripts or administrative tasks that modify GRUB configurations for legitimate reasons should be reviewed and, if deemed safe, added to the exclusion list to avoid repeated false positives.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent potential lateral movement or further unauthorized access.
-- Review the GRUB configuration files identified in the alert to confirm unauthorized modifications or creations. Restore any altered files from a known good backup if necessary.
-- Conduct a thorough scan of the system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any malicious code or backdoors that may have been introduced.
-- Change all system and user passwords on the affected machine to prevent unauthorized access using potentially compromised credentials.
-- Monitor the system for any further suspicious activity, particularly focusing on processes attempting to modify GRUB configuration files.
-- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.
-- Implement additional logging and monitoring for GRUB configuration changes to enhance detection capabilities and prevent future unauthorized modifications."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
-
 [[rule.threat.technique]]
 id = "T1542"
 name = "Pre-OS Boot"
@@ -138,7 +137,9 @@ 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/"
+

rules/linux/persistence_grub_makeconfig.toml

@@ -2,9 +2,7 @@
 creation_date = "2025/01/16"
 integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
-min_stack_version = "8.13.0"
-min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/01/22"
+updated_date = "2025/03/20"
 
 [rule]
 author = ["Elastic"]
@@ -15,10 +13,48 @@ during the boot process. Attackers may use these built-in utilities to generate
 includes malicious kernel parameters or boot options, which can be leveraged to maintain persistence on the system.
 """
 from = "now-9m"
-index = ["logs-endpoint.events.process*", "endgame-*", "logs-crowdstrike.fdr*", "logs-sentinel_one_cloud_funnel.*"]
+index = [
+    "logs-endpoint.events.process*",
+    "endgame-*",
+    "logs-crowdstrike.fdr*",
+    "logs-sentinel_one_cloud_funnel.*",
+]
 language = "eql"
 license = "Elastic License v2"
 name = "GRUB Configuration Generation through Built-in Utilities"
+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 GRUB Configuration Generation through Built-in Utilities
+
+GRUB, the Grand Unified Bootloader, is crucial for loading the Linux kernel during system startup. It uses configuration files to determine boot parameters. Adversaries may exploit utilities like `grub-mkconfig` to alter these files, embedding malicious parameters for persistence. The detection rule identifies suspicious executions of these utilities, especially when initiated by atypical parent processes, signaling potential misuse.
+
+### Possible investigation steps
+
+- Review the process execution details to identify the parent process of the suspicious GRUB configuration utility execution. Check if the parent process is unusual or unexpected based on the query's exclusion list.
+- Examine the command-line arguments used in the execution of the GRUB configuration utility to identify any potentially malicious kernel parameters or boot options.
+- Investigate the user account associated with the process execution to determine if it has the necessary privileges and if the activity aligns with the user's typical behavior.
+- Check the system's recent changes or updates, especially those related to bootloader configurations, to identify any unauthorized modifications.
+- Analyze system logs for any other suspicious activities or anomalies around the time of the GRUB configuration utility execution to gather additional context.
+
+### False positive analysis
+
+- Routine system updates or maintenance tasks may trigger the rule when legitimate processes like package managers (e.g., pacman, dnf, yum) or system utilities (e.g., sudo) execute GRUB configuration commands. Users can mitigate this by adding these processes to the exception list in the rule configuration.
+- Automated scripts or cron jobs that regularly update GRUB configurations for legitimate reasons might be flagged. To handle this, identify these scripts and add their parent process names or paths to the exclusion criteria.
+- Custom administrative scripts that manage bootloader settings could also cause false positives. Review these scripts and, if verified as safe, include their parent process details in the rule's exceptions.
+- Some Linux distributions may have specific utilities or services that interact with GRUB as part of their normal operation. Investigate these utilities and consider excluding them if they are confirmed to be benign and necessary for system functionality.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further malicious activity or lateral movement.
+- Terminate any suspicious processes related to `grub-mkconfig`, `grub2-mkconfig`, or `update-grub` that were initiated by atypical parent processes.
+- Review and restore the GRUB configuration file from a known good backup to ensure no malicious parameters are present.
+- Conduct a thorough examination of the system for additional signs of compromise, focusing on persistence mechanisms and unauthorized changes to boot parameters.
+- Escalate the incident to the security operations team for further analysis and to determine if additional systems are affected.
+- Implement monitoring for future unauthorized executions of GRUB configuration utilities, ensuring alerts are generated for similar suspicious activities.
+- Review and update access controls and permissions to restrict the execution of GRUB configuration utilities to authorized personnel only."""
 risk_score = 21
 rule_id = "aabdad51-51fb-4a66-9d82-3873e42accb8"
 setup = """## Setup
@@ -56,6 +92,7 @@ tags = [
 ]
 timestamp_override = "event.ingested"
 type = "eql"
+
 query = '''
 process where host.os.type == "linux" and event.type == "start" and
 event.action in ("exec", "exec_event", "start", "ProcessRollup2") and
@@ -66,43 +103,10 @@ process.parent.executable != null and process.name in ("grub-mkconfig", "grub2-m
   )
 )
 '''
-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 GRUB Configuration Generation through Built-in Utilities
-
-GRUB, the Grand Unified Bootloader, is crucial for loading the Linux kernel during system startup. It uses configuration files to determine boot parameters. Adversaries may exploit utilities like `grub-mkconfig` to alter these files, embedding malicious parameters for persistence. The detection rule identifies suspicious executions of these utilities, especially when initiated by atypical parent processes, signaling potential misuse.
-
-### Possible investigation steps
-
-- Review the process execution details to identify the parent process of the suspicious GRUB configuration utility execution. Check if the parent process is unusual or unexpected based on the query's exclusion list.
-- Examine the command-line arguments used in the execution of the GRUB configuration utility to identify any potentially malicious kernel parameters or boot options.
-- Investigate the user account associated with the process execution to determine if it has the necessary privileges and if the activity aligns with the user's typical behavior.
-- Check the system's recent changes or updates, especially those related to bootloader configurations, to identify any unauthorized modifications.
-- Analyze system logs for any other suspicious activities or anomalies around the time of the GRUB configuration utility execution to gather additional context.
-
-### False positive analysis
-
-- Routine system updates or maintenance tasks may trigger the rule when legitimate processes like package managers (e.g., pacman, dnf, yum) or system utilities (e.g., sudo) execute GRUB configuration commands. Users can mitigate this by adding these processes to the exception list in the rule configuration.
-- Automated scripts or cron jobs that regularly update GRUB configurations for legitimate reasons might be flagged. To handle this, identify these scripts and add their parent process names or paths to the exclusion criteria.
-- Custom administrative scripts that manage bootloader settings could also cause false positives. Review these scripts and, if verified as safe, include their parent process details in the rule's exceptions.
-- Some Linux distributions may have specific utilities or services that interact with GRUB as part of their normal operation. Investigate these utilities and consider excluding them if they are confirmed to be benign and necessary for system functionality.
-
-### Response and remediation
-
-- Immediately isolate the affected system from the network to prevent further malicious activity or lateral movement.
-- Terminate any suspicious processes related to `grub-mkconfig`, `grub2-mkconfig`, or `update-grub` that were initiated by atypical parent processes.
-- Review and restore the GRUB configuration file from a known good backup to ensure no malicious parameters are present.
-- Conduct a thorough examination of the system for additional signs of compromise, focusing on persistence mechanisms and unauthorized changes to boot parameters.
-- Escalate the incident to the security operations team for further analysis and to determine if additional systems are affected.
-- Implement monitoring for future unauthorized executions of GRUB configuration utilities, ensuring alerts are generated for similar suspicious activities.
-- Review and update access controls and permissions to restrict the execution of GRUB configuration utilities to authorized personnel only."""
 
 [[rule.threat]]
 framework = "MITRE ATT&CK"
-
 [[rule.threat.technique]]
 id = "T1542"
 name = "Pre-OS Boot"
@@ -118,7 +122,9 @@ 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/"
+

rules/linux/persistence_init_d_file_creation.toml

@@ -2,9 +2,7 @@
 creation_date = "2023/03/21"
 integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
-min_stack_version = "8.13.0"
-min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/02/04"
+updated_date = "2025/03/20"
 
 [transform]
 [[transform.osquery]]
@@ -179,15 +177,18 @@ and file.path : "/etc/init.d/*" and not (
   (process.name == "perl" and file.name : "e2scrub_all.tmp*") 
 )
 '''
+
+
 [[rule.threat]]
 framework = "MITRE ATT&CK"
-
 [[rule.threat.technique]]
 id = "T1037"
 name = "Boot or Logon Initialization Scripts"
 reference = "https://attack.mitre.org/techniques/T1037/"
 
+
 [rule.threat.tactic]
 id = "TA0003"
 name = "Persistence"
 reference = "https://attack.mitre.org/tactics/TA0003/"
+

rules/linux/persistence_insmod_kernel_module_load.toml

@@ -2,9 +2,7 @@
 creation_date = "2022/07/11"
 integration = ["endpoint", "auditd_manager", "sentinel_one_cloud_funnel"]
 maturity = "production"
-min_stack_version = "8.13.0"
-min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/02/04"
+updated_date = "2025/03/20"
 
 [transform]
 [[transform.osquery]]
@@ -41,7 +39,13 @@ security products. Manually loading a kernel module in this manner should not be
 suspcious or malicious behavior.
 """
 from = "now-9m"
-index = ["auditbeat-*", "endgame-*", "logs-auditd_manager.auditd-*", "logs-endpoint.events.process*", "logs-sentinel_one_cloud_funnel.*"]
+index = [
+    "auditbeat-*",
+    "endgame-*",
+    "logs-auditd_manager.auditd-*",
+    "logs-endpoint.events.process*",
+    "logs-sentinel_one_cloud_funnel.*",
+]
 language = "eql"
 license = "Elastic License v2"
 name = "Kernel Module Load via insmod"
@@ -162,6 +166,7 @@ tags = [
 ]
 timestamp_override = "event.ingested"
 type = "eql"
+
 query = '''
 process where host.os.type == "linux" and event.type == "start" and process.name == "insmod" and process.args : "*.ko" and
 not process.parent.executable like (
@@ -170,20 +175,22 @@ not process.parent.executable like (
 )
 '''
 
+
 [[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/linux/persistence_kde_autostart_modification.toml

@@ -2,9 +2,7 @@
 creation_date = "2021/01/06"
 integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
-min_stack_version = "8.13.0"
-min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/02/04"
+updated_date = "2025/03/20"
 
 [transform]
 [[transform.osquery]]
@@ -232,15 +230,17 @@ file where host.os.type == "linux" and event.type != "deletion" and
     )
 '''
 
+
 [[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.tactic]
 id = "TA0003"
 name = "Persistence"
 reference = "https://attack.mitre.org/tactics/TA0003/"
+

rules/linux/persistence_kworker_file_creation.toml

@@ -2,9 +2,7 @@
 creation_date = "2023/10/26"
 integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
-min_stack_version = "8.13.0"
-min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/02/04"
+updated_date = "2025/03/20"
 
 [transform]
 [[transform.osquery]]
@@ -167,6 +165,7 @@ tags = [
 ]
 timestamp_override = "event.ingested"
 type = "eql"
+
 query = '''
 file where host.os.type == "linux" and event.action in ("creation", "file_create_event") and
   process.name : "kworker*" and not (
@@ -181,28 +180,29 @@ file where host.os.type == "linux" and event.action in ("creation", "file_create
   )
 '''
 
+
 [[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.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_linux_backdoor_user_creation.toml

@@ -2,9 +2,7 @@
 creation_date = "2023/03/07"
 integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
-min_stack_version = "8.13.0"
-min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/02/04"
+updated_date = "2025/03/20"
 
 [transform]
 [[transform.osquery]]
@@ -38,7 +36,14 @@ Identifies the attempt to create a new backdoor user by setting the user's UID t
 0 to establish persistence on a system.
 """
 from = "now-9m"
-index = ["auditbeat-*", "endgame-*", "logs-auditd_manager.auditd-*", "logs-crowdstrike.fdr*", "logs-endpoint.events.process*", "logs-sentinel_one_cloud_funnel.*"]
+index = [
+    "auditbeat-*",
+    "endgame-*",
+    "logs-auditd_manager.auditd-*",
+    "logs-crowdstrike.fdr*",
+    "logs-endpoint.events.process*",
+    "logs-sentinel_one_cloud_funnel.*",
+]
 language = "eql"
 license = "Elastic License v2"
 name = "Potential Linux Backdoor User Account Creation"

rules/linux/persistence_linux_shell_activity_via_web_server.toml

@@ -2,9 +2,7 @@
 creation_date = "2023/03/04"
 integration = ["endpoint", "sentinel_one_cloud_funnel"]
 maturity = "production"
-min_stack_version = "8.13.0"
-min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/02/04"
+updated_date = "2025/03/20"
 
 [transform]
 [[transform.osquery]]

rules/linux/persistence_linux_user_added_to_privileged_group.toml

@@ -2,9 +2,7 @@
 creation_date = "2023/02/13"
 integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_funnel"]
 maturity = "production"
-min_stack_version = "8.13.0"
-min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
-updated_date = "2025/02/04"
+updated_date = "2025/03/20"
 
 [transform]
 [[transform.osquery]]
@@ -31,7 +29,14 @@ Identifies attempts to add a user to a privileged group. Attackers may add users
 establish persistence on a system.
 """
 from = "now-9m"
-index = ["auditbeat-*", "endgame-*", "logs-auditd_manager.auditd-*", "logs-crowdstrike.fdr*", "logs-endpoint.events.process*", "logs-sentinel_one_cloud_funnel.*"]
+index = [
+    "auditbeat-*",
+    "endgame-*",
+    "logs-auditd_manager.auditd-*",
+    "logs-crowdstrike.fdr*",
+    "logs-endpoint.events.process*",
+    "logs-sentinel_one_cloud_funnel.*",
+]
 language = "eql"
 license = "Elastic License v2"
 name = "Linux User Added to Privileged Group"
@@ -124,6 +129,7 @@ tags = [
 ]
 timestamp_override = "event.ingested"
 type = "eql"
+
 query = '''
 process where host.os.type == "linux" and event.type == "start" and
   event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and
@@ -136,20 +142,22 @@ process where host.os.type == "linux" and event.type == "start" and
   )
 '''
 
+
 [[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/"
+