{"description":"Trending threats, MITRE ATT\u0026CK coverage, and detection metadata — refreshed continuously.","feed_url":"https://feed.craftedsignal.io/tags/container/","home_page_url":"https://feed.craftedsignal.io/","items":[{"_cs_actors":[],"_cs_cves":[{"cvss":7.5,"id":"CVE-2026-33540"}],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["high"],"_cs_tags":["CVE-2026-33540","authentication","redirection","container"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eThe distribution toolkit, used for managing container content, is vulnerable to an authentication redirection attack in versions prior to 3.1.0 when operating in pull-through cache mode. The vulnerability, identified as CVE-2026-33540, stems from the toolkit\u0026rsquo;s method of discovering token authentication endpoints. It parses WWW-Authenticate challenges from upstream registries without properly validating the realm URL against the upstream registry host. This allows an attacker controlling the upstream registry or positioned as a Man-in-the-Middle to redirect authentication requests to an attacker-controlled realm URL. This results in distribution sending the configured upstream credentials via basic authentication to the malicious URL. Organizations using affected versions of the distribution toolkit are vulnerable to credential compromise if the toolkit interacts with a malicious or compromised upstream registry. Upgrading to version 3.1.0 or later resolves this vulnerability.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAttacker gains control of or MitM position to an upstream registry server used by the distribution toolkit.\u003c/li\u003e\n\u003cli\u003eDistribution toolkit attempts to pull an image from the upstream registry.\u003c/li\u003e\n\u003cli\u003eAttacker\u0026rsquo;s registry responds with a WWW-Authenticate header, specifying a Bearer authentication scheme and an attacker-controlled realm URL.\u003c/li\u003e\n\u003cli\u003eThe distribution toolkit, vulnerable to CVE-2026-33540, parses the WWW-Authenticate header but fails to validate the realm URL against the legitimate upstream registry.\u003c/li\u003e\n\u003cli\u003eThe distribution toolkit initiates a basic authentication request to the attacker-controlled realm URL, sending the configured upstream credentials (username and password).\u003c/li\u003e\n\u003cli\u003eThe attacker captures the credentials sent via basic authentication.\u003c/li\u003e\n\u003cli\u003eAttacker uses the compromised credentials to gain unauthorized access to the legitimate upstream registry.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation of CVE-2026-33540 allows an attacker to steal credentials used by the distribution toolkit to authenticate to an upstream registry. This can lead to unauthorized access to container images stored in the upstream registry, potentially resulting in supply chain attacks, data breaches, or the deployment of malicious container images. The severity of the impact depends on the permissions associated with the compromised credentials and the sensitivity of the data stored in the upstream registry.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eUpgrade the distribution toolkit to version 3.1.0 or later to remediate CVE-2026-33540.\u003c/li\u003e\n\u003cli\u003eImplement network monitoring to detect basic authentication attempts originating from the distribution toolkit to unusual or unexpected destinations (see rule: \u0026ldquo;Detect Basic Authentication to Non-Standard Ports\u0026rdquo;).\u003c/li\u003e\n\u003cli\u003eMonitor network traffic for connections to unusual or suspicious realm URLs returned in WWW-Authenticate headers from container registries (see rule: \u0026ldquo;Detect Authentication Redirection\u0026rdquo;).\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-06T15:17:10Z","date_published":"2026-04-06T15:17:10Z","id":"/briefs/2026-04-distribution-auth-redirect/","summary":"A vulnerability in the distribution toolkit prior to 3.1.0 allows a malicious upstream registry or man-in-the-middle attacker to redirect authentication requests, potentially exposing upstream credentials.","title":"Distribution Toolkit Authentication Redirection Vulnerability (CVE-2026-33540)","url":"https://feed.craftedsignal.io/briefs/2026-04-distribution-auth-redirect/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["medium"],"_cs_tags":["container","persistence","lateral-movement","privilege-escalation","ssh"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eThis detection focuses on identifying malicious actors who modify SSH authorized_keys files inside containers to gain unauthorized access. SSH authorized keys are used for public key authentication, and modification of these files allows attackers to maintain persistence or move laterally within a containerized environment. The rule specifically looks for file creation and modification events of authorized_keys files within Linux-based containers. Introduced as part of the Defend for Containers integration in Elastic Stack version 9.3.0, this detection is crucial because unauthorized SSH access can lead to significant compromise within cloud environments and containerized workloads. Defenders need to be aware of unexpected SSH key modifications as indicators of compromise inside containerized environments.\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, possibly through a software vulnerability or misconfiguration.\u003c/li\u003e\n\u003cli\u003eThe attacker executes commands within the container to locate the SSH authorized_keys file (typically located at \u003ccode\u003e/home/\u0026lt;user\u0026gt;/.ssh/authorized_keys\u003c/code\u003e or \u003ccode\u003e/root/.ssh/authorized_keys\u003c/code\u003e).\u003c/li\u003e\n\u003cli\u003eThe attacker modifies the authorized_keys file, adding their own SSH public key to the file using commands like \u003ccode\u003eecho \u0026quot;ssh-rsa AAAAB3Nz...\u0026quot; \u0026gt;\u0026gt; /root/.ssh/authorized_keys\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the newly added SSH key to authenticate and log into the container without needing a password.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the SSH session to execute further commands, potentially escalating privileges or moving laterally to other containers or systems.\u003c/li\u003e\n\u003cli\u003eThe attacker maintains persistence by ensuring their SSH key remains in the authorized_keys file, allowing them to re-access the container at any time.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful modification of the authorized_keys file enables persistent, unauthorized SSH access to the compromised container. This can lead to lateral movement within the container environment, privilege escalation, data exfiltration, or further attacks on other systems. The rule aims to detect these modifications early, preventing significant damage. While the number of specific victims isn\u0026rsquo;t stated, a successful attack targeting containers can affect critical cloud infrastructure and applications.\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 modifications of SSH authorized_keys files within containers (rule: \u003ccode\u003eSSH Authorized Key File Activity\u003c/code\u003e).\u003c/li\u003e\n\u003cli\u003eEnable \u003ccode\u003eElastic Defend for Containers\u003c/code\u003e integration (minimum version 9.3.0) to provide the necessary file event data for the Sigma rule to function correctly.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the Sigma rule, focusing on the process and user context of the file modifications, as outlined in the rule\u0026rsquo;s description (rule: \u003ccode\u003eSSH Authorized Key File Activity\u003c/code\u003e).\u003c/li\u003e\n\u003cli\u003eImplement stricter access controls and monitoring on SSH usage within containers to prevent similar incidents in the future, as recommended in the incident response section.\u003c/li\u003e\n\u003cli\u003eCreate exceptions for known update processes or deployment scripts that regularly alter these files to reduce false positives, as suggested in the false positive analysis.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-02T12:00:00Z","date_published":"2026-04-02T12:00:00Z","id":"/briefs/2026-04-ssh-authorized-keys-modification-inside-a-container/","summary":"The rule detects the creation or modification of an authorized_keys file inside a container, a technique used by adversaries to maintain persistence on a victim host by adding their own public key(s) to enable unauthorized SSH access for lateral movement or privilege escalation.","title":"SSH Authorized Key File Modification Inside a Container","url":"https://feed.craftedsignal.io/briefs/2026-04-ssh-authorized-keys-modification-inside-a-container/"},{"_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":["Auditd Manager"],"_cs_severities":["medium"],"_cs_tags":["command-and-control","execution","container","auditd","linux"],"_cs_type":"advisory","_cs_vendors":["Elastic"],"content_html":"\u003cp\u003eThis detection rule identifies instances of \u003ccode\u003ecurl\u003c/code\u003e or \u003ccode\u003ewget\u003c/code\u003e being executed from within containers managed by \u003ccode\u003erunc\u003c/code\u003e on Linux systems. The rule leverages Auditd Manager to monitor system calls and flags processes running with the title \u003ccode\u003erunc init\u003c/code\u003e that then execute \u003ccode\u003ecurl\u003c/code\u003e or \u003ccode\u003ewget\u003c/code\u003e. This activity is noteworthy because attackers often use these tools to download malicious payloads (stagers, scripts, implants) or to exfiltrate data after compromising a container. While these tools can be used legitimately within containers, their execution in the context of \u003ccode\u003erunc init\u003c/code\u003e suggests a higher risk of malicious activity. The rule focuses on narrowing the signal to the container runtime boundary where unexpected download clients are more worthy of review. The rule specifically leverages Auditd Manager for data collection.\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 host system, possibly through exploiting a vulnerability in an application running outside the container (e.g., web application).\u003c/li\u003e\n\u003cli\u003eThe attacker identifies a containerized application running on the compromised host.\u003c/li\u003e\n\u003cli\u003eThe attacker exploits a vulnerability within the container, or abuses a privileged workload within the container, to gain elevated privileges or code execution within the container.\u003c/li\u003e\n\u003cli\u003eThe attacker uses \u003ccode\u003ecurl\u003c/code\u003e or \u003ccode\u003ewget\u003c/code\u003e to download additional tools or scripts into the container. These tools might include reverse shells, credential dumping tools, or data exfiltration utilities.\u003c/li\u003e\n\u003cli\u003eThe attacker executes the downloaded tools to further compromise the container or the underlying host.\u003c/li\u003e\n\u003cli\u003eThe attacker uses \u003ccode\u003ecurl\u003c/code\u003e or \u003ccode\u003ewget\u003c/code\u003e to stage data for exfiltration to an external server. This may involve compressing and encoding data before transmission.\u003c/li\u003e\n\u003cli\u003eThe attacker initiates the data exfiltration process using \u003ccode\u003ecurl\u003c/code\u003e or \u003ccode\u003ewget\u003c/code\u003e to send the staged data to a remote server controlled by the attacker.\u003c/li\u003e\n\u003cli\u003eThe attacker achieves their final objective, which could include data theft, system disruption, or further lateral movement within the network.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eCompromised containers can lead to data breaches, service disruptions, and further attacks on internal systems. Successful exploitation could allow attackers to steal sensitive data, install malware, or pivot to other parts of the network, impacting confidentiality, integrity, and availability. The number of affected systems depends on the scope of the container deployment and the privileges granted to the compromised container.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eDetect Curl or Wget Execution from Container Context\u003c/code\u003e to your SIEM and tune for your environment.\u003c/li\u003e\n\u003cli\u003eEnable Auditd Manager with syscall coverage including \u003ccode\u003eexecve\u003c/code\u003e to capture process execution and arguments within containers, as mentioned in the rule\u0026rsquo;s setup instructions.\u003c/li\u003e\n\u003cli\u003eCorrelate alerts from this rule with network logs to identify the destination IP addresses and domains contacted by the compromised container.\u003c/li\u003e\n\u003cli\u003eBaseline trusted images and exclude stable image digests or namespaces when noisy to reduce false positives, as suggested in the rule\u0026rsquo;s false positives section.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-23T12:00:00Z","date_published":"2024-01-23T12:00:00Z","id":"/briefs/2024-01-curl-wget-container-execution/","summary":"This rule detects the execution of curl or wget from within runc-backed containers on Linux systems monitored by Auditd Manager, indicating potential ingress tool transfer or data exfiltration by attackers who have compromised the container.","title":"Curl or Wget Execution from Container Context","url":"https://feed.craftedsignal.io/briefs/2024-01-curl-wget-container-execution/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Auditd Manager"],"_cs_severities":["high"],"_cs_tags":["container","privilege-escalation","linux"],"_cs_type":"advisory","_cs_vendors":["Elastic"],"content_html":"\u003cp\u003eThis detection identifies a potential privilege escalation vulnerability within container environments utilizing \u003ccode\u003erunc\u003c/code\u003e, the low-level container runtime used by Docker and containerd. The rule focuses on audit events triggered by \u003ccode\u003erunc init\u003c/code\u003e child processes. Specifically, it flags instances where the effective user ID is root (0), while the login user ID is not root. This discrepancy can indicate malicious activity, such as exploiting credential separation or namespace transitions to gain unauthorized root privileges within the container or escape to the host. This is relevant for defenders because a compromised container can lead to host compromise, data exfiltration, or denial of service.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAttacker gains initial access to a container with limited privileges.\u003c/li\u003e\n\u003cli\u003eThe attacker exploits a vulnerability within the container to execute code as the \u003ccode\u003erunc init\u003c/code\u003e process.\u003c/li\u003e\n\u003cli\u003eThe \u003ccode\u003erunc init\u003c/code\u003e process spawns a child process while retaining a non-root user ID in audit telemetry.\u003c/li\u003e\n\u003cli\u003eThe child process is assigned an effective user ID of 0 (root), bypassing normal permission controls.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages the elevated privileges to modify sensitive files or execute commands as root within the container\u0026rsquo;s namespace.\u003c/li\u003e\n\u003cli\u003eThe attacker may then attempt to escape the container by exploiting kernel vulnerabilities or misconfigurations to gain access to the host system.\u003c/li\u003e\n\u003cli\u003eUpon gaining access to the host system, the attacker can install malware, steal sensitive data, or disrupt services.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA successful privilege escalation attack within a container environment can lead to complete compromise of the container and potentially the host system. This can result in data breaches, service disruptions, and unauthorized access to sensitive resources. The impact is significant because a single compromised container can become a launchpad for attacks against other containers or the underlying infrastructure.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Potential Privilege Escalation via Runc Init\u0026rdquo; to your SIEM to detect suspicious \u003ccode\u003erunc init\u003c/code\u003e process executions.\u003c/li\u003e\n\u003cli\u003eEnable Linux audit logging via the Auditd Manager integration, ensuring that \u003ccode\u003eexecve\u003c/code\u003e and identity-related fields are captured.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the Sigma rule by examining the full audit event details, including process ancestry, user IDs, and container metadata.\u003c/li\u003e\n\u003cli\u003eReview container configurations and security profiles to identify potential misconfigurations that could facilitate privilege escalation.\u003c/li\u003e\n\u003cli\u003eImplement network segmentation to limit the blast radius of a compromised container.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-05T14:22:00Z","date_published":"2024-01-05T14:22:00Z","id":"/briefs/2024-01-runc-privilege-escalation/","summary":"Detection of runc init child processes with root effective user and non-root login user ID, indicating potential container privilege escalation.","title":"Potential Privilege Escalation in Container via Runc Init","url":"https://feed.craftedsignal.io/briefs/2024-01-runc-privilege-escalation/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["high"],"_cs_tags":["privilege-escalation","linux","container"],"_cs_type":"advisory","_cs_vendors":["Elastic"],"content_html":"\u003cp\u003eThis detection identifies instances where the \u003ccode\u003ensenter\u003c/code\u003e command is used to enter a process namespace, specifically targeting a PID. This technique is often employed to attach to the host\u0026rsquo;s init namespace from a container or session, effectively allowing the attacker to execute commands within the host\u0026rsquo;s context. This behavior is concerning because it can be used to escalate privileges and gain unauthorized access to the underlying system. This is especially relevant in containerized environments where attackers may attempt to escape the container and access the host system. The rule leverages Auditd logs to identify these \u003ccode\u003ensenter\u003c/code\u003e executions, focusing on those that include the \u003ccode\u003e--target\u003c/code\u003e or \u003ccode\u003e-t\u003c/code\u003e flags, which specify the target PID for namespace entry.\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 or a restricted session on a Linux host.\u003c/li\u003e\n\u003cli\u003eThe attacker identifies a target PID, often the init process (PID 1), to enter its namespace.\u003c/li\u003e\n\u003cli\u003eThe attacker executes the \u003ccode\u003ensenter\u003c/code\u003e command with the \u003ccode\u003e--target\u003c/code\u003e or \u003ccode\u003e-t\u003c/code\u003e flag, specifying the target PID. Additional namespace flags like \u003ccode\u003e--mount\u003c/code\u003e, \u003ccode\u003e--uts\u003c/code\u003e, \u003ccode\u003e--ipc\u003c/code\u003e, \u003ccode\u003e--net\u003c/code\u003e, and \u003ccode\u003e--user\u003c/code\u003e may also be used.\u003c/li\u003e\n\u003cli\u003eAuditd logs the \u003ccode\u003ensenter\u003c/code\u003e execution, capturing the process name, arguments, and other relevant metadata.\u003c/li\u003e\n\u003cli\u003eThe detection rule identifies the \u003ccode\u003ensenter\u003c/code\u003e execution based on the command name and the presence of the \u003ccode\u003e--target\u003c/code\u003e or \u003ccode\u003e-t\u003c/code\u003e flag.\u003c/li\u003e\n\u003cli\u003eThe attacker, now within the target PID\u0026rsquo;s namespace, executes commands with the privileges of that process. This may include reading sensitive files, modifying system configurations, or executing malicious code.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages the escalated privileges to further compromise the host system, potentially gaining root access or deploying malware.\u003c/li\u003e\n\u003cli\u003eThe attacker establishes persistence mechanisms to maintain access to the compromised host, such as creating new systemd units or modifying existing ones.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation can lead to complete compromise of the host system. Attackers can gain root privileges, access sensitive data, and deploy malware. In containerized environments, this can allow attackers to escape the container and access the underlying host, potentially affecting other containers running on the same host. The impact is especially significant in production environments where compromised hosts can disrupt critical services and expose sensitive data.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Auditd Manager integration on Linux hosts to collect process execution telemetry, as specified in the \u003ca href=\"#setup\"\u003esetup instructions\u003c/a\u003e.\u003c/li\u003e\n\u003cli\u003eImplement the Sigma rule \u0026ldquo;Nsenter to PID Namespace via Auditd\u0026rdquo; to detect suspicious \u003ccode\u003ensenter\u003c/code\u003e executions.\u003c/li\u003e\n\u003cli\u003eTune the Sigma rule by excluding known false positives, such as legitimate \u003ccode\u003ensenter\u003c/code\u003e executions by platform engineers or CNI/snap workflows, as mentioned in the \u003ca href=\"#false-positive-analysis\"\u003efalse positives section\u003c/a\u003e.\u003c/li\u003e\n\u003cli\u003eInvestigate any detected \u003ccode\u003ensenter\u003c/code\u003e executions by reviewing process arguments, parent processes, user identities, and host information, as outlined in the \u003ca href=\"#triage-and-analysis\"\u003etriage and analysis section\u003c/a\u003e.\u003c/li\u003e\n\u003cli\u003eIsolate any compromised hosts, revoke credentials, inspect for persistence, and re-image if integrity cannot be proven, as recommended in the \u003ca href=\"#response-and-remediation\"\u003eresponse and remediation section\u003c/a\u003e.\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-03-nsenter-pid-namespace/","summary":"This rule detects nsenter executions that target a PID with a namespace target flag, a common pattern used to attach to the host init namespace from a container or session and run with host context, potentially escalating privileges.","title":"Nsenter to PID Namespace via Auditd","url":"https://feed.craftedsignal.io/briefs/2024-01-03-nsenter-pid-namespace/"},{"_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":["Auditbeat","Auditd Manager","Docker","containerd","kubelet"],"_cs_severities":["medium"],"_cs_tags":["container","privilege-escalation","lateral-movement","linux"],"_cs_type":"advisory","_cs_vendors":["Elastic","Docker","Kubernetes"],"content_html":"\u003cp\u003eThis threat involves unauthorized processes connecting directly to container runtime sockets (Docker or Containerd) on Linux systems. This bypasses Kubernetes API server restrictions, potentially allowing attackers to create, execute, or manipulate containers without proper authorization or logging. The risk lies in attackers circumventing RBAC, admission webhooks, and pod security standards. The attack can start when a compromised process attempts to connect to the Docker or Containerd socket, potentially leading to privilege escalation and lateral movement within the containerized environment. This attack is significant because it undermines core security controls within container orchestration platforms.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eA malicious or compromised process gains initial access to the host system.\u003c/li\u003e\n\u003cli\u003eThe process attempts to connect to the container runtime socket (e.g., \u003ccode\u003e/var/run/docker.sock\u003c/code\u003e or \u003ccode\u003e/run/containerd/containerd.sock\u003c/code\u003e).\u003c/li\u003e\n\u003cli\u003eThe process bypasses the Kubernetes API server and associated security controls.\u003c/li\u003e\n\u003cli\u003eThe attacker exploits the direct socket connection to create a new container.\u003c/li\u003e\n\u003cli\u003eThe attacker gains access to sensitive data or resources within the container.\u003c/li\u003e\n\u003cli\u003eThe attacker escalates privileges within the compromised container.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the compromised container to move laterally to other containers or hosts within the environment.\u003c/li\u003e\n\u003cli\u003eThe attacker achieves their objective, such as data exfiltration or system compromise.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation allows attackers to bypass Kubernetes security measures, create unauthorized containers, and potentially gain control over the entire cluster. The observed impact includes privilege escalation, lateral movement, and data exfiltration. The severity of this attack depends on the level of access granted to the compromised container and the sensitivity of the data and resources within the cluster.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eEnable Auditd Manager to capture network and socket events, specifically monitoring for \u003ccode\u003econnect\u003c/code\u003e calls to Unix sockets as described in the \u003ca href=\"https://docs.elastic.co/integrations/auditd_manager\"\u003eAuditd Manager documentation\u003c/a\u003e.\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Unusual Process Connecting to Docker or Containerd Socket\u0026rdquo; to detect suspicious processes connecting to container runtime sockets, tuning \u003ccode\u003eprocess.executable\u003c/code\u003e and \u003ccode\u003euser.name\u003c/code\u003e for known legitimate processes.\u003c/li\u003e\n\u003cli\u003eMonitor file permissions on the socket paths (\u003ccode\u003e/var/run/docker.sock\u003c/code\u003e, \u003ccode\u003e/run/docker.sock\u003c/code\u003e, \u003ccode\u003e/var/run/containerd/containerd.sock\u003c/code\u003e, \u003ccode\u003e/run/containerd/containerd.sock\u003c/code\u003e) and restrict access to trusted groups only.\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-unusual-container-socket-connection/","summary":"An unusual process connecting to a container runtime Unix socket like Docker or Containerd can indicate an attacker attempting to bypass Kubernetes security measures for container manipulation.","title":"Unusual Process Connecting to Docker or Containerd Socket","url":"https://feed.craftedsignal.io/briefs/2024-01-unusual-container-socket-connection/"},{"_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":[],"_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":["Defend for Containers"],"_cs_severities":["high"],"_cs_tags":["container","privilege-escalation","linux"],"_cs_type":"advisory","_cs_vendors":["Elastic"],"content_html":"\u003cp\u003eThis detection identifies the execution of \u003ccode\u003ensenter\u003c/code\u003e within a Linux container, specifically when the \u003ccode\u003e-t\u003c/code\u003e or \u003ccode\u003e--target\u003c/code\u003e flag is used. This flag indicates an attempt to enter another process or namespace context. Attackers can exploit this capability, especially when combined with privileged mounts, exposed PIDs, or shared namespaces, to escape the container and pivot to the host system. This activity can lead to privilege escalation and further compromise of the underlying infrastructure. The detection is relevant for environments using Elastic Defend for Containers.\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, possibly through exploiting a vulnerability in a containerized application.\u003c/li\u003e\n\u003cli\u003eThe attacker identifies a container with weak configurations, such as exposed PIDs, shared namespaces, or privileged mounts.\u003c/li\u003e\n\u003cli\u003eThe attacker executes \u003ccode\u003ensenter\u003c/code\u003e with the \u003ccode\u003e-t\u003c/code\u003e or \u003ccode\u003e--target\u003c/code\u003e flag, specifying a target PID or namespace.\u003c/li\u003e\n\u003cli\u003eThe \u003ccode\u003ensenter\u003c/code\u003e command joins the target namespace (mount, network, PID, user, or IPC) based on specified flags (\u003ccode\u003e-m\u003c/code\u003e, \u003ccode\u003e-n\u003c/code\u003e, \u003ccode\u003e-p\u003c/code\u003e, \u003ccode\u003e-U\u003c/code\u003e, or \u003ccode\u003e-i\u003c/code\u003e).\u003c/li\u003e\n\u003cli\u003eThe attacker gains access to the host system\u0026rsquo;s resources or processes due to the namespace sharing or privileged access.\u003c/li\u003e\n\u003cli\u003eThe attacker escalates privileges on the host system, potentially gaining root access.\u003c/li\u003e\n\u003cli\u003eThe attacker pivots to other containers or the host infrastructure, expanding their control.\u003c/li\u003e\n\u003cli\u003eThe attacker achieves their final objective, such as data exfiltration, system disruption, or deploying malware on the host.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA successful container escape can allow an attacker to compromise the underlying host system. This can lead to the compromise of other containers running on the same host, as well as sensitive data stored on the host system. The impact can range from data breaches to complete infrastructure takeover. If the host is a node in a Kubernetes cluster, the attacker might be able to compromise the entire cluster.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eDetect Nsenter Container Escape\u003c/code\u003e to your SIEM and tune for your environment to detect suspicious \u003ccode\u003ensenter\u003c/code\u003e executions within containers.\u003c/li\u003e\n\u003cli\u003eReview container configurations and enforce least privilege to prevent unauthorized namespace sharing and privileged mounts.\u003c/li\u003e\n\u003cli\u003eMonitor container logs for \u003ccode\u003ensenter\u003c/code\u003e executions with target flags, as indicated by the log source \u003ccode\u003elogs-cloud_defend.process*\u003c/code\u003e and the query in this brief.\u003c/li\u003e\n\u003cli\u003eRestrict the use of hostPath volumes and other sensitive mounts within container deployments.\u003c/li\u003e\n\u003cli\u003eReduce recurrence by avoiding host namespace sharing, restricting hostPath and sensitive mounts, and blocking unnecessary capabilities.\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-nsenter-container-escape/","summary":"The rule detects nsenter executions from inside a monitored Linux container that include a namespace target flag (-t or --target), which can be abused to escape container isolation.","title":"Nsenter Execution with Target Flag Inside Container","url":"https://feed.craftedsignal.io/briefs/2024-01-nsenter-container-escape/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Defend for Containers"],"_cs_severities":["high"],"_cs_tags":["container","kubeletctl","lateral-movement","execution"],"_cs_type":"advisory","_cs_vendors":["Elastic"],"content_html":"\u003cp\u003eThis rule detects the execution of \u003ccode\u003ekubeletctl\u003c/code\u003e inside a container. Kubeletctl is a command-line tool that interacts with the Kubelet API directly, making the often undocumented API more accessible. Attackers may use it to enumerate the Kubelet API or other resources within the container, potentially indicating lateral movement within the pod. The detection is based on the \u0026ldquo;Defend for Containers\u0026rdquo; integration (version 9.3.0 and later) within the Elastic stack. This activity is significant because \u003ccode\u003ekubeletctl\u003c/code\u003e can expose pod and node details, enabling actions that facilitate discovery and lateral movement from a compromised container.\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, possibly through a vulnerability in the containerized application or a misconfigured Kubernetes environment.\u003c/li\u003e\n\u003cli\u003eThe attacker executes \u003ccode\u003ekubeletctl\u003c/code\u003e inside the compromised container. This could be facilitated by the tool being present in the container image or downloaded post-compromise.\u003c/li\u003e\n\u003cli\u003eThe attacker uses \u003ccode\u003ekubeletctl scan\u003c/code\u003e to discover Kubelet endpoints within the Kubernetes cluster.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages \u003ccode\u003ekubeletctl pods\u003c/code\u003e or \u003ccode\u003ekubeletctl runningpods\u003c/code\u003e to enumerate running pods and their details.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the discovered pod information to identify potential targets for lateral movement.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to use \u003ccode\u003ekubeletctl exec\u003c/code\u003e or \u003ccode\u003ekubeletctl attach\u003c/code\u003e to gain access to other pods within the cluster.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to port forward using \u003ccode\u003ekubeletctl portForward\u003c/code\u003e to establish connections to services running in other pods.\u003c/li\u003e\n\u003cli\u003eUpon successful lateral movement, the attacker performs further reconnaissance or deploys malicious payloads to achieve their objectives, such as data exfiltration or denial-of-service.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful execution of \u003ccode\u003ekubeletctl\u003c/code\u003e within a container can lead to the exposure of sensitive information about the Kubernetes cluster, including pod details and internal network configurations. This can enable attackers to move laterally within the cluster, potentially compromising other applications and data. The impact could range from data breaches and service disruptions to full cluster compromise depending on the attacker\u0026rsquo;s objectives and the scope of the compromised container\u0026rsquo;s access.\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 the execution of \u003ccode\u003ekubeletctl\u003c/code\u003e within containers based on process name and arguments.\u003c/li\u003e\n\u003cli\u003eMonitor container network activity for connections to node addresses on Kubelet ports (commonly 10250/10255) and investigate any suspicious patterns.\u003c/li\u003e\n\u003cli\u003eImplement network policies to restrict pod-to-node access to the Kubelet API.\u003c/li\u003e\n\u003cli\u003eHarden container images by removing unnecessary tools like \u003ccode\u003ekubeletctl\u003c/code\u003e and enforce least privilege principles.\u003c/li\u003e\n\u003cli\u003eEnable and review Kubernetes audit logs to identify the source of interactive sessions into containers, correlating with timestamps of \u003ccode\u003ekubeletctl\u003c/code\u003e execution.\u003c/li\u003e\n\u003cli\u003eEnforce Pod Security Standards to restrict privileged pods and limit node API exposure.\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-container-execution/","summary":"This rule detects the execution of kubeletctl inside a container, which can be used to enumerate the Kubelet API or other resources inside the container, potentially indicating lateral movement attempts within the pod.","title":"Kubeletctl Execution Inside Container Detected","url":"https://feed.craftedsignal.io/briefs/2024-01-kubeletctl-container-execution/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Gotenberg \u003c= 8.30.1"],"_cs_severities":["critical"],"_cs_tags":["argument-injection","vulnerability","container"],"_cs_type":"advisory","_cs_vendors":["Gotenberg"],"content_html":"\u003cp\u003eGotenberg, a Docker-based solution for converting various document formats to PDF, is vulnerable to an argument injection flaw affecting versions 8.30.1 and earlier. This vulnerability stems from insufficient sanitization of metadata values passed to the ExifTool during PDF processing. Specifically, the application fails to properly sanitize newline characters within metadata values. By exploiting this flaw, an unauthenticated attacker can inject arbitrary ExifTool pseudo-tags, such as \u003ccode\u003e-FileName\u003c/code\u003e, \u003ccode\u003e-Directory\u003c/code\u003e, \u003ccode\u003e-SymLink\u003c/code\u003e, and \u003ccode\u003e-HardLink\u003c/code\u003e, allowing for unauthorized file manipulation, including renaming, moving, overwriting, and creating symbolic or hard links to files within the container\u0026rsquo;s filesystem. The vulnerability is a bypass of an incomplete key sanitization fix introduced in version 8.30.1, highlighting the importance of thorough input validation.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker crafts a malicious PDF file or uses an existing PDF.\u003c/li\u003e\n\u003cli\u003eThe attacker injects a newline character followed by an ExifTool pseudo-tag (e.g., \u003ccode\u003e-FileName=/tmp/inject_proof\u003c/code\u003e) into a metadata value (e.g., the \u0026lsquo;Title\u0026rsquo; field).\u003c/li\u003e\n\u003cli\u003eThe attacker sends the PDF, along with the crafted metadata, to the Gotenberg \u003ccode\u003e/forms/pdfengines/metadata/write\u003c/code\u003e endpoint via a POST request.\u003c/li\u003e\n\u003cli\u003eGotenberg\u0026rsquo;s \u003ccode\u003eWriteMetadata\u003c/code\u003e function in \u003ccode\u003epkg/modules/exiftool/exiftool.go\u003c/code\u003e processes the metadata.\u003c/li\u003e\n\u003cli\u003eThe unsanitized metadata value is passed to \u003ccode\u003ego-exiftool\u003c/code\u003e\u0026rsquo;s \u003ccode\u003eSetString\u003c/code\u003e function.\u003c/li\u003e\n\u003cli\u003e\u003ccode\u003ego-exiftool\u003c/code\u003e writes the key-value pair to ExifTool\u0026rsquo;s stdin using \u003ccode\u003efmt.Fprintln(e.stdin, \u0026quot;-\u0026quot;+k+\u0026quot;=\u0026quot;+str)\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe newline character splits the ExifTool stdin line into two separate arguments, injecting the attacker\u0026rsquo;s pseudo-tag.\u003c/li\u003e\n\u003cli\u003eExifTool executes the injected command (e.g., moving the PDF to \u003ccode\u003e/tmp/inject_proof\u003c/code\u003e).\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation allows an unauthenticated attacker to rename or move any PDF being processed to an arbitrary path within the container filesystem, which runs as root by default. This also enables overwriting arbitrary files (e.g., corrupting the \u003ccode\u003e/etc/passwd\u003c/code\u003e file), creating symlinks, and creating hard links. The container filesystem becomes fully exposed to arbitrary file manipulation.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eApply value sanitization parallel to the existing key check in \u003ccode\u003eWriteMetadata\u003c/code\u003e as described in the advisory.\u003c/li\u003e\n\u003cli\u003eImplement detection rules to identify attempts to exploit the vulnerability by monitoring for suspicious characters in HTTP requests to the \u003ccode\u003e/forms/pdfengines/metadata/write\u003c/code\u003e endpoint using the provided Sigma rule.\u003c/li\u003e\n\u003cli\u003eMonitor for unexpected file modifications within the Gotenberg container, especially the creation or modification of symbolic links and hard links, using \u003ccode\u003efile_event\u003c/code\u003e log source.\u003c/li\u003e\n\u003cli\u003eUpgrade to a patched version of Gotenberg that addresses this vulnerability to prevent exploitation (CVE-2026-40281).\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-02-gotenberg-exiftool-injection/","summary":"Gotenberg version 8.30.1 and earlier is vulnerable to argument injection, where an unauthenticated attacker can inject arbitrary ExifTool pseudo-tags via newline characters in metadata values, leading to arbitrary file manipulation within the container filesystem.","title":"Gotenberg ExifTool Argument Injection via Metadata Values","url":"https://feed.craftedsignal.io/briefs/2024-01-02-gotenberg-exiftool-injection/"}],"language":"en","title":"CraftedSignal Threat Feed — Container","version":"https://jsonfeed.org/version/1.1"}