{"description":"Trending threats, MITRE ATT\u0026CK coverage, and detection metadata — refreshed continuously.","feed_url":"https://feed.craftedsignal.io/products/kubernetes/","home_page_url":"https://feed.craftedsignal.io/","items":[{"_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":["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":["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":["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":["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":["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"}