Unpacking Cloud-Based Cryptocurrency Miners That Abuse GitHub Actions and Azure Virtual Machines

In this section, we cover how malicious actors are leveraging Windows runners in their attempts to mine cryptocurrency, as well as the persistence techniques they use to dodge detection by GitHub to prevent their Actions from being disabled. GitHub provides the runner, a server designed to run workflows (aka Actions). Workflows are deployed on Azure and terminated after an enterprise’s automation is completed. While this service has its limits, users do not pay anything to use it, even with a free GitHub account. 

Figure 2 (retrieved here) shows one of the many YAML scripts we found while analyzing hundreds of repositories on GitHub:

We unpack this workflow YAML to better understand the process involved here:  

• Lines 1 and 2. The malicious actors set a trigger for GitHub Actions workflow called “CI/CD” to commence upon any push or pull request events. This means the workflow begins when you push a commit or tag, or when changes are made to a pull request in a repository.  
  
• Lines 3 to 6. The workflow is running only one job called “CI” and named “Run Tests” using the latest version of the Windows runner provided by GitHub inside Azure. More details on the technical specifications of this GitHub-hosted runner can be found here.   
• Lines 7 to 12. This part uses a multidimensional matrix strategy to create multiple job runs at the same time. The GitHub official documentation provides more details on how to use a matrix for your jobs. The maximum number of concurrent jobs is set to 50 with the max parallel directive on line 8. This allows the malicious actors to make the most out of the servers so that they can mine cryptocurrency before their incursions are discovered and shut down. Malicious actors define how the Action will handle job failures on line 9. By default, fail-fast is set to true, which means that it will cancel any other jobs, whether in progress or queued, should any of the other jobs in the matrix fail. On the other hand, attackers will set the fail-fast to false since they do not want any of the jobs to fail, and so that other jobs continue running despite failures occurring in others that are running in parallel. The next step is defining the matrix itself, used only to set the number of concurrent jobs. This is set to 60 in this case. Based on the number of entries on each directive, the total number of jobs in this two-dimensional matrix is 60 (from 6 x 10 = 60). This, however, doesn’t make sense since we saw earlier that the attackers set the max parallel to 50 jobs, implying a possible mistake in their calculation. 
• Lines 13 to 23. The steps being executed by the job are stated during each run. The first one, named “Checkout,” uses a third-party action provided by GitHub to check out the current repository inside the runner before doing anything. The code for this action can be found here. The second step, starting on line 16, is called sad-path (retry_wait_seconds). This also runs another third-party GHA that now belongs to a regular GitHub user. It retries a GHA step on failure or timeout. The code for this action can be found here. Lines 19 to 23 set the details to retry the step to run the cryptocurrency miner binary by waiting for 15 seconds before the retry and only attempting to retry it twice before failing the step or after a timeout of 10 minutes. The retry GHA description can be found here. The continue-on-error command guarantees that the job exits successfully even if an error occurs.

There was another Portable Executable (PE) binary inside the repository named lang.exe, but it wasn’t being used by GitHub Actions. Nonetheless, we analyzed it and found that it was another cryptocurrency miner, only with fewer detections according to VT. 

This next repository we analyzed was published on GitHub in April 2022. Similar variations of the same GHA script can be found from different users. Figure 6 shows the GHA workflow script labeled as kapten_crypto, (retrieved here). This is set to be manually triggered with the workflow dispatch directive.

Looking at the repository structure, we can clearly see how it shows that the user does not understand GitHub Actions very well, having created the GHA YAML in different locations with different names and extensions. We saw that the worflows file on the repository root as well as the one found on .GitHub/workflows and .github/Workflows were all the same. Someone familiar with GHA would know that the workflow scripts should be placed under .github/workflows inside the root directory and with their YAML/YML extension for the scripts to work. Workflows with “W” in uppercase are also accepted, but it is important to remember adding “S” at the end.  

