Step 128. ★ Project — The MS2 Full-Compromise Report

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

Prerequisites: Steps 118–127 — the journey through MS2 recon and penetration (vsftpd, distccd, etc.), john/hashcat, privilege escalation, linPEAS, and the post-exploitation checklist.

What you need: every record you’ve left in the MS2 lab so far (scan results, command outputs, screenshots), the checklist from Step 127, and a Markdown editor. If you don’t have an MS2 lab, proceed as an exercise filling in this chapter’s screen example material.
⚠️ All exercises in this chapter are for your own lab and legal platforms only. Applying them to unauthorized systems is a crime.
This chapter is a test — we give you the report’s skeleton (a template), but its content must come from your own attack records.

The deliverable of a professional penetration test is not a shell — it’s the report. What a customer pays for is not "the fact that you got in," but a document containing "what was breached, why it was breached, and how to fix it." Everything you’ve built against MS2 (Metasploitable2) so far — recon, penetration, cracking, privilege escalation, enumeration — today we weave into a single report. This is not a time to replay flashy hacking scenes; it’s a time to turn your traces into a document others can read and act on.

1. Learning Objectives

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

Explain the standard structure of a penetration test report (summary through remediation)
Describe one attack path in the four boxes of "cause → method → privilege gained → defense"
Place command outputs as evidence, and write no claim without evidence
Distinguish the tone of an executive summary from a technical body
Translate your own attacks into defensive recommendations

2. Background Knowledge — Today’s Tools and Concepts

Today’s Tools at a Glance

Category	Details
Language/environment	Markdown (the documentation skills from Step 89), all your lab records so far
Today’s materials	The outputs from Steps 118–127: nmap, shells, john/hashcat, recon tables, linPEAS
Concepts needed	The report’s 6-part structure, evidence-centered writing, severity classification, per-reader tone
Today’s artifact	`MS2-pentest-report.md` — one submittable-quality penetration report

2-1. The Report’s Standard Structure — Six Rooms

A professional penetration test report shares roughly the same skeleton.

① Summary (Executive Summary)   — for executives. "What was possible," without technical terms
② Scope & Recon (Recon)         — target, method, scan results
③ Attack Paths                  — per vulnerability: cause → method → privilege gained
④ Privilege Escalation (Privesc)— the path from a low shell to root
⑤ Evidence                      — outputs and screenshots backing each claim
⑥ Remediation                   — per finding: fix method and priority

Each room has a different reader — ① is read by executives, ③~⑤ by engineers, ⑥ by the person in charge. One document, three kinds of readers. This is how a report differs from a blog post.

2-2. Evidence-Centered Writing — "Output After the Claim"

A report sentence has one law — write no claim without evidence. Behind the claim "gained root," an id output follows. Behind "the service is open" comes an nmap output. Build the habit of taking screenshots so they always include the result of whoami or id — that’s how the screen proves "whose screen it is, at what privilege."

The reason you’ve been told again and again since Steps 125–127 to save outputs to files is revealed today. A finding not saved cannot be written into a report.

2-3. Severity Classification — Not All Findings Are Equal

You grade the vulnerabilities you find. A simple criterion for the introductory stage:

Grade	Criterion	MS2 examples
Critical	Remote, immediate system control	vsftpd backdoor, distccd RCE
High	Authentication bypass, direct route to escalation	Vulnerable kernel (Dirty COW), loose SUID
Medium	Information exposure, weak configuration	Exposed backup files, weak password policy
Low	Best-practice violation level	Unnecessary banner information exposure

The grade is also "the order of fixing" — section ⑥, remediation, is arranged in this grade order.

2-4. "Why It Was Breached" Determines the Document’s Dignity

A list of commands is a log, not a report. The same finding diverges like this:

✗ Bad writing: "I typed nc 192.168.56.101 6200 and a shell came out."
○ Good writing: "vsftpd 2.3.4 contains a backdoor planted without the authors' knowledge.
  Connecting with a username containing :) opens a root shell on port 6200.
  The cause was a supply-chain incident in which the official distribution file was tampered with,
  and the direct exposure cause was failing to update past this version."

The difference is causality — only a sentence where "what was done" (the act) carries "why it worked" (the cause) and "what is wrong" (the point of responsibility) is a sentence that can be fixed.

