Kubernetes Controller – the perfect backdoor

The hidden dangers:

1. For kubectl get pods is this invisible: The malicious sidecar is often hidden deep in the pod specification. If the attacker has a common name like proxy-agent used, it merges with legitimate mesh traffic.
2. A cleanup doesn’t help: If the compromised pod is deleted, the deployment controller creates a new one. This triggers the webhook again and the backdoor is open again. Persistence is hard-wired into the cluster lifecycle itself.

This technique corresponds to Persistence (TA0003) in the MITER ATT&CK for Containers matrix. It specifically uses the cluster’s own control loop to maintain access. This makes them significantly more resilient than traditional, shell-based backdoors.

Ghost hunting in the API

To detect an attack of this type, you need to think beyond standard protocols. In other words, you need to audit the cluster’s control plane configuration. A three-step process is recommended:

1. MutatingWebhookConfigurations check

To see who is intercepting your pod creations, use the following command:

kubectl get mutatingwebhookconfigurations

Look for webhooks that point to external URLs or services in unknown namespaces, such as kube-public or default. You should use a webhook called compliance-check If you discover an IP address pointing to an IP address outside of your VPC, this is a serious red flag.