GitHub Supply Chain Attack Uses Octopus Scanner Malware

On March 9, the GitHub Security Incident Response Team (SIRT) received a message from security researcher JJ, who had discovered a set of GitHub repositories actively serving malware. A deep-dive analysis of the malware revealed it was built to compromise NetBeans projects, something they hadn't seen before on GitHub. All affected projects were actively serving backdoored code, and the owners of these repositories were completely unaware of it.

Nico Waisman, head of GitHub Security Lab, says the first step in their investigation was to identify whether the campaign was still active. Once the critical assessment was complete and they learned the command-and-control (C2) server was not active, they were able to reduce the risk level and take a closer look at Octopus Scanner, an open source supply chain malware.

"The unique feature around this malware is that it is targeting developers as the means of spreading," Waisman explains. "Once the computer gets infected, it looks for NetBeans files to infect." While GitHub users, as developers, should be concerned about this malware using developers for propagation, Waisman notes this particular technique is "extremely rare."

When Octopus Scanner lands on a machine, it looks for signs indicating the NetBeans IDE is in use on a developer's system, GitHub security researcher Alvaro Muñoz explains in a blog post on their findings. If it doesn't find anything, the malware takes no action. If it does, it ensures that every time a project is built, any resulting JAR files are infected with a dropper. When executed, the payload ensures persistence and spreads a remote access Trojan (RAT), which connects to C2 servers.

The malware continues to spread by infecting NetBeans projects, or JAR files. This way, it backdoors healthy projects so when developers release code to the public, it contains malware. The goal of Octopus Scanner is to insert backdoors into artifacts built by NetBeans so the attacker can use these resources as part of the C2 server, Waisman says.

"When the end user deploys the workload, they have given the attacker access via the backdoor to their resources for use as part of a command-and-control server," he adds.

Octopus Scanner also tries to prevent any new project builds from replacing the infected one. This ensures the malicious build components remain in place. While researching the infected repositories, GitHub found four different versions of affected NetBeans projects. All but one of them, a downstream system, would get infected either by building from an infected repository or by using any of the compromised artifacts that came from an infected build, Muñoz wrote. 

"Infecting build artifacts is a means to infect more hosts since the infected project will most likely get built by other systems and the build artifacts will probably be loaded and executed on other systems as well," he explains in the blog post.

It is interesting the attackers specifically chose to target the NetBeans build process, especially because it's not the most common Java IDE. This could indicate a targeted attack, Muñoz says, or they may have already implemented the malware for build systems like Make, MsBuild, or Gradle, and it could be spreading unnoticed.

Supply Chain Threats: What You Should Know
Developers and companies are growing more reliant on open source code, Waisman says. Open source is easy for developers, meaning it's also easy for adversaries. Attackers are pursuing supply chain compromises because they can have widespread reach: a single attack can give them access to multiple targets. And as Muñoz points out, malware that abuses the build process and its resulting artifacts is "both interesting and concerning" for several reasons. 

In an open source context, this gives the malware an effective means of spreading. The infected projects will likely be cloned and used on different systems, and the artifacts of the builds may spread even further, making it harder to track down.

Because the primary users of these repositories are developers, a successful intrusion could give attackers access to the same resources that developers use. These may include additional passwords, production environments, database passwords, and other sensitive assets, he adds.

While supply chain compromises like this are scary, Waisman says they remain rare.

"The primary issue in supply chain security is unpatched software," he explains. "It's much easier for an attacker to take advantage of an unpatched, known vulnerability in a dependency than to insert a new vulnerability into your code."

For developers, the challenge is knowing their dependencies and knowing when they need to be patched. GitHub aims to help with this through Dependency Graph, which helps users better understand their projects' dependencies and provides security alerts when a dependency has a vulnerability, he says. For open source maintainers, the challenge is in preventing issues and responding when necessary. On GitHub, maintainers can create a security.md file with their reporting and disclosure policy, create fixes when needed, and publish security advisories. 

"Ultimately, this is about surfacing, coordinating, and sharing information between multiple parties, including developers, open source maintainers, security researchers, and enterprises," Waisman says.

Related Content:

Learn from industry experts in a setting that is conducive to interaction and conversation about how to prepare for that "really  bad day" in cybersecurity. Click for more information and to register.