Hackers are abusing GitHub's search function to spread malware

Hackers are using the names of popular GitHub repositories to trick users into downloading malicious code, new research reveals.

Analysis from Checkmarx found cyber criminals are abusing GitHub’s search functionality to trick unsuspecting devs into loading malware onto their systems.

The report’s author, Checkmarx research engineer Yehuda Gelb, detailed how hackers use a series of techniques to artificially inflate the popularity of their fake repositories to push them further up GitHub search results.

The first of these involves leveraging the platform’s automation tool, GitHub Action, to frequently update the malicious repositories, making very minor tweaks to a log file or by updating the date or time, for example.

This activity on the repository boosts its visibility, particularly if developers choose to filter their search by those most recently updated  – a common choice for devs who want to ensure the code is properly maintained.

Attackers were also observed creating multiple fake accounts in order to promote their own malicious repositories, adding fake stars in an attempt to make the asset seem more trustworthy.

Gelb noted that this investigation found attackers had become more subtle in their attempts to push their fake repos on devs, learning from previous cases where attackers were easily identifiable by the sheer amount of churn their fake activity was creating.

“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”, Gelb explained.

“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.”

GitHub users should be wary of suspicious Visual Studio project files

The malicious code used in these attacks is often concealed within Visual Studio project files in order to evade detection, the study found, which executes automatically when the project is built.

Unless users explicitly search the repository for suspicious elements they won’t notice the dubious files, the report noted.

Interestingly, the PowerShell script contained in the malware retrieves the country code of the target machine’s IP address in order to determine if the victim is based in Russia. 

Based on where the victim is located, the payload downloaded onto the machine is different, suggesting the attackers could be located in Russia and tailoring their attacks to avoid impacting domestic entities, and reduce any unwanted attention from the state’s authorities.

The report includes advice on some indicators of compromise (IoC), including whether the repository in question has received complaints through the GitHub Issues feature, or pull requests from devs who experienced problems after downloading and deploying the code.

Gelb recommended developers scrutinize any repositories more closely, paying attention to the commit frequency. 

For example, does the repository have an incredible number of commits compared to how long it has been available on the platform? Or are these modifications only changing one file with minor edits?

Gelb also advised users to investigate the accounts that have starred the repository they are considering using, paying particular attention to how long these accounts have been active and whether this matches other accounts who have starred the repository.

All of these indicators should warn developers to exercise caution before downloading and executing the code, according to Gelb, who argued that the recent XZ attack should be enough evidence to show relying on reputation is not enough for meaningful supply chain security.

“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”, Gelb wrote.

“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.”