Nsenter to PID Namespace via Auditd
Detects nsenter executions that target PID with a namespace target flag, a pattern commonly used to attach to the host init namespace from a container or session and run with host context.
Elastic rule (View on GitHub)
1[metadata]
2creation_date = "2026/04/27"
3integration = ["auditd_manager"]
4maturity = "production"
5updated_date = "2026/04/27"
6
7[rule]
8author = ["Elastic"]
9description = """
10Detects nsenter executions that target PID with a namespace target flag, a pattern commonly used to attach to the
11host init namespace from a container or session and run with host context.
12"""
13false_positives = [
14 """
15 Platform engineers may nsenter into PID 1 namespaces during deep node debugging; correlate with tickets and bastion
16 sessions before escalating.
17 """,
18]
19from = "now-9m"
20index = ["auditbeat-*", "logs-auditd_manager.auditd-*"]
21language = "kuery"
22license = "Elastic License v2"
23name = "Nsenter to PID Namespace via Auditd"
24note = """## Triage and analysis
25
26### Investigating Nsenter to PID Namespace via Auditd
27
28Review process.args for the full nsenter invocation (target PID, mount, UTS, IPC, net, user namespaces), parent process,
29user identity, and host. PID targeting is a strong escape or host-administration signal when unexpected for the actor.
30
31### Possible investigation steps
32
33- Confirm whether the session originated from a container, SSH session, or automation agent.
34- Pivot on the same host for subsequent writes under /etc, docker.sock access, or new systemd units.
35
36### False positive analysis
37
38- Some CNI or snap workflows can resemble nsenter; rely on the built-in exclusions first, then tune by parent command
39 or service account.
40
41### Response and remediation
42
43- If malicious, isolate the host, revoke credentials, inspect for persistence, and re-image if integrity cannot be proven.
44"""
45references = [
46 "https://attack.mitre.org/techniques/T1611/",
47 "https://man7.org/linux/man-pages/man1/nsenter.1.html",
48]
49risk_score = 73
50rule_id = "75f9b95f-370b-4ff3-a84c-66d9ec0b84eb"
51setup = """## Setup
52
53Deploy the Auditd Manager integration on Linux hosts that should emit process execution telemetry (Fleet, Integrations,
54Auditd Manager, attach to an agent policy).
55
56Ensure syscall rules capture execve for utilities such as nsenter so event.category process and event.action executed
57populate with process.name and process.args.
58
59See https://docs.elastic.co/integrations/auditd_manager for integration details.
60"""
61severity = "high"
62tags = [
63 "Domain: Endpoint",
64 "Domain: Container",
65 "OS: Linux",
66 "Use Case: Threat Detection",
67 "Tactic: Privilege Escalation",
68 "Data Source: Auditd Manager",
69 "Resources: Investigation Guide",
70]
71timestamp_override = "event.ingested"
72type = "query"
73query = '''
74host.os.type:linux and
75event.category:process and event.action:(executed or exec) and
76(process.name:nsenter or process.args:nsenter) and
77process.args:((--target* or -t) and not --net=/run/netns/* and not (--assertion and snap) and not (is-active and snap.*))
78'''
79
80[[rule.threat]]
81framework = "MITRE ATT&CK"
82
83[[rule.threat.technique]]
84id = "T1611"
85name = "Escape to Host"
86reference = "https://attack.mitre.org/techniques/T1611/"
87
88[rule.threat.tactic]
89id = "TA0004"
90name = "Privilege Escalation"
91reference = "https://attack.mitre.org/tactics/TA0004/"
Triage and analysis
Investigating Nsenter to PID Namespace via Auditd
Review process.args for the full nsenter invocation (target PID, mount, UTS, IPC, net, user namespaces), parent process, user identity, and host. PID targeting is a strong escape or host-administration signal when unexpected for the actor.
Possible investigation steps
- Confirm whether the session originated from a container, SSH session, or automation agent.
- Pivot on the same host for subsequent writes under /etc, docker.sock access, or new systemd units.
False positive analysis
- Some CNI or snap workflows can resemble nsenter; rely on the built-in exclusions first, then tune by parent command or service account.
Response and remediation
- If malicious, isolate the host, revoke credentials, inspect for persistence, and re-image if integrity cannot be proven.
References
Related rules
- Chroot Execution in Container Context on Linux
- Unusual Process Connection to Docker or Containerd Socket
- Pod or Container Creation with Suspicious Command-Line
- Potential Chroot Container Escape via Mount
- Namespace Manipulation Using Unshare