Step 305. Taking Down Practice Machines Begins — One Report per Machine

Level 4 — Expert | Difficulty ★★★☆☆ | Estimated time: 1–2 days (4-hour timebox × 2 machines)

Prerequisites: you completed the OSCP preparation plan and the 30-machine practice list in Step 304. You know Step 128’s six-part report structure.

What you need: the practice machine list from Step 304, an HTB or Proving Grounds account with VPN, an attack machine (Kali recommended), an evidence folder convention, and a timer.
⚠️ All exercises in this chapter are for your own lab and legal platforms only. Applying them to unauthorized systems is a crime. Proving Grounds and Hack The Box are legal learning platforms officially opened by their operators.
Screen guide: every platform screen and machine-takedown output in this chapter is a screen example. The actual takedowns are performed by you.

In Step 304 you drew the map; today you start walking. But the way you walk differs from before in one respect — every machine you take down leaves behind one exam-format report draft. In the OSCP, "solved but no evidence means zero points," so evidence collection is not cleanup done after the takedown — it is part of the takedown itself. Today’s real goal is not two machines; it is building a body rhythm of attacking while recording.

1. Learning Objectives

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

Select machines matching difficulty and type from an OSCP-like machine list
Practice the habit of collecting evidence (command output, screenshots) while attacking
Allocate time across "attack / record / judge" inside a timebox (4 hours)
Write one exam-format report draft per machine
Update the practice list and your weakness map through takedown retrospectives

2. Background Knowledge — Today’s Tools and Concepts

Today’s Tools at a Glance

Category	Details
Language/environment	HTB or Proving Grounds (VPN) + Kali attack machine
Today’s commands	`rustscan`/`nmap`, per-service enumeration tools, a screenshot tool (Flameshot, etc.), `tee`
Concepts needed	OSCP-like machine lists, evidence collection rules, timeboxing, the report draft format
Today’s deliverable	2 Easy standalone machines taken down + 2 per-machine report drafts + an evidence folder

2-1. What Is an OSCP-like Machine — Not a "Flag Puzzle"

Not every HTB/PG machine is good exam preparation. The traits of machines classified as OSCP-like:

Service-chain type: they follow the order of a real penetration, like web vulnerability → shell → privilege escalation.
Few CTF-style tricks: no contrived riddles for difficulty’s sake (steganography, excessive crypto puzzles).
Enumeration is the difficulty: the reason you get stuck is almost always "a port/directory you didn’t look at."

The community’s TJ_Null’s OSCP-like list is a long-validated list on these criteria (screen example):

OSCP-like practice machines (example classification)
┌──────────┬─────────────────────────────────────────┐
│ Easy     │ Lame, Blue, Legacy, Jerry, Nibbles ...  │
│ Medium   │ Forest, Sauna, Active, Bastion ...      │
│ Hard/AD  │ APT, Offshore (lab), PG AD sets ...     │
└──────────┴─────────────────────────────────────────┘

The actual list is the 30 machines you made yourself in Step 304. Today you pick 2 Easy ones from it.

2-2. Evidence Collection Rules — The Reality of Exam Grading

For points to count in the exam, evidence is required. The known requirements as of this writing (check the exam guide for details):

Per machine, the contents of local.txt (user evidence) and proof.txt (highest-privilege evidence)
Screenshots must also show information identifying that machine (IP, hostname)
The penetration’s commands must be described in the report at a reproducible level

Translated into practice habits, these requirements become three things.

① Take the shot "before" running an important command — after the result appears, it's often too late
② Always keep hostname/IP visible in the captured screen
③ Also save command output to a file with tee — don't trust screenshots alone

2-3. Evidence Folder Convention — One Storage Location

If evidence scatters, you’ll spend report-writing time hunting for evidence. Fix one folder convention.

