Defend for Containers — CraftedSignal Threat Feed

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.

Nsenter Execution with Target Flag Inside Container

hello@craftedsignal.io — Tue, 02 Jan 2024 12:00:00 +0000

This detection identifies the execution of nsenter within a Linux container, specifically when the -t or --target 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.

Attack Chain

An attacker gains initial access to a container, possibly through exploiting a vulnerability in a containerized application.
The attacker identifies a container with weak configurations, such as exposed PIDs, shared namespaces, or privileged mounts.
The attacker executes nsenter with the -t or --target flag, specifying a target PID or namespace.
The nsenter command joins the target namespace (mount, network, PID, user, or IPC) based on specified flags (-m, -n, -p, -U, or -i).
The attacker gains access to the host system’s resources or processes due to the namespace sharing or privileged access.
The attacker escalates privileges on the host system, potentially gaining root access.
The attacker pivots to other containers or the host infrastructure, expanding their control.
The attacker achieves their final objective, such as data exfiltration, system disruption, or deploying malware on the host.

Impact

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

Recommendation

Deploy the Sigma rule Detect Nsenter Container Escape to your SIEM and tune for your environment to detect suspicious nsenter executions within containers.
Review container configurations and enforce least privilege to prevent unauthorized namespace sharing and privileged mounts.
Monitor container logs for nsenter executions with target flags, as indicated by the log source logs-cloud_defend.process* and the query in this brief.
Restrict the use of hostPath volumes and other sensitive mounts within container deployments.
Reduce recurrence by avoiding host namespace sharing, restricting hostPath and sensitive mounts, and blocking unnecessary capabilities.

Kubeletctl Execution Inside Container Detected

hello@craftedsignal.io — Tue, 02 Jan 2024 12:00:00 +0000

This rule detects the execution of kubeletctl 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 “Defend for Containers” integration (version 9.3.0 and later) within the Elastic stack. This activity is significant because kubeletctl can expose pod and node details, enabling actions that facilitate discovery and lateral movement from a compromised container.

Attack Chain

An attacker gains initial access to a container, possibly through a vulnerability in the containerized application or a misconfigured Kubernetes environment.
The attacker executes kubeletctl inside the compromised container. This could be facilitated by the tool being present in the container image or downloaded post-compromise.
The attacker uses kubeletctl scan to discover Kubelet endpoints within the Kubernetes cluster.
The attacker leverages kubeletctl pods or kubeletctl runningpods to enumerate running pods and their details.
The attacker uses the discovered pod information to identify potential targets for lateral movement.
The attacker attempts to use kubeletctl exec or kubeletctl attach to gain access to other pods within the cluster.
The attacker attempts to port forward using kubeletctl portForward to establish connections to services running in other pods.
Upon successful lateral movement, the attacker performs further reconnaissance or deploys malicious payloads to achieve their objectives, such as data exfiltration or denial-of-service.

Impact

Successful execution of kubeletctl 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’s objectives and the scope of the compromised container’s access.

Recommendation

Deploy the provided Sigma rule to your SIEM to detect the execution of kubeletctl within containers based on process name and arguments.
Monitor container network activity for connections to node addresses on Kubelet ports (commonly 10250/10255) and investigate any suspicious patterns.
Implement network policies to restrict pod-to-node access to the Kubelet API.
Harden container images by removing unnecessary tools like kubeletctl and enforce least privilege principles.
Enable and review Kubernetes audit logs to identify the source of interactive sessions into containers, correlating with timestamps of kubeletctl execution.
Enforce Pod Security Standards to restrict privileged pods and limit node API exposure.