How ChocoPoC Malware Targets Researchers with Trojanized PoC Exploits

ChocoPoC: How Attackers Are Weaponizing Open Source Against Security Researchers

It's a frustrating irony: we, as security researchers, spend our days dissecting vulnerabilities and building exploits to understand and defend against threats. We often lean on the open-source community for Proof-of-Concept (PoC) code, a shared resource that helps us move faster. But what happens when that shared resource becomes the attack vector itself? That's the core problem with ChocoPoC malware.

This isn't some complex, never-before-seen zero-day. It's a supply chain attack that preys on our implicit trust in open-source repositories and package managers. And it's effective because it targets the very people who should know better – us. This sophisticated approach highlights a critical vulnerability in the software supply chain, making it imperative for researchers to understand and mitigate the risks posed by ChocoPoC malware.

The Incident: A Trojan Horse in Your Exploit Kit

Sekoia researchers recently pulled back the curtain on ChocoPoC, a Python-based Remote Access Trojan (RAT) specifically designed to target cybersecurity researchers. The delivery mechanism is what makes it insidious: weaponized PoC exploits hosted on GitHub.

Here's the thing: the malware isn't directly embedded in the exploit file itself. That would be too obvious. Instead, the attackers inject malicious Python packages into the PoC's dependency list, then host those packages on the Python Package Index (PyPI). When you clone a seemingly legitimate PoC repository and try to run it, those trojanized packages get automatically fetched and installed. It's a clever move, leveraging the automated nature of dependency management.

Sekoia identified at least seven GitHub repositories distributing ChocoPoC, targeting a range of vulnerabilities from FortiWeb (CVE-2025-64446) to PAN-OS (CVE-2026-0257) and Ivanti Sentry (CVE-2026-10520). The 'skytext' package alone has seen around 2,400 downloads, mostly on Linux systems, with spikes following popular vulnerability disclosures. That tells you the attackers are paying attention to what we're looking for, constantly adapting their ChocoPoC malware distribution tactics.

The Mechanism: A Dependency Chain of Compromise

Let's walk through the attack chain, because understanding the steps is key to defending against them.

1. The Lure: An attacker creates a GitHub repository with a PoC exploit for a recently disclosed or high-profile vulnerability. They make it look legitimate, maybe even fork it from a known good source.
2. The Trap: The requirements.txt or setup.py file in that PoC repository lists a malicious Python package, like 'frint' (or 'slogsec' and 'logcrypt.cryptography' in earlier campaigns).
3. The Download: You, the researcher, clone the repository. When you try to install dependencies (e.g., pip install -r requirements.txt), 'frint' gets pulled from PyPI.
4. The Payload Stage 1: 'frint' then pulls its own malicious dependency, 'skytext'. This 'skytext' package is the real workhorse here; it contains a compiled native Python extension.
5. The Execution: When you run the PoC exploit, the 'skytext' extension runs automatically. It decrypts embedded Python code, which then acts as a downloader.
6. The Final Payload: This downloader retrieves the full ChocoPoC RAT payload from a Mapbox dataset. Yes, Mapbox. Attackers are getting creative with their C2 infrastructure, using legitimate services to blend in.
7. The RAT is Live: ChocoPoC is now running on your system.

About a bad PoC is about a compromised software supply chain. The attackers are using PyPI, a trusted source for Python packages, to distribute their malware. They're exploiting the trust we place in package managers and the convenience of pip install. This makes ChocoPoC malware particularly dangerous, as it subverts established trust mechanisms.

The Impact: What ChocoPoC Malware Steals and Why It Matters

Once ChocoPoC is on a system, it's a full-featured RAT. It can:

• Execute arbitrary shell commands and Python code.
• Upload files and directories.
• Collect browser passwords, cookies, autofill data, and browsing history.
• Search for text files, markdown documentation, and database files.
• Gather shell history.
• Collect network configuration and enumerate running processes.

Think about that for a second. If you're a security researcher, what's on your machine? Exploit code, client data, internal network diagrams, VPN credentials, shell history full of sensitive commands, maybe even unpatched zero-days you're working on. All of that is fair game for ChocoPoC malware. The data exfiltration happens via Mapbox datasets or an HTTP server for larger files.

Discussions on platforms like Reddit's r/pwnhub reflect this shared awareness. People are talking about the Python-based RAT nature, the trojanized dependencies, and the targeting of Linux systems. The sentiment is a clear call for caution among vulnerability testers and security researchers, emphasizing the risks associated with open-source code repositories. It's a stark reminder that our tools can be turned against us, especially when facing sophisticated threats like ChocoPoC malware.

The Response: Rebuilding Trust and Hardening Our Habits

The mainstream narrative, as seen in outlets like Bleeping Computer, rightly warns researchers to be extremely cautious. But "extreme caution" needs to translate into concrete actions.

First, verify your sources. Don't just clone the first PoC you see on GitHub. Check the repository's age, the committer's history, and any associated issues or pull requests. Look for red flags like newly created accounts or a lack of activity beyond the PoC itself. The attribution for ChocoPoC points to attackers using compromised accounts to publish these malicious packages and PoCs, with some credentials appearing in leak databases. This means a seemingly legitimate account might not be, making vigilance against ChocoPoC malware crucial.

Second, isolate your work. Running PoCs in a dedicated virtual machine or container environment is non-negotiable. If the PoC is malicious, you want it contained. This limits the blast radius to that isolated environment, preventing it from reaching your host system, your browser data, or your other sensitive files.

Third, review dependencies. Before you run pip install -r requirements.txt, actually read the requirements.txt file. Look up any unfamiliar packages on PyPI. Check their download counts, their release history, and their maintainers. Does 'frint' sound like a legitimate dependency for a FortiWeb exploit? Probably not.

Finally, for the broader open-source ecosystem, this highlights the ongoing challenge of supply chain security. PyPI, like other package managers, needs solid mechanisms to detect and remove malicious packages quickly. But we can't rely solely on them. We, the users, have to be the last line of defense against threats like ChocoPoC malware.

This isn't a problem that's going away. Attackers will continue to find ways to exploit trust. Our job is to make that exploitation harder, starting with our own habits. The convenience of open-source PoCs is immense, but it comes with a responsibility to scrutinize what we're bringing into our environments, especially in the face of evolving ChocoPoC malware tactics.