~/oscp-evidence/
├── lame/
│   ├── 01-nmap-full.txt
│   ├── 02-nmap-detail.txt
│   ├── 03-enum-web.txt
│   ├── 04-initial-shell.png   ← keep whoami + ip a visible
│   ├── 05-privesc.png
│   └── 06-proof.png           ← proof.txt + hostname + ip
├── blue/
└── reports/
    ├── lame-draft.md
    └── blue-draft.md

The number in front of each filename is the takedown order — later you can point to it directly in the report as "evidence 03." Same philosophy as Step 128’s evidence rules.

2-4. Timeboxing — The Blueprint of 4 Hours

In the exam you can spend about 4 hours per machine on average. Build that rhythm into your body from practice.

0:00~0:40  Enumeration — full ports → service detail → dig into each service
0:40~2:00  Initial foothold — start with the most promising surface
2:00~3:00  Privilege escalation — recon checklist (linPEAS/winPEAS + manual checks)
3:00~4:00  Slack / re-enumeration — if stuck, regress to enumeration (Step 306)
          ※ The report draft is filled for 5 minutes after each phase, not "at the end"

When the timebox ends, stop. If you didn’t solve it, write the retrospective exactly as it stands and continue the next day — "holding on forever" is not the exam sense; "keeping time" is.

3. Follow Along

3-1. Machine Selection and Deployment

Pick 2 from the Easy tier of your Step 304 list — one Linux and one Windows is good for balance (screen example):

Today's selection
1. Lame (HTB, Linux, Easy)   — service-version vulnerability type
2. Blue (HTB, Windows, Easy) — known vulnerability (MS17-010) type

Once you deploy a machine and get its IP, do two things immediately: create the evidence folder (mkdir -p ~/oscp-evidence/machine-name), and create the report draft file (skeleton only — the format from 3-4).

3-2. Enumeration — Full Ports First

The first command is always a full-port scan (screen example):

rustscan -a 10.10.10.3 -- -sC -sV -oN ~/oscp-evidence/lame/01-nmap-full.txt

PORT     STATE SERVICE    VERSION
21/tcp   open  ftp        vsftpd 2.3.4
22/tcp   open  ssh        OpenSSH 4.7p1
139/tcp  open  netbios-ssn Samba smbd 3.0.20-Debian
445/tcp  open  netbios-ssn Samba smbd 3.0.20-Debian
3632/tcp open  distccd    distccd v1

How to read it: next to each service, memo a "thing to check" — vsftpd 2.3.4 → backdoor?, Samba 3.0.20 → search known vulnerabilities, distccd → RCE possible. These memos are the candidate list for the attack order. And confirm the scan result file is already saved as evidence 01 — the moment recording runs ahead of the attack.

3-3. Initial Foothold and Evidence Capture

Try the most promising surface first. The moment you get a shell, capture before the next command (screen example):

whoami && hostname && ip a | grep inet

root
lame
inet 10.10.10.3/24 ...

cat /root/root.txt   # on a user machine: /home/<user>/user.txt

Capture order matters — whoami (privilege) + hostname (machine identification) + ip a (network identification) + the flag must be on one screen for that evidence to be complete. Save it in the number-four folder (04-initial-shell.png), and write the filename straight into the corresponding section of the report draft.

3-4. Report Draft — One per Machine

When the takedown ends (or the timebox ends), complete the draft within 30 minutes. The format is a compact version of Step 128 — the formal exam template is finalized in Step 307, so today you fill only five boxes.

# Lame (10.10.10.3) — report draft
- Date: ____ / Time taken: __h __m / Result: full compromise or initial foothold only

## Attack path summary (one sentence)
## 1. Enumeration — services found and judgment grounds (evidence 01–03)
## 2. Initial foothold — the vulnerability, why it's vulnerable, commands run (evidence 04)
## 3. Privilege escalation — the path and its grounds (evidence 05)
## 4. Evidence — local/root + hostname + ip capture (evidence 06)
## 5. Remediation — one line per finding

Writing tips: you’re not "transcribing the attack log" — you’re "writing a document a reviewer can reproduce." Commands in order, with confirmed grounds (versions, configurations), not guesses. Always record the time taken — this is where the "my data" from Step 304 accumulates.

