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

nldcsc_elastic_rules/rules/linux/execution_suspicious_mkfifo_execution.toml

@@ -0,0 +1,138 @@
+[metadata]
+creation_date = "2025/04/30"
+integration = ["endpoint", "crowdstrike"]
+maturity = "production"
+updated_date = "2025/10/17"
+
+[rule]
+author = ["Elastic"]
+description = """
+This rule detects the creation of unusually labeled named pipes (FIFOs) by the mkfifo command, which is often used by
+attackers to establish persistence on a target system or to execute commands in the background. Through the new_terms
+rule type, this rule can identify uncommon process command lines that may indicate the presence of a malicious
+named pipe.
+"""
+from = "now-9m"
+index = ["logs-endpoint.events.process*", "logs-crowdstrike.fdr*"]
+language = "kuery"
+license = "Elastic License v2"
+name = "Suspicious Named Pipe 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 Suspicious Named Pipe Creation
+
+Named pipes, or FIFOs, are a form of inter-process communication in Linux environments, allowing data transfer between processes. Adversaries exploit this by creating named pipes in common directories like /tmp to stealthily execute commands or maintain persistence. The detection rule identifies unusual named pipe creation by monitoring the `mkfifo` command, especially when initiated by common shell processes, to flag potential malicious activity.
+
+### Possible investigation steps
+
+- Review the process command line arguments to identify the exact named pipe path and any associated commands or scripts that might have been executed using the named pipe.
+- Investigate the parent process (bash, csh, dash, fish, ksh, sh, tcsh, or zsh) to determine the origin of the mkfifo command, checking for any unusual or unexpected scripts or commands that might have initiated it.
+- Examine the user account associated with the mkfifo process to determine if it is a legitimate user or if the account might have been compromised.
+- Check for any other suspicious activities or processes running under the same user account or originating from the same parent process to identify potential lateral movement or further malicious actions.
+- Analyze the system logs around the time of the named pipe creation for any other indicators of compromise, such as unauthorized access attempts or unusual network connections.
+- If possible, capture and review the contents of the named pipe to understand the data being transferred and assess whether it is part of a malicious operation.
+
+### False positive analysis
+
+- Named pipes created by legitimate applications for inter-process communication can trigger this rule. Users should identify and whitelist these applications by adding exceptions for specific process command lines that are known to be safe.
+- System maintenance scripts or backup processes that use named pipes in directories like /tmp or /var/tmp may cause false positives. Review these scripts and exclude them from the rule if they are verified as non-malicious.
+- Development environments or testing frameworks that frequently create and delete named pipes during their operations might be flagged. Users can mitigate this by excluding these environments from monitoring or by specifying exceptions for known development tools.
+- Automated deployment tools that use named pipes for configuration management or orchestration tasks can also be a source of false positives. Ensure these tools are recognized and excluded from the rule to prevent unnecessary alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further malicious activity or lateral movement.
+- Terminate any suspicious processes associated with the mkfifo command, especially those originating from common shell processes like bash or sh.
+- Delete any named pipes created in directories such as /tmp, /dev/shm, or /var/tmp that do not follow expected naming conventions or are not part of legitimate applications.
+- Conduct a thorough review of user accounts and permissions on the affected system to identify any unauthorized access or privilege escalation.
+- Restore the system from a known good backup if any unauthorized changes or persistence mechanisms are detected.
+- Implement additional monitoring on the affected system and network to detect any further attempts to create suspicious named pipes or execute unauthorized commands.
+- Escalate the incident to the security operations team for further investigation and to determine if the threat is part of a larger attack campaign.
+"""
+risk_score = 21
+rule_id = "8167c5ae-3310-439a-8a58-be60f55023d2"
+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: Execution",
+  "Tactic: Command and Control",
+  "Data Source: Elastic Defend",
+  "Resources: Investigation Guide",
+  "Data Source: Crowdstrike",
+]
+timestamp_override = "event.ingested"
+type = "new_terms"
+query = '''
+host.os.type:linux and event.category:process and event.type:start and event.action:(exec or ProcessRollup2) and process.name:mkfifo and
+process.parent.name:(bash or csh or dash or fish or ksh or sh or tcsh or zsh) and
+process.args:((/dev/shm/* or /tmp/* or /var/tmp/*) and not /*fifo*)
+'''
+
+[[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]]
+id = "T1059.004"
+name = "Unix Shell"
+reference = "https://attack.mitre.org/techniques/T1059/004/"
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+
+[rule.threat.tactic]
+name = "Command and Control"
+id = "TA0011"
+reference = "https://attack.mitre.org/tactics/TA0011/"
+
+[[rule.threat.technique]]
+name = "Application Layer Protocol"
+id = "T1071"
+reference = "https://attack.mitre.org/techniques/T1071/"
+
+[rule.new_terms]
+field = "new_terms_fields"
+value = ["host.id", "process.command_line"]
+
+[[rule.new_terms.history_window_start]]
+field = "history_window_start"
+value = "now-10d"

nldcsc_elastic_rules/rules/linux/execution_system_binary_file_permission_change.toml

@@ -0,0 +1,118 @@
+[metadata]
+creation_date = "2025/01/07"
+integration = ["endpoint"]
+maturity = "production"
+updated_date = "2025/02/04"
+
+[rule]
+author = ["Elastic"]
+description = """
+This rule identifies file permission modification events on files located in common system binary paths. Adversaries may attempt to
+hide their payloads in the default Linux system directories, and modify the file permissions of these payloads prior to execution.
+"""
+from = "now-9m"
+index = ["logs-endpoint.events.process*"]
+language = "eql"
+license = "Elastic License v2"
+name = "System Binary Path File Permission Modification"
+references = ["https://blog.exatrack.com/Perfctl-using-portainer-and-new-persistences/"]
+risk_score = 21
+rule_id = "0049cf71-fe13-4d79-b767-f7519921ffb5"
+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: 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.name in ("chmod", "chown") and
+process.args like~ (
+  "/bin/*", "/usr/bin/*", "/usr/local/bin/*", "/sbin/*", "/usr/sbin/*", "/usr/local/sbin/*",
+  "/lib/*", "/usr/lib/*", "/lib64/*", "/usr/lib64/*"
+) and
+process.args in ("4755", "755", "000", "777", "444", "-x", "+x") and not (
+  process.args in ("/bin/chmod", "/usr/bin/chmod", "/usr/local/bin/chmod") or
+  process.parent.executable like~ ("/tmp/newroot/*", "/var/lib/dpkg/info/*") or
+  process.parent.name in ("udevadm", "systemd", "entrypoint", "sudo", "dart") or
+  process.parent.command_line == "runc init" or
+  process.parent.args like "/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 System Binary Path File Permission Modification
+
+In Linux environments, system binary paths contain critical executables. Adversaries may exploit these by altering file permissions to execute malicious payloads. The detection rule monitors processes like `chmod` and `chown` in key directories, flagging suspicious permission changes. It excludes benign activities, focusing on unauthorized modifications to prevent potential execution of harmful scripts.
+
+### Possible investigation steps
+
+- Review the process details to identify the exact command executed, focusing on the process name and arguments, especially those involving `chmod` or `chown` in critical directories like `/bin`, `/usr/bin`, and `/lib`.
+- Examine the parent process information, including the executable path and command line, to determine if the process was initiated by a known or trusted application, excluding those like `udevadm`, `systemd`, or `sudo`.
+- Check the user account associated with the process to verify if the action was performed by an authorized user or if there are signs of compromised credentials.
+- Investigate the file or directory whose permissions were modified to assess its importance and potential impact, focusing on changes to permissions like `4755`, `755`, or `777`.
+- Correlate the event with other security alerts or logs to identify any related suspicious activities, such as unauthorized access attempts or unexpected script executions.
+- Review recent changes or updates in the system that might explain the permission modification, ensuring they align with legitimate administrative tasks or software installations.
+
+### False positive analysis
+
+- System updates and package installations often involve legitimate permission changes in system binary paths. Users can exclude processes with parent executables located in directories like /var/lib/dpkg/info to reduce noise from these activities.
+- Administrative scripts or automation tools may execute chmod or chown commands as part of routine maintenance. Exclude processes with parent names such as udevadm, systemd, or sudo to prevent these from being flagged.
+- Container initialization processes might trigger permission changes. Exclude processes with parent command lines like runc init to avoid false positives related to container setups.
+- Temporary script executions during software installations can cause permission modifications. Exclude processes with parent arguments matching patterns like /var/tmp/rpm-tmp.* to filter out these benign events.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or execution of malicious payloads.
+- Terminate any suspicious processes identified as executing `chmod` or `chown` commands in critical system binary paths.
+- Revert any unauthorized file permission changes to their original state to ensure system integrity and prevent execution of malicious scripts.
+- Conduct a thorough review of system logs and process execution history to identify any additional unauthorized activities or related threats.
+- Escalate the incident to the security operations team for further investigation and to determine if the threat has spread to other systems.
+- Implement additional monitoring on the affected system and similar environments to detect any recurrence of unauthorized permission modifications.
+- Review and update access controls and permissions policies to minimize the risk of unauthorized modifications in critical system directories."""
+
+[[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/"

nldcsc_elastic_rules/rules/linux/execution_tc_bpf_filter.toml

@@ -0,0 +1,124 @@
+[metadata]
+creation_date = "2022/07/11"
+integration = ["endpoint", "sentinel_one_cloud_funnel"]
+maturity = "production"
+updated_date = "2025/03/20"
+
+[rule]
+author = ["Elastic"]
+description = """
+Detects when the tc (transmission control) binary is utilized to set a BPF (Berkeley Packet Filter) on a network
+interface. Tc is used to configure Traffic Control in the Linux kernel. It can shape, schedule, police and drop traffic.
+A threat actor can utilize tc to set a bpf filter on an interface for the purpose of manipulating the incoming traffic.
+This technique is not at all common and should indicate abnormal, suspicious or malicious activity.
+"""
+from = "now-9m"
+index = ["endgame-*", "logs-endpoint.events.process*", "logs-sentinel_one_cloud_funnel.*"]
+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",
+]
+risk_score = 73
+rule_id = "ef04a476-07ec-48fc-8f3d-5e1742de76d3"
+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 = "high"
+tags = [
+    "Domain: Endpoint",
+    "OS: Linux",
+    "Use Case: Threat Detection",
+    "Tactic: Execution",
+    "Threat: TripleCross",
+    "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.executable == "/usr/sbin/tc" and
+process.args == "filter" and process.args == "add" and process.args == "bpf" and
+not process.parent.executable == "/usr/sbin/libvirtd"
+'''
+
+
+[[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/"
+

nldcsc_elastic_rules/rules/linux/execution_unix_socket_communication.toml

@@ -0,0 +1,109 @@
+[metadata]
+creation_date = "2023/09/04"
+integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_funnel"]
+maturity = "production"
+updated_date = "2025/03/20"
+
+[rule]
+author = ["Elastic"]
+description = """
+This rule monitors for inter-process communication via Unix sockets. Adversaries may attempt to communicate with local
+Unix sockets to enumerate application details, find vulnerabilities/configuration mistakes and potentially escalate
+privileges or set up malicious communication channels via Unix sockets for inter-process communication to attempt to
+evade detection.
+"""
+from = "now-9m"
+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"
+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 Unix Socket Connection
+
+Unix sockets facilitate efficient inter-process communication (IPC) on the same host, crucial for system operations. However, adversaries can exploit them to probe applications, identify weaknesses, or establish covert channels. The detection rule identifies suspicious use of tools like netcat and socat with specific arguments, signaling potential misuse of Unix sockets for unauthorized communication or privilege escalation attempts.
+
+### Possible investigation steps
+
+- Review the process details to confirm the execution of netcat or socat with the specified arguments, focusing on the process name and arguments fields to verify the suspicious activity.
+- Investigate the source and destination of the Unix socket connection by examining the process.args field to determine if the connection is legitimate or potentially malicious.
+- Check the user context under which the process was executed to assess if there is any indication of privilege escalation attempts.
+- Correlate the event with other logs or alerts from the same host to identify any patterns or additional suspicious activities that might indicate a broader attack.
+- Examine the process lineage to understand the parent process and any child processes spawned, which might provide insights into how the suspicious process was initiated.
+- Verify if the process is part of any known legitimate application or service by cross-referencing with system documentation or application inventories.
+
+### False positive analysis
+
+- Legitimate administrative tasks using netcat or socat for system maintenance or monitoring can trigger alerts. To manage this, identify and whitelist specific scripts or commands used regularly by system administrators.
+- Automated backup or monitoring tools that use Unix sockets for communication may be flagged. Review these tools and add them to an exception list if they are verified as safe and necessary for operations.
+- Certain applications may use Unix sockets for legitimate inter-process communication, such as database services or web servers. Monitor these applications and exclude their typical behavior from the rule to prevent unnecessary alerts.
+- Development environments where developers frequently use netcat or socat for testing purposes can generate false positives. Establish a policy to differentiate between development and production environments and apply exceptions accordingly.
+- System services like libvirt, which are known to use Unix sockets, should be excluded from the rule as indicated by the exception for /var/run/libvirt/libvirt-sock. Regularly update this list to include other known benign services.
+
+### Response and remediation
+
+- Immediately isolate the affected host from the network to prevent potential lateral movement or data exfiltration.
+- Terminate any suspicious processes identified by the detection rule, specifically those involving netcat or socat with the flagged arguments.
+- Conduct a thorough review of the affected system's logs to identify any unauthorized access or data manipulation that may have occurred.
+- Reset credentials and review permissions for any accounts that may have been compromised or used in the attack.
+- 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/"
+

nldcsc_elastic_rules/rules/linux/execution_unknown_rwx_mem_region_binary_executed.toml

@@ -0,0 +1,126 @@
+[metadata]
+creation_date = "2024/03/13"
+integration = ["auditd_manager"]
+maturity = "production"
+updated_date = "2025/01/24"
+
+[rule]
+author = ["Elastic"]
+description = """
+Monitors for the execution of a previously unknown unix binary with read, write and execute memory region permissions.
+The mprotect() system call is used to change the access protections on a region of memory that has already been
+allocated. This syscall allows a process to modify the permissions of pages in its virtual address space, enabling or
+disabling permissions such as read, write, and execute for those pages. RWX permissions on memory is in many cases
+overly permissive, and should be analyzed thoroughly.
+"""
+from = "now-9m"
+index = ["auditbeat-*", "logs-auditd_manager.auditd-*"]
+language = "kuery"
+license = "Elastic License v2"
+name = "Unknown Execution of Binary with RWX Memory Region"
+references = [
+    "https://man7.org/linux/man-pages/man2/mprotect.2.html",
+    "https://www.elastic.co/security-labs/linux-detection-engineering-with-auditd",
+]
+risk_score = 47
+rule_id = "23bcd283-2bc0-4db2-81d4-273fc051e5c0"
+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 mprotect
+```
+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: Execution",
+    "Data Source: Auditd Manager",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "new_terms"
+
+query = '''
+event.category:process and host.os.type:linux and auditd.data.syscall:mprotect and auditd.data.a2:7 and not (
+  process.executable:(
+    "/usr/share/kibana/node/bin/node" or "/usr/share/elasticsearch/jdk/bin/java" or "/usr/sbin/apache2"
+  ) or
+  process.name:(httpd or java)
+)
+'''
+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 Unknown Execution of Binary with RWX Memory Region
+
+In Linux environments, the `mprotect()` system call is crucial for managing memory permissions, allowing processes to modify access rights of memory pages. Adversaries exploit this by granting read, write, and execute (RWX) permissions to inject and execute malicious code. The detection rule identifies suspicious RWX memory allocations by monitoring `mprotect()` calls, excluding known safe binaries, thus highlighting potential threats.
+
+### Possible investigation steps
+
+- Review the process details associated with the alert, focusing on the process.executable and process.name fields to identify the binary that triggered the alert.
+- Investigate the command line arguments and parent process of the suspicious binary to understand its origin and purpose.
+- Check the process's hash against known threat intelligence databases to determine if it is associated with any known malicious activity.
+- Analyze the network activity of the process to identify any suspicious connections or data exfiltration attempts.
+- Examine the user account under which the process is running to assess if it has been compromised or is being used for unauthorized activities.
+- Review recent system logs and audit records for any other anomalies or related suspicious activities around the time of the alert.
+
+### False positive analysis
+
+- Known safe binaries like Node.js, Java, and Apache may trigger the rule due to their legitimate use of RWX memory regions. These are already excluded in the rule, but additional similar applications might need to be added to the exclusion list.
+- Custom or in-house developed applications that require RWX permissions for legitimate functionality can also cause false positives. Identify these applications and add them to the exclusion list to prevent unnecessary alerts.
+- Development environments or testing frameworks that dynamically generate and execute code might be flagged. Consider excluding these environments if they are known and trusted within your organization.
+- Security tools or monitoring software that perform memory analysis or manipulation could be mistakenly identified. Verify their behavior and exclude them if they are part of your security infrastructure.
+- Regularly review and update the exclusion list to ensure it reflects the current environment and any new applications that are introduced.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent potential lateral movement or data exfiltration by the malicious code.
+- Terminate the suspicious process identified by the detection rule to halt any ongoing malicious activity.
+- Conduct a forensic analysis of the affected system to identify the source and scope of the compromise, focusing on the unknown binary and its origin.
+- Remove any malicious binaries or scripts identified during the forensic analysis to prevent further execution.
+- Apply security patches and updates to the affected system to address any vulnerabilities that may have been exploited.
+- Restore the system from a known good backup if the integrity of the system is in question and ensure all security patches are applied post-restoration.
+- 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 = "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.new_terms]
+field = "new_terms_fields"
+value = ["process.executable"]
+[[rule.new_terms.history_window_start]]
+field = "history_window_start"
+value = "now-7d"
+
+