{
	"id": "0d2fce3f-2b5c-49ed-beef-9eec13fbe8be",
	"created_at": "2026-04-06T00:22:08.631165Z",
	"updated_at": "2026-04-10T03:21:53.187088Z",
	"deleted_at": null,
	"sha1_hash": "7a27f12bb5d2555455689a9b98e74d5ac0e48a09",
	"title": "First-Ever Attack Leveraging Kubernetes RBAC to Backdoor Clusters",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 176334,
	"plain_text": "First-Ever Attack Leveraging Kubernetes RBAC to Backdoor\r\nClusters\r\nBy Michael Katchinskiy\r\nPublished: 2023-04-21 · Archived: 2026-04-05 19:44:51 UTC\r\nWe have recently discovered the first-ever evidence that attackers are exploiting Kubernetes (K8s) Role-Based\r\nAccess Control (RBAC) in the wild to create backdoors. The attackers also deployed DaemonSets to take over and\r\nhijack resources of the K8s clusters they attack. Our research suggests that this campaign is actively targeting at\r\nleast 60 clusters in the wild.\r\nThis blog post is a part of a comprehensive study we conducted on misconfigured K8s clusters in the wild. Our\r\nresearch findings are significant as they shed light on the risks of misconfigurations and how even large\r\norganizations can overlook the importance of securing their clusters, leaving them vulnerable to potential disasters\r\nwith just one mistake.\r\nThe Attack\r\nWe have recorded and analyzed an attack on one of our K8s honeypots, which utilized the RBAC system to gain\r\npersistence. The attacker deployed containers using DaemonSets to run Monero cryptominers.\r\nThe initial access was gained via a misconfigured API server that allowed unauthenticated requests from\r\nanonymous users with privileges. The attacker sent a few HTTP requests to list secrets and then made two API\r\nrequests to gain information about the cluster by listing the entities in the ‘kube-system’ namespace. Next, the\r\nattacker checked if the attack had already been deployed on this specific cluster by looking for a deployment\r\nnamed ‘kube-controller’.\r\nThe attacker also attempted to delete some existing deployments in various namespaces, including ‘kube-secure-fhgxtsjh’, ‘kube-secure-fhgxt’, ‘api-proxy’, and ‘worker-deployment’. We assume that the attacker was disabling\r\nlegacy campaigns or competitors’ campaigns to increase available CPU and reduce the chances of being\r\ndiscovered if the server was exhausted.\r\nThe most interesting part of this attack was when the attacker used RBAC to gain persistence. The attacker created\r\na new ClusterRole with near admin-level privileges. Since it was a cluster role, it was not bound to a specific\r\nnamespace. Next, the attacker created a ‘ServiceAccount‘, ‘kube-controller‘ in the ‘kube-system’ namespace.\r\nLastly, the attacker created a ‘ClusterRoleBinding’, binding the ClusterRole with the ServiceAccount to create a\r\nstrong and inconspicuous persistence.\r\nhttps://blog.aquasec.com/leveraging-kubernetes-rbac-to-backdoor-clusters\r\nPage 1 of 5\n\nhttps://blog.aquasec.com/leveraging-kubernetes-rbac-to-backdoor-clusters\r\nPage 2 of 5\n\nFigure 1: ClusterRole created by the attacker with admin-like privileges\r\nAt this point, even if the anonymous user access is disabled, the attacker created persistence that allows further\r\nexploitation of the cluster. Additionally, while binding the ‘cluster-admin’ role to a new or suspicious user may set\r\noff alarms, the attacker created a clever way to blend in nicely with the API audit logs. Eventually, by setting this\r\nlegitimate-looking ClusterRoleBinding ‘system:controller:kube-controller’, the attacker could persist under the\r\nradar without setting off any alarms. \r\nAs part of our environment, we exposed AWS access keys in various locations on the cluster. Later that day, we\r\nreceived a beacon indicating that the access keys were used by the attacker to try and gain further access to the\r\ntarget’s cloud service provider account and leverage the attack to steal more resources, data, and get out of the\r\nspecific scope of the k8s cluster. \r\nThe attacker then created a DaemonSet to deploy containers on all nodes with a single API request. The\r\nDaemonSet creation request object contained the container image ‘kuberntesio/kube-controller:1.0.1’, hosted on\r\nthe public registry Docker Hub. The impact on the cluster was resource hijacking. \r\nhttps://blog.aquasec.com/leveraging-kubernetes-rbac-to-backdoor-clusters\r\nPage 3 of 5\n\nFigure 2: Deploying a DaemonSet with the container image kuberntesio/kube-controller\r\nWhen inspecting the container image ‘kuberntesio/kube-controller:1.0.1’ on Docker Hub, we found that the\r\ncontainer was pulled 14,399 times since it was uploaded five months ago, indicating that this campaign is\r\nwidespread. We found another 60 exposed K8s clusters that had evidence of active attacks by this attacker – this\r\nproves how large-scale the campaign is.\r\nThe container ‘kuberntesio/kube-controller’ has 3 tags, we analyzed all of them. Inside each of the container\r\nimages we found the binary kube-controller (MD5=2833c82055bf2d29c65cd9cf6684449a), which was detected in\r\nVirusTotal as a cryptominer. We also found on each of the container images the configuration file. The wallet\r\naddress indicated that the attacker had already mined 5 XMR, and at this rate of mining, they could gain another 5\r\nper year ($200 USD) from a single worker.\r\nThe container image named ‘kuberntesio/kube-controller’ is a case of typosquatting that impersonates the\r\nlegitimate ‘kubernetesio’ account. It has amassed millions of pulls, despite having only a few dozen container\r\nimages. The image also mimics the popular ‘kube-controller-manager’ container image, which is a critical\r\ncomponent of the control plane, running within a Pod on every master node, responsible for detecting and\r\nresponding to node failures. Essentially, it is a widely used K8s component that should exist on the cluster and\r\ncould deceive practitioners into thinking it is a legitimate deployment rather than a cryptominer. Since it is\r\ndesigned to run continuously, no one would question its presence.\r\nMapping the Attacks to the Microsoft threat matrix for Kubernetes \r\nAs a best practice, our team usually map the components of the attacks to the corresponding techniques of\r\nthe MITRE ATT\u0026CK framework. In this case, however, MITRE has yet to publish a framework for attacks\r\nagainst Kubernetes cluster. We utilized the threat matrix created by Microsoft, and added some new suggestions: \r\nSummary and Mitigation\r\nWe are naming this attack RBAC Buster – a new K8s attack aimed to exploit K8s API servers to create a\r\nClusterRoleBinding and gain full access to the cluster with persistence after the misconfiguration is fixed.\r\nhttps://blog.aquasec.com/leveraging-kubernetes-rbac-to-backdoor-clusters\r\nPage 4 of 5\n\nTo help mitigate such attacks, you can use Aqua Trivy to secure your K8s clusters. Trivy can help to find\r\nvulnerabilities, exposed secrets and misconfigurations.\r\nAdditionally, Aqua’s CNAPP is designed to detect such misconfigurations and protect your K8s clusters.\r\nMichael is a former Security Researcher at Team Nautilus, Aqua's research team. His work focuses on researching\r\nand analyzing new attack vectors and threats in cloud native environments. When he isn't at work, he enjoys a\r\ngood kite-surfing session or making Neapolitan pizza.\r\nAssaf Morag\r\nAssaf is the Director of Threat Intelligence at Aqua Nautilus. He is responsible of acquiring threat intelligence\r\nrelated to software development life cycle in cloud native environments, supports the team's data needs, and helps\r\nAqua and the ecosystem remain at the forefront of emerging threats and protective methodologies. His research\r\nhas been featured in leading information security publications and journals worldwide, and he has presented at\r\nleading cybersecurity conferences. Notably, Assaf has also contributed to the development of the new MITRE\r\nATT\u0026CK Container Framework.\r\nAssaf is leading an O’Reilly course, focusing on cyber threat intelligence in cloud-native environments. The\r\ncourse covers both theoretical concepts and practical applications, providing valuable insights into the unique\r\nchallenges and strategies associated with securing cloud-native infrastructures.\r\nSource: https://blog.aquasec.com/leveraging-kubernetes-rbac-to-backdoor-clusters\r\nhttps://blog.aquasec.com/leveraging-kubernetes-rbac-to-backdoor-clusters\r\nPage 5 of 5",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://blog.aquasec.com/leveraging-kubernetes-rbac-to-backdoor-clusters"
	],
	"report_names": [
		"leveraging-kubernetes-rbac-to-backdoor-clusters"
	],
	"threat_actors": [],
	"ts_created_at": 1775434928,
	"ts_updated_at": 1775791313,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/7a27f12bb5d2555455689a9b98e74d5ac0e48a09.pdf",
		"text": "https://archive.orkl.eu/7a27f12bb5d2555455689a9b98e74d5ac0e48a09.txt",
		"img": "https://archive.orkl.eu/7a27f12bb5d2555455689a9b98e74d5ac0e48a09.jpg"
	}
}