Potential Privilege Escalation via SUID/SGID Proxy Execution
Detects potential privilege escalation via SUID/SGID proxy execution on Linux systems. Attackers may exploit binaries with the SUID/SGID bit set to execute commands with elevated privileges. This rule identifies instances where a process is executed with root privileges (user ID 0 or group ID 0) while the real user or group ID is non-root, indicating potential misuse of SUID/SGID binaries.
Elastic rule (View on GitHub)
1[metadata]
2creation_date = "2025/10/30"
3integration = ["endpoint"]
4maturity = "production"
5updated_date = "2025/11/11"
6
7[rule]
8author = ["Elastic"]
9description = """
10Detects potential privilege escalation via SUID/SGID proxy execution on Linux systems. Attackers may exploit binaries with the
11SUID/SGID bit set to execute commands with elevated privileges. This rule identifies instances where a process is executed with
12root privileges (user ID 0 or group ID 0) while the real user or group ID is non-root, indicating potential misuse of SUID/SGID
13binaries.
14"""
15from = "now-9m"
16index = ["logs-endpoint.events.process*"]
17language = "eql"
18license = "Elastic License v2"
19name = "Potential Privilege Escalation via SUID/SGID Proxy Execution"
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 Potential Privilege Escalation via SUID/SGID Proxy Execution
26
27This rule surfaces executions of well-known SUID/SGID helpers on Linux that run with root privileges while the launching user remains non‑root, signaling an attempt to proxy elevated rights. It matters because a non‑privileged process invoking pkexec can spawn /bin/sh as root via environment manipulation, turning a low-privilege foothold into full system control.
28
29### Possible investigation steps
30
31- Determine if the invocation is interactive and expected (e.g., admin using su/sudo) by correlating with a TTY/SSH session, recent successful authentication logs, and sudo/polkit policy outcomes in journald.
32- For pkexec events, inspect the environment for exploit indicators (e.g., unset argv or suspicious GCONV_PATH, PATH, LD_PRELOAD, LC_* values) and look for attacker-created files in /tmp or the user's home that match gconv or loader artifacts.
33- Review the child/descendant process tree of the SUID/SGID helper to see if it spawned a root shell or arbitrary interpreter, and pivot to concurrent network connections or file writes by those children.
34- Validate whether the executable’s SUID/SGID file on disk has been tampered with by checking its hash, permissions, ownership, and recent mtime against package manager metadata and known-good baselines.
35- If the binary is mount/umount/fusermount or newuidmap/newgidmap, correlate with container or FUSE activity to confirm a legitimate workflow and inspect mounts or namespace changes for risky options (e.g., suid, exec) or unusual target directories.
36
37### False positive analysis
38
39- An authorized pkexec or polkit-agent-helper invocation by a user to perform a permitted administrative task may run as root while the real user is non‑root, often with a single‑argument parent, and should align with an interactive prompt and expected policy.
40- Normal unprivileged workflows using fusermount3 or newuidmap/newgidmap legitimately leverage SUID/SGID helpers, typically launched by a simple shell with one argument, and should correlate with expected mount or user‑namespace activity.
41
42### Response and remediation
43
44- Immediately isolate the host, kill the offending SUID/SGID child processes (e.g., pkexec spawning /bin/sh), and temporarily remove the setuid/setgid bit from the abused binary (chmod u-s /usr/bin/pkexec or chmod g-s /usr/bin/newgrp) to halt further elevation.
45- Reinstall and verify integrity of abused packages and SUID helpers (e.g., polkit to replace /usr/bin/pkexec, dbus-daemon-launch-helper, fusermount3) and delete attacker artifacts such as gconv modules or LD_PRELOAD payloads from /tmp, /var/tmp, and user homes.
46- Undo attacker changes by restoring /etc/sudoers, /etc/passwd and /etc/shadow, and polkit rules under /usr/share/polkit-1 or /etc/polkit-1, unmount suspicious FUSE or bind mounts created by fusermount3/mount, and rotate credentials and keys.
47- Escalate to incident command if you observe a SUID helper launching an interactive root shell (/bin/sh -p or bash -p), root-owned droppers in /tmp or /usr/local/bin, or similar events on more than one host or account.
48- Permanently reduce the SUID/SGID attack surface by auditing and removing setuid bits from rarely used binaries (e.g., chfn, chsh, newgrp, ssh-keysign), restricting pkexec via polkit rules to specific callers, and mounting /tmp, /var/tmp, and home directories with nosuid,nodev,noexec.
49- Strengthen monitoring and policy by enabling AppArmor/SELinux confinement for pkexec and mount helpers, adding auditd rules for exec of setuid binaries and writes to /tmp by root, and enforcing least-privilege sudoers by removing broad NOPASSWD entries and requiring MFA for privileged tasks.
50"""
51references = [
52 "https://dfir.ch/posts/today_i_learned_binfmt_misc/",
53 "https://gtfobins.github.io/#+suid",
54 "https://www.elastic.co/security-labs/primer-on-persistence-mechanisms",
55]
56risk_score = 21
57rule_id = "341c6e18-9ef1-437e-bf18-b513f3ae2130"
58setup = """## Setup
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 = "low"
84tags = [
85 "Domain: Endpoint",
86 "OS: Linux",
87 "Use Case: Threat Detection",
88 "Tactic: Privilege Escalation",
89 "Tactic: Persistence",
90 "Tactic: Defense Evasion",
91 "Data Source: Elastic Defend",
92 "Resources: Investigation Guide",
93]
94timestamp_override = "event.ingested"
95type = "eql"
96query = '''
97process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and (
98 (process.user.id == "0" and process.real_user.id != "0") or
99 (process.group.id == "0" and process.real_group.id != "0")
100) and process.args in (
101 "/bin/su", "/usr/bin/su",
102 "/usr/bin/sudo",
103 "/bin/mount", "/usr/bin/mount",
104 "/bin/umount", "/usr/bin/umount",
105 "/usr/bin/fusermount3",
106 "/bin/passwd", "/usr/bin/passwd",
107 "/bin/chfn", "/usr/bin/chfn",
108 "/bin/chsh", "/usr/bin/chsh",
109 "/bin/gpasswd", "/usr/bin/gpasswd",
110 "/bin/newgrp", "/usr/bin/newgrp",
111 "/sbin/unix_chkpwd", "/usr/sbin/unix_chkpwd",
112 "/usr/bin/newuidmap", "/usr/bin/newgidmap",
113 "/usr/lib/dbus-1.0/dbus-daemon-launch-helper", "/usr/libexec/dbus-daemon-launch-helper",
114 "/usr/lib/openssh/ssh-keysign", "/usr/libexec/openssh/ssh-keysign",
115 "/usr/bin/pkexec", "/usr/libexec/pkexec", "/usr/lib/polkit-1/pkexec",
116 "/usr/lib/polkit-1/polkit-agent-helper-1", "/usr/libexec/polkit-agent-helper-1",
117 "/usr/lib/snapd/snap-confine"
118) and process.parent.args_count == 1
119'''
120
121[[rule.threat]]
122framework = "MITRE ATT&CK"
123
124[[rule.threat.technique]]
125id = "T1068"
126name = "Exploitation for Privilege Escalation"
127reference = "https://attack.mitre.org/techniques/T1068/"
128
129[[rule.threat.technique]]
130id = "T1548"
131name = "Abuse Elevation Control Mechanism"
132reference = "https://attack.mitre.org/techniques/T1548/"
133
134[[rule.threat.technique.subtechnique]]
135id = "T1548.001"
136name = "Setuid and Setgid"
137reference = "https://attack.mitre.org/techniques/T1548/001/"
138
139[rule.threat.tactic]
140id = "TA0004"
141name = "Privilege Escalation"
142reference = "https://attack.mitre.org/tactics/TA0004/"
143
144[[rule.threat]]
145framework = "MITRE ATT&CK"
146
147[rule.threat.tactic]
148id = "TA0003"
149name = "Persistence"
150reference = "https://attack.mitre.org/tactics/TA0003/"
151
152[[rule.threat]]
153framework = "MITRE ATT&CK"
154
155[rule.threat.tactic]
156name = "Defense Evasion"
157id = "TA0005"
158reference = "https://attack.mitre.org/tactics/TA0005/"
159
160[[rule.threat.technique]]
161id = "T1218"
162name = "System Binary Proxy Execution"
163reference = "https://attack.mitre.org/techniques/T1218/"
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 SUID/SGID Proxy Execution
This rule surfaces executions of well-known SUID/SGID helpers on Linux that run with root privileges while the launching user remains non‑root, signaling an attempt to proxy elevated rights. It matters because a non‑privileged process invoking pkexec can spawn /bin/sh as root via environment manipulation, turning a low-privilege foothold into full system control.
Possible investigation steps
- Determine if the invocation is interactive and expected (e.g., admin using su/sudo) by correlating with a TTY/SSH session, recent successful authentication logs, and sudo/polkit policy outcomes in journald.
- For pkexec events, inspect the environment for exploit indicators (e.g., unset argv or suspicious GCONV_PATH, PATH, LD_PRELOAD, LC_* values) and look for attacker-created files in /tmp or the user's home that match gconv or loader artifacts.
- Review the child/descendant process tree of the SUID/SGID helper to see if it spawned a root shell or arbitrary interpreter, and pivot to concurrent network connections or file writes by those children.
- Validate whether the executable’s SUID/SGID file on disk has been tampered with by checking its hash, permissions, ownership, and recent mtime against package manager metadata and known-good baselines.
- If the binary is mount/umount/fusermount or newuidmap/newgidmap, correlate with container or FUSE activity to confirm a legitimate workflow and inspect mounts or namespace changes for risky options (e.g., suid, exec) or unusual target directories.
False positive analysis
- An authorized pkexec or polkit-agent-helper invocation by a user to perform a permitted administrative task may run as root while the real user is non‑root, often with a single‑argument parent, and should align with an interactive prompt and expected policy.
- Normal unprivileged workflows using fusermount3 or newuidmap/newgidmap legitimately leverage SUID/SGID helpers, typically launched by a simple shell with one argument, and should correlate with expected mount or user‑namespace activity.
Response and remediation
- Immediately isolate the host, kill the offending SUID/SGID child processes (e.g., pkexec spawning /bin/sh), and temporarily remove the setuid/setgid bit from the abused binary (chmod u-s /usr/bin/pkexec or chmod g-s /usr/bin/newgrp) to halt further elevation.
- Reinstall and verify integrity of abused packages and SUID helpers (e.g., polkit to replace /usr/bin/pkexec, dbus-daemon-launch-helper, fusermount3) and delete attacker artifacts such as gconv modules or LD_PRELOAD payloads from /tmp, /var/tmp, and user homes.
- Undo attacker changes by restoring /etc/sudoers, /etc/passwd and /etc/shadow, and polkit rules under /usr/share/polkit-1 or /etc/polkit-1, unmount suspicious FUSE or bind mounts created by fusermount3/mount, and rotate credentials and keys.
- Escalate to incident command if you observe a SUID helper launching an interactive root shell (/bin/sh -p or bash -p), root-owned droppers in /tmp or /usr/local/bin, or similar events on more than one host or account.
- Permanently reduce the SUID/SGID attack surface by auditing and removing setuid bits from rarely used binaries (e.g., chfn, chsh, newgrp, ssh-keysign), restricting pkexec via polkit rules to specific callers, and mounting /tmp, /var/tmp, and home directories with nosuid,nodev,noexec.
- Strengthen monitoring and policy by enabling AppArmor/SELinux confinement for pkexec and mount helpers, adding auditd rules for exec of setuid binaries and writes to /tmp by root, and enforcing least-privilege sudoers by removing broad NOPASSWD entries and requiring MFA for privileged tasks.
References
Related rules
- Kernel Load or Unload via Kexec Detected
- Git Hook Command Execution
- Suspicious APT Package Manager Execution
- Unusual LD_PRELOAD/LD_LIBRARY_PATH Command Line Arguments
- Cron Job Created or Modified