Step 173. Scenario 1 Review and Penetration Report — The Skill of Weaving Records into a Document

Level 2 — Introduction to Security and Attack Skill Basics | Difficulty ★★★☆☆ | Estimated time: 3 hours

Prerequisites: you have Step 172’s (Capstone Scenario 1) timeline and evidence, and you know Step 128’s (MS2 report) six-part structure.

• What you need: Step 172’s timeline and evidence files, a Markdown editor, Python 3 (for the structure validator).
• ⚠️ All exercises in this chapter are for your own lab and legal platforms only. Applying them to unauthorized systems is a crime.
• Character note: today is a [project] chapter. There is no new attack — this is the day you turn yesterday’s attack into a document someone else can reproduce.

The penetration is over, but the work isn’t. The deliverable of a real penetration test is not the shell but the report, and a report is written for two readers — the executive ("how dangerous is it, what must we do") and the engineer ("where and how do we fix it"). Today we do two kinds of work. First, the review — reconstructing Scenario 1’s whole process from records, not memory, and analyzing missed clues. Then the report — weaving the review’s results into a document both readers can each read. Writing even the stuck points and the breakthroughs is today’s rule — failures raise a report’s value.

1. Learning Objectives

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

• Reconstruct the attack path from timeline records
• Extract improvements for the next round through missed-clue analysis (why did I see it late)
• Write in distinct tones for the executive summary (non-technical) and technical details (reproducible)
• Describe each finding in the four fields: severity, reproduction steps, evidence, fix
• Build a small tool that automatically validates the report’s structure

2. Background Knowledge — Today’s Tools and Concepts

Today’s Tools at a Glance

2-1. The Review — From Records, Not Memory

A debrief is the work of unfolding a finished round again. Like reviewing a game of Go, the purpose is not confirming the result but reviewing the judgments — "why did I verify this hypothesis first here," "why did I see this clue late."

The raw material of a review is not memory but records. Memory flatters a round you won — a section where you actually wandered for 40 minutes shrinks to 5 in memory. The reason you wrote down times in Step 172 reveals itself today: the timeline’s time gaps are the honest answer to "where did I spend my time."

2-2. Missed-Clue Analysis — A Legacy for the Next Round

The most valuable output of a review is the "missed clues" list. The format has three fields.

