Attackers are again weaponizing the urgency around newly disclosed vulnerabilities, this time with fake Python proof-of-concept repositories that deliver a remote access trojan known as ChocoPoC. The campaign matters because it is aimed directly at the people most likely to test public exploit code: vulnerability researchers, red teams, bug bounty hunters, and security engineers building detections.
According to reporting based on joint findings from YesWeHack and Sekoia, the malicious repositories appear to offer exploit code for high-profile CVEs. The visible PoC may look ordinary at a quick glance, but the danger sits deeper in the dependency chain. That dependency-level lure makes quick PoC reviews dangerously incomplete.
How the ChocoPoC infection chain works
The lure starts with a familiar workflow: a researcher clones a repository, installs requirements, and runs a PoC in a lab environment. In this campaign, that install path can pull in a Python package named frint, which then brings in another package named skytext.
The second package is where the real payload behavior begins. It includes a compiled component named gradient.so on Linux or gradient.pyd on Windows. Rather than immediately revealing itself in a simple package-only sandbox test, the component checks for signs that it is being executed alongside the expected exploit project, including PoC-style filenames such as EXPLOIT_POC.py. If the right context is present, it unpacks additional logic and downloads the trojan.
That design is important. Many researchers know not to trust random exploit code, but they often focus review time on the main script. ChocoPoC abuses the gap between “the PoC file looks clean” and “every transitive dependency has been validated.” It is a supply-chain technique applied to exploit research habits.
What the malware can steal
Once active, ChocoPoC behaves like a full remote access trojan and infostealer. The reported capabilities include theft of browser data such as saved passwords, cookies, autofill records, and browsing history from major browsers including Chrome, Brave, Edge, and Firefox. It also targets local files, notes, databases, shell history, network configuration, and process information.
The operator can reportedly execute shell commands, run Python code, collect folders, and adjust behavior to reduce noise. The malware uses command-and-control techniques meant to blend into normal traffic, including the use of a legitimate mapping service as a dead-drop mechanism and DNS-over-HTTPS for resolution. Large data transfers were associated with a separate server, which makes network monitoring more complex than simply blocking one obvious malware domain.
For defenders, the takeaway is that this is not just a “malicious script” problem. A compromised research workstation can expose client data, private vulnerability notes, VPN material, SSH keys, cloud credentials, bug bounty accounts, and early-stage exploit intelligence.
Why vulnerability researchers are attractive targets
Security researchers often run untrusted code by necessity. They may also work inside privileged environments, maintain access to test infrastructure, and store artifacts that are valuable to criminals or state-aligned groups. That combination creates a high-value target: compromise one researcher and the attacker may gain access to multiple downstream organizations, private reports, and tooling pipelines.
Fake exploit repositories are not new. Previous campaigns have used malicious Visual Studio projects, trojanized PoCs, and social engineering against researchers. ChocoPoC stands out because the main exploit repository can appear less suspicious while the dependency chain carries the malicious logic. This lowers the chance that a rushed manual review catches the problem.
The same pattern also creates a broader supply-chain concern. Researchers often contribute templates, detections, scripts, and exploit modules to tools used by many others. If an attacker compromises a trusted contributor, malicious code or stolen credentials can ripple into frameworks and communities far beyond the first infected machine.
Practical steps for researchers and teams
Treat public exploit code as hostile until proven otherwise, especially when it appears immediately after a major CVE disclosure or comes from a new account with limited history. Do not rely on repository popularity, a polished README, or a clean main script as proof of safety.
Before running a PoC, review the full dependency tree. Look for newly published packages, unusual maintainers, compiled extensions, post-install behavior, and dependency names that do not match the project’s stated purpose. Pin and inspect packages before installation rather than allowing a fresh environment to resolve arbitrary latest versions.
Run exploit testing in disposable virtual machines with no browser profile, no password manager session, no SSH agent forwarding, no cloud tokens, and no mounted work directories containing client data. Isolation is still necessary, but ChocoPoC shows that isolation by itself is not enough if the environment contains real secrets.
Organizations should also separate research activity from production administration. A researcher testing PoCs should not do so from the same workstation used to manage cloud consoles, customer environments, or internal source repositories. Use dedicated accounts, short-lived credentials, and network egress controls for malware-analysis and exploit-validation labs.
Detection and response guidance
Teams should check whether systems used for PoC testing installed or executed packages named frint, skytext, slogsec, or logcrypt.cryptography. The latter two names were linked to an earlier related campaign in the public reporting. Review package manager logs, shell history, virtual environment directories, and endpoint telemetry for those package names and for compiled modules such as gradient.so or gradient.pyd.
If any of these packages were run on a machine containing real credentials, assume compromise. Rotate browser-stored passwords, SSH keys, API tokens, cloud credentials, VPN certificates, and any secrets available to the user account. Rebuilding the host is safer than trying to surgically remove a RAT, especially when the malware may have executed arbitrary commands.
Network defenders can look for unusual traffic to mapping-service APIs from research sandboxes, DNS-over-HTTPS usage from machines that do not normally use it, and unexpected outbound transfers after PoC execution. These signals are not conclusive on their own, but they can help prioritize investigation when combined with package installation evidence.
Bottom line
The ChocoPoC campaign is a reminder that exploit code is part of the software supply chain. For researchers, the safest workflow is to assume that every PoC, dependency, and build step may be adversarial until inspected in a sterile environment. Fast validation is useful, but attackers are counting on speed to outrun scrutiny.
Source: The Hacker News source