Chroot Execution in Container Context on Linux
Detects suspicious chroot execution within a Linux container context, potentially indicating a container escape attempt by pivoting to an alternate root filesystem.
This detection rule identifies instances of the chroot command being executed within a Linux containerized environment. It leverages process execution telemetry from Elastic Defend and Auditd Manager to detect potential container escape attempts. The rule focuses on processes where the name is chroot or the command-line arguments contain chroot. Container context is determined by identifying processes with a title matching runc init, a container workload entry leader, or runc as the parent process. Successful container escapes can allow attackers to gain unauthorized access to the host system. The technique is often combined with sensitive host mounts, which are then leveraged after the chroot to access files and processes outside the container.
Attack Chain
- An attacker gains initial access to a container, potentially through exploiting a vulnerability in the containerized application.
- The attacker identifies sensitive host mounts within the container’s filesystem, such as
/host,/proc/1/root, or other unexpected node paths. - The attacker executes the
chrootcommand, specifying an alternate root filesystem, typically a host-linked mount. - The
chrootcommand redirects system calls to the new root filesystem, effectively isolating the attacker from the container’s original environment. - The attacker leverages the new root filesystem to access files, directories, and processes on the host system outside the container’s boundaries.
- The attacker may then attempt to escalate privileges by exploiting vulnerabilities in host system services or binaries.
- The attacker may install malware or establish persistence mechanisms on the host system.
- The attacker uses the compromised host system to pivot to other systems on the network or to exfiltrate sensitive data.
Impact
A successful container escape can lead to full compromise of the underlying host system, potentially impacting all containers running on the same host. This can enable attackers to access sensitive data, disrupt services, and move laterally within the network. In multi-tenant environments, a container escape can compromise the security of other tenants sharing the same infrastructure. A single successful container escape can lead to a widespread breach impacting numerous systems and applications.
Recommendation
- Deploy the Sigma rule
Chroot Execution in Container Contextto your SIEM and tune for your environment. - Enable process execution telemetry from Elastic Defend and Auditd Manager on Linux to ensure the required data is available for detection.
- Investigate any alerts generated by the Sigma rule to determine if the
chrootexecution was authorized and the target directory is an internal build root versus a host filesystem mount. - Monitor for follow-on shell execution, access to the container runtime socket, or kubelet credential paths, as these are common indicators of container escape attempts.
Detection coverage 2
Chroot Execution in Container Context
highDetects chroot execution when the process runs in a container-oriented context.
Chroot with Suspicious Arguments in Container
highDetects chroot execution with arguments commonly used in container escape scenarios.
Detection queries are kept inside the platform. Get full rules →