Interactive Privilege Boundary Enumeration Detected via Defend for Containers

  1[metadata]
  2creation_date = "2026/02/06"
  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/02/06"
  8
  9[rule]
 10author = ["Elastic"]
 11description = """
 12This rule detects the execution of the "id", "whoami", "capsh", "getcap", and "lsns" commands inside a container.
 13These commands are used to enumerate the privilege boundary of the container, which can be used by an adversary to
 14gain information about the container and the services running inside it.
 15"""
 16false_positives = [
 17    """
 18    There is a potential for false positives if the "id", "whoami", "capsh", "getcap", or "lsns" commands are used for legitimate purposes,
 19    such as debugging or troubleshooting. For example, an operator may use the "id" command to verify the identity of the current user, or
 20    the "whoami" command to verify the current user. It is important to investigate any alerts generated by this rule to determine if they
 21    are indicative of malicious activity or part of legitimate container activity.
 22    """,
 23]
 24from = "now-6m"
 25index = ["logs-cloud_defend.process*"]
 26interval = "5m"
 27language = "eql"
 28license = "Elastic License v2"
 29name = "Interactive Privilege Boundary Enumeration Detected via Defend for Containers"
 30note = """## Triage and analysis
 31
 32> **Disclaimer**:
 33> 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.
 34
 35### Investigating Interactive Privilege Boundary Enumeration Detected via Defend for Containers
 36
 37This detects an interactive session inside a Linux container running common identity and capability discovery tools (id, whoami, capsh, getcap, lsns) to map what privileges and namespace isolation the container actually has. This matters because attackers use this early in an intrusion to judge whether they can escalate within the container or pivot toward a host escape. A typical pattern is an attacker landing a shell through a vulnerable web service and immediately checking user context and Linux capabilities before attempting privilege abuse.
 38
 39### Possible investigation steps
 40
 41- Identify the impacted workload (pod/task/service), node, and cluster context, then correlate with Kubernetes audit logs or container runtime events to determine whether the interactive session originated from an operator action (e.g., exec) or an unexpected access path.  
 42- Review surrounding process activity from the same container to find follow-on commands indicating escalation or lateral movement attempts, such as spawning shells, modifying permissions, inspecting mounts, or downloading tooling.  
 43- Attribute the session to an identity by mapping the initiating user/service account and source to recent admin/CI activity, and flag anomalies like first-time access, unusual geolocation, or access outside change windows.  
 44- Evaluate escape and blast-radius risk by confirming the container’s effective privileges and isolation, including privileged mode, added capabilities, host namespace sharing, and sensitive host mounts or sockets.  
 45- If activity is suspicious, preserve evidence (processes, mounts, network connections, recent file changes) and consider isolating the pod/node or rotating credentials before remediation actions that would destroy artifacts.
 46
 47### False positive analysis
 48
 49- A platform engineer or developer attaches an interactive shell to a running container for routine troubleshooting and runs `id`/`whoami` to confirm the effective user and group context before making configuration changes.  
 50- During a planned hardening or validation task, an operator interactively inspects container capability and namespace settings using `capsh`/`getcap`/`lsns` to verify the workload is running with the intended privilege boundaries.
 51
 52### Response and remediation
 53
 54- Contain the incident by terminating the interactive session and quarantining the affected pod/container (or cordoning the node) while preserving container filesystem, running processes, mounts, and active network connections for evidence.  
 55- Eradicate by removing any unauthorized shells, binaries, or scripts dropped during the session, revoking/rotating credentials used to access the container (service account tokens, registry creds, app secrets), and rebuilding/redeploying the workload from a known-good image.  
 56- Recover by restoring the service with clean images and validated configuration, then verify no persistence remains by checking for unexpected running processes, modified entrypoints, altered file permissions, or new cron/systemd artifacts within the container image/build context.  
 57- Escalate to the incident response/on-call security team immediately if the container is privileged, has hostPath mounts or access to the container runtime socket, shares host namespaces, or if follow-on behavior appears (e.g., attempts to access `/proc/1`, `/var/run/docker.sock`, `nsenter`, or outbound downloads).  
 58- Harden by disabling or tightly restricting interactive exec/attach for production workloads, enforcing least-privilege securityContext (drop capabilities, runAsNonRoot, read-only root filesystem), and preventing host mounts/sockets via admission controls and policy (Pod Security Admission/Gatekeeper/Kyverno).  
 59- Improve detection and prevention by alerting on interactive shells and suspicious tooling in containers, adding egress allowlists to limit tool download/pivoting, and ensuring audit logging is enabled for Kubernetes exec events and container runtime actions."""
 60risk_score = 21
 61rule_id = "737626a2-4dca-4195-8ecd-68ef96fd1bad"
 62severity = "low"
 63tags = [
 64    "Data Source: Elastic Defend for Containers",
 65    "Domain: Container",
 66    "OS: Linux",
 67    "Use Case: Threat Detection",
 68    "Tactic: Discovery",
 69    "Resources: Investigation Guide",
 70]
 71timestamp_override = "event.ingested"
 72type = "eql"
 73query = '''
 74process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and process.interactive == true and (
 75  (process.name in ("id", "whoami", "capsh", "getcap", "lsns")) or
 76  (process.args in (
 77     "id", "/bin/id", "/usr/bin/id", "/usr/local/bin/id",
 78     "whoami", "/bin/whoami", "/usr/bin/whoami", "/usr/local/bin/whoami",
 79     "capsh", "/bin/capsh", "/usr/bin/capsh", "/usr/local/bin/capsh",
 80     "getcap", "/bin/getcap", "/usr/bin/getcap", "/usr/local/bin/getcap",
 81     "lsns", "/bin/lsns", "/usr/bin/lsns", "/usr/local/bin/lsns"
 82   ) and
 83    /* default exclusion list to not FP on default multi-process commands */
 84    not process.args in (
 85      "man", "/bin/man", "/usr/bin/man", "/usr/local/bin/man",
 86      "chmod", "/bin/chmod", "/usr/bin/chmod", "/usr/local/bin/chmod",
 87      "chown", "/bin/chown", "/usr/bin/chown", "/usr/local/bin/chown"
 88    )
 89  )
 90) and container.id like "?*"
 91'''
 92
 93[[rule.threat]]
 94framework = "MITRE ATT&CK"
 95
 96[[rule.threat.technique]]
 97id = "T1613"
 98name = "Container and Resource Discovery"
 99reference = "https://attack.mitre.org/techniques/T1613/"
100
101[[rule.threat.technique]]
102id = "T1082"
103name = "System Information Discovery"
104reference = "https://attack.mitre.org/techniques/T1082/"
105
106[rule.threat.tactic]
107id = "TA0007"
108name = "Discovery"
109reference = "https://attack.mitre.org/tactics/TA0007/"