Cryptojacking worm infects exposed Docker deployments

Attackers are exploiting Docker Engine deployments that are exposed to the internet without authentication to deploy and run cryptojacking malware on servers. A new cryptojacking botnet with self-spreading capabilities has infected over 2,000 such Docker deployments so far.

“There have been incidents of cryptojacking malware spreading as a worm, but this is the first time we see a cryptojacking worm spread using containers in the Docker Engine (Community Edition),” researchers from Palo Alto Networks said in a report released today. “Because most traditional endpoint protection software does not inspect data and activities inside containers, this type of malicious activity can be difficult to detect.”

A botnet with unusual behavior

The new worm has been dubbed Graboid and was distributed from Docker Hub, a public repository of Docker container images. Attackers uploaded images to Docker Hub with malicious scripts that, when executed, deployed the malware to other insecure servers.

The researchers found several container images associated with the attack for different stages of the infection chain. They have been removed after the Docker Hub maintainers were notified of the abuse.

One image was based on CentOS and its purpose was to connect to predefined command-and-control (C2) servers to download and execute four shell scripts. It also contained a Docker client for sending commands to exposed Docker daemons.

One of the scripts delivered by the C2 servers collected details about the compromised environment, such as the number of available CPUs, and sent the information back to the attackers. Another script downloaded a list of over 2,000 IP addresses corresponding to insecure Docker API endpoints, randomly picked one of them and used the Docker client to connect to it and deploy the same rogue container image from Docker Hub, thus achieving self-propagation.

A third script randomly connected to one of the vulnerable Docker hosts in the list and deployed a second image from Docker Hub that contained an Xmrig binary masquerading as either the nginx web server or the MySQL database server. Xmrig is an open-source application that uses CPUs to mine cryptocurrencies. In the case of Graboid, it was configured to mine Monero.

Finally, the fourth script ran on a timer and again randomly connected to one of the IP addresses in the list and stopped Xmrig mining containers, including those deployed by the botnet itself. This means the mining activity on each server was not continuous and the botnet was in a constant flux of reinfecting hosts and starting and stopping the mining containers.

“Essentially, the miner on every infected host is randomly controlled by all other infected hosts,” the researchers said. “The motivation for this randomized design is unclear. It can be a bad design, an evasion technique (not very effective), a self-sustaining system or some other purposes.”

Based on their analysis, the researchers estimate that the mining activity on every infected host happened in intervals of 250 seconds on average and that each miner was active only 65% of the time, which is not very efficient.

That said, the malicious image used for the worm’s propagation was downloaded over 10,000 times and the one with the Xmrig binary more than 6,500 times. Based on the IP addresses in the worm’s targeting list, almost 60% of the compromised Docker deployments were hosted in China, 13% in the US, and the rest in other countries

Secure your Docker deployments

“While this cryptojacking worm doesn’t involve sophisticated tactics, techniques or procedures, the worm can periodically pull new scripts from the C2s, so it can easily repurpose itself to ransomware or any malware to fully compromise the hosts down the line and shouldn’t be ignored,” the researchers said. “If a more potent worm is ever created to take a similar infiltration approach, it could cause much greater damage, so it’s imperative for organizations to safeguard their Docker hosts.”

Docker Hub is a community project maintained by volunteers, so it’s not easy to police. Backdoored container images were uploaded to the repository in the past and it took months for them to be discovered and removed.

Last year, researchers from Kromtech identified 17 malicious Docker images that had been stored on Docker Hub for around a year. Some contained scripts that deployed reverse shells, rogue SSH access keys and cryptominers.

The Palo Alto researchers advise companies to never expose their Docker daemons directly to the internet without proper authentication. In fact, the Docker Engine is not exposed to the internet by default, so the insecure deployments exploited by this worm have been manually configured to be publicly accessible.

Even when Docker is not directly exposed to the internet, container orchestration and API management systems might be, and those pose a serious risk as well. Last year, a study by cloud security firm Lacework found over 22,000 publicly exposed container management dashboards, including Kubernetes, Docker Swarm, Swagger, Mesos Marathon and Red Hat OpenShift.

The Palo Alto researchers advise companies to use SSH with strong authentication if they need to connect to a Docker daemon remotely. This should be combined with firewall rules that restrict such connections to only a trusted set of IP addresses.

Furthermore, administrators should make sure that they never deploy Docker container images from untrusted uploaders on Docker Hub and should frequently check their Docker deployments for unknown container or images.