Digital attackers have used the XMRig Monero-miner to prey upon Docker in the past. In October 2019, for instance, researchers came across the first publicly documented cryptojacking worm that used containers in Docker Engine in order to spread. Attackers ultimately deployed the worm, called “Graboid,” to mine for Monero using XMRig. Less than a year later, Unit 42 identified a malicious Docker Hub account, “azurenql,” hosting six malicious images that had been collectively pulled two million times. Those malicious images called down XMRig to prey upon organizations who pulled those images.

Add Xanthe to the Mix…

Acknowledging the campaigns discussed above, it’s not surprising that researchers spotted a new operation in which attackers attempted to distribute XMRig.

Cisco Talos spotted the campaign when its honeypots logged a potential Docker attack from an obscure crypto mining botnet. An investigation into this attack revealed that only a few anti-malware engines had spotted earlier samples of the botnet. Even then, security firms had identified just one of the scripts used by the botnet to carry out its attacks.

The investigation also provided some insight into the infection chain. An attack began when an initial script, “pop.sh,” downloaded and ran the main bot module, “xanthe.sh.” (Cisco Talos named the attack “Xanthe” after this module.) At that point, xanthe.sh ran an initialization procedure that attempted to run two additional modules. These were as follows:

• Xesa: After removing the system log file, xesa.txt added multiple IP addresses to the /etc/hosts file so that the DNS resolver would resolve them locally and block them. Those IP addresses were associated with competing cryptomining botnets. In addition to trying to delete accounts associated with those rival threats, xesa.txt ran some commands to determine whether there were any other miners running on the infected system. If it found such a threat, xesa.txt terminated the rival botnet’s processes and Docker containers as well as removed its images from the local Docker repository.
• Fczyo: The second auxiliary module loaded by xanthe.sh, “fczyo,” performed similar functionality to xesa.txt but singled out different parts of the system for termination. It did so by first adding two public DNS servers to the beginning of the /etc/resolve.conf file and restarting the DNS resolver. With the DNS resolver now using those public DNS servers, fczyo got to work seeking out and terminating competing Docker containers.

Once it had gotten its two auxiliary modules up and running, xanthe.sh downloaded a variant of XMRig along with a JSON configuration file and the module “libprocesshider.so.” This last resource concealed the miner process name in memory so as to help the botnet evade detection. Next, xanthe.sh verified that the /tmp directory was configured to allow the execution of files before checking to see if the miner was already running in memory.

In its investigation, Cisco Talos confirmed that the Xanthe variant used SSH to spread. The threat did this by configuring the SSH daemon to be less secure and enable functionality, at which point it restarted the SSH service. The attack then used the localgo function to connect to icanhazip.com and obtain an externally visible IP address of the infected host. Xanthe used the same utility to search for client-side certificates so that it could authenticate to remote hosts.

As it’s the security firm explained in its report:

Once all possible keys have been found, the script proceeds with finding known hosts, TCP ports and usernames used to connect to those hosts. Finally, a loop is entered which iterates over the combination of all known usernames, hosts, keys and ports in an attempt to connect, authenticate on the remote host and launch the command lines to download and execute the main module on the remote system.

Researchers at Cisco Talos also found that the attack came with Docker scanning and spreading capabilities, though that functionality was commented out at the time of analysis.

Highlighting the Need for Docker Security

The emergence of attacks like Xanthe highlights the need for organizations to practice Docker security. StackRox noted that this is especially pertinent given the complexity that containers create within organizations’ IT environments. As quoted in a blog post:

Containerized environments have many more components than traditional VMs, including the Kubernetes orchestrator that poses its own set of security challenges. Can you tell which deployments or clusters are affected by a high-severity vulnerability? Are any exposed to the Internet? What’s the blast radius if a given vulnerability is exploited? Is the container running in production or a dev/test environment?

Those are not rhetorical questions. Organizations need to work to understand the risks confronting their Docker deployments and take steps to protect them against digital attackers. Towards that end, they can view Docker’s documentation to learn about some important security recommendations that they can use to their advantage. More information is available here.

About the Author: David Bisson is an information security writer and security junkie. He’s a contributing editor to IBM’s Security Intelligence, Tripwire’s The State of Security Blog, and a contributing writer to Bora. He also regularly produces written content for Zix and a number of other companies in the digital security space.