redcap-payloads — Offensive payload library

redcap-payloads — Offensive payload library

Wraps a local clone of swisskyrepo/PayloadsAllTheThings with navigation and retrieval workflows. The corpus is ~140 topic folders covering every major web application vulnerability class, each with a README and wordlist files suitable for Burp Intruder or custom fuzzers.

Prerequisites

The skill expects the fork cloned to:

~/Documents/GitHub/PayloadsAllTheThings

If the path is missing, prompt the user to clone:

cd ~/Documents/GitHub && gh repo clone GITDIDDY69/PayloadsAllTheThings
# or upstream:
# gh repo clone swisskyrepo/PayloadsAllTheThings

Structure of the corpus

PayloadsAllTheThings/
├── SQL Injection/
│   ├── README.md                    ← vulnerability overview + payload index
│   ├── MySQL Injection.md           ← DBMS-specific payloads
│   ├── MSSQL Injection.md
│   ├── PostgreSQL Injection.md
│   ├── OracleSQL Injection.md
│   ├── Intruder/                    ← Burp Intruder wordlists (.txt)
│   │   ├── Generic_TimeBased.txt
│   │   └── FUZZDB_MySQL-WHERE_Time.txt
│   └── Files/                       ← supplementary files
├── Cross-Site Scripting/
├── Server Side Template Injection/
├── Command Injection/
├── XXE Injection/
├── Insecure Deserialization/
├── Authentication/
├── CSRF Injection/
├── Upload Insecure Files/
├── Server Side Request Forgery/
├── LDAP Injection/
├── ... (~140 topics total)
└── Methodology and Resources/

Workflow

Step 1: Identify the vulnerability class from user intent

Map the user's request to a topic folder. Common mappings:

User intent	Topic folder
"SQLi / SQL injection"	SQL Injection
"XSS / cross-site scripting"	Cross-Site Scripting
"SSTI / template injection"	Server Side Template Injection
"XXE / XML injection"	XXE Injection
"command injection / RCE via shell"	Command Injection
"SSRF / request forgery"	Server Side Request Forgery
"auth bypass / login bypass"	Authentication
"CSRF / request forgery"	CSRF Injection
"insecure deserialization / gadget"	Insecure Deserialization
"file upload / unrestricted upload"	Upload Insecure Files
"LDAP injection / directory lookup bypass"	LDAP Injection
"open redirect"	Open Redirect
"race condition"	Race Condition
"prototype pollution"	Prototype Pollution

When the class is unclear, list the top-level directories so the user can choose:

ls ~/Documents/GitHub/PayloadsAllTheThings | grep -v '^_' | grep -v Images | grep -v Files

Step 2: Read the topic README

cat ~/Documents/GitHub/PayloadsAllTheThings/<topic>/README.md

Each README has:

• Vulnerability definition and attack model
• Detection techniques
• Payload index with TOC links
• Exploitation examples inline
• Known tools and reference reading

Step 3: Drill into specific payload files

For injection classes with DBMS / language variants, read the specific file:

cat "~/Documents/GitHub/PayloadsAllTheThings/SQL Injection/MSSQL Injection.md"

For XSS specifically, check the CSP-bypass file when the target uses CSP:

cat "~/Documents/GitHub/PayloadsAllTheThings/Cross-Site Scripting/README.md"

Step 4: Grab Intruder wordlists for fuzzing

ls "~/Documents/GitHub/PayloadsAllTheThings/<topic>/Intruder/"
head -50 "~/Documents/GitHub/PayloadsAllTheThings/<topic>/Intruder/<wordlist>.txt"

Copy the wordlist into Burp Intruder or pipe into a custom fuzzer. The wordlist paths are stable across upstream updates — safe to reference by path.

Step 5: Produce the answer

Return one or more of:

• Inline payload — quote the specific payload string(s) with context (what they exploit, what to replace with real values, how to URL-encode if relevant)
• Detection technique — summary from the README's detection section
• Attack chain — sequence of payloads for multi-step exploitation
• Wordlist reference — path + 5-10 sample lines from the relevant Intruder file
• Defense note — if the user seems to be asking from a defender perspective, include the remediation guidance from the README

Safety and authorization

• Only use against targets the user owns or has explicit written authorization to test.
• If authorization is unclear, ASK before producing payloads for what looks like a third-party production system.
• Payloads are raw — they can cause data corruption, data exfiltration, or service disruption if mis-aimed.
• Time-based payloads (especially SLEEP(N) style) can trip monitoring systems and page on-call engineers. Use SLEEP(2) for validation, not SLEEP(30).

Pairing with other siblings

• With redcap-droid: decompile an app, find its backend URL + framework, look up payloads specific to that framework (e.g., Retrofit + Spring → Java & Spring payloads).
• With redcap-gpt: feed found payloads into the autonomous agent as suggested probes.
• With redcap-kernel: compare payload patterns against compile-time input validation in firmware — payloads that bypass server-side validation often expose partial validation bugs in the validation code itself.
• With redcap-compliance: cross-reference each payload's vulnerability class against baselines — CIS / STIG / PCI-DSS rules that WOULD have blocked the payload if enabled.