Step 266. Medium Review + Re-Attack — How to Learn After Solving

Level 3 — Real-World CTF & Advanced Offensive Skills | Difficulty ★★★☆☆ | Estimated time: 4 hours

Prerequisites: Step 265 (independently solving one HTB Medium machine) — your progress log and root record are today’s raw material.

What you need: Step 265’s progress log, that machine’s official write-up plus 2–3 community write-ups, and an HTB VPN environment where you can reset the machine.
⚠️ All exercises in this chapter are for your own lab and legal platforms only. Applying them to unauthorized systems is a crime. HackTheBox (HTB) is a legal learning platform — today’s re-attack also stays inside it.
Platform note: every HTB screen and output in this chapter is a screen example. The comparison and re-attack happen in your own environment.

A machine’s learning value doesn’t ferment the moment you stamp root — it ferments afterward. Right now, having broken through on your own strength, is the only moment you can read other people’s solutions — with no spoiler risk, because you can lay your path and theirs side by side. Today you review Step 265’s machine and re-attack it along a faster path. It’s the day you see "why something that took me 3 hours took someone else 10 minutes."

1. Learning Objectives

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

Reconstruct a timeline from your progress log and quantify "where the time went"
Read official and community write-ups not passively but by tracing "why that order"
Classify the differences between your solution and others’ into three types (detour, unknown, inefficiency)
Reproduce a faster alternative path with your own hands and graft it into your body
Distill five improvements — "next Medium, I do it this way" — into your routine document

2. Background Knowledge — Today’s Tools and Concepts

Today’s Tools at a Glance

Category	Details
Language/environment	The same HTB environment from Step 265 + a documentation tool (Markdown editor)
Today’s commands	No new commands — a day for working the "order and selection" of commands you already know
Concepts needed	Timeline reconstruction, difference classification (detour/unknown/inefficiency), the learning principle of re-attack
Today’s deliverable	One review note + re-attack record + five improvements (folded into routine document v2)

2-1. Why Look Again After Solving — The Learning Principle of Review

Reading a write-up before solving is copying the answer; reading it after solving is learning a different solution to the same problem. The difference is that you already have a path of your own — comparison becomes possible.

Review is especially powerful because errors are preserved. The detours, misses, and unnecessary attempts you made while solving get erased from memory quickly. But they remain in the progress log, and held against a write-up, those errors stand out sharply as "moves others don’t make." Contrasting them before they get erased — that’s the timing of review.

2-2. Timeline Reconstruction — Turning the Log into a Map of Time

Review’s first process is spreading the progress log out as a map in time order.

[Reconstruction example]
Day 1 (2.5h): recon 1h → path scan 0.5h → stuck 1h (vhosts not tried)
Day 2 (3h):   vhost found 0.5h → API enumeration 1h → credentials 0.5h → stuck 1h
Day 3 (2.5h): SSH entry 0.5h → burned 1h on escalation trap → found cron path 1h → root

From this map there’s one thing to ask — "which segment was unnecessary?" In the example above, day one’s stuck hour (time that wouldn’t exist if you’d done vhosts that day) and day three’s trap hour are the candidates. Not every segment is unnecessary — time spent discarding hypotheses is also learning. The map’s purpose is not self-blame but reallocation: next time, where will that time go?

2-3. How to Read a Write-Up — Trace the Order

Read a write-up passively and all that remains is "ah, so that’s how you solve it." Read it tracing, and learning remains. The question to throw at every sentence is this:

Why did they look there first — in which line of the output were the grounds for that judgment
Did I see that line — if I saw it and passed over it, why; if I didn’t see it, which command was missing
Why could they skip that step — a tool option, service knowledge, or experience

Answering these questions as you read, the write-up becomes not an answer key but a public recording of a judgment process. What you learn is not the result but the choices at the branch points.

2-4. The Three Types of Difference — Detour, Unknown, Inefficiency

When you find a difference between your solution and someone else’s, classify it into one of three. Each type has a different prescription.

Type	Meaning	Example	Prescription
Detour	I went around; they went straight	Me: path scans with 3 lists / Them: hit on the first list	Improve enumeration order
Unknown	I didn’t know their technique/tool	Them: using `feroxbuster`‘s filter options	Add to playbook
Inefficiency	Same job, I did it slower	Me: manually trying 20 / Them: a 3-line script	Automation habits

