Threat Alert: Massive Cryptomining Campaign Abusing GitHub, Docker Hub, Travis CI & Circle CI

Aqua’s Team Nautilus detected an impressive campaign that set out to hijack resources to enable cryptocurrency mining. This operation focused on several SaaS software development environments, including Docker Hub, GitHub, Travis CI, and Circle CI, by abusing their automated build processes.

Fortunately, our research efforts occasionally include scanning images on Docker Hub using Aqua Dynamic Threat Analysis (DTA) and we were able to detect and investigate this campaign within hours of its initial launch. The affected service providers were then notified by our research team with details of this attack.

An Orchestrated “Blitz” Campaign

The infrastructure of this campaign consisted of 11 GitHub users who created 51 GitHub projects that were masquerading as popular software projects (such as nginx, okular, openssh, openvpn, seahorse, nautilus, zookeeper etc.). The adversary similarly created 56 Docker Hub accounts also using the names of popular software. All of this happened over the course of only a few hours. During the build process, these container images proceeded to download a cryptominer from a single GitHub repository. All 56 Docker Hub images were detected within a couple of hours after they were created. Based on these findings, a Team Nautilus researcher connected the dots to uncover the entire attack kill chain.

All the images were set to download the same binary file. This file — GCC — is marked as malicious by VirusTotal.

The adversary has named the binary “GCC” in order to disguise the PUA to a compiler system (The GNU Compiler Collection – GCC – is a compiler system that is a key component for most projects related to Linux, including the Linux kernel).

A New Modus Operandi for Cryptocurrency Attacks

Interestingly, the adversaries are abusing a fundamental service of GitHub, Docker Hub, Travis CI, and Circle CI. We’ve seen other container supply chain attacks that leverage public images in hopes of abusing the container runtime environment – but in this new campaign, the infrastructure of the build process itself is being abused.

The images are built on these service providers’ environments and then hijack their resources in order to mine cryptocurrency. The sophisticated build mechanism in the Dockerfile is as follows:

1. Ubuntu base image is set.
2. /workdir is defined as working directory.
3. CURL installation is verified.
4. Using CURL, the binary GCC file (PUA) is downloaded from GitHub as well as a configuration file.
5. The file Docker.sh is copied into the working directory and executed. This is what the file Docker.sh is doing:

• The binary GCC (the Cryptominer) is executed with the configuration file.
• While the miner is running the GitHub, the repository is cloned.
• Two files are randomly selected, and their content is replaced.
• A random commit message is submitted.
• The repository is pushed back to GitHub.

1. PUA files are deleted.
2. The file git is set in CMD.

When pulling and running the image it fails, since the CMD is instructing to run a JSON file with bash command.

Since these projects and container images were created, they each have committed thousands of code changes. Each commit is executing a build process by all of the above-mentioned services, and on each build, a cryptominer is executed. For three days, this campaign amassed over 23.3K commits in GitHub and 5.8K builds in Docker Hub, translating into ~30K Monero mining sessions. Currently, Docker Hub limits automated builds to a two-hour duration, which leaves the attackers plenty of time to abuse this feature.

It could be that the adversaries are trying to abuse this feature as much as they can. This campaign can easily be modified to attack innocent end-users (such as Developers, DevOps). If the adversaries change the CMD to execute the miner, this campaign can target anyone who downloads these images.

In Summary

This attack represents yet another example of the evolving creativity of adversaries. They are persistent in their pursuit of abusable cloud compute resources wherever they can get them. This is also a reminder that developer environments in the cloud are just as susceptible to attack as production environments, and sometimes more so because they are not getting the same level of security attention.

As always, we recommend that such environments have strict access controls, authentication, and least-privilege enforcement, but also continuous monitoring and restrictions on outbound network connections to prevent both data theft and resource abuse.