Going back to the GHA script on Figure 6, we can see a few similarities with the previous one we just analyzed. It uses the multidimensional matrix strategy that sets the max parallel jobs to 5 and disables the fail-fast approach by setting it to false on lines 7 to 12. It creates an environment variable, NUM_JOBS, and sets it to 20. Then it creates each job by labeling them using the matrix parameters on lines 13 to 15. After that, it has three main steps: download, extract, and run.  

• Download (lines 17 and 18). This uses the Invoke-WebRequest PowerShell command to download the XMRig Windows binary from its GitHub repository.  
  
• Extract (lines 19 and 20). The next step also uses a PowerShell command called Expand-Archive to extract the files from the zip. 
• Run (lines 21 and 22). The last step is to run the xmrig.exe binary with a few parameters such as the URL of the mining server (-o), the mining algorithm (-a), and the user (-u), among others. A more detailed reference of the command-line options can be found here. 

The following list of repositories shows similar versions of this same script. After cross-referencing the usernames or wallet addresses, we were able to identify that different GitHub users were using the same wallet, suggesting that they are either the same person or a group working together as a pool.  

Cryptocurrency miners that abuse Linux runners

Linux and Windows runners are hosted on Standard_DS2_v2 virtual machines on Azure. Both have two vCPUs and 7 GB of memory, according to the GitHub documentation. Upon discussion with some fellow professionals and legitimate cryptocurrency miners, and considering that these runners are not GPU-based, we can assume that it is more profitable for the cybercriminals to leverage the Linux runners instead of the Windows ones. But without any direct comparison, one cannot say for certain why some choose the Windows runners if that were the case.

Cryptocurrency miners that abuse the Linux runners follow an approach that resembles the one that cybercriminals use to exploit Windows runners to start and run their mining scripts as shown in the following image (retrieved here).

For our purpose, we focus only on the code that is relevant to performing the mining steps:  

• Lines 32-33. The script does exactly what the step describes — it downloads the XMRig binary inside the runner from the GitHub repository. 
  
• Lines 35-36. The script extracts all *.gz files in the current folder. It will only extract the XMRig files present in that folder. 
• Lines 38-41. This step runs two basic Linux commands (pwd and ls) to show the current directory and list the files. However, we think this is a needless step at this stage.  
• Lines 43-50. This command starts the mining process by running the XMRig binary with the proper parameters such as the mining pool, the user, setting keepalive, and enabling TLS. 
• Lines 53-54. This is essentially the same command from line 50, which doesn’t make much sense unless you know that the previous command failed, and you are running it again. But since there are no checks, we think that this command is redundant. 

Fortunately, this GitHub Action, along with many others analyzed and reported in this article, has already been flagged and disabled by GitHub. We can see this by going to the Actions tab inside the repository and noting the alert in Figure 9 (retrieved here): 

As we saw in the mining scripts on Figure 9 and in several attacks reported in the past, malicious actors prefer to leverage Monero as their cryptocurrency of choice since Monero CPU-based mining done at scale provides a decent ROI. They therefore deem it a worthwhile endeavor to compromise a significant number of systems and subsequently integrate them into the mining pools 

Red flag: Is this something to be concerned about? 

For as long as the malicious actors only use their own accounts and repositories, end users should have no cause for worry. This is a problem GitHub is cognizant of and is trying to address and mitigate as much as possible. However, it is hard to eliminate the problem entirely.  

Problems arise when these GHAs are shared on GitHub Marketplace or used as a dependency for other Actions. As discussed in a prior report, anyone can create and share GHA on GitHub Marketplace. This is why it is recommended to exercise caution and discernment when choosing a shared GHA from Marketplace. We advise looking for the “uses” directive on your GHA YAML files, and for each , you can go to github.com/username/action to see its source code. For example, in Figure 2, on line 18, there is the nick-invision/retry@v2, which as we previously showed, can be found at https://github.com/nick-fields/retry. 

Users can also enhance the security of their Actions by going to Settings à Actions inside each repository they own to apply proper settings such as Actions and workflow permissions, forked pull requests, and log retention expiration.