3-5. Retrospective — Updating the List and the Weakness Map

When both machines are done, stamp completion dates on the Step 304 list and leave a three-line retrospective for each machine.

## Lame retrospective
- Where I got stuck: (nowhere / where)
- The enumeration that unblocked me: (what did I re-look at to solve it)
- What I'll do differently next time: (e.g., move the SMB version check earlier, into the scan phase)

The accumulation of "the enumeration that unblocked me" is the raw material for the weakness map you’ll build in Step 306. Retrospect on unsolved machines too — "how far I got and what I didn’t look at" at the moment the timebox ended is the best textbook.

4. Missions & Exercises

Mission — 2 Easy Standalone Machines + 2 Report Drafts

Pick 2 Easy machines from the Step 304 list (1 Linux + 1 Windows recommended) and take them down with a 4-hour timebox
Create a per-machine evidence folder and save evidence by the numbering convention
Leave captures showing whoami+hostname+ip a at the moments of initial shell and flag capture
Complete each machine’s report draft (five-box format) within the same day as the takedown
Leave a three-line retrospective per machine and record completion dates on the Step 304 list

Exercises

Exercise 1. Explain why the habit of "taking the shot before running an important command" is needed, from the perspective of exam grading.

Exercise 2. Why must whoami, hostname, and ip a appear together in an evidence capture?

Exercise 3. Name two advantages of filling the report draft "for 5 minutes after each phase" rather than "later, after solving everything."

Exercise 4. Explain why the retrospective of an unsolved machine is, if anything, more valuable.

5. Model Answers & Completion Criteria

Mission Model Answer

The "Initial foothold" section of a finished report draft looks like this (the output portion is a screen example — the space you fill with your own measurements):

## 2. Initial foothold — Samba 3.0.20 'username map script' (CVE-2007-2447)
- Cause of vulnerability: Samba 3.0.20's username map script feature
  can be abused for unauthenticated command execution. Running an
  end-of-support version is the direct cause.
- Attack process:
  1. Confirmed Samba 3.0.20-Debian on 139/445 in nmap (evidence 01)
  2. searchsploit samba 3.0.20 → confirmed CVE-2007-2447
  3. Obtained a reverse shell by injecting a command via the smbclient username
- Privilege obtained: root (evidence 04: whoami=root, hostname=lame, ip=10.10.10.3)
- Defense: update Samba to the latest release, review external exposure

How to verify: ① can the draft "be reproduced by a reviewer" — are commands in order with grounds? ② do the evidence filename citations match the actual files in the folder? ③ do the captures show privilege + identification information together? ④ are time taken and the retrospective recorded? ⑤ if the machine is unsolved, is "how far you got" left precisely in the draft — even a partial record must be in a submittable state.

Exercise Answers

Answer 1. Because in the exam, each phase of the penetration is graded on evidence, and a screen that has passed often cannot be recovered — if the shell session drops or the machine resets, you can never take that shot again. The habit of "capturing before running" builds evidence into the attack flow itself, so the solution becomes grading material. If this habit isn’t in your body from practice, you will inevitably drop it in the tension of exam day.

Answer 2. To prove "on which machine, with what privilege" that capture was obtained. A screen showing only a flag string can’t be tied to any machine, so a grader can hardly accept it. Only with hostname and ip visible does the evidence attach to the machine, and only with whoami visible can the privilege level (user / highest) be distinguished.

Answer 3. First, you write while memory is alive, so command order and judgment grounds stay accurate — a day later, you forget even "why did I run this command." Second, the burden at completion disappears — a report written whole after a 4-hour takedown is an hour of labor, but 5 minutes per phase is break-level. Quality and speed rise at the same time.

Answer 4. Because a solved machine is confirmation of what you already know, while an unsolved machine tells you "the location of what you don’t know." The record at timebox end — which enumerations you did and what you never looked at — becomes the precise target of the next training. In OSCP preparation, the weakness map is drawn from failure logs, not success logs.

