Step 265. One HTB Medium Machine — Solve It Independently, Even If It Takes Days

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

Prerequisites: Step 252 (THM Easy cumulative 8 — locking in the routine) and Step 253 (Linux privesc). If you’ve also read Step 264 (pivoting), handling internal services will come easier.

What you need: an HTB account and VPN (free machines work without VIP), the common routine document you made in Step 252, a folder for progress logs, and three days.
⚠️ 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 platform built for attack practice — today’s techniques are used on its machines and nowhere else.
Platform note: every HTB screen and attack scene in this chapter is a screen example. This book’s server cannot connect to HTB for verification, so the actual solving happens by your own hands.

Your first Medium machine is a wall. The Easy instinct — "one standard technique opens the entrance" — does not work here. The entrance is two layers deep, and even after you break in, the privilege escalation is twisted. Today’s goal is not solving fast. It’s solving it alone to the end, even if it takes days, and leaving the entire process in a progress log. This one machine raises your skill more than ten Easy machines.

1. Learning Objectives

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

Explain the structural differences between Easy and Medium (chains, misdirection, enumeration demands)
Run a multi-day attack with a daily hypothesis-verification cycle
Distinguish "technique shortage" from "enumeration shortage" when stuck, and prescribe differently for each
Run a research routine that looks up attack methods on HackTricks and similar sources by service name
Write a dated progress log that becomes the raw material for a later write-up and review

2. Background Knowledge — Today’s Tools and Concepts

Today’s Tools at a Glance

Category	Details
Language/environment	The same attack environment from Step 252 (Kali + HTB VPN)
Today’s commands	`nmap -sV -p-`, `nmap -sU --top-ports 100`, `gobuster vhost`, `ffuf -u ... -H "Host: FUZZ.target"` — the deep-enumeration set
Concepts needed	Vulnerability chains, the hypothesis-verification cycle, deep enumeration (UDP/vhosts/subdomains), the research routine
Today’s deliverable	One Medium machine rooted + a dated progress log + a retrospective timeline

2-1. How Are Easy and Medium Different — Difficulty Seen as Structure

The difficulty difference is not "harder techniques" but structure.

[Easy]   recon → 1 vulnerability → shell → 1 escalation technique → root
[Medium] recon (deeper) → info fragment A → door B that A unlocks → shell
         → twisted escalation path (the visible one is a trap, the real one is elsewhere)

The three differences look like this.

Chains: Medium doesn’t end with a single vulnerability. You pick up a credential fragment from a comment in the page source, use it to log into an admin page, find an upload vulnerability there, and from the shell the upload gives you, search again for an escalation path. You have to keep asking, "what door is this discovery the key to?"
Misdirection: sometimes the visible path is a trap. The obvious SUID binary is locked down, and the real path lies in a cron script’s permissions. Having your first hypothesis be wrong is Medium’s default.
Enumeration demands: on Easy, the entrance shows up in a basic scan; on Medium, the entrance commonly shows up only in second-stage enumeration (UDP, vhosts, a bigger wordlist).

2-2. Taking Days Is Normal

If you start Medium with hands that finished eight Easy machines at about an hour each, despair arrives on the first night. A log entry reading "found nothing" is normal.

Even skilled people spend hours on HTB’s Medium rating, and for someone new to this difficulty, three days is on the fast side. The reason it takes days is not lack of skill but the number of hypotheses — Easy has a handful of hypotheses to verify, while Medium spawns ten entrance candidates and you need time to discard nine of them.

That’s why this chapter’s unit of time is the "day," not the "box." Two to three hours a day: write down "today’s hypothesis" when you start, and write down the result when you close. Operating by stopping and resuming is itself the training.

2-3. Seventy Percent of Being Stuck Is Enumeration Shortage

When you’re stuck on a Medium, the cause is usually one of two things.

Enumeration shortage (the majority): the entrance is there — you just didn’t see it. You didn’t scan UDP ports, didn’t sweep vhosts, your wordlist was too small, or you skimmed past a comment in the page source. The prescription is "look deeper and wider."
Technique shortage (the minority): you saw the entrance but don’t know how to break it. A service you’ve never seen, a framework you’ve never seen. The prescription is research — find the HackTricks page by service name and version, and if there isn’t one, search "service name + pentest/exploit."

The test is simple. "Is there a fragment of information I’ve collected that I haven’t used yet?" If yes, it’s an enumeration problem; if every fragment has been used and you still don’t know the method, it’s a technique problem. Once you can make this distinction, being stuck turns from fog into a checklist.

