{"id":12538,"date":"2019-10-19T00:10:45","date_gmt":"2019-10-18T21:10:45","guid":{"rendered":"https:\/\/saudishopper.com.sa\/en\/?p=12538"},"modified":"2026-03-27T18:43:00","modified_gmt":"2026-03-27T15:43:00","slug":"graboid-first-ever-cryptojacking-worm-found-in-images-on-docker-hub","status":"publish","type":"post","link":"https:\/\/saudishopper.com.sa\/en\/graboid-first-ever-cryptojacking-worm-found-in-images-on-docker-hub\/","title":{"rendered":"Graboid: First-Ever Cryptojacking Worm Found in Images on Docker Hub"},"content":{"rendered":"

Unit 42 researchers identified a new cryptojacking worm we\u2019ve named Graboid that\u2019s spread to more than 2,000 unsecured Docker hosts. We derived the name by paying homage to the 1990\u2019s movie \u201cTremors,\u201d since this worm behaves similarly to the sandworms in the movie, in that it moves in short bursts of speed, but overall is relatively inept.<\/p>\n

There have been incidents of cryptojacking malware\u00a0spreading as a worm<\/a>, but this is the first time we see a cryptojacking worm spread using containers in the Docker Engine (Community Edition). Because most traditional endpoint protection software does not inspect data and activities inside containers, this type of malicious activity can be difficult to detect. The malicious actor gained an initial foothold through unsecured\u00a0Docker daemons<\/a>,\u00a0<\/a>where a Docker image was first installed to run on the compromised host. The malware, which was downloaded from command and control (C2) servers, is deployed to mine for\u00a0Monero<\/a>\u00a0and periodically queries for new vulnerable hosts from the C2 and picks the next target at random to spread the worm to. Our analysis shows that on average, each miner is active 63% of the time and each mining period lasts for 250 seconds. The Docker team worked quickly in tandem with Unit 42 to remove the malicious images once our team alerted them of this operation.<\/p>\n

Containerized Cryptojacking Worm<\/strong><\/p>\n

Figure 1. Cryptojacking worm activity overview<\/em><\/p>\n

A quick\u00a0Shodan<\/a>\u00a0search shows that show that more than 2,000 Docker engines are insecurely exposed to the internet. Without any authentication or authorization, a malicious actor can take full control of the Docker Engine (CE) and the host. The attacker leverages this entry point to deploy and spread the worm. Figure 1 illustrates how the malware is delivered and spread. The attacker compromised an unsecured docker daemon, ran the malicious docker container pulled from Docker Hub, downloaded a few scripts and a list of vulnerable hosts from C2 and repeatedly picked the next target to spread the worm. The malware, which we\u2019ve named \u2018Graboid\u2019, carries out both worm-spreading and cryptojacking inside containers. It randomly picks three targets at each iteration. It installs the worm on the first target, stops the miner on the second target, and starts the miner on the third target. This procedure leads to a very random mining behavior. If my host is compromised, the malicious container does not start immediately. Instead, I have to wait until another compromised host picks me and starts my mining process. Other compromised hosts can also randomly stop my mining process. Essentially, the miner on every infected host is randomly controlled by all other infected hosts. 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.<\/p>\n

Below is a more detailed step-by-step operation:<\/p>\n

    \n
  1. The attacker picks an unsecured docker host as the target and sends remote commands to download and deploy the malicious Docker image\u00a0pocosow\/centos:7.6.1810<\/em><\/strong>. The image contains a\u00a0docker client<\/a>tool that is used to communicate with other Docker hosts.<\/li>\n
  2. The entry point script\u00a0\/var\/sbin\/bash<\/strong>in the pocosow\/centos container downloads 4 shell scripts from the C2 and executes them one by one. The downloaded scripts are\u00a0sh<\/strong>,\u00a0worm.sh<\/strong>,\u00a0cleanxmr.sh<\/strong>,\u00a0xmr.sh.<\/strong><\/li>\n
  3. sh<\/strong>sends the number of available CPUs on the compromised host to the C2.<\/li>\n
  4. sh<\/strong>downloads a file \u201cIP\u201d that contains a list of 2000+ IPs. These IPs are the hosts with unsecured docker API endpoints. worm.sh randomly picks one of the IPs as its target and uses the docker client tool to pull and deploy the\u00a0pocosow\/centos<\/strong>\u00a0container remotely.<\/li>\n
  5. sh<\/strong>randomly picks one of the vulnerable hosts from the IP file and stops the cryptojacking containers on the target. cleanxmr.sh stops not only the cryptojacking container the worm deploys (gakeaws\/nginx) but also few other xmrig-based containers if they are running.<\/li>\n
  6. sh<\/strong>randomly picks one of the vulnerable hosts from the IP file and deploys the image\u00a0gakeaws\/nginx<\/strong>\u00a0on the target host. gakeaws\/nginx contains an xmrig binary that is masqueraded as nginx.<\/li>\n<\/ol>\n

    Step 1 to Step 6 is repeated periodically on every compromised host. The last known refresh interval is set to 100 seconds. The refresh interval, the shell scripts, and the IP file are all downloaded from the C2 after the pocosow\/centos container is launched.<\/p>\n

    At the time of writing, Docker image\u00a0pocosow\/centos<\/strong>\u00a0has been downloaded more than 10,000 times and\u00a0gakeaws\/nginx<\/strong>\u00a0has been downloaded more than 6,500 times, as shown in Figure 2. We also noticed that the same user (gakeaws) published another cryptojacking image,\u00a0gakeaws\/mysql<\/strong>, that has the identical content to\u00a0gakeaws\/nginx<\/strong>.<\/p>\n

    The malicious intent of the\u00a0pocosow\/centos<\/strong>\u00a0image can\u2019t be known until the shell scripts are downloaded and executed inside the container. However, the malicious intent of the\u00a0gakeaws\/nginx<\/strong>\u00a0image can be easily spotted from its image build history. As shown in Figure 3, it simply renames the xmrig binary to nginx at the build time (Line 7). Even the payment address is hard-coded to an environment variable during the build time (Line 6).<\/p>\n

    Figure 4 shows the location of the 2,034 vulnerable hosts listed in the IP file \u2014 57.4% of the IPs originated from China, followed by 13% from the U.S. We also noticed that out of the 15 C2 servers that the malware uses, 14 hosts are listed in the IP file and the other one host has more than 50 known vulnerabilities. It indicates that the attacker likely compromised these hosts and used them as C2 servers. With the control of the Docker daemon, it is straightforward to deploy a web server container (e.g., httpd, nginx) and place the payload there.<\/p>\n

    Figure 2. Malicious Docker images on Docker Hub<\/em><\/p>\n

    Figure 3. The image history of gakeaws\/nginx<\/em><\/p>\n

    Figure 4. Countries of the vulnerable hosts in the IP file<\/em><\/p>\n

    Worm Simulation<\/strong><\/p>\n

    To better understand the effectiveness of the worm and its overall mining power, we created a simple Python program to simulate the worm. Assume that there are 2,000 hosts in the IP file, 30% of these hosts fail during the operation, a 100-seconds refresh interval and one CPU on each compromised host. The experiment simulates a 30-day campaign. We are interested in finding out:<\/p>\n

      \n
    1. How long does it take for the worm to spread to all the vulnerable Docker hosts?<\/li>\n
    2. How much mining power does this malicious actor own?<\/li>\n
    3. How much time does each miner stay active on an infected host?<\/li>\n<\/ol>\n

      The left part of Figure 5 shows how fast the worm spreads. It takes about 60 minutes for the worm to reach all the 1,400 vulnerable hosts (70% of the 2,000+ hosts). The right part of Figure 5 shows the overall mining power of the compromised hosts. There are, on average, 900 active miners at any time. In other words, the malicious actor owns a 1,400 node mining cluster that has at least 900 CPU mining power. Because miners on the infected hosts can randomly start and stop, each miner is only active 65% of the time and each mining period lasts for only 250 seconds on average.<\/p>\n

       <\/p>\n

      Conclusion<\/strong><\/p>\n

      While this cryptojacking worm doesn\u2019t 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\u2019t be ignored. If a more potent worm is ever created to take a similar infiltration approach, it could cause much greater damage, so it\u2019s imperative for organizations to safeguard their Docker hosts.<\/p>\n

      Below is a list of best practices for organizations to help prevent from being compromised:<\/p>\n