Potential Privilege Escalation via unshare and UID Change
Identifies potentially suspicious use of unshare to create a user namespace context followed by a UID change event indicating a transition to root. Adversaries may use unshare-based primitives as part of local privilege escalation chains. This rule is intentionally generic and can surface multiple local privesc patterns beyond a single CVE.
Elastic rule (View on GitHub)
1[metadata]
2creation_date = "2023/07/28"
3integration = ["endpoint"]
4maturity = "production"
5updated_date = "2026/05/08"
6
7[rule]
8author = ["Elastic"]
9description = """
10Identifies potentially suspicious use of unshare to create a user namespace context followed by a UID change event
11indicating a transition to root. Adversaries may use unshare-based primitives as part of local privilege escalation
12chains. This rule is intentionally generic and can surface multiple local privesc patterns beyond a single CVE.
13"""
14from = "now-9m"
15index = ["logs-endpoint.events.process*"]
16language = "eql"
17license = "Elastic License v2"
18name = "Potential Privilege Escalation via unshare and UID Change"
19references = [
20 "https://www.wiz.io/blog/ubuntu-overlayfs-vulnerability",
21 "https://twitter.com/liadeliyahu/status/1684841527959273472",
22]
23risk_score = 73
24rule_id = "b51dbc92-84e2-4af1-ba47-65183fcd0c57"
25setup = """## Setup
26
27This rule requires data coming in from Elastic Defend.
28
29### Elastic Defend Integration Setup
30Elastic 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.
31
32#### Prerequisite Requirements:
33- Fleet is required for Elastic Defend.
34- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).
35
36#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:
37- Go to the Kibana home page and click "Add integrations".
38- In the query bar, search for "Elastic Defend" and select the integration to see more details about it.
39- Click "Add Elastic Defend".
40- Configure the integration name and optionally add a description.
41- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads".
42- 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).
43- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions"
44- 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.
45For more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).
46- Click "Save and Continue".
47- 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.
48For more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).
49"""
50severity = "high"
51tags = [
52 "Domain: Endpoint",
53 "OS: Linux",
54 "Use Case: Threat Detection",
55 "Tactic: Privilege Escalation",
56 "Use Case: Vulnerability",
57 "Data Source: Elastic Defend",
58 "Resources: Investigation Guide",
59]
60type = "eql"
61
62query = '''
63sequence by process.parent.entity_id, host.id with maxspan=60s
64 [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and
65 process.name == "unshare" and process.args : ("-r", "-rm", "m", "-U", "--user") and user.id != "0"]
66 [process where host.os.type == "linux" and event.action == "uid_change" and event.type == "change" and
67 user.id == "0"]
68'''
69note = """## Triage and analysis
70
71> **Disclaimer**:
72> 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.
73
74### Investigating Potential Privilege Escalation via unshare and UID Change
75
76The unshare utility can create new namespaces, including user namespaces. In some exploit chains, an attacker uses
77unshare (often with user namespace flags) as a precursor step and then achieves a transition to root. This rule detects
78a short sequence where a non-root user executes unshare with user-namespace related arguments and a subsequent uid_change
79event indicates the user became root, which can represent a successful local privilege escalation attempt.
80
81### Possible investigation steps
82
83- Review unshare arguments in the first event to confirm user namespace related flags were used (for example -U/--user or -r).
84- Check the process tree and parent context (process.parent.entity_id) to understand what launched unshare and whether it originated from an interactive session or user-writable path.
85- Confirm whether the uid_change corresponds to the same activity and identify the first root process spawned after the uid_change event.
86- Review other host signals around the same time for exploit activity such as compilation in /tmp, suspicious downloads, or execution of unusual binaries.
87
88### False positive analysis
89
90- Legitimate sandboxing or container tooling may use unshare and then legitimately trigger uid_change events; validate the parent process and user context.
91- Security testing, exploit validation, or developer environments may intentionally exercise namespace-related behavior; tune by users, hosts, or maintenance windows.
92
93### Response and remediation
94
95- Immediately isolate the affected host to prevent further privilege abuse or lateral movement.
96- Terminate suspicious processes and collect forensic data (process tree, binaries, and relevant files in temp locations).
97- Patch and harden the host; review policies that allow unprivileged user namespaces if not required in your environment.
98- Escalate for incident response when root access is confirmed and scope for follow-on persistence.
99"""
100
101
102[[rule.threat]]
103framework = "MITRE ATT&CK"
104
105[[rule.threat.technique]]
106id = "T1068"
107name = "Exploitation for Privilege Escalation"
108reference = "https://attack.mitre.org/techniques/T1068/"
109
110[[rule.threat.technique]]
111id = "T1548"
112name = "Abuse Elevation Control Mechanism"
113reference = "https://attack.mitre.org/techniques/T1548/"
114
115[rule.threat.tactic]
116id = "TA0004"
117name = "Privilege Escalation"
118reference = "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 Potential Privilege Escalation via unshare and UID Change
The unshare utility can create new namespaces, including user namespaces. In some exploit chains, an attacker uses unshare (often with user namespace flags) as a precursor step and then achieves a transition to root. This rule detects a short sequence where a non-root user executes unshare with user-namespace related arguments and a subsequent uid_change event indicates the user became root, which can represent a successful local privilege escalation attempt.
Possible investigation steps
- Review unshare arguments in the first event to confirm user namespace related flags were used (for example -U/--user or -r).
- Check the process tree and parent context (process.parent.entity_id) to understand what launched unshare and whether it originated from an interactive session or user-writable path.
- Confirm whether the uid_change corresponds to the same activity and identify the first root process spawned after the uid_change event.
- Review other host signals around the same time for exploit activity such as compilation in /tmp, suspicious downloads, or execution of unusual binaries.
False positive analysis
- Legitimate sandboxing or container tooling may use unshare and then legitimately trigger uid_change events; validate the parent process and user context.
- Security testing, exploit validation, or developer environments may intentionally exercise namespace-related behavior; tune by users, hosts, or maintenance windows.
Response and remediation
- Immediately isolate the affected host to prevent further privilege abuse or lateral movement.
- Terminate suspicious processes and collect forensic data (process tree, binaries, and relevant files in temp locations).
- Patch and harden the host; review policies that allow unprivileged user namespaces if not required in your environment.
- Escalate for incident response when root access is confirmed and scope for follow-on persistence.
References
Related rules
- Potential snap-confine Privilege Escalation via CVE-2026-3888
- Deprecated - Sudo Heap-Based Buffer Overflow Attempt
- Potential CVE-2025-32463 Nsswitch File Creation
- Potential CVE-2025-32463 Sudo Chroot Execution Attempt
- Potential CVE-2025-41244 vmtoolsd LPE Exploitation Attempt