News

Kubernetes Machine Learning Hacked for Crypto Mining in Azure Cloud

Hackers managed to exploit user misconfigurations -- apparently done for convenience -- to launch crypto mining campaigns leveraging powerful Kubernetes machine learning nodes in the Azure cloud, Microsoft announced earlier this month.

Specifically, the attackers targeted Kubeflow, a machine learning platform for working with Kubernetes, the popular container orchestration system.

"Kubeflow is an open-source project, started as a project for running TensorFlow jobs on Kubernetes. Kubeflow has grown and become a popular framework for running machine learning tasks in Kubernetes. Nodes that are used for ML tasks are often relatively powerful, and in some cases include GPUs. This fact makes Kubernetes clusters that are used for ML tasks a perfect target for crypto mining campaigns, which was the aim of this attack," said Yossi Weizman, security research software engineer, Azure Security Center, in a June 10 blog post.

Crypto mining (or cryptocurrency mining or bitcoin mining) is a way to generate digital currency wealth by leveraging powerful computing power. While it's not illegal, it requires tremendous computing effort for usually minimal gains. The whole process is explained here.

Hackers were able to turn Kubeflow machine learning to cryptocurrency mining by taking advantage of user misconfigurations, having to do with dashboards deployed in Kubeflow clusters that expose Kubeflow UI functionality. Weizman summarized this:

The dashboard is exposed by Istio ingress gateway, which is by default accessible only internally. Therefore, users should use port-forward to access the dashboard (which tunnels the traffic via the Kubernetes API server).

In some cases, users modify the setting of the Istio Service to Load-Balancer which exposes the Service (istio-ingressgateway in the namespace istio-system) to the internet. We believe that some users chose to do it for convenience: without this action, accessing to the dashboard requires tunneling through the Kubernetes API server and isn't direct. By exposing the Service to the internet, users can access to the dashboard directly. However, this operation enables insecure access to the Kubeflow dashboard, which allows anyone to perform operations in Kubeflow, including deploying new containers in the cluster.
The Azure Security Center earlier published a Kubernetes Threat Matrix detailing the major techniques that are relevant to container orchestration security, with a focus on Kubernetes. Shading the matrix to illustrate the recent campaign results in this:
The recent attack depicted in the Kubernetes Threat Matrix
[Click on image for larger view.] The recent attack depicted in the Kubernetes Threat Matrix (source: Microsoft).

Weizman said the attack affected "tens of Kubernetes clusters" but there was no information provided about how much mining was conducted or if attackers managed to do other nefarious deeds via the exposed dashboards.

Although the Azure Security Center has detected similar campaigns against Kubernetes implementations that leverage exposed services to the internet as an access vector, this is the first Kubeflow-specific attack. For example, Weizman in April described a similar exploit of Kubernetes.

User misconfigurations are a prime enabler of such attacks on Azure and other clouds. Notoriously, the Amazon Web Services (AWS) cloud suffered a long string of such attacks beginning a few years ago.

Weizman in his recent post provided guidance on how organizations can check to see if their clusters are impacted and provided advice going forward, warning that they should be aware of security aspects including:

  1. Authentication and access control to the application.

  2. Monitor the public-facing endpoints of the cluster. Make sure that sensitive interfaces are not exposed to the internet in an unsecure method. You can restrict public load balancers in the cluster by using Azure Policy, which now has integration with Gatekeeper.

  3. Regularly monitor the runtime environment. This includes monitoring the running containers, their images, and the processes that they run.

  4. Allow deployments of only trusted images and scan your images for vulnerabilities. The allowed images in the cluster can be restricted by using Azure Policy.

About the Author

David Ramel is an editor and writer at Converge 360.

comments powered by Disqus

Featured

  • Using Local AI to Cut Copilot Usage-Based Billing Shock

    After being gobsmacked by the new billing plan using almost all my monthly credits in one or two days, I tried pushing some Copilot-style coding work onto local models in VS Code. What I found was less "free AI" and more "pick your pain": cloud charges on one side, heavy local resource use and long waits on the other.

  • .NET 11 Preview 5 Focuses on Performance, Productivity and Safer Code

    .NET 11 Preview 5 focuses on under-the-hood runtime performance gains, streamlined APIs and language features that reduce boilerplate, plus built‑in security checks and incremental ASP.NET Core and EF Core improvements aimed at everyday developer productivity.

  • VS Code 1.124 Focuses on Agent Autonomy and Parallel Sessions

    Microsoft's June 2026 VS Code update turns on Autopilot by default and adds background sending for agent sessions.

  • Developing Agentic Systems in .NET: From Concept to Code

    ZioNet founder Alon Fliess previews his Visual Studio Live! San Diego session on building true agentic systems in .NET -- covering the cognitive loop, MCP tool integration, multi-agent orchestration and enterprise hosting and governance with the Microsoft Agent Framework.

Subscribe on YouTube