How KSOC Protects Against the Dero Cryptocurrency Miner

Overview

A first-of-its-kind set of cryptojacking operations has been discovered targeting Kubernetes clusters in the wild. The general goal of each operation is to use the victim's Kubernetes resources to mine cryptocurrency. The first miner targets Dero by deploying a DaemonSet pod on each node in the cluster to mine the cryptocurrency. The second miner targets Monero, creating a privileged pod and mounting a host directory, allowing it to escape the container. The attacker’s goal is to install the miner directly on the nodes instead of in a pod so that it can enjoy higher priority access to node resources.

It’s important to note that, while these attacks bring crypto miners into the cluster, the attack path has to establish outbound connections with a malicious server to get files. In doing so, an attack path is created that could just as easily be used to exfiltrate data from a cluster.

Why Kubernetes is a Great Target for Cryptocurrency Miners

Kubernetes is a widely adopted container orchestrator. While it offers a near unlimited amount of configuration, it was never meant to be configured out of the box for security. Kubernetes also offers plenty of compute and auto-scaling capabilities for attackers to cause serious financial damage. These malicious miners typically come bundled with other command and control programs and data exfiltration malware.

While cryptocurrency miners target Kubernetes due to its lack of built-in security detections, most guardrails today start with point in time Kubernetes posture scanners that leave security teams blind to rogue workloads, container escapes, and privilege escalation within the cluster.

If you would like to learn more about the most pressing risks that face CISOs today when it comes to Kubernetes, our Co-founder & CTO wrote the OWASP Top Ten for Kubernetes as an in-depth reference and guide.

How KSOC Can Mitigate the Risk

What few recognize about Kubernetes Security and Posture Management (KSPM) tools today is that they surface misconfigurations on polling intervals, which run, on average, every 24 hours. But Kubernetes workloads are dynamic, containers live for less than 5 minutes and thousands of deployments with various configurations happen on any given day. Periodically scanning for Kubernetes misconfigurations is an incredibly inefficient and inactionable tool in either preventing or reducing the blast radius of  cryptocurrency miners.

KSOC is the first and only KSPM platform that surfaces misconfigurations in real-time, taking the lifecycle of the Kubernetes workload into account to determine what is currently relevant. The obvious benefit here is to save you time diagnosing issues as well as help you make the most effective remediation decisions possible based on the current state of your clusters. View this demo to see real-time Kubernetes security in action.

Kube API Anonymous Auth

“The researchers say the attacks start with the threat actors scanning exposed, vulnerable Kubernetes clusters with authentication set to --anonymous-auth=true, allowing anyone anonymous access to the Kubernetes API.”

KSOC can detect kube-api servers with anonymous authentication enabled and warn administrators.

This is just one way into a Kubernetes cluster. While KSOC can detect clusters that allow anonymous authentication and warn administrators, Kubernetes defaults to --anonymous-auth=false and managed Kubernetes (e.g. EKS, AKS, GKE) will also not allow anonymous authentication.

Vulnerable web applications are not uncommon and web applications attacks by bots and live attackers can be assumed to be occurring at any given moment. If a web application has a command injection vulnerability, the pod running the web application could be compromised.

Whether the cluster is infiltrated via a misconfigured kube-api server or via a compromised pod or some other method, what should be top of mind is limiting the blast radius.

Pods with Security Misconfigurations

Stopping workloads containing images not from trusted image sources, including malicious DaemonSets, is part of KSOC’s default set of functions.

“After gaining access to the API, the threat actors will deploy a DaemonSet named "proxy-api" that allows the attackers to engage the resources of all nodes in the cluster simultaneously and mine Dero using the available resources.”

In addition to stopping workloads not from trusted sources, KSOC is always on the watch for pods with serious security misconfigurations. The pods might be intended for malicious use or accidentally misconfigured and could be dangerous if compromised. Stopping such workloads from being deployed and limiting the blast radius of a compromised cluster is a key focus of KSOC.

“The second threat actor deleted the proxy-api DaemonSet used by the Dero campaign and then performed a much more aggressive takeover of the cluster, employing a privileged pod and mounting a host directory, attempting to escape the container.”

The following list of misconfigurations could be blocked by KSOC and thwart both of the attacks described.

• images from non-whitelisted registries
• privileged pods
• host mounted paths

Here we can see an attempt to deploy a pod that violates these and other policies. Notice the timestamp at the top.

The event was blocked and is seen in the UI less than a second after the pod was blocked. The blocked reasons include:

• Running as privileged
• Image not from list of approved registries
• Use of hostPath volume
• Shares the host network

badpod.yml used in example

“Next, the threat actor used a custom XMRig miner downloaded from the attacker's command and control server to mine Monero by escalating to the host and installing a custom service.

The Monero campaign opted to mine on the host instead of the pods, as Dero did, to access more computational resources and make a more significant profit.”

This was only possible because the attacker was able to mount a privileged pod with a mounted host directory which allowed escape from the container. KSOC would block the privileged pod, regardless of how the cluster was compromised, with the default rules as seen in the example above.

Conclusion

This attack is the first of its kind and getting a real-time view into the Kubernetes lifecycle is the only way to ensure your future success against this and other attacks. Reach out for a demo today to put real-time Kubernetes security to the test in discovering and proactively controlling your Kubernetes exposure.