Step 267. One HTB Medium Machine (Cumulative 2) — Read the Starring Service, Turn Stuck Points into Statistics

Level 3 — Real-World CTF & Advanced Offensive Skills | Difficulty ★★★★☆ | Estimated time: 2 days (2–3 hours a day)

Prerequisites: Step 265 (first Medium solved independently) and Step 266 (review + re-attack). Start with routine document v2’s five improvements spread out in front of you.

What you need: an HTB VPN environment, routine document v2, Step 265’s progress log (your comparison baseline), and a per-stage time sheet.
⚠️ 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 techniques are used on its machines and nowhere else.
Platform note: every HTB screen and output in this chapter is a screen example. The actual solving and recording happen by your own hands.

The second Medium matters in a different way. It’s the box that verifies whether the pattern you learned on the first (deep enumeration + hypothesis management + research) was luck or reusable skill. Today has two themes — the instinct of reading "what is this machine’s starring service" quickly from the first scan, and the habit of recording where you get stuck, stage by stage, turning it into statistics. Two machines of data sketch the tendency of your weaknesses; the boxes that follow draw their map.

1. Learning Objectives

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

Identify the machine’s type (web-focused / service-focused / AD, etc.) and its "starring service" from the first recon results
Set the starting point of HackTricks research based on the starring service
Pick a machine of a different type from your first Medium and verify the routine’s generality
Record per-stage time and stuck locations and compare them with the first machine
Diagnose "at which stage do I get stuck" using the stuck-point statistics of two cumulative machines

2. Background Knowledge — Today’s Tools and Concepts

Today’s Tools at a Glance

Category	Details
Language/environment	HTB VPN + Kali — the same environment as Step 265
Today’s commands	Familiar recon commands + identification tools of the `whatweb`, `wappalyzer` family, per-stage `date` records
Concepts needed	Machine-type classification, the starring service, statistical diagnosis of weak stages
Today’s deliverable	Cumulative 2 machines rooted + per-stage time comparison table + stuck-point statistics v1

2-1. Reading the Machine’s Star — What the First Scan Decides

Not all services carry equal weight. A Medium machine usually has a starring service — the machine’s theme, around which the entrance and most of the chain revolve.

The clues for reading the star in first recon look like these:

- A service on a non-standard port (web/app servers in the 3000s, 8000s, 9000s)
- An unfamiliar service with an exact version (a service you can't name = likely the machine's theme)
- An unusually large web application (a site with login, search, upload, and an API)
- Conversely, only common 22/80 with a simple web → the type whose clues hide deep in source/paths

The faster you name the star, the faster research goes. Within the first 30 minutes, write "what is this machine about" as a sentence in your log — it’s fine to be wrong; you can correct it as recon deepens. The act of naming itself gives your investigation its coordinates.

2-2. Why Pick a Different Type — Verifying the Routine’s Generality

If your first Medium was web-focused, pick a service-focused one (SMB, DB, mail, etc.) or another theme for the second. Solve the same type back to back and you become "someone good at web machines," but what Medium graduation requires is "someone whose routine stands even when the type changes."

Remember Step 252’s type-branching table — the recon results only decide the branch; the routine’s skeleton (recon → identify → hypothesize → verify → escalate) is the same across types. What you confirm on the second machine is this — does the skeleton hold, with only the branch changing? Where the skeleton shakes, that’s your training list.

2-3. HackTricks Research — Finding the Starring Service’s Attack Order

Once the star is decided, research’s starting point is decided. HackTricks (book.hacktricks.xyz) has a page per service, and each page is a list of "what to check first when you meet this service" (screen example):

[Research routine]
1. Put the service name + version from the nmap banner straight into the HackTricks search box
2. Run the page's 'Enumeration' section from the top like a checklist
3. If no page exists, search "service-name pentest", "service-name exploit"
4. Transfer the attack steps you found into the progress log as a 'hypothesis list to verify'

The key point is that enumeration output is itself the search keyword. One banner line (Apache httpd 2.4.49) opens all of research, and that research makes the hypothesis list. Recon → identify → research → hypothesis list — this chain is Medium’s standard process.

2-4. Stuck-Point Statistics — Diagnosis Starting from Two Machines

