Attackers Create Synthetic Security Researchers to Steal IP

During the month of May, an unknown threat group created a malicious GitHub repository that claimed to contain a zero-day exploit for a vulnerability in the Signal messaging app. The attackers supported the credibility of the exploit by creating a fake security company — High Sierra Cyber Security — linked to a number of made-up profiles of security researchers.

That’s according to research conducted by threat intelligence firm VulnCheck, which found that the level of effort that the attacker put into create a social presence around the fake security company and the fake exploits is on a whole other level compared to what researchers have seen in the past.

“They put in a decent amount of effort into building personas, if you will, for each of these characters — these actors that who would advertise the GitHub repositories with the actual malware,” VulnCheck security researcher William Vu tells Dark Reading. “So they put a lot of time and effort into building, really, a fake security company, and that, to me, is kind of new.”

Targeting security researchers is rare, but has a long history. In 2021, for example, Google’s Threat Analysis Group (TAG) warned that North Korea-backed hackers had created a faux research blog and multiple fake Twitter profiles. Researchers would then be asked to collaborate on vulnerability research, and those who agreed would be sent a Visual Studio project file that would run custom malware to infect the target’s system, according to Google TAG’s analysis. Three months later, the Cybersecurity and Infrastructure Security Agency (CISA) issued an alert about the campaign.

A similar attack — also by North Korea — targeted security researchers by using LinkedIn accounts and acting as recruiters, according to research released in March by Mandiant.

The latest attack also uses social engineering to target the supply chain, says Mike Parkin, a senior technical engineer at Vulcan Cyber, a provider of enterprise cyber-risk remediation services.

“One of the core defenses against malicious packages is for developers to actually vet the package before they download and use it, and part of that vetting process is determining if the package was created by a trustworthy source, whether commercial or otherwise,” he says. “If threat actors can do a good job of faking that, they have a better chance of getting a victim to download their package and then not give it as close of an inspection as they should.”

GitHub, WhatsApp, What’s Next?

VulnCheck contacted GitHub about the project hosting the fake exploit, and the page was taken down. A day later, however, the same group created a similar page advertising a WhatsApp zero-day exploit, VulnCheck’s researchers stated in the advisory. That pattern continued, and each time the company notified GitHub of a new page, it was removed but a new project page would appear. Pages offering a purported Microsoft Exchange remote code execution (RCE) bug, a Discord zero-day RCE, and others continued the cat-and-mouse game, the company stated.

In each case, instead of an exploit, a Python file in the repository would — if run by the target — download an operating-system-specific binary. While most antivirus programs detected the Windows malware that the Python script loaded, only three of the 62 Linux host-based scanners detected that binary, VulnCheck stated.

The threat actor used a variety of social media profiles to push out links to the pages. While the technique has been used as a way to convince software developers to download vulnerable or malicious components as a way of infecting the supply chain, this attack seems more likely to gain access to security professionals’ own research, Vu says.

“Security researchers and testers usually have their own research, and if I were going after security researchers this way, I would be looking to obtain their cache of real zero-day exploits, and any kind of corporate IP that they might have access to,” he says.

Not the Sharpest Tool in the Toolbox

While companies should always educate their developers about the risks that come with online code and how to best vet projects and unknown developers to determine if they are legitimate, researchers need to learn to be wary too, says Erich Kron, security awareness advocate at KnowBe4.

“Running code that others have written, especially when available in free and open websites such as GitHub, always carries some risk,” he said. “In this case, researchers looking at the code may even assume that the malicious parts are simply a piece of these zero days being disclosed, when in fact it’s designed to infect their own systems.”

For most security researchers, a little due diligence will go a long way. A little research would likely discover that the company behind the “security research” has no track record, and that the researchers have no history in the industry, says Vulcan Cyber’s Parkin.

“If a package just appeared out of nowhere, and the developers all seem to be new on the scene? Red flags,” he says. “The sad thing is that this will have some negative impact on newly active researchers who may not have any history yet, but it’s also easy to tell the difference between someone who doesn’t have a history because they’re just getting started and someone who has no history because they don’t exist.”