Cryptojacking Attacks in Kubernetes: A Serious Threat That Deserves Attention

Security in cyberspace is definitely an important issue, with dedicated specialists being tasked with the protection of users’ data and infrastructure in various organizations.

As cryptocurrencies become an integral and widely used means of transferring value globally, cyberspace's security threats have incremented with cryptojacking.

Cryptojacking is a form of cyberattack where hackers hijack a target’s computer to stealthily mine cryptocurrency without the user’s awareness.

Because of the greater compute capacities available in the cloud, hackers are now specifically targeting these cryptojacking attacks to cloud infrastructure through containerized platforms, including Docker and Kubernetes.

This dreadful act has proved to be very effective with some major tech companies recently attacked.

A recent article "Trend Micro Attacks on Cryptomining Docker" reported hackers are now targeting Docker via container escape features to run malicious crypto-mining software for their personal gains.

In an attack case studied by Trend Micro, the attacker broke into the system through a calm.sh shell script, which then released a shell script called cmd. A scanner named Zgrab then infected the Docker container image*,* scans the container for an exposed API, then deploys the malicious container.

Depending on whether the operation to gain privileged access was successful or not, The calm.sh shell script then calls the cryptocurrency miner embedded in an executable linkable format (ELF) file and runs it on the vulnerable server.

In 2018, Tesla’s AWS Kubernetes console was hit by a cryptojacking attack, even though the Tesla security team addressed it few hours after the RedLock security team made them aware of the situation. The attack was initiated when the unknown attackers gained access to Tesla’s Kubernetes administrative console - a console used to automate the deployment, scaling, and operation of application containers and other cloud-based services not protected by a password.

The admin privilege enables the attacker to see all running services, access every pod, inspect files, and access private information stored in Tesla’s AWS S3  buckets.

In addition to comprising Tesla’s cloud environment through Kubernetes and running malicious scripts to mine cryptocurrency, the hackers adopted several techniques to make it difficult for domain and IP-based theta detection systems detect its activities.

Earlier in February, Palo Alto Networks, a renowned cybersecurity firm, through a publication on its website, announced the detection of a new cryptojacking malware targeting Kubernetes clusters, intending to use Kubernetes resources to mine the cryptocurrency, Monero (XMR) secretly.

The malware gained access to the cloud system via a misconfigured Kubelet that allowed anonymous access to the Kubernetes cluster. It then spread over to as many containers as it could and eventually launches the cryptojacking scripts.

Cybersecurity researchers of Unit 42 at Palo Alto Networks concluded, based on the tactics, techniques, and procedures used, that the malware is a new campaign from popular cyber attackers group, TeamTNT. The malware was named Hildegard, the username of the account used by the malware. At the time of discovery, the malware campaign already has 25.05 KH/s hashing power and 11 XMR (worth $2,359 as at the time of writing) in the wallet.

Palo Alto also noted that it believes the new malware is still under development due to its apparently incomplete codebase, infrastructure, and rather new C2 domain, a command-and-control server used by hackers to maintain communication with a target’s compromised system, registered barely 2 months ago.

Since its initial discovery, the malware has not been active, which signals a possible reinforcement and weaponization of the malware for a large-scale attack. To stay clear of this security threat whenever it bounces back, we need to study the malware attack's details and behavior to help us put the necessary security measures in place.

Hildegard: The new kubernetes Crypojacking Malware

In Hildegard and some earlier cryptojacking attacks targeted at Kubernetes, researchers observed the following procedure.

• Initial Access: The attackers gained initial access by executing commands on kubelets through the run command API. It makes use of compromised images in the registry and exposed Kubernetes dashboard
• Execution: The malware then executes a command that creates a reverse shell which allows it to carry out subsequent operations.
• Persistence: The malware carries some detection-proof capabilities that make it more stealthy and persistent.
• Discovery: It searches for kubelets in the Kubernetes’s internal network and also gathers information about the host’s OS, CPU, and memory.
• Access Kubernetes Dashboard: It uses the information gathered above to gain access into the Kubernetes dashboard.
• Lateral Movement: The malware uses the exploitable kubelets found during the discovery stage to move laterally inside the Kubernetes cluster.
• Impact: the malware impacts result in denial of service and intent resource hijacking.
• Resource Hijacking: The malware operation leverages the system's resources and disrupts every application in the Kubernetes cluster for its mining process.

Unit 24 researchers made a visual illustration of the attacker’s movement in the image below.

1. The malware started by directly exploiting an unsecured Kubelet on the internet, then scanned it for containers running inside the Kubernetes node (Node A). After finding container 1 in Node A, the attacker tried to perform a remote code execution (RCE) by dropping a file named TDGG executed via Kubelet, which then downloads and executes a tt.sh, api.key, and tmate files. After establishing the tmate connection, an sGAU.sh, kshell, install_monerod.bash, setup_moneroocean_miner.sh and xmrig files are then run.
2. The attacker downloaded tmate and issued a command to run and establish a reverse shell to tmate.io from container 1. The malware then continued the attack with the tmate session.
3. From container 1, the attacker used masscan to scan Kubernetes’s internal network and found unsecured Kubelets in Node B and Node C. The attacker then attempted to deploy a malicious Monero crypto-mining script (xmr.sh) to containers managed by other Kubelets (containers 2-7).
4. Containers that ran xmr.sh started an xmrig process and established an IRC channel back to the IRC C2.
5. The attacker could also create another tmate session from one of the containers (container 4). With the reverse shell, the attacker could perform more manual reconnaissance and operations.

The researchers tagged the Hildegard malware “one of the most complicated Kubernetes-targeted attacks yet” and warns that it might be a difficult threat to deal with.

The full Hildegard malware analysis report is published on Palo Alto’s Unit 42 website.

How Do I Protect My Cloud Environment Against Cryptojacking Attack?

As in the cases we studied above, we see that most of these attacks leverage weak security practices in the system to compromise the cloud.

Cryptojacking attacks can easily be detected and prevented by adopting DevSecOps and implementing Continuous security in your DevOps processes.

Continuous security is making continuous threat monitoring and testing an integral part of the continuous integration and continuous delivery (CI/CD) process.

Below are some DevSecOps and Continuous security practices that can help you prevent cryptojacking attacks.

1. Scan and secure container images for vulnerabilities: to ensure that a container image is free of vulnerabilities, you need to periodically scan it for malware and exploit files. In addition to that, you should also control the images that can be used to run containers by allowing images only from trusted or private registries to be used when building containerized applications.
2. Automate security for Kubernetes pipelines: Investing time in manually securing Kubernetes pipelines is a tedious task and can also slow down the pipeline. By automating Kubernetes pipeline security, you can effectively address misconfiguration, leading to cryptojacking and other threats associated with each Kubernetes pipeline stage.
3. Implement multi-layer security: Cryptojacking attacks can be lethal but securing production run-time environment from the network phase can stop the attacks from reaching the applications
4. Leverage Role-based Access Control (RBAC): Adopting the least privilege model and configuring Kubernetes Role-Based Access Control (RBAC) to restrict certain permissions for least-privilege service accounts. This ensures that developers only get access to the resources that they need and reduces the risk of account compromisation. Permissions to create pods and abstraction.