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

to-top