In Step 265 you tagged every stuck point with an [enumeration/technique] distinction. Now you gather those records by stage.

[Stuck-point record format]
Stuck #1 | stage: finding the entrance | type: enumeration shortage | spent: 40 min | breakthrough: vhost scan
Stuck #2 | stage: escalation          | type: technique shortage   | spent: 55 min | breakthrough: HackTricks cron doc

Combine two machines’ stuck points and a tendency starts to show.

[Statistics example — cumulative 2 machines]
| Stage            | Times stuck | Total time burned |
|------------|-----------|--------------|
| Recon/entrance   | 3         | 2.5h         |
| Intrusion        | 1         | 1.0h         |
| Privesc          | 4         | 3.5h         |

What this table says: "I get stuck most often, and longest, at escalation." That’s a weakness caught as a number, not a feeling. Stuck points are not random — every person has a tendency in which stage they get stuck, and knowing that tendency sets the order of your next training. As boxes accumulate, this table gets more accurate.

3. Follow Along

3-1. Choosing the Machine — A Different Type from the First

The selection criteria are the same as Step 265, with one addition.

□ Is the community rating good
□ Is it a different type from the first Medium (web-focused ↔ service-focused ↔ other)
□ Does a starring-service candidate look identifiable (inferred from reviews/tags)

Write on the log’s first line: "Selected: (name) / type: ____ / how it differs from the first: ____".

How to read it: "a different type" is not pain but design. Today’s experiment is checking whether the routine you learned on the first machine still stands on unfamiliar terrain.

3-2. Recon and Naming the Star — The First 30 Minutes’ Sentence

Start recon per routine document v2 (screen example):

export TARGET=10.10.11.YYY
mkdir -p htb/second-medium && cd htb/second-medium
date '+start: %F %H:%M' | tee timeline.txt
nmap -sV -p- $TARGET -oN 01_full_tcp.txt
nmap -sU --top-ports 100 $TARGET -oN 02_udp_top100.txt

When the scans finish, look at the results and within 30 minutes write this sentence in the log.

