{"description":"Trending threats, MITRE ATT\u0026CK coverage, and detection metadata — refreshed continuously.","feed_url":"https://feed.craftedsignal.io/tags/command_and_control/","home_page_url":"https://feed.craftedsignal.io/","items":[{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["medium"],"_cs_tags":["command_and_control","malware","llm"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eThis detection identifies instances where suspicious processes are communicating with known Large Language Model (LLM) endpoints. The activity suggests potential command and control behavior, where malware or unauthorized scripts leverage LLMs to dynamically execute actions on compromised systems. This behavior emerged in late 2025 and continues to evolve. The rule focuses on detecting DNS queries originating from unsigned binaries or common scripting utilities like PowerShell, \u003ccode\u003emshta.exe\u003c/code\u003e, and \u003ccode\u003ewscript.exe\u003c/code\u003e. The targeting scope includes both Windows and macOS systems. Defenders should be aware of this technique as attackers increasingly integrate LLMs to enhance malware capabilities and evade traditional detection methods.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eA user inadvertently executes a malicious script or binary, potentially delivered through social engineering or drive-by download.\u003c/li\u003e\n\u003cli\u003eThe malicious script, such as a PowerShell script or JavaScript within \u003ccode\u003emshta.exe\u003c/code\u003e, is launched.\u003c/li\u003e\n\u003cli\u003eThe script executes code to perform reconnaissance, gathering system information or user credentials.\u003c/li\u003e\n\u003cli\u003eThe script constructs a query for a Large Language Model (LLM) endpoint, such as \u003ccode\u003eapi.openai.com\u003c/code\u003e, using a common scripting utility.\u003c/li\u003e\n\u003cli\u003eThe DNS query is resolved, and a network connection is established to the LLM API endpoint, bypassing standard network security controls.\u003c/li\u003e\n\u003cli\u003eThe malicious script sends data to the LLM API, requesting instructions or performing tasks such as code generation or data exfiltration.\u003c/li\u003e\n\u003cli\u003eThe LLM responds with instructions or processed data, which the script then executes on the compromised system.\u003c/li\u003e\n\u003cli\u003eThe attacker gains control over the compromised system by leveraging the LLM to perform various malicious activities, like lateral movement or data theft.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eCompromised systems could be remotely controlled via LLM APIs, allowing attackers to perform data exfiltration, lateral movement, or deploy ransomware. Successful exploitation can lead to significant data breaches, financial loss, and reputational damage. The number of victims is currently unknown, but the attack vector affects organizations across all sectors.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rules in this brief to your SIEM to identify suspicious processes querying LLM endpoints.\u003c/li\u003e\n\u003cli\u003eEnable DNS query logging on both Windows and macOS endpoints to provide the necessary data source for the detections.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the Sigma rules, focusing on identifying the parent process and associated network activity.\u003c/li\u003e\n\u003cli\u003eImplement application control policies to restrict the execution of unsigned binaries and common scripting utilities from untrusted locations.\u003c/li\u003e\n\u003cli\u003eReview and update network firewall rules to restrict outbound connections to known malicious or suspicious domains.\u003c/li\u003e\n\u003cli\u003eMonitor process creation events for command-line arguments that indicate the use of scripting engines to perform DNS queries to LLM domains.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-22T16:34:10Z","date_published":"2026-04-22T16:34:10Z","id":"/briefs/2024-01-30-llm-command-and-control/","summary":"This rule detects DNS queries to known Large Language Model (LLM) domains by unsigned binaries or common Windows scripting utilities, indicating potential command and control activity leveraging LLMs for dynamic actions on compromised systems.","title":"Suspicious Processes Connecting to Large Language Model Endpoints","url":"https://feed.craftedsignal.io/briefs/2024-01-30-llm-command-and-control/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["low"],"_cs_tags":["kubectl","kubernetes","command_and_control","network_configuration","linux","macos"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eThis detection rule identifies potential malicious activity involving the \u003ccode\u003ekubectl\u003c/code\u003e command-line tool, specifically focusing on modifications to network configurations within Kubernetes environments. The rule monitors for \u003ccode\u003ekubectl\u003c/code\u003e commands executed with arguments like \u0026ldquo;port-forward\u0026rdquo;, \u0026ldquo;proxy\u0026rdquo;, or \u0026ldquo;expose,\u0026rdquo; which can be used to manipulate network settings. The activity is considered suspicious when initiated from atypical parent processes or directories, such as temporary folders or user home directories. This behavior might indicate an adversary attempting to establish unauthorized access channels or exfiltrate sensitive data. The rule is designed to work with endpoint detection and response (EDR) solutions like Elastic Defend, Crowdstrike, SentinelOne, and cloud workload protection platforms. The rule was last updated on March 30, 2026, and is intended for use in production environments.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains initial access to a system with \u003ccode\u003ekubectl\u003c/code\u003e installed and configured to interact with a Kubernetes cluster.\u003c/li\u003e\n\u003cli\u003eThe attacker executes the \u003ccode\u003ekubectl\u003c/code\u003e command with arguments like \u003ccode\u003eport-forward\u003c/code\u003e to create a local port that forwards traffic to a service or pod within the cluster.\u003c/li\u003e\n\u003cli\u003eThe attacker uses \u003ccode\u003ekubectl proxy\u003c/code\u003e to create a proxy server that allows them to access the Kubernetes API server from their local machine.\u003c/li\u003e\n\u003cli\u003eThe attacker employs \u003ccode\u003ekubectl expose\u003c/code\u003e to create a new service that exposes a deployment, replication controller, or pod as a new Kubernetes service, potentially opening up unintended access points.\u003c/li\u003e\n\u003cli\u003eThe attacker may execute these commands from a shell like \u003ccode\u003ebash\u003c/code\u003e, or from a script located in a temporary directory like \u003ccode\u003e/tmp/\u003c/code\u003e or \u003ccode\u003e/var/tmp/\u003c/code\u003e, to evade detection.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages the modified network configurations to establish unauthorized access to sensitive services or data within the Kubernetes cluster.\u003c/li\u003e\n\u003cli\u003eThe attacker may use the proxied or forwarded connections to exfiltrate data from the cluster to an external location.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation via \u003ccode\u003ekubectl\u003c/code\u003e network configuration modification can lead to unauthorized access to sensitive data and services within a Kubernetes cluster. This can result in data breaches, service disruptions, and lateral movement within the cluster. The low severity score suggests that while the risk exists, the impact might be limited if proper Kubernetes security best practices are followed. The rule aims to detect these actions early, preventing potential damage to the cluster.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eEnable Elastic Defend integration or equivalent EDR solutions to monitor process execution and network connections (\u003ccode\u003eData Source: Elastic Defend\u003c/code\u003e, \u003ccode\u003eData Source: Crowdstrike\u003c/code\u003e, \u003ccode\u003eData Source: SentinelOne\u003c/code\u003e).\u003c/li\u003e\n\u003cli\u003eDeploy the provided Sigma rule to detect suspicious \u003ccode\u003ekubectl\u003c/code\u003e commands with network-related arguments (\u003ccode\u003erules\u003c/code\u003e section). Tune the rule based on your environment to minimize false positives.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the Sigma rule, focusing on the parent process and the command-line arguments of the \u003ccode\u003ekubectl\u003c/code\u003e command (\u003ccode\u003erules\u003c/code\u003e section, \u003ccode\u003eResources: Investigation Guide\u003c/code\u003e).\u003c/li\u003e\n\u003cli\u003eImplement enhanced monitoring and logging for \u003ccode\u003ekubectl\u003c/code\u003e activities and network configuration changes within the Kubernetes cluster to proactively detect and respond to similar threats in the future (\u003ccode\u003eResources: Investigation Guide\u003c/code\u003e).\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-01T14:16:09Z","date_published":"2026-04-01T14:16:09Z","id":"/briefs/2026-05-kubectl-network-modification/","summary":"This rule detects potential kubectl network configuration modification activity by monitoring for process events where the kubectl command is executed with arguments that suggest an attempt to modify network configurations in Kubernetes, potentially leading to unauthorized access or data exfiltration.","title":"Kubectl Network Configuration Modification","url":"https://feed.craftedsignal.io/briefs/2026-05-kubectl-network-modification/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["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/"}],"language":"en","title":"CraftedSignal Threat Feed — Command_and_control","version":"https://jsonfeed.org/version/1.1"}