poc-weaponization

When to use

• You have a public PoC (from cve-search, GitHub, Exploit-DB, Sploitus, etc.).
• The PoC lacks reliability, targets wrong offsets, or was written for Python 2.
• You must verify the PoC is not backdoored before running it against a target.

The Weaponization Workflow

1. Safety Audit (Isolated Environment)

Before executing any public exploit script:

• Record provenance first: exact source URL, repository revision or release, file path, cryptographic hash of the reviewed artifact, and the claimed affected product/version. Preserve this record with the review so later edits or mirrors are not mistaken for the inspected PoC.
• Run in an isolated environment first (container or VM with no credentials mounted). A clean-looking PoC may still exfiltrate environment variables or SSH keys at runtime.
• Check requirements.txt, setup.py, install.sh, and any package manifest for typosquatted or malicious dependencies and build hooks that execute at install time.
• Look for obfuscation: Base64 blocks, eval(), exec(), reversed strings.
• Look for callbacks: network connections to third-party hosts outside the intended target (DNS exfiltration, analytics beacons, hardcoded C2).
• Check for destructive side-effects: hardcoded rm -rf, DROP TABLE, unnecessary persistence.
• Load references/backdoor-patterns.md for the full pattern list.