Conversely, record points where you were better, too. They really exist — you may have found a path the community write-ups missed, and that discovery is both evidence of skill and material for teaching others.

2-5. The Re-Attack — The Final Process That Grafts It into Your Body

Read only, and it’s knowledge; do it again, and it’s skill. Reset the machine and reproduce the write-up’s faster path with your own hands.

The re-attack has three rules. ① Go from start to finish without interruption (target: 1/3 of your first solve’s time). ② Use the alternative path, but be able to explain in words why each step holds. ③ If there’s a point where you get stuck even on the re-attack, that’s a genuinely weak spot — you understood it while reading, but your hands don’t know it, so mark it.

3. Follow Along

3-1. Building the Review Note’s Skeleton

Next to Step 265’s log folder, open review.md.

cd htb/first-medium
touch review.md

The skeleton has five sections.

# Review: (machine name)
### 1. Timeline reconstruction (log → map of time)
### 2. Write-up comparison (official + 2 community)
### 3. Difference classification (detour / unknown / inefficiency / where I was better)
### 4. Re-attack record
### 5. Five improvements for the next Medium

How to read it: the reason you make the sections first and then fill them is to keep the review from drifting into "impressions as they come to mind." Only with structure does no comparison get dropped.

3-2. Timeline Reconstruction — Spreading It Out in Numbers

Convert the log’s dated entries into time items (screen example):

| Segment | My time | Main actions |
|------|---------|-----------|
| Recon | 1.0h | TCP/UDP full scans, path scan |
| Finding the entrance | 2.5h | up to vhost discovery — includes 1h stuck |
| Intrusion | 2.0h | API enumeration → credentials → SSH |
| Escalation | 2.0h | trap 1h + cron discovery 1h |
| Total | 7.5h | |

How to read it: check that the sum matches the log’s total time — if it doesn’t, there’s unrecorded time, and that’s information too ("time I can’t even remember what I did in"). This table is the baseline for the write-up comparison.

3-3. Write-Up Comparison — Three Side by Side

Pick one official write-up and two community write-ups. The selection criterion is "different solution styles from each other" — three different styles carry more comparison value than three of the same style.

The table you fill in as you read (screen example):

| Stage | My solution | Official | Community A | Community B |
|------|---------|------|-----------|-----------|
| Entrance | vhost (Day 2) | vhost | vhost | UDP SNMP first |
| Credentials | JS analysis | JS analysis | JS analysis | obtained via SNMP |
| Escalation | cron | cron | SUID (a different path!) | cron |

How to read it: rows that are "all the same" in this table are the machine’s fixed path; the diverging rows are where learning sits. In the example above, Community A’s SUID escalation path is an alternative path you didn’t know — a re-attack target.

3-4. Difference Classification and Re-Attack

After classifying the differences you found by 2-4’s types, reset the machine and re-attack (screen example):

# Reset Machine in the HTB console → wait for a new IP
export TARGET=10.10.11.YYY
nmap -sV -p- $TARGET -oN retry_full_tcp.txt

Re-attack record example:

[Re-attack] Goal: pass via the alternative path (SNMP entrance + SUID escalation), target time 2.5h
- Recon: this time UDP on day one — SNMP 161/udp confirmed immediately
- Entrance: credentials via SNMP community string (25 min)
- Intrusion: SSH entry (10 min)
- Escalation: reproducing the SUID path — found the binary with find, cross-checked GTFOBins (35 min)
- Result: 1h 10m. 1/6 of the first solve's 7.5h.
- Stuck: 15 minutes on the SUID binary's option syntax — bookmarked the GTFOBins page

How to read it: don’t overrate the re-attack’s shorter time — memory did that. The real harvest is that the new path was reproduced by your own hands and that the point where you got stuck even on the re-attack (the option syntax above) got exposed.

3-5. Five Improvements — Into Routine Document v2

Review’s final process is five lines of "next Medium, I do it this way." Write them not as impressions but as action rules.