"This machine's star is ____. Grounds: ____."
(e.g., "The star is the unfamiliar web app on 8080. Grounds: the only surface
 with a login form + API; the rest is 22 and static pages.")

How to read it: if identification is ambiguous, check the tech stack with an identification tool like whatweb http://$TARGET:8080. Naming the star is not a verdict but a working hypothesis — if later recon corrects this sentence, that too is a record.

3-3. Star-Centered Research — Building the Hypothesis List

Open the starring service’s HackTricks page and run the ‘Enumeration’ section from the top. For each item checked, leave the result in the progress log (screen example):

[Research → hypothesis list]
Service: (e.g.) Gitea 1.16
□ Try default credentials → failed
□ /api/v1 version info exposure → confirmed, anonymous access denied
□ Public exploit exists? → searchsploit: none
→ Remaining hypotheses: abusing the signup feature, repository enumeration

How to read it: this list is today’s work queue. Verify from the top, one at a time, and erase discards together with their reasons. When hypotheses run dry, that’s when you move to the next star candidate (a supporting service) — confirm that Step 265’s hypothesis-verification cycle is being reused as-is.

3-4. Per-Stage Time Recording — On the Same Scale as the First Machine

Use Step 252’s time-measurement format as-is. Stamp the time whenever the stage changes (screen example):

Machine 2: start 10:00
Recon done: 10:25 (25 min)    ← first machine 1.0h
Entrance found: 11:40 (75 min)    ← first machine 2.5h
Intrusion (shell): 13:20 (100 min)   ← first machine 2.0h
Privesc: 15:10 (110 min)  ← first machine 2.0h

How to read it: the comparisons in parentheses are today’s data. Not everything needs to get faster — with a different type, some stages slowing down is normal. What matters is being able to answer in a sentence, "which stage slowed down, and why."

3-5. Wrap-Up — Stuck-Point Statistics v1 and a Mini Retrospective

After root, merge both machines’ stuck-point records into 2-4’s table and write a mini retrospective.

[Mini retrospective format]
- One thing that went well: ____
- One stuck point (does it match the stage the statistics point to): ____
- One thing to change on the next machine (cumulative 3): ____

How to read it: Step 266’s full-scale review is only needed once every few cumulative machines. What you do every box is this mini retrospective — three lines, but powerful when attached to the statistics table. The point is checking whether "the stuck point" matches the statistics’ most-frequent stage — when gut feel and data disagree, trust the data.

4. Missions & Exercises

Mission — Break a Different-Type Medium and Build Stuck-Point Statistics v1

Pick a machine of a different type from your first Medium and write the grounds for selection.
Within the first 30 minutes, write the "starring-service sentence" in the log — if you correct it later, leave that record too.
Build a hypothesis list from the starring service’s HackTricks page (or search results) and verify from the top.
Record per-stage times in the same format as the first machine, and make a comparison table after finishing.
Merge both machines’ stuck points into a per-stage statistics table, and declare "my most-frequent stuck stage" in one sentence. Close with a 3-line mini retrospective.

Exercises

Exercise 1. Explain why naming the "starring service" quickly speeds up research, from the perspective of the starting point of a HackTricks search.

Exercise 2. Explain why the second Medium should be a different type from the first, together with the concept of "the routine’s generality."

Exercise 3. In stuck-point statistics, explain why data should take priority when the "felt weakness" and the "data weakness" disagree.

Exercise 4. Give two reasons why a slower time at a particular stage than on the first machine does not necessarily mean your skill regressed.

5. Model Answers & Completion Criteria

Mission Model Answer

An example of the deliverable’s shape (the content should be your actual records):

Machine 2: (name) / type: service-focused (first was web-focused)
Star named (Day 1 10:25): "The star is 445/SMB + 5985/WinRM. Grounds: the
  combination of SMB with a readable user list and an admin port — a machine
  whose theme is credentials."
Time comparison: recon 25 min (first 60) / entrance 75 min (150) / intrusion 100 min (120) / privesc 110 min (120)
Stuck statistics (cumulative 2): recon/entrance 3×, 2.5h / intrusion 1×, 1.0h / privesc 4×, 3.5h
→ Declaration: "My most-frequent stuck stage is privesc. Prescription: expanding the privesc checklist comes first."
Mini retrospective: went well — star named within day one. Stuck on — WinRM auth attempt order.
  Change next time — build the credential insertion-order table before starting.

How to verify: ① HTB profile shows 2 cumulative machines complete. ② Is the star-naming sentence in day one’s log? ③ Do the comparison table’s two columns (machine 1 / machine 2) use the same stage divisions? ④ Does the statistics table’s count sum match the number of stuck records in both logs? ⑤ Is there a "most-frequent stuck stage" declaration with a prescription attached?

Exercise Answers

Answer 1. HackTricks is a document organized per service — the search key is the service name. Without naming the star, you wander from "what do I even search for," and inefficiency arises where you investigate every open service a little. Once the star is set, the query is set, and that page’s Enumeration section becomes the very list of hypotheses to verify — research changes from wandering into checklist processing.

Answer 2. To confirm whether the routine is real skill, you have to change the conditions. Solve only the same type and you can’t tell whether you learned a "web-machine pattern" or a "machine-attack routine." If on a different type the skeleton (recon → identify → hypothesize → verify → escalate) holds with only the branch changing, that routine is reusable across types — this is the verification of generality. The parts that shook go onto the training list precisely.

Answer 3. Gut feel is swayed by recency and emotion — the stuck point that hurt most recently feels like the biggest weakness, and the struggle in stretches that were long but successful gets forgotten. Statistics weigh every stuck point on the same scale. Especially "at which stage, how many times, how many total hours" is the basis for allocating training, so training should go not to the stage that feels good but to the stage where time leaks. That said, when data is scarce (2–3 cumulative machines), read it as a tendency only, and correct as boxes accumulate.

Answer 4. First, when the type differs, the stages’ inherent difficulty differs — an intrusion that was fast on a web-focused machine may legitimately be slow on a service-focused one. Second, on the first machine a technique you happened to know may have been the answer (the role of luck). So the purpose of comparison is diagnosis, not ranking — the question is "can you say in a sentence why the stage slowed," and being slow is not itself a failure.

Completion Criteria Checklist

[ ] I picked a Medium of a different type from the first and wrote the grounds
[ ] I wrote the starring-service sentence within the first 30 minutes
[ ] I built and verified a hypothesis list based on the starring service’s HackTricks page (or search)
[ ] I recorded per-stage times in the same format as the first machine
[ ] I made a time comparison table for the 2 cumulative machines
[ ] I made a stuck-point statistics table (stage × count × time)
[ ] I declared "my most-frequent stuck stage" and its prescription
[ ] I wrote a 3-line mini retrospective

6. Common Pitfalls & Fixes

Wall 1. "I can’t tell what the star is within 30 minutes"

Symptom: several services are open and you can’t decide which is the theme.
Cause: you’re treating the naming as a verdict. Naming the star is not guessing the right answer — it’s setting the investigation’s starting point.
Fix: pick the one with the thickest grounds, write it as a "working hypothesis," and start. Thirty more minutes won’t bring certainty — it gets corrected naturally during verification. The correction record ("thought the star was X, but it was Y") is also evidence of skill.

Wall 2. "HackTricks has no page for this service"

Symptom: searching turns up no summary page for that service.
Cause: the service name is a common noun, it’s too new, or you misread the banner.
Fix: try in order — ① reread the banner and secure the exact name + version (version decides search quality), ② search "service name + pentest", "service name + exploit", "service name + misconfiguration", ③ check the service’s official docs for ‘default settings/default credentials.’ Every piece of information enumeration gathered is a search-keyword candidate.

Wall 3. "I’m slower than on the first machine and getting anxious"

Symptom: it’s your second machine, yet some stages take longer, and impatience rises.
Cause: a comparison that doesn’t account for type difference and the role of luck (see Exercise 4).
Fix: add a "reason" column to the comparison table — write a cause sentence for each slowed stage. If the cause is "a technique I didn’t know," that’s today’s harvest; if it’s "an enumeration miss," it’s an improvement for routine document v3. Turning anxiety into measurement is this chapter’s knack.

Wall 4. "The stuck records’ formats differ between the two machines and can’t be merged"

Symptom: machine 1’s log and machine 2’s log use different stage divisions, so the statistics table won’t come together.
Cause: you didn’t fix the format in advance. Statistics can only merge records weighed on the same scale.
Fix: unify the stage divisions now — the four segments recon/entrance/intrusion/escalation are recommended. Reclassify the old logs to build the table, and from the next machine on, fix 2-4’s format into your log template. This inconvenience itself is the lesson "records are written for analysis."

Wall 5. "I dug only the star and missed the real entrance"

Symptom: every hypothesis for the service you judged the star got discarded, and the actual entrance was a supporting service.
Cause: the star-naming turned into obsession. Naming is a priority, not an exclusive choice.
Fix: the hypothesis list running dry is the normal signal to move to supporting services — "it wasn’t the star" is also a fact confirmed by verification. Write "star re-named: ____" in the log and continue. On Medium machines, renaming the star twice is a common occurrence.

7. Summary

Today’s Concepts

Concept	One-line explanation
Starring service	The theme service around which the machine’s entrance and chain revolve
Star-naming sentence	The first 30 minutes’ working hypothesis — research’s starting coordinates
The routine’s generality	The routine’s quality, verified by whether the skeleton holds when the type changes
Stuck-point statistics	A map of weaknesses gathered as stage × count × time
Mini retrospective	Went well / stuck on / one next improvement — the 3-line close of every box

Today’s Commands & Tools

Command	What it does
`whatweb http://$TARGET:8080`	Identify the web tech stack (aids star-naming)
`nmap -sV -p- $TARGET -oN 01_full_tcp.txt`	Recon’s first command — the recording continues
`date '+%F %H:%M' \| tee -a timeline.txt`	Record stage-transition times
HackTricks service pages	The starring service’s attack-order table
`searchsploit "service version"`	Check whether a public exploit exists

An Instinct More Important Than Commands

What the second box confirmed for you is that the first box’s pattern gets reused — recon, naming the star, research, hypothesis list, verification. If this chain has turned twice, it is no longer "this book’s method" but "your method."

And cherish the statistics table. Two machines of it is still small, but a single line like "4 times at escalation" is the coordinate of a weakness that gut feel could never catch. How enumeration records get added to this table on the next box (cumulative 3) — the next chapter is exactly that system of records: the depth of enumeration.

Once every box is checked, Step 267 is complete.