Detection of Malicious Reverse Shell Patterns in Kubernetes Pod Exec Requests

This threat brief focuses on detecting unauthorized interactive access within Kubernetes clusters via the 'exec' subresource. Threat actors often leverage the Kubernetes API to execute commands within running containers to establish persistent or interactive command-and-control channels. The analyzed detection logic monitors Kubernetes audit logs for specific command-line idioms associated with reverse and bind shells, such as the use of /dev/tcp, netcat, socat, and various scripting language socket libraries. This behavior is a common indicator of post-exploitation movement where an attacker, having gained access to the Kubernetes API, attempts to escalate their foothold by transitioning from a single container execution to a persistent shell session. Defenders should monitor for these patterns to identify unauthorized container administration and potential command-and-control activity.

Attack Chain

1. Attacker gains authentication to the Kubernetes API server (e.g., via compromised kubeconfig, service account token, or SSRF).
2. Attacker performs enumeration to identify pods and containers within the cluster.
3. Attacker identifies a target container for exploitation.
4. Attacker invokes the kubectl exec command or makes a direct REST API call to the pod's 'exec' subresource.
5. The API request URI is crafted to include a shell payload (e.g., bash -i >& /dev/tcp/...).
6. The container executes the malicious payload, which initiates an outbound connection to an attacker-controlled listener.
7. A reverse shell is established, granting the attacker interactive access to the container environment.
8. Attacker proceeds to lateral movement or data exfiltration from the compromised container.

Impact

Successful exploitation allows for unauthorized interactive shell access to containerized workloads, enabling attackers to execute arbitrary code, steal secrets from the container filesystem or environment variables, and facilitate lateral movement throughout the cluster. Impact can range from individual workload compromise to full cluster persistence depending on the privileges assigned to the accessed pod or service account.

Recommendation

• Implement the detection logic described in the provided audit rule to monitor for suspicious command patterns within exec requests.
• Review all users and service accounts with the ability to execute commands in pods (pods/exec permissions) and enforce the principle of least privilege.
• Baseline authorized container image commands and block unauthorized binaries like socat or nc from being executed in production containers.
• Enable Kubernetes API Server Audit logging to a centralized SIEM to provide the telemetry required for detecting these 'exec' patterns.
• Deploy automated responses to terminate suspicious exec sessions identified by the monitoring logic.