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

to-top