Your Kubernetes Cluster Might Be Mining Crypto for Someone Else

There is a kind of attack where nobody steals your data, nobody encrypts your files, and nobody sends you a ransom note. Instead, someone quietly uses your computers to make money for themselves, and hopes you never notice. Your only clue is a cloud bill that keeps creeping up.

It is called cryptojacking, and security firm Wiz documented a campaign that does exactly this to Kubernetes clusters. The clever part is not how they break in. It is how they hide once they are inside.

This post starts from zero. If you run anything on Kubernetes, you should understand this one, because the way in is a single misconfiguration that far too many clusters ship with by accident.

First: what is cryptojacking?

Some cryptocurrencies are created by "mining." Mining means running heavy math on a computer, over and over, and getting paid in coins for the effort. The more computers you throw at it, the more you earn. The catch is that it costs a lot of electricity and computing power, which normally means it costs money to do.

Cryptojacking is the shortcut. Instead of paying for your own computers, you sneak onto someone else's and mine using their machines. They pay the electricity and cloud bill. You keep the coins.

So the attacker's goal here is not your secrets. It is your spare compute. That changes how the attack behaves: it wants to stay quiet and run as long as possible, not cause a dramatic incident.

What is a Kubernetes cluster, and what is the "API server"?

A Kubernetes cluster is a group of machines that run your apps together as one system. You do not manage each machine by hand. You talk to one central brain, and it decides what runs where.

That brain is called the API server. It is the front door to the whole cluster. Every command, "run this app," "show me what's running," "give this thing more power," goes through the API server. Whoever can talk to the API server and give it orders effectively controls the cluster.

So the single most important question for cluster security is simple: who is allowed to talk to the API server, and does it check who they are?

The open door: anonymous access

Here is the mistake this campaign hunts for.

By default in some setups, and by accident in many, the API server can be reachable from the public internet and configured to accept "anonymous" requests. Anonymous means exactly what it sounds like: a request with no login, no identity, no credentials at all, and the cluster still answers it.

There is one important nuance here. Anonymous access being switched on is not, by itself, enough to hand over the cluster. An anonymous request arrives as a built-in identity Kubernetes calls system:anonymous, and a well-configured cluster grants that identity essentially no permissions. The real danger appears when someone has also, usually by accident, given that anonymous identity real permissions, for example by carelessly binding it to a powerful role. That is the actual misconfiguration this campaign hunts for: anonymous access plus permissions handed to anonymous users.

Put those together with an API server exposed to the internet, and you have a front door that is both visible to everyone and unlocked. Attackers scan the internet all day looking for exactly this. When they find a cluster where anonymous users can create workloads, they do not need to hack anything. They just walk in and start giving orders.

What they do once inside: run the miner everywhere

Once the attacker can send commands to the cluster, they tell it to deploy something. Specifically, they use a Kubernetes feature called a DaemonSet.

A DaemonSet is a normal, legitimate Kubernetes tool. Its job is: "run one copy of this on every single machine in the cluster." Real system components use DaemonSets for good reasons, like putting a monitoring agent on every node.

The attacker abuses that. By deploying the miner as a DaemonSet, they guarantee it runs on every machine in your cluster at once, squeezing the maximum amount of stolen compute out of you. One command, and your whole cluster is mining for them.

The clever part: hiding in plain sight

This is where the campaign is genuinely smart, and worth learning from.

If an attacker deployed something called evil-crypto-miner, anyone glancing at the cluster would spot it instantly. So they don't. They dress the miner up to look like ordinary Kubernetes plumbing.

• The DaemonSets have boring, legitimate-sounding names like k8s-device-plugin and pytorch-container. Both sound like exactly the kind of thing that belongs in a modern cluster running GPU or AI workloads. An earlier version of this campaign used a name like proxy-api, so the disguises keep evolving to blend in better.
• The miner program itself is named pause. This is the sneakiest touch. Kubernetes really does have a small, real component called the "pause" container. It runs in every pod and does legitimate low-level work. So when an admin sees a process called pause running everywhere, it looks completely normal. The miner is impersonating a real system part by name.
• The miner carries its settings inside itself. Normally a miner is launched with obvious command-line arguments, like the wallet to pay and the pool to mine in. Security tools watch for exactly those tell-tale arguments. This one bakes the wallet address and mining pool directly into the program, so there are no suspicious arguments to catch. It is also compressed with a tool called UPX to make it harder to inspect.

