Container process entering the host namespaces

Siemphony@siemphonymediumT1611unverifiedPlaybook · Privilege escalation

Matches the escape step AN0613 describes — a containerised process crossing into the host's namespaces — on the Sysmon-for-Linux process-creation source the analytic offers, in two arms. The first pairs `nsenter` in `Image` with a `CommandLine` naming PID 1 as the target, which is the direction that matters: host tooling entering a container targets that container's PID, so a target of 1 (or a `/proc/1/ns` path handed to setns) is a process reaching upward out of its own namespace set rather than downward into someone else's. The second arm matches command lines naming `release_agent`, `notify_on_release` or `/proc/sys/kernel/core_pattern`, the three host files a privileged container writes to make the host kernel execute a payload for it. The analytic's other log source, raw `auditd`, was not used: it records the syscall number rather than the name, splits arguments into positional a0/a1 fields instead of one command line, and does not watch unshare/setns/keyctl at all until an audit rule is added by hand, which no default or baseline policy does. MITRE supplies the SyscallWhitelist knob; the utility and path list here is authored. Three limits worth stating: an escape carried out entirely in-process — a program calling setns() or unshare() through libc, or a kernel exploit — creates no exec and is invisible here; a shell builtin redirect such as `echo … > /proc/sys/kernel/core_pattern` also creates no exec, so only the `sh -c` and `tee` forms of that write are seen; and Sysmon for Linux is a separate agent that no distribution installs by default, so a host running stock auditd alone produces nothing this rule can read. UNVERIFIED AS AUTHORED — derived from MITRE ATT&CK DET0219, not hand-written and not tested by its author. Any lab result is on this rule's own page.Full description

The 3 SIEM queries below are previews produced by Siemphony’s own translator, not pySigma, and none has been executed against a real backend — review before you deploy.

detection.yml

1title: Container process entering the host namespaces2id: f27d0c3b-c763-4343-aa9f-c0f82a5907a63status: experimental4description: |5  Matches the escape step AN0613 describes — a containerised process crossing6  into the host's namespaces — on the Sysmon-for-Linux process-creation source7  the analytic offers, in two arms. The first pairs `nsenter` in `Image` with a8  `CommandLine` naming PID 1 as the target, which is the direction that matters:9  host tooling entering a container targets that container's PID, so a target of10  1 (or a `/proc/1/ns` path handed to setns) is a process reaching upward out of11  its own namespace set rather than downward into someone else's. The second arm12  matches command lines naming `release_agent`, `notify_on_release` or13  `/proc/sys/kernel/core_pattern`, the three host files a privileged container14  writes to make the host kernel execute a payload for it. The analytic's other15  log source, raw `auditd`, was not used: it records the syscall number rather16  than the name, splits arguments into positional a0/a1 fields instead of one17  command line, and does not watch unshare/setns/keyctl at all until an audit18  rule is added by hand, which no default or baseline policy does. MITRE supplies19  the SyscallWhitelist knob; the utility and path list here is authored. Three20  limits worth stating: an escape carried out entirely in-process — a program21  calling setns() or unshare() through libc, or a kernel exploit — creates no22  exec and is invisible here; a shell builtin redirect such as23  `echo … > /proc/sys/kernel/core_pattern` also creates no exec, so only the24  `sh -c` and `tee` forms of that write are seen; and Sysmon for Linux is a25  separate agent that no distribution installs by default, so a host running26  stock auditd alone produces nothing this rule can read.27  UNVERIFIED AS AUTHORED — derived from MITRE ATT&CK DET0219, not hand-written and not tested by its author. Any lab result is on this rule's own page.28references:29  - https://attack.mitre.org/techniques/T161130  - https://attack.mitre.org/detectionstrategies/DET021931author: Siemphony pipeline (machine-derived from MITRE ATT&CK v19.2)32date: 2026-08-1633tags:34  - attack.privilege-escalation35  - attack.t161136logsource:37  product: linux38  service: sysmon39detection:40  selection_nsenter:41    Image|endswith: '/nsenter'42  selection_hostns:43    CommandLine|contains:44      - '-t 1 '45      - '--target 1 '46      - '--target=1 '47      - '/proc/1/ns'48  selection_hostwrite:49    CommandLine|contains:50      - 'release_agent'51      - 'notify_on_release'52      - '/proc/sys/kernel/core_pattern'53  condition: (selection_nsenter and selection_hostns) or selection_hostwrite54falsepositives:55  - "Node-level agents on a Kubernetes cluster that enter the host namespaces on purpose. CSI drivers, CNI plugins, log shippers and monitoring DaemonSets routinely run `nsenter -t 1 -m -u -i -n -p` to read host state or mount volumes, and on a busy node this is the highest-volume match by a wide margin, recurring every time one of those pods is rescheduled."56  - "Operators troubleshooting a node with `kubectl debug node/...` or a privileged `docker run`, both of which drop the user into the host mount and PID namespaces using the identical nsenter one-liner an operator would type."57  - "Container runtime and cgroup-v1 housekeeping, where runc, systemd or a legacy container manager names release_agent or notify_on_release while creating or tearing down a cgroup hierarchy."58  - "Crash-handler packages configuring core dumps at boot or on upgrade — ABRT, systemd-coredump and Apport post-install scripts write /proc/sys/kernel/core_pattern through `sh -c` or `tee`, which is exactly the visible form of that write."59level: medium

