17 Backdoored Docker Images Removed From Docker Hub

The Docker team has pulled 17 Docker container images that have been backdoored and used to install reverse shells and cryptocurrency miners on users' servers for the past year.

The malicious Docker container images have been uploaded on Docker Hub, the official repository of ready-made Docker images that sysadmins can pull and use on their servers, work, or personal computers.

These Docker images allow sysadmins to quickly start an application container within seconds, without having to create their own Docker app container, a complicated and painstaking process that not all users are technically capable or inclined to do.

Malicious Docker images remained online for a year

Just like it happened with other package repositories in the past —such as Python [1, 2] and npm [1, 2]— malicious actors have uploaded malicious packages on the main Docker Hub repository.

Because new Docker images don't go through a security audit or testing process, these images were listed on the Docker Hub portal right away, where they remained active between May 2017 and May 2018, when the Docker team finally intervened to pull them down.

All 17 images were uploaded on the Docker Hub portal by the same person/group, using the pseudonym of "docker123321." Some of these packages have been installed more than one million times, while others were used hundreds of thousands of times.

Took a while before users caught on to what was happening

Signs that something was wrong on the Docker and Kubernetes (app for managing Docker images at a large scale) scene started appearing last September and continued through the winter.

Users reported that malicious activity was happening on their cloud servers running Docker and Kubernetes instances. Reports of security incidents involving Docker images were posted on GitHub and Twitter.

Several security firms and security researchers such as Sysdig, Aqua Security, and Alexander Urcioli also published reports about security incidents they've observed.

Even Bleeping Computer ran an article in March about an increase in coin-mining-related security incidents involving Docker and Kubernetes servers, in an attempt to highlight a new rising trend in cloud security.

Malicious Docker images taken offline

But while the number of security incidents grew, it was only when Fortinet and Kromtech got involved that all the pieces surrounding these hacks got put together, and researcher tracked down all these incidents to the docker123321 account.

Docker removed the 17 backdoored images from Docker Hub on May 10, this year, a week after Fortinet published a report about some of the cryptocurrency mining incidents linking back to Docker images created by the docker123321 account.

Today, Kromtech published a complete report connecting all the events that happened this past year. According to this report, these is the timeline of the attacks and the 17 malicious Docker images that have been uploaded by the docker123321 account, along with each package's capabilities.

Name of image	Creation timestamp
docker123321/tomcat	2017-07-25 04:53:28	1st bunch of malicious images
docker123321/tomcat11	2017-08-22 08:38:48
docker123321/tomcat22	2017-08-22 08:58:35
docker123321/kk	2017-10-13 18:56:22	2nd bunch of malicious images
docker123321/mysql	2017-10-24 01:49:42
docker123321/data	2017-11-09 01:00:14
docker123321/mysql0	2017-12-12 18:32:22
docker123321/cron	2018-01-05 11:33:04	3rd bunch of malicious images
docker123321/cronm	2018-01-05 11:33:04
docker123321/cronnn	2018-01-12 02:06:11
docker123321/t1	2018-01-18 09:54:04
docker123321/t2	2018-01-19 09:41:46
docker123321/mysql2	2018-02-02 11:40:53	4th bunch of malicious images
docker123321/mysql3	2018-02-02 18:52:00
docker123321/mysql4	2018-02-05 14:05:18
docker123321/mysql5	2018-02-05 14:05:18
docker123321/mysql6	2018-02-07 02:16:29

Docker image name	Type of malware
docker123321/tomcat     docker123321/mysql2   docker123321/mysql3   docker123321/mysql4   docker123321/mysql5   docker123321/mysql6	Containers run Python Reverse Shell
docker123321/tomcat11	Containers run Bash Reverse Shell
docker123321/tomcat22	Containers add attacker’s SSH key
docker123321/cron   docker123321/cronm   docker123321/cronnn   docker123321/mysql   docker123321/mysql0   docker123321/data   docker123321/t1   docker123321/t2	Containers run embedded cryptocoin miners.   (On condition that container runs, it will download a malicious .jpg file that runs in bash and exposes mining software.)
docker123321/kk	Containers run embedded crypto coin miners.   (On condition that container runs, it will download a malicious .sh file that runs in bash and exposes mining software.)

According to current evidence, in the vast majority of cases, attackers used these poisoned Docker images to install XMRig-based Monero miners on victims' machines.

In just one campaign the Kromtech team managed to track down, they say the docker123321 actor mined 544.74 Monero using his victims' servers, which is about $90,000 at today's exchange rate. Other campaigns using other Monero wallet addresses might store even more ill-gotten funds.

Some affected servers may still be compromised

Nonetheless, Kromtech researchers warn that some of these images also contained backdoor-like capabilities thanks to the embedded reverse shells.

This means that even if victims stopped using or removed the malicious Docker images, the attacker could have very easily obtained persistence on their systems through other means, possibly granting them access to the system at a later time.

Wiping systems entirely is probably the safest bet for users who've used one of the 17 Docker images listed in the tables above.

"For ordinary users, just pulling a Docker image from the DockerHub is like pulling arbitrary binary data from somewhere, executing it, and hoping for the best without really knowing what’s in it," Kromtech researchers said, explaining the dangers of using unvetted code from a public repository like Docker Hub.

When dealing with Docker and Kubernetes-based environments, the safest bet is to use your homemade Docker images or by using verified images, whenever possible.