3. Follow Along

Here’s the template. Copy it to make MS2-pentest-report.md and fill it with your lab records. If you don’t have a lab, follow the filling guidance below for what kind of material fills each item — the outputs pre-filled as examples are marked as screen examples, and replacing them with your own measurements is the mission.

3-1. ① Summary — The First Page You Write Last

The summary sits at the document’s front but is written last — the whole must be complete before it can be summarized. The skeleton:

# Metasploitable2 Penetration Test Report
Date: ____ | Author: ____ | Target: 192.168.56.101 (simulated internal-network environment)

### 1. Summary
This test confirmed (N) penetration paths against the target system,
of which (N) reached the system's highest privilege (root) remotely, without authentication.
The main causes are ① operation of services with known vulnerable versions, ② an outdated kernel,
and ③ default/weak authentication configuration.
There are (N) Critical-grade findings requiring immediate action.

Filling guidance: the summary’s rule is using no technical terms. Not "a shell via port 6200" but "the entire system can be taken over from outside without authentication" — practice translating into sentences an executive can read and decide on.

3-2. ② Scope & Recon — Placing the nmap Results

### 2. Scope & Recon
- Target: 192.168.56.101 / Period: ____ / Method: black box (no prior information)

#### Scan results (evidence: evidence/01-nmap.txt)

Attach Step 118’s nmap output here. If you have no lab records, the below is a reference screen example — just confirm that material of this shape goes in.

PORT     STATE SERVICE     VERSION
21/tcp   open  ftp         vsftpd 2.3.4
22/tcp   open  ssh         OpenSSH 4.7p1
23/tcp   open  telnet      Linux telnetd
80/tcp   open  http        Apache httpd 2.2.8
3632/tcp open  distccd     distccd v1
...

How to read it: scan results are not "narration" but "quotation." And attach a line or two of interpretation under the table — something like "port 23 (telnet) is a plaintext authentication protocol, so its very existence signals poor administration."

3-3. ③ Attack Paths — Repeating the Four-Box Format

Repeat the format below verbatim per path. Filling at least 3 (vsftpd, distccd, + 1 more — the IRC backdoor or rlogin) is the mission.

### Path 1: vsftpd 2.3.4 backdoor [Critical]
- Vulnerability cause: a backdoor planted in a tampered distribution — a shell opens on port 6200 when the username contains `:)`
- Attack method: (the commands and order used — from your records)
- Privilege gained: root shell (evidence below)
- Evidence:
  (command output — screenshots must include id/whoami)
- Defense: replace vsftpd with the latest version, introduce integrity verification for packages from external repositories

Filling guidance: in the "attack method" box, write the exact command order you actually typed — reproducibility is a report’s life, so a reader must get the same result by following the same order. Step 121’s distccd shell and Step 125’s escalation process are the materials for path 2 and the privilege-escalation section respectively.

3-4. ④ Privilege Escalation — Documenting Steps 125–126

### 4. Privilege Escalation
- Before escalation: daemon (distccd shell)
- Recon summary: (what you found in the Step 125 recon table — kernel 2.6.24, SUID list, etc.)
- Escalation path: Dirty COW (CVE-2016-5195) / or a misconfiguration path
- Evidence: the before/after contrast of id outputs

How to read it: the before/after contrast is the key evidence — if the change from uid=1(daemon) to uid=0(root) sits side by side in two lines, that is complete proof of privilege escalation.

3-5. ⑤ Evidence — Storage Rules

Evidence is quoted in the body; the originals are collected separately.

evidence/
  01-nmap.txt          ← recon
  02-vsftpd-shell.txt  ← path 1
  03-distccd-shell.txt ← path 2
  04-privesc-id.txt    ← before/after escalation
  ...

Filling guidance: the filename rule is number-content.txt — with numbers matching the body’s citation order. The tee saving habit from Steps 126–127 pays off here.

3-6. ⑥ Remediation — You Must Know How to Fix as Much as You Were Attacked

