Potential Kubeletctl Execution Detected in Containers

This brief details the detection of kubeletctl execution inside Linux containers, a behavior indicative of potential malicious activity within Kubernetes environments. Kubeletctl is an open-source command-line utility that facilitates direct interaction with the Kubelet API, often making undocumented features more accessible. Threat actors commonly employ kubeletctl for enumerating Kubelet API details, scanning for accessible endpoints, and performing actions like exec or attach to other pods or nodes from a compromised container. This activity suggests an attempt to gain further access, move laterally, or escalate privileges within the cluster. While kubeletctl can be used for legitimate debugging or troubleshooting, its presence and use in containerized workloads warrants immediate investigation due to the significant risk of container escape and broader cluster compromise.

Attack Chain

1. Initial Access: An attacker gains initial access to a container, typically through a vulnerable application (e.g., Remote Code Execution - RCE) or by compromising credentials allowing interactive shell access (e.g., kubectl exec).
2. Tool Deployment/Execution: The attacker deploys or executes the kubeletctl utility within the compromised Linux container.
3. Kubelet API Discovery: The attacker uses kubeletctl scan to identify and enumerate Kubelet API endpoints, gathering information about the host node's configuration and exposed services.
4. Workload Enumeration: The attacker leverages kubeletctl pods or kubeletctl runningpods to discover other pods and workloads running on the same node or across the cluster, including their names, namespaces, and associated resources.
5. Lateral Movement/Privilege Escalation: Utilizing kubeletctl exec, attach, or portForward, the attacker attempts to gain access to other pods, services, or the underlying node, potentially escalating privileges within the cluster.
6. Impact and Persistence: The attacker may establish persistence, exfiltrate sensitive data, or hijack cluster resources for cryptomining, further compromise, or denial-of-service.

Impact

Successful exploitation involving kubeletctl can lead to severe consequences for an organization's Kubernetes infrastructure. Attackers can gain unauthorized access to sensitive data within other pods, execute arbitrary commands on different containers or even the host node, and potentially achieve full cluster compromise. This can result in data breaches, resource hijacking (e.g., for cryptomining), service disruption, and the establishment of persistent backdoors. The broad scope of damage stems from the ability to bypass container isolation and interact directly with the critical Kubelet component, which manages pods and containers on a node.

Recommendation

• Deploy the Potential Kubeletctl Execution in Container Sigma rule to your SIEM to detect suspicious kubeletctl invocations.
• Configure Elastic Defend for Containers to ensure process execution logs from Linux containers (process_creation logsource) are ingested for analysis.
• Block pod-to-node access to Kubelet API ports (typically 10250 and 10255) at the network layer where not explicitly required, using network policies or firewall rules.
• Rotate and revoke any Kubernetes service account tokens or kubeconfig files present within a container if kubeletctl was observed attempting authenticated actions.
• Harden Kubernetes clusters by enforcing Pod Security Standards (e.g., disallowing privileged pods, restricting hostNetwork, hostPID, and hostPath) to limit the impact of container escapes.
• Limit interactive exec access into production pods and disable unauthenticated Kubelet endpoints, ensuring all Kubelet API access requires authentication and authorization.