{"description":"Trending threats, MITRE ATT\u0026CK coverage, and detection metadata — refreshed continuously.","feed_url":"https://feed.craftedsignal.io/products/defend-for-containers/","home_page_url":"https://feed.craftedsignal.io/","items":[{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Defend for Containers"],"_cs_severities":["high"],"_cs_tags":["container","kubelet","kubernetes","lateral-movement","execution"],"_cs_type":"advisory","_cs_vendors":["Elastic"],"content_html":"\u003cp\u003eThis rule detects potential direct Kubelet access via process arguments within Linux containers. Attackers may target the Kubelet API to gain unauthorized access to the Kubernetes API server or other sensitive resources within the cluster. Observed requests are often used for reconnaissance, such as enumerating pods and cluster resources, or for executing commands directly on the API server. This activity indicates a potential attempt to move laterally within the Kubernetes environment. The activity is detected by monitoring process arguments for HTTP requests directed at the Kubelet API on ports 10250 or 10255. The detection leverages Elastic Defend for Containers, introduced in version 9.3.0.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains initial access to a container within the Kubernetes cluster, potentially through exploiting a vulnerable application.\u003c/li\u003e\n\u003cli\u003eThe attacker opens an interactive shell within the compromised container.\u003c/li\u003e\n\u003cli\u003eUsing command-line tools such as \u003ccode\u003ecurl\u003c/code\u003e or \u003ccode\u003ewget\u003c/code\u003e, the attacker crafts an HTTP request targeting the Kubelet API, typically on port 10250 or 10255.\u003c/li\u003e\n\u003cli\u003eThe HTTP request is embedded within the process arguments, including specific Kubelet endpoints such as \u003ccode\u003e/pods\u003c/code\u003e, \u003ccode\u003e/exec\u003c/code\u003e, \u003ccode\u003e/run\u003c/code\u003e, or \u003ccode\u003e/logs\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to enumerate pods and other cluster resources by querying the \u003ccode\u003e/pods\u003c/code\u003e endpoint.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to execute commands within containers by leveraging the \u003ccode\u003e/exec\u003c/code\u003e or \u003ccode\u003e/run\u003c/code\u003e endpoints.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to retrieve container logs using the \u003ccode\u003e/logs\u003c/code\u003e endpoint.\u003c/li\u003e\n\u003cli\u003eSuccessful exploitation allows the attacker to move laterally within the Kubernetes cluster, potentially gaining access to sensitive data or control over other resources.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation of direct Kubelet access can lead to significant compromise within a Kubernetes cluster. Attackers can enumerate sensitive information, execute arbitrary commands within containers, and move laterally to other parts of the cluster. This can result in data exfiltration, denial of service, or complete cluster takeover. Due to the high level of access granted by Kubelet, a successful attack allows the attacker to take complete control over the target node.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the provided Sigma rules to your SIEM and tune them for your environment. Enable Elastic Defend for Containers with a minimum version of 9.3.0 to generate the necessary logs for these detections.\u003c/li\u003e\n\u003cli\u003eReview network policies to restrict pod access to Kubelet ports (10250, 10255) except from approved node-local agents (references: \u003ca href=\"https://www.cyberark.com/resources/threat-research-blog/using-kubelet-client-to-attack-the-kubernetes-cluster)\"\u003ehttps://www.cyberark.com/resources/threat-research-blog/using-kubelet-client-to-attack-the-kubernetes-cluster)\u003c/a\u003e.\u003c/li\u003e\n\u003cli\u003eHarden Kubelet authentication and authorization by disabling anonymous access and requiring webhook authorization (references: \u003ca href=\"https://www.aquasec.com/blog/kubernetes-exposed-exploiting-the-kubelet-api/)\"\u003ehttps://www.aquasec.com/blog/kubernetes-exposed-exploiting-the-kubelet-api/)\u003c/a\u003e.\u003c/li\u003e\n\u003cli\u003eEnforce pod security policies to restrict privileged pods and host networking, reducing the attack surface for node API access.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T12:00:00Z","date_published":"2024-01-03T12:00:00Z","id":"/briefs/2024-01-kubelet-access/","summary":"Detection of potential direct Kubelet access via process arguments in Linux containers, which could lead to enumeration, execution, or lateral movement within the Kubernetes cluster.","title":"Potential Direct Kubelet Access via Process Arguments","url":"https://feed.craftedsignal.io/briefs/2024-01-kubelet-access/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Defend for Containers"],"_cs_severities":["high"],"_cs_tags":["container","privilege-escalation","linux"],"_cs_type":"advisory","_cs_vendors":["Elastic"],"content_html":"\u003cp\u003eThis detection identifies the execution of \u003ccode\u003ensenter\u003c/code\u003e within a Linux container, specifically when the \u003ccode\u003e-t\u003c/code\u003e or \u003ccode\u003e--target\u003c/code\u003e flag is used. This flag indicates an attempt to enter another process or namespace context. Attackers can exploit this capability, especially when combined with privileged mounts, exposed PIDs, or shared namespaces, to escape the container and pivot to the host system. This activity can lead to privilege escalation and further compromise of the underlying infrastructure. The detection is relevant for environments using Elastic Defend for Containers.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains initial access to a container, possibly through exploiting a vulnerability in a containerized application.\u003c/li\u003e\n\u003cli\u003eThe attacker identifies a container with weak configurations, such as exposed PIDs, shared namespaces, or privileged mounts.\u003c/li\u003e\n\u003cli\u003eThe attacker executes \u003ccode\u003ensenter\u003c/code\u003e with the \u003ccode\u003e-t\u003c/code\u003e or \u003ccode\u003e--target\u003c/code\u003e flag, specifying a target PID or namespace.\u003c/li\u003e\n\u003cli\u003eThe \u003ccode\u003ensenter\u003c/code\u003e command joins the target namespace (mount, network, PID, user, or IPC) based on specified flags (\u003ccode\u003e-m\u003c/code\u003e, \u003ccode\u003e-n\u003c/code\u003e, \u003ccode\u003e-p\u003c/code\u003e, \u003ccode\u003e-U\u003c/code\u003e, or \u003ccode\u003e-i\u003c/code\u003e).\u003c/li\u003e\n\u003cli\u003eThe attacker gains access to the host system\u0026rsquo;s resources or processes due to the namespace sharing or privileged access.\u003c/li\u003e\n\u003cli\u003eThe attacker escalates privileges on the host system, potentially gaining root access.\u003c/li\u003e\n\u003cli\u003eThe attacker pivots to other containers or the host infrastructure, expanding their control.\u003c/li\u003e\n\u003cli\u003eThe attacker achieves their final objective, such as data exfiltration, system disruption, or deploying malware on the host.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA successful container escape can allow an attacker to compromise the underlying host system. This can lead to the compromise of other containers running on the same host, as well as sensitive data stored on the host system. The impact can range from data breaches to complete infrastructure takeover. If the host is a node in a Kubernetes cluster, the attacker might be able to compromise the entire cluster.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eDetect Nsenter Container Escape\u003c/code\u003e to your SIEM and tune for your environment to detect suspicious \u003ccode\u003ensenter\u003c/code\u003e executions within containers.\u003c/li\u003e\n\u003cli\u003eReview container configurations and enforce least privilege to prevent unauthorized namespace sharing and privileged mounts.\u003c/li\u003e\n\u003cli\u003eMonitor container logs for \u003ccode\u003ensenter\u003c/code\u003e executions with target flags, as indicated by the log source \u003ccode\u003elogs-cloud_defend.process*\u003c/code\u003e and the query in this brief.\u003c/li\u003e\n\u003cli\u003eRestrict the use of hostPath volumes and other sensitive mounts within container deployments.\u003c/li\u003e\n\u003cli\u003eReduce recurrence by avoiding host namespace sharing, restricting hostPath and sensitive mounts, and blocking unnecessary capabilities.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-02T12:00:00Z","date_published":"2024-01-02T12:00:00Z","id":"/briefs/2024-01-nsenter-container-escape/","summary":"The rule detects nsenter executions from inside a monitored Linux container that include a namespace target flag (-t or --target), which can be abused to escape container isolation.","title":"Nsenter Execution with Target Flag Inside Container","url":"https://feed.craftedsignal.io/briefs/2024-01-nsenter-container-escape/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Defend for Containers"],"_cs_severities":["high"],"_cs_tags":["container","kubeletctl","lateral-movement","execution"],"_cs_type":"advisory","_cs_vendors":["Elastic"],"content_html":"\u003cp\u003eThis rule detects the execution of \u003ccode\u003ekubeletctl\u003c/code\u003e inside a container. Kubeletctl is a command-line tool that interacts with the Kubelet API directly, making the often undocumented API more accessible. Attackers may use it to enumerate the Kubelet API or other resources within the container, potentially indicating lateral movement within the pod. The detection is based on the \u0026ldquo;Defend for Containers\u0026rdquo; integration (version 9.3.0 and later) within the Elastic stack. This activity is significant because \u003ccode\u003ekubeletctl\u003c/code\u003e can expose pod and node details, enabling actions that facilitate discovery and lateral movement from a compromised container.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains initial access to a container, possibly through a vulnerability in the containerized application or a misconfigured Kubernetes environment.\u003c/li\u003e\n\u003cli\u003eThe attacker executes \u003ccode\u003ekubeletctl\u003c/code\u003e inside the compromised container. This could be facilitated by the tool being present in the container image or downloaded post-compromise.\u003c/li\u003e\n\u003cli\u003eThe attacker uses \u003ccode\u003ekubeletctl scan\u003c/code\u003e to discover Kubelet endpoints within the Kubernetes cluster.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages \u003ccode\u003ekubeletctl pods\u003c/code\u003e or \u003ccode\u003ekubeletctl runningpods\u003c/code\u003e to enumerate running pods and their details.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the discovered pod information to identify potential targets for lateral movement.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to use \u003ccode\u003ekubeletctl exec\u003c/code\u003e or \u003ccode\u003ekubeletctl attach\u003c/code\u003e to gain access to other pods within the cluster.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to port forward using \u003ccode\u003ekubeletctl portForward\u003c/code\u003e to establish connections to services running in other pods.\u003c/li\u003e\n\u003cli\u003eUpon successful lateral movement, the attacker performs further reconnaissance or deploys malicious payloads to achieve their objectives, such as data exfiltration or denial-of-service.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful execution of \u003ccode\u003ekubeletctl\u003c/code\u003e within a container can lead to the exposure of sensitive information about the Kubernetes cluster, including pod details and internal network configurations. This can enable attackers to move laterally within the cluster, potentially compromising other applications and data. The impact could range from data breaches and service disruptions to full cluster compromise depending on the attacker\u0026rsquo;s objectives and the scope of the compromised container\u0026rsquo;s access.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the provided Sigma rule to your SIEM to detect the execution of \u003ccode\u003ekubeletctl\u003c/code\u003e within containers based on process name and arguments.\u003c/li\u003e\n\u003cli\u003eMonitor container network activity for connections to node addresses on Kubelet ports (commonly 10250/10255) and investigate any suspicious patterns.\u003c/li\u003e\n\u003cli\u003eImplement network policies to restrict pod-to-node access to the Kubelet API.\u003c/li\u003e\n\u003cli\u003eHarden container images by removing unnecessary tools like \u003ccode\u003ekubeletctl\u003c/code\u003e and enforce least privilege principles.\u003c/li\u003e\n\u003cli\u003eEnable and review Kubernetes audit logs to identify the source of interactive sessions into containers, correlating with timestamps of \u003ccode\u003ekubeletctl\u003c/code\u003e execution.\u003c/li\u003e\n\u003cli\u003eEnforce Pod Security Standards to restrict privileged pods and limit node API exposure.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-02T12:00:00Z","date_published":"2024-01-02T12:00:00Z","id":"/briefs/2024-01-kubeletctl-container-execution/","summary":"This rule detects the execution of kubeletctl inside a container, which can be used to enumerate the Kubelet API or other resources inside the container, potentially indicating lateral movement attempts within the pod.","title":"Kubeletctl Execution Inside Container Detected","url":"https://feed.craftedsignal.io/briefs/2024-01-kubeletctl-container-execution/"}],"language":"en","title":"CraftedSignal Threat Feed — Defend for Containers","version":"https://jsonfeed.org/version/1.1"}