### 6. Remediation (in severity order)
1. [Critical] vsftpd 2.3.4 → replace with the latest version. Introduce a hash-verification procedure for distribution files.
2. [Critical] distccd — block external access or apply authentication. Remove development tools from production servers.
3. [High] Kernel update — apply the Dirty COW patch. Establish a replacement plan for end-of-support OSes.
4. [High] Disable unnecessary services (telnet, rlogin, etc.).
5. [Medium] Strengthen password policy — grounded in the cracking results from Steps 123–124.

How to read it: every recommendation’s ground is your findings from the preceding sections. You can write "strengthen password policy" because you actually cracked those hashes with john/hashcat yourself — the point where attack records become defense arguments.

3-7. Time Allocation Guide

Recommended allocation of the estimated 4 hours: collecting and organizing records 40 min, writing paths 90 min (3 × 30 min), escalation & evidence organizing 50 min, summary & remediation 40 min, polishing 20 min. It’s normal for time to stall on a path whose records are thin — re-run that path in the lab and harvest fresh evidence. Going back to redo an attack while writing a report is not embarrassing; it’s the daily routine of real work.

4. Missions & Exercises

Mission — Completing One MS2 Compromise Report

Create MS2-pentest-report.md with section 3’s template and fill all six sections
Describe at least 3 attack paths in the four-box format (cause → method → privilege → defense)
Every claim carries evidence (an output quotation or an evidence/ file reference)
Evidence screenshots/outputs include id or whoami results
Remediation is in severity order, with each item’s ground connected to a body finding
(Without a lab) Tag every box filled with example material as [to be replaced with measurements after a lab run], transparently marking which parts are unverified

Exercises

Exercise 1. State the reason the Executive Summary is written last, and the reason technical terms are avoided in that section.

Exercise 2. Explain how the rule "write no claim without evidence" connects to a report’s credibility.

Exercise 3. Organize in your own words the criterion separating [Critical] from [Medium] severity.

Exercise 4. Explain why every remediation item must connect to a body finding, in terms of the problems of "groundless recommendations."

5. Model Answers & Completion Criteria

Mission Model Answer

Here’s an example of one completed path (the output portions are screen examples — places to replace with your own measurements):

### Path 2: distccd remote command execution [Critical]
- Vulnerability cause: distccd (a distributed compile service) accepts external commands without authentication.
  The direct cause was a development tool exposed on a production server with no authentication or access restriction.
- Attack method:
  1. Confirm 3632/tcp distccd in the nmap scan (evidence 01)
  2. Attempt arbitrary command execution with an NSE script
  3. Open a reverse connection and obtain a shell
- Privilege gained: daemon (a restricted service account) → root via section ④'s path
- Evidence: evidence/03-distccd-shell.txt
  $ id
  uid=1(daemon) gid=1(daemon) groups=1(daemon)
- Defense: remove the distccd service or restrict allowed hosts.
  Establish a policy forbidding development tools in production environments.

How to verify: ① are all six sections present without omission? ② is each path filled with the four boxes (cause, method, privilege, defense) — even one empty box means incomplete. ③ does every "I did this" sentence carry evidence? ④ read the summary aloud — can someone who doesn’t know the technology understand the size of the danger? ⑤ grade yourself — four items (structure completeness, evidence faithfulness, causal narration, remediation connection), 0–2 points each; 6 or more of 8 total is a pass.

Exercise Answers

Answer 1. The summary can be written accurately only after the whole content is fixed, so it’s written last — if the counts and grades disagree with the body, credibility collapses. Technical terms are avoided because the reader is different — the summary’s reader is the person who handles budgets and decisions, and what they need is not "port 6200" but the business-language translation "total takeover possible without authentication."

Answer 2. A report’s reader must be able to reproduce and verify for themselves by looking at the quoted outputs — not buy on trust in the author’s skill. Only a claim with evidence is reproducible, and only a reproducible report remains valid "after the author has left." A claim without evidence has no way to be checked, so from the reader’s position it’s indistinguishable from fiction.

Answer 3. The criterion is the directness of damage and whether prerequisites exist. Reaching system control remotely with no authentication is Critical; if local access or other conditions must come first, it drops a grade; indirect risks like information exposure are Medium or below. The deciding question is "does this single finding, by itself, immediately cause the worst case?"

