Privilege Escalation via CAP_SETUID/SETGID Capabilities

Identifies instances where a process (granted CAP_SETUID and/or CAP_SETGID capabilities) is executed, after which the user's access is elevated to UID/GID 0 (root). In Linux, the CAP_SETUID and CAP_SETGID capabilities allow a process to change its UID and GID, respectively, providing control over user and group identity management. Attackers may leverage a misconfiguration for exploitation in order to escalate their privileges to root.

Elastic rule (View on GitHub)

  1[metadata]
  2creation_date = "2024/01/08"
  3integration = ["endpoint"]
  4maturity = "production"
  5updated_date = "2025/12/23"
  6
  7[rule]
  8author = ["Elastic"]
  9description = """
 10Identifies instances where a process (granted CAP_SETUID and/or CAP_SETGID capabilities) is executed, after which the
 11user's access is elevated to UID/GID 0 (root). In Linux, the CAP_SETUID and CAP_SETGID capabilities allow a process to
 12change its UID and GID, respectively, providing control over user and group identity management. Attackers may leverage
 13a misconfiguration for exploitation in order to escalate their privileges to root.
 14"""
 15from = "now-9m"
 16index = ["logs-endpoint.events.process*"]
 17language = "eql"
 18license = "Elastic License v2"
 19name = "Privilege Escalation via CAP_SETUID/SETGID Capabilities"
 20note = """## Triage and analysis
 21
 22> **Disclaimer**:
 23> 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.
 24
 25### Investigating Privilege Escalation via CAP_SETUID/SETGID Capabilities
 26
 27In Linux, CAP_SETUID and CAP_SETGID capabilities allow processes to change user and group IDs, crucial for identity management. Adversaries exploit misconfigurations to gain root access. The detection rule identifies processes with these capabilities that elevate privileges to root, excluding benign scenarios, to flag potential misuse.
 28
 29### Possible investigation steps
 30
 31- Review the process details such as process.name and process.executable to identify the specific application or script that triggered the alert. This can help determine if the process is expected or potentially malicious.
 32- Examine the process.parent.executable and process.parent.name fields to understand the parent process that initiated the suspicious process. This can provide context on whether the parent process is legitimate or part of a known attack vector.
 33- Check the user.id field to confirm the user context under which the process was executed. If the user is not expected to have elevated privileges, this could indicate a potential compromise.
 34- Investigate the process.command_line to analyze the command executed. Look for any unusual or unexpected command patterns that could suggest malicious intent.
 35- Correlate the alert with other security events or logs from the same host.id to identify any related suspicious activities or patterns that could indicate a broader attack.
 36- Assess the environment for any recent changes or misconfigurations that could have inadvertently granted CAP_SETUID or CAP_SETGID capabilities to unauthorized processes.
 37
 38### False positive analysis
 39
 40- Processes related to system management tools like VMware, SolarWinds, and language tools may trigger false positives. Exclude these by adding their executables to the exception list.
 41- Scheduled tasks or system updates that involve processes like update-notifier or dbus-daemon can cause false alerts. Consider excluding these parent process names from the detection rule.
 42- Automation tools such as Ansible or scripts executed by Python may inadvertently match the rule. Exclude command lines that match known automation patterns.
 43- Legitimate use of sudo or pkexec for administrative tasks can be misinterpreted as privilege escalation. Exclude these executables if they are part of regular administrative operations.
 44- Monitoring tools like osqueryd or saposcol might trigger the rule during normal operations. Add these process names to the exception list to prevent unnecessary alerts.
 45
 46### Response and remediation
 47
 48- Immediately isolate the affected host from the network to prevent further unauthorized access or lateral movement by the adversary.
 49- Terminate any suspicious processes identified with CAP_SETUID or CAP_SETGID capabilities that have escalated privileges to root, ensuring no further exploitation occurs.
 50- Conduct a thorough review of the affected system's user and group configurations to identify and correct any misconfigurations that allowed the privilege escalation.
 51- Revoke unnecessary CAP_SETUID and CAP_SETGID capabilities from processes and users that do not require them, reducing the attack surface for future exploitation.
 52- Restore the affected system from a known good backup if unauthorized changes or persistent threats are detected, ensuring the system is returned to a secure state.
 53- Monitor the system and network for any signs of continued or attempted exploitation, using enhanced logging and alerting to detect similar threats in the future.
 54- Escalate the incident to the security operations team for further investigation and to assess the potential impact on other systems within the network."""
 55risk_score = 47
 56rule_id = "9b80cb26-9966-44b5-abbf-764fbdbc3586"
 57setup = """## Setup
 58
 59
 60This rule requires data coming in from Elastic Defend.
 61
 62### Elastic Defend Integration Setup
 63Elastic 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.
 64
 65#### Prerequisite Requirements:
 66- Fleet is required for Elastic Defend.
 67- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).
 68
 69#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:
 70- Go to the Kibana home page and click "Add integrations".
 71- In the query bar, search for "Elastic Defend" and select the integration to see more details about it.
 72- Click "Add Elastic Defend".
 73- Configure the integration name and optionally add a description.
 74- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads".
 75- 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).
 76- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions"
 77- 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.
 78For more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).
 79- Click "Save and Continue".
 80- 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.
 81For more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).
 82"""
 83severity = "medium"
 84tags = [
 85    "Domain: Endpoint",
 86    "OS: Linux",
 87    "Use Case: Threat Detection",
 88    "Tactic: Privilege Escalation",
 89    "Data Source: Elastic Defend",
 90    "Resources: Investigation Guide",
 91]
 92type = "eql"
 93query = '''
 94sequence by host.id, process.entity_id with maxspan=1s
 95  [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and process.name != null and
 96   (process.thread.capabilities.effective : "CAP_SET?ID" or process.thread.capabilities.permitted : "CAP_SET?ID") and
 97   user.id != "0" and not (
 98     process.parent.executable : ("/tmp/newroot/*", "/opt/carbonblack*") or
 99     process.parent.executable in (
100       "/opt/SolarWinds/Agent/bin/Plugins/JobEngine/SolarWinds.Agent.JobEngine.Plugin", "/usr/bin/vmware-toolbox-cmd",
101       "/usr/bin/dbus-daemon", "/usr/bin/update-notifier", "/usr/share/language-tools/language-options",
102       "/opt/SolarWinds/Agent/*", "/usr/local/sbin/lynis.sh", "/usr/libexec/sssd/sssd_be",
103       "/opt/sophos-spl/plugins/edr/bin/osqueryd.5", "/apps/dynatrace/oneagent/install/agent/lib64/oneagentos",
104       "/opt/carbonblack/*/osqueryi"
105     ) or
106     process.executable : ("/opt/dynatrace/*", "/tmp/newroot/*", "/opt/SolarWinds/Agent/*") or
107     process.executable in (
108       "/bin/fgrep", "/usr/bin/sudo", "/usr/bin/pkexec", "/usr/lib/cockpit/cockpit-session", "/usr/sbin/suexec"
109     ) or
110     process.parent.name in ("update-notifier", "language-options", "osqueryd", "saposcol", "dbus-daemon", "osqueryi", "sdbrun") or
111     process.command_line like ("sudo*BECOME-SUCCESS*", "/bin/sh*sapsysinfo.sh*", "sudo su", "sudo su -", "sudo -E -H bash -l") or
112     process.name in ("sudo", "fgrep", "lsb_release", "apt-update", "dbus-daemon-launch-helper", "man") or
113     process.parent.command_line like "/usr/bin/python*ansible*" or
114     process.working_directory like ("/opt/Elastic/Agent/data/*", "/usr/sap/tmp") or
115     process.args like ("/usr/bin/lsb_release*", "/bin/fgrep*")
116   )]
117  [process where host.os.type == "linux" and event.action == "uid_change" and event.type == "change" and
118   (process.thread.capabilities.effective : "CAP_SET?ID" or process.thread.capabilities.permitted : "CAP_SET?ID")
119   and user.id == "0"]
120'''
121
122[[rule.threat]]
123framework = "MITRE ATT&CK"
124
125[[rule.threat.technique]]
126id = "T1068"
127name = "Exploitation for Privilege Escalation"
128reference = "https://attack.mitre.org/techniques/T1068/"
129
130[[rule.threat.technique]]
131id = "T1548"
132name = "Abuse Elevation Control Mechanism"
133reference = "https://attack.mitre.org/techniques/T1548/"
134
135[[rule.threat.technique.subtechnique]]
136id = "T1548.001"
137name = "Setuid and Setgid"
138reference = "https://attack.mitre.org/techniques/T1548/001/"
139
140[rule.threat.tactic]
141id = "TA0004"
142name = "Privilege Escalation"
143reference = "https://attack.mitre.org/tactics/TA0004/"

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 CAP_SETUID/SETGID Capabilities

