Potential Privilege Escalation in Container via Runc Init

Identifies audit events for runc init child processes where the effective user is root and the login user ID is not root. This pattern can indicate privilege escalation or credential separation abuse inside container runtimes, where a process executes with elevated effective privileges while retaining a non-root audit identity.

Elastic rule (View on GitHub)

 1[metadata]
 2creation_date = "2026/04/22"
 3integration = ["auditd_manager"]
 4maturity = "production"
 5updated_date = "2026/04/22"
 6
 7[rule]
 8author = ["Elastic"]
 9description = """
10Identifies audit events for runc init child processes where the effective user is root and the login user ID is not root. 
11This pattern can indicate privilege escalation or credential separation abuse inside container runtimes, where a process executes 
12with elevated effective privileges while retaining a non-root audit identity.
13"""
14from = "now-9m"
15index = ["auditbeat-*", "logs-auditd_manager.auditd-*"]
16language = "kuery"
17license = "Elastic License v2"
18name = "Potential Privilege Escalation in Container via Runc Init"
19note = """## Triage and analysis
20
21### Investigating Potential Privilege Escalation in Container via Runc Init
22
23runc is the low-level container runtime used by Docker, containerd, and others. The runc init process initializes the
24container environment. A mismatch between effective root (user.effective.id 0) and a non-root user.id in audit
25telemetry can reflect namespace or capability transitions worth validating in your environment.
26
27### Possible investigation steps
28
29- Confirm the host is running containers and identify which workload invoked runc (orchestrator, image, namespace).
30- Review full audit fields for the event: process, process.parent, user.*, and any container or cgroup metadata
31  available in your auditd_manager pipeline.
32- Correlate with other alerts on the same host (namespace changes, mounts, unshare, nsenter, suspicious image pulls).
33- Validate whether the pattern matches expected behavior for your container stack (e.g. specific init or security
34  profiles) before treating as malicious.
35
36### False positive analysis
37
38- Some legitimate container or CRI configurations may produce effective UID 0 with a non-root login UID in audit records.
39  Tune with host, image, or process ancestry exclusions after baseline review.
40
41### Response and remediation
42
43- If abuse is confirmed: isolate the node or workload, rotate credentials exposed to that container, and rebuild from a
44  trusted image after forensic capture.
45"""
46references = [
47    "https://attack.mitre.org/techniques/T1611/",
48    "https://book.hacktricks.xyz/linux-hardening/privilege-escalation/docker-security/docker-breakout-privilege-escalation",
49]
50risk_score = 73
51rule_id = "f2a8c4d1-6b3e-4a9f-8c2d-1e5f7a9b0c4d"
52setup = """## Setup
53
54This rule requires Linux audit events from the **Auditd Manager** integration.
55
56### Auditd Manager integration
57
58Auditd Manager simplifies configuring and monitoring the Linux audit subsystem via Fleet. Administrators define audit
59rules, collect events, and forward them to Elasticsearch.
60
61#### Steps to deploy Auditd Manager
62
63- In Kibana, go to **Integrations** and search for **Auditd Manager**.
64- Add the integration to an Elastic Agent policy that covers your Linux hosts.
65- Configure audit rules appropriate for your environment so execve and identity-related fields are captured where
66  needed for this detection.
67
68For more details, see the [Auditd Manager integration documentation](https://docs.elastic.co/integrations/auditd_manager).
69"""
70severity = "high"
71tags = [
72    "Domain: Endpoint",
73    "Domain: Container",
74    "OS: Linux",
75    "Use Case: Threat Detection",
76    "Tactic: Privilege Escalation",
77    "Resources: Investigation Guide",
78    "Data Source: Auditd Manager",
79]
80timestamp_override = "event.ingested"
81type = "query"
82query = '''
83host.os.type:linux and event.category:process and 
84event.action:(executed or exec) and 
85process.title:"runc init" and user.effective.id:0 and user.id:(* and not 0)
86'''
87
88[[rule.threat]]
89framework = "MITRE ATT&CK"
90
91[[rule.threat.technique]]
92id = "T1611"
93name = "Escape to Host"
94reference = "https://attack.mitre.org/techniques/T1611/"
95
96[rule.threat.tactic]
97id = "TA0004"
98name = "Privilege Escalation"
99reference = "https://attack.mitre.org/tactics/TA0004/"

Triage and analysis

Investigating Potential Privilege Escalation in Container via Runc Init

runc is the low-level container runtime used by Docker, containerd, and others. The runc init process initializes the container environment. A mismatch between effective root (user.effective.id 0) and a non-root user.id in audit telemetry can reflect namespace or capability transitions worth validating in your environment.

Possible investigation steps

  • Confirm the host is running containers and identify which workload invoked runc (orchestrator, image, namespace).
  • Review full audit fields for the event: process, process.parent, user.*, and any container or cgroup metadata available in your auditd_manager pipeline.
  • Correlate with other alerts on the same host (namespace changes, mounts, unshare, nsenter, suspicious image pulls).
  • Validate whether the pattern matches expected behavior for your container stack (e.g. specific init or security profiles) before treating as malicious.

False positive analysis

  • Some legitimate container or CRI configurations may produce effective UID 0 with a non-root login UID in audit records. Tune with host, image, or process ancestry exclusions after baseline review.

Response and remediation

  • If abuse is confirmed: isolate the node or workload, rotate credentials exposed to that container, and rebuild from a trusted image after forensic capture.

References

Related rules

to-top