Completion Criteria Checklist

[ ] I can explain the traits of an OSCP-like machine (service-chain type)
[ ] I created and applied an evidence folder convention (number-content)
[ ] I practiced the habit of putting whoami+hostname+ip together in captures
[ ] I attacked following the phase allocation of the 4-hour timebox
[ ] I completed per-machine report drafts on the same day
[ ] I left three-line retrospectives and stamped completion dates on the list
[ ] Mission: 2 Easy machines + 2 drafts + evidence folder complete

6. Common Pitfalls & Fixes

Wall 1. Absorbed in solving, I miss the screenshots

Symptom: the machine is compromised but there’s no evidence.
Cause: recording sat "after" the attack.
Fix: reverse the order — capturing before important commands is the rule. If the machine is still alive, take the evidence anew; if it was reset, attack from the beginning again, this time capturing. This inconvenience builds the muscle that protects your score on exam day. Write "in the exam, no evidence means zero points even if solved" on your folder’s wallpaper.

Wall 2. Breaking the timebox and holding on all night

Symptom: 4 hours became 9, and the next day’s schedule collapsed.
Cause: the illusion that "just a bit more" is skill — the exam has no "just a bit more."
Fix: when the timer rings, take your hands off and write the retrospective. If you want to continue, redeploy the same machine the next day and go from the start — a redeployed takedown also reviews enumeration, so it’s no loss.

Wall 3. The report draft becomes a copy of the attack log

Symptom: the draft is a list of commands with no "why."
Cause: you forgot the reader — the draft’s readers are "future me" and "the reviewer."
Fix: force one line of grounds into each section — "reason I probed this service: version 3.0.20 confirmed." Step 128’s four-box format (cause → method → privilege → defense) applies as-is.

Wall 4. The evidence folder becomes a mess and I can’t find citations

Symptom: names like Screenshot 2026-09-09 (3).png pile up.
Cause: you didn’t apply the naming rule at capture time.
Fix: set the capture tool’s save folder to the machine folder in advance, and rename to number-content.png right after saving. A 10-second rename saves 30 minutes of report writing.

Wall 5. The machines are easy, so I want to skip them

Symptom: "I already know Lame," you say, wanting to skip the recording drill.
Cause: you misunderstood this chapter’s purpose as machine compromise.
Fix: today’s training target is not the machine but the recording rhythm. Easy machines are exactly the optimal sandbox for focusing on the recording habit with no technical burden. If you first train the recording habit on a hard machine, you’ll drop both.

7. Summary

Today’s Concepts

Concept	One-line explanation
OSCP-like machine	Service-chain type, enumeration is the difficulty — few CTF tricks
Evidence collection rules	local/proof + hostname + ip — capture before running
Evidence folder	`~/oscp-evidence/machine/number-content` — citation order matches numbers
4-hour timebox	Enumerate 40 min → foothold → escalate → re-enumerate; draft 5 min after each phase
Report draft	Five-box format — at a level a reviewer can reproduce
Three-line retrospective	Where stuck / the enumeration that unblocked / what’s different next — raw material for the weakness map

Today’s Commands & Tools

Tool	What it does
`rustscan -a target -- -sC -sV -oN file`	Full-port scan and evidence-01 save at once
`whoami && hostname && ip a`	The privilege/identification set right before an evidence capture
Flameshot or other capture tool	Save-folder setting + naming rule applied
`~/oscp-evidence/`	Per-machine evidence repository
Timer	The timebox’s enforcement device — when it rings, hands off

The Core Instinct

In OSCP preparation, "solving" and "recording" are not two jobs but the front and back of one job. The rhythm you made today — capture before running, fill the five boxes when a phase ends, write the retrospective when the timer rings — saves time on hard machines and protects points in the exam room. The count of accumulated report drafts is your readiness. Once about 10 drafts have piled up, the report stops being work and becomes the breathing of the takedown itself.

Once every box is checked, Step 305 is complete.