The result is a miner that runs on every node, named like a system component, launched with nothing suspicious to grep for. Unless you are specifically looking, it hides in the noise. The malicious container images were even hosted openly on Docker Hub, with some pulled more than 10,000 times.

Why you might never notice

Because the goal is stolen compute, not damage, this attack is designed to be boring. Your apps keep working. Nothing crashes. No alert fires.

What actually changes:

• Your nodes run hotter and slower, because a chunk of every machine's power is now mining.
• Your autoscaler may spin up more nodes to handle the load, so the cluster quietly grows.
• Your cloud bill climbs for no reason you can explain.

Plenty of teams discover cryptojacking not through a security tool, but through their finance team asking why compute costs doubled.

How to make sure this is not you

The good news: the entry point is a configuration you control, and closing it is straightforward.

1. Turn off anonymous access, and make sure no permissions are bound to anonymous users.

This is the single most important one, and it has two parts. First, where you can, disable anonymous authentication so an unidentified request is rejected outright. Second, and just as important, check that nobody has accidentally granted permissions to system:anonymous or the system:unauthenticated group. Run kubectl get clusterrolebindings,rolebindings -A -o wide and look for either of those names on the subject side. If an anonymous user is bound to anything, especially a broad role, remove it.

2. Do not expose the API server to the whole internet.

Most clusters have no reason for their control plane to be reachable by the entire world. Restrict it to known networks, a VPN, or an allowlist of IPs. If attackers cannot reach the front door, they cannot rattle the handle.

3. Lock down permissions with RBAC.

Even authenticated users should only be able to do what they need. Kubernetes RBAC (role-based access control) lets you say precisely who can create workloads and who cannot. A random or low-privilege identity should not be able to deploy a DaemonSet across every node.

4. Block risky workloads before they run.

Policy tools like Kyverno or admission controls can refuse deployments that do not meet your rules. You can block workloads from unknown image registries, or stop anything from scheduling cluster-wide unless it is on an approved list. That turns "deploy a miner everywhere" into an automatic rejection.

5. Watch for the tells.

Look for new DaemonSets you did not create, pods pulling images from Docker Hub accounts you do not recognize, and sustained high CPU with no matching increase in real traffic. A cluster that is suddenly maxed out but serving the same number of users is a classic sign.

None of this requires a fancy product. It is mostly closing a door that should never have been open, and watching who walks through the ones that are.

The whole post in four lines

• Cryptojacking steals your compute to mine cryptocurrency, quietly, so your only symptom is a rising cloud bill, not a dramatic breach.
• Attackers scan the internet for Kubernetes API servers that are both exposed and allow anonymous access, then simply walk in and deploy a miner as a DaemonSet so it runs on every node at once.
• The miner hides by impersonating real Kubernetes components: innocent DaemonSet names like k8s-device-plugin, and a miner binary literally named pause to mimic the real system container, with its config baked in so there is nothing suspicious to detect.
• The fix is config you control: disable anonymous access, keep the API server off the public internet, tighten RBAC, block untrusted workloads with policy, and watch for unexplained DaemonSets and CPU spikes.

Nobody has to break in when you leave the front door unlocked. Check that yours is not.

Sources and further reading

• Wiz: DERO cryptojacking adopts new techniques to evade detection. The original research from the team that found and analyzed the campaign.
• The Hacker News: Cryptojacking Campaign Targets Misconfigured Kubernetes Clusters. A plain-language summary of the Wiz findings.
• BleepingComputer: First-known Dero cryptojacking operation seen targeting Kubernetes. Background on the earlier version of the same campaign.