Methodology

# === PHASES (PTES — Penetration Testing Execution Standard) ===

# 1. Pre-engagement
#    - Scope: in-scope IPs / domains / apps, out-of-scope
#    - Authorisation: signed by C-level, legal review
#    - Rules of engagement: test windows, allowed techniques, escalation path
#    - Reporting cadence: critical → immediate, others → end of engagement
#    - Goals: compliance? full breach simulation? specific app focus?
#    - Communication: emergency contacts, status updates

# 2. Intelligence gathering (passive recon)
#    - OSINT: Whois, DNS, certificate transparency, Wayback Machine, GitHub orgs
#    - Employee info: LinkedIn, breach dumps (HIBP / DeHashed with auth)
#    - Tech stack: BuiltWith / Wappalyzer / Shodan / Censys
#    - Job postings → tech indicators

# 3. Threat modelling
#    - Identify high-value targets (customer data, payment, IP, admin paths)
#    - Likely attacker types: external opportunist, motivated APT, insider
#    - Attack scenarios: business email compromise, web app compromise, supply chain

# 4. Vulnerability analysis (active recon + enumeration)
#    - Network: nmap, masscan, naabu — what's listening?
#    - Web:    httpx, gobuster, ffuf, nuclei — what's exposed?
#    - Service version checks against known CVEs
#    - Default creds, misconfigurations
#    - Cloud: scoutsuite, prowler, cs-discover

# 5. Exploitation
#    - Attempt to gain initial access (within scope + ROE)
#    - Web: SQLi, XSS, SSRF, IDOR, auth bypass
#    - Network: known service exploits (metasploit modules)
#    - Phishing (if in scope): GoPhish / King Phisher campaign
#    - Document EVERY step for repro

# 6. Post-exploitation (only if access is granted by scope)
#    - Privilege escalation: LinPEAS / WinPEAS / PowerUp
#    - Lateral movement: kerberoasting, pass-the-hash, RDP, SSH chains
#    - Persistence: ONLY in lab/scope-allowed; document for removal
#    - Data identification: where are crown jewels? (don't exfiltrate)
#    - Impact assessment: 'if a real attacker reached here, they could…'

# 7. Reporting
#    - Executive summary: risk to the business, top 3 findings
#    - Technical detail: each finding with severity, evidence, mitigation
#    - Reproduction steps: clear enough for engineering to verify
#    - Strategic recommendations: process / training / architecture fixes
#    - Re-test offer: validate fixes after remediation

# === Sample 2-week engagement timeline ===

# Week 1 — Mon-Wed: Recon + enumeration
#   - Passive recon across all in-scope domains
#   - Subdomain enumeration: amass, subfinder
#   - DNS recon: dnsrecon, fierce
#   - Live host probing: httpx
#   - Tech detection: nuclei -tags tech
#   - Daily standup with client (15 min)

# Week 1 — Thu-Fri: Vulnerability analysis
#   - Web app testing in scope: Burp Suite + manual exploration
#   - Critical finding? Notify immediately, pause if requested
#   - Network port scans (slowly, respecting infrastructure)
#   - Cloud config review (if in scope)

# Week 2 — Mon-Wed: Exploitation + chaining
#   - Confirm vulnerabilities with proof-of-concept
#   - Chain findings: 'IDOR + missing auth → admin takeover'
#   - Test defenses (WAF rules, anomaly detection — what trips, what doesn't?)

# Week 2 — Thu: Report writing
#   - Findings catalogued, screenshotted, severity-rated
#   - Executive summary tailored to business impact

# Week 2 — Fri: Debrief
#   - Live walkthrough of findings
#   - Q&A with eng + security teams
#   - Hand over detailed report + raw evidence

# === Severity scoring ===

# Common scales:
#   - CVSS v3.1     : 0-10 numeric, broadly used; can be misleading for business risk
#   - DREAD          : Damage, Reproducibility, Exploitability, Affected users, Discoverability (1-10 each, average)
#   - Custom 5-tier  : Critical / High / Medium / Low / Info — tied to the org's risk appetite

# Always include BUSINESS context, not just CVSS:
#   - CVSS 7.5 on a non-internet-facing internal service: maybe Medium
#   - CVSS 6.0 on the main payment endpoint with leaked tokens: definitely Critical

# === Reporting template per finding ===

