Potential Container Escape via Kernel core_pattern Modification

[metadata]
creation_date = "2026/07/02"
integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_funnel", "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/07/06"

[rule]
author = ["Elastic"]
description = """
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.
"""
from = "now-9m"
index = [
    "auditbeat-*",
    "endgame-*",
    "logs-auditd_manager.auditd-*",
    "logs-crowdstrike.fdr*",
    "logs-endpoint.events.process*",
    "logs-sentinel_one_cloud_funnel.*",
    "logs-cloud_defend.process*",
]
language = "eql"
license = "Elastic License v2"
name = "Potential Container Escape via Kernel core_pattern Modification"
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 Potential Container Escape via Kernel core_pattern Modification

This rule detects attempts on Linux to change the kernel’s core dump handler, a setting that can make the host run a program as root when a process crashes. In a container, an attacker can write a pipe-based core_pattern such as a shell script path, then deliberately crash a process so the host executes the handler outside the container, turning container access into full host compromise.

### Possible investigation steps

- Verify the current and recent value of `kernel.core_pattern` on the affected node, prioritizing pipe-based handlers and whether the referenced program lives in a writable, temporary, container-mounted, or otherwise untrusted path.
- Reconstruct the full ancestry and session context of the modifying process to determine whether it came from a legitimate admin workflow or from a containerized shell, and identify the associated user, container, image, pod, and privilege level.
- Review the container or pod security context for escape-enabling conditions such as privileged mode, shared host namespaces, hostPath mounts to `/proc` or the host filesystem, and elevated capabilities that would have allowed changing a host kernel parameter.
- Hunt for follow-on exploitation by looking for deliberate crashes, core-dump activity, and new root-owned host processes launched shortly after the change, especially executions from `/tmp`, container overlay paths, or bind-mounted locations.
- If the activity is not authorized, collect the referenced handler file and related artifacts, assess the host for persistence or lateral movement, and contain the node and implicated workload before restoring `kernel.core_pattern` to a known-good value.

### False positive analysis

- An administrator or approved automation may temporarily change `kernel.core_pattern` from a host shell or privileged container during crash-dump troubleshooting; verify the initiating user and parent process, look for a corresponding maintenance window or change record, and confirm the setting was restored to an approved value afterward.
- A legitimate test or debugging workflow may use `sysctl`, shell redirection, or file-copy utilities to point `core_pattern` to a known crash handler before generating controlled faults; confirm the activity is tied to an expected container or host session, the handler path is trusted, and no unexpected root-owned host processes were launched after the change.

### Response and remediation

- Isolate the affected host from the network, cordon and drain the Kubernetes node if applicable, and stop or quarantine the implicated container or pod so the attacker cannot trigger additional core dumps or spawn new host processes.
- Preserve the malicious artifacts for incident handling and then remove the attacker-controlled core dump handler, including any scripts or binaries referenced by `/proc/sys/kernel/core_pattern` and copies placed in `/tmp`, `/var/tmp`, container overlay paths, bind mounts, or other writable locations.
- Restore the node to a known-good state by resetting `kernel.core_pattern` to the approved value, removing unauthorized entries from `/etc/sysctl.conf`, `/etc/sysctl.d/`, and startup scripts that would reapply it, and rebuilding the host from a trusted image if host-level execution occurred.
- Hunt for and remove persistence added after the escape attempt, including rogue systemd units, cron jobs, `/etc/rc.local` changes, SSH `authorized_keys`, newly created sudoers entries, and unauthorized privileged DaemonSets or containers on the node.
- Escalate immediately to incident response if the handler executed on the host, if you find root-owned processes launched from a container-writable path such as `/tmp` or an overlay mount, or if the same `core_pattern` change appears on more than one node.
- Rotate any credentials or tokens exposed on the host or mounted into the compromised workload, then harden the environment by blocking privileged pods, removing dangerous capabilities such as `CAP_SYS_ADMIN`, prohibiting writable `hostPath` access to `/proc` or the host filesystem, and enforcing pod security or admission policies to prevent recurrence.
"""
references = [
    "https://www.sysdig.com/blog/runc-container-escape-vulnerabilities",
    "https://github.com/opencontainers/runc/security/advisories/GHSA-cgrx-mc8f-2prm",
    "https://kubehound.io/reference/attacks/CE_UMH_CORE_PATTERN/",
    "https://aquasecurity.github.io/tracee/latest/docs/events/builtin/signatures/core_pattern_modification/"
]
risk_score = 47
rule_id = "4872671a-c8d2-4847-9891-d3ce08b9e4c9"
setup = """## Setup

This rule requires data coming in from Elastic Defend.

### Elastic Defend Integration Setup
Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app.

#### Prerequisite Requirements:
- Fleet is required for Elastic Defend.
- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).
#### The following steps should be executed in order to add the Elastic Defend integration on a Linux system:
- In the query bar, search for "Elastic Defend" and select the integration to see more details about it.
- Click "Add Elastic Defend".
- Configure the integration name and optionally add a description.
- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads".
- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. [Helper guide](https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html).
- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions"
- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead.
For more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).
- Click "Save and Continue".
- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts.
For more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).
"""
severity = "medium"
tags = [
  "Domain: Endpoint",
  "Domain: Container",
  "Domain: Kubernetes",
  "OS: Linux",
  "Use Case: Threat Detection",
  "Tactic: Privilege Escalation",
  "Data Source: Elastic Defend",
  "Data Source: Elastic Endgame",
  "Data Source: Auditd Manager",
  "Data Source: Crowdstrike",
  "Data Source: SentinelOne",
  "Data Source: Elastic Defend for Containers",
  "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"
query = '''
process where host.os.type == "linux" and event.type == "start" and
event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and
process.args like ("*/proc/sys/kernel/core_pattern*", "*kernel.core_pattern*") and
?process.parent.executable != null and
(
  process.name in ("tee", "cp", "mv", "dd") or
  (
    process.name == "sysctl" and
    process.args like ("*-w*", "*core_pattern*")
  ) or
  (
    process.name in ("bash", "dash", "sh", "zsh", "ksh", "fish", "ash", "mksh", "busybox") and
    process.args == "-c" and process.args like ("*echo *", "*printf *")
  )
) and
not ?process.parent.executable in ("/usr/lib/systemd/systemd", "/usr/bin/kdumpctl", "/usr/sbin/abrtd", "/usr/bin/apport")
'''

[[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/"