Weeks 12-13. The full PTES engagement lifecycle, conducted against an instructor-built target network, graded on a two-tier rubric against a client-style report and oral debrief.
Capstone overview
The capstone is a five-day simulated penetration engagement against an instructor-built target network of three to five hosts with documented intentional vulnerabilities. Students work individually. The engagement is bounded by the scope document below. The output is a professional-grade written report and a 20-minute oral debrief delivered to the instructor playing two roles: technical peer and non-technical client executive.
The capstone is intentionally modeled on what a junior penetration tester would deliver on their first client engagement. The grading rubric is explicit about this: findings that are real, documented, and explained in client-addressable language score better than findings that are technically correct but buried in tool output.
Authorization and rules of engagement
Authorized targets
The capstone lab network is an isolated RFC 1918 environment with no connection to the production network or the Internet. The instructor provides the following at the start of Day 1:
- The target IP range (e.g.,
192.168.100.0/24) - The DNS hostname(s) of authorized targets
- A mock Statement of Work (SOW) identifying the fictional client ("Meridian Financial Partners") and the authorized scope
No system outside the stated IP range is authorized. If you reach an IP outside the range, stop, document the excursion with a timestamp, and notify the instructor before continuing. Accidental scope excursions handled this way do not result in grade penalty. Continued probing after discovery does.
Prohibited actions
- Denial-of-service or resource-exhaustion attacks
- Persistence mechanisms that survive a VM snapshot reset
- Exfiltration of actual data off the lab network
- Any action against the instructor workstation or the hypervisor management interface
- Any action against systems outside the authorized IP range
Evidence preservation
Every command run during the engagement must be captured in a terminal log. The script utility provides this:
script -a ~/capstone/evidence/day$(date +%d)-session.log
Screenshots at every meaningful step. Timestamps on every finding. Your report must be fully reproducible from your evidence alone.
Five-day engagement timeline
This is a suggested schedule, not a rigid constraint. You may spend more time on phases where you find more. You may not skip phases.
| Day | PTES phase focus | Suggested work |
|---|---|---|
| Day 1 | Pre-engagement + Intelligence Gathering | Review SOW; draft operational plan; passive recon (OSINT against fictional client); begin active recon (port scan, service enum) |
| Day 2 | Intelligence Gathering + Vulnerability Analysis | Complete active recon; web recon if web services present; run scanner (Nessus / Nuclei); begin manual vuln analysis |
| Day 3 | Exploitation | Triage findings; begin exploitation of highest-confidence findings; document evidence per exploit |
| Day 4 | Post-Exploitation | Privilege escalation; lateral movement where in-scope hosts allow; credential capture and reuse |
| Day 5 | Reporting | Stop active testing by end of Day 5 morning; spend afternoon drafting and refining the report |
Required report sections
A report that is missing any of these five sections fails the first gate and is not scored.
1. Executive summary
One to two pages. Audience: a non-technical client executive who decides whether to allocate remediation budget.
Must include:
- Purpose of the engagement (paraphrase the SOW)
- Overall risk posture assessment (High / Medium / Low with a one-sentence rationale)
- The three most significant findings in plain English, no tool names required
- A recommended remediation priority order with estimated urgency
Must not include: raw tool output, IP addresses without hostnames or service context, CVE numbers without plain-English explanation, jargon without definition.
2. Methodology
One page. Audience: a technical auditor who wants to know what was and was not tested.
Must include:
- The PTES phases followed and their timeline
- The tools used (name, version, purpose) in a table
- The scope statement (IP range, authorized actions, prohibited actions)
- What was explicitly out of scope and why
3. Findings
One section per finding. Audience: the technical team responsible for remediation.
Each finding must contain:
- Finding title (short, descriptive, not "SQLi found")
- CVSS v3.1 base score (show the vector string and score derivation)
- Affected host(s) and service(s)
- Description of the vulnerability (what it is, why it exists)
- Evidence: command run, output received, screenshot. All reproducible from your log.
- Business impact (what an attacker gains, in business-consequence terms)
- Remediation guidance (specific, actionable, prioritized)
4. Evidence appendix
All raw evidence referenced in the Findings section: terminal transcripts (excerpted, not dumped in full), screenshots annotated with callouts, captured artifacts (hashes, tokens, files -- lab environment only). Organized by finding number.
5. Remediation roadmap
One to two pages. A prioritized list of all findings with estimated remediation effort (Low / Medium / High) and a suggested sequence. Frame this as advice to the fictional client's CISO: what to fix now, what to fix this quarter, what is longer-term architectural.
Two-tier grading rubric
Tier 1: Binary gates
All five gates must pass before the report is scored. A gate that fails means the capstone is returned unscored for revision (one revision cycle is allowed; the second submission is final).
- ROE respected. No evidence of probing outside the authorized IP range or performing prohibited actions.
- At least one finding exploited end-to-end with proof. The finding must be reproducible from the evidence in the appendix.
- Report contains all five required sections (above).
- Oral debrief delivered in under 25 minutes. Time starts when the student begins presenting.
- Both technical and non-technical stakeholder questions answered substantively. At minimum one question of each type will be asked.
Tier 2: Scored components (100 points total)
| Component | Weight | Scoring criteria |
|---|---|---|
| Technical depth + accuracy | 40 pts | Findings are real (no false positives from scanner output without manual verification). CVSS scores are defensible against base-metric components. Exploitation evidence is reproducible. Remediation guidance is specific, not generic. |
| Report clarity and craft | 30 pts | Executive summary readable by a non-technical decision-maker. Methodology section auditable by a technical reviewer. Evidence appendix well-organized. Document professionally typeset. Spelling and grammar clean. No academic hedging where confidence is appropriate. |
| Engagement discipline + reflection | 30 pts | ROE respected and documented. Scope boundaries acknowledged in the report. OPSEC trade-offs (loud vs. stealthy scans, timing, noise) explained. Oral debrief demonstrates understanding of what the student would do differently and why. |
Scoring rubric details
Technical depth + accuracy (40 pts)
36-40: All findings verified manually before inclusion. CVSS vectors correct and defensible. At least one finding exploited past initial foothold (post-exploitation evidence). Remediation guidance is patch-specific or configuration-specific, not "apply security patches."
28-35: Most findings verified. CVSS mostly correct with minor errors. Exploitation evidence present but shallow (no post-exploitation). Remediation guidance is partially specific.
20-27: Some findings rely on scanner output without manual verification. CVSS errors affect risk ranking. Exploitation evidence incomplete. Remediation guidance generic ("update the software").
Below 20: Findings not verified. CVSS scores missing or obviously incorrect. No end-to-end exploitation demonstrated.
Report clarity and craft (30 pts)
27-30: Executive summary passes the "CISO test" -- could be read aloud in a board meeting without confusion or embarrassment. Finding titles are descriptive. Evidence appendix is navigable. Document looks professional.
21-26: Executive summary understandable but contains some jargon. Finding structure consistent. Minor formatting issues.
15-20: Executive summary requires security knowledge to parse. Findings inconsistently structured. Notable formatting or grammar issues.
Below 15: Executive summary inaccessible to a non-technical reader. Document structure unclear.
Engagement discipline + reflection (30 pts)
27-30: ROE respected throughout; documented explicitly in methodology. Scope boundary events (if any) were reported and documented. OPSEC choices (e.g., TCP SYN vs. connect scan; timing; noise level) explained in methodology. Oral debrief shows genuine post-engagement learning -- the student can name two things they would do differently and articulate why.
21-26: ROE respected. Limited OPSEC discussion. Oral debrief adequate but surface-level on reflection.
15-20: ROE respected but not documented. No OPSEC discussion. Oral debrief does not engage with lessons learned.
Below 15: ROE compliance uncertain. Oral debrief unprepared or evasive.
Required submitted artifacts
All artifacts submitted before the oral debrief:
- Engagement report (PDF, professionally typeset; Markdown-to-PDF via Pandoc or equivalent is acceptable)
- Evidence-appendix archive (ZIP containing screenshots and terminal transcripts; named by finding number)
- Oral-debrief slide deck (10 slides maximum; covering the three most significant findings + engagement timeline + lessons learned)
- Lessons-learned memo (one page; personal reflection on what the student would do differently in a real engagement)
- Engagement Git repository (private; submitted via instructor-access URL)
Oral debrief format
The instructor plays two stakeholders in sequence:
Technical peer (first 10 minutes): Questions about tool choice, why a finding was CVSS-scored the way it was, whether a specific exploitation technique was optimal, what the student tried that did not work. The goal is to probe whether the student understands what they did, not just that they ran the tools.
Non-technical client executive (last 10 minutes): Questions about what the risk means for the fictional business, what to fix first and why, what this engagement cost and whether it was worth it, what the company should do differently going forward. The goal is to probe whether the student can translate technical findings into business language.
The student may refer to slides and the report during the debrief. Notes are permitted.
Exemplar report outline
Meridian Financial Partners -- External Penetration Test Report
Engagement dates: [Day 1-5]
Prepared by: [Student name], Virtus Cyber Academy, PEN-101 Cohort [N]
Executive Summary ............................ 1-2
Methodology .................................. 3
Scope and authorization
Tools and versions
Timeline
Out-of-scope items
Findings ..................................... 4-N
Finding 1: [Title] ........................ 4
CVSS v3.1 score: [X.X / VECTOR_STRING]
Affected system: [host:service]
Description
Evidence
Business impact
Remediation
Finding 2: [Title] ........................ [N]
...
Remediation Roadmap ......................... [N]
Immediate (Days 1-7)
Short-term (Weeks 1-4)
Long-term (Quarter+)
Evidence Appendix ........................... [N]
Appendix A: Network scan output
Appendix B: Screenshots (by finding)
Appendix C: Command transcripts (by finding)
A note on report quality
Writing a good penetration test report is practice. The report is not a technical document that happens to have an executive summary bolted on; it is a business document that happens to have technical evidence attached. The executive summary is the document. The findings and appendices support it.
Georgia Weidman puts it directly in Penetration Testing: "You'll need to convey your findings clearly to everyone from the IT staff charged with fixing vulnerabilities to upper management who signs off on the changes to external auditors." That is the standard the capstone report is graded against.
A finding that reads "Exploited MS08-067 to get a Meterpreter shell on 192.168.100.12" scores in the lower tier. The same finding rewritten as "Unauthenticated remote code execution on the legacy order-processing server: an attacker with network access could read, modify, or destroy any order or customer record on this system" scores in the upper tier. The underlying technical work is identical. The client communication is not.
CAPSTONE.md v0.1. Related: INSTRUCTOR-GUIDE.md (lab network setup, oral debrief logistics), PEN-101-OUTLINE.md (two-tier rubric summary), SETUP.md (evidence-preservation discipline).