“Gitting” the Malware: How Threat Actors Use GitHub Repositories to Deploy Malware
The CrowdStrike Falcon® Complete™ managed detection and response (MDR) team recently uncovered a creative and opportunistic interpretation of a watering hole attack that leverages GitHub to gain access to victim organizations. In the observed cases, there were no phishing emails, no exploitation of public-facing vulnerabilities, no malvertising and no compromised credentials. Instead, the threat actor leveraged a misconfiguration in GitHub repositories to get code execution and initial access on thousands of hosts across what are likely multiple victim environments worldwide.
In addition to detailing what the team observed, this blog will show how Falcon Complete MDR provides comprehensive protection against these undocumented and new threats.
The Initial Detection
During one of Falcon Complete’s routine investigations, an analyst discovered an unusual detection on a customer’s host without a clear source of threat. Closer inspection of the process tree showed a terminal window running an administrative tool which then spawned a binary called
Client32.exe (see Figure 1).
An online search for the administrative tool showed it was a potentially legitimate tool available for download via GitHub. Close inspection of the tool’s GitHub page revealed that the command line parameters and usage were the same as the commands Falcon Complete saw the user manually running under
cmd.exe. However, the binary didn’t appear to be operating as the user intended; instead it was creating and executing an additional binary named
Client32.exe. Taking a closer look in the Falcon UI (see Figure 2) we can clearly see that “Client32.exe” is a signed version of the NetSupport remote admin tool. At this stage it appears this was not the legitimate tool the user wanted.
Why would this legitimate administrative tool from GitHub execute a remote admin tool? Review of the enterprise activity monitoring (EAM) data (i.e., the raw telemetry generated by the Falcon sensor) in the Falcon UI revealed that just before this activity occurred the remote admin tool was downloaded and extracted to a local folder on the disk, and DNS requests for GitHub were observed. A review of the affected host showed that the file was recorded as being downloaded from the legitimate GitHub wiki page, so it remained unclear how this file could be any different than the legitimate one.
During this review, the Falcon Complete analysts expanded their investigation to analyze similar activity in another customer environment. In this case the NetSupport remote admin tool had attempted to spawn under a different tool that a user had also downloaded from GitHub. The process tree was virtually the same as the one shown in Figure 1, except with a different administrative tool.
It remained to be seen how these malicious files were getting onto the endpoints and why users were executing them. To better understand the source of this threat and how it was occurring, Falcon Complete used Falcon Real Time Response (RTR) — CrowdStrike’s method of connecting into hosts within the CrowdStrike Falcon®® platform — to review additional details on the host such as internet history, enabling deeper investigation of the suspicious downloaded file. Analysts were able to identify the file being downloaded and the “referrer” — a http header containing an address of the page making the request — that pointed to the legitimate GitHub page (see Figure 3).
The internet history showed the URL chain — the recording of every URL that was passed through for the downloading of the file — which unlocked the missing pieces: the user clicked on a link from the legitimate wiki (the referrer from above), which pointed to a redirection URL service (Linkify) that directed the download to occur from an unknown GitHub account hosting the malicious file (see Figure 4).
After this discovery, Falcon Complete analysts examined similar activity across a number of customers to see if they could identify other attempts to install this malicious software. They found an interesting instance where the hijacked GitHub download chain was not a factor; instead a user had simply downloaded the malicious file through the shared fake malicious GitHub link and then downloaded the fake NetSupport binary. This was interesting because it was likely the result of an unsuspecting admin sharing malware thinking it was a legitimate admin tool. (See Figure 5.)
After identifying the source of the malicious software, Falcon Complete analysts turned their attention to how the malware was ending up in legitimate GitHub repositories. They reviewed the wiki of the trusted repository involved in the original detection, which revealed numerous successful attempts by new GitHub accounts to edit the wiki (see Figure 6).
Closer inspection revealed that a malicious actor had been able to edit the wiki to point to malware by changing the main download link. This confirmed that this actor was changing one of the main download links from the GitHub wiki to point to malware, which then redirects to an associated GitHub account to download the fake installer. (See Figure 7.)
After uncovering the source of the threat, Falcon Complete could explain to the customer how the threat had entered their environment and how the customer could prevent its users from facing this issue in the future. From a remediation point of view, Falcon Complete analysts were able to quickly and easily remove the offending files from affected hosts because the analysts had a list of all files that were dropped and downloaded to the hosts. In addition, because the Falcon sensor had killed the malicious processes, the hosts were already protected.
The Falcon Complete team had successfully remediated the victim environment and identified the problem but remained curious about how these GitHub wikis had been tampered with. How could GitHub accounts that had been created only recently edit wikis for highly popular GitHub accounts? To find out, Falcon Complete analysts went to the source, logging in to GitHub to see what the threat actors were seeing, and noticed the buttons shown in Figure 8.
With a standard unprivileged account, analysts had the permissions needed to edit the wiki on these popular pages. However, this was inconsistent in that only some GitHub wikis had these open permissions. To investigate further, analysts created a new public repository to try and understand how this could be happening. While reviewing this new repository, analysts came across the configuration option to “Restrict editing to collaborators only,” as shown in Figure 9.
This suggests that all the “compromised” wikis that Falcon Complete analysts had uncovered were in fact misconfigured, allowing unprivileged GitHub user accounts to edit popular repositories. Numerous legitimate public repositories (with wikis) were taken advantage of and used by this threat actor by the selection of accounts they had created. It’s important to note that most of these pages were not small projects followed by only a few; rather, all of the identified pages had at least 1,000 stars. The most popular one, with over 140,000 stars (see Figure 10), was cause for greater concern as it indicated the possibility that this threat’s reach is substantial, particularly given that this page is also linked directly from an internet search.
Knowing this, owners of public repositories on GitHub are advised to review this setting. Starting from the repository’s main settings page (account logon required), users should see a checkbox next to “Restrict editing to collaborators only” under the Features section under wikis. Falcon Complete recommends you ensure this option is enabled, lest any valid GitHub user account be able to edit your wikis on these repositories.
Malicious GitHub Accounts
Further drilling down into the accounts reveals details on steps the threat actor may have taken in preparing for these campaigns. Below is an example account that was live for a number of days. It appears the threat actor would create numerous GitHub accounts and then fork a number of legitimate GitHub repositories. Figure 11 shows the threat actor forking two legitimate repositories.
In each of the forked repositories, they replaced the files located in the release section with malware. The other compromised wikis could then be edited to point to malware on seemingly legitimate GitHub accounts. Figure 12 shows this in action — the “Releases” section shows a large number of the same malicious binary, however, they were named to be relevant to the GitHub wikis they were targeting. Notice in this case the file size is identical; reviewing each of these files reveals that they had the same file hash, meaning they were the same malicious binary, only with different filenames.
Falcon Complete analysts uncovered numerous GitHub accounts created and used for these purposes that were seen delivering or attempting to deliver malware.
The threat actor’s next step was to use a different GitHub account to edit a wiki on a popular page that was vulnerable and then point back to the legitimate download link. However, this was done via the Linkify service, which allowed them to track all the relevant details likely to gauge the popularity of a particular link before pointing to the malware. After a period of time they would update the link as shown in Figure 13 to point to a different malicious link to download the malware. In addition, Falcon Complete analysts often saw that the threat actor would also update their malware links when certain GitHub accounts were taken offline. Threat actors would often edit and change their own links in the wikis to then point to different pieces of malware on other repos when the old GitHub accounts and repos had been disabled.
Figure 14 shows a small subset of the scale the threat actor was operating on.
MaaS — Cover All Your Bases
Because the scale of this campaign was rather large, Falcon Complete started tracking the relevant details to ensure that even if the threat actor changed their malware or techniques, analysts would know and could still protect customers against these changes. Yet while doing so, Falcon Complete analysts noticed something interesting about this threat actor — they had likely subscribed to at least four different malware-as-a-service (MaaS) offerings. MaaS is a business model between malware operators and affiliates in which affiliates pay to have access to managed and supported malware.
Analysts could see direct connections between the grouping of malicious GitHub accounts, whereby the threat actor uploaded different malware — Grind3wald, Raccoon Stealer, Zloader and Gozi, all part of known MaaS offerings — with the same versions to different repositories. So it appears this threat actor may have signed up for numerous MaaS offerings to ensure the best possible chance of bypassing endpoint security.
MaaS makes it easy for threat actors to leverage well-developed and fully functioning remote access tools without needing to know how to program. This highlights the malicious benefits of MaaS tooling and services, enabling less technically capable actors to conduct multiple campaigns.
The only infrastructure this threat actor was managing was likely the NetSupport Manager servers. But eventually the threat actor started hosting malware directly on GitHub instead of having to go through the NetSupport remote admin tool. Falcon Complete also saw instances of different types of malware, namely Grind3wald and Raccoon Stealer, being hosted on these same GitHub repositories.
Figure 15 highlights the basic flow of this attack, in which the threat actor uses the weakness in GitHub wiki permissions to introduce numerous different types of malware to unsuspecting users (often administrators) as they download their legitimate tools through GitHub.
This blog has shown the creativeness and ingenuity of threat actors in trying to achieve their goals of getting code execution on victim endpoints. The Falcon Complete team continues to look at new and evolving threats while endeavoring to stay ahead of those adversaries trying to harm CrowdStrike’s customers.