In Linux, CAP_SETUID and CAP_SETGID capabilities allow processes to change user and group IDs, crucial for identity management. Adversaries exploit misconfigurations to gain root access. The detection rule identifies processes with these capabilities that elevate privileges to root, excluding benign scenarios, to flag potential misuse.

Possible investigation steps

  • Review the process details such as process.name and process.executable to identify the specific application or script that triggered the alert. This can help determine if the process is expected or potentially malicious.
  • Examine the process.parent.executable and process.parent.name fields to understand the parent process that initiated the suspicious process. This can provide context on whether the parent process is legitimate or part of a known attack vector.
  • Check the user.id field to confirm the user context under which the process was executed. If the user is not expected to have elevated privileges, this could indicate a potential compromise.
  • Investigate the process.command_line to analyze the command executed. Look for any unusual or unexpected command patterns that could suggest malicious intent.
  • Correlate the alert with other security events or logs from the same host.id to identify any related suspicious activities or patterns that could indicate a broader attack.
  • Assess the environment for any recent changes or misconfigurations that could have inadvertently granted CAP_SETUID or CAP_SETGID capabilities to unauthorized processes.

False positive analysis

  • Processes related to system management tools like VMware, SolarWinds, and language tools may trigger false positives. Exclude these by adding their executables to the exception list.
  • Scheduled tasks or system updates that involve processes like update-notifier or dbus-daemon can cause false alerts. Consider excluding these parent process names from the detection rule.
  • Automation tools such as Ansible or scripts executed by Python may inadvertently match the rule. Exclude command lines that match known automation patterns.
  • Legitimate use of sudo or pkexec for administrative tasks can be misinterpreted as privilege escalation. Exclude these executables if they are part of regular administrative operations.
  • Monitoring tools like osqueryd or saposcol might trigger the rule during normal operations. Add these process names to the exception list to prevent unnecessary alerts.

Response and remediation

  • Immediately isolate the affected host from the network to prevent further unauthorized access or lateral movement by the adversary.
  • Terminate any suspicious processes identified with CAP_SETUID or CAP_SETGID capabilities that have escalated privileges to root, ensuring no further exploitation occurs.
  • Conduct a thorough review of the affected system's user and group configurations to identify and correct any misconfigurations that allowed the privilege escalation.
  • Revoke unnecessary CAP_SETUID and CAP_SETGID capabilities from processes and users that do not require them, reducing the attack surface for future exploitation.
  • Restore the affected system from a known good backup if unauthorized changes or persistent threats are detected, ensuring the system is returned to a secure state.
  • Monitor the system and network for any signs of continued or attempted exploitation, using enhanced logging and alerting to detect similar threats 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.

Related rules

to-top