ChocoPoc RAT Hidden in Trojanized GitHub PoC Exploit Repos

Threat actors have seeded GitHub with weaponized proof-of-concept exploit repositories that silently install a Python-based remote access trojan called ChocoPoc, according to BleepingComputer. The RAT is capable of executing arbitrary commands on the victim's machine and exfiltrating sensitive data — and it arrives wrapped in code that looks exactly like the kind of security research material professionals clone without a second thought.

What Happened

Attackers published multiple GitHub repositories disguised as legitimate PoC exploits — the kind security researchers, pentesters, and developers routinely grab to reproduce a CVE, test a patch, or study attack technique. Hidden inside the Python code is ChocoPoc, a RAT that establishes attacker-controlled command execution and begins stealing sensitive data from the compromised host. The repositories are designed to blend in: realistic READMEs, CVE references, and the visual scaffolding of credible vulnerability research.

This is a supply-chain-adjacent attack that targets the moment of trust most technical people extend automatically — when they git clone something that looks like it came from the security community.

Why It Matters

The attack surface here is wide. Security researchers, red teamers, and developers all have workflows that involve cloning unfamiliar code from GitHub with minimal vetting. PoC repositories are especially dangerous bait because they're expected to contain aggressive, low-level code — so unusual Python invocations or subprocess calls don't immediately raise flags.

A RAT with command execution and data exfiltration is not a nuisance-tier payload. From a compromised workstation it can:

• Harvest stored credentials, SSH keys, and API tokens
• Pivot laterally into internal networks or cloud environments
• Exfiltrate source code, configuration files, or secrets from .env files
• Establish persistence for long-term access

If you work in an environment where you clone PoCs to a machine that also has production credentials, VPN access, or AWS/GCP/Azure CLI profiles configured, the blast radius is significant.

What to Do Now

Immediate triage:

1. Audit recently cloned repos. Review your local ~/ and any project directories for Python PoC repositories cloned in the past several weeks from unverified accounts. Pay close attention to repos discovered via GitHub search, Reddit, or vulnerability disclosure threads rather than from known, established researchers.

1. Hunt for active RAT processes. Check running Python processes (ps aux | grep python) and review outbound network connections (ss -tnp or netstat -tnp) for unexpected connections to external IPs — especially on non-standard ports.

1. Check persistence mechanisms. On Linux, inspect crontabs (crontab -l, /etc/cron*), systemd user services (~/.config/systemd/user/), and shell init files (.bashrc, .zshrc, .profile) for entries you didn't add.

1. Rotate credentials if exposure is plausible. If a suspicious repo was executed on a machine with access to cloud credentials, SSH keys, or API tokens, rotate those immediately. Check cloud provider audit logs for unexpected API calls.

Going forward:

• Run unfamiliar PoC code exclusively in disposable VMs or containers with no credential access and no network route to internal systems.
• Verify the account publishing a PoC has a credible history — look at their commit history, follower count, and whether the repo appeared suspiciously close to a CVE disclosure.
• Treat any repo that immediately asks you to pip install from a requirements.txt or run a setup script as elevated risk until reviewed line by line.