Root Network Connection via GDB CAP_SYS_PTRACE

  1[metadata]
  2creation_date = "2024/01/09"
  3integration = ["endpoint"]
  4maturity = "production"
  5updated_date = "2025/02/04"
  6
  7[rule]
  8author = ["Elastic"]
  9description = """
 10Identifies instances where GDB (granted the CAP_SYS_PTRACE capability) is executed, after which an outbound network
 11connection is initiated by UID/GID 0 (root). In Linux, the CAP_SYS_PTRACE capability grants a process the ability to use
 12the ptrace system call, which is typically used for debugging and allows the process to trace and control other
 13processes. Attackers may leverage this capability to hook and inject into a process that is running with root
 14permissions in order to execute shell code and gain a reverse shell with root privileges.
 15"""
 16from = "now-9m"
 17index = ["logs-endpoint.events.network*", "logs-endpoint.events.process*"]
 18language = "eql"
 19license = "Elastic License v2"
 20name = "Root Network Connection via GDB CAP_SYS_PTRACE"
 21risk_score = 47
 22rule_id = "28bc620d-b2f7-4132-b372-f77953881d05"
 23setup = """## Setup
 24
 25
 26This rule requires data coming in from Elastic Defend.
 27
 28### Elastic Defend Integration Setup
 29Elastic 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.
 30
 31#### Prerequisite Requirements:
 32- Fleet is required for Elastic Defend.
 33- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).
 34
 35#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:
 36- Go to the Kibana home page and click "Add integrations".
 37- In the query bar, search for "Elastic Defend" and select the integration to see more details about it.
 38- Click "Add Elastic Defend".
 39- Configure the integration name and optionally add a description.
 40- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads".
 41- 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).
 42- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions"
 43- 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.
 44For more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).
 45- Click "Save and Continue".
 46- 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.
 47For more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).
 48"""
 49severity = "medium"
 50tags = [
 51    "Domain: Endpoint",
 52    "OS: Linux",
 53    "Use Case: Threat Detection",
 54    "Tactic: Privilege Escalation",
 55    "Tactic: Execution",
 56    "Tactic: Command and Control",
 57    "Data Source: Elastic Defend",
 58    "Resources: Investigation Guide",
 59]
 60type = "eql"
 61
 62query = '''
 63sequence by host.id, process.entry_leader.entity_id with maxspan=30s
 64  [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and process.name == "gdb" and
 65   (process.thread.capabilities.effective : "CAP_SYS_PTRACE" or process.thread.capabilities.permitted : "CAP_SYS_PTRACE") and
 66   user.id != "0"]
 67  [network where host.os.type == "linux" and event.action == "connection_attempted" and event.type == "start" and
 68   process.name != null and user.id == "0"]
 69'''
 70note = """## Triage and analysis
 71
 72> **Disclaimer**:
 73> 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.
 74
 75### Investigating Root Network Connection via GDB CAP_SYS_PTRACE
 76
 77GDB, 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.
 78
 79### Possible investigation steps
 80
 81- 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.
 82- 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.
 83- 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.
 84- 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.
 85- 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.
 86- 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.
 87
 88### False positive analysis
 89
 90- 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.
 91- 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.
 92- 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.
 93- 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.
 94- Custom administrative scripts that use GDB for process management under root privileges should be documented and excluded to avoid false alarms.
 95
 96### Response and remediation
 97
 98- Immediately isolate the affected host from the network to prevent further malicious activity and potential lateral movement.
 99- Terminate any suspicious processes associated with GDB that have been granted the CAP_SYS_PTRACE capability, especially those initiated by non-root users.
100- Conduct a thorough review of the affected system's logs to identify any unauthorized changes or additional malicious activities that may have occurred.
101- Reset credentials and review permissions for any accounts that may have been compromised, particularly those with elevated privileges.
102- Apply security patches and updates to the affected system to address any vulnerabilities that may have been exploited.
103- Implement network monitoring to detect and block any further unauthorized outbound connections from root processes.
104- Escalate the incident to the security operations team for further investigation and to assess the potential impact on other systems within the network."""
105
106
107[[rule.threat]]
108framework = "MITRE ATT&CK"
109[[rule.threat.technique]]
110id = "T1055"
111name = "Process Injection"
112reference = "https://attack.mitre.org/techniques/T1055/"
113[[rule.threat.technique.subtechnique]]
114id = "T1055.008"
115name = "Ptrace System Calls"
116reference = "https://attack.mitre.org/techniques/T1055/008/"
117
118
119[[rule.threat.technique]]
120id = "T1068"
121name = "Exploitation for Privilege Escalation"
122reference = "https://attack.mitre.org/techniques/T1068/"
123
124
125[rule.threat.tactic]
126id = "TA0004"
127name = "Privilege Escalation"
128reference = "https://attack.mitre.org/tactics/TA0004/"
129[[rule.threat]]
130framework = "MITRE ATT&CK"
131[[rule.threat.technique]]
132id = "T1059"
133name = "Command and Scripting Interpreter"
134reference = "https://attack.mitre.org/techniques/T1059/"
135[[rule.threat.technique.subtechnique]]
136id = "T1059.004"
137name = "Unix Shell"
138reference = "https://attack.mitre.org/techniques/T1059/004/"
139
140
141
142[rule.threat.tactic]
143id = "TA0002"
144name = "Execution"
145reference = "https://attack.mitre.org/tactics/TA0002/"
146[[rule.threat]]
147framework = "MITRE ATT&CK"
148[[rule.threat.technique]]
149id = "T1071"
150name = "Application Layer Protocol"
151reference = "https://attack.mitre.org/techniques/T1071/"
152
153
154[rule.threat.tactic]
155id = "TA0011"
156name = "Command and Control"
157reference = "https://attack.mitre.org/tactics/TA0011/"