Researchers documented the first evidence of attackers abusing Kubernetes RBAC to backdoor clusters, using DaemonSets to hijack resources and mining Monero across numerous targets. The activity highlights how misconfigurations can enable persistence and widespread impact, with about 60 exposed clusters affected and a typosquatting image used in the campaign. #RBACBuster #KubernetesRBAC #kuberntesio/kube-controller #Monero #DaemonSet #typosquatting #DockerHub
Keypoints
- The attack demonstrates the first-ever in-the-wild use of Kubernetes RBAC to create backdoors and persistence.
- Initial access came through a misconfigured API server that allowed unauthenticated requests from anonymous users with privileges.
- The attacker used RBAC to gain persistence by creating a near-admin ClusterRole, a kube-system ServiceAccount, and a ClusterRoleBinding to persist.
- A DaemonSet was deployed to run containers on all nodes, hijacking cluster resources (container image: kuberntesio/kube-controller:1.0.1).
- The cryptominer inside the image was detected (MD5 of the kube-controller binary: 2833c82055bf2d29c65cd9cf6684449a).
- Typosquatting was used to impersonate legitimate Kubernetes components, with the image kuberntesio/kube-controller mimicking kubernetesio/kube-controller-manager and amassing millions of pulls.
- Beacons and exposed AWS keys indicate the attacker attempted to pivot to cloud resources and steal additional assets.
- Microsoft’s threat matrix for Kubernetes was used to map techniques, with the campaign named “RBAC Buster.”
- Mitigation suggestions include Aqua Trivy for vulnerability/secret/misconfiguration detection and Aqua CNAPP for defense in depth.
MITRE Techniques
- [T1190] Exploit Public-Facing Application – The attacker gained initial access via a misconfigured API server that allowed unauthenticated requests from anonymous users with privileges. “The initial access was gained via a misconfigured API server that allowed unauthenticated requests from anonymous users with privileges.”
- [T1036] Masquerading – The attacker blended with logs and persistence mechanisms to evade detection, “persist under the radar without setting off any alarms.”
- [T1543] Create or Modify System Process – The attacker created a near-admin ClusterRole, a kube-system ServiceAccount named kube-controller, and a ClusterRoleBinding to establish lasting persistence. “created a ClusterRoleBinding, binding the ClusterRole with the ServiceAccount to create a strong and inconspicuous persistence.”
- [T1105] Ingress Tool Transfer – The DaemonSet used a container image hosted on Docker Hub, demonstrating external tool acquisition. “The DaemonSet creation request object contained the container image ‘kuberntesio/kube-controller:1.0.1’, hosted on the public registry Docker Hub.”
- [T1078.003] Valid Accounts: Cloud Accounts – AWS keys were exposed and used to attempt access to the cloud provider account. “we exposed AWS access keys in various locations on the cluster… the access keys were used by the attacker to try and gain further access to the target’s cloud service provider account.”
- [T1583] Acquire Infrastructure – Typosquatting on container images to impersonate legitimate components and host on Docker Hub. “The container image named ‘kuberntesio/kube-controller’ is a case of typosquatting that impersonates the legitimate ‘kubernetesio’ account.”
- [T1496] Resource Hijacking – DaemonSet deployed across nodes to hijack cluster resources for cryptomining. “The impact on the cluster was resource hijacking.”
- [T1083] – File and Directory Discovery (Discovery of cluster state) – The attacker listed secrets and queried cluster information. “The attacker sent a few HTTP requests to list secrets and then made two API requests to gain information about the cluster by listing the entities in the ‘kube-system’ namespace.”
Indicators of Compromise
- [File hash] 2833c82055bf2d29c65cd9cf6684449a – Kube-controller binary inside the malicious container image
- [Container Image] kuberntesio/kube-controller:1.0.1 – Used across the attack to deploy miners
- [Deployment Names] kube-controller, kube-secure-fhgxtsjh, kube-secure-fhgxt, api-proxy, worker-deployment – Names checked during cluster activity
- [Wallet Address] – Wallet address mined 5 XMR (exact address not disclosed in article)
- [Source / Registry] Docker Hub – Public registry hosting the malicious image
- [Exposed Clusters] 60 exposed Kubernetes clusters with evidence of activity
Read more: https://blog.aquasec.com/leveraging-kubernetes-rbac-to-backdoor-clusters