# Finding ID: F-001
# Title: Authenticated SQL Injection in /api/orders
# Severity: Critical (CVSS 9.8)
# Affected: https://api.example.com/v1/orders (GET id parameter)
# Description:
#   The 'id' query parameter is concatenated into a SQL query without parameterisation.
#   An authenticated attacker can extract arbitrary database contents.
# Reproduction:
#   1. Authenticate as a low-privilege user.
#   2. GET /api/orders?id=1' AND CAST((SELECT current_database()) AS int)-- 
#   3. The error message in the response leaks the database name.
#   4. [HTTP request / response screenshots]
# Impact:
#   - Full extraction of orders table (customer PII, payment references)
#   - Likely extraction of users table (password hashes if stored there)
#   - Likely RCE via UDF on certain configs
# Recommendation:
#   1. Parameterise the query: 'SELECT * FROM orders WHERE id = $1', [id]
#   2. Restrict the app DB user to SELECT/INSERT/UPDATE on application tables only
#   3. Disable verbose error messages in production
#   4. Deploy a WAF rule as a temporary mitigation while the code is fixed
# References:
#   - OWASP: A03:2021 — Injection
#   - CWE-89: Improper Neutralization of Special Elements in SQL
# Evidence: see attached burp-history-2026-06-08-1432.json

# === Common methodology frameworks ===

# PTES        — Penetration Testing Execution Standard (most common ref for general pen-tests)
# OSSTMM      — Open Source Security Testing Methodology Manual (formal, audit-friendly)
# NIST SP 800-115 — Technical Guide to Information Security Testing (US federal)
# OWASP WSTG  — Web Security Testing Guide (web-app focused, deeply detailed)
# MITRE ATT&CK — TTPs reference; useful for adversary emulation
# Cyber Kill Chain (Lockheed Martin) — high-level intrusion model

# === Specialisations ===

# Web application pen-test         : OWASP WSTG + Burp Suite + manual exploration
# Mobile app                        : OWASP MASTG / MASVS, Frida, Objection
# API                               : OWASP API Security Top 10 + Burp + Postman
# Cloud                             : Provider Well-Architected + Prowler / ScoutSuite
# Internal network                  : Nmap + impacket + responder + bloodhound
# Active Directory                  : impacket + bloodhound + crackmapexec + certipy
# Wireless                          : aircrack-ng + bettercap (in your own lab only)
# Physical / social engineering     : SE-toolkit, GoPhish — high authorisation required
# Red team / adversary emulation    : MITRE ATT&CK + C2 framework (Cobalt Strike, Sliver, etc.)

# === Ethical reminders ===

#   ✅ Always work with signed authorisation specifying scope + dates
#   ✅ Stay within scope — don't 'just check' an out-of-scope asset
#   ✅ Notify immediately on critical findings (don't wait for the report)
#   ✅ Document every action for repeatability + accountability
#   ✅ Don't exfiltrate real customer data; demonstrate access without copying
#   ✅ Clean up artifacts (test accounts, persistence) before disengaging
#   ✅ Respect privacy + legal boundaries (some jurisdictions criminalise even authorised tests of certain systems)

#   ❌ DON'T attempt DoS without explicit pre-approval
#   ❌ DON'T pivot to other organisations (suppliers, partners) without their explicit consent
#   ❌ DON'T retain customer data after the engagement
#   ❌ DON'T publicly disclose without coordinated disclosure agreement
#   ❌ DON'T use real PII in proof-of-concepts; redact + use sample data

# === Defender's mirror ===

# The same methodology benefits blue teams:
#   - Continuous OSINT monitoring of your own brand
#   - External attack surface management (Detectify, Hadrian, etc.)
#   - Pre-prod scanning (OWASP ZAP, Nuclei) in CI
#   - Internal red team / purple team exercises
#   - Bug bounty for crowd-sourced testing
#   - Tabletop exercises walking through the same phases — what would we see?

# === Books / resources ===
# - 'The Web Application Hacker's Handbook' (Stuttard, Pinto)
# - 'Real-World Bug Hunting' (Yaworski)
# - 'Penetration Testing' (Weidman)
# - PortSwigger Web Security Academy (free, practical labs)
# - HackTheBox, TryHackMe (lab environments)
# - OffSec (OSCP / OSEP / OSWE) certifications

# Standard phases:
#   1) Reconnaissance     — passive then active
#   2) Enumeration        — services, versions, users
#   3) Vulnerability ID   — automated scan + manual review
#   4) Exploitation       — proof-of-concept, in scope only
#   5) Post-exploitation  — privilege, persistence (if authorised)
#   6) Reporting          — clear, reproducible, prioritised