Loading

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.

Rule type: query
Rule indices:

  • auditbeat-*
  • logs-auditd_manager.auditd-*

Rule Severity: high
Risk Score: 73
Runs every:
Searches indices from: now-9m
Maximum alerts per execution: 100
References:

Tags:

  • Domain: Endpoint
  • Domain: Container
  • OS: Linux
  • Use Case: Threat Detection
  • Tactic: Privilege Escalation
  • Resources: Investigation Guide
  • Data Source: Auditd Manager

Version: 1
Rule authors:

  • Elastic

Rule license: Elastic License v2

This rule requires Linux audit events from the Auditd Manager integration.

Auditd Manager simplifies configuring and monitoring the Linux audit subsystem via Fleet. Administrators define audit rules, collect events, and forward them to Elasticsearch.

  • In Kibana, go to Integrations and search for Auditd Manager.
  • Add the integration to an Elastic Agent policy that covers your Linux hosts.
  • Configure audit rules appropriate for your environment so execve and identity-related fields are captured where needed for this detection.

For more details, see the Auditd Manager integration documentation.

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.

  • 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.
  • 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.
  • If abuse is confirmed: isolate the node or workload, rotate credentials exposed to that container, and rebuild from a trusted image after forensic capture.
host.os.type:linux and event.category:process and
event.action:(executed or exec) and
process.title:"runc init" and user.effective.id:0 and user.id:(* and not 0)

Framework: MITRE ATT&CK