Cryptojacking Attacks in Kubernetes: How to Stop Them

We recently published a blog post - the first of a nine-part series - on the Kubernetes attack matrix and the representative threat vectors that organizations must consider to adequately secure their Kubernetes environments. The tactics and techniques that comprise the matrix are partly based on observations of attacks occurring “in the wild.” This post takes a closer look at one of the most prevalent attacks on container environments throughout the last several years: cryptojacking Kubernetes clusters.

Real-world Cryptojacking Attacks

Cryptojacking describes the scenario where an attacker gains access to and hijacks compute resources to mine cryptocurrency. Some real-world examples of cryptojacking attacks in Kubernetes environments that have been disclosed include the following:

1. A Kubernetes Dashboard was configured insecurely in Tesla’s cloud environment, allowing attackers to gain access to cloud account credentials and mine cryptocurrency.
2. Backdoored container images that contained malicious code for mining cryptocurrency were publicly available on Docker Hub and downloaded more than five million times.
3. A cryptojacking worm named Graboid was observed to spread to more than 2,000 Docker hosts using containers in the community version of the Docker Engine.
4. Microsoft Azure disclosed a large-scale campaign against Kubernetes clusters that abused exposed Kubernetes dashboards to carry out cryptomining attacks and was notable for its scale.
5. Kubeflow, a framework for running machine learning (ML) workloads on Kubernetes, was discovered to serve as an access vector for cryptojacking attacks.
6. As recently as last week, additional malicious images intended to mine cryptocurrency were publicly hosted on Docker Hub and downloaded more than two millions times.

These examples share several notable patterns. First, several of these attacks arose from downloading compromised images that were accessible from public repositories. In examples 2, 4, 5, and 6, the images contained a miner for the Monero cryptocurrency, and in at least one instance it was likely that malicious actors were actively scanning the Internet for exposed Docker APIs that would enable them to use the images to launch containers on hosts.

Second, at least two attack campaigns involved the Kubernetes Dashboard being exploited to gain access to clusters to mine cryptocurrency. In example 4, attackers used the Dashboard’s service account to launch the malicious containers. And similarly in example 5, these cryptojacking attacks stemmed from misconfigured Kubeflow Dashboards, whose incoming traffic is managed by the Istio ingress gateway, that were exposed directly to the Internet.

Third, these examples demonstrate the ability of attackers to move laterally within environments. In both examples 3 and 4, malicious containers ended up being run on thousands of Docker hosts and dozens of Kubernetes clusters.

Cryptojacking: Tactics and Techniques

The Kubernetes attack matrix provides a helpful reference when evaluating the tactics and techniques that comprise these various attacks. Specifically, we can see that most cryptopjacking attacks involve some combination of the following techniques:

• Initial Access
  • Compromised images in registry
  • Exposed Dashboard
• Execution
  • New container
• Persistence
  • Backdoor container
• Discovery
  • Access Kubernetes Dashboard
• Lateral Movement
  • Container service account
  • Access Kubernetes Dashboard
• Impact
  • Resource Hijacking

Mitigating Cryptomining Attacks in Kubernetes

This breakdown serves as a basis to formulate a blueprint for mitigating against these cryptojacking attacks. Organizations should implement the following key protections:

• Ensure images are secure
• Avoid risks associated with the Kubernetes Dashboard risks
• Leverage Kubernetes Role-based Access Control (RBAC) to ensure least privilege for service accounts

To start, organizations should set controls on the images that can be used to run containers, which may include allowing images only from trusted registries to be used, restricting images from public registries such as Docker Hub, configuring access controls on trusted and/or private registries, and requiring developers to use only trusted base images when building containerized applications. For more details, read our blog post on image security.

Next, organizations should take steps to mitigate threat vectors arising from the Kubernetes Dashboard. If the Dashboard is not needed, administrators should ensure that it is deleted from the environment entirely or disabled (which most Kubernetes platforms now do by default). If the Dashboard is needed and deployed, then ensure it has no elevated service account privileges, remove any bindings to its service account, and block ingress traffic using Kubernetes Network Policies. Check out our blog post on Kubernetes Network Policies for more details.

Organizations can then also take steps to prevent malicious containers from being launched by configuring Kubernetes Role-Based Access Control (RBAC) to restrict permissions to create pods and/or abstractions (such as Deployments, DaemonSets, ReplicaSets, and others) that also create pods. Administrators should adopt a least-privilege model for service accounts and their role bindings, as described in this blog post on mistakes to avoid when using Kubernetes RBAC.

How StackRox Secures Organizations From Cryptojacking

The StackRox Kubernetes Security Platform automatically protects organizations from cryptojacking attacks with several built-in capabilities. It enforces policies on images that can be used to launch containers and identifies issues, including vulnerabilities and problematic packages, in image layers separate from the underlying base operating system (OS) image.

StackRox also provides a built-in policy that alerts you when the Kubernetes Dashboard is deployed.

In addition, StackRox monitors RBAC privileges on service accounts and can identify whether elevated privileges have been granted.