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

nldcsc_elastic_rules/rules/linux/privilege_escalation_docker_mount_chroot_container_escape.toml

@@ -0,0 +1,130 @@
+[metadata]
+creation_date = "2024/01/15"
+integration = ["endpoint", "sentinel_one_cloud_funnel", "crowdstrike"]
+maturity = "production"
+updated_date = "2025/10/17"
+
+[rule]
+author = ["Elastic"]
+description = """
+Monitors for the execution of a file system mount followed by a chroot execution. Given enough permissions, a user
+within a container is capable of mounting the root file system of the host, and leveraging chroot to escape its
+containarized environment. This behavior pattern is very uncommon and should be investigated.
+"""
+from = "now-9m"
+index = ["logs-endpoint.events.process*", "logs-sentinel_one_cloud_funnel.*", "logs-crowdstrike.fdr*"]
+language = "eql"
+license = "Elastic License v2"
+name = "Potential Chroot Container Escape via Mount"
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
+
+### Investigating Potential Chroot Container Escape via Mount
+
+Chroot and mount are Linux utilities that can isolate processes and manage file systems, respectively. Adversaries may exploit these to escape containerized environments by mounting the host's root file system and using chroot to change the root directory, gaining unauthorized access. The detection rule identifies this rare sequence by monitoring for mount and chroot executions within a short timeframe, signaling potential privilege escalation attempts.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific host.id and process.parent.entity_id associated with the alert to understand which system and parent process are involved.
+- Examine the process execution timeline to confirm the sequence of the mount and chroot commands, ensuring they occurred within the specified maxspan of 5 minutes.
+- Investigate the process.args field for the mount command to determine the specific device or file system being targeted, especially focusing on any /dev/sd* entries that suggest attempts to access physical disks.
+- Check the user permissions and roles associated with the process.parent.name (e.g., bash, dash, sh) to assess if the user had sufficient privileges to perform such operations.
+- Analyze the broader context of the host.os.type to identify any recent changes or anomalies in the Linux environment that could have facilitated this behavior.
+- Correlate with other security logs or alerts from the same host to identify any additional suspicious activities or patterns that might indicate a broader attack or compromise.
+
+### False positive analysis
+
+- System maintenance scripts may trigger the rule if they involve mounting and chroot operations. Review scheduled tasks and scripts to identify legitimate use and consider excluding these specific processes from the rule.
+- Backup or recovery operations that require mounting file systems and changing root directories can also cause false positives. Identify these operations and create exceptions for the associated processes or users.
+- Development or testing environments where users frequently perform mount and chroot operations for legitimate purposes may trigger alerts. Evaluate the necessity of these actions and exclude known safe processes or users.
+- Automated deployment tools that use mount and chroot as part of their setup routines can be mistaken for malicious activity. Verify the tools and their processes, then add them to an exclusion list if they are deemed safe.
+- Custom scripts executed by trusted users that involve mount and chroot should be reviewed. If these scripts are part of regular operations, consider excluding them from the detection rule.
+
+### Response and remediation
+
+- Immediately isolate the affected container to prevent further unauthorized access or potential lateral movement within the host system.
+- Terminate any suspicious processes identified as executing the mount or chroot commands within the container to halt any ongoing escape attempts.
+- Conduct a thorough review of the container's permissions and configurations to ensure that only necessary privileges are granted, reducing the risk of similar exploits.
+- Inspect the host system for any signs of compromise or unauthorized access, focusing on logs and system changes around the time of the detected activity.
+- Restore the container from a known good backup if any unauthorized changes or compromises are detected, ensuring the environment is clean and secure.
+- Update and patch the container and host systems to address any known vulnerabilities that could be exploited for privilege escalation or container escape.
+- Escalate the incident to the security operations team for further analysis and to determine if additional monitoring or security measures are required to prevent future occurrences."""
+references = [
+    "https://book.hacktricks.xyz/v/portugues-ht/linux-hardening/privilege-escalation/escaping-from-limited-bash",
+]
+risk_score = 47
+rule_id = "5ae02ebc-a5de-4eac-afe6-c88de696477d"
+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).
+
+Session View uses process data collected by the Elastic Defend integration, but this data is not always collected by default. Session View is available on enterprise subscription for versions 8.3 and above.
+#### To confirm that Session View data is enabled:
+- Go to “Manage → Policies”, and edit one or more of your Elastic Defend integration policies.
+- Select the” Policy settings” tab, then scroll down to the “Linux event collection” section near the bottom.
+- Check the box for “Process events”, and turn on the “Include session data” toggle.
+- If you want to include file and network alerts in Session View, check the boxes for “Network and File events”.
+- If you want to enable terminal output capture, turn on the “Capture terminal output” toggle.
+For more information about the additional fields collected when this setting is enabled and the usage of Session View for Analysis refer to the [helper guide](https://www.elastic.co/guide/en/security/current/session-view.html).
+"""
+severity = "medium"
+tags = [
+  "Domain: Endpoint",
+  "OS: Linux",
+  "Use Case: Threat Detection",
+  "Tactic: Privilege Escalation",
+  "Domain: Container",
+  "Data Source: Elastic Defend",
+  "Data Source: SentinelOne",
+  "Resources: Investigation Guide",
+  "Data Source: Crowdstrike",
+]
+type = "eql"
+
+query = '''
+sequence by host.id, process.parent.entity_id with maxspan=5m
+  [process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "start", "ProcessRollup2") and
+   process.name == "mount" and process.args : "/dev/sd*" and process.args_count >= 3 and
+   process.parent.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish")]
+  [process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "start", "ProcessRollup2") and
+   process.name == "chroot"]
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1611"
+name = "Escape to Host"
+reference = "https://attack.mitre.org/techniques/T1611/"
+
+
+[rule.threat.tactic]
+id = "TA0004"
+name = "Privilege Escalation"
+reference = "https://attack.mitre.org/tactics/TA0004/"
+

nldcsc_elastic_rules/rules/linux/privilege_escalation_docker_release_file_creation.toml

@@ -0,0 +1,88 @@
+[metadata]
+creation_date = "2025/04/25"
+integration = ["endpoint"]
+maturity = "production"
+updated_date = "2025/07/07"
+
+[rule]
+author = ["Elastic"]
+description = """
+This rule detects the creation of files named release_agent or notify_on_release, which are
+commonly associated with the abuse of Linux cgroup release mechanisms. In Docker or containerized
+environments, this behavior may indicate an attempt to exploit privilege escalation vulnerabilities
+such as CVE-2022-0492, where attackers use the release_agent feature to execute code on the host
+from within a container.
+"""
+from = "now-9m"
+index = ["logs-endpoint.events.file*"]
+language = "eql"
+license = "Elastic License v2"
+name = "Docker Release File Creation"
+note = """ ## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
+
+### Investigating Docker Release File Creation
+
+In Linux, cgroups manage resources for processes, and the release_agent file can execute scripts when a cgroup is released. In containerized environments like Docker, adversaries may exploit this to escalate privileges, executing code on the host. The detection rule identifies the creation of files like release_agent, signaling potential misuse of cgroup release mechanisms for privilege escalation.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the file creation event occurred on a Linux host, as specified by the query field host.os.type == "linux".
+- Identify the specific file name created, either release_agent or notify_on_release, to understand the potential method of exploitation.
+- Investigate the process that created the file by examining process logs or using process monitoring tools to determine if it was initiated by a legitimate application or a suspicious process.
+- Check for any recent container activity on the host, such as new container deployments or changes, to identify potential sources of the file creation.
+- Analyze user activity logs to determine if any unauthorized or unusual user actions correlate with the file creation event.
+- Look for any additional indicators of compromise or related alerts on the host that might suggest a broader attack or exploitation attempt.
+- Assess the system for any signs of privilege escalation or unauthorized access to determine if the release_agent or notify_on_release file creation was part of a successful attack.
+
+### False positive analysis
+
+- System administrators or automated scripts may create release_agent or notify_on_release files for legitimate resource management tasks in containerized environments.
+- Regularly scheduled maintenance scripts might trigger the rule if they involve creating or modifying cgroup release files as part of their operations.
+- Developers testing container features might inadvertently create these files during the development process.
+- To handle these false positives, users can create exceptions for known scripts or processes that routinely create these files by whitelisting their specific paths or process names.
+- Implement monitoring to differentiate between expected and unexpected file creation events, focusing on unusual patterns or contexts that deviate from normal operations.
+
+### Response and remediation
+
+- Immediately isolate the affected container to prevent further exploitation or lateral movement. This can be done by stopping the container or disconnecting it from the network.
+- Investigate the container's logs and processes to identify any unauthorized or suspicious activity that may have occurred as a result of the release_agent or notify_on_release file creation.
+- Remove any unauthorized files or scripts that were executed as a result of the cgroup release mechanism exploitation. Ensure that the release_agent and notify_on_release files are deleted if they were created maliciously.
+- Patch the host system and all containers to address known vulnerabilities such as CVE-2022-0492. Ensure that all security updates are applied to prevent similar exploits.
+- Review and tighten the security configurations of Docker and the host system, including setting appropriate cgroup permissions and limiting container capabilities to the minimum necessary.
+- Monitor for any further attempts to exploit cgroup release mechanisms by setting up alerts for the creation of release_agent and notify_on_release files.
+- Escalate the incident to the security operations team for further analysis and to determine if additional systems may have been affected or if there is a broader security incident underway.
+"""
+references = ["https://sysdig.com/blog/detecting-mitigating-cve-2022-0492-sysdig/"]
+risk_score = 21
+rule_id = "4d4cda2b-9aad-4702-a0a2-75952bd6a77c"
+severity = "low"
+tags = [
+    "Domain: Endpoint",
+    "Domain: Container",
+    "OS: Linux",
+    "Use Case: Threat Detection",
+    "Tactic: Privilege Escalation",
+    "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "eql"
+query = '''
+file where host.os.type == "linux" and event.type == "creation" and file.name in ("release_agent", "notify_on_release")
+'''
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+
+[[rule.threat.technique]]
+id = "T1611"
+name = "Escape to Host"
+reference = "https://attack.mitre.org/techniques/T1611/"
+
+[rule.threat.tactic]
+id = "TA0004"
+name = "Privilege Escalation"
+reference = "https://attack.mitre.org/tactics/TA0004/"

nldcsc_elastic_rules/rules/linux/privilege_escalation_enlightenment_window_manager.toml

@@ -0,0 +1,115 @@
+[metadata]
+creation_date = "2024/01/05"
+integration = ["endpoint"]
+maturity = "production"
+updated_date = "2025/02/04"
+
+[rule]
+author = ["Elastic"]
+description = """
+Identifies an attempt to exploit a local privilege escalation CVE-2022-37706 via a flaw in Linux window manager package
+Enlightenment. enlightenment_sys in Enlightenment before 0.25.4 allows local users to gain privileges because it is
+setuid root, and the system library function mishandles pathnames that begin with a /dev/.. substring.
+"""
+from = "now-9m"
+index = ["logs-endpoint.events.process*"]
+language = "eql"
+license = "Elastic License v2"
+name = "Potential Privilege Escalation via Enlightenment"
+references = ["https://ubuntu.com/security/CVE-2022-37706", "https://www.exploit-db.com/exploits/51180"]
+risk_score = 73
+rule_id = "bc0fc359-68db-421e-a435-348ced7a7f92"
+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: Privilege Escalation",
+    "Use Case: Vulnerability",
+    "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
+]
+type = "eql"
+
+query = '''
+sequence by host.id, process.parent.entity_id with maxspan=5s
+  [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and
+    process.name == "enlightenment_sys" and process.args in ("/bin/mount/", "-o","noexec","nosuid","nodev","uid=*") ]
+  [process where host.os.type == "linux" and event.action == "uid_change" and event.type == "change" and user.id == "0"]
+'''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
+
+### Investigating Potential Privilege Escalation via Enlightenment
+
+Enlightenment, a Linux window manager, can be exploited for privilege escalation due to a flaw in its setuid root configuration. Attackers may exploit this by manipulating pathnames, gaining unauthorized root access. The detection rule identifies suspicious execution of 'enlightenment_sys' with specific arguments and subsequent UID changes to root, flagging potential exploitation attempts.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of the process "enlightenment_sys" with the specified arguments ("/bin/mount/", "-o", "noexec", "nosuid", "nodev", "uid=*") on a Linux host.
+- Check the process execution timeline to verify if the suspicious "enlightenment_sys" execution was followed by a UID change to root (user.id == "0") within a 5-second window.
+- Investigate the host.id and process.parent.entity_id to identify the parent process and determine if it was initiated by a legitimate user or service.
+- Examine the system logs around the time of the alert to identify any other unusual activities or related processes that might indicate a broader attack or exploitation attempt.
+- Assess the affected system for any unauthorized changes or signs of compromise, focusing on privilege escalation indicators and potential persistence mechanisms.
+- Review user access logs and permissions to determine if the user associated with the process had legitimate reasons to execute "enlightenment_sys" with elevated privileges.
+- Consider isolating the affected system to prevent further exploitation and begin remediation steps, such as applying patches or configuration changes to mitigate the vulnerability.
+
+### False positive analysis
+
+- Legitimate administrative tasks using enlightenment_sys may trigger the rule. Review the context of the execution, such as the user and the specific arguments used, to determine if the activity is authorized.
+- Automated scripts or system maintenance processes that involve enlightenment_sys with similar arguments might be flagged. Identify these scripts and consider excluding them by specifying their process hashes or paths in the detection rule.
+- System updates or package installations that temporarily change UID to root could be misinterpreted as exploitation attempts. Monitor these activities and whitelist known update processes to prevent false alerts.
+- Custom user applications that interact with enlightenment_sys for legitimate purposes may cause false positives. Evaluate these applications and, if deemed safe, add them to an exception list based on their unique identifiers.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
+- Terminate any suspicious processes related to 'enlightenment_sys' that are running with elevated privileges to stop ongoing exploitation.
+- Conduct a thorough review of system logs to identify any unauthorized changes or access patterns, focusing on UID changes to root.
+- Revoke any unauthorized access or privileges granted during the exploitation, ensuring that only legitimate users have root access.
+- Apply the latest security patches and updates to the Enlightenment package, specifically upgrading to version 0.25.4 or later to mitigate the vulnerability.
+- Implement file integrity monitoring to detect unauthorized changes to critical system files and configurations in the future.
+- Escalate the incident to the security operations team for further investigation and to assess the potential impact on other systems within the network."""
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1068"
+name = "Exploitation for Privilege Escalation"
+reference = "https://attack.mitre.org/techniques/T1068/"
+
+
+[rule.threat.tactic]
+id = "TA0004"
+name = "Privilege Escalation"
+reference = "https://attack.mitre.org/tactics/TA0004/"
+

nldcsc_elastic_rules/rules/linux/privilege_escalation_gdb_sys_ptrace_elevation.toml

@@ -0,0 +1,127 @@
+[metadata]
+creation_date = "2024/01/09"
+integration = ["endpoint"]
+maturity = "production"
+updated_date = "2025/02/04"
+
+[rule]
+author = ["Elastic"]
+description = """
+Identifies instances where GDB (granted the CAP_SYS_PTRACE capability) is executed, after which the user's access is
+elevated to UID/GID 0 (root). In Linux, the CAP_SYS_PTRACE capability grants a process the ability to use the ptrace
+system call, which is typically used for debugging and allows the process to trace and control other processes.
+Attackers may leverage this capability to hook and inject into a process that is running with root permissions in order
+to escalate their privileges to root.
+"""
+from = "now-9m"
+index = ["logs-endpoint.events.process*"]
+language = "eql"
+license = "Elastic License v2"
+name = "Privilege Escalation via GDB CAP_SYS_PTRACE"
+risk_score = 47
+rule_id = "c296f888-eac6-4543-8da5-b6abb0d3304f"
+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: Privilege Escalation",
+    "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
+]
+type = "eql"
+
+query = '''
+sequence by host.id, process.entry_leader.entity_id with maxspan=1m
+  [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and process.name == "gdb" and
+   (process.thread.capabilities.effective : "CAP_SYS_PTRACE" or process.thread.capabilities.permitted : "CAP_SYS_PTRACE") and
+   user.id != "0"]
+  [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and
+   process.name != null and user.id == "0"]
+'''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
+
+### Investigating Privilege Escalation via GDB CAP_SYS_PTRACE
+
+The CAP_SYS_PTRACE capability in Linux allows processes to trace and control other processes, a feature primarily used for debugging. Adversaries can exploit this by using GDB with this capability to inject code into processes running as root, thereby escalating privileges. The detection rule identifies such abuse by monitoring sequences where GDB is executed with CAP_SYS_PTRACE, followed by a process running as root, indicating potential privilege escalation.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific host and process entity ID where the GDB execution with CAP_SYS_PTRACE was detected.
+- Examine the process tree on the affected host to determine the parent process of GDB and any child processes it may have spawned, focusing on any processes running as root.
+- Check the user account associated with the GDB execution to verify if it is a legitimate user and assess if there are any indications of compromise or misuse.
+- Investigate the timeline of events around the alert to identify any preceding or subsequent suspicious activities, such as unauthorized access attempts or changes in user privileges.
+- Analyze system logs and audit records for any signs of unauthorized access or privilege escalation attempts, particularly focusing on the time window specified by the maxspan of 1 minute in the query.
+- Correlate the findings with other security alerts or incidents on the same host to determine if this event is part of a larger attack campaign.
+
+### False positive analysis
+
+- Development environments where GDB is frequently used for legitimate debugging purposes may trigger false positives. To mitigate this, consider excluding specific user accounts or processes that are known to use GDB regularly for debugging.
+- Automated testing systems that utilize GDB for testing applications with elevated privileges might be flagged. Implement exceptions for these systems by identifying and excluding their specific process names or user IDs.
+- Security tools or monitoring solutions that use GDB with CAP_SYS_PTRACE for legitimate monitoring or analysis tasks can cause false alerts. Review and whitelist these tools by their process names or associated user accounts.
+- System administrators or developers who have legitimate reasons to use GDB with elevated capabilities should be identified, and their activities should be excluded from the rule to prevent unnecessary alerts.
+- Scheduled maintenance scripts that involve GDB for system diagnostics or performance tuning may be misinterpreted as malicious. Exclude these scripts by their execution schedule or specific identifiers.
+
+### Response and remediation
+
+- Immediately isolate the affected host from the network to prevent further unauthorized access or lateral movement.
+- Terminate any suspicious processes identified as running with elevated privileges, especially those involving GDB with CAP_SYS_PTRACE.
+- Revoke CAP_SYS_PTRACE capability from non-essential users and processes to limit potential abuse.
+- Conduct a thorough review of user accounts and permissions on the affected system to ensure no unauthorized privilege escalations have occurred.
+- Restore the affected system from a known good backup if any unauthorized changes or code injections are detected.
+- Monitor the affected and related systems for any signs of persistence mechanisms or further malicious activity.
+- Report the incident to the appropriate internal security team or authority for further investigation and potential escalation if necessary."""
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1055"
+name = "Process Injection"
+reference = "https://attack.mitre.org/techniques/T1055/"
+[[rule.threat.technique.subtechnique]]
+id = "T1055.008"
+name = "Ptrace System Calls"
+reference = "https://attack.mitre.org/techniques/T1055/008/"
+
+
+[[rule.threat.technique]]
+id = "T1068"
+name = "Exploitation for Privilege Escalation"
+reference = "https://attack.mitre.org/techniques/T1068/"
+
+
+[rule.threat.tactic]
+id = "TA0004"
+name = "Privilege Escalation"
+reference = "https://attack.mitre.org/tactics/TA0004/"
+

nldcsc_elastic_rules/rules/linux/privilege_escalation_gdb_sys_ptrace_netcon.toml

@@ -0,0 +1,158 @@
+[metadata]
+creation_date = "2024/01/09"
+integration = ["endpoint"]
+maturity = "production"
+updated_date = "2025/02/04"
+
+[rule]
+author = ["Elastic"]
+description = """
+Identifies instances where GDB (granted the CAP_SYS_PTRACE capability) is executed, after which an outbound network
+connection is initiated by UID/GID 0 (root). In Linux, the CAP_SYS_PTRACE capability grants a process the ability to use
+the ptrace system call, which is typically used for debugging and allows the process to trace and control other
+processes. Attackers may leverage this capability to hook and inject into a process that is running with root
+permissions in order to execute shell code and gain a reverse shell with root privileges.
+"""
+from = "now-9m"
+index = ["logs-endpoint.events.network*", "logs-endpoint.events.process*"]
+language = "eql"
+license = "Elastic License v2"
+name = "Root Network Connection via GDB CAP_SYS_PTRACE"
+risk_score = 47
+rule_id = "28bc620d-b2f7-4132-b372-f77953881d05"
+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: Privilege Escalation",
+    "Tactic: Execution",
+    "Tactic: Command and Control",
+    "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
+]
+type = "eql"
+
+query = '''
+sequence by host.id, process.entry_leader.entity_id with maxspan=30s
+  [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and process.name == "gdb" and
+   (process.thread.capabilities.effective : "CAP_SYS_PTRACE" or process.thread.capabilities.permitted : "CAP_SYS_PTRACE") and
+   user.id != "0"]
+  [network where host.os.type == "linux" and event.action == "connection_attempted" and event.type == "start" and
+   process.name != null and user.id == "0"]
+'''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
+
+### Investigating Root Network Connection via GDB CAP_SYS_PTRACE
+
+GDB, a debugger, can be granted the CAP_SYS_PTRACE capability, allowing it to trace and control processes, a feature often exploited by attackers. By injecting code into root processes, adversaries can execute malicious payloads, such as reverse shells. The detection rule identifies suspicious sequences where GDB is used with this capability, followed by a root-initiated network connection, signaling potential privilege escalation or command and control activities.
+
+### Possible investigation steps
+
+- Review the process execution details to confirm the presence of GDB with CAP_SYS_PTRACE capability by examining the process name, capabilities, and user ID fields in the alert.
+- Investigate the network connection attempt by analyzing the process name and user ID fields to determine if the connection was initiated by a root process.
+- Check the timeline of events to ensure the sequence of GDB execution followed by a network connection attempt occurred within the specified maxspan of 30 seconds.
+- Identify the destination IP address and port of the network connection to assess if it is known for malicious activity or associated with command and control servers.
+- Examine the host system for any signs of compromise or unauthorized changes, focusing on processes and files that may have been affected by the potential privilege escalation.
+- Correlate the alert with other security events or logs from the same host to identify any additional suspicious activities or patterns that may indicate a broader attack.
+
+### False positive analysis
+
+- Development environments may trigger this rule when developers use GDB with CAP_SYS_PTRACE for legitimate debugging purposes. To mitigate, create exceptions for specific user IDs or processes known to be involved in development activities.
+- Automated testing frameworks that utilize GDB for testing applications with root privileges can cause false positives. Identify and exclude these processes or testing environments from the rule.
+- System maintenance scripts that require debugging of root processes might inadvertently match the rule criteria. Review and whitelist these scripts or the specific time frames they run to prevent unnecessary alerts.
+- Security tools that perform legitimate process tracing as part of their monitoring activities could be mistaken for malicious behavior. Ensure these tools are recognized and excluded from the detection rule.
+- Custom administrative scripts that use GDB for process management under root privileges should be documented and excluded to avoid false alarms.
+
+### Response and remediation
+
+- Immediately isolate the affected host from the network to prevent further malicious activity and potential lateral movement.
+- Terminate any suspicious processes associated with GDB that have been granted the CAP_SYS_PTRACE capability, especially those initiated by non-root users.
+- Conduct a thorough review of the affected system's logs to identify any unauthorized changes or additional malicious activities that may have occurred.
+- Reset credentials and review permissions for any accounts that may have been compromised, particularly those with elevated privileges.
+- Apply security patches and updates to the affected system to address any vulnerabilities that may have been exploited.
+- Implement network monitoring to detect and block any further unauthorized outbound connections from root processes.
+- Escalate the incident to the security operations team for further investigation and to assess the potential impact on other systems within the network."""
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1055"
+name = "Process Injection"
+reference = "https://attack.mitre.org/techniques/T1055/"
+[[rule.threat.technique.subtechnique]]
+id = "T1055.008"
+name = "Ptrace System Calls"
+reference = "https://attack.mitre.org/techniques/T1055/008/"
+
+
+[[rule.threat.technique]]
+id = "T1068"
+name = "Exploitation for Privilege Escalation"
+reference = "https://attack.mitre.org/techniques/T1068/"
+
+
+[rule.threat.tactic]
+id = "TA0004"
+name = "Privilege Escalation"
+reference = "https://attack.mitre.org/tactics/TA0004/"
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1059"
+name = "Command and Scripting Interpreter"
+reference = "https://attack.mitre.org/techniques/T1059/"
+[[rule.threat.technique.subtechnique]]
+id = "T1059.004"
+name = "Unix Shell"
+reference = "https://attack.mitre.org/techniques/T1059/004/"
+
+
+
+[rule.threat.tactic]
+id = "TA0002"
+name = "Execution"
+reference = "https://attack.mitre.org/tactics/TA0002/"
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1071"
+name = "Application Layer Protocol"
+reference = "https://attack.mitre.org/techniques/T1071/"
+
+
+[rule.threat.tactic]
+id = "TA0011"
+name = "Command and Control"
+reference = "https://attack.mitre.org/tactics/TA0011/"
+