Answer 4. Groundless recommendations create two problems. First, priorities can’t be set — if you can’t tell which recommendation blocks a Critical finding, the person in charge can’t decide where to start fixing. Second, it erodes trust — a recommendation drawn from a finding not in the report reads as "generalities" and gets ignored. When a recommendation connects to a body finding, the single line "we went in through this very hole ourselves" becomes the recommendation’s driving force.

Completion Criteria Checklist

[ ] I can explain the report’s standard 6-part structure
[ ] I can write the four boxes of path narration (cause → method → privilege → defense)
[ ] The summary is written in business language without technical terms
[ ] Every claim carries evidence (an output quotation or a file reference)
[ ] Evidence includes id/whoami so privilege is proven
[ ] Remediation is in severity order and connected to body findings
[ ] Mission: I completed one submittable-quality report

6. Common Pitfalls & Fixes

Wall 1. I have no records, so nothing to write

Symptom: you did the attacks, but there are no outputs to put in the report.

Cause: because you didn’t save back then — the very situation Steps 126–127 taught as "a finding not saved is a finding that never happened."

Fix: if the lab is alive, re-run and harvest fresh evidence — re-running is common in real work too. And this time, save with tee. The discomfort of this wall builds the saving habit that lasts a lifetime.

Wall 2. The report ends up a list of commands

Symptom: the body is a repetition of "I typed it, it came out."

Cause: section 2-4’s "why it was breached" is missing.

Fix: write each path’s "vulnerability cause" box first. Once the cause sentence stands, the command list naturally slides into the "method" box behind it. Just changing the order raises the document’s grade.

Wall 3. Evidence screenshots show "whose screen" unclearly

Symptom: there’s just a bare shell screen capture.

Cause: a capture missing privilege proof.

Fix: always type id or whoami before capturing, and take the shot with its result visible. The evidence for "I got a root shell" is not the prompt’s color but the one line uid=0(root).

Wall 4. The summary becomes a copy-paste of the body

Symptom: the summary is full of port numbers and tool names.

Cause: you forgot the reader.

Fix: a test — tear off just the summary and read it to someone who doesn’t know the technology. If the reaction is "so what’s the danger?", rewrite it. Each summary sentence must answer one of three: "what was possible, how much of it, and where to start fixing."

Wall 5. I stop, claiming I can’t do it without a lab

Symptom: you have no MS2, so the report is empty.

Cause: you misunderstood this chapter’s purpose — the purpose is not "breaching MS2" but "the ability to weave records into a document."

Fix: proceed by mission item 6’s method — complete the frame with example material and tag unverified boxes as [to be replaced with measurements after a lab run]. Complete the structure first, and when you meet a lab, you only need to plug in evidence. Marking blanks transparently is also a report’s honesty.

7. Summary

Today’s Concepts

Concept	One-line explanation
The report’s 6-part structure	Summary, recon, attack paths, privesc, evidence, remediation — six rooms with different readers
Evidence-centered writing	Output after the claim. A finding not saved is a finding that never happened
The four-box format	Cause → method → privilege gained → defense — the skeleton of path narration
Severity classification	Grading by damage directness and prerequisites — the order of remediation
Translating the summary	Technical terms into business language — the first page written last
Honest blanks	Unverified items are marked and kept — a blank is also accurate information, so it becomes a document

Today’s Commands & Tools

Tool	What it does
`MS2-pentest-report.md`	Today’s artifact — the 6-part template
`evidence/number-content.txt`	The evidence storage — numbers matching body citation order
`tee` (Step 126)	The tool of the evidence-making habit
Step 125 recon table	Material for section ④ privilege escalation
Step 127 checklist	Raw material for section ⑥ remediation (the defensive copy)

An Instinct More Important Than Commands

Today you bound Level 2’s long journey — recon, penetration, cracking, escalation, enumeration — into one volume of a document. A shell vanishes when the session drops, but a report remains. The attacker’s hands are forgotten; the document carries on into a system that gets fixed. "Being able to break in" and "being able to prove the break-in and get it fixed" are different levels of skill, and the latter is the definition of a professional. And finally — remember that this report’s remediation section is itself the defender’s work list. Today, you wrote defense by attacking.

Once every box is checked, Step 128 is complete. Click the checkbox in the sidebar to save your progress.