Loading

Unusual Process Connection to Docker or Containerd Socket

Detects a process connecting to a container runtime Unix socket (containerd or Docker) that is not a known legitimate runtime component. Direct access to the container runtime socket allows an attacker to create, exec into, or manipulate containers without going through the Kubernetes API server, bypassing RBAC, admission webhooks, pod security standards, and Kubernetes audit logging entirely.

Rule type: query
Rule indices:

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

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

Tags:

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

Version: 1
Rule authors:

  • Elastic

Rule license: Elastic License v2

This rule requires Auditd Manager (or Auditbeat) process and network events where Unix socket paths populate destination.address (or equivalent ECS mapping from your pipeline).

Enable auditing of socket-related activity so event.category:network and event.action:connected-to (or your pipeline’s equivalent) are emitted for connect to Unix sockets. Example audit rules to extend as needed:

# 64-bit connect (required for socket connection telemetry)
-a always,exit -F arch=b64 -S connect -k netconn

# 32-bit (if applicable)
-a always,exit -F arch=b32 -S connect -k netconn

After deployment, confirm in Discover that events for connections to /var/run/docker.sock, /run/docker.sock, or containerd socket paths include process.executable and destination.address fields used by this rule.

For more details on the integration refer to the Auditd Manager documentation.

Review the initiating process executable, user, and parent chain. Confirm whether the socket path is the host default or a bind-mounted path inside a container. Pivot on the same host for subsequent container creation, image pulls, or credential access.

  • Map process.executable, process.args, process.title and user.id to an identity and session (SSH, cron, web shell).
  • Check file permissions on the socket path and whether the workload should have access at all.
  • Correlate with process and authentication telemetry before and after the connection.
  • Vendor agents that wrap docker or containerd CLIs from non-standard install locations may match; add explicit exclusions for known binaries.
  • If malicious, isolate the host, revoke credentials, inspect for rogue containers and persistence, and restrict socket permissions to trusted groups only.
host.os.type:"linux" and
event.category:"network" and
event.action:"connected-to" and network.direction:"egress" and
destination.address:("/run/containerd/containerd.sock" or "/var/run/containerd/containerd.sock" or "/var/run/docker.sock" or "/run/docker.sock") and
process.executable:(* and not
  ("/usr/bin/kubelet" or
  "/usr/local/bin/kubelet" or
  "/usr/bin/containerd" or
  "/usr/sbin/containerd" or
  "/usr/bin/containerd-shim" or
  "/usr/bin/containerd-shim-runc-v2" or
  "/usr/local/bin/containerd-shim-runc-v2" or
  "/usr/bin/dockerd" or
  "/usr/sbin/dockerd" or
   /var/lib/*/usr/bin/dockerd or
  "/usr/bin/docker-proxy")
)

Framework: MITRE ATT&CK

Framework: MITRE ATT&CK

Framework: MITRE ATT&CK