Hackers are using RBAC (Role-Based Access Control) to create a permanent backdoor on Kubernetes clusters and steal their resources for Monero cryptocurrency mining.
The Kubernetes RBAC (Role-Based Access Control) system allows administrators to specify which users or service accounts may access API resources and perform actions via the Kubernetes API.
Threat actors may remain on compromised clusters even if initial access misconfigurations are corrected in the future by exploiting RBAC to impose malicious access control policies. Aqua Security’s “Nautilus” research team discovered this new attack, which they called the “RBAC Buster” attack.
Researchers have discovered a campaign that targeted at least 60 Kubernetes clusters. The attackers accomplished this by installing DaemonSets to hijack and steal resources from the victims’ clusters.
Kubernetes Cluster RBAC Buster Attack
Researchers at the cybersecurity firm Aqua Security said that they monitored and analysed an attack on their Kubernetes honeypots. To achieve persistence, the attackers used the RBAC system.
Attackers take advantage of improperly configured API servers to allow unauthenticated requests from privileged anonymous users to access the target Kubernetes cluster. Once inside the cluster, the attackers use HTTP queries and API requests to list secrets and entities in the ‘kube-system’ namespace, respectively.
After gaining access to the Kubernetes cluster, the attacker initially looks for its own campaign, installed as ‘kube-controller’ and any further competing malicious installations that may have infected the cluster. If the deployments of other attackers are discovered, the attacker takes them down to seize control of the device’s resources for their malicious purposes.
The attacker used RBAC to create a new ClusterRole with nearly admin-level access. This ClusterRole offered a separate persistence method since it was not bound to a particular namespace. To boost this persistence, the attacker built a ServiceAccount and ClusterRoleBinding, coupling the ClusterRole with the ServiceAccount.
The attacker created a ClusterRoleBinding called ‘kube-controller,’ which allowed them to hide within the logs and avoid detection. This name is the same as that of a real Kubernetes daemon, making it much more difficult for administrators to detect fraudulent activity.
When the researchers set up their honeypots, they intentionally placed AWS access keys in various locations throughout the cluster. After receiving an alert, they discovered that the attacker had attempted to gain further access to the cloud service provider account by using the access keys. They proceeded to use this as an opportunity to steal more data and information.
According to Experts:
The findings are significant as they shed light on the risks of misconfigurations and how even large organizations can overlook the importance of securing their clusters, leaving them vulnerable to potential disasters with just one mistake.
Once the attacker has created the ClusterRoleBinding, the final step is to deploy the malicious Docker image using a DaemonSet, infecting all nodes on the Kubernetes cluster with a single API request. After deployment, the attacker may start mining Monero and using the resources of the hacked server.
Following an investigation, the malicious ‘kube-controller’ container named ‘kuberntesio/kube-controller:1.0.1’ was launched from the public Docker registry. The attacker impersonated the authentic ‘kubernetesio’ account and the commonly used ‘kube-controller-manager’ image to deceive users.
According to AquaSec’s research, the campaign appears to be widespread, as the exact container image has been downloaded over 14,000 times from Docker Hub since it was first posted to the repository five months ago.
The image can deceive practitioners into believing that it is a real deployment rather than a cryptominer because of how frequently it is used. Furthermore, the fact that it keeps working makes it much less likely to be questioned.
Administrators are advised to take several actions to minimise the risk. First, they need to secure the API server by preventing anonymous users from making unauthenticated queries, and then they need to establish and effectively enforce strict API access rules using RBAC. Additionally, companies are encouraged to encrypt any secrets and account credentials stored in the cluster and monitor audit logs closely.
Help your colleagues keep a security-first mindset and boost your human firewall by starting your Phishing Tackle security awareness training today with our two-week free trial.
