First Dero cryptojacking campaign targets unprotected Kubernetes instances

Learn how this cryptocurrency campaign operates and its scope. Then, get tips on protecting vulnerable Kubernetes instances from this cybersecurity threat.

The cybersecurity company CrowdStrike has observed the first-ever Dero cryptojacking campaign. The attack targets Kubernetes clusters that were accessible on the internet and allowed anonymous access to the Kubernetes API.

Jump to:

What is Dero?

Dero is a privacy-focused blockchain platform that aims to provide fast and secure transactions with enhanced privacy features.

Dero makes use of several technologies, including CryptoNote, Bulletproofs and its own proof of work algorithm to offer private and anonymous transactions without compromising speed or scalability. Dero uses ring signatures and stealth addresses to ensure transactions cannot be traced back to their origin.

Dero also provides low transfer fees, and the platform is open source. Dero’s native cryptocurrency is called DERO.

Some cybercriminals seeing these specifications have started using DERO instead of other popular cryptocurrencies that are used widely by cybercriminals, such as Bitcoin and Monero.

How does this cryptojacking attack operate?

With this cryptojacking attack, the threat actor scans for Kubernetes instances with the authentication parameter set as “–anonymous-auth=true”. Also, as stated by CrowdStrike researchers Benjamin Grap and Manoj Ahuje, “a user with sufficient privileges who runs ‘kubectl proxy’ can unintentionally expose a secure Kubernetes API on the host where kubectl is running, which is a less obvious way to expose the secure Kubernetes cluster bypassing authentication.”

SEE: Remote access policy (TechRepublic Premium)

Once a vulnerable Kubernetes cluster is found, the threat actor deploys a Kubernetes DaemonSet named “proxy-api.” That action deploys a malicious pod on every node of the cluster, enabling the attacker to run cryptojacking on all nodes from the cluster at the same time (Figure A).

Figure A

Once it is all set, mining starts on every pod, generating Dero coins that are then distributed to a community pool.

What is this cryptojacking attack’s scope?

The threat actor uses the Docker image “pauseyyf/pause” that is hosted on Docker Hub. The Docker image has more than 4,200 pulls at the time of this research (Figure B), revealing how many potential miner instances have been deployed.

Figure B

A script file named “entrypoint.sh” runs a Dero coin miner binary named “pause,” using a wallet address and mining pool as arguments.

Attackers have probably named the miner “pause” because pause containers in legitimate Kubernetes instances are used to bootstrap pods. That naming likely helps attackers avoid obvious detection.

As noted by researchers, attackers do not attempt to move laterally or pivot in any way around the Kubernetes instances, meaning they are not interested in anything other than mining resources for generating Dero coins.

Unlike other cryptocurrencies, such as Bitcoin, it is not possible to check the balance of the wallet address used in the attack campaign.

A new Monero cryptocurrency attack

In February 2023, another campaign hit vulnerable Kubernetes instances, this time aiming at mining Monero cryptocurrency.

The new campaign started by deleting existing Kubernetes DaemonSets named “proxy-api,” which was specific to the Dero cryptojacking campaign. In other words, the threat actor deploying the new campaign knew about the existing Dero cryptojacking operation and wanted to knock it off.

In addition to deleting the proxy-api DaemonSets, the attacker also deleted DaemonSets named “api-proxy” and “k8s-proxy,” which were possibly responsible for other attack campaigns.

The Monero campaign is more sophisticated than the Dero campaign, as it deploys a privileged pod and mounted a “host” directory in attempts to escape the container. It also created a cron job to run a payload and use a rootkit to hide the mining process.

How to protect your Kubernetes instances

It is critical to protect Kubernetes instances that are accessible from the internet. Follow these tips for optimal protection:

For starters, no Kubernetes instance should allow anonymous access. Strong authentication should be enforced to access Kubernetes, such as multi-factor authentication to ensure only authorized users can access the instance.

You should also deploy role-based access control to control access to Kubernetes resources based on user roles and permissions.

On a wider scale, whether it’s for Kubernetes or Docker, container images should only be downloaded from trusted sources like official repositories or reputable vendors. Even then, images should still be scanned for vulnerabilities.

From there, enable logging and monitor activity on all Kubernetes instances in order to detect suspicious activity or access attempts.

Finally, keep all software up to date and patched to address known vulnerabilities and security issues.

Read next: Security risk assessment checklist (TechRepublic Premium)

Disclosure: I work for Trend Micro, but the views expressed in this article are mine.