Splunk · SPL

Run this as a search.

index=* ((Image="*/nsenter" AND (CommandLine="*-t 1 *" OR CommandLine="*--target 1 *" OR CommandLine="*--target=1 *" OR CommandLine="*/proc/1/ns*")) OR (CommandLine="*release_agent*" OR CommandLine="*notify_on_release*" OR CommandLine="*/proc/sys/kernel/core_pattern*"))

Elastic · ES|QL

Run this as a search.

FROM logs-*| WHERE ((TO_LOWER(process.executable) LIKE "*/nsenter" AND (TO_LOWER(CommandLine) LIKE "*-t 1 *" OR TO_LOWER(CommandLine) LIKE "*--target 1 *" OR TO_LOWER(CommandLine) LIKE "*--target=1 *" OR TO_LOWER(CommandLine) LIKE "*/proc/1/ns*")) OR (TO_LOWER(CommandLine) LIKE "*release_agent*" OR TO_LOWER(CommandLine) LIKE "*notify_on_release*" OR TO_LOWER(CommandLine) LIKE "*/proc/sys/kernel/core_pattern*"))

Wazuh · XML rule

Deploy to your manager — this is a rule, not a search.

<group name="sigma,linux,">  <!-- Rule ids must be unique on your manager; 100000+ is the user range. -->  <!-- 2 rules: the Sigma condition ORs across different fields,       which one rule cannot express. Any one matching is a hit. -->  <rule id="100000" level="7">    <!-- Set <if_sid> to the decoder/base rule for linux so this only evaluates relevant events. -->    <field name="Image" type="pcre2">(?i)/nsenter$</field>    <field name="CommandLine" type="pcre2">(?i)(-t 1 |--target 1 |--target=1 |/proc/1/ns)</field>    <description>Container process entering the host namespaces (1/2)</description>    <mitre>      <id>T1611</id>    </mitre>  </rule>   <rule id="100001" level="7">    <!-- Set <if_sid> to the decoder/base rule for linux so this only evaluates relevant events. -->    <field name="CommandLine" type="pcre2">(?i)(release_agent|notify_on_release|/proc/sys/kernel/core_pattern)</field>    <description>Container process entering the host namespaces (2/2)</description>    <mitre>      <id>T1611</id>    </mitre>  </rule></group>

Sentinel · KQL

Run this as a search.

Sentinel cannot express this construct. No Sentinel table is modelled for this logsource ({"product":"linux","service":"sysmon"}), so there is nothing honest to query. Pick a logsource this translator maps, or write the KQL by hand. The Sigma source is on the first tab, unchanged.

At a glance

Logsource: sysmon / linux
Level: medium
Category: container_escape
Sigma status: experimental
Backends: 3 of 4 rendered
Updated: 30 Aug 2026
Rule ID: f27d0c3b-c763-4343-aa9f-c0f82a5907a6

ATT&CKT1611

T1611Escape to Host

ATT&CK® is a registered trademark of The MITRE Corporation. These mappings are the rule author’s, and are neither reviewed nor endorsed by MITRE.

Evidence

Verificationnone

Never run

The lab has not evaluated this composition. A run needs a dataset of its log type — a capture of the technique it claims, or the benign baseline — and not every rule has one. Some are also held back by the evaluator’s own safety limits.

Other compositions here have been run and some carry the badge — this one has not, so nothing about it has been shown either way. Read the rule and its noise check on their own terms; silence here is the absence of evidence, not evidence of a problem.

Noise checknot tested

No baseline event covers this rule’s log type (sysmon / linux), so the rule was never evaluated. This is missing data, not a clean result — nothing was checked either way.

Run live against 65 hand-written events of ordinary corporate activity — backup agents, software distribution, patching, helpdesk scripts, EDR. It says nothing about how often the rule would fire in production, which is the number that actually exhausts an analyst.

Test it yourselfin your browser

Runs here in your browser against public attack recordings. A preview — not the verification badge.

Recordings of T1611, evaluated against their — events.

Using it

Tuning & false positivesexperimental · 4 declared

