{"id":16016,"date":"2026-03-30T09:04:17","date_gmt":"2026-03-30T09:04:17","guid":{"rendered":"https:\/\/newestek.com\/?p=16016"},"modified":"2026-03-30T09:04:17","modified_gmt":"2026-03-30T09:04:17","slug":"why-kubernetes-controllers-are-the-perfect-backdoor","status":"publish","type":"post","link":"https:\/\/newestek.com\/?p=16016","title":{"rendered":"Why Kubernetes controllers are the perfect backdoor"},"content":{"rendered":"
\n
\n
\n
\n
\n
\n
<\/div>\n<\/section>\n

In my years securing cloud-native environments, I\u2019ve noticed a recurring blind spot. We obsess over the \u201cfront doors\u201d such as exposed dashboards, misconfigured RBAC<\/a>, or unpatched container vulnerabilities. We harden the perimeter, but we often ignore the machinery humming inside.\u00a0<\/p>\n

Sophisticated adversaries have moved beyond simple smash-and-grab tactics. They don\u2019t just want to run a crypto miner for a few hours; they want persistence. They want a foothold that survives a node reboot, a pod restart, or even a cluster upgrade.\u00a0<\/p>\n

The most dangerous, overlooked mechanism for this persistence is the Kubernetes Controller Pattern. By compromising or registering a rogue controller, an attacker turns the cluster\u2019s own automation against it, creating a self-healing backdoor that is incredibly difficult to detect. It\u2019s the ultimate \u201cliving off the land\u201d technique for the cloud age.\u00a0<\/p>\n

Weaponizing the control loop\u00a0<\/h2>\n

At its core, Kubernetes is an automation engine. It constantly compares the desired state<\/em> (YAML) with the actual state<\/em> (running pods) and reconciles the difference. This logic lives in Controllers<\/a>.\u00a0<\/p>\n

A malicious controller works by subscribing to cluster events. Instead of deploying an application, it watches for specific triggers, such as the creation of a new namespace or the deployment of a specific secret, and automatically injects malicious code.\u00a0<\/p>\n

Scenario: The \u201cshadow\u201d sidecar injector\u00a0<\/h2>\n

We saw this play out in the wild with Siloscape, a sophisticated malware campaign uncovered by Palo Alto Networks Unit 42<\/a>. Unlike typical cryptojacking scripts, Siloscape didn\u2019t just want compute resources; it wanted the cluster itself. It targeted Windows containers, escaped to the underlying node, and used the node\u2019s credentials to spread via the API server.\u00a0<\/p>\n

Similarly, the TeamTNT group has been documented using the Hildegard<\/a> malware to exploit the kubelet API for persistence. These aren\u2019t theoretical classroom exercises. They are documented campaigns where attackers weaponized the control plane to turn Kubernetes against its owners.\u00a0<\/p>\n

Consider an attacker who gains similar limited write access to the cluster\u2019s API server<\/a>. This access might come from a compromised CI\/CD pipeline credential or a developer\u2019s leaked kubeconfig that has just enough permission to create MutatingWebhookConfigurations but not full cluster admin rights. The attacker doesn\u2019t need to deploy a workload directly; they just need to tell the API server to run their logic on everyone else\u2019s<\/em> workloads.\u00a0<\/p>\n

Instead of launching a conspicuous pod named mining-rig, they register a MutatingAdmissionWebhook<\/a>.\u00a0<\/p>\n

\n
Figure 1: Anatomy of a controller-based attack. The malicious webhook intercepts legitimate pod creation requests and injects a backdoor sidecar before the object is persisted to etcd.<\/em>\u00a0<\/figcaption><\/figure>\n

Niranjan Kumar Sharma<\/p>\n<\/div>\n

\u00a0<\/p>\n

As illustrated in Figure 1, this webhook acts as a controller. Every time a legitimate pod is created (e.g., a payment service), the API server sends the pod definition to the attacker\u2019s webhook for approval. The webhook modifies the pod spec to inject a malicious sidecar container before it is persisted to etcd.\u00a0<\/p>\n

The hidden danger:\u00a0<\/strong><\/p>\n

    \n
  1. It\u2019s invisible to kubectl get pods: <\/strong>The malicious sidecar is often hidden deep in the pod spec, and if the attacker uses a common name like proxy-agent, it blends in with legitimate mesh traffic.\u00a0<\/li>\n<\/ol>\n
      \n
    1. It survives cleanup:<\/strong> If you delete the compromised pod, the Deployment controller creates a new one. The new one triggers the webhook again, and the backdoor is re-injected. The persistence is baked into the lifecycle of the cluster itself.\u00a0<\/li>\n<\/ol>\n

      Mapping the threat:<\/strong> This technique maps to Persistence (TA0003)<\/a> in the MITRE ATT&CK for Containers matrix. It specifically leverages the cluster\u2019s own control loop to maintain access, making it far more resilient than traditional shell-based backdoors.\u00a0<\/p>\n

      Hunting ghosts in the API\u00a0<\/h2>\n

      To catch this, you have to look beyond standard logs. You need to audit the cluster\u2019s control plane configuration.\u00a0<\/p>\n

      1. Audit MutatingWebhookConfigurations\u00a0<\/strong><\/p>\n

      Run this command to see who is intercepting your pod creations:\u00a0<\/p>\n

      kubectl get mutatingwebhookconfigurations<\/code><\/pre>\n
      Look for webhooks pointing to external URLs or services in namespaces you don\u2019t recognize (e.g., kube-public or default). If you see a webhook named compliance-check pointing to an IP address outside your VPC, treat it as a massive red flag.\u00a0<\/p>\n
      2. Monitor RoleBinding changes\u00a0<\/strong><\/p>\n
      Controllers need permissions. A rogue controller needs a ServiceAccount<\/a> with elevated privileges to do damage. Monitor your audit logs for new RoleBindings<\/a> that grant watch or list permissions on Secrets or Pods.\u00a0<\/p>\n
      3. Check for anomalous OwnerReferences\u00a0<\/strong><\/p>\n
      Kubernetes objects use OwnerReferences<\/a> for garbage collection. If you see pods that claim to be owned by a controller that doesn\u2019t exist or doesn\u2019t match standard deployment patterns, investigate immediately.\u00a0<\/p>\n
      Locking down the machinery\u00a0<\/h2>\n
      To prevent controller-based persistence, you must restrict access to the machinery of the cluster.\u00a0<\/p>\n