Service Account Token or Certificate Access Followed by Kubernetes API Request

ELASTIC detection rule by Elastic · Elastic License v2

This rule leverages a combination of Defend for Containers and Kubernetes audit logs to detect the access to the service account token or certificate followed by the execution of a direct interactive Kubernetes API request. An adversary may need to access the service account token or certificate to gain access to the Kubernetes API server or other resources within the cluster. These requests are often used to enumerate the Kubernetes API server or other resources within the cluster, and may indicate an attempt to move laterally within the cluster.

[metadata]
creation_date = "2026/01/21"
integration = ["cloud_defend", "kubernetes"]
maturity = "production"
min_stack_comments = "Defend for Containers integration was re-introduced in 9.3.0"
min_stack_version = "9.3.0"
updated_date = "2026/04/10"

[rule]
author = ["Elastic"]
description = """
This rule leverages a combination of Defend for Containers and Kubernetes audit logs to detect the access to the service
account token or certificate followed by the execution of a direct interactive Kubernetes API request. An adversary may
need to access the service account token or certificate to gain access to the Kubernetes API server or other resources
within the cluster. These requests are often used to enumerate the Kubernetes API server or other resources within the
cluster, and may indicate an attempt to move laterally within the cluster.
"""
false_positives = [
    """
    There is a potential for false positives if the access to the service account token or certificate is used for legitimate purposes,
    such as debugging or troubleshooting. It is important to investigate any alerts generated by this rule to determine
    if they are indicative of malicious activity or part of legitimate container activity.
    """,
    """
    There is a risk of false positives if there are several containers named the same, as the rule may correlate the request
    to the wrong container.
    """,
]
from = "now-6m"
index = ["logs-cloud_defend.file*", "logs-kubernetes.audit_logs-*"]
interval = "5m"
language = "eql"
license = "Elastic License v2"
name = "Service Account Token or Certificate Access Followed by Kubernetes API Request"
note = """ ## Triage and analysis

> **Disclaimer**:
> 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.

### Investigating Service Account Token or Certificate Access Followed by Kubernetes API Request

This rule correlates interactive access to a pod’s service account token or CA certificate with a near-immediate Kubernetes API request, signaling credential harvesting to query the cluster and potential lateral movement. An attacker execs into a container, reads /var/run/secrets/kubernetes.io/serviceaccount/token and ca.crt, then uses curl or kubectl with that token and CA to list pods, get secrets, or create a privileged pod to pivot across nodes.

### Possible investigation steps

- Attribute the activity by identifying the pod, container image, node, and interactive session initiator (e.g., kubectl exec) from Kubernetes events and cluster logs to determine whether a human or automation accessed the credentials.
- Retrieve the pod’s service account and enumerate its RBAC bindings to assess effective privileges, highlighting any ability to read secrets, create pods, or modify roles.
- Reconstruct the full sequence of audit log requests tied to that pod/user around the alert, noting resources, verbs, namespaces, response codes, and userAgent to distinguish legitimate controller behavior from reconnaissance.
- Examine the container for signs of token abuse or exfiltration by reviewing shell history and filesystem artifacts, and correlate with network egress from the pod to external destinations.
- Validate that the API request originated from the same pod by matching source IP, node, and TLS client identity, and check for concurrent suspicious activity on the node or other pods.

### False positive analysis

- A cluster operator troubleshooting an issue execs into a pod, inspects the service account token or CA certificate, and then uses the pod’s credentials to make a quick Kubernetes API request to verify permissions or list resources.
- A workload running with TTY/stdin enabled is marked as interactive, and the application legitimately reads the service account token (e.g., on startup or token refresh) to perform routine API operations such as leader election or informer watches, producing the observed file access followed by audit log activity.

### Response and remediation

- Immediately isolate the pod that read /var/run/secrets/kubernetes.io/serviceaccount/token or ca.crt by deleting the pod or scaling its deployment to zero, cordoning its node if similar behavior is seen on other pods, and applying a NetworkPolicy that blocks the pod’s access to the API server while you capture its filesystem.
- Revoke access by removing the implicated service account’s RBAC bindings, recreating the service account to invalidate tokens, restarting any workloads that mount /var/run/secrets/kubernetes.io/serviceaccount, and rotating the service-account signing key if compromise is suspected.
- Validate and recover by reviewing audit records for unauthorized actions (e.g., secrets reads, pod or role changes), rolling back or deleting any malicious resources, and redeploying affected workloads from trusted images with signed releases.
- Escalate to incident response immediately if you observe API requests from the pod that read secrets, create pods in other namespaces, alter Role or ClusterRoleBindings, or transmit the token/ca.crt via curl or similar tooling to external addresses.
- Harden by disabling automountServiceAccountToken on pods that don't require it, scoping service accounts to a single namespace with least‑privilege RBAC, enforcing Pod Security Admission to block privileged/interactive shells, and restricting exec/attach via RBAC or admission policies.
"""
risk_score = 47
rule_id = "4bd306f9-ee89-4083-91af-e61ed5c42b9a"
severity = "medium"
tags = [
    "Data Source: Elastic Defend for Containers",
    "Data Source: Kubernetes",
    "Domain: Container",
    "Domain: Kubernetes",
    "OS: Linux",
    "Use Case: Threat Detection",
    "Tactic: Execution",
    "Tactic: Credential Access",
    "Tactic: Discovery",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"
query = '''
sequence with maxspan=60s
  [file where host.os.type == "linux" and event.type == "change" and event.action == "open" and
   file.path in ("/var/run/secrets/kubernetes.io/serviceaccount/token", "/var/run/secrets/kubernetes.io/serviceaccount/ca.crt") and
   process.interactive == true and container.id like "*"] by orchestrator.resource.name
  [any where data_stream.dataset == "kubernetes.audit_logs" and kubernetes.audit.stage in ("ResponseComplete", "ResponseStarted")] by `kubernetes.audit.user.extra.authentication.kubernetes.io/pod-name`
'''

[[rule.threat]]
framework = "MITRE ATT&CK"

[[rule.threat.technique]]
id = "T1059"
name = "Command and Scripting Interpreter"
reference = "https://attack.mitre.org/techniques/T1059/"

[[rule.threat.technique.subtechnique]]
id = "T1059.004"
name = "Unix Shell"
reference = "https://attack.mitre.org/techniques/T1059/004/"

[rule.threat.tactic]
id = "TA0002"
name = "Execution"
reference = "https://attack.mitre.org/tactics/TA0002/"

[[rule.threat]]
framework = "MITRE ATT&CK"

[[rule.threat.technique]]
id = "T1528"
name = "Steal Application Access Token"
reference = "https://attack.mitre.org/techniques/T1528/"

[[rule.threat.technique]]
id = "T1552"
name = "Unsecured Credentials"
reference = "https://attack.mitre.org/techniques/T1552/"

[[rule.threat.technique.subtechnique]]
id = "T1552.001"
name = "Credentials In Files"
reference = "https://attack.mitre.org/techniques/T1552/001/"

[rule.threat.tactic]
id = "TA0006"
name = "Credential Access"
reference = "https://attack.mitre.org/tactics/TA0006/"

[[rule.threat]]
framework = "MITRE ATT&CK"

[[rule.threat.technique]]
id = "T1613"
name = "Container and Resource Discovery"
reference = "https://attack.mitre.org/techniques/T1613/"

[rule.threat.tactic]
id = "TA0007"
name = "Discovery"
reference = "https://attack.mitre.org/tactics/TA0007/"

[[rule.threat]]
framework = "MITRE ATT&CK"

[[rule.threat.technique]]
id = "T1550"
name = "Use Alternate Authentication Material"
reference = "https://attack.mitre.org/techniques/T1550/"

[[rule.threat.technique.subtechnique]]
id = "T1550.001"
name = "Application Access Token"
reference = "https://attack.mitre.org/techniques/T1550/001/"

[rule.threat.tactic]
id = "TA0008"
name = "Lateral Movement"
reference = "https://attack.mitre.org/tactics/TA0008/"

[[ currentRule.title && currentRule.title.length > 60 ? currentRule.title.slice(0, 60) + '…' : currentRule.title ]]

0ee15d02-e1f8-4874-b250-b283b9e899f4

Propose edits, view related rules, and engage with the community through comments.

Executable code, not a declarative rule

This submission is arbitrary [[ currentRule.format ? currentRule.format.toUpperCase() : '' ]] code, not a declarative detection rule — review it as you would any script before running it, and note that it cannot be safely aggregated or auto-executed alongside YARA/Sigma/Suricata/CRS rules.

Rejected pattern present

[[ reason ]]

What does this mean?

Format & documentation suggestions

Not a security issue — this rule is valid and was accepted as-is. These are optional fields/conventions its own format recommends, mainly affecting its quality score and how well it documents itself for other reviewers.

[[ reason ]]

What do these messages mean?

[[ currentRule.title && currentRule.title.length > 60 ? currentRule.title.slice(0, 60) + '…' : currentRule.title ]]

[[ currentRule.title ]]

Community Discussion