Clue: (what turned out decisive in hindsight — e.g., the version was in the banner)
When first seen vs when used: (e.g., seen at 0:05 → used at 0:41)
Why late: (e.g., skipped past looking only at the port number, not reading the banner)
Rule for the next round: (e.g., read every open port's banner aloud in full)

The moment "why late" turns into "rule for the next round," a mistake becomes an asset.

2-3. Two Readers, Two Styles

The report’s first page (summary) and body (technical details) use different languages.

✗ A sentence that must not appear in the summary: "Unauthenticated command execution confirmed on 9000/tcp"
○ A summary sentence: "Commands on the server could be executed from outside with no
   authentication whatsoever, and this server was running with the highest privileges."

Conversely, the criterion for technical details is reproducibility — "can a third party reproduce this exactly from this text alone?" Commands, outputs, and evidence are its materials. Step 128’s "never write a claim without evidence" applies here as-is.

2-4. Severity Is Reasoned Description First

Findings get severity ratings. The field has a standard scoring system called CVSS, but at the introductory stage, reasoned description comes before precise calculation — the form where a reason follows the grade, like "since unauthenticated remote command execution with the highest privileges is possible, this is High/Critical grade." Use Step 128’s severity criteria as-is (critical = immediate remote control, high = direct privilege escalation, medium = information exposure).

3. Follow Along

3-1. Review — Reconstructing the Timeline

Spread out Step 172’s timeline and bundle each line into "stages." Template:

# Scenario 1 Review (date: ____)

### Stage-by-stage reconstruction
| Time | Stage | What I did | Result | Elapsed |
|------|------|-------|------|------|
| 16:52 | recon | nmap -sV | open + banner captured | 1 min |
| 16:53 | hypothesis | "unauthenticated command execution" | formed | immediate |
| 16:53 | verification | ran id via nc | uid=0(root) confirmed | 1 min |

### Time analysis
Section where I spent the most time: ____
Its cause and the next round's countermeasure: ____

### Missed clues (at least 2, in 2-2's three-field format)
1. Clue: ____ / delay: ____ / reason: ____ / rule: ____
2. Clue: ____ / delay: ____ / reason: ____ / rule: ____

How to read it: fill the "elapsed" column from time gaps — from records, not memory. The section where you spent the most time is exactly your growth point, and that section’s analysis is the material for the report’s "breakthrough process" section.

3-2. The Report Skeleton — Reusing Step 128’s Structure

Bring Step 128’s six-part structure over in a Scenario 1 version, with a review section added.

# Scenario 1 Penetration Test Report
Date: ____ | Author: ____ | Target: (lab environment noted)

### 1. Summary
(3 non-technical sentences — what was possible, how dangerous, where to fix first)

### 2. Scope and Recon
(target, period, method + scan results quoted — evidence: evidence/01-scan.txt)

### 3. Attack Paths
#### Path 1: (service name) [severity]
- Root cause: ____
- Attack method: (commands in exact order — reproducibly)
- Privilege gained: ____ (id output as evidence)
- Remediation: ____

### 4. Evidence
(quoted outputs or evidence/ file references — screenshots include id/whoami)

### 5. Recommendations
(in severity order — each item's basis is a finding in section 3)

### 6. Timeline and Review
(3-1's reconstruction table + missed clues and next-round rules)

How to read it: sections 1~5 are exactly what you practiced in Step 128; section 6 is today’s addition. "Stuck points and breakthroughs" go into each path of section 3 as a sentence, and into section 6 in structured form.

3-3. Finding Details — The Four Fields, Repeated

For each path, fill "root cause → attack method → privilege gained → remediation." An example filled with the Step 172 mini chain (measurement-based):

### Path 1: Unauthenticated command-execution service [Critical]
- Root cause: the 9000/tcp service accepts and executes commands without
  authentication. The service runs as root, so the damage ties directly
  to the highest privilege.
- Attack method:
  1. nmap -p 9000 -sV 127.0.0.1 → banner "MiniVulnService 1.0" captured
  2. printf "idn" | nc 127.0.0.1 9000 → command execution confirmed
- Privilege gained: root (evidence below)
- Evidence:
  $ uid=0(root) gid=0(root) groups=0(root)     (measured 2026-09-09)
- Remediation: add authentication to the service; minimize the service
  account's privileges.

How to read it: the "attack method" is the commands in exact order — a reader following them must get the same result. "Remediation" pairs with the cause — if the cause is "no authentication," the fix is "add authentication"; if the cause is "running as root," the fix is "privilege minimization."

3-4. A Structure Validator — Let a Machine Find Missing Sections

Once a report gets long, a missing section escapes the eye. Let’s build a small validator.

Input: report_check.py:

# Report structure validator — checks that required sections exist
import re, sys

REQUIRED = ["Summary", "Scope and Recon", "Attack Paths", "Evidence", "Recommendations", "Timeline"]

def check(path):
    text = open(path, encoding="utf-8").read()
    headings = re.findall(r"^#{2,3}s+(.+)$", text, re.M)
    print(f"Checking: {path}")
    missing = []
    for need in REQUIRED:
        ok = any(need in h for h in headings)
        print(f"  [{'x' if ok else ' '}] {need}")
        if not ok:
            missing.append(need)
    if missing:
        print("Missing:", ", ".join(missing))
    else:
        print("Structure check passed — all 6 required sections present")

if __name__ == "__main__":
    check(sys.argv[1] if len(sys.argv) > 1 else "report.md")

Output (measured 2026-09-09, against a sample with the skeleton complete):

Checking: report_sample.md
  [x] Summary
  [x] Scope and Recon
  [x] Attack Paths
  [x] Evidence
  [x] Recommendations
  [x] Timeline
Structure check passed — all 6 required sections present

Against a file with an empty skeleton (no sections) (measured 2026-09-09):

Checking: step170_meta.py
  [ ] Summary
  [ ] Scope and Recon
  [ ] Attack Paths
  [ ] Evidence
  [ ] Recommendations
  [ ] Timeline
Missing: Summary, Scope and Recon, Attack Paths, Evidence, Recommendations, Timeline

How to read it: the regular expression ^#{2,3}s+(.+) picks out only Markdown section headings (Step 48 review). Handing structure checking to a machine lets your eyes focus on reviewing content — Step 164’s automation sense applies as-is to document work.

3-5. Self-Feedback — The Reproducibility Self-Check

Pose the final question to your completed draft: "Can someone reproduce my penetration with this report?"

Check order: ① if you copy section 3’s commands exactly, does the same output come out? ② does every output have a source (an evidence file or a measured tag)? ③ when you read the summary aloud to someone who doesn’t know the technology, does the size of the danger come across? If even one is "no," go back to that section and reinforce it. This self-check turns a report from "my diary" into "someone else’s manual."

4. Missions & Exercises

Mission — Completing a One-Part Scenario 1 Penetration Report

1. Reconstruct the Step 172 timeline with 3-1’s template, filling in the time analysis and 2 missed clues
2. Create scenario1-pentest-report.md with 3-2’s skeleton and fill all 6 sections
3. The summary is 3 non-technical sentences, and every claim in the body carries evidence (a quoted output or a file reference)
4. At least 1 stuck point and breakthrough is recorded
5. Pass the structure validation with report_check.py
6. (If you did Step 172 as a plan without a lab) tag unverified cells with [to be replaced with measurement after lab run]

Exercises

Exercise 1. Using the time-analysis example, explain why a review must be done from "records," not "memory."

Exercise 2. Explain why the output of missed-clue analysis must be "rules for the next round."

Exercise 3. Referring to 2-3’s example, explain how the same finding is written differently in the summary section and the technical-details section.

Exercise 4. From the reader’s standpoint, explain what it means that "recording stuck points and breakthroughs raises a report’s value."

Clue: nmap -sV consumes the server's single connection (version detection = connecting)
When first seen vs used: nc failed right after the scan → cause identified after checking the log
Why late: assumed "scanning only reads" and didn't suspect the server structure
Rule for the next round: always build lab services with a repeating-accept structure,
  and on failure, open the other side's logs first

6. Common Pitfalls & Fixes

Wall 1. The validator dies with FileNotFoundError

Symptom (measured 2026-09-09, after mistyping the filename):

FileNotFoundError: [Errno 2] No such file or directory: 'nofile.md'

Cause: the filename you passed to the validator doesn’t exist in the current directory.
Fix: check the filename with ls (or dir) before passing it. Once you’re comfortable, wrapping it in try/except FileNotFoundError to show a friendly message is a nice enhancement.

Wall 2. Technical terms keep slipping into the summary

Symptom: "nc", "port 9000", "uid=0" appear in the summary.
Cause: the writer’s eyes are still the attacker’s.
Fix: a test — tear out just the summary and read it to someone who doesn’t know the technology. If the reaction is "so what’s dangerous about that?", rewrite it. Each summary sentence must answer one of three: "what was possible, how dangerous is it, where to fix first."

Wall 3. The timeline is empty, so the review depends on memory

Symptom: filling in the reconstruction table, all the times are guesses.
Cause: you postponed recording in Step 172.
Fix: for this round, honestly tag it [no record — estimated] and analyze only the sections that are certain. And adopt "record one line immediately per command" as the first rule of the next round. The honesty of marking blanks is also a review deliverable.

Wall 4. The recommendations don’t connect to the body’s findings

Symptom: the recommendations include content not in the body (like "we recommend introducing antivirus").
Cause: you padded it with generalities.
Fix: Step 128’s rule as-is — attach "(basis: path N)" in parentheses after each recommendation item. A recommendation with no basis to attach gets removed, or its finding gets added to the body. A recommendation’s driving force comes from "we personally entered through this hole."

Wall 5. Erasing failures and writing only successes

Symptom: the 40 minutes you were stuck appear nowhere in the report.
Cause: the heart that is ashamed of failure.
Fix: reread the sentence in section 5 — a record of failure is both a trap-avoidance sentence for the reader and the evidence of trust that makes this report believable. A report with only success is a diary; a report with failure and breakthrough is a textbook.

7. Summary

Today’s Concepts

Today’s Commands & Tools

An Instinct More Important Than Commands

Today Scenario 1’s cycle closed — you penetrated, recorded, reviewed, and left a document. A shell vanishes when the session drops, but a report remains as the power that fixes the system. And don’t forget what the review taught: the best attacker is not the one who never gets stuck, but the one who turns stuck spots into rules. Your first report doesn’t need to be perfect — honest, reproducible, and making the next round better is enough.

Once every box is checked, Step 173 is complete.