Kubernetes — CraftedSignal Threat Feed

Suspicious Pod Creation in Kubernetes System Namespace

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

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

Attack Chain

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

Impact

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

Recommendation

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

Kubernetes Event Deletion for Defense Evasion

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

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

Attack Chain

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

Impact

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

Recommendation

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

Kubernetes Sensitive Role Creation or Modification

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

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

Attack Chain

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

Impact

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

Recommendation

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

Kubernetes RBAC Wildcard Elevation on Existing Role

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

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

Attack Chain

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

Impact

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

Recommendation

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

Kubernetes Secret Access by Node or Pod Service Account

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

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

Attack Chain

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

Impact

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

Recommendation

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

Kubernetes Pod Exec with Curl or Wget to HTTPS

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

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

Attack Chain

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

Impact

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

Recommendation

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

Kubernetes Secret Access with Suspicious User Agent

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

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

Attack Chain

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

Impact

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

Recommendation

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

Kubernetes Rapid Secret GET Activity Against Multiple Objects

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

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

Attack Chain

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

Impact

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

Recommendation

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

Kubernetes Pod Exec Potential Reverse Shell Activity Detected

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

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

Attack Chain

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

Impact

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

Recommendation

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

Kubernetes Secrets Enumeration from Non-Loopback Client

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

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

Attack Chain

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

Impact

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

Recommendation

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