Kubelet — CraftedSignal Threat Feed

Potential Direct Kubelet API Access via Process Arguments

hello@craftedsignal.io — Mon, 04 May 2026 21:18:23 +0000

This detection identifies potential direct Kubelet API access attempts on Linux systems. The Kubelet, acting as the primary node agent, exposes an API accessible via ports 10250 and 10255. Attackers may exploit this API to enumerate pods, fetch logs, or even attempt remote execution. This access can lead to significant breaches in Kubernetes environments, facilitating discovery, lateral movement, and ultimately, compromise of sensitive data or control over cluster resources. The detection focuses on identifying process executions where the command-line arguments contain URLs targeting these Kubelet ports, indicating a potential attempt to interact with the Kubelet API directly.

Attack Chain

An attacker gains initial access to a compromised host within the Kubernetes cluster or a host with network access to the Kubelet ports.
The attacker uses a utility like curl, wget, python, or similar tools to craft an HTTP request targeting the Kubelet API on ports 10250 or 10255.
The request includes a path like /pods, /runningpods, /metrics, /exec, or /containerLogs to gather information about the cluster’s state and configuration.
The attacker examines the response to identify potential targets for lateral movement, such as specific pods or containers of interest.
The attacker attempts to execute commands within a container using the /exec endpoint, potentially leveraging exposed service account tokens or other credentials.
The attacker uses gathered information to move laterally to other pods or nodes within the cluster, escalating privileges as they go.
The attacker compromises sensitive data or critical applications running within the Kubernetes cluster.

Impact

Successful exploitation can lead to full cluster compromise. Attackers can gain unauthorized access to sensitive data, disrupt critical applications, and move laterally to other resources within the Kubernetes environment. This could lead to significant financial losses, reputational damage, and legal liabilities. The potential impact includes data breaches, denial of service, and complete control over the Kubernetes infrastructure.

Recommendation

Deploy the Sigma rule Kubelet API Access via Process Arguments to your SIEM to detect suspicious process executions.
Restrict access to Kubelet ports 10250/10255 at the network layer to limit pod-to-node or host-to-node traffic as recommended in the overview section.
Harden Kubelet configuration by disabling anonymous authentication and enforcing webhook authentication/authorization as described in the overview section.

Kubelet API Connection Attempt to Internal IP

hello@craftedsignal.io — Wed, 03 Jan 2024 14:30:00 +0000

This detection rule identifies suspicious network connections to the Kubernetes Kubelet API, specifically targeting ports 10250 and 10255, from Linux hosts within internal network ranges. Attackers frequently exploit weak authentication or network controls to access the Kubelet API, potentially enabling them to enumerate pods, retrieve logs, and execute commands on nodes. This activity often originates from common scripting utilities like curl, wget, or interpreters like python and node, particularly when executed from world-writable directories such as /tmp, /var/tmp, or /dev/shm. This technique is often a component of container and cluster lateral movement, where the attacker seeks to expand their access within the Kubernetes environment. The rule is designed to detect these unauthorized attempts and alert security teams to investigate potential breaches.

Attack Chain

An attacker gains initial access to a compromised container or host within the Kubernetes cluster, potentially through exploiting a vulnerability in a running application.
The attacker executes a reconnaissance command, such as curl or wget, from within the compromised container, targeting the Kubelet API on port 10250 or 10255.
The curl or wget command is executed from a temporary directory like /tmp or /dev/shm to avoid detection.
The attacker attempts to enumerate running pods and services by querying the /pods or /runningpods endpoints of the Kubelet API.
If successful, the attacker identifies a target pod within the cluster based on the enumerated information.
The attacker leverages the Kubelet API to execute commands within the target pod, potentially escalating privileges or accessing sensitive data.
The attacker attempts to move laterally to other nodes or containers within the Kubernetes cluster, repeating the reconnaissance and exploitation steps.
The ultimate goal is to gain control over the entire Kubernetes cluster, enabling data exfiltration, resource hijacking, or disruption of services.

Impact

Successful exploitation of the Kubelet API can lead to a complete compromise of the Kubernetes cluster. Attackers can gain unauthorized access to sensitive data, escalate privileges, and disrupt critical services. While the number of victims may vary depending on the organization’s security posture, a successful attack could impact all applications and data managed by the cluster. Organizations in any sector utilizing Kubernetes are potentially at risk.

Recommendation

Enable syscall auditing and ensure that event.category:network events are generated for network connections, as outlined in the rule’s setup guide.
Deploy the provided Sigma rule to your SIEM and tune it based on your environment to reduce false positives.
Restrict pod-to-node access to port 10250 using network policies or security groups to limit the attack surface, as noted in the rule’s documentation.
Implement Kubernetes API audit logging to detect unauthorized access attempts and credential access, correlating with process argument telemetry as mentioned in the triage steps.

Potential Direct Kubelet Access via Process Arguments

hello@craftedsignal.io — Wed, 03 Jan 2024 12:00:00 +0000

This 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.

Attack Chain

An attacker gains initial access to a container within the Kubernetes cluster, potentially through exploiting a vulnerable application.
The attacker opens an interactive shell within the compromised container.
Using command-line tools such as curl or wget, the attacker crafts an HTTP request targeting the Kubelet API, typically on port 10250 or 10255.
The HTTP request is embedded within the process arguments, including specific Kubelet endpoints such as /pods, /exec, /run, or /logs.
The attacker attempts to enumerate pods and other cluster resources by querying the /pods endpoint.
The attacker attempts to execute commands within containers by leveraging the /exec or /run endpoints.
The attacker attempts to retrieve container logs using the /logs endpoint.
Successful exploitation allows the attacker to move laterally within the Kubernetes cluster, potentially gaining access to sensitive data or control over other resources.

Impact

Successful 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.

Recommendation

Deploy 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.
Review network policies to restrict pod access to Kubelet ports (10250, 10255) except from approved node-local agents (references: https://www.cyberark.com/resources/threat-research-blog/using-kubelet-client-to-attack-the-kubernetes-cluster).
Harden Kubelet authentication and authorization by disabling anonymous access and requiring webhook authorization (references: https://www.aquasec.com/blog/kubernetes-exposed-exploiting-the-kubelet-api/).
Enforce pod security policies to restrict privileged pods and host networking, reducing the attack surface for node API access.