2-4. The Progress Log — A Ship’s Log for a Multi-Day Attack

Across a multi-day attack, memory cannot be trusted. On day four, you won’t remember the grounds on which you judged "this port was a dead end" three days ago. So you write, dated.

### Day 1 (2.5h)
- Hypothesis: /admin on the port-80 web app is the entrance
- Did: full scan complete (22, 80), path scan with common.txt → /admin 403
- Learned: 403 means it exists — there must be another way in
- Tomorrow: bigger wordlist + vhost scan

### Day 2 (3h)
- Hypothesis: there's a dev subdomain among the vhosts
- Did: ffuf vhost fuzzing → found dev.target, API key exposed in the source
- Stuck: wandered 40 minutes over where to use the API key → found /api/docs
- Tomorrow: exhaustively check every endpoint the key authenticates to

This log does three jobs. It hands today’s context to tomorrow’s you (eliminating restart costs), it stops you from wasting effort on the same attempt twice, and once you’ve solved the machine it becomes the skeleton of your write-up.

3. Follow Along

3-1. Choosing the Machine — Criteria for a First Medium

There’s a separate class of "good first Mediums." The selection criteria are three.

□ Is the community rating good (stars and reviews on the machine page)
□ Are there reviews saying "the attack path is clear" (suited to hypothesis-verification practice)
□ Have many people solved it recently (community threads for questions are alive)

How to read it: pick the machine type from whichever side you were most confident on in Step 252. For your first Medium, the enemy should be difficulty, not unfamiliarity. This stage is designed so you learn only "depth," on familiar terrain (web-focused if you were web-focused).

3-2. Day 1 — Recon One Layer Deeper Than Easy

Day one’s goal is not intrusion but completeness of information gathering (screen example):

mkdir -p htb/first-medium && cd htb/first-medium
export TARGET=10.10.11.XXX
nmap -sV -p- $TARGET -oN 01_full_tcp.txt
nmap -sU --top-ports 100 $TARGET -oN 02_udp_top100.txt

How to read it: the difference from the Easy routine is the UDP scan line. On Medium, a UDP service like SNMP (161/udp) can be the entrance, so if you close up shop after TCP only, day one has no path forward. The habit of saving with -oN becomes a system in Step 268 — start today.

3-3. Day 1 Continued — If There’s a Web Port, Go to Second-Stage Enumeration

If a web port shows up, add two lines to what you did on Easy (screen example):

gobuster dir -u http://$TARGET -w /usr/share/wordlists/dirb/common.txt -x php,txt -oN 03_dirs.txt
gobuster vhost -u http://$TARGET -w /usr/share/seclists/Discovery/DNS/subdomains-top1million-5000.txt -oN 04_vhosts.txt

Then do the work only human eyes can do — view-source on every page, comments (), robots.txt, endpoints inside JS files. Medium’s clues often hide not in scanners but in source.

How to read it: a vhost scan finds virtual hosts by changing only the Host header on the same IP. It was rarely needed on Easy, but on Medium, "a different site on the same web server" is a common design for the entrance. Step 268 covers the concept more deeply with local measurements.

3-4. Days 2–3 — Running the Hypothesis-Verification Cycle

From day two on, you run the same format every day.

1. Read yesterday's log (5 min) — what has been confirmed as fact
2. Write one hypothesis for today — "X is probably the entrance, because Y"
3. Verify it — if true, move to the next step; if false, record the 'reason for discarding' in the log
4. If stuck, apply the 2-3 distinction — enumeration shortage or technique shortage
5. Before closing, write one line: 'tomorrow's first action'

If the verdict is technique shortage, you enter the research routine (screen example):

# the service/version is the starting point of the hypothesis
searchsploit "service-name version"
# browser: search the service name on book.hacktricks.xyz

How to read it: research has one rule — look not for "exploit code" but for "this service’s attack steps." A HackTricks service page is a list of "what to check first when you meet this service," which fits Medium research best.

3-5. After Root — The Timeline Retrospective

Getting the root flag is not the end but the start of the retrospective. Open the progress log and ask:

□ How many days to the entrance — and was that entrance already in day one's scans
□ How many hypotheses were discarded — was discarding fast or slow
□ What was the decisive clue for the breakthrough — was there a way to see it earlier
□ What blocked you during escalation — did you add that technique to your playbook

How to read it: the answers to this retrospective are the raw material for the next chapter (Step 266 review), and this machine’s learning value is decided right here. Root is a moment; the retrospective is what remains.

4. Missions & Exercises

Mission — Independently Solve One Medium Machine with a Progress Log