[Example — write yours from your own review results]
1. Finish UDP top100 on the first day of recon (vhosts/UDP are Day 1 work)
2. Run the vhost scan the moment a TCP web port is confirmed — before path scans
3. If sudo -l looks clean, suspect a trap — immediately search the next candidates in parallel
4. Open GTFOBins in a tab at the start of every escalation stage
5. On finding a credential, classify its protocol candidates first (SSH/form/API header)

Fold these five lines into the routine document you started in Step 252 to make it v2.

How to read it: the condition for a good improvement is "can it be executed on the next machine?" "Be more thorough" is not executable — rejected. "vhosts on Day 1" is executable — accepted. On day one of the next machine (Step 267), spread these five lines out in front of you before you start.

4. Missions & Exercises

Mission — Complete the Review Note and Re-Attack

Reconstruct Step 265’s machine timeline in 3-2’s format and check that the sum matches the total time.
Read the official + two community write-ups while throwing 2-3’s three questions (why look there first / did I see that line / why could they skip it), and fill in 3-3’s comparison table.
Classify the differences into detour/unknown/inefficiency, and if there are points where you were better, record those too.
Reset the machine and re-attack via the alternative path (or a faster version of the same path) — record the time taken and where you got stuck.
Write five improvements as action rules and update the routine document to v2.

Exercises

Exercise 1. Explain the difference between reading a write-up before solving and after solving, from the perspective of "comparison becoming possible."

Exercise 2. If "unrecorded time" (time that doesn’t add up) is discovered during timeline reconstruction, explain what it means and how to handle it.

Exercise 3. Among the three types of difference (detour/unknown/inefficiency), state which type leads to a playbook addition and which leads to enumeration-order improvement, and explain why the prescriptions differ.

Exercise 4. Explain why a point where you get stuck even on the re-attack is a "genuinely weak spot."

5. Model Answers & Completion Criteria

Mission Model Answer

The completed form of the review note is 3-1 through 3-5’s examples combined. There are four core requirements — ① the timeline’s sum matches the log, ② the comparison table has at least one "diverging" row and it’s classified by type, ③ the re-attack record specifies time taken and stuck points, ④ all five improvements are executable sentences (starting with a verb, with a condition).

Bad and good examples of improvements:

✗ "Enumerate better"                      → no way to execute it
✓ "Run the vhost scan the moment a web port is confirmed" → executable on day one of the next machine
✗ "Reduce my time"                        → no measurement criterion
✓ "Record a re-attack reference time (per machine) in the routine document and compare it against the first solve"

How to verify: ① are all five sections of review.md filled in? ② Does the comparison table contain a "where I was better" judgment (absent is legitimate too — with grounds)? ③ Is the re-attack time shorter than the first solve — if longer, is the reason recorded? ④ Are the five improvements in a form you can spread out on day one of Step 267?

Exercise Answers

Answer 1. Read before solving and you have no path of your own, so the write-up becomes the only path, and learning stops at "follow along" — you have no material with which to ask "where would I have gone?" at each branch point. After solving, your own path serves as a control group, so you can compare why different actions came out of the same input (the scan output). Learning happens not in the difference of results but in the difference of judgments — and that difference of judgments is visible only when a control group exists.

Answer 2. Time that doesn’t add up is "time with nothing in the log about what was done" — usually time spent wandering while stuck, or a stretch where the recording habit broke down. It means two things. ① The attempts made in that time are missing from evaluation, so the timeline analysis is probably kinder than reality; ② on the next machine, the recording habit for that stretch (writing one line when you get a shell, etc.) must be strengthened — that’s the prescription. Handle it by marking it "unrecorded," never by filling it with estimates — fabricating missing records contaminates the entire review.

Answer 3. Unknown leads to a playbook addition (entering the technique you didn’t know into the document), and detour leads to enumeration-order improvement (replacing your order with one that gets the same information faster). The prescriptions differ because the differences are different in nature — unknown is a hole in knowledge, so filling it works, but detour is a problem of procedural arrangement, which adding knowledge won’t fix. Inefficiency sits between the two and is solved with tool options or short automation.

Answer 4. A first-solve stuck point can be from lack of information, but a re-attack stuck point is a stuck point in a state where you already know the path. Knowing it and still failing to do it means that step is not an understanding problem but a hands problem — the syntax isn’t in your body or your tool handling is unskilled. It’s where the gap between "I understood" while reading and "I can do it" gets exposed, so it becomes the exact coordinate of your next training.