experimental (current stage)
test
stable

Written and reasoned about, but not yet run against real telemetry. Expect to tune it before trusting it.

Tuning tips

MITRE supplies the SyscallWhitelist and TimeWindow knobs; the utility and
level: medium contradicts that first false positive. Split the arms: nsenter
Move arm 1 onto CommandLine|contains: 'nsenter'. It survives the busybox
Pin EventID: 1. The logsource carries no EventID, so the selections are

Declared by the author

Node-level agents on a Kubernetes cluster that enter the host namespaces on purpose. CSI drivers, CNI plugins, log shippers and monitoring DaemonSets routinely run nsenter -t 1 -m -u -i -n -p to read host state or mount volumes, and on a busy node this is the highest-volume match by a wide margin, recurring every time one of those pods is rescheduled.
Operators troubleshooting a node with kubectl debug node/... or a privileged docker run, both of which drop the user into the host mount and PID namespaces using the identical nsenter one-liner an operator would type.
Container runtime and cgroup-v1 housekeeping, where runc, systemd or a legacy container manager names release_agent or notify_on_release while creating or tearing down a cgroup hierarchy.
Crash-handler packages configuring core dumps at boot or on upgrade — ABRT, systemd-coredump and Apport post-install scripts write /proc/sys/kernel/core_pattern through sh -c or tee, which is exactly the visible form of that write.

Lessoncontainer escape

container escapeAI draft — unreviewed

01 · What this rule detects

AN0613 asks for containerised processes crossing into the host's namespaces — unshare/keyctl/mount/setns activity, or execution of host binaries from inside a container. The rule authors that as two independent arms on Sysmon for Linux process creation: an nsenter invocation naming PID 1 as its target, and a command line naming one of the three host files a privileged container writes to make the host kernel run a payload on its behalf.

02 · Telemetry you need

Sysmon for Linux, the analytic's second log source. No distribution installs it, so a host running stock auditd alone produces nothing here — and zero rows reads as quiet when it means blind. AN0613's other source, raw auditd, was deliberately not used: it records syscall numbers rather than names, splits arguments into positional a0/a1 fields instead of one command line, and does not watch unshare/setns/keyctl at all until someone hand-writes an audit rule. No default or baseline policy does.

03 · How the logic works

Direction is what the first arm buys. Host tooling entering a container targets that container's PID; a target of 1, or a /proc/1/ns path handed to setns, is a process reaching upward out of its own namespace set. The second arm needs no partner, because naming release_agent or core_pattern on a command line has essentially one meaning. Two reviewer findings are still open. Image|endswith: '/nsenter' is blind on minimal images: busybox ships nsenter as an applet (Image=/bin/busybox) and sh -c 'nsenter …' execs the shell, so the PID-1 half still matches while the AND kills the hit. The literal list also misses the attached short form -t1 and any argument ordering that leaves -t 1 at end of line, where the required trailing space fails.

04 · Common false positives

Loudly, and on the nsenter arm. Node-level DaemonSets — CSI drivers, CNI plugins, log shippers, monitoring — run nsenter -t 1 -m -u -i -n -p by design, and the rule's own first false positive calls this the highest-volume match by a wide margin, recurring on every pod reschedule. Operators running kubectl debug node/... type the identical one-liner. On the write arm, runc and systemd name release_agent while building or tearing down cgroup-v1 hierarchies, and ABRT, systemd-coredump and Apport post-install scripts write core_pattern through sh -c or tee — exactly the visible form of that write.

05 · Detection maturity

tier_1: **, the lowest tier, and it stays there until it has been run against real data. UNVERIFIED — derived from DET0219, never executed against a log line. Coverage is Linux-only: AN0614 (Windows containers, 4688 plus Sysmon EID 11 on restricted host directories) has no rule here. The structural blind spot is in-process escape — a program calling setns() or unshare() through libc, or a kernel exploit, creates no exec at all.
tier_2: means measuring DaemonSet volume on a real cluster and building the allowlist that measurement implies;
tier_3: means the correlation AN0613 actually describes.

Share this rule

/u/siemphony/f27d0c3b-c763-4343-aa9f-c0f82a5907a6

More from this repertoire

All compositions

Verdicts · reactions · comments

Community

Verdicts from engineers who actually deployed it, and the conversation around it.

Not yet reported on

Nobody has run this in a real environment and said what happened.

Verdicts from engineers who deployed it

0 cast

No verdicts reported yet. The first one is worth more than the tenth — say what you ran it against.

No comments yet. Someone who deploys this will have something to say about it.

Container process entering the host namespaces

The detection

detection.yml

Splunk · SPL

Elastic · ES|QL

Wazuh · XML rule

Sentinel · KQL

Community

Verdicts from engineers who deployed it