Select one Medium machine by the criteria in 3-1, and write the grounds for your selection on the log’s first line.
Spread the work over at least 3 days — write "today’s hypothesis" when you open the day and "tomorrow’s first action" when you close it.
Include a UDP scan and a vhost scan in recon, and save every scan’s output to a file.
Every time you get stuck, mark the 2-3 distinction (enumeration/technique) in the log and write the prescription you applied.
After reaching root, write a retrospective section at the end of the log answering 3-5’s four questions.

Rules: do not look at official write-ups or YouTube walkthroughs. Even when stuck, research (HackTricks, documentation, search) is the limit. If you did look at someone else’s solution, mark it in the log and make the machine a re-attack target in Step 266.

Exercises

Exercise 1. Explain why Medium is harder than Easy not in terms of "technique difficulty" but from the structural perspective (chains, misdirection, enumeration demands).

Exercise 2. Explain why "today’s hypothesis" should be written at the start of the day, along with the problems that arise when you run tools first without writing a hypothesis.

Exercise 3. State the criterion for dividing "stuck" into "enumeration shortage" and "technique shortage," and explain why the prescriptions differ.

Exercise 4. Explain why a progress log is especially important in a "multi-day attack," compared with a one-day attack.

5. Model Answers & Completion Criteria

Mission Model Answer

An example of the log’s shape (the content should be your actual solution):

Machine: (name) — Medium / reason for selection: top community rating, web-focused
Day 1: hypothesis "port 80 is the entrance" → TCP 22,80 + UDP scan complete. Path/vhost scans saved.
       Found: dev subdomain via vhost. Discarded hypothesis: /admin bypass (403 fixed).
Day 2: hypothesis "the dev site's API is the entrance" → extracted 3 endpoints from JS.
       Stuck 14:00-15:20 [enumeration shortage] → prescription: rescan with a bigger list → found /backup.
Day 3: hypothesis "credentials in a config file inside the backup archive" → hit. SSH entry (user).
       Escalation: sudo -l was a trap; root via write permission on a cron script. Total 7.5 hours.
Retrospective: the entrance (vhost) was in Day 1's scans but went unseen until the rescan → switching
      to a routine that finishes vhosts on day one. Added the cron-permissions technique to the playbook.

How to verify: ① the machine shows as complete (user+root) on your HTB profile. ② Does the log have "hypothesis / did / discard reason / tomorrow’s first action" for each date? ③ Is every stuck point tagged [enumeration/technique]? ④ Are the four retrospective questions answered? ⑤ Did you solve it without write-ups — if you looked, you marked it and will revisit it in Step 266.

Exercise Answers

Answer 1. On Easy, one vulnerability is the entrance and one standard technique finishes the escalation, but Medium is a chain structure where information fragments are each other’s keys, it has misdirection where the visible path is a trap, and the entrance itself hides in second-stage enumeration (UDP, vhosts, big wordlists). In other words, the source of difficulty is not "high-difficulty individual techniques" but "the amount of things to find and the number of connections." So the prescription is not learning harder techniques but deepening enumeration and managing hypotheses.

Answer 2. If you run tools without a hypothesis, you lose "what you were looking for" in an ocean of output — scans come back but no judgment forms, and you end up repeating the same attempts on different days. Write the hypothesis first and the day’s work becomes "verifying true/false," so even a false result leaves progress in the form of a discard. In a multi-day attack, "the list of discarded hypotheses" is itself the progress bar.

Answer 3. The criterion is "is there a fragment among the information I’ve collected that I haven’t used yet?" If yes, it’s enumeration shortage and the prescription is deeper and wider collection (rescans, enumeration from other angles). If every fragment is used and there’s still no method, it’s technique shortage and the prescription is research (looking up attack steps by service name + version). The prescriptions differ because the disease sits in a different place — if ingredients are missing, studying recipes won’t help; if the recipe is the problem, buying more ingredients won’t help.

Answer 4. In a one-day attack, context stays inside working memory, but in a multi-day attack, sleep and other life get in between and memory resets. Without a log, the next day begins with the restart cost of re-confirming "how far did I get," and you forget the grounds for judgments made three days ago, wasting effort re-verifying the same hypotheses. The log is an external memory device — in a multi-day attack, the log is not a byproduct but continuity itself.

Completion Criteria Checklist

[ ] I selected one Medium machine and wrote down the grounds for selection
[ ] I worked across at least 3 days, and every day has "today’s hypothesis" and "tomorrow’s first action" in the log
[ ] Recon included a UDP scan and a vhost scan, and the output files remain
[ ] Every stuck point has an [enumeration/technique] distinction and a prescription recorded
[ ] I reached root without a write-up (if I looked, I marked it and have a re-attack plan)
[ ] I answered the four retrospective questions
[ ] I added newly encountered techniques to my playbook

