This rule detects potential Docker socket enumeration activity by monitoring processes that attempt to interact with the Docker socket file (/var/run/docker.sock). Docker socket enumeration is a common technique used by attackers to interact with the Docker daemon and perform various operations, such as creating, starting, stopping, and removing containers. Attackers may abuse Docker socket enumeration to gain unauthorized access to the host system, escalate privileges, or move laterally within the environment.

Read More

Detects GKE pod creation with dangerous Linux capabilities that are commonly abused in container escape techniques. Standalone pods are included; controller-owned ReplicaSet, DaemonSet, and StatefulSet workloads are excluded.

Read More

Detects GKE pod create, update, or patch events that mount sensitive hostPath volumes such as the root filesystem, kubelet paths, or container runtime sockets. This can enable container escape and credential theft. System identities and controller-owned workloads are excluded.

Read More

Detects GKE pod create, update, or patch events that enable host IPC namespace sharing. This exposes host inter-process communication mechanisms and can support privilege escalation. Controller-owned workloads are excluded.

Read More

Detects GKE pod create, update, or patch events that enable host network namespace sharing. HostNetwork grants access to the node network stack and can bypass namespace network policies. System identities and controller-owned workloads are excluded.

Read More

Detects GKE pod create, update, or patch events that enable host PID namespace sharing. HostPID exposes host processes and can support privilege escalation, especially with ptrace or privileged containers. System identities and controller-owned workloads are excluded.

Read More

Detects successful GKE audit events where a pod is created with allowPrivilegeEscalation enabled. This weakens container isolation and can help an attacker escalate toward host access. Standalone pods are included; workloads owned by ReplicaSet, DaemonSet, or StatefulSet controllers are excluded.

Read More

This rule detects a container deployed with one or more dangerously permissive Linux capabilities. An attacker with the ability to deploy a container with added capabilities could use this for further execution, lateral movement, or privilege escalation within a cluster. The capabilities detected in this rule have been used in container escapes to the host machine.

Read More

This rule detects when a pod is created with a sensitive volume of type hostPath. A hostPath volume type mounts a sensitive file or folder from the node to the container. If the container gets compromised, the attacker can use this mount for gaining access to the node. There are many ways a container with unrestricted access to the host filesystem can escalate privileges, including reading data from other containers, and accessing tokens of more privileged pods.

Read More

This rule detects an attempt to create or modify a pod using the host IPC namespace. This gives access to data used by any pod that also use the hosts IPC namespace. If any process on the host or any processes in a pod uses the hosts inter-process communication mechanisms (shared memory, semaphore arrays, message queues, etc.), an attacker can read/write to those same mechanisms. They may look for files in /dev/shm or use ipcs to check for any IPC facilities being used.

Read More

This rules detects an attempt to create or modify a pod attached to the host network. HostNetwork allows a pod to use the node network namespace. Doing so gives the pod access to any service running on localhost of the host. An attacker could use this access to snoop on network activity of other pods on the same node or bypass restrictive network policies applied to its given namespace.

Read More

This rule detects an attempt to create or modify a pod attached to the host PID namespace. HostPID allows a pod to access all the processes running on the host and could allow an attacker to take malicious action. When paired with ptrace this can be used to escalate privileges outside of the container. When paired with a privileged container, the pod can see all of the processes on the host. An attacker can enter the init system (PID 1) on the host. From there, they could execute a shell and continue to escalate privileges to root.

Read More

This rule detects when a user creates a pod/container running in privileged mode. A highly privileged container has access to the node's resources and breaks the isolation between containers. If compromised, an attacker can use the privileged container to gain access to the underlying host. Gaining access to the host may provide the adversary with the opportunity to achieve follow-on objectives, such as establishing persistence, moving laterally within the environment, or setting up a command and control channel on the host.

Read More

Detects nsenter executions from inside a monitored Linux container that include a namespace target flag (-t or --target). Adversaries abuse nsenter to attach to host or sibling namespaces and escape container isolation when combined with privileged mounts, exposed PIDs, or shared namespaces.

Read More

Detects nsenter executions that target PID with a namespace target flag, a pattern commonly used to attach to the host init namespace from a container or session and run with host context.

Read More

Monitors for the execution of a file system mount followed by a chroot execution. Given enough permissions, a user within a container is capable of mounting the root file system of the host, and leveraging chroot to escape its containarized environment. This behavior pattern is very uncommon and should be investigated.

Read More

The Linux kernel invokes the program named in "/proc/sys/kernel/core_pattern" whenever a process core-dumps. When that value begins with a pipe (|), the kernel runs the handler from the host's initial namespace as root, regardless of where the crashing process lived. Because the core-dump up-call is not namespaced, a process inside a container that can write core_pattern can register an attacker-controlled handler and then deliberately crash a process to have it execute on the host as root, resulting in a full container-to-host escape.

Read More

This rule identifies a UID change event via "nsenter". The "nsenter" command is used to enter a namespace, which is a way to isolate processes and resources. Attackers can use "nsenter" to escape from a container to the host, which can lead to privilege escalation and lateral movement.

Read More

This rule detects modification of the cgroup notify_on_release file from inside a container. When the notify_on_release flag is enabled (1) in a cgroup, then whenever the last task in the cgroup exits or attaches to another cgroup, the command specified in the release_agent file is run and invoked from the host. A privileged container with SYS_ADMIN capabilities, enables a threat actor to mount a cgroup directory and modify the notify_on_release flag in order to take advantage of this feature, which could be used for further privilege escalation and container escapes to the host machine.

Read More

This rule monitors for the usage of Docker runtime sockets to escalate privileges on Linux systems. Docker sockets by default are only be writable by the root user and docker group. Attackers that have permissions to write to these sockets may be able to create and run a container that allows them to escalate privileges and gain further access onto the host file system.

Read More

This rule detects modification of the CGroup release_agent file from inside a privileged container. The release_agent is a script that is executed at the termination of any process on that CGroup and is invoked from the host. A privileged container with SYS_ADMIN capabilities, enables a threat actor to mount a CGroup directory and modify the release_agent which could be used for further privilege escalation and container escapes to the host machine.

Read More

This rule detects the creation of privileged containers that mount host directories into the container's filesystem. Such configurations can be exploited by attackers to escape the container isolation and gain access to the host system, potentially leading to privilege escalation and lateral movement within the environment.

Read More

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.

Read More