Completion Criteria Checklist

[ ] I reconstructed the timeline and cross-checked the sum against the log
[ ] I read 3 write-ups (official + 2 community) with the three questions
[ ] I filled the comparison table and classified differences into detour/unknown/inefficiency
[ ] I examined "where I was better" and left grounds
[ ] I reset the machine and re-attacked via the alternative/fast path
[ ] I recorded the re-attack time and stuck points
[ ] I wrote five improvements as executable sentences
[ ] I updated the routine document to v2

6. Common Pitfalls & Fixes

Wall 1. "Reading the write-ups made me ashamed of my solution"

Symptom: what others did in 10 minutes took you 3 hours, and the hand writing the note stops.
Cause: the comparison’s direction is wrong. What you should compare now is not "others’ present" but "my yesterday." And the author of that 10-minute write-up also spent days on their first Medium — you’re looking at their hundredth box.
Fix: fix the review note’s first sentence as "the first solve reached root on my own strength." Independent solving and fast solving are different skills, and there is no latter without the former. Write differences as numbers only — the emotions will still be there after the analysis is done.

Wall 2. "Every write-up takes a different path — I don’t know what to learn"

Symptom: three write-ups, three paths, and the comparison table gets chaotic.
Cause: that’s normal — Mediums often have alternative paths, and that is the machine’s value.
Fix: don’t try to learn every path; pick the one alternative closest to your own path and re-attack only that. Leave the other paths in the table at the level of "I know they exist." In re-attack, one depth beats three breadths.

Wall 3. "The re-attack took longer than the first solve"

Symptom: you took the alternative path and still burned 3 hours.
Cause: the alternative path’s technique is unfamiliar — there was a reason you went the familiar way the first time.
Fix: it’s not failure, it’s measurement. That unfamiliar technique is the core harvest of this review, so record the exact stuck point (command? syntax? concept?) and pass through the same path once more. The second pass’s time is your true re-attack time.

Wall 4. "My improvements all come out in the ‘try harder’ family"

Symptom: the improvements fill up with resolutions like "be more thorough," "go faster."
Cause: you skipped difference classification and tried to write conclusions first. A resolution is a prescription with no cause analysis.
Fix: derive every improvement from a row of the comparison table — the form "in this row of the table, I did X and they did Y; from now on I do Y." An improvement with no row behind it is a groundless improvement.

Wall 5. "I spent the whole day on review and never got to the re-attack"

Symptom: time ran out while reading and organizing.
Cause: you tried to write the review note as a finished document. The review note is a workbench, not a publication.
Fix: decide the time allocation in advance — timeline 30 min, write-up comparison 60 min, classification 20 min, re-attack 90 min, improvements 20 min is about right. However rough the sentences, never skip the re-attack — reading is the eyes’ review, re-attack is the hands’ review, and without the latter half the review is gone.

7. Summary

Today’s Concepts

Concept	One-line explanation
Review	The learning process of contrasting your path with others’ after solving
Timeline reconstruction	Spreading the progress log as a map of time to find unnecessary segments
Detour / unknown / inefficiency	The three types of solution difference — each with a different prescription
Tracing read	Reading a write-up by following "why did they look there first"
Re-attack	The final process of reproducing the alternative path and grafting it into your hands
Five improvements	Lessons in the form of action rules executable on the next machine

Today’s Commands & Tools

Command	What it does
`cd htb/first-medium && touch review.md`	Start the review note
Reset Machine in the HTB console	Initialize the machine for re-attack
`nmap -sV -p- $TARGET -oN retry_full_tcp.txt`	Re-attack recon (the recording continues)
Official write-up + 2 community	Comparison material — pick different styles

An Instinct More Important Than Commands

The essence of today’s work is not "solving the same problem twice" but turning one experience into two learnings. If the first solve measured your skill, the review calibrated it. And the re-attack verified that the calibration made it into your hands.

Spread those five improvement lines out in front of you. A next machine without those five lines will merely repeat today; a next machine with them builds on top of today. Skill grows not by boxes solved but by layers stacked — in the next chapter, your second Medium, that layer will show.

Once every box is checked, Step 266 is complete.