nldcsc-elastic-rules 0.0.8__py3-none-any.whl

nldcsc_elastic_rules/rules/linux/defense_evasion_symlink_binary_to_writable_dir.toml

@@ -0,0 +1,115 @@
+[metadata]
+creation_date = "2025/04/30"
+integration = ["endpoint"]
+maturity = "production"
+updated_date = "2025/07/07"
+
+[rule]
+author = ["Elastic"]
+description = """
+This rule detects the creation of a symbolic link from a system binary to a suspicious and writable location. This
+activity may indicate an attacker's attempt to evade detection by behavioral rules that depend on predefined process
+parent/child relationships. By executing the symlinked variant of a binary instead of the original, the attacker aims to
+bypass these rules. Through the new_terms rule type, this rule can identify uncommon parent processes that may indicate the
+presence of a malicious symlink.
+"""
+from = "now-9m"
+index = [
+    "logs-endpoint.events.process*",
+]
+language = "kuery"
+license = "Elastic License v2"
+name = "System Binary Symlink to Suspicious Location"
+note = """ ## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
+
+### Investigating System Binary Symlink to Suspicious Location
+
+Symbolic links in Linux create shortcuts to files or directories, allowing flexible file management. Adversaries exploit this by linking system binaries to writable, suspicious locations, aiming to bypass security measures that monitor standard execution paths. The detection rule identifies unusual parent processes and symbolic link creation to these locations, flagging potential evasion attempts.
+
+### Possible investigation steps
+
+- Review the parent process executable (process.parent.executable) to determine if it is a known and legitimate process that should be creating symbolic links.
+- Examine the specific system binary involved (process.args) to verify if it is commonly used in the environment and assess if its redirection to a suspicious location is justified.
+- Investigate the destination path of the symbolic link (process.args) to determine if it is a writable and potentially malicious location such as /tmp, /dev/shm, or /var/tmp.
+- Check for any recent or concurrent alerts or logs related to the same parent process or destination path to identify potential patterns or repeated attempts.
+- Assess the user account associated with the process (if available) to determine if it has the necessary permissions and if the activity aligns with the user's typical behavior.
+- Correlate with other security tools or logs to identify any additional suspicious activities or anomalies around the time of the alert.
+
+### False positive analysis
+
+- Routine system maintenance tasks may create symbolic links in monitored directories. Exclude known maintenance scripts or processes like mkinitcpio and dracut from triggering alerts by adding them to the exception list.
+- Software installations or updates often involve creating symbolic links in writable directories. Identify and whitelist trusted installation processes or package managers to prevent unnecessary alerts.
+- Development environments may frequently use symbolic links for testing purposes. Consider excluding specific user directories or development tools that are known to create such links regularly.
+- Backup or synchronization tools might create symbolic links as part of their operation. Verify and exclude these tools if they are part of a legitimate and routine process.
+- Custom scripts or automation tools used within the organization might trigger this rule. Review and whitelist these scripts if they are verified to be safe and necessary for business operations.
+
+### 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 creating symbolic links to writable locations, especially those with uncommon parent processes.
+- Remove any unauthorized symbolic links from system binaries to suspicious locations, ensuring the integrity of the original binaries.
+- Conduct a thorough review of user accounts and permissions on the affected system to identify and disable any compromised accounts or unnecessary elevated privileges.
+- Restore affected binaries and system files from a known good backup to ensure no tampered files remain.
+- Monitor the system for any further attempts to create unauthorized symbolic links, using enhanced logging and alerting mechanisms.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.
+"""
+risk_score = 21
+rule_id = "d19a2399-f8e2-4b10-80d8-a561ce9d24d1"
+severity = "low"
+tags = [
+    "Domain: Endpoint",
+    "OS: Linux",
+    "Use Case: Threat Detection",
+    "Tactic: Defense Evasion",
+    "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "new_terms"
+query = '''
+host.os.type:linux and event.category:process and event.type:start and event.action:exec and process.parent.executable:* and
+(process.name:ln or process.name:busybox and process.args:ln or process.name:cp and process.args:--symbolic-link) and
+process.args:(
+  (
+    /bin/* or /lib/* or /lib64/* or /sbin/* or /usr/bin/* or /usr/lib/* or /usr/lib64/* or /usr/local/bin/* or
+    /usr/local/lib/* or /usr/local/lib64/* or /usr/local/sbin/* or /usr/sbin/*
+  ) and (
+    /*/.* or /dev/shm/* or /home/* or /root/* or /tmp/* or /var/tmp/*
+  ) and
+  not (/usr/bin/coreutils or /tmp/mkinitcpio* or /var/tmp/dracut* or /var/tmp/mkinitramfs*)
+)
+'''
+
+[[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 = "Hijack Execution Flow"
+    id = "T1574"
+    reference = "https://attack.mitre.org/techniques/T1574/"
+
+    [[rule.threat.technique]]
+    name = "Indirect Command Execution"
+    id = "T1202"
+    reference = "https://attack.mitre.org/techniques/T1202/"
+
+    [[rule.threat.technique]]
+    name = "Hide Artifacts"
+    id = "T1564"
+    reference = "https://attack.mitre.org/techniques/T1564/"
+
+[rule.new_terms]
+field = "new_terms_fields"
+value = ["host.id", "process.parent.name"]
+
+[[rule.new_terms.history_window_start]]
+field = "history_window_start"
+value = "now-10d"

nldcsc_elastic_rules/rules/linux/defense_evasion_sysctl_kernel_feature_activity.toml

@@ -0,0 +1,129 @@
+[metadata]
+creation_date = "2025/04/29"
+integration = ["endpoint", "crowdstrike"]
+maturity = "production"
+updated_date = "2025/10/17"
+
+[rule]
+author = ["Elastic"]
+description = """
+This rule detects the modification and reading of kernel features through built-in commands. Attackers may collect
+information, disable or weaken Linux kernel protections. For example, an attacker may modify ASLR protection by
+disabling kernel.randomize_va_space, allow ptrace by setting kernel.yama.ptrace_scope to 0, or disable the
+NMI watchdog by setting kernel.nmi_watchdog to 0. These changes may be used to impair defenses and evade detection.
+"""
+from = "now-9m"
+index = [
+  "logs-endpoint.events.process*",
+  "logs-crowdstrike.fdr*",
+]
+language = "eql"
+license = "Elastic License v2"
+name = "Suspicious Kernel Feature 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 Suspicious Kernel Feature Activity
+
+Kernel features in Linux systems are critical for maintaining security and stability. They control various system behaviors, such as memory randomization and process tracing. Adversaries may exploit these features to weaken defenses, for instance, by disabling address space layout randomization (ASLR) or enabling unrestricted process tracing. The detection rule identifies suspicious activities by monitoring command executions that modify or read kernel settings, focusing on unusual patterns or contexts that suggest malicious intent.
+
+### Possible investigation steps
+
+- Review the process command line to identify which specific kernel feature was accessed or modified, focusing on entries like kernel.randomize_va_space or kernel.yama.ptrace_scope.
+- Examine the parent process executable and name to determine the context in which the suspicious command was executed, checking for unusual or unauthorized parent processes.
+- Investigate the user account associated with the process execution to assess whether the activity aligns with expected behavior for that user.
+- Check for any recent changes in the /etc/sysctl.conf or /etc/sysctl.d/ directories that might indicate unauthorized modifications to kernel settings.
+- Analyze the system's process execution history to identify any patterns or sequences of commands that suggest a broader attack or compromise.
+- Correlate the alert with other security events or logs to determine if this activity is part of a larger attack campaign or isolated incident.
+
+### False positive analysis
+
+- System administrators or automated scripts may frequently modify kernel settings for legitimate purposes such as performance tuning or system maintenance. To handle these, identify and whitelist known administrative scripts or processes that regularly perform these actions.
+- Security tools or monitoring solutions might execute commands that read kernel settings as part of their normal operation. Review and exclude these tools from triggering alerts by adding them to an exception list based on their process names or command patterns.
+- Developers and testers might disable certain kernel features temporarily during debugging or testing phases. Coordinate with development teams to document these activities and exclude them from detection by specifying the relevant process names or command lines.
+- Some system management tools may use commands like sysctl to apply configuration changes across multiple systems. If these tools are verified as non-threatening, exclude their specific command patterns or parent processes from triggering the rule.
+- Regular system updates or configuration management processes might involve reading or modifying kernel settings. Identify these processes and add them to an exception list to prevent unnecessary alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further exploitation or lateral movement by the adversary.
+- Review and revert any unauthorized changes to kernel settings, such as ASLR, ptrace scope, or NMI watchdog, to their secure defaults using sysctl or by editing configuration files.
+- Conduct a thorough examination of the system for signs of compromise, including checking for unauthorized access, unusual processes, or modifications to critical files.
+- Restore the system from a known good backup if the integrity of the system is compromised and cannot be reliably remediated.
+- Implement additional monitoring and logging for kernel feature modifications to detect similar activities in the future, ensuring alerts are configured for immediate response.
+- Escalate the incident to the security operations center (SOC) or relevant security team for further investigation and correlation with other potential threats across the network.
+- Review and update security policies and configurations to prevent unauthorized kernel modifications, including enforcing stricter access controls and auditing procedures.
+"""
+risk_score = 21
+rule_id = "3aff6ab1-18bd-427e-9d4c-c5732110c261"
+severity = "low"
+tags = [
+  "Domain: Endpoint",
+  "OS: Linux",
+  "Use Case: Threat Detection",
+  "Tactic: Defense Evasion",
+  "Tactic: Discovery",
+  "Data Source: Elastic Defend",
+  "Resources: Investigation Guide",
+  "Data Source: Crowdstrike",
+]
+timestamp_override = "event.ingested"
+type = "eql"
+query = '''
+process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "ProcessRollup2") and
+process.command_line : (
+  "*/etc/sysctl.conf*", "*/etc/sysctl.d/*", "*/proc/sys/kernel/nmi_watchdog*",
+  "*/proc/sys/vm/nr_hugepages*", "*/proc/sys/kernel/yama/ptrace_scope*",
+  "*/proc/sys/kernel/randomize_va_space*", "*/proc/sys/vm/drop_caches*",
+  "*/proc/sys/kernel/sysrq*", "*grsecurity*", "*exec-shield*",
+  "*kernel.randomize_va_space*", "*kernel.yama.ptrace_scope*",
+  "*kernel.nmi_watchdog*", "*vm.nr_hugepages*", "*vm.drop_caches*",
+  "*kernel.sysrq*"
+) and
+?process.parent.executable != null and 
+(
+  (process.name == "tee" and process.args like "-*a*") or // also detects --append
+  (process.name == "cat" and not process.parent.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish")) or
+  (process.name == "grep" and process.args_count == 3 and not process.parent.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish")) or
+  (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.args : "*echo *")
+)
+'''
+
+[[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 = "Impair Defenses"
+id = "T1562"
+reference = "https://attack.mitre.org/techniques/T1562/"
+
+[[rule.threat.technique.subtechnique]]
+name = "Indicator Blocking"
+id = "T1562.006"
+reference = "https://attack.mitre.org/techniques/T1562/006/"
+
+[[rule.threat.technique]]
+name = "Subvert Trust Controls"
+id = "T1553"
+reference = "https://attack.mitre.org/techniques/T1553/"
+
+[[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/"

nldcsc_elastic_rules/rules/linux/defense_evasion_unsual_kill_signal.toml

@@ -0,0 +1,108 @@
+[metadata]
+creation_date = "2025/07/16"
+integration = ["auditd_manager"]
+maturity = "production"
+updated_date = "2025/07/21"
+
+[rule]
+author = ["Elastic"]
+description = """
+This rule detects the use of unusual kill signals, specifically kill signals in the range of 32-64, which
+are not commonly used in standard operations. Rootkits may leverage these signals to conduct certain actions,
+such as manipulating processes in unexpected ways, potentially escalating privileges or evading detection. 
+"""
+from = "now-9m"
+index = ["auditbeat-*", "logs-auditd_manager.auditd-*"]
+language = "eql"
+license = "Elastic License v2"
+name = "Unusual Kill Signal"
+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 Kill Signal
+
+In Linux environments, kill signals are used to manage process lifecycles. Signals in the range of 32-64 are less common and can be exploited by adversaries, such as rootkits, to manipulate processes stealthily, potentially leading to privilege escalation or evasion of security measures. The 'Unusual Kill Signal' detection rule identifies these rare signals, flagging potential misuse by monitoring specific syscall activities, thus aiding in early threat detection.
+
+### Possible investigation steps
+
+- Review the process details associated with the alert, focusing on the process name, PID, and parent process to understand the context of the kill signal usage.
+- Examine the user account under which the process was executed to determine if it aligns with expected behavior or if it indicates potential unauthorized access.
+- Investigate the command line arguments and environment variables of the process to identify any suspicious or unusual commands that may suggest malicious activity.
+- Check the system logs around the time of the alert for any related events or anomalies that could provide additional context or indicate a broader attack pattern.
+- Correlate the alert with other security events or alerts from the same host to identify if this is part of a larger attack or if there are other indicators of compromise.
+- Assess the network activity of the host to identify any unusual outbound connections that could suggest data exfiltration or communication with a command and control server.
+
+### False positive analysis
+
+- Legitimate applications or services may use signals in the 32-64 range for custom inter-process communication, leading to false positives. Identify these applications and create exceptions for their specific processes.
+- Some system monitoring or management tools might utilize these signals for legitimate process management tasks. Review the tools in use and whitelist their activities if they are verified as non-threatening.
+- Development environments or testing frameworks might employ unusual signals for debugging or testing purposes. Ensure these environments are properly isolated and exclude their activities from triggering alerts.
+- Custom scripts or automation tasks could be configured to use these signals for specific operations. Audit these scripts and, if deemed safe, add them to an exception list to prevent unnecessary alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent potential lateral movement by the adversary.
+- Terminate any suspicious processes identified with unusual kill signals in the range of 32-64 to halt any ongoing malicious activity.
+- Conduct a thorough forensic analysis of the affected system to identify any rootkits or malicious software that may have been installed, focusing on the processes and files associated with the unusual kill signals.
+- Restore the system from a known good backup if rootkit presence is confirmed, ensuring that the backup is free from any compromise.
+- Update and patch the system to the latest security standards to close any vulnerabilities that may have been exploited.
+- Implement enhanced monitoring and logging for unusual kill signals and related activities to detect any future attempts at similar attacks.
+- Escalate the incident to the security operations center (SOC) or relevant cybersecurity team for further investigation and to assess the need for broader organizational response measures.
+"""
+references = [
+    "https://github.com/m0nad/Diamorphine/blob/master/diamorphine.c#L302",
+    "https://www.elastic.co/security-labs/linux-detection-engineering-with-auditd",
+]
+risk_score = 47
+rule_id = "cf307a5a-d503-44a4-8158-db196d99c9df"
+setup = """## Setup
+
+This rule requires the use of the `auditd_manager` integration. `Auditd_manager` is a tool designed to simplify and enhance the management of the audit subsystem in Linux systems. It provides a user-friendly interface and automation capabilities for configuring and monitoring system auditing through the auditd daemon. With `auditd_manager`, administrators can easily define audit rules, track system events, and generate comprehensive audit reports, improving overall security and compliance in the system. The following steps should be executed in order to install and deploy `auditd_manager` on a Linux system.
+```
+Kibana -->
+Management -->
+Integrations -->
+Auditd Manager -->
+Add Auditd Manager
+```
+`Auditd_manager` subscribes to the kernel and receives events as they occur without any additional configuration. However, if more advanced configuration is required to detect specific behavior, audit rules can be added to the integration in either the "audit rules" configuration box or the "auditd rule files" box by specifying a file to read the audit rules from.
+For this detection rule to trigger, the following additional audit rules are required to be added to the integration:
+```
+-a always,exit -F arch=b64 -S kill
+```
+Add the newly installed `auditd manager` to an agent policy, and deploy the agent on a Linux system from which auditd log files are desirable.
+"""
+severity = "medium"
+tags = [
+    "Domain: Endpoint",
+    "OS: Linux",
+    "Use Case: Threat Detection",
+    "Tactic: Defense Evasion",
+    "Data Source: Auditd Manager",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "eql"
+query = '''
+process where host.os.type == "linux" and event.action == "killed-pid" and auditd.data.syscall == "kill" and
+auditd.data.a1 in (
+  "21", "22", "23", "24", "25", "26", "27", "28", "29", "2a", "2b", "2c", "2d", "2e", "2f", "30",
+  "31", "32", "33", "34", "35", "36", "37", "38", "39", "3a", "3b", "3c", "3d", "3e", "3f", "40",
+  "41", "42", "43", "44", "45", "46", "47"
+)
+'''
+
+[[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/"

nldcsc_elastic_rules/rules/linux/defense_evasion_unusual_preload_env_vars.toml

@@ -0,0 +1,152 @@
+[metadata]
+creation_date = "2024/12/16"
+integration = ["endpoint"]
+maturity = "production"
+updated_date = "2025/01/15"
+
+[rule]
+author = ["Elastic"]
+description = """
+This rule detects processes that are executed with environment variables that are not commonly used. This could indicate
+an attacker is attempting to hijack the execution flow of a process by loading malicious libraries or binaries into the
+process memory space.
+"""
+from = "now-9m"
+index = ["logs-endpoint.events.process*"]
+language = "kuery"
+license = "Elastic License v2"
+name = "Unusual Preload Environment Variable Process Execution"
+risk_score = 21
+rule_id = "a22b8486-5c4b-4e05-ad16-28de550b1ccc"
+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).
+
+Elastic Defend integration does not collect environment variable logging by default.
+In order to capture this behavior, this rule requires a specific configuration option set within the advanced settings of the Elastic Defend integration.
+ #### To set up environment variable capture for an Elastic Agent policy:
+- Go to “Security → Manage → Policies”.
+- Select an “Elastic Agent policy”.
+- Click “Show advanced settings”.
+- Scroll down or search for “linux.advanced.capture_env_vars”.
+- Enter the names of environment variables you want to capture, separated by commas.
+- For this rule the linux.advanced.capture_env_vars variable should be set to "LD_PRELOAD,LD_LIBRARY_PATH".
+- Click “Save”.
+After saving the integration change, the Elastic Agents running this policy will be updated and the rule will function properly.
+For more information on capturing environment variables refer to the [helper guide](https://www.elastic.co/guide/en/security/current/environment-variable-capture.html).
+"""
+severity = "low"
+tags = [
+    "Domain: Endpoint",
+    "OS: Linux",
+    "Use Case: Threat Detection",
+    "Tactic: Defense Evasion",
+    "Tactic: Persistence",
+    "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "new_terms"
+query = '''
+event.category:process and host.os.type:linux and event.type:start and event.action:exec and process.env_vars:*
+'''
+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 Preload Environment Variable Process Execution
+
+In Linux environments, preload environment variables can dictate which libraries are loaded into a process, potentially altering its behavior. Adversaries exploit this by injecting malicious libraries to hijack execution flow, achieving persistence or evasion. The detection rule identifies atypical environment variables during process execution, signaling potential misuse by attackers.
+
+### Possible investigation steps
+
+- Review the process details associated with the alert, focusing on the process name, command line, and any unusual environment variables listed in process.env_vars.
+- Investigate the parent process to understand the context of how the process was initiated and whether it aligns with expected behavior.
+- Check the history of the process and its associated user account to identify any recent changes or suspicious activities that might indicate compromise.
+- Analyze the libraries or binaries specified in the environment variables to determine if they are legitimate or potentially malicious.
+- Cross-reference the process and environment variables with known threat intelligence sources to identify any matches with known malicious activity.
+- Examine system logs and other related alerts around the same timeframe to identify any correlated or supporting evidence of malicious activity.
+
+### False positive analysis
+
+- Development and testing environments often use custom preload variables to test new libraries, which can trigger false positives. Users should identify and whitelist these known variables to prevent unnecessary alerts.
+- Some legitimate software applications may use uncommon preload environment variables for performance optimization or compatibility reasons. Users can create exceptions for these applications by verifying their source and behavior.
+- System administrators might employ preload variables for system tuning or debugging purposes. Documenting and excluding these specific cases can help reduce false positives.
+- Security tools and monitoring solutions might use preload variables as part of their operation. Ensure these tools are recognized and excluded from triggering alerts by maintaining an updated list of their known behaviors.
+- Regularly review and update the list of excluded variables and processes to adapt to changes in the environment and software updates, ensuring that only non-threatening behaviors are excluded.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
+- Terminate any suspicious processes identified with unusual preload environment variables to halt potential malicious execution.
+- Conduct a thorough review of the affected system's environment variables and loaded libraries to identify and remove any unauthorized or malicious entries.
+- Restore the affected system from a known good backup to ensure all malicious modifications are removed.
+- Update and patch the system to the latest security standards to mitigate vulnerabilities that could be exploited for similar attacks.
+- Monitor the network and system logs for any signs of re-infection or similar suspicious activity, focusing on process execution patterns.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are compromised."""
+
+[[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]
+id = "TA0005"
+name = "Defense Evasion"
+reference = "https://attack.mitre.org/tactics/TA0005/"
+
+[[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]
+id = "TA0003"
+name = "Persistence"
+reference = "https://attack.mitre.org/tactics/TA0003/"
+
+[rule.new_terms]
+field = "new_terms_fields"
+value = ["process.env_vars"]
+
+[[rule.new_terms.history_window_start]]
+field = "history_window_start"
+value = "now-14d"