The use of public services as command-and-control (C2) infrastructure isn’t a revolutionary technique for malicious actors. ReversingLabs has observed such behavior in several malware campaigns throughout the last few years.
Malware authors occasionally place their samples in services like Dropbox, Google Drive, OneDrive and Discord to host second stage malware and sidestep detection tools. However, the ReversingLabs threat research team has recently observed the increasing use of the GitHub open source development platform for hosting malware.
Here are two novel techniques deployed on GitHub that were discovered by ReversingLabs. The first abuses GitHub Gists, and the second issues commands through git commit messages.
Public services as C2 infrastructure
In one of our previous research team posts, we described a malicious npm package masquerading as the Material Tailwind CSS tool. The malware used Google Drive, Microsoft OneDrive and GitHub to fetch the address of the real C2 server. This is historically the most common use case of public services being used for malicious purposes: fetching of the real C2 address.
However, several families of infostealers published to open source package repositories have also been seen using Dropbox and Discord services to host two stage malware instead of just the location of the real C2 server. Versions of W4SP and similar token stealers, which are typically used as the second stage for downloader PyPI packages, were hosted on GitHub and (more commonly) as Discord attachments. The same approach has been observed in the fake Roblox NPM packages we observed delivering the LunaGrabber malware. With the recent IAmReboot campaign the ReversingLabs threat research team documented, the distributed malicious NuGet downloaders also hosts a second stage, obfuscating a version of the SeroXen RAT on a GitHub repository.
There are several reasons why malware authors decide to use public services as C2 infrastructure. The first is that network communication of the infected host with such services is less likely to raise suspicion than communication to an obscure domain or IP address. This is especially true, because developers are becoming a primary target for software supply chain attacks. In a perfect world, there’s nothing suspicious about a developer’s computer communicating with a GitHub repository. However, in light of these attacks, organizations can’t assume that such traffic is benign.
Also, standing up and running C2 infrastructure on platforms like GitHub is simpler than cybercriminals operating their own server. By using public services, the attacker needs only to create an account to access the service, and then publish the desired content to their repository. It falls to the service itself to manage communications and ensure uptime and so on. This eliminates the time and money malware authors need to spend on the maintenance of their attack infrastructure.
Malware (ab)using GitHub Gists
Two interesting malware types using GitHub features have recently been detected during our threat research activities, which the team performs using the ReversingLabs Software Supply Chain Security platform. The first one used GitHub Gists for hosting two-stage malicious payloads.
Gists are a GitHub feature that provides a simple way to share code snippets with other developers, and can be public or secret. As described in Gists documentation: “Secret gists don't show up in Discover and are not searchable unless you are logged in and are the author of the secret gist. Secret gists aren't private. If you send the URL of a secret gist to a friend, they'll be able to see it.” Another nice characteristic of secret Gists is that they don’t end up being visible in the GitHub profile page of the author. From an attacker's perspective, this makes them usable as a kind of a pastebin service which doesn’t raise much suspicion.
In this incident, several PyPI packages presented themselves as libraries for handling network proxying, and contained a Base64 encoded string, allegedly related to telemetry data, but actually containing a URL, pointing to a secret Gist. Malware authors used Base64 encoding to obfuscate the true purpose of this string and make it harder for security tools to detect it as suspicious. Base64 encoding is often used to encode some binary data before it gets transferred over the network. Nevertheless, an experienced eye will quickly recognize that the first few characters of this concrete string get decoded to “http” — almost surely the beginning of an URL, and therefore a red flag for a threat analyst.
Figure 1: Fetching and executing commands from a Base64 encoded URL
The malicious code was hidden in the setup.py file. It was implemented by extending setuptools commands, specifically the egg_info command. The code inside PostEggInfoCommand visible in Figure 1 decodes a Base64 encoded URL from which it also fetches Base64 encoded Python commands that are executed in a new process.
Figure 2: Extending setuptools commands in setup.py
The interesting part about this malware sample is the decoded URL, which points to a secret Gist belonging to the user yeremyvalidslov2342 — a throwaway account without any public projects, created the same day as the malicious PyPI package. Using Gists for delivery of malicious commands to infected machines isn’t a frequently seen technique. Google search on this topic doesn’t give many results. Our threat research team was able to find only one mention of such a technique being actively used by malware, in a Trend Micro report on SLUB Backdoor from March 2019.
Figure 3: Secret Gist containing Base64 encoded commands
Malware fetching commands from git commit messages
The second interesting malware type the ReversingLabs threat research team discovered is a sample that abuses version control system features and was detected in the easyhttprequest PyPI package. The malicious code was once again hidden in the setup.py file and implemented by extending the same egg_info setuptools command.
This malicious package is using an original technique for command delivery. After installation on the victim's machine, the malicious code from this package clones a specific git repository from GitHub and checks if the “head” commit of this repository contains a commit message that starts with a specific string. If it does, it strips that magic string and decodes the rest of the Base64 encoded commit message, executing it as a Python command in a new process.
However, the code in this form isn’t executing malicious functionality since the name of the variable used for condition validation doesn’t match the name of the variable containing Base64 encoded commit message. It is unclear if the malware author did this on purpose or by mistake. The referenced GitHub repository that is cloned is a fork of a legitimate looking PySocks project. At time of publication of this research, it didn’t yet contain the commit with a malicious commit message.
Figure 4: Fetching and executing commands from a Base64 encoded commit message
Conclusion
Using GitHub as C2 infrastructure isn't new on its own, but abuse of features like Git Gists and commit messages for command delivery are novel approaches used by malicious actors. We have not previously observed malware using such methods of command delivery, nor are we aware of third-party reports documenting such activity. Also, based on an identical execution technique, similar abuse of uncommon GitHub features, and the impersonation of similar networking utilities — ReversingLabs researchers believe that the same malware author is likely behind both of these campaigns.
Despite these malicious packages being taken down from PyPI, the threat research team expects that more GitHub tricks like these will be seen soon. This is because the malware author behind these incidents is still publishing new malware samples, despite the previous version of malware getting removed from PyPI shortly after.
Our discoveries of these novel attack methods serve as yet another reminder hat developers must remain wary of the threats that lie within the open source ecosystem. As attackers are becoming more skilled in their deployment of malware, it is essential that developers and application security teams are able to differentiate between malicious and legitimate packages on these platforms. This is why software producers should utilize modern tooling that employs complex binary analysis, which provides comprehensive software software supply chain security.
Indicators of Compromise (IOCs)
Indicators of Compromise (IoCs) refer to forensic artifacts or evidence related to a security breach or unauthorized activity on a computer network or system. IOCs play a crucial role in cybersecurity investigations and cyber incident response efforts, helping analysts and cybersecurity professionals identify and detect potential security incidents.
The following IOCs were collected as part of ReversingLabs investigation of this software supply chain campaign.
PyPI packages:
| package_name | version | SHA1 |
| httprequesthub | 2.31.0 | fa64041676f22ac3ea55170c6594b5142d3e45ac |
| httprequesthub | 2.31.1 | abd752e9603f9714f4e8b6860ad148d4003151a2 |
| httprequesthub | 2.31.3 | b8e878bb3a47c6ca66e5f962a3e7f92f0a47324f |
| httprequesthub | 2.31.4 | b39f20452100f2fc3dc27088876ef4c07ede5f36 |
| pyhttpproxifier | 0.9.2 | eb18768cbe6b74394c46162008a289e0b5e191f0 |
| pyhttpproxifier | 0.9.3 | 04f0ffd63368d84ec320cfae5b059eb7431b758f |
| easyhttprequest | 2.31.4 | 8b5de82c0a51bd0e5be225a1ae968c8fad2467bb |
| easyhttprequest | 2.31.5 | 0058dffe115f5d631a5f0a93a69ef88dc29d2c2d |
| libsock | 1.1.3 | fd727a37938e9d94d3bc6159bee398a915e74465 |
| libproxy | 1.1.4 | 38e431bfc8496e80e59077efa4a5889763a812fc |
| libproxy | 1.1.5 | c1fe2550edd3815f7a72a98dabd4a450419e0592 |
| libsocks5 | 1.1.1 | fa761695087db89316cac5accf6eae332bda4803 |
| libsocks5 | 1.7.0 | e9a42bdeb8da3a460dde3b2c162ed1fd65d07bb0 |
| libsocks5 | 1.7.1 | 687abd0a47c26c112309bb16238c7cf8238239d9 |
| libsocks5 | 1.7.3 | b5e0e89d7d675b6804bdb3a86e1c4609be5d7689 |
| libsocks5 | 1.7.4 | 7f27520be02c490b7b12ad4001bd63fb98245c63 |
