Container-Escape — CraftedSignal Threat Feed

Potential Chroot Container Escape via Mount

hello@craftedsignal.io — Sat, 02 May 2026 12:45:21 +0000

This detection rule monitors for a specific sequence of commands on Linux systems that could indicate an attempt to escape a containerized environment. The attack involves first mounting a file system, typically targeting the host’s root file system, and then using the chroot command to change the root directory. This combination, if successful, allows an attacker inside a container to gain unauthorized access to the host system. The rule is designed to identify this uncommon behavior pattern, which is a strong indicator of malicious activity. The rule is applicable to environments utilizing Elastic Defend, SentinelOne Cloud Funnel, and Crowdstrike FDR. The detection looks for this sequence occurring within a 5-minute timeframe.

Attack Chain

An attacker gains initial access to a container, possibly through exploiting a vulnerability or misconfiguration in the application running within the container.
The attacker attempts to mount the host’s root filesystem within the container using the mount command, often targeting /dev/sd* devices. This requires sufficient privileges within the container, or the exploitation of a container escape vulnerability to gain such privileges.
The mount command is executed with arguments specifying the device to mount and the mount point within the container’s file system.
The attacker then executes the chroot command, changing the root directory of the current process to the mounted host’s root filesystem.
After successfully executing chroot, the attacker’s perspective shifts to the host’s file system, allowing them to access and modify sensitive files and configurations.
The attacker uses their newly acquired access to install backdoors, create new user accounts with elevated privileges, or modify system configurations to establish persistence.
The attacker may attempt to move laterally to other containers or systems within the network, leveraging their compromised position on the host.
The final objective is to gain complete control over the host system and potentially the entire infrastructure, leading to data exfiltration, system disruption, or other malicious activities.

Impact

A successful container escape can have severe consequences, potentially leading to complete compromise of the host system and the data it contains. Depending on the environment, this could affect a single server or spread to many hosts. The compromise of containerized environments can lead to data breaches, service disruption, and reputational damage. Given the sensitive nature of data often processed within containers, the impact can range from financial losses to regulatory penalties.

Recommendation

Deploy the Sigma rules in this brief to your SIEM and tune for your environment to detect potential container escapes.
Enable Elastic Defend integration to collect process data, and ensure Session View data is enabled to enhance visibility as mentioned in the setup guide.
Review and harden container configurations to minimize privileges granted to containerized processes, reducing the attack surface for escape attempts.
Implement network segmentation to limit the potential for lateral movement following a successful container escape.
Monitor process execution logs for unusual mount and chroot command sequences within container environments using Elastic Defend, SentinelOne, and Crowdstrike logs.

Chroot Execution in Container Context on Linux

hello@craftedsignal.io — Sat, 02 May 2026 12:45:21 +0000

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 chroot command, specifying an alternate root filesystem, typically a host-linked mount.
The chroot command 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 Context to 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 chroot execution 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.

LXD Backup Import Bypass Allows Privilege Escalation in Restricted Projects

hello@craftedsignal.io — Fri, 10 Apr 2026 19:24:26 +0000

A critical vulnerability exists in LXD (versions prior to the fixes mentioned below) that allows an attacker with limited privileges in a restricted project to bypass security restrictions and gain full control of the LXD host. The vulnerability stems from improper validation during instance backup import. Specifically, LXD validates project restrictions against the backup/index.yaml file within the backup archive but creates the instance from the backup/container/backup.yaml file. By crafting a malicious backup archive where index.yaml appears clean while backup.yaml contains configurations that violate project restrictions (e.g., security.privileged=true, raw.lxc host filesystem mounts), an attacker can create a privileged container and escape the restricted environment. This allows them to escalate privileges and potentially compromise the entire LXD host. The attacker needs can_view_instances, can_create_instances, and can_operate_instances permissions. This affects LXD versions up to those patched in April 2026.

Attack Chain

