Service Account Token or Certificate 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 token or certificate inside a container. The service account
 13token or certificate is used to authenticate the container to the Kubernetes API server, and may be used by an
 14adversary to gain access to the Kubernetes API server or other resources within the cluster. These files are a
 15common target for adversaries to gain access to the cluster.
 16"""
 17false_positives = [
 18    """
 19    There is a potential for false positives if the service account token or certificate is used for legitimate purposes,
 20    such as debugging or troubleshooting. It is important to investigate any alerts generated by this rule to determine
 21    if they are indicative of malicious activity or part of legitimate container activity.
 22    """,
 23]
 24from = "now-6m"
 25index = ["logs-cloud_defend.file*", "logs-cloud_defend.process*"]
 26interval = "5m"
 27language = "eql"
 28license = "Elastic License v2"
 29name = "Service Account Token or Certificate Read 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 Service Account Token or Certificate Read Detected via Defend for Containers
 36
 37This rule flags when a container’s service account token or CA certificate is opened interactively, signaling direct access to credentials that grant API permissions within the cluster. Attackers often exec into a running pod, read /var/run/secrets/kubernetes.io/serviceaccount/token and ca.crt, then use the token with kubectl or curl to enumerate namespaces, list secrets, or spawn privileged workloads via the Kubernetes API.
 38
 39### Possible investigation steps
 40
 41- Map the container to its pod, namespace, node, image, and service account, and use Kubernetes audit and runtime logs to identify any recent exec/attach/tty into the pod and the originating user and source IP.
 42- Examine process ancestry and command activity around the event to detect shells, kubectl/curl/wget usage, token exfiltration patterns (for example, piping the token to a network client), or the token being copied elsewhere.
 43- Correlate with network telemetry to see if the container initiated connections to the API server or external endpoints immediately after the read, including unusual DNS lookups or spikes in egress.
 44- Search Kubernetes audit logs for requests authenticated as the implicated service account after the event, prioritizing secrets access, pod exec/attach, workload create/update, and role or clusterrole binding changes, and verify the source IP matches the pod.
 45- Run a SubjectAccessReview or review RBAC bindings for the service account to quickly determine effective permissions and the potential blast radius if the token was abused.
 46
 47### False positive analysis
 48
 49- During legitimate troubleshooting, an engineer attaches an interactive shell to the container and opens /var/run/secrets/kubernetes.io/serviceaccount/token or /var/run/secrets/kubernetes.io/serviceaccount/ca.crt to verify the service account mount and certificate trust.
 50- An interactive in-container diagnostic or training session reads the token or CA certificate to confirm connectivity or inspect claims, with no subsequent API calls or credential exfiltration, resulting in a benign open event.
 51
 52### Response and remediation
 53
 54- Immediately delete the affected pod (namespace/pod-name) to invalidate /var/run/secrets/kubernetes.io/serviceaccount/token, scale the owning Deployment/StatefulSet to zero to stop respawns, and apply a temporary deny-all egress NetworkPolicy to the namespace to contain any misuse.
 55- On the node hosting the pod, kill any interactive shells (e.g., bash or sh) attached to the container and remove any copied credential artifacts such as /tmp/token or files containing contents of /var/run/secrets/kubernetes.io/serviceaccount/token or ca.crt.
 56- Rotate credentials and access by recreating the service account and its tokens, purge unauthorized RoleBinding/ClusterRoleBinding entries granting high privileges to that identity, and redeploy the workload from a trusted image with a clean start.
 57- Escalate to incident response if audit logs show the token being used to read Secrets, create or modify Pods/Jobs/Deployments, or alter RoleBinding/ClusterRoleBinding, or if API requests originate from an IP not matching the affected pod’s node.
 58- Harden by setting automountServiceAccountToken: false for pods that do not need API access, using projected service account tokens with short TTL and audience binding, denying kubectl exec/attach in production via RBAC/admission, and trimming the service account’s RBAC to least privilege.
 59"""
 60risk_score = 47
 61rule_id = "66229f32-c460-410d-bc37-4b32322cd4bb"
 62severity = "medium"
 63tags = [
 64    "Data Source: Elastic Defend for Containers",
 65    "Domain: Container",
 66    "OS: Linux",
 67    "Use Case: Threat Detection",
 68    "Tactic: Credential Access",
 69    "Resources: Investigation Guide",
 70]
 71timestamp_override = "event.ingested"
 72type = "eql"
 73query = '''
 74any where host.os.type == "linux" and process.interactive == true and container.id like "*" and (
 75  (event.category == "file" and event.type == "change" and event.action == "open" and
 76  file.path in (
 77    "/var/run/secrets/kubernetes.io/serviceaccount/token",
 78    "/var/run/secrets/kubernetes.io/serviceaccount/ca.crt",
 79    "/run/secrets/kubernetes.io/serviceaccount/token",
 80    "/run/secrets/kubernetes.io/serviceaccount/ca.crt"
 81  )) or
 82  (event.category == "process" and event.type == "start" and event.action == "exec" and
 83  (
 84    process.name in ("cat", "head", "tail", "more", "less", "sed", "awk") or
 85    process.args in (
 86      "cat", "/bin/cat", "/usr/bin/cat", "/usr/local/bin/cat",
 87      "head", "/bin/head", "/usr/bin/head", "/usr/local/bin/head",
 88      "tail", "/bin/tail", "/usr/bin/tail", "/usr/local/bin/tail",
 89      "more", "/bin/more", "/usr/bin/more", "/usr/local/bin/more",
 90      "less", "/bin/less", "/usr/bin/less", "/usr/local/bin/less",
 91      "sed", "/bin/sed", "/usr/bin/sed", "/usr/local/bin/sed",
 92      "awk", "/bin/awk", "/usr/bin/awk", "/usr/local/bin/awk"
 93    )
 94  ) and process.args like (
 95    "*/run/secrets/kubernetes.io/serviceaccount/token*",
 96    "*/run/secrets/kubernetes.io/serviceaccount/ca.crt*"
 97  ))
 98)
 99'''
100
101[[rule.threat]]
102framework = "MITRE ATT&CK"
103
104[[rule.threat.technique]]
105id = "T1552"
106name = "Unsecured Credentials"
107reference = "https://attack.mitre.org/techniques/T1552/"
108
109[[rule.threat.technique.subtechnique]]
110id = "T1552.001"
111name = "Credentials In Files"
112reference = "https://attack.mitre.org/techniques/T1552/001/"
113
114[rule.threat.tactic]
115id = "TA0006"
116name = "Credential Access"
117reference = "https://attack.mitre.org/tactics/TA0006/"