Attack targets Docker, Hadoop, Confluence, and Redis with new payloads

A new attack campaign is targeting publicly accessible Docker, Hadoop, Confluence, and Redis deployments by exploiting common misconfigurations and known vulnerabilities. The attackers deploy previously unseen payloads including four binaries written in Golang.

“Once initial access is achieved, a series of shell scripts and general Linux attack techniques are used to deliver a cryptocurrency miner, spawn a reverse shell, and enable persistent access to the compromised hosts,” researchers from Cado Security said in a new report. While attribution cannot be made with certainty, the shell scripts observed in the campaign have some similarities to those used in the past by known threat actors TeamTNT and WatchDog.

Complex multi-stage infection chain via shell scripts

The infection chain of this campaign is quite complex totaling over 10 shell scripts and various binaries, multiple persistence mechanisms, backup payload delivery methods, anti-forensics techniques, user mode rootkits, network scanning tools and exploits. Cado first observed the attack on one of its Docker honeypots, which was intentionally configured insecurely. The attackers connected to the Docker Engine API, spawned a new container based on Alpine Linux, and mounted the host’s root file system to a temporary directory inside the container.

This technique is not new and is commonly used in Docker attacks to write a malicious cron job on the host system that would then execute the attackers’ code. In this new campaign, the attackers wrote a file to the /usr/bin/vurl path and created a cron job to execute some base64-encoded shell commands.

The shell code executed by cron uses the vurl script to retrieve a first stage payload from a hardcoded command-and-control server via a TCP connection. If this method fails, a second cron job is created that uses Python and the urllib2 library to retrieve an alternative payload. The vurl payload is a shell script called cronb.sh whose goal is to make sure the chattr (change file attributes) utility is installed and to check if the current account is root. This will determine the next payload, yet another shell script called ar.sh whose purpose is to prepare the system for the next stages of infection.

First, it uses the ​​netstat command to check if connections on port 80 are allowed to the internet. It then disables the firewalld and iptables Linux firewalls, deletes the shell history to hide its tracks, disables the SELinux protection and addes public DNS servers /etc/resolv.conf to ensure future C2 domains are resolved correctly.

“Interestingly, ar.sh makes use of the shopt (shell options) built in to prevent additional shell commands from the attacker’s session from being appended to the history file,” the researchers said. Not only are additional commands prevented from being written to the history file, but the shopt command itself doesn’t appear in the shell history once a new session has been spawned. This is an effective anti-forensics technique for shell script malware, one that Cado Security Labs researchers have yet to see in other campaigns.”

The script then downloads a copy of the masscan network scanner and installs the libprocesshider and diamorphine user mode rootkits, which are used to hide running processes. It also downloads a copy of the XMRig cryptocurrency miner, deploys an attacker-controlled SSH key on the system for persistence, and downloads a Golang binary called bioset that’s a copy of a reverse shell utility called Platypus.

The script also inspects the SSH config file and tries to use the locally stored SSH keys to access the associated IP and spread the cronb.sh malware to those systems to initiate the infection chain on them. Finally, it downloads a second Golang binary called fkoths that searches the system for any container images downloaded from the Ubuntu or Alpine repositories and deletes them.

As a final step, ar.sh downloads and executes yet another script called s.sh. The purpose of this new script is to download even more payloads from another command-and-control server. These include four more Golang binaries deceptively named c.sh, d.sh, w.sh and h.sh a shell script called s.sh that sets up systemd services for them.

The purpose of the new four Golang binaries is to attempt to compromise systems running each of the four targeted technologies — Hadoop YARN, Docker, Confluence and Redis — using different techniques after identifying target IPs with masscan and pnscan.

The d.sh binary exploits Docker API using the techniques described above, while h.sh targets Hadoop YARN via a misconfiguration that leads to remote code execution (RCE). “If the YARN API is exposed to the open Internet, it’s possible to conduct a RCE attack by sending a JSON payload in a HTTP POST request to the /ws/v1/cluster/apps/ endpoint,” the researchers said. “This method of conducting RCE has been leveraged previously to deliver cloud-focused malware campaigns, such as Kinsing.”

The w.sh binary attempts to exploit a known RCE vulnerability tracked as CVE-2022-26134 in Confluence Server while ​​c.sh is used to target unprotected Redis instances by writing a cron job with shell commands to the database and then saving the database file to one of the cron directories so it’s automatically executed by the scheduler.

Variety of initial access techniques available to cloud and Linux malware developers

“This extensive attack demonstrates the variety in initial access techniques available to cloud and Linux malware developers,” the researchers said. “It’s clear that attackers are investing significant time into understanding the types of web-facing services deployed in cloud environments, keeping abreast of reported vulnerabilities in those services and using this knowledge to gain a foothold in target environments.”

Organizations are advised to use the indicators of compromise in the Cado report to scan their Docker, Confluence, Hadoop and Redis services and ensure they patch any vulnerabilities and correct insecure configurations.

Cryptocurrency, Cyberattacks, Cybercrime, Malware