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

nldcsc_elastic_rules/rules/linux/defense_evasion_base64_decoding_activity.toml

@@ -0,0 +1,203 @@
+[metadata]
+creation_date = "2025/02/21"
+integration = ["endpoint"]
+maturity = "production"
+updated_date = "2025/07/16"
+
+[rule]
+author = ["Elastic"]
+description = """
+This rule leverages ESQL 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. ESQL 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"
+language = "esql"
+license = "Elastic License v2"
+name = "Unusual Base64 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 Unusual Base64 Encoding/Decoding Activity
+Base64 encoding is a method to convert binary data into ASCII text, often used for data transmission. Adversaries exploit this to obfuscate malicious payloads or commands, bypassing security controls. The detection rule identifies suspicious Base64 activity on Linux by monitoring specific processes and command patterns, flagging anomalies for further investigation.
+
+### Possible investigation steps
+
+- Review the process name and command line arguments to understand the context of the Base64 activity. Check if the process name matches known legitimate applications or scripts.
+- Examine the timestamp of the event to determine if the activity occurred during normal operational hours or if it coincides with other suspicious activities.
+- Investigate the host operating system type and agent ID to identify the specific Linux system involved and assess if it has a history of similar alerts or other security incidents.
+- Analyze the process command line for any unusual patterns or parameters that might indicate obfuscation or malicious intent, such as the presence of decode flags or unexpected Base64 operations.
+- Correlate the event with other logs or alerts from the same host or network to identify potential lateral movement or coordinated attacks.
+- Check for any recent changes or deployments on the affected system that might explain the Base64 activity, such as new software installations or updates.
+- Consult threat intelligence sources to determine if the observed Base64 patterns or command line arguments are associated with known malware or attack techniques.
+
+### False positive analysis
+
+- Routine administrative scripts may use base64 encoding for legitimate data processing tasks. Review the process.command_line and process.args fields to identify known scripts and consider excluding them from the rule.
+- Backup or data transfer operations might employ base64 encoding to handle binary data. Verify the process.name and process.command_line to ensure these operations are recognized and add exceptions for these specific processes.
+- Development environments often use base64 encoding for testing purposes. Identify development-related processes by examining the process.name and process.command_line and exclude them if they are part of regular development activities.
+- Automated system monitoring tools might trigger this rule if they use base64 encoding for log or data analysis. Check the agent.id and process.command_line to confirm these tools and exclude them from the rule if they are verified as non-threatening.
+- Security tools that perform data encoding for analysis or reporting could be flagged. Validate these tools by reviewing the process.name and process.command_line and create exceptions for them if they are part of the security infrastructure.
+
+### Response and remediation
+
+- Isolate the affected Linux system from the network to prevent further data exfiltration or lateral movement by the adversary.
+- Terminate any suspicious processes identified by the alert, particularly those involving base64 encoding/decoding, to halt potential malicious activity.
+- Conduct a thorough review of the process command lines and arguments flagged by the alert to identify any malicious scripts or payloads. Remove or quarantine these files as necessary.
+- Check for any unauthorized user accounts or privilege escalations that may have been established during the attack and revoke access immediately.
+- Restore any affected systems or files from a known good backup to ensure the integrity of the system and data.
+- Implement additional monitoring on the affected system and similar environments to detect any recurrence of the suspicious base64 activity.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if broader organizational impacts exist.
+"""
+risk_score = 21
+rule_id = "c5637438-e32d-4bb3-bc13-bd7932b3289f"
+setup = """## Setup
+
+This rule requires data coming in from one of the following integrations:
+- 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: Defense Evasion",
+    "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "esql"
+
+query = '''
+from logs-endpoint.events.process-*
+| where
+    @timestamp > now() - 1h and
+    host.os.type == "linux" and
+    event.type == "start" and
+    event.action == "exec" and (
+        (
+            process.name in ("base64", "base64plain", "base64url", "base64mime", "base64pem", "base32", "base16") and
+            process.command_line like "*-*d*"
+        ) or
+        (
+            process.name == "openssl" and
+            process.args == "enc" and
+            process.args in ("-d", "-base64", "-a")
+        ) or
+        (
+            process.name like "python*" and (
+                (
+                    process.args == "base64" and
+                    process.args in ("-d", "-u", "-t")
+                ) or
+                (
+                    process.args == "-c" and
+                    process.command_line like "*base64*" and
+                    process.command_line like "*b64decode*"
+                )
+            )
+        ) or
+        (
+            process.name like "perl*" and
+            process.command_line like "*decode_base64*"
+        ) or
+        (
+            process.name like "ruby*" and
+            process.args == "-e" and
+            process.command_line like "*Base64.decode64*"
+        )
+    )
+| keep
+    @timestamp,
+    host.os.type,
+    event.type,
+    event.action,
+    process.name,
+    process.args,
+    process.command_line,
+    agent.id,
+    host.name
+| stats
+    Esql.event_count = count(),
+    Esql.agent_id_count_distinct = count_distinct(agent.id),
+    Esql.host_name_values = values(host.name),
+    Esql.agent_id_values = values(agent.id)
+    by process.name, process.command_line
+| where
+    Esql.agent_id_count_distinct == 1 and
+    Esql.event_count < 15
+| sort Esql.event_count asc
+| limit 100
+'''
+
+
+[[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.technique]]
+id = "T1140"
+name = "Deobfuscate/Decode Files or Information"
+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.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/"
+

nldcsc_elastic_rules/rules/linux/defense_evasion_binary_copied_to_suspicious_directory.toml

@@ -0,0 +1,156 @@
+[metadata]
+creation_date = "2023/08/29"
+integration = ["endpoint"]
+maturity = "production"
+updated_date = "2025/05/05"
+
+[rule]
+author = ["Elastic"]
+description = """
+This rule monitors for the copying or moving of a system binary. Adversaries may copy/move and rename system binaries to
+evade detection. Copying a system binary to a different location should not occur often, so if it does, the activity
+should be investigated.
+"""
+from = "now-9m"
+index = ["logs-endpoint.events.file*"]
+language = "eql"
+license = "Elastic License v2"
+name = "System Binary Moved or Copied"
+references = [
+    "https://intezer.com/blog/research/kaiji-new-chinese-linux-malware-turning-to-golang/",
+    "https://www.elastic.co/security-labs/sequel-on-persistence-mechanisms",
+]
+risk_score = 47
+rule_id = "fda1d332-5e08-4f27-8a9b-8c802e3292a6"
+setup = """## Setup
+
+This rule requires data coming in from Elastic Defend.
+
+### Elastic Defend Integration Setup
+Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app.
+
+#### Prerequisite Requirements:
+- Fleet is required for Elastic Defend.
+- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).
+
+#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:
+- Go to the Kibana home page and click "Add integrations".
+- In the query bar, search for "Elastic Defend" and select the integration to see more details about it.
+- Click "Add Elastic Defend".
+- Configure the integration name and optionally add a description.
+- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads".
+- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. [Helper guide](https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html).
+- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions"
+- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead.
+For more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).
+- Click "Save and Continue".
+- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts.
+For more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).
+"""
+severity = "medium"
+tags = [
+    "Domain: Endpoint",
+    "OS: Linux",
+    "Use Case: Threat Detection",
+    "Tactic: Defense Evasion",
+    "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "eql"
+
+query = '''
+file where host.os.type == "linux" and event.type == "change" and event.action == "rename" and process.name != null and
+file.Ext.original.path : (
+  "/bin/*", "/usr/bin/*", "/usr/local/bin/*", "/sbin/*", "/usr/sbin/*", "/usr/local/sbin/*"
+) and not (
+  process.executable in (
+    "/bin/dpkg", "/usr/bin/dpkg", "/bin/dockerd", "/usr/bin/dockerd", "/usr/sbin/dockerd", "/bin/microdnf",
+    "/usr/bin/microdnf", "/bin/rpm", "/usr/bin/rpm", "/bin/snapd", "/usr/bin/snapd", "/bin/yum", "/usr/bin/yum",
+    "/bin/dnf", "/usr/bin/dnf", "/bin/podman", "/usr/bin/podman", "/bin/dnf-automatic", "/usr/bin/dnf-automatic",
+    "/bin/pacman", "/usr/bin/pacman", "/usr/bin/dpkg-divert", "/bin/dpkg-divert", "/sbin/apk", "/usr/sbin/apk",
+    "/usr/local/sbin/apk", "/usr/bin/apt", "/usr/sbin/pacman", "/bin/podman", "/usr/bin/podman", "/usr/bin/puppet",
+    "/bin/puppet", "/opt/puppetlabs/puppet/bin/puppet", "/usr/bin/chef-client", "/bin/chef-client",
+    "/bin/autossl_check", "/usr/bin/autossl_check", "/proc/self/exe", "/dev/fd/*",  "/usr/bin/pamac-daemon",
+    "/bin/pamac-daemon", "/usr/lib/snapd/snapd", "/usr/local/bin/dockerd", "/usr/libexec/netplan/generate",
+    "/usr/bin/update-alternatives", "/bin/update-alternatives", "/usr/sbin/update-alternatives",
+    "/sbin/update-alternatives", "/usr/bin/pip3", "/bin/pip3", "/usr/local/bin/pip3", "/usr/local/bin/node",
+    "/bin/node", "/usr/bin/node", "/sbin/apk", "/usr/sbin/apk", "/usr/local/sbin/apk", "/usr/bin/pip", "/bin/pip",
+    "/usr/local/bin/pip", "/usr/libexec/platform-python", "/usr/bin/platform-python", "/bin/platform-python",
+    "/usr/lib/systemd/systemd", "/usr/sbin/sshd", "/sbin/sshd", "/usr/local/sbin/sshd", "/usr/sbin/crond", "/sbin/crond",
+    "/usr/local/sbin/crond", "/usr/sbin/gdm"
+  ) or
+  process.name like (
+    "python*", "packagekitd", "systemd", "ln", "platform-python", "dnf_install", "runc", "apt-get", "ssm-agent-worker",
+    "convert-usrmerge", "updatenow.static-cpanelsync", "apk", "exe", "php", "containerd-shim-runc-v2", "dpkg", "sed",
+    "platform-python*", "gedit", "crond", "sshd", "ruby", "sudo", "chainctl", "update-alternatives", "pip*", "microdnf",
+    "rsync", "convert2rhel", "convert-usr-merge"
+  ) or
+  file.Ext.original.path : (
+    "/bin/*.tmp", "/usr/bin/*.tmp", "/usr/local/bin/*.tmp", "/sbin/*.tmp", "/usr/sbin/*.tmp", "/usr/local/sbin/*.tmp"
+  ) or
+  file.extension in ("swp", "swpx", "swx", "dpkg-remove") or
+  file.Ext.original.extension == "dpkg-new" or
+  process.executable : ("/nix/store/*", "/var/lib/dpkg/*", "/tmp/vmis.*", "/snap/*", "/dev/fd/*") or
+  process.executable == null or
+  (process.name == "sed" and file.name : "sed*") or
+  (process.name == "perl" and file.name : "e2scrub_all.tmp*")
+)
+'''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> 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 Moved or Copied
+
+System binaries are essential executables in Linux environments, crucial for system operations. Adversaries may move or copy these binaries to alternate locations to evade detection, often renaming them to blend in with legitimate processes. The detection rule identifies unusual movements or copies of these binaries, excluding common system processes and paths, to flag potential malicious activity. This helps in identifying attempts at masquerading, a tactic used to bypass security measures.
+
+### Possible investigation steps
+
+- Review the file path and name in the alert to determine if the binary was moved or copied to a suspicious or unusual location, which could indicate an attempt to masquerade.
+- Examine the process name and executable path that triggered the alert to identify if it is associated with known legitimate processes or if it appears suspicious or unexpected.
+- Check the user account associated with the process to determine if the action was performed by a privileged or unauthorized user, which could suggest malicious intent.
+- Investigate the historical activity of the process and user involved to identify any patterns or previous suspicious behavior that might correlate with the current alert.
+- Correlate the alert with other security events or logs from the same timeframe to identify any related activities or anomalies that could provide additional context or evidence of malicious activity.
+
+### False positive analysis
+
+- System updates and package installations often involve legitimate movement or copying of binaries. Exclude processes like dpkg, rpm, and apt-get from triggering alerts by adding them to the exception list.
+- Development and testing environments may frequently rename or move binaries for testing purposes. Consider excluding paths like /tmp or /dev/fd from monitoring if they are commonly used for non-malicious activities.
+- Automated scripts or configuration management tools such as Puppet or Chef may move binaries as part of their normal operations. Add these tools to the exception list to prevent unnecessary alerts.
+- Temporary files created during software installations or updates, such as those with extensions like .tmp or .dpkg-new, can trigger false positives. Exclude these extensions from monitoring to reduce noise.
+- Custom scripts or applications that mimic system processes for legitimate reasons might be flagged. Review and whitelist these specific scripts or applications if they are verified as non-threatening.
+
+### 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 identified in the alert that are associated with the unauthorized movement or copying of system binaries.
+- Restore any altered or moved system binaries to their original locations and verify their integrity using known good backups or checksums.
+- Conduct a thorough review of system logs and the alert details to identify any additional indicators of compromise or related malicious activity.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.
+- Implement additional monitoring on the affected system and similar environments to detect any recurrence of the activity, focusing on the specific paths and processes identified in the alert.
+- Review and update access controls and permissions to ensure that only authorized users and processes can modify or move system binaries, reducing the risk of similar incidents in the future."""
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+
+[[rule.threat.technique]]
+id = "T1036"
+name = "Masquerading"
+reference = "https://attack.mitre.org/techniques/T1036/"
+
+[[rule.threat.technique.subtechnique]]
+id = "T1036.003"
+name = "Rename Legitimate Utilities"
+reference = "https://attack.mitre.org/techniques/T1036/003/"
+
+[[rule.threat.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/"

nldcsc_elastic_rules/rules/linux/defense_evasion_busybox_indirect_shell_spawn.toml

@@ -0,0 +1,139 @@
+[metadata]
+creation_date = "2025/11/20"
+integration = ["endpoint"]
+maturity = "production"
+updated_date = "2025/11/24"
+
+[rule]
+author = ["Elastic"]
+description = """
+Detects the execution of a shell through Busybox. Attackers may use this technique to execute shells while attempting to
+evade detection.
+"""
+from = "now-9m"
+index = ["logs-endpoint.events.process*"]
+language = "eql"
+license = "Elastic License v2"
+name = "Proxy Shell Execution via Busybox"
+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 Proxy Shell Execution via Busybox
+
+This rule identifies Linux shells started via Busybox, indicating proxy execution to sidestep controls that focus on direct shell binaries. Adversaries leverage Busybox’s ubiquity and static build to blend in, obscure parentage, and run commands in constrained or minimal environments. A common pattern is copying a standalone busybox into /tmp on a container or embedded host, making it executable, then invoking busybox sh to run one-liners, pull payloads, and stage persistence.
+
+### Possible investigation steps
+
+- Correlate the event to a user session or container exec by pivoting to TTY/session ID, SSH auth logs, and Kubernetes/Docker exec audits to verify whether it was an authorized action.
+- Determine Busybox provenance by checking its path and file metadata (non-standard location, recent write, unusual owner/capabilities or symlink), confirming package ownership, and hashing against trusted repositories and threat intelligence.
+- Expand the process tree 10–15 minutes around the event to find staging steps (curl/wget/tftp, chmod, mv) and post-shell behavior (reverse shells, crypto miners, persistence writes).
+- Collect live context for the shell (current working directory, environment, open sockets, controlling TTY, effective user) to quickly decide if it is interactive misuse or command staging.
+- Hunt across hosts for similar Busybox-to-shell chains and review persistence artifacts and new files in writable dirs (crontab, systemd units, rc files, authorized_keys, /tmp, /dev/shm) to catch follow-on activity.
+
+### False positive analysis
+
+- An administrator performing recovery on a minimal host may copy a static busybox and start an interactive sh with no arguments for troubleshooting, producing a busybox-to-shell chain that is expected.
+- Legitimate privilege-switch or login workflows using Busybox applets (e.g., su or login) can spawn a bare sh without -c for an authenticated session, so confirm a controlling TTY, expected user, and standard paths before treating it as malicious.
+
+### Response and remediation
+
+- Immediately isolate the impacted host or container at the network level, terminate any shells whose parent is busybox, and block outbound traffic initiated by those shells (e.g., nc, curl/wget, ssh to unknown IPs).
+- Identify and remove rogue busybox copies or symlinks in writable locations such as /tmp, /var/tmp, and /dev/shm by revoking execute permissions or deleting them, and capture file hashes, paths, and mtimes for evidence.
+- Remove persistence and droppers created by the busybox-spawned shell by cleaning newly added cron entries under /etc/cron.*, systemd units in /etc/systemd/system, rc.local edits, and suspicious authorized_keys or ~/.bashrc/.profile changes, then reboot if kernel modules or LD_PRELOAD were modified.
+- Reset passwords, rotate SSH keys and tokens used in the session, rebuild affected containers from clean images or reimage hosts if system binaries were changed, and restore services only after verifying no busybox-to-shell chains launch at startup.
+- Escalate to incident response if the busybox-launched shell ran as root, established a reverse connection (e.g., bash -i >& /dev/tcp/<IP>/<port>), created SUID files, or dropped payloads in /tmp, /var/tmp, or /dev/shm, or if a new busybox binary was downloaded or touched minutes before execution.
+- Harden by enforcing noexec,nosuid,nodev mounts on /tmp and /var/tmp, constraining busybox with AppArmor/SELinux to block spawning interactive shells or execution from world-writable paths, locking down container runtime exec and capabilities (e.g., disable kubectl/docker exec for non-admins, remove CAP_SYS_ADMIN), and implementing file integrity monitoring on busybox and standard shells.
+"""
+references = ["https://gtfobins.github.io/gtfobins/busybox/"]
+risk_score = 21
+rule_id = "5134be90-42c1-4ac7-859c-4d82caaddbec"
+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: Defense Evasion",
+    "Tactic: Execution",
+    "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "eql"
+query = '''
+process where host.os.type == "linux" and  event.type == "start" and event.action == "exec" and process.parent.name == "busybox" and
+process.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and
+process.command_line in ("bash", "bash-", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and
+not (
+  process.args == "-c" or
+  process.parent.args : (
+    "crond", "/usr/sbin/crond", "/local-registrator.sh", "/var/atlassian/application-data/bamboo-agent*"
+  ) or
+  process.parent.command_line in (
+    "sh /readonly-config/fix-split-brain.sh",
+    "/bin/sh -c /health-check.sh || bash -c 'kill -s 15 $(pidof siridb-server) && (sleep 10; kill -s 9 $(pidof siridb-server))'"
+  ) or
+  process.command_line == "bash /etc/kafka/docker/run" or
+  process.parent.command_line like (
+    "/bin/sh -c apk add*", "/bin/sh -c crm-cron-enabled*", "udhcpc -n -p /run/udhcpc.*", "flock -x*"
+  ) or
+  process.working_directory == "/usr/share/grafana"
+)
+'''
+
+[[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 = "T1218"
+    name = "System Binary Proxy Execution"
+    reference = "https://attack.mitre.org/techniques/T1218/"
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+
+  [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/"

nldcsc_elastic_rules/rules/linux/defense_evasion_chattr_immutable_file.toml

@@ -0,0 +1,140 @@
+[metadata]
+creation_date = "2022/07/22"
+integration = ["endpoint", "sentinel_one_cloud_funnel"]
+maturity = "production"
+updated_date = "2025/03/20"
+
+[rule]
+author = ["Elastic"]
+description = """
+Detects a file being made immutable using the chattr binary. Making a file immutable means it cannot be deleted or
+renamed, no link can be created to this file, most of the file's metadata can not be modified, and the file can not be
+opened in write mode. Threat actors will commonly utilize this to prevent tampering or modification of their malicious
+files or any system files they have modified for purposes of persistence (e.g .ssh, /etc/passwd, etc.).
+"""
+from = "now-9m"
+index = ["auditbeat-*", "endgame-*", "logs-endpoint.events.process*", "logs-sentinel_one_cloud_funnel.*"]
+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
+
+This rule requires data coming in from one of the following integrations:
+- Elastic Defend
+- Auditbeat
+
+### 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).
+
+### Auditbeat Setup
+Auditbeat is a lightweight shipper that you can install on your servers to audit the activities of users and processes on your systems. For example, you can use Auditbeat to collect and centralize audit events from the Linux Audit Framework. You can also use Auditbeat to detect changes to critical files, like binaries and configuration files, and identify potential security policy violations.
+
+#### The following steps should be executed in order to add the Auditbeat on a Linux System:
+- Elastic provides repositories available for APT and YUM-based distributions. Note that we provide binary packages, but no source packages.
+- To install the APT and YUM repositories follow the setup instructions in this [helper guide](https://www.elastic.co/guide/en/beats/auditbeat/current/setup-repositories.html).
+- To run Auditbeat on Docker follow the setup instructions in the [helper guide](https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-docker.html).
+- To run Auditbeat on Kubernetes follow the setup instructions in the [helper guide](https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-kubernetes.html).
+- For complete “Setup and Run Auditbeat” information refer to the [helper guide](https://www.elastic.co/guide/en/beats/auditbeat/current/setting-up-and-running.html).
+
+#### Custom Ingest Pipeline
+For versions <8.2, you need to add a custom ingest pipeline to populate `event.ingested` with @timestamp for non-elastic-agent indexes, like auditbeats/filebeat/winlogbeat etc. For more details to add a custom ingest pipeline refer to the [guide](https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html).
+"""
+severity = "medium"
+tags = [
+    "Domain: Endpoint",
+    "OS: Linux",
+    "Use Case: Threat Detection",
+    "Tactic: Defense Evasion",
+    "Data Source: Elastic Endgame",
+    "Data Source: Elastic Defend",
+    "Data Source: SentinelOne",
+    "Resources: Investigation Guide",
+]
+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 (
+  process.parent.executable: ("/lib/systemd/systemd", "/usr/local/uems_agent/bin/*", "/usr/lib/systemd/systemd") or
+  process.parent.name in (
+    "systemd", "cf-agent", "ntpdate", "xargs", "px", "preinst", "auth", "cf-agent", "dcservice", "dcagentupgrader",
+    "sudo", "ephemeral-disk-warning"
+  )
+)
+'''
+
+
+[[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/"
+