In a recent attack campaign, cybercriminals were discovered cleverly manipulating GitHub's search functionality, and using meticulously crafted repositories to distribute malware.
Key Points
Exploiting GitHub's Search Functionality
Our recent findings reveal a threat actor creating GitHub repositories with names and topics that are likely to be searched by unsuspecting users. These repositories are cleverly disguised as legitimate projects, often related to popular games, cheats, or tools, making it difficult for users to distinguish them from benign code.
To ensure maximum visibility, the attackers employ a couple of clever techniques that consistently place their malicious repositories at the top of GitHub search results.
Automatic Updates
By leveraging GitHub Actions, the attackers automatically update the repositories at a very high frequency by modifying a file, usually called "log", with the current date and time or just some random small change. This continuous activity artificially boosts the repositories' visibility, especially for instances where users filter their results by "most recently updated," increasing the likelihood of unsuspecting users finding and accessing them.
Faking Popularity
While automatic updates help, the attackers combine another technique to amplify the effectiveness of their repo making it to the top results.
The attackers employed multiple fake accounts to add bogus stars, creating an illusion of popularity and trustworthiness. This artificially boosts the repositories' visibility further, especially for instances where users filter their results by "most stars."
In contrast to past incidents where attackers were found to add hundreds or thousands of stars to their repos, it appears that in these cases, the attackers opted for a more modest number of stars, probably to avoid raising suspicion with an exaggerated number.
Many of the stargazers are created on the same date. A red flag for fake accounts.
This social engineering technique is designed to manipulate users into believing that the repository is widely used and reliable, preying on the inherent trust users place in highly-starred repositories.
Unsuspecting users, often drawn to the top search results and repositories with seemingly positive engagement, are more likely to click on these malicious repositories and use the code or tools they provide, unaware of the hidden dangers lurking within.
For a deeper dive into the tactic of fake stars, check out our recent blog that explores this manipulation technique in greater detail.
Hidden Malware in Project Files
The attackers conceal their malware primarily as obfuscated code deep within the .csproj or .vcxproj files of the repository (files commonly used in Visual Studio projects) to decrease the chances of the average user detecting it unless they proactively search for suspicious elements.
However, it's worth noting that there have been a small number of other detected repos that contained different malware within other files.
Technical Analysis of the Common Malicious Payload
The malicious script is embedded within a pre-build event of a Visual Studio project file (.vcxproj) and is designed to be executed automatically during the build process. The script consists of two main parts:
The batch script creates a temporary directory, generates a VBScript file, and decodes the base64-encoded PowerShell script. It then executes the decoded PowerShell script and cleans up the temporary files.
The decoded PowerShell script performs the following malicious actions:
The script also employs error handling to silently catch exceptions and continue execution.
Active Campaign
On April 3rd, the attacker updated the malicious code within one of their repositories, pointing to a new URL that downloads a different encrypted .7z file containing an executable named feedbackAPI.exe.
The attacker had padded the executable with many zeros, a technique used to artificially boost the file size. Due to this padding, the file size exceeded the threshold of many security solutions, VirusTotal being a notable one, preventing the possibility of it from being scanned. According to VirusTotal's documentation,
"If the file to be uploaded is bigger than 32MB, please use the /private/files/upload_url endpoint instead which admits files up to 650MB.”
The padded feedbackAPI.exe file was 750MB in size, exceeding even the increased limit for the alternative endpoint.
The results of our analysis of this malware suggest that the malware contains similarities to the "Keyzetsu clipper" malware, a relatively new addition to the growing list of crypto wallet clippers commonly distributed through pirated software.
This executable file also attempts to create persistence on Windows machines. It achieves this by creating a shortcut to the exe file and then establishing a daily scheduled task named "Feedback_API_VS_Services_Client" that executes the shortcut at 4AM. Notably, this task is created without any confirmation prompts, making it stealthier and more likely to go unnoticed by unsuspecting users.
Indicators of Successful Exploitation
Evidence indicates that the attackers' campaign has successfully deceived unsuspecting users. Numerous malicious repositories have received complaints through Issues and pull requests from users who experienced problems after downloading and using the code.
Conclusion
The use of malicious GitHub repositories to distribute malware is an ongoing trend that poses a significant threat to the open-source ecosystem. By exploiting GitHub's search functionality and manipulating repository properties, attackers can lure unsuspecting users into downloading and executing malicious code.
To prevent falling victim to similar attacks, it is recommended to keep an eye on the following suspicious properties of a repo:
By being aware of these red flags, users can better protect themselves from inadvertently downloading and executing malware.
In the aftermath of the XZ attack and many other recent incidents, it would be irresponsible for developers to rely solely on reputation as a metric when using open source code. A developer who blindly takes code also blindly takes responsibility for that code. These incidents highlight the necessity for manual code reviews or the use of specialized tools that perform thorough code inspections for malware. Merely checking for known vulnerabilities is insufficient.
As part of Checkmarx's commitment to supply chain security, our research team continuously monitors and detects suspicious activities in the open-source software ecosystem. We track and flag potential indicators of malicious behavior and promptly alert our customers and the community to help protect them from these evolving threats.
Working together to keep the open source ecosystem safe.
IOC