The attacker creates a local directory structure mimicking an LXD backup archive, including backup/index.yaml and backup/container/backup.yaml.
The attacker crafts a backup/index.yaml file with configurations that satisfy project restrictions (e.g., no privileged mode, no raw.lxc).
The attacker crafts a malicious backup/container/backup.yaml file that contains configurations violating project restrictions, such as security.privileged=true and raw.lxc entries to mount the host’s LXD Unix socket.
The attacker packages the crafted directory structure into a tar archive (e.g., malicious-backup.tar).
The attacker uses lxc import target-lxd: malicious-backup.tar --project restricted-project to import the malicious backup into the target LXD server. LXD validates against index.yaml at this stage.
LXD extracts the contents of the tar archive, including the malicious backup.yaml, to the storage volume. The actual instance creation uses backup.yaml configuration.
The attacker starts the newly created, privileged container using lxc start target-lxd:escalated-instance --project restricted-project.
The attacker leverages the bind-mounted LXD Unix socket from within the container to interact with the LXD API as a full administrator, allowing them to create admin certificates, access all projects, and modify any instance, leading to full host compromise.

Impact

Successful exploitation allows an attacker to completely bypass LXD project restrictions and gain full administrative control over the LXD host. This can lead to the compromise of all containers running on the host, data theft, and further malicious activities. The vulnerability affects multi-tenant environments where LXD is used to isolate different users or projects, allowing a malicious tenant to break out of their restricted environment and compromise the entire system.

Recommendation

Apply the patches provided by Canonical for LXD versions 6, 5.21, and 5.0 to remediate the vulnerability. Specifically, upgrade to LXD 6.7, LXD 5.21.4, or LXD 5.0.6.
Monitor LXD server logs for suspicious lxc import commands, especially those targeting restricted projects. While difficult to detect solely on command line arguments, anomalous import patterns could be a sign of attempted exploitation.
Deploy the provided Sigma rule to detect the creation of containers with security.privileged set to true or with raw.lxc configurations in restricted projects by analyzing the LXD database (if accessible).
As a defense-in-depth measure, consider implementing filesystem integrity monitoring on the LXD storage volumes to detect unauthorized modifications to container configurations.

Kata Containers CopyFile Policy Subversion via Symlinks

hello@craftedsignal.io — Wed, 03 Jan 2024 12:00:00 +0000

An oversight in the CopyFile policy within Kata Containers allows a malicious host to manipulate guest workload images. The vulnerability stems from insufficient validation within the CopyFileRequest policy, specifically related to symlink creation. The policy primarily checks the destination path of copied files but fails to adequately validate the target of symlinks created via the same API. This flaw was discovered by @calonso-nv and impacts environments where the genpolicy implementation is used to prevent host access to container images, including Confidential Containers workloads which rely on strong isolation. If the guest image is not protected from the host (e.g., when using unprotected host pull), the system is not vulnerable. The affected package is go/github.com/kata-containers/kata-containers versions prior to 0.0.0-20260422180503-1b9e49eb2763.

Attack Chain

The attacker identifies a target file within the guest container image, such as a binary or configuration file they wish to overwrite.
The attacker crafts a CopyFileRequest to create a symbolic link within the /run/kata-containers/shared/containers directory.
The path parameter of the request specifies the location of the symlink within the shared directory.
The data parameter of the request specifies the target of the symbolic link, which points to the target file identified in step 1, inside the guest file system.
The Kata Agent processes the CopyFileRequest, creating the symbolic link within the shared directory, pointing to the target file inside the container image.
The attacker crafts a second CopyFileRequest to copy malicious data into the symlink created in step 5.
The Kata Agent writes the malicious data to the symlink, which then overwrites the original target file within the container image.
The attacker restarts the container or waits for the compromised binary to be executed, achieving arbitrary code execution within the guest.

Impact

Successful exploitation allows attackers to overwrite arbitrary files within container images managed by Kata Containers. This can lead to arbitrary code execution within the guest environment, data exfiltration, and privilege escalation. This is particularly critical in Confidential Containers environments where the trust model explicitly forbids host access to container images. Affected systems are those employing the upstream genpolicy implementation.

Recommendation

Apply the patch or upgrade to go/github.com/kata-containers/kata-containers version 0.0.0-20260422180503-1b9e49eb2763 or later to address CVE-2026-41326.
Monitor the creation of symbolic links within the /run/kata-containers/shared/containers directory, using the provided Sigma rule, as this is an unusual operation (file_event).
Implement strict access controls and monitoring for the Kata Agent to prevent unauthorized CopyFileRequest messages.

