Chroot Execution Detected via Defend for Containers

[metadata]
creation_date = "2026/03/26"
integration = ["cloud_defend"]
maturity = "production"
min_stack_comments = "Defend for Containers integration was re-introduced in 9.3.0"
min_stack_version = "9.3.0"
updated_date = "2026/04/06"

[rule]
author = ["Elastic"]
description = """
This rule detects when chroot is executed inside a container. Chroot is a Linux utility that allows a user to
run a command in a different directory. This can be used to escape a container and gain access to the host system.
"""
from = "now-6m"
index = ["logs-cloud_defend.process*"]
interval = "5m"
language = "eql"
license = "Elastic License v2"
name = "Chroot Execution Detected via Defend for Containers"
note = """## Triage and analysis

> **Disclaimer**:
> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.

### Investigating Chroot Execution Detected via Defend for Containers

This alert flags a process inside a Linux container that launches chroot, which can let code run against an alternate root filesystem and is often used to break container isolation. An attacker who has landed in a privileged or misconfigured container may chroot into a mounted host path such as /host or /proc/1/root, then spawn a shell to access host files, binaries, and credentials.

### Possible investigation steps

- Review the full execution chain and command arguments to identify the target root path and spawned program, prioritizing cases that reference host-linked locations such as /host, /proc/1/root, /mnt, or other node filesystem mounts.
- Validate the container’s security posture at the time of execution, including whether it ran as root, used privileged mode, exposed host namespaces, or mounted sensitive host paths that would make a chroot attempt capable of escaping isolation.
- Examine nearby process, file, and network activity from the same container or pod for follow-on actions against the host, such as shell launches, access to container runtime sockets, kubelet paths, SSH material, or other credential-bearing files.
- Compare the behavior with the container image’s normal purpose, entrypoint, recent image or deployment changes, and any approved troubleshooting activity to determine whether the chroot was expected administration or anomalous runtime behavior.
- If the activity is unexplained or hostile, isolate or terminate the workload, collect the container filesystem and runtime metadata for forensics, and assess the underlying node for compromise before rotating any potentially exposed secrets.

### False positive analysis

- Some build, initialization, or package-maintenance containers legitimately call chroot to install files into a staged root filesystem; verify the image or startup script is intended to prepare an alternate root and that the target path is an expected internal mount rather than a host-linked location.
- An approved troubleshooting or recovery session in a privileged container may use chroot to inspect or repair an intentionally mounted filesystem; verify the user and timing align with authorized maintenance and confirm the command did not pivot to paths such as /proc/1/root, /host, or other node filesystems.

### Response and remediation

- Immediately isolate the affected pod or container, cordon the worker node it ran on, stop the malicious workload, and preserve the container filesystem, mounted volumes, and node logs for forensic review.
- Hunt for and remove persistence related to the compromise, including rogue CronJobs or DaemonSets, modified entrypoint or startup scripts, unauthorized SSH authorized_keys, new sudoers entries, and unexpected systemd services on the node.
- If the chroot targeted host-linked paths such as /proc/1/root or /host, or you find access to the container runtime socket, kubelet credentials, or new privileged workloads, escalate immediately to incident response and treat the node as potentially fully compromised.
- Restore the environment from a known-good state by reimaging or replacing affected nodes, redeploying the workload from a trusted image digest, and rotating any credentials, service account tokens, kubeconfigs, or cloud keys exposed to the container or host.
- Harden the environment to prevent recurrence by removing privileged mode and hostPath mounts, enforcing non-root containers, dropping unnecessary Linux capabilities, applying seccomp or AppArmor or SELinux profiles, and restricting access to host namespaces and runtime sockets.
"""
references = [
    "https://some-natalie.dev/container-escapes-chroot/",
]
risk_score = 21
rule_id = "47661529-15ed-4848-93da-9fbded7a3a0e"
severity = "low"
tags = [
    "Data Source: Elastic Defend for Containers",
    "Domain: Container",
    "OS: Linux",
    "Use Case: Threat Detection",
    "Tactic: Privilege Escalation",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"
query = '''
process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and (
  process.name == "chroot" or
  (
    /* account for tools that execute utilities as a subprocess, in this case the target utility name will appear as a process arg */
    process.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish", "busybox") and
    process.args in (
      "chroot", "/bin/chroot", "/usr/bin/chroot", "/usr/local/bin/chroot"
    ) and
    /* default exclusion list to not FP on default multi-process commands */
    not process.args in (
      "which", "/bin/which", "/usr/bin/which", "/usr/local/bin/which",
      "man", "/bin/man", "/usr/bin/man", "/usr/local/bin/man",
      "chmod", "/bin/chmod", "/usr/bin/chmod", "/usr/local/bin/chmod",
      "chown", "/bin/chown", "/usr/bin/chown", "/usr/local/bin/chown"
    )
  )
) and container.id like "?*"
'''

[[rule.threat]]
framework = "MITRE ATT&CK"

[[rule.threat.technique]]
id = "T1611"
name = "Escape to Host"
reference = "https://attack.mitre.org/techniques/T1611/"

[rule.threat.tactic]
id = "TA0004"
name = "Privilege Escalation"
reference = "https://attack.mitre.org/tactics/TA0004/"