Container — CraftedSignal Threat Feed

Distribution Toolkit Authentication Redirection Vulnerability (CVE-2026-33540)

hello@craftedsignal.io — Mon, 06 Apr 2026 15:17:10 +0000

The distribution toolkit, used for managing container content, is vulnerable to an authentication redirection attack in versions prior to 3.1.0 when operating in pull-through cache mode. The vulnerability, identified as CVE-2026-33540, stems from the toolkit’s method of discovering token authentication endpoints. It parses WWW-Authenticate challenges from upstream registries without properly validating the realm URL against the upstream registry host. This allows an attacker controlling the upstream registry or positioned as a Man-in-the-Middle to redirect authentication requests to an attacker-controlled realm URL. This results in distribution sending the configured upstream credentials via basic authentication to the malicious URL. Organizations using affected versions of the distribution toolkit are vulnerable to credential compromise if the toolkit interacts with a malicious or compromised upstream registry. Upgrading to version 3.1.0 or later resolves this vulnerability.

Attack Chain

Attacker gains control of or MitM position to an upstream registry server used by the distribution toolkit.
Distribution toolkit attempts to pull an image from the upstream registry.
Attacker’s registry responds with a WWW-Authenticate header, specifying a Bearer authentication scheme and an attacker-controlled realm URL.
The distribution toolkit, vulnerable to CVE-2026-33540, parses the WWW-Authenticate header but fails to validate the realm URL against the legitimate upstream registry.
The distribution toolkit initiates a basic authentication request to the attacker-controlled realm URL, sending the configured upstream credentials (username and password).
The attacker captures the credentials sent via basic authentication.
Attacker uses the compromised credentials to gain unauthorized access to the legitimate upstream registry.

Impact

Successful exploitation of CVE-2026-33540 allows an attacker to steal credentials used by the distribution toolkit to authenticate to an upstream registry. This can lead to unauthorized access to container images stored in the upstream registry, potentially resulting in supply chain attacks, data breaches, or the deployment of malicious container images. The severity of the impact depends on the permissions associated with the compromised credentials and the sensitivity of the data stored in the upstream registry.

Recommendation

Upgrade the distribution toolkit to version 3.1.0 or later to remediate CVE-2026-33540.
Implement network monitoring to detect basic authentication attempts originating from the distribution toolkit to unusual or unexpected destinations (see rule: “Detect Basic Authentication to Non-Standard Ports”).
Monitor network traffic for connections to unusual or suspicious realm URLs returned in WWW-Authenticate headers from container registries (see rule: “Detect Authentication Redirection”).

SSH Authorized Key File Modification Inside a Container

hello@craftedsignal.io — Thu, 02 Apr 2026 12:00:00 +0000

This detection focuses on identifying malicious actors who modify SSH authorized_keys files inside containers to gain unauthorized access. SSH authorized keys are used for public key authentication, and modification of these files allows attackers to maintain persistence or move laterally within a containerized environment. The rule specifically looks for file creation and modification events of authorized_keys files within Linux-based containers. Introduced as part of the Defend for Containers integration in Elastic Stack version 9.3.0, this detection is crucial because unauthorized SSH access can lead to significant compromise within cloud environments and containerized workloads. Defenders need to be aware of unexpected SSH key modifications as indicators of compromise inside containerized environments.

Attack Chain

