Nsenter Execution with Target Flag Inside Container

 1[metadata]
 2creation_date = "2026/03/31"
 3integration = ["cloud_defend"]
 4maturity = "production"
 5min_stack_comments = "Defend for Containers integration was re-introduced in 9.3.0"
 6min_stack_version = "9.3.0"
 7updated_date = "2026/03/31"
 8
 9[rule]
10author = ["Elastic"]
11description = """
12Detects nsenter executions from inside a monitored Linux container that include a namespace target flag (-t or
13--target). Adversaries abuse nsenter to attach to host or sibling namespaces and escape container isolation when
14combined with privileged mounts, exposed PIDs, or shared namespaces.
15"""
16from = "now-6m"
17index = ["logs-cloud_defend.process*"]
18interval = "5m"
19language = "eql"
20license = "Elastic License v2"
21name = "Nsenter Execution with Target Flag Inside Container"
22note = """## Triage and analysis
23
24> **Disclaimer**:
25> 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.
26
27### Investigating Nsenter Execution with Target Flag Inside Container
28
29This alert flags `nsenter` (by process name or as a process argument) launched from a workload with a non-empty
30`container.id`, with `-t` or `--target` present on the command line. That pattern is consistent with entering another
31process or namespace context and is a common building block for container escape and host pivoting when prerequisites
32such as host PID mounts or excessive capabilities exist.
33
34### Possible investigation steps
35
36- Review the full command line and parent process to see which PID or path was passed to `-t` / `--target`, and whether
37  additional flags such as `-m`, `-n`, `-p`, `-U`, or `-i` indicate mount, network, PID, user, or IPC namespace joins.
38- Map the container image, pod, namespace, and node; confirm whether the workload should ever invoke nsenter or share
39  namespaces with the host.
40- Correlate with file, network, and authentication telemetry from the same container for follow-on access to the
41  container runtime socket, kubelet paths, SSH material, or cloud instance metadata.
42
43### False positive analysis
44
45- Some troubleshooting images or platform agents may wrap nsenter for diagnostics; verify image provenance, scheduled
46  maintenance, and approved break-glass procedures before treating as malicious.
47
48### Response and remediation
49
50- If the activity is unauthorized, isolate the pod or node, preserve runtime artifacts, rotate any credentials exposed to
51  the container, and re-image or replace the node when host integrity is in doubt.
52- Reduce recurrence by enforcing least privilege, avoiding host namespace sharing, restricting hostPath and sensitive
53  mounts, and blocking unnecessary capabilities.
54"""
55references = [
56    "https://attack.mitre.org/techniques/T1611/",
57    "https://man7.org/linux/man-pages/man1/nsenter.1.html",
58]
59risk_score = 73
60rule_id = "39029450-8e2d-4034-81b0-15af8e4e3a4e"
61severity = "high"
62tags = [
63    "Data Source: Elastic Defend for Containers",
64    "Domain: Container",
65    "OS: Linux",
66    "Use Case: Threat Detection",
67    "Tactic: Privilege Escalation",
68    "Resources: Investigation Guide",
69]
70timestamp_override = "event.ingested"
71type = "eql"
72query = '''
73process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and
74  (process.name == "nsenter" or process.args == "nsenter") and
75  container.id like "?*" and process.args like ("-t", "--target*")
76'''
77
78[[rule.threat]]
79framework = "MITRE ATT&CK"
80
81[[rule.threat.technique]]
82id = "T1611"
83name = "Escape to Host"
84reference = "https://attack.mitre.org/techniques/T1611/"
85
86[rule.threat.tactic]
87id = "TA0004"
88name = "Privilege Escalation"
89reference = "https://attack.mitre.org/tactics/TA0004/"