ChocoPoC Malware Targets Researchers Through Trojanized PoC Exploits
What happened
Multiple weaponized proof-of-concept exploit repositories on GitHub were found delivering a Python-based remote access trojan named ChocoPoC. The campaign appears designed to target cybersecurity researchers, vulnerability testers, penetration testers, and others who download and run exploit code from public repositories.
ChocoPoC stands out because the malware is not embedded directly inside the exploit file. Instead, the attackers add malicious Python packages to the proof-of-concept repository’s dependency list. When a victim clones one of the malicious repositories, a trojanized package named frint is automatically fetched and installed. During installation, frint pulls another malicious dependency named skytext, which contains a compiled native Python extension.
When the proof-of-concept exploit runs, the extension executes automatically and decrypts additional embedded Python code. That code triggers a downloader that retrieves the final ChocoPoC payload from a Mapbox dataset.
The ChocoPoC remote access trojan can execute arbitrary shell commands and Python code, upload files and directories, collect browser passwords, cookies, autofill data, and browsing history, search for text, markdown, and database files, gather shell history, collect network configuration, and enumerate running processes. Mapbox datasets are also abused for data exfiltration, though larger file uploads are handled separately through an HTTP server.
Sekoia identified at least seven GitHub proof-of-concept repositories distributing ChocoPoC. The repositories hosted exploits for FortiWeb, React2Shell, MongoBleed, PAN-OS, Ivanti Sentry, Check Point VPN, and Joomla SP Page Builder vulnerabilities.
The malicious skytext package was downloaded 2,400 times, mostly on Linux-based systems. Downloads increased after the disclosure of a popular vulnerability, suggesting the attackers used trending security issues to lure researchers into testing malicious PoC repositories.
Before using frint and skytext, the campaign used two other packages, slogsec and logcrypt.cryptography, with similar source code and the same ChocoPoC payload. Sekoia said the campaign appears to rely on compromised accounts to publish malicious PyPI packages and proof-of-concept repositories. Researchers found email addresses tied to GitHub committers linked to earlier PoC trojanizing activity, with some credentials appearing in leak databases and one login likely originating from an infostealer compromise.
Who is affected
Cybersecurity researchers, penetration testers, vulnerability analysts, red teams, and low-skilled hackers who downloaded and ran the malicious proof-of-concept repositories may be affected.
The risk is especially relevant to Linux-based systems, which accounted for most skytext downloads.
Organizations may also be affected if researchers tested the malicious PoCs on workstations containing browser credentials, shell history, API keys, internal documentation, databases, source code, or access to security tooling.
Security teams should pay attention if staff downloaded PoCs for FortiWeb, React2Shell, MongoBleed, PAN-OS, Ivanti Sentry, Check Point VPN, or Joomla SP Page Builder vulnerabilities from untrusted GitHub repositories.
Why CISOs should care
This campaign highlights a persistent risk in security research workflows: defenders often run untrusted exploit code while investigating new vulnerabilities. Attackers can exploit that habit by publishing trojanized proof-of-concepts around trending vulnerabilities.
For CISOs, the dependency-based delivery method is especially important. The exploit code itself may appear clean, while the malicious behavior lives in a package dependency that looks harmless during review. That makes manual inspection harder if teams only examine the main PoC file.
The targeting of researchers also creates enterprise risk. Security teams often use privileged workstations, browser sessions, internal tools, VPN access, and vulnerability management systems. A compromised researcher machine can expose credentials, internal notes, exploit testing environments, and access paths into the organization.
The use of compromised accounts to publish malicious packages and repositories also reinforces that reputation alone is not enough. A GitHub or PyPI account may look legitimate while being controlled by an attacker.
3 practical actions
Run proof-of-concepts only in isolated environments: Researchers should execute unverified exploit code in disposable virtual machines, containers, or lab systems without access to production credentials, browser sessions, SSH keys, or internal repositories.
Review dependencies, not only exploit files: ChocoPoC was delivered through malicious Python packages added to PoC dependency lists. Security teams should inspect requirements files, package installation scripts, native extensions, dependency chains, and network activity before running public exploit code.
Monitor researcher workstations for unusual behavior: ChocoPoC can execute commands, steal browser data, collect shell history, and upload files. Defenders should watch for suspicious Python package installs, unexpected Mapbox dataset access, outbound HTTP uploads, unusual shell activity, and credential access from research systems.
Also on the news today:
CISO HQ is right that ChocoPoC turns the researcher's own toolchain against them, trojanized GitHub PoCs and poisoned PyPI dependencies land because the target trusts the source, not despite it. My piece agrees and pushes the same logic up a level. The single point of failure is rarely your own hygiene, it is the security provider, the exploit repo, the package you pulled in good faith because it wore the right badge. Once you concede that trusted supply is the attack surface, screening researchers who download PoCs stops being an edge case and becomes the model for how any defender should treat every vendor and every dependency they run.
https://cyrilsimonnet.substack.com/p/your-security-provider-is-a-bigger