An attacker gains initial access to a container, possibly through a software vulnerability or misconfiguration.
The attacker executes commands within the container to locate the SSH authorized_keys file (typically located at /home//.ssh/authorized_keys or /root/.ssh/authorized_keys).
The attacker modifies the authorized_keys file, adding their own SSH public key to the file using commands like echo "ssh-rsa AAAAB3Nz..." >> /root/.ssh/authorized_keys.
The attacker uses the newly added SSH key to authenticate and log into the container without needing a password.
The attacker uses the SSH session to execute further commands, potentially escalating privileges or moving laterally to other containers or systems.
The attacker maintains persistence by ensuring their SSH key remains in the authorized_keys file, allowing them to re-access the container at any time.

Impact

Successful modification of the authorized_keys file enables persistent, unauthorized SSH access to the compromised container. This can lead to lateral movement within the container environment, privilege escalation, data exfiltration, or further attacks on other systems. The rule aims to detect these modifications early, preventing significant damage. While the number of specific victims isn’t stated, a successful attack targeting containers can affect critical cloud infrastructure and applications.

Recommendation

Deploy the provided Sigma rule to your SIEM to detect unauthorized modifications of SSH authorized_keys files within containers (rule: SSH Authorized Key File Activity).
Enable Elastic Defend for Containers integration (minimum version 9.3.0) to provide the necessary file event data for the Sigma rule to function correctly.
Investigate any alerts generated by the Sigma rule, focusing on the process and user context of the file modifications, as outlined in the rule’s description (rule: SSH Authorized Key File Activity).
Implement stricter access controls and monitoring on SSH usage within containers to prevent similar incidents in the future, as recommended in the incident response section.
Create exceptions for known update processes or deployment scripts that regularly alter these files to reduce false positives, as suggested in the false positive analysis.

Suspicious Pod Creation in Kubernetes System Namespace

hello@craftedsignal.io — Thu, 07 Nov 2024 14:23:50 +0000

Attackers can exploit the trust associated with the kube-system namespace in Kubernetes to deploy malicious pods. By naming these pods similarly to legitimate system pods (e.g., kube-proxy-bv61v), they attempt to blend in and avoid detection. This technique leverages the fact that system pods created by controllers like Deployments or DaemonSets have random suffixes in their names, making it difficult to distinguish malicious pods from legitimate ones based on naming conventions alone. The deployment of a backdoor container in the kube-system namespace alongside other administrative containers poses a significant risk.

Attack Chain

Compromise a Kubernetes cluster with sufficient privileges to deploy pods.
Identify existing pods in the kube-system namespace, noting naming conventions and suffixes.
Craft a pod manifest for a malicious container, naming it to resemble a legitimate system pod (e.g., kube-proxy-xxxx).
Deploy the malicious pod to the kube-system namespace using kubectl apply -f .
The malicious pod executes its intended function, such as establishing a reverse shell or providing unauthorized access.
The attacker maintains persistence by ensuring the malicious pod is recreated if deleted, possibly via a custom controller.
The attacker performs lateral movement to other resources within the cluster from the compromised pod.
The attacker achieves their objective, such as data exfiltration or denial of service, using the compromised pod as a base of operations.

Impact

Successful deployment of malicious pods in the kube-system namespace can lead to a range of impacts, including unauthorized access to sensitive resources, data exfiltration, and denial of service. This can compromise the entire Kubernetes cluster and any applications it hosts. The number of affected systems depends on the scope of the compromised cluster, but it could potentially impact all applications and data within the environment.

Recommendation

Deploy the Sigma rule Creation Of Pod In System Namespace to your SIEM to detect suspicious pod creations in the kube-system namespace.
Investigate any alerts generated by the Creation Of Pod In System Namespace Sigma rule to determine if the pod creation is legitimate or malicious.
Implement strong RBAC policies to limit the ability of users and service accounts to create pods in the kube-system namespace.
Regularly audit pod deployments in the kube-system namespace to identify any unauthorized or suspicious activity.

Curl or Wget Execution from Container Context

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

This detection rule identifies instances of curl or wget being executed from within containers managed by runc on Linux systems. The rule leverages Auditd Manager to monitor system calls and flags processes running with the title runc init that then execute curl or wget. This activity is noteworthy because attackers often use these tools to download malicious payloads (stagers, scripts, implants) or to exfiltrate data after compromising a container. While these tools can be used legitimately within containers, their execution in the context of runc init suggests a higher risk of malicious activity. The rule focuses on narrowing the signal to the container runtime boundary where unexpected download clients are more worthy of review. The rule specifically leverages Auditd Manager for data collection.

Attack Chain

An attacker gains initial access to a host system, possibly through exploiting a vulnerability in an application running outside the container (e.g., web application).
The attacker identifies a containerized application running on the compromised host.
The attacker exploits a vulnerability within the container, or abuses a privileged workload within the container, to gain elevated privileges or code execution within the container.
The attacker uses curl or wget to download additional tools or scripts into the container. These tools might include reverse shells, credential dumping tools, or data exfiltration utilities.
The attacker executes the downloaded tools to further compromise the container or the underlying host.
The attacker uses curl or wget to stage data for exfiltration to an external server. This may involve compressing and encoding data before transmission.
The attacker initiates the data exfiltration process using curl or wget to send the staged data to a remote server controlled by the attacker.
The attacker achieves their final objective, which could include data theft, system disruption, or further lateral movement within the network.

Impact

Compromised containers can lead to data breaches, service disruptions, and further attacks on internal systems. Successful exploitation could allow attackers to steal sensitive data, install malware, or pivot to other parts of the network, impacting confidentiality, integrity, and availability. The number of affected systems depends on the scope of the container deployment and the privileges granted to the compromised container.

Recommendation

Deploy the Sigma rule Detect Curl or Wget Execution from Container Context to your SIEM and tune for your environment.
Enable Auditd Manager with syscall coverage including execve to capture process execution and arguments within containers, as mentioned in the rule’s setup instructions.
Correlate alerts from this rule with network logs to identify the destination IP addresses and domains contacted by the compromised container.
Baseline trusted images and exclude stable image digests or namespaces when noisy to reduce false positives, as suggested in the rule’s false positives section.

Potential Privilege Escalation in Container via Runc Init

hello@craftedsignal.io — Fri, 05 Jan 2024 14:22:00 +0000

This detection identifies a potential privilege escalation vulnerability within container environments utilizing runc, the low-level container runtime used by Docker and containerd. The rule focuses on audit events triggered by runc init child processes. Specifically, it flags instances where the effective user ID is root (0), while the login user ID is not root. This discrepancy can indicate malicious activity, such as exploiting credential separation or namespace transitions to gain unauthorized root privileges within the container or escape to the host. This is relevant for defenders because a compromised container can lead to host compromise, data exfiltration, or denial of service.

Attack Chain

Attacker gains initial access to a container with limited privileges.
The attacker exploits a vulnerability within the container to execute code as the runc init process.
The runc init process spawns a child process while retaining a non-root user ID in audit telemetry.
The child process is assigned an effective user ID of 0 (root), bypassing normal permission controls.
The attacker leverages the elevated privileges to modify sensitive files or execute commands as root within the container’s namespace.
The attacker may then attempt to escape the container by exploiting kernel vulnerabilities or misconfigurations to gain access to the host system.
Upon gaining access to the host system, the attacker can install malware, steal sensitive data, or disrupt services.

Impact

A successful privilege escalation attack within a container environment can lead to complete compromise of the container and potentially the host system. This can result in data breaches, service disruptions, and unauthorized access to sensitive resources. The impact is significant because a single compromised container can become a launchpad for attacks against other containers or the underlying infrastructure.

Recommendation

Deploy the Sigma rule “Potential Privilege Escalation via Runc Init” to your SIEM to detect suspicious runc init process executions.
Enable Linux audit logging via the Auditd Manager integration, ensuring that execve and identity-related fields are captured.
Investigate any alerts generated by the Sigma rule by examining the full audit event details, including process ancestry, user IDs, and container metadata.
Review container configurations and security profiles to identify potential misconfigurations that could facilitate privilege escalation.
Implement network segmentation to limit the blast radius of a compromised container.

Nsenter to PID Namespace via Auditd

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

This detection identifies instances where the nsenter command is used to enter a process namespace, specifically targeting a PID. This technique is often employed to attach to the host’s init namespace from a container or session, effectively allowing the attacker to execute commands within the host’s context. This behavior is concerning because it can be used to escalate privileges and gain unauthorized access to the underlying system. This is especially relevant in containerized environments where attackers may attempt to escape the container and access the host system. The rule leverages Auditd logs to identify these nsenter executions, focusing on those that include the --target or -t flags, which specify the target PID for namespace entry.

Attack Chain

An attacker gains initial access to a container or a restricted session on a Linux host.
The attacker identifies a target PID, often the init process (PID 1), to enter its namespace.
The attacker executes the nsenter command with the --target or -t flag, specifying the target PID. Additional namespace flags like --mount, --uts, --ipc, --net, and --user may also be used.
Auditd logs the nsenter execution, capturing the process name, arguments, and other relevant metadata.
The detection rule identifies the nsenter execution based on the command name and the presence of the --target or -t flag.
The attacker, now within the target PID’s namespace, executes commands with the privileges of that process. This may include reading sensitive files, modifying system configurations, or executing malicious code.
The attacker leverages the escalated privileges to further compromise the host system, potentially gaining root access or deploying malware.
The attacker establishes persistence mechanisms to maintain access to the compromised host, such as creating new systemd units or modifying existing ones.

Impact

Successful exploitation can lead to complete compromise of the host system. Attackers can gain root privileges, access sensitive data, and deploy malware. In containerized environments, this can allow attackers to escape the container and access the underlying host, potentially affecting other containers running on the same host. The impact is especially significant in production environments where compromised hosts can disrupt critical services and expose sensitive data.

Recommendation

Deploy the Auditd Manager integration on Linux hosts to collect process execution telemetry, as specified in the setup instructions.
Implement the Sigma rule “Nsenter to PID Namespace via Auditd” to detect suspicious nsenter executions.
Tune the Sigma rule by excluding known false positives, such as legitimate nsenter executions by platform engineers or CNI/snap workflows, as mentioned in the false positives section.
Investigate any detected nsenter executions by reviewing process arguments, parent processes, user identities, and host information, as outlined in the triage and analysis section.
Isolate any compromised hosts, revoke credentials, inspect for persistence, and re-image if integrity cannot be proven, as recommended in the response and remediation 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.

Unusual Process Connecting to Docker or Containerd Socket

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

This threat involves unauthorized processes connecting directly to container runtime sockets (Docker or Containerd) on Linux systems. This bypasses Kubernetes API server restrictions, potentially allowing attackers to create, execute, or manipulate containers without proper authorization or logging. The risk lies in attackers circumventing RBAC, admission webhooks, and pod security standards. The attack can start when a compromised process attempts to connect to the Docker or Containerd socket, potentially leading to privilege escalation and lateral movement within the containerized environment. This attack is significant because it undermines core security controls within container orchestration platforms.

Attack Chain

A malicious or compromised process gains initial access to the host system.
The process attempts to connect to the container runtime socket (e.g., /var/run/docker.sock or /run/containerd/containerd.sock).
The process bypasses the Kubernetes API server and associated security controls.
The attacker exploits the direct socket connection to create a new container.
The attacker gains access to sensitive data or resources within the container.
The attacker escalates privileges within the compromised container.
The attacker uses the compromised container to move laterally to other containers or hosts within the environment.
The attacker achieves their objective, such as data exfiltration or system compromise.

Impact

Successful exploitation allows attackers to bypass Kubernetes security measures, create unauthorized containers, and potentially gain control over the entire cluster. The observed impact includes privilege escalation, lateral movement, and data exfiltration. The severity of this attack depends on the level of access granted to the compromised container and the sensitivity of the data and resources within the cluster.

Recommendation

Enable Auditd Manager to capture network and socket events, specifically monitoring for connect calls to Unix sockets as described in the Auditd Manager documentation.
Deploy the Sigma rule “Unusual Process Connecting to Docker or Containerd Socket” to detect suspicious processes connecting to container runtime sockets, tuning process.executable and user.name for known legitimate processes.
Monitor file permissions on the socket paths (/var/run/docker.sock, /run/docker.sock, /var/run/containerd/containerd.sock, /run/containerd/containerd.sock) and restrict access to trusted groups only.

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.

Potential Kubeletctl Execution on Linux Hosts

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

The kubeletctl tool simplifies access to Kubelet endpoints, potentially allowing attackers to perform discovery and lateral movement within Kubernetes environments. The tool can be used to enumerate pods and nodes, and attempt actions such as exec/attach/portForward. Attackers may run kubeletctl scan to find reachable Kubelet endpoints, then use pods or exec/attach for follow-on access. This activity is typically observed on Linux hosts within containerized environments. Defenders should monitor for the execution of kubeletctl with suspicious arguments or connections to Kubelet ports (commonly 10250/10255).

Attack Chain

Attacker gains initial access to a compromised host within the Kubernetes environment.
Attacker downloads or transfers the kubeletctl binary to the compromised host.
Attacker executes kubeletctl scan to identify accessible Kubelet API endpoints by scanning for open ports 10250 and 10255.
Attacker uses kubeletctl pods to enumerate running pods on a targeted node based on the scan results.
Attacker leverages kubeletctl exec or kubeletctl attach to gain shell access to a pod.
Attacker uses the compromised pod to move laterally within the Kubernetes cluster, potentially accessing sensitive data or resources.
Attacker may attempt to access Kubernetes credentials, such as service account tokens or kubeconfigs, for further privilege escalation.

Impact

Successful exploitation can allow attackers to enumerate pods and nodes, execute commands within containers, and potentially move laterally within the Kubernetes cluster. This could lead to unauthorized access to sensitive data, resource hijacking, or complete compromise of the Kubernetes environment. The CyberArk research cited in the references describes how kubeletctl can be leveraged to attack Kubernetes clusters.

Recommendation

Deploy the Sigma rule Potential Kubeletctl Execution to detect suspicious execution of the kubeletctl binary on Linux hosts, focusing on command-line arguments such as scan, pods, exec, and attach.
Monitor host and container telemetry for connections to Kubelet ports (10250/10255) using a network connection rule and look for scanning patterns across multiple nodes.
Restrict access to Kubelet ports at the network layer and harden Kubelet authentication/authorization based on the recommendations in the provided references.
Rotate/revoke any exposed Kubernetes credentials (service account tokens, kubeconfigs, client certs) and investigate for follow-on discovery or execution attempts.

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.

Gotenberg ExifTool Argument Injection via Metadata Values

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

Gotenberg, a Docker-based solution for converting various document formats to PDF, is vulnerable to an argument injection flaw affecting versions 8.30.1 and earlier. This vulnerability stems from insufficient sanitization of metadata values passed to the ExifTool during PDF processing. Specifically, the application fails to properly sanitize newline characters within metadata values. By exploiting this flaw, an unauthenticated attacker can inject arbitrary ExifTool pseudo-tags, such as -FileName, -Directory, -SymLink, and -HardLink, allowing for unauthorized file manipulation, including renaming, moving, overwriting, and creating symbolic or hard links to files within the container’s filesystem. The vulnerability is a bypass of an incomplete key sanitization fix introduced in version 8.30.1, highlighting the importance of thorough input validation.

Attack Chain

An attacker crafts a malicious PDF file or uses an existing PDF.
The attacker injects a newline character followed by an ExifTool pseudo-tag (e.g., -FileName=/tmp/inject_proof) into a metadata value (e.g., the ‘Title’ field).
The attacker sends the PDF, along with the crafted metadata, to the Gotenberg /forms/pdfengines/metadata/write endpoint via a POST request.
Gotenberg’s WriteMetadata function in pkg/modules/exiftool/exiftool.go processes the metadata.
The unsanitized metadata value is passed to go-exiftool’s SetString function.
go-exiftool writes the key-value pair to ExifTool’s stdin using fmt.Fprintln(e.stdin, "-"+k+"="+str).
The newline character splits the ExifTool stdin line into two separate arguments, injecting the attacker’s pseudo-tag.
ExifTool executes the injected command (e.g., moving the PDF to /tmp/inject_proof).

Impact

Successful exploitation allows an unauthenticated attacker to rename or move any PDF being processed to an arbitrary path within the container filesystem, which runs as root by default. This also enables overwriting arbitrary files (e.g., corrupting the /etc/passwd file), creating symlinks, and creating hard links. The container filesystem becomes fully exposed to arbitrary file manipulation.

Recommendation

Apply value sanitization parallel to the existing key check in WriteMetadata as described in the advisory.
Implement detection rules to identify attempts to exploit the vulnerability by monitoring for suspicious characters in HTTP requests to the /forms/pdfengines/metadata/write endpoint using the provided Sigma rule.
Monitor for unexpected file modifications within the Gotenberg container, especially the creation or modification of symbolic links and hard links, using file_event log source.
Upgrade to a patched version of Gotenberg that addresses this vulnerability to prevent exploitation (CVE-2026-40281).