« Potential Privacy Control Bypass via TCCDB Modification Potential Privilege Escalation through Writable Docker Socket »
Elastic Docs ›Elastic Security [8.19] ›Detections and alerts ›Prebuilt rule reference

Potential Privilege Escalation in Container via Runc Init

edit
IMPORTANT: This documentation is no longer updated. Refer to Elastic's version policy and the latest documentation.

Potential Privilege Escalation in Container via Runc Init

edit

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-*

Severity: high

Risk score: 73

Runs every: 5m

Searches indices from: now-9m (Date Math format, see also Additional look-back time)

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

Investigation guide

edit

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.

Setup

edit

Setup

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

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.

Steps to deploy Auditd Manager

  • 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.

Rule query

edit
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&CKTM

« Potential Privacy Control Bypass via TCCDB Modification Potential Privilege Escalation through Writable Docker Socket »