Suspicious Unshare Usage for Namespace Manipulation

hello@craftedsignal.io — Tue, 02 Jan 2024 12:00:00 +0000

The unshare command in Linux is a utility used to create new namespaces, providing isolation for processes. While crucial for containerization and security, attackers can misuse unshare to escape container boundaries or escalate privileges by manipulating system namespaces. This occurs by creating namespaces that bypass established security controls. This activity is often observed when threat actors attempt to gain unauthorized access to host resources or elevate their privileges within a compromised system. The focus of this detection is on identifying unusual unshare executions that deviate from legitimate system management activities.

Attack Chain

An attacker gains initial access to a Linux system, potentially through exploiting a vulnerability in a containerized application.
The attacker executes the unshare command.
unshare creates new namespaces, isolating the attacker’s process from the rest of the system.
The attacker attempts to mount sensitive directories from the host system into the new namespace.
Using the newly gained access, the attacker attempts to modify system files, such as /etc/passwd or /etc/shadow, to create new privileged accounts.
The attacker leverages the elevated privileges to install persistent backdoors or malware on the host system.
The attacker attempts to move laterally to other systems on the network.
The attacker achieves their final objective, such as data exfiltration or system disruption.

Impact

Successful exploitation via unshare can lead to privilege escalation, container escape, and unauthorized access to sensitive resources on the host system. The impact includes potential data breaches, system compromise, and lateral movement within the network. While the number of victims is unknown, the widespread use of containerization technologies makes this a significant threat, particularly for organizations relying on Linux-based container environments and cloud infrastructures.

Recommendation

Deploy the Sigma rule Namespace Manipulation Using Unshare to your SIEM to detect suspicious unshare command executions and tune for your environment.
Enable Auditbeat or Elastic Defend to collect the necessary process execution data to trigger the provided Sigma rule, as outlined in the rule’s setup section.
Review and tune the provided Sigma rule’s exclusion list based on your environment’s legitimate use cases for unshare, as described in the “False positive analysis” section.
Implement additional monitoring and alerting for unusual unshare usage patterns to enhance detection capabilities and prevent future occurrences as recommended in the “Response and remediation” section.

Suspicious Unshare Usage for Container Escape and Privilege Escalation

hello@craftedsignal.io — Tue, 02 Jan 2024 12:00:00 +0000

The unshare command in Linux is used to create new namespaces, isolating processes from the rest of the system. This isolation is crucial for containerization and security. However, attackers can exploit unshare to break out of containers or elevate privileges by creating namespaces that bypass security controls. This activity has been observed in containerized environments where threat actors attempt to gain unauthorized access to the host system or escalate their privileges within the container. The detection rule identifies suspicious unshare executions by monitoring process starts, filtering out benign parent processes, and focusing on unusual usage patterns, thus highlighting potential misuse. The rule covers activity starting from Elastic Defend for Containers version 9.3.0.

Attack Chain

A containerized process is compromised, potentially through an initial exploit or misconfiguration.
The attacker executes the unshare command within the container.
unshare is used to create new namespaces, isolating the attacker’s process from the container’s limitations.
The attacker manipulates these namespaces to gain access to resources outside the container.
The attacker attempts to escape the container by leveraging the newly created namespaces.
Upon successful escape, the attacker gains access to the host system.
The attacker escalates privileges on the host, potentially exploiting vulnerabilities or misconfigurations.
The attacker achieves full control over the host system, allowing for data exfiltration, system compromise, or lateral movement.

Impact

Successful exploitation can lead to container escape, allowing attackers to gain unauthorized access to the host system. This can result in privilege escalation, data exfiltration, and complete system compromise. The rule aims to detect and prevent such attacks by identifying suspicious usage of the unshare command, helping to maintain the integrity and security of containerized environments.

Recommendation

Deploy the provided Sigma rule to your SIEM to detect suspicious unshare executions within containers and tune for your environment.
Review and whitelist legitimate uses of unshare by system management tools like udevadm and systemd-udevd to reduce false positives, as mentioned in the rule’s description.
Implement additional monitoring and alerting for unusual unshare usage patterns to enhance detection capabilities and prevent future occurrences.