6. Common Pitfalls & Fixes

Wall 1. "I found nothing on day one — am I not good enough?"

Symptom: you started with the feel of eight cumulative Easy machines, spent an entire day, and ended with no progress.
Cause: the comparison target is wrong. Easy’s one-hour routine is not Medium’s yardstick — "didn’t find the entrance on day one" is Medium’s normal progress.
Fix: change the definition of progress. Count not "did I get closer to root" but "how many hypotheses were discarded today." Five discarded hypotheses are five units of progress. Remember that three days is on the fast side.

Wall 2. "I ran nmap -p- and still can’t see the entrance"

Symptom: the TCP full scan shows only 22 and 80, and the web shows no end in sight.
Cause: enumeration is trapped inside TCP. Medium’s entrance commonly hides in a UDP service, a vhost, or a deeper path.
Fix: run the second-stage enumeration checklist in order — UDP top-ports scan (-sU --top-ports 100), vhost fuzzing, a path rescan with a bigger wordlist, careful reading of JS and source. "I’ve done everything" is a sentence you may only use after all four are done.

Wall 3. "I searched, but nothing about my machine comes up"

Symptom: searching the service name returns only walkthroughs of that machine, no general material.
Cause: the query is aimed at the machine — put the machine name in the query and write-ups are all you get.
Fix: aim the query at the technique — "service name + version + pentest" or "framework name + exploit." Looking up the service name on HackTricks is the standard. The information enumeration gathered (banners, versions, page titles) is itself your keyword list.

Wall 4. "I found credentials, but they don’t work anywhere"

Symptom: the account/key you found in the source fails on SSH and on the web login alike.
Cause: either you haven’t tried every insertion point, or the credential is used in "a different form." An API key goes not in a login form but in a header, and a found password may pair with a different username.
Fix: the moment you find a credential, build a combination table of "every login point × every username" and try them all without gaps. And make it a habit to first ask which protocol the credential belongs to (form login? HTTP Basic? API header? SSH?) — this instinct is completed in Step 269’s chain attacks.

Wall 5. "It’s day four and my hands won’t move"

Symptom: you open the log and don’t know where to start; you want to power off the machine.
Cause: hypothesis exhaustion — when the hypotheses to verify run dry, so does motivation. This is not a skill problem but the absence of a hypothesis-production routine.
Fix: check whether the cause is a day you ended without "tomorrow’s first action," and use the fixed routine for hypothesis exhaustion — ① reread the entire log from the top, ② list the unused fragments among collected information, ③ build a combination table of each fragment × each attack surface. As you fill the table, the untried cells become hypotheses. If that still fails, taking a day off is also strategy — but leave the log open and read it with fresh eyes a few days later.

7. Summary

Today’s Concepts

Concept	One-line explanation
Vulnerability chain	Medium’s basic structure: information fragment A becomes the key to door B
Misdirection	A design where the visible path is a trap and the real path lies elsewhere
Hypothesis-verification cycle	Operating each day as "declare hypothesis → verify → discard/advance"
Enumeration vs. technique shortage	The two causes of being stuck — prescriptions differ: re-collection vs. research
Progress log	External memory of dated hypotheses, attempts, discard reasons, next actions
Research routine	The search habit of finding attack ‘steps’ by service name + version

Today’s Commands & Tools

Command	What it does
`nmap -sV -p- $TARGET -oN file`	TCP full scan + save to file
`nmap -sU --top-ports 100 $TARGET`	UDP top-ports scan (mandatory addition on Medium)
`gobuster vhost -u URL -w list`	Virtual-host fuzzing
`ffuf -u http://$TARGET -H "Host: FUZZ.target" -w list`	Another way to express vhost fuzzing
`searchsploit "service version"`	Search public exploits
HackTricks service pages	Look up attack steps per service

An Instinct More Important Than Commands

What Medium teaches is not techniques but how to handle time. If Easy was a one-hour sprint, Medium is a three-day march — that five discarded hypotheses at day’s end are progress, that a log handing context to tomorrow’s you is continuity, that most of being stuck comes not from not knowing but from not looking.

If you broke this one machine on your own strength, you now possess "an operating system that doesn’t break in front of a wall it’s never seen." In the next chapter, we look at this machine one more time — now that you’ve solved it, you’ve earned the right to compare how others solved it.

Once every box is checked, Step 265 is complete.