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…
Description
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.
Detection logic
Its licence does not clear it for publishing here
Sunturai publishes a detection's own text where the licence it arrived under has been reviewed and permits it, and Elastic License 2.0 has not. The query as its source wrote it, its canonical form and the hash that pins this revision are in the workspace record.
Detection requirements
- Platform
- ContainersESXiLinuxWindows
The rule states no platform. This is derived from the ATT&CK technique it maps to.
- Log source category
- event_index
MITRE ATT&CK mappings
0 exclusive techniques.This is coverage no other published rule has; it is not this rule's total technique count.
References
| Reference | Cited by |
|---|---|
| attack.mitre.org/techniques/T1611/ | 6from 2 sources |
| book.hacktricks.xyz/linux-hardening/privilege-escalation/docker-security/docker-breakout-privilege-escalation | 8 |
From the source
- At source
- Open at source
- Upstream identifier
- f2a8c4d1-6b3e-4a9f-8c2d-1e5f7a9b0c4d
- Tagged by the source as
- Data Source: Auditd ManagerDomain: ContainersDomain: EndpointNoise: UnknownOS: LinuxPerformance: NormalPlatform: LinuxResources: Investigation GuideRule Type: Custom Query (KQL)Tactic: Privilege EscalationUse Case: Threat Detection
Licence
- Published under
- Elastic License 2.0Read the licence
- Attribution
- Required
Authorship
- Written by
- Published
- Sep 20, 2026
- Version
- 3