November 8, 2024
New Cryptojacking Attack Targets Docker API to Create Malicious Swarm Botnet
Cybersecurity researchers have uncovered a new cryptojacking campaign targeting the Docker Engine API with the goal of co-opting the instances to join a malicious Docker Swarm controlled by the threat actor. This enabled the attackers to "use Docker Swarm's orchestration features for command-and-control (C2) purposes," Datadog researchers Matt Muir and Andy Giron said in an analysis. The attacks

Cybersecurity researchers have uncovered a new cryptojacking campaign targeting the Docker Engine API with the goal of co-opting the instances to join a malicious Docker Swarm controlled by the threat actor.

This enabled the attackers to “use Docker Swarm’s orchestration features for command-and-control (C2) purposes,” Datadog researchers Matt Muir and Andy Giron said in an analysis.

The attacks leverage Docker for initial access to deploy a cryptocurrency miner on compromised containers, while also fetching and executing additional payloads that are responsible for conducting lateral movement to related hosts running Docker, Kubernetes, or SSH.

Specifically, this involves identifying unauthenticated and exposed Docker API endpoints using Internet scanning tools, such as masscan and ZGrab.

On vulnerable endpoints, the Docker API is used to spawn an Alpine container and then retrieve an initialization shell script (init.sh) from a remote server (“solscan[.]live”) that, in turn, checks if it’s running as the root user and tools like curl and wget are installed before downloading the XMRig miner.

Like other cryptojacking campaigns, it makes use of the libprocesshider rootkit to hide the malicious miner process from the user when running process enumerating tools like top and ps.

The shell script is also designed to fetch three other shell scripts – kube.lateral.sh, spread_docker_local.sh, and spread_ssh.sh – from the same server for lateral movement to Docker, Kubernetes, and SSH endpoints on the network.

Spread_docker_local.sh “uses masscan and zgrab to scan the same LAN ranges […] for nodes with ports 2375, 2376, 2377, 4244, and 4243 open,” the researchers said. “These ports are associated with either Docker Engine or Docker Swarm.”

“For any IPs discovered with the target ports open, the malware attempts to spawn a new container with the name alpine. This container is based on an image named upspin, hosted on Docker Hub by the user nmlmweb3.”

The upspin image is designed to execute the aforementioned init.sh script, thus allowing the group’s malware to propagate in a worm-like fashion to other Docker hosts.

What’s more, the Docker image tag that’s used to retrieve the image from Docker Hub is specified in a text file hosted on the C2 server, thereby allowing the threat actors to easily recover from potential takedowns by simply changing the file contents to point to a different container image.

The third shell script, spread_ssh.sh, is capable of compromising SSH servers, as well as adding an SSH key and a new user named ftp that enables the threat actors to remotely connect to the hosts and maintain persistent access.

It also searches for various credential files related to SSH, Amazon Web Services (AWS), Google Cloud, and Samba in hard-coded file paths within the GitHub Codespaces environment (i.e., the “/home/codespace/” directory), and if found, uploads them to the C2 server.

In the final stage, both the Kubernetes and SSH lateral movement payloads execute another shell script called setup_mr.sh that retrieves and launches the cryptocurrency miner.

Datadog said it also discovered three other scripts hosted on the C2 server –

  • ar.sh, a variant of init.sh that modifies iptables rules and clears logs and cron jobs to evade detection
  • TDGINIT.sh, which downloads scanning tools and drops a malicious container on each identified Docker host
  • pdflushs.sh, which installs a persistent backdoor by appending a threat-actor-controlled SSH key to the /root/.ssh/authorized_keys file

TDGINIT.sh is also notable for its manipulation of Docker Swarm by forcing the host to leave any existing Swarm it may be part of and add it to a new Swarm under the attacker’s control.

“This allows the threat actor to expand their control over multiple Docker instances in a coordinated fashion, effectively turning compromised systems into a botnet for further exploitation,” the researchers said.

It’s currently not clear who is behind the attack campaign, although the tactics, techniques, and procedures exhibited overlap with those of a known threat group known as TeamTNT.

“This campaign demonstrates that services such as Docker and Kubernetes remain fruitful for threat actors conducting cryptojacking at scale,” Datadog said.

“The campaign relies on Docker API endpoints being exposed to the Internet without authentication. The malware’s ability to propagate rapidly means that even if the chances of initial access are relatively slim, the rewards are high enough to keep cloud-focused malware groups motivated enough to continue conducting these attacks.”

The development comes as Elastic Security Labs shed light on a sophisticated Linux malware campaign targeting vulnerable Apache servers to establish persistence via GSocket and deploy malware families such as Kaiji and RUDEDEVIL (aka Lucifer) that facilitate distributed denial-of-service (DDoS) and cryptocurrency mining, respectively.

“The REF6138 campaign involved cryptomining, DDoS attacks, and potential money laundering via gambling APIs, highlighting the attackers’ use of evolving malware and stealthy communication channels,” researchers Remco Sprooten and Ruben Groenewoud said.

Found this article interesting? Follow us on Twitter and LinkedIn to read more exclusive content we post.