Potential Privilege Escalation via unshare Followed by Root Process
Detects a short sequence where a non-root user performs unshare-related namespace activity (often associated with user namespace privilege escalation primitives) and then a root process is executed shortly after. This can indicate a successful local privilege escalation attempt or suspicious namespace manipulation captured in Auditd Manager telemetry.
Elastic rule (View on GitHub)
1[metadata]
2creation_date = "2026/05/08"
3integration = ["auditd_manager"]
4maturity = "production"
5updated_date = "2026/05/08"
6
7[rule]
8author = ["Elastic"]
9description = """
10Detects a short sequence where a non-root user performs unshare-related namespace activity (often associated with user
11namespace privilege escalation primitives) and then a root process is executed shortly after. This can indicate a
12successful local privilege escalation attempt or suspicious namespace manipulation captured in Auditd Manager telemetry.
13"""
14false_positives = [
15 """
16 Legitimate sandboxing, container tooling, or maintenance scripts may use unshare and spawn privileged helpers under
17 controlled workflows. Baseline approved tools and tune by host role, parent process, or user accounts.
18 """,
19]
20from = "now-9m"
21index = ["auditbeat-*", "logs-auditd_manager.auditd-*"]
22language = "eql"
23license = "Elastic License v2"
24name = "Potential Privilege Escalation via unshare Followed by Root Process"
25note = """## Triage and analysis
26
27### Investigating Potential Privilege Escalation via unshare Followed by Root Process
28
29Validate that the initiating user and parent process should be using unshare. Then confirm whether the subsequent root
30process aligns with an approved administrative workflow or represents an unexpected transition to root.
31
32### Possible investigation steps
33
34- Review auditd.data.* (syscall, class, and a0) and process args to understand the unshare intent.
35- Identify the first root process spawned and its command line, then look for follow-on persistence or credential access.
36- Correlate with recent downloads/compilation in temp directories and other local privesc indicators on the host.
37
38### Response and remediation
39
40- If unauthorized, isolate the host, capture forensic artifacts, and patch/harden user namespace settings as appropriate.
41"""
42references = [
43 "https://docs.elastic.co/integrations/auditd_manager",
44 "https://attack.mitre.org/techniques/T1068/",
45]
46risk_score = 73
47rule_id = "0dd84246-a723-49ba-9f4e-a1e1dfa15990"
48setup = """## Setup
49
50This rule relies on Auditd Manager (or Auditbeat) process telemetry that captures:
51
52- Process execution events (execve/execveat) to populate process.name, process.args, and process.parent.pid
53- Namespace-related activity to populate auditd.data.syscall, auditd.data.class, and auditd.data.a0 for unshare calls
54- Privilege transitions so processes started as root can be correlated after the namespace action
55
56Ensure your auditd ruleset includes coverage for unshare and exec-related syscalls and that arguments are collected. If
57your environment does not populate auditd.data.class/a0 for unshare, keep the process-based fallback branch (process.name
58== unshare with -U/--user/-r args) enabled and consider extending auditing to enrich those auditd.data fields.
59
60### Example auditd rules
61
62The following example syscall rules are commonly used to capture the signals required by this detection. Adjust keys and
63scope to your environment (these examples are intentionally broad).
64
65- Capture unshare (namespace activity):
66 -a always,exit -F arch=b64 -S unshare -k namespace
67 -a always,exit -F arch=b32 -S unshare -k namespace
68
69- Capture process execution (argv collection depends on your auditd/auditbeat pipeline configuration):
70 -a always,exit -F arch=b64 -S execve -S execveat -k exec
71 -a always,exit -F arch=b32 -S execve -S execveat -k exec
72
73- Capture UID transition syscalls often associated with privilege changes:
74 -a always,exit -F arch=b64 -S setuid -S setreuid -S setresuid -S setfsuid -k uid_change
75 -a always,exit -F arch=b32 -S setuid -S setreuid -S setresuid -S setfsuid -k uid_change
76
77See https://docs.elastic.co/integrations/auditd_manager
78"""
79severity = "high"
80tags = [
81 "Data Source: Auditd Manager",
82 "Domain: Endpoint",
83 "OS: Linux",
84 "Use Case: Threat Detection",
85 "Tactic: Privilege Escalation",
86 "Resources: Investigation Guide",
87]
88timestamp_override = "event.ingested"
89type = "eql"
90query = '''
91sequence by host.id, process.parent.pid with maxspan=30s
92 [process where host.os.type == "linux" and
93 (
94 (auditd.data.syscall == "unshare" and auditd.data.class == "namespace" and auditd.data.a0 in ("10000000", "50000000", "70000000", "10020000", "50020000", "70020000")) or
95
96 (process.name == "unshare" and
97 (process.args in ("--user", "--map-root-user", "--map-current-user") or process.args like ("-*U*", "-*r*")))
98 ) and user.id != "0" and user.id != null]
99 [process where host.os.type == "linux" and
100 user.id == "0" and user.id != null and
101 (
102 process.name in ("su", "sudo", "pkexec", "passwd", "chsh", "newgrp", "doas", "run0", "sg", "dash", "sh", "bash", "zsh", "fish",
103 "ksh", "csh", "tcsh", "ash", "mksh", "busybox", "rbash", "rzsh", "rksh", "tmux", "screen", "node") or
104 process.name like ("python*", "perl*", "ruby*", "php*", "lua*")
105 )]
106'''
107
108[[rule.threat]]
109framework = "MITRE ATT&CK"
110
111[[rule.threat.technique]]
112id = "T1068"
113name = "Exploitation for Privilege Escalation"
114reference = "https://attack.mitre.org/techniques/T1068/"
115
116[rule.threat.tactic]
117id = "TA0004"
118name = "Privilege Escalation"
119reference = "https://attack.mitre.org/tactics/TA0004/"
Triage and analysis
Investigating Potential Privilege Escalation via unshare Followed by Root Process
Validate that the initiating user and parent process should be using unshare. Then confirm whether the subsequent root process aligns with an approved administrative workflow or represents an unexpected transition to root.
Possible investigation steps
- Review auditd.data.* (syscall, class, and a0) and process args to understand the unshare intent.
- Identify the first root process spawned and its command line, then look for follow-on persistence or credential access.
- Correlate with recent downloads/compilation in temp directories and other local privesc indicators on the host.
Response and remediation
- If unauthorized, isolate the host, capture forensic artifacts, and patch/harden user namespace settings as appropriate.
References
Related rules
- Potential Privilege Escalation in Container via Runc Init
- Nsenter to PID Namespace via Auditd
- Chroot Execution in Container Context on Linux
- Unusual Process Connection to Docker or Containerd Socket
- Namespace Manipulation Using Unshare