{"description":"Trending threats, MITRE ATT\u0026CK coverage, and detection metadata. Fed continuously.","favicon":"https://feed.craftedsignal.io/favicon-32x32.png","feed_url":"https://feed.craftedsignal.io/products/kubernetes-all-versions/feed.json","home_page_url":"https://feed.craftedsignal.io/","icon":"https://feed.craftedsignal.io/apple-touch-icon.png","items":[{"_cs_actors":[],"_cs_cpes":[],"_cs_cves":[],"_cs_exploited":false,"_cs_has_poc":false,"_cs_poc_references":[],"_cs_products":["Kubernetes (all versions)","Kubernetes"],"_cs_severities":["medium"],"_cs_tags":["execution","discovery","kubernetes","cloud-native","container-security","container","threat-detection"],"_cs_type":"advisory","_cs_vendors":["Kubernetes"],"content_html":"\u003cp\u003eThis detection pattern identifies unauthorized interactive access attempts within a Kubernetes cluster. When an attacker gains access to a container, they often utilize shell environments to perform discovery and lateral movement. By leveraging utilities such as kubectl, curl, or openssl, attackers attempt to communicate with the Kubernetes API server to enumerate resources, probe for secrets, or test service account privileges. Because these actions are often performed by under-privileged accounts or against sensitive endpoints, they result in 'forbid' decisions within the Kubernetes audit logs. This rule provides a mechanism for detection engineers to correlate the specific interactive shell activity within a container with these denied API requests, identifying potential hands-on-keyboard probing even when the attacker lacks the necessary permissions to succeed. This visibility is critical for identifying compromised workloads that are being repurposed for cluster-level discovery.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAttacker gains initial access to a container process (e.g., via web application exploit).\u003c/li\u003e\n\u003cli\u003eAttacker executes an interactive shell (e.g., /bin/bash or /bin/sh) within the container.\u003c/li\u003e\n\u003cli\u003eAttacker identifies native tooling within the container (e.g., kubectl, curl, openssl) or drops malicious binaries.\u003c/li\u003e\n\u003cli\u003eAttacker uses the container's mounted ServiceAccount token to initiate an API request to the Kubernetes API server.\u003c/li\u003e\n\u003cli\u003eAPI request is sent from the pod to the API server endpoint (e.g., \u003ca href=\"https://kubernetes.default.svc\"\u003ehttps://kubernetes.default.svc\u003c/a\u003e).\u003c/li\u003e\n\u003cli\u003eKubernetes authorization policy evaluates the request and returns an HTTP 403 Forbidden status.\u003c/li\u003e\n\u003cli\u003eAudit logs record the forbidden action associated with the specific pod identity.\u003c/li\u003e\n\u003cli\u003eSecurity monitoring platform correlates the local shell activity with the denied API audit log.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful unauthorized discovery can provide an attacker with a map of the cluster's network, services, and secrets. If the attacker successfully leverages an over-privileged service account, they may escalate privileges or pivot to other nodes within the cluster. This activity indicates a breakdown in container isolation and least-privilege RBAC.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eEnable Kubernetes Audit Logging and stream to the SIEM to support the audit correlation logic described in this brief.\u003c/li\u003e\n\u003cli\u003eDeploy the EQL detection logic to identify unauthorized interactive attempts originating from pods.\u003c/li\u003e\n\u003cli\u003eImplement NetworkPolicies that restrict egress from non-admin containers to the Kubernetes API server IP addresses.\u003c/li\u003e\n\u003cli\u003ePerform regular audits of ServiceAccount permissions, ensuring pods only possess the minimal RBAC roles required for their function.\u003c/li\u003e\n\u003cli\u003eRebuild container images to exclude administrative tooling (kubectl, curl, nmap, socat) where such functionality is not required for application operation.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-09-19T13:12:57Z","date_published":"2026-09-18T19:15:00Z","id":"https://feed.craftedsignal.io/briefs/2026-09-forbidden-k8s-api-access/","summary":"Adversaries performing hands-on-keyboard enumeration within compromised containers are detected by correlating interactive process execution with forbidden Kubernetes API audit responses.","title":"Detection of Unauthorized Interactive Kubernetes API Probing","url":"https://feed.craftedsignal.io/briefs/2026-09-forbidden-k8s-api-access/"},{"_cs_actors":[],"_cs_cpes":[],"_cs_cves":[],"_cs_exploited":false,"_cs_has_poc":false,"_cs_poc_references":[],"_cs_products":["Kubernetes (all versions)"],"_cs_severities":["medium"],"_cs_tags":["kubernetes","container-security","discovery","execution","cloud"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eThis threat involves adversaries who have gained initial access to a containerized environment attempting to escalate privileges or perform reconnaissance by interacting directly with the Kubernetes API server. Attackers leverage existing containerized utilities such as 'curl', 'wget', 'kubectl', 'socat', or 'ncat' to perform 'hands-on-keyboard' discovery. By compromising a pod, an attacker can access the mounted Kubernetes service account token located at '/var/run/secrets/kubernetes.io/serviceaccount/token'. Using this token, they perform direct HTTP(S) requests to the Kubernetes API server to enumerate pods, secrets, and cluster-scoped RBAC objects, facilitating further lateral movement. This detection approach focuses on correlating interactive process execution within a container with near-simultaneous Kubernetes audit log events. Defenders should focus on workloads that do not require network utilities or direct API access to function as part of their standard operations.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAttacker exploits a vulnerability in a containerized application to gain remote code execution.\u003c/li\u003e\n\u003cli\u003eAttacker invokes an interactive shell (e.g., '/bin/sh', 'bash') inside the compromised container.\u003c/li\u003e\n\u003cli\u003eAttacker locates the Kubernetes service account token at '/var/run/secrets/kubernetes.io/serviceaccount/token'.\u003c/li\u003e\n\u003cli\u003eAttacker uses an installed utility like 'curl' or 'kubectl' to initiate an interactive session.\u003c/li\u003e\n\u003cli\u003eAttacker executes a command targeting the Kubernetes API server endpoint (e.g., 'https://kubernetes.default.svc').\u003c/li\u003e\n\u003cli\u003eThe Kubernetes API server logs the request in the audit logs, reflecting the pod's service account identity.\u003c/li\u003e\n\u003cli\u003eAttacker parses the API response to enumerate cluster resources, secrets, or RBAC configurations.\u003c/li\u003e\n\u003cli\u003eAttacker uses identified information to move laterally or exfiltrate sensitive data from the cluster.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation allows attackers to bypass pod-level isolation to discover cluster topology, gain unauthorized access to secrets, or modify RBAC configurations. This activity often precedes full cluster compromise, exfiltration of sensitive credentials stored in Kubernetes Secrets, or the deployment of persistent backdoor pods, potentially affecting any enterprise utilizing Kubernetes for production workloads.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cp\u003ePrioritize the following actions for your detection and response teams:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the provided EQL-based logic to correlate 'logs-cloud_defend.process' events with 'kubernetes.audit_logs' entries to surface interactive API abuse.\u003c/li\u003e\n\u003cli\u003eAudit all container images to remove unnecessary networking utilities (e.g., curl, wget, ncat, socat) and Kubernetes binaries (kubectl) to minimize the attack surface.\u003c/li\u003e\n\u003cli\u003eImplement and enforce NetworkPolicies to restrict pod-level egress, specifically blocking traffic to the 'kubernetes.default.svc' API endpoint for pods that do not require cluster administration.\u003c/li\u003e\n\u003cli\u003eRegularly rotate service account tokens and use fine-grained RBAC with 'automountServiceAccountToken' set to 'false' for all pods where it is not strictly necessary.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-09-18T19:14:52Z","date_published":"2026-09-18T19:14:52Z","id":"https://feed.craftedsignal.io/briefs/2026-09-k8s-interactive-api-abuse/","summary":"Adversaries may move laterally or perform reconnaissance by compromising a container and using interactive shells or networking utilities to query the Kubernetes API server directly.","title":"Detection of Interactive Kubernetes API Abuse via Container Utilities","url":"https://feed.craftedsignal.io/briefs/2026-09-k8s-interactive-api-abuse/"}],"language":"en","title":"CraftedSignal Threat Feed - Kubernetes (All Versions)","version":"https://jsonfeed.org/version/1.1"}