Protecting against new Kubernetes threats in 2024 and beyond

A wave of new attacks targeted Kubernetes in 2023: Dero and Monero crypto miners, Scarleteel and RBAC-Buster. Finding an initial foothold with a web app vulnerability, then moving laterally is the hallmark of a Kubernetes attack. Understanding the reality of these attacks can help protect your organization from current and future attacks targeting Kubernetes.

Here’s a breakdown of how the attacks unfold and what you can do to protect against them — or at least minimize the damage once attacked.

Scarleteel plan of attack

A Jupyter notebook web application hosted in Kubernetes was the entry point for Scarleteel, with the goal of accessing encrypted, sensitive data housed in cloud storage and crypto mining. To find open entry to the AWS cloud environment, the attackers also used an open-source Kubernetes penetration testing tool called Peirates, along with a similar tool called Pacu.

Scarleteel demonstrated how fluidly an attacker can move through a cloud environment. The attacker jumped from a web application hosted in Kubernetes straight to the cloud to Kubernetes and then back again. Defenders do not have a similarly connected view of their environment, instead looking at cloud security, web app security and Kubernetes security separately, then struggling to put together the full motion and objectives of the attacker. 

What you can do to protect from Scarleteel

If you’re not using Jupyter notebooks, you might not be susceptible to this attack. But there are many other web app vulnerabilities. You can ensure that you protect against the very specific cloud misconfiguration the attackers took advantage of. If you run EKS, look into places where you have IMDSv1 versus IMDSv2 installed and get a blue team to run Peirates and Paco against your environment before an attacker does.

Runtime capabilities would potentially detect the Pandora malware, but wouldn’t connect this to the broader attack and activity happening across the cloud and Kubernetes environments, so it can’t stop the entirety of the attack.

Dero and Monero Cryptocurrency Miners

In the Dero attack, the bad actor first scanned for Kubernetes APIs where authentication is set to allow anyone anonymous access. For this to work, the cluster also needed RBAC configuration that allowed for the creation of pods in that cluster. With these conditions met, the attacker deployed a Daemonset, creating its own pods from malicious images across the cluster. 

The first part of the Monero attack is the same as Dero. Then, with access to the Kubernetes API, attackers deleted the Dero pods and deployed their own privileged pod via Daemonset. The privileged pod then attempted to mount the host directory to escape the container and downloaded a rootkit that could hide the miner. Afterward, the attacker installed a custom mining service on the host.

Unlike Dero, the Monero attack involves privilege escalation and container escape techniques. Allowing privileged containers is one of the most critical Kubernetes security issues to avoid. Kubernetes disallows privileged pods in its baseline policy for Pod Security Standards, making it less likely this will happen by default.

However, if you’re running EKS and Kubernetes v1.13 and above, the default pod security policy is privileged. In EKS, you must delete this policy to enable your customer policies — an added step that potentially increases the chances you’ll allow creation of privileged pods. 

In Monero, there’s a lot of runtime activity that happens after hackers take advantage of the initial Kubernetes misconfiguration. Locking this down would prevent malicious runtime behavior from spreading to other pods and clusters. Stopping disallowed host mounted paths and privileged pod misconfigurations is the most important preventive measure. If you’re doing KSPM on polling intervals, you’re missing any attacker activity that happens in between.

How to protect from the Dero / Monero attacks

If exposed, your primary concern is tamping down the blast radius — as the attack occurs in real-time in Kubernetes, not in runtime. If your runtime capability includes a rule around Monero crypto mining, you can stop the last step but not the initial phases of the compromise.

Although you probably wouldn’t set your API to allow anonymous access, there are other ways this same entry point could be exploited. A malicious insider may plant backdoors or cryptocurrency miners similar to the ones in these attacks. A developer may unknowingly check in a service account token or kubeconfig file to a public git repository that could leave a cluster vulnerable.

The most important protective measure is preventing the creation of malicious workloads from Daemonsets. There’s also a case for observability tooling, as many crypto jacking operations are discovered through unexpected traffic spikes.

Since this attack used an image to create the malicious pods, setting up an admission control policy that prevents the creation of workloads coming from untrusted image sources would work. However, you’d either have to enforce the policy broadly or employ a real-time KSPM detection solution to understand exactly where you’re having issues, then use the admission controller surgically as you fix the configurations in code.

RBAC-Buster plan of attack

The attacker attempts to gain a foothold in a Kubernetes environment by scanning for a misconfigured API server that would allow unauthenticated requests from users with privileges. Attackers used privileged access to list secrets and discover the kube-system namespace.

They created a new ClusterRole with admin privileges and a new Service Account in the namespace, binding the two together to give the ClusterRole’s admin privileges to the Service Account. The attacker looked for AWS keys to gain access to the cloud service provider. They then used a Daemonset to deploy malicious pods for crypto mining across the cluster, using a container image. 

The initial step in this attack assumes that not only is your Kubernetes API server open, but it’s also accepting requests that privileged users have. The rest of the attack operates with this privileged access. 

What you can do to protect from RBAC-Buster

To spread laterally, the attackers used the same Daemonset technique as in the Dero campaign — a reminder to prevent creation of malicious workloads from Daemonsets. Check your API server configurations and audit your RBAC permissions to protect against this attack.

Preventing future attacks

The team that discovered RBAC-Buster said 60% of exposed clusters found had an active campaign running. This doesn’t mean 60% of all clusters are exposed. But attackers are searching for mistakes, misconfigurations and a way into your Kubernetes environment.

Most clusters were only accessible for a few hours, highlighting the ephemeral nature of Kubernetes clusters and how what today points to an exploitation and exposure might tomorrow be closed off to attackers. This means a nightmare in remediation if you’re working with polling intervals that can’t show these changes over time.

Relying solely on admission control or reverse-engineering detection on runtime events when the next attack comes either won’t detect it at all or will detect it too late. You need a real-time, combined view of Kubernetes risk. Defense-in-depth is best practice. But, if defense-in-depth provides no view of how all the different components work together, you’re still one step behind the attacker. 

Jimmy Mesta is CTO and co-founder of KSOC.

Originally appeared on: TheSpuzz