{"description":"Trending threats, MITRE ATT\u0026CK coverage, and detection metadata — refreshed continuously.","feed_url":"https://feed.craftedsignal.io/tags/container-escape/","home_page_url":"https://feed.craftedsignal.io/","items":[{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Elastic Defend","sentinel_one_cloud_funnel","crowdstrike.fdr"],"_cs_severities":["high"],"_cs_tags":["container-escape","privilege-escalation","linux"],"_cs_type":"advisory","_cs_vendors":["Elastic","SentinelOne","Crowdstrike"],"content_html":"\u003cp\u003eThis 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\u0026rsquo;s root file system, and then using the \u003ccode\u003echroot\u003c/code\u003e 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.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains initial access to a container, possibly through exploiting a vulnerability or misconfiguration in the application running within the container.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to mount the host\u0026rsquo;s root filesystem within the container using the \u003ccode\u003emount\u003c/code\u003e command, often targeting \u003ccode\u003e/dev/sd*\u003c/code\u003e devices. This requires sufficient privileges within the container, or the exploitation of a container escape vulnerability to gain such privileges.\u003c/li\u003e\n\u003cli\u003eThe \u003ccode\u003emount\u003c/code\u003e command is executed with arguments specifying the device to mount and the mount point within the container\u0026rsquo;s file system.\u003c/li\u003e\n\u003cli\u003eThe attacker then executes the \u003ccode\u003echroot\u003c/code\u003e command, changing the root directory of the current process to the mounted host\u0026rsquo;s root filesystem.\u003c/li\u003e\n\u003cli\u003eAfter successfully executing \u003ccode\u003echroot\u003c/code\u003e, the attacker\u0026rsquo;s perspective shifts to the host\u0026rsquo;s file system, allowing them to access and modify sensitive files and configurations.\u003c/li\u003e\n\u003cli\u003eThe attacker uses their newly acquired access to install backdoors, create new user accounts with elevated privileges, or modify system configurations to establish persistence.\u003c/li\u003e\n\u003cli\u003eThe attacker may attempt to move laterally to other containers or systems within the network, leveraging their compromised position on the host.\u003c/li\u003e\n\u003cli\u003eThe 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.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rules in this brief to your SIEM and tune for your environment to detect potential container escapes.\u003c/li\u003e\n\u003cli\u003eEnable Elastic Defend integration to collect process data, and ensure Session View data is enabled to enhance visibility as mentioned in the setup guide.\u003c/li\u003e\n\u003cli\u003eReview and harden container configurations to minimize privileges granted to containerized processes, reducing the attack surface for escape attempts.\u003c/li\u003e\n\u003cli\u003eImplement network segmentation to limit the potential for lateral movement following a successful container escape.\u003c/li\u003e\n\u003cli\u003eMonitor process execution logs for unusual mount and chroot command sequences within container environments using Elastic Defend, SentinelOne, and Crowdstrike logs.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-05-02T12:45:21Z","date_published":"2026-05-02T12:45:21Z","id":"/briefs/2024-01-chroot-container-escape/","summary":"The rule detects a potential chroot container escape via mount, which involves a user within a container mounting the host's root file system and using chroot to escape the containerized environment, indicating a privilege escalation attempt.","title":"Potential Chroot Container Escape via Mount","url":"https://feed.craftedsignal.io/briefs/2024-01-chroot-container-escape/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Elastic Defend","Auditd Manager"],"_cs_severities":["high"],"_cs_tags":["container-escape","privilege-escalation","linux","chroot"],"_cs_type":"advisory","_cs_vendors":["Elastic"],"content_html":"\u003cp\u003eThis detection rule identifies instances of the \u003ccode\u003echroot\u003c/code\u003e 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 \u003ccode\u003echroot\u003c/code\u003e or the command-line arguments contain \u003ccode\u003echroot\u003c/code\u003e. Container context is determined by identifying processes with a title matching \u003ccode\u003erunc init\u003c/code\u003e, a container workload entry leader, or \u003ccode\u003erunc\u003c/code\u003e 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 \u003ccode\u003echroot\u003c/code\u003e to access files and processes outside the container.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains initial access to a container, potentially through exploiting a vulnerability in the containerized application.\u003c/li\u003e\n\u003cli\u003eThe attacker identifies sensitive host mounts within the container\u0026rsquo;s filesystem, such as \u003ccode\u003e/host\u003c/code\u003e, \u003ccode\u003e/proc/1/root\u003c/code\u003e, or other unexpected node paths.\u003c/li\u003e\n\u003cli\u003eThe attacker executes the \u003ccode\u003echroot\u003c/code\u003e command, specifying an alternate root filesystem, typically a host-linked mount.\u003c/li\u003e\n\u003cli\u003eThe \u003ccode\u003echroot\u003c/code\u003e command redirects system calls to the new root filesystem, effectively isolating the attacker from the container\u0026rsquo;s original environment.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages the new root filesystem to access files, directories, and processes on the host system outside the container\u0026rsquo;s boundaries.\u003c/li\u003e\n\u003cli\u003eThe attacker may then attempt to escalate privileges by exploiting vulnerabilities in host system services or binaries.\u003c/li\u003e\n\u003cli\u003eThe attacker may install malware or establish persistence mechanisms on the host system.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the compromised host system to pivot to other systems on the network or to exfiltrate sensitive data.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eChroot Execution in Container Context\u003c/code\u003e to your SIEM and tune for your environment.\u003c/li\u003e\n\u003cli\u003eEnable process execution telemetry from Elastic Defend and Auditd Manager on Linux to ensure the required data is available for detection.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the Sigma rule to determine if the \u003ccode\u003echroot\u003c/code\u003e execution was authorized and the target directory is an internal build root versus a host filesystem mount.\u003c/li\u003e\n\u003cli\u003eMonitor for follow-on shell execution, access to the container runtime socket, or kubelet credential paths, as these are common indicators of container escape attempts.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-05-02T12:45:21Z","date_published":"2026-05-02T12:45:21Z","id":"/briefs/2026-05-chroot-container-escape/","summary":"Detects suspicious chroot execution within a Linux container context, potentially indicating a container escape attempt by pivoting to an alternate root filesystem.","title":"Chroot Execution in Container Context on Linux","url":"https://feed.craftedsignal.io/briefs/2026-05-chroot-container-escape/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["critical"],"_cs_tags":["lxd","privilege-escalation","container-escape","cve-2026-34178"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eA 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 \u003ccode\u003ebackup/index.yaml\u003c/code\u003e file within the backup archive but creates the instance from the \u003ccode\u003ebackup/container/backup.yaml\u003c/code\u003e file. By crafting a malicious backup archive where \u003ccode\u003eindex.yaml\u003c/code\u003e appears clean while \u003ccode\u003ebackup.yaml\u003c/code\u003e contains configurations that violate project restrictions (e.g., \u003ccode\u003esecurity.privileged=true\u003c/code\u003e, \u003ccode\u003eraw.lxc\u003c/code\u003e 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 \u003ccode\u003ecan_view_instances\u003c/code\u003e, \u003ccode\u003ecan_create_instances\u003c/code\u003e, and \u003ccode\u003ecan_operate_instances\u003c/code\u003e permissions. This affects LXD versions up to those patched in April 2026.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe attacker creates a local directory structure mimicking an LXD backup archive, including \u003ccode\u003ebackup/index.yaml\u003c/code\u003e and \u003ccode\u003ebackup/container/backup.yaml\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe attacker crafts a \u003ccode\u003ebackup/index.yaml\u003c/code\u003e file with configurations that satisfy project restrictions (e.g., no privileged mode, no raw.lxc).\u003c/li\u003e\n\u003cli\u003eThe attacker crafts a malicious \u003ccode\u003ebackup/container/backup.yaml\u003c/code\u003e file that contains configurations violating project restrictions, such as \u003ccode\u003esecurity.privileged=true\u003c/code\u003e and \u003ccode\u003eraw.lxc\u003c/code\u003e entries to mount the host\u0026rsquo;s LXD Unix socket.\u003c/li\u003e\n\u003cli\u003eThe attacker packages the crafted directory structure into a tar archive (e.g., \u003ccode\u003emalicious-backup.tar\u003c/code\u003e).\u003c/li\u003e\n\u003cli\u003eThe attacker uses \u003ccode\u003elxc import target-lxd: malicious-backup.tar --project restricted-project\u003c/code\u003e to import the malicious backup into the target LXD server. LXD validates against \u003ccode\u003eindex.yaml\u003c/code\u003e at this stage.\u003c/li\u003e\n\u003cli\u003eLXD extracts the contents of the tar archive, including the malicious \u003ccode\u003ebackup.yaml\u003c/code\u003e, to the storage volume. The actual instance creation uses \u003ccode\u003ebackup.yaml\u003c/code\u003e configuration.\u003c/li\u003e\n\u003cli\u003eThe attacker starts the newly created, privileged container using \u003ccode\u003elxc start target-lxd:escalated-instance --project restricted-project\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe 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.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eApply 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.\u003c/li\u003e\n\u003cli\u003eMonitor LXD server logs for suspicious \u003ccode\u003elxc import\u003c/code\u003e 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.\u003c/li\u003e\n\u003cli\u003eDeploy the provided Sigma rule to detect the creation of containers with \u003ccode\u003esecurity.privileged\u003c/code\u003e set to true or with \u003ccode\u003eraw.lxc\u003c/code\u003e configurations in restricted projects by analyzing the LXD database (if accessible).\u003c/li\u003e\n\u003cli\u003eAs a defense-in-depth measure, consider implementing filesystem integrity monitoring on the LXD storage volumes to detect unauthorized modifications to container configurations.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-10T19:24:26Z","date_published":"2026-04-10T19:24:26Z","id":"/briefs/2026-04-lxd-backup-bypass/","summary":"A vulnerability in LXD allows an attacker with instance-creation rights in a restricted project to bypass project restrictions and escalate privileges by crafting a malicious backup archive.","title":"LXD Backup Import Bypass Allows Privilege Escalation in Restricted Projects","url":"https://feed.craftedsignal.io/briefs/2026-04-lxd-backup-bypass/"},{"_cs_actors":[],"_cs_cves":[{"id":"CVE-2026-41326"}],"_cs_exploited":false,"_cs_products":["kata-containers/kata-containers (\u003c 0.0.0-20260422180503-1b9e49eb2763)"],"_cs_severities":["high"],"_cs_tags":["kata-containers","container-escape","symlink"],"_cs_type":"advisory","_cs_vendors":["kata-containers"],"content_html":"\u003cp\u003eAn 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 \u003ccode\u003eCopyFileRequest\u003c/code\u003e 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 \u003ccode\u003egenpolicy\u003c/code\u003e 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 \u003ccode\u003ego/github.com/kata-containers/kata-containers\u003c/code\u003e versions prior to \u003ccode\u003e0.0.0-20260422180503-1b9e49eb2763\u003c/code\u003e.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe attacker identifies a target file within the guest container image, such as a binary or configuration file they wish to overwrite.\u003c/li\u003e\n\u003cli\u003eThe attacker crafts a \u003ccode\u003eCopyFileRequest\u003c/code\u003e to create a symbolic link within the \u003ccode\u003e/run/kata-containers/shared/containers\u003c/code\u003e directory.\u003c/li\u003e\n\u003cli\u003eThe \u003ccode\u003epath\u003c/code\u003e parameter of the request specifies the location of the symlink within the shared directory.\u003c/li\u003e\n\u003cli\u003eThe \u003ccode\u003edata\u003c/code\u003e 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.\u003c/li\u003e\n\u003cli\u003eThe Kata Agent processes the \u003ccode\u003eCopyFileRequest\u003c/code\u003e, creating the symbolic link within the shared directory, pointing to the target file inside the container image.\u003c/li\u003e\n\u003cli\u003eThe attacker crafts a second \u003ccode\u003eCopyFileRequest\u003c/code\u003e to copy malicious data into the symlink created in step 5.\u003c/li\u003e\n\u003cli\u003eThe Kata Agent writes the malicious data to the symlink, which then overwrites the original target file within the container image.\u003c/li\u003e\n\u003cli\u003eThe attacker restarts the container or waits for the compromised binary to be executed, achieving arbitrary code execution within the guest.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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 \u003ccode\u003egenpolicy\u003c/code\u003e implementation.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eApply the patch or upgrade to \u003ccode\u003ego/github.com/kata-containers/kata-containers\u003c/code\u003e version \u003ccode\u003e0.0.0-20260422180503-1b9e49eb2763\u003c/code\u003e or later to address CVE-2026-41326.\u003c/li\u003e\n\u003cli\u003eMonitor the creation of symbolic links within the \u003ccode\u003e/run/kata-containers/shared/containers\u003c/code\u003e directory, using the provided Sigma rule, as this is an unusual operation (file_event).\u003c/li\u003e\n\u003cli\u003eImplement strict access controls and monitoring for the Kata Agent to prevent unauthorized \u003ccode\u003eCopyFileRequest\u003c/code\u003e messages.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T12:00:00Z","date_published":"2024-01-03T12:00:00Z","id":"/briefs/2024-01-03-kata-containers-copyfile-symlink/","summary":"An oversight in the CopyFile policy in Kata Containers allows untrusted hosts to write to arbitrary locations inside the guest workload image via symlinks, enabling binary overwrites and data exfiltration.","title":"Kata Containers CopyFile Policy Subversion via Symlinks","url":"https://feed.craftedsignal.io/briefs/2024-01-03-kata-containers-copyfile-symlink/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Elastic Defend","Auditbeat","Elastic Endgame","SentinelOne Cloud Funnel"],"_cs_severities":["medium"],"_cs_tags":["privilege-escalation","container-escape","linux"],"_cs_type":"advisory","_cs_vendors":["Elastic","SentinelOne"],"content_html":"\u003cp\u003eThe \u003ccode\u003eunshare\u003c/code\u003e command in Linux is a utility used to create new namespaces, providing isolation for processes. While crucial for containerization and security, attackers can misuse \u003ccode\u003eunshare\u003c/code\u003e 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 \u003ccode\u003eunshare\u003c/code\u003e executions that deviate from legitimate system management activities.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains initial access to a Linux system, potentially through exploiting a vulnerability in a containerized application.\u003c/li\u003e\n\u003cli\u003eThe attacker executes the \u003ccode\u003eunshare\u003c/code\u003e command.\u003c/li\u003e\n\u003cli\u003e\u003ccode\u003eunshare\u003c/code\u003e creates new namespaces, isolating the attacker\u0026rsquo;s process from the rest of the system.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to mount sensitive directories from the host system into the new namespace.\u003c/li\u003e\n\u003cli\u003eUsing the newly gained access, the attacker attempts to modify system files, such as \u003ccode\u003e/etc/passwd\u003c/code\u003e or \u003ccode\u003e/etc/shadow\u003c/code\u003e, to create new privileged accounts.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages the elevated privileges to install persistent backdoors or malware on the host system.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to move laterally to other systems on the network.\u003c/li\u003e\n\u003cli\u003eThe attacker achieves their final objective, such as data exfiltration or system disruption.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation via \u003ccode\u003eunshare\u003c/code\u003e 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eNamespace Manipulation Using Unshare\u003c/code\u003e to your SIEM to detect suspicious \u003ccode\u003eunshare\u003c/code\u003e command executions and tune for your environment.\u003c/li\u003e\n\u003cli\u003eEnable Auditbeat or Elastic Defend to collect the necessary process execution data to trigger the provided Sigma rule, as outlined in the rule\u0026rsquo;s \u003ccode\u003esetup\u003c/code\u003e section.\u003c/li\u003e\n\u003cli\u003eReview and tune the provided Sigma rule\u0026rsquo;s exclusion list based on your environment\u0026rsquo;s legitimate use cases for \u003ccode\u003eunshare\u003c/code\u003e, as described in the \u0026ldquo;False positive analysis\u0026rdquo; section.\u003c/li\u003e\n\u003cli\u003eImplement additional monitoring and alerting for unusual \u003ccode\u003eunshare\u003c/code\u003e usage patterns to enhance detection capabilities and prevent future occurrences as recommended in the \u0026ldquo;Response and remediation\u0026rdquo; section.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-02T12:00:00Z","date_published":"2024-01-02T12:00:00Z","id":"/briefs/2024-01-unshare-namespace-manipulation/","summary":"The `unshare` command is used to create new namespaces in Linux, which can be exploited to break out of containers or elevate privileges by creating namespaces that bypass security controls.","title":"Suspicious Unshare Usage for Namespace Manipulation","url":"https://feed.craftedsignal.io/briefs/2024-01-unshare-namespace-manipulation/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Elastic Defend for Containers"],"_cs_severities":["medium"],"_cs_tags":["privilege-escalation","container-escape","linux"],"_cs_type":"advisory","_cs_vendors":["Elastic"],"content_html":"\u003cp\u003eThe \u003ccode\u003eunshare\u003c/code\u003e 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 \u003ccode\u003eunshare\u003c/code\u003e 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 \u003ccode\u003eunshare\u003c/code\u003e 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.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eA containerized process is compromised, potentially through an initial exploit or misconfiguration.\u003c/li\u003e\n\u003cli\u003eThe attacker executes the \u003ccode\u003eunshare\u003c/code\u003e command within the container.\u003c/li\u003e\n\u003cli\u003e\u003ccode\u003eunshare\u003c/code\u003e is used to create new namespaces, isolating the attacker\u0026rsquo;s process from the container\u0026rsquo;s limitations.\u003c/li\u003e\n\u003cli\u003eThe attacker manipulates these namespaces to gain access to resources outside the container.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to escape the container by leveraging the newly created namespaces.\u003c/li\u003e\n\u003cli\u003eUpon successful escape, the attacker gains access to the host system.\u003c/li\u003e\n\u003cli\u003eThe attacker escalates privileges on the host, potentially exploiting vulnerabilities or misconfigurations.\u003c/li\u003e\n\u003cli\u003eThe attacker achieves full control over the host system, allowing for data exfiltration, system compromise, or lateral movement.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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 \u003ccode\u003eunshare\u003c/code\u003e command, helping to maintain the integrity and security of containerized environments.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the provided Sigma rule to your SIEM to detect suspicious \u003ccode\u003eunshare\u003c/code\u003e executions within containers and tune for your environment.\u003c/li\u003e\n\u003cli\u003eReview and whitelist legitimate uses of \u003ccode\u003eunshare\u003c/code\u003e by system management tools like \u003ccode\u003eudevadm\u003c/code\u003e and \u003ccode\u003esystemd-udevd\u003c/code\u003e to reduce false positives, as mentioned in the rule\u0026rsquo;s description.\u003c/li\u003e\n\u003cli\u003eImplement additional monitoring and alerting for unusual \u003ccode\u003eunshare\u003c/code\u003e usage patterns to enhance detection capabilities and prevent future occurrences.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-02T12:00:00Z","date_published":"2024-01-02T12:00:00Z","id":"/briefs/2024-01-unshare-container-escape/","summary":"The rule identifies suspicious usage of unshare to manipulate system namespaces, which can be utilized to escalate privileges or escape container security boundaries.","title":"Suspicious Unshare Usage for Container Escape and Privilege Escalation","url":"https://feed.craftedsignal.io/briefs/2024-01-unshare-container-escape/"}],"language":"en","title":"CraftedSignal Threat Feed — Container-Escape","version":"https://jsonfeed.org/version/1.1"}