Service Account Namespace Read Detected via Defend for Containers

  1[metadata]
  2creation_date = "2026/01/21"
  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 reading of the service account namespace file inside a container. The service account namespace file
 13is used to identify the namespace of the container in which it is running, and may be used by an adversary to get a better
 14understanding of the container and the services running inside it.
 15"""
 16false_positives = [
 17    """
 18    There is a potential for false positives if the reading of the service account namespace file is used for legitimate purposes,
 19    such as debugging or troubleshooting. It is important to investigate any alerts generated by this rule to determine
 20    if they are indicative of malicious activity or part of legitimate container activity.
 21    """,
 22]
 23from = "now-6m"
 24index = ["logs-cloud_defend.file*", "logs-cloud_defend.process*"]
 25interval = "5m"
 26language = "eql"
 27license = "Elastic License v2"
 28name = "Service Account Namespace Read Detected via Defend for Containers"
 29note = """ ## Triage and analysis
 30
 31> **Disclaimer**:
 32> 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.
 33
 34### Investigating Service Account Namespace Read Detected via Defend for Containers
 35
 36This rule flags an interactive process inside a container opening /var/run/secrets/kubernetes.io/serviceaccount/namespace, which reveals the pod’s Kubernetes namespace; adversaries use this quick check to orient themselves and scope discovery. A common pattern is: after landing a shell in a pod, the attacker reads the namespace file, then issues namespace-scoped kubectl or direct API calls to list Deployments, Secrets, and ServiceAccounts, map privileges and service endpoints, and plan targeted lateral movement within that namespace.
 37
 38### Possible investigation steps
 39
 40- Build the process tree and shell session timeline around the event to identify the parent and child processes, interactive TTY, and exact commands executed before and after.
 41- Map the container to its pod, namespace, node, image, owner, and service account, and verify whether any kubectl exec/attach or debug container activity targeting this pod is expected at that time.
 42- Correlate Kubernetes audit logs for that service account and pod around the timestamp to spot list/get calls, Secrets or ServiceAccounts enumeration, and the user/IP that initiated any exec/attach.
 43- Inspect network flows and DNS from the container to the Kubernetes API server immediately after the event to confirm follow-on API access or token validation attempts.
 44- Review the service account’s RBAC bindings and search the container for reads of the token/ca.crt or the presence of kubectl/kubeconfig or scripts that could leverage the token.
 45
 46### False positive analysis
 47
 48- During legitimate troubleshooting, a user opens an interactive shell in the container and the shell’s profile or prompt customization reads /var/run/secrets/kubernetes.io/serviceaccount/namespace to display the current namespace.
 49- A documented operational check or training exercise instructs staff to manually open the service account namespace file inside a container to confirm the environment before changes, producing a benign detection.
 50
 51### Response and remediation
 52
 53- Immediately kill the interactive shell process inside the container (e.g., bash/sh attached via kubectl exec) and quarantine the pod/namespace by applying a deny-all NetworkPolicy and pausing the owning Deployment/StatefulSet.
 54- Escalate to a major incident and page the on-call cluster security team if you observe subsequent reads of /var/run/secrets/kubernetes.io/serviceaccount/token or ca.crt or API calls from the pod to the Kubernetes API (443) that list Secrets or ServiceAccounts.
 55- Rotate the service account credentials by deleting the pod to force a new projected token, set automountServiceAccountToken: false on the workload if not needed, and remove pods/exec and pods/attach privileges from users or roles that accessed this pod.
 56- Redeploy the workload from a trusted, signed image without embedded shells/kubectl, verify image digest on rollout, and only lift quarantine after confirming no unauthorized containers, cronjobs, or startup scripts were added.
 57- Enforce least-privilege RBAC for the service account (deny list/get on Secrets, ConfigMaps, and Pods in the namespace), enable Pod Security Admission restricted with readOnlyRootFilesystem and dropped Linux capabilities, and require approvals for kubectl exec using ephemeral containers for debugging.
 58"""
 59risk_score = 21
 60rule_id = "f7c64a1b-9d00-4b92-9042-d3bb4196899a"
 61severity = "low"
 62tags = [
 63    "Data Source: Elastic Defend for Containers",
 64    "Domain: Container",
 65    "OS: Linux",
 66    "Use Case: Threat Detection",
 67    "Tactic: Discovery",
 68    "Resources: Investigation Guide",
 69]
 70timestamp_override = "event.ingested"
 71type = "eql"
 72query = '''
 73any where host.os.type == "linux" and process.interactive == true and container.id like "*" and (
 74  (event.category == "file" and event.type == "change" and event.action == "open" and
 75  file.path in (
 76    "/var/run/secrets/kubernetes.io/serviceaccount/namespace",
 77    "/run/secrets/kubernetes.io/serviceaccount/namespace"
 78  )) or
 79  (event.category == "process" and event.type == "start" and event.action == "exec" and
 80  (
 81    process.name in ("cat", "head", "tail", "more", "less", "sed", "awk") or
 82    process.args in (
 83      "cat", "/bin/cat", "/usr/bin/cat", "/usr/local/bin/cat",
 84      "head", "/bin/head", "/usr/bin/head", "/usr/local/bin/head",
 85      "tail", "/bin/tail", "/usr/bin/tail", "/usr/local/bin/tail",
 86      "more", "/bin/more", "/usr/bin/more", "/usr/local/bin/more",
 87      "less", "/bin/less", "/usr/bin/less", "/usr/local/bin/less",
 88      "sed", "/bin/sed", "/usr/bin/sed", "/usr/local/bin/sed",
 89      "awk", "/bin/awk", "/usr/bin/awk", "/usr/local/bin/awk"
 90    )
 91  ) and process.args like "*/run/secrets/kubernetes.io/serviceaccount/namespace*"
 92    )
 93)
 94'''
 95
 96[[rule.threat]]
 97framework = "MITRE ATT&CK"
 98
 99[[rule.threat.technique]]
100id = "T1613"
101name = "Container and Resource Discovery"
102reference = "https://attack.mitre.org/techniques/T1613/"
103
104[[rule.threat.technique]]
105id = "T1082"
106name = "System Information Discovery"
107reference = "https://attack.mitre.org/techniques/T1082/"
108
109[rule.threat.tactic]
110id = "TA0007"
111name = "Discovery"
112reference = "https://attack.mitre.org/tactics/TA0007/"