Step 306. The Thoroughness of Enumeration — The Reality of “Try Harder”

Step 306. The Thoroughness of Enumeration — The Reality of "Try Harder"

Level 4 — Expert | Difficulty ★★★☆☆ | Estimated time: 1–2 days

Prerequisites: you finished 2 practice machines and the report-draft drill in Step 305. You know basic nmap usage (the Step 96–117 range).

  • What you need: a practice machine account (HTB/PG), an attack machine, your three-line retrospectives from Step 305, and time for 2 new machines.
  • ⚠️ All exercises in this chapter are for your own lab and legal platforms only. Applying them to unauthorized systems is a crime.
  • Measurement guide: the nmap comparison output in this chapter is the result of actual execution against localhost in the writing environment (WSL Ubuntu, nmap 7.94SVN). The practice machine takedown screens are screen examples.

Misread OffSec’s motto "Try Harder" and you lose the exam. The phrase doesn’t mean "try more brute-forcely" — it means "enumerate more thoroughly." Most of why you get stuck on exam machines is not a missing new technique but missed enumeration — a port you didn’t see, a directory you didn’t scrape, a banner you didn’t read, a scan run at defaults. Today we turn "where do you go back to when stuck" into rules and a checklist, and we actually practice getting stuck. Not technique but the systemization of persistence — that is today’s topic.


1. Learning Objectives

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

  • Define the true meaning of "Try Harder" as "regression to enumeration"
  • Explain with measured data the difference between a full-port scan and a top-1000 scan
  • Build your own "when-stuck checklist" and apply it to real takedowns
  • Record blockages as "at what minute, which check unblocked it" to build a weakness map
  • Hold the balance point of persistence and efficiency with the 90-minute rule

2. Background Knowledge — Today’s Tools and Concepts

Today’s Tools at a Glance

Category Details
Language/environment Practice machines (HTB/PG) + attack machine — and today’s measurement is nmap on WSL
Today’s commands nmap -p-, sudo nmap -sU --top-ports 100, gobuster with a large wordlist, vhost checks
Concepts needed Enumeration regression, the checklist of thoroughness, the blockage log, the 90-minute rule
Today’s deliverable Your own "when-stuck checklist" (1 copy) + blockage-resolution log + 2 machines (4 cumulative)

2-1. The Reality of Try Harder — Not Technique but a Switch of Assumptions

When stuck, beginners and veterans make different assumptions.

✗ The beginner's assumption: "I need some new technique I don't know"
              → burns time hunting exploits on Google
○ The veteran's assumption: "I haven't fully looked at what I already have"
              → returns to the enumeration results to find what's missing

OSCP machines are designed from "techniques you already learned." Difficulty is tuned not by the novelty of technique but by how deeply information is hidden — a port sits on a non-standard number, the hint sits in a file comment, the directory appears only with the second wordlist. So the fix for a blockage is almost always regression to enumeration.

2-2. Measured — What the Top-1000 Scan Misses

We don’t just say it; we check it ourselves. Here is the measured result of scanning localhost two ways in the writing environment (WSL Ubuntu, nmap 7.94SVN).

Default scan (top 1000 ports only):

nmap 127.0.0.1
Nmap scan report for localhost (127.0.0.1)
Host is up (0.0000010s latency).
All 1000 scanned ports on localhost (127.0.0.1) are in ignored states.
Not shown: 1000 closed tcp ports (reset)

Nmap done: 1 IP address (1 host up) scanned in 0.06 seconds

It looks like "a machine with nothing." But the full-port scan:

nmap -p- --min-rate 10000 127.0.0.1
Nmap scan report for localhost (127.0.0.1)
Host is up (0.0000010s latency).
Not shown: 65534 closed tcp ports (reset)
PORT      STATE SERVICE
43463/tcp open  unknown

Nmap done: 1 IP address (1 host up) scanned in 0.32 seconds

An open service was found on 43463/tcp. The default scan looked at only 1000 ports and missed this port entirely. Most of the moments when "there’s nothing there" turned out wrong on an exam machine are exactly this — it isn’t absent; you didn’t look. If 0.32 seconds covers all 65,535, there’s no reason to settle for the top 1000.

2-3. The When-Stuck Checklist — The List of Places to Go Back To

The veteran’s "Try Harder" is actually executing a list. The basic skeleton:

□ Did I look at all TCP ports?        nmap -p- (did I only look at the top 1000?)
□ Did I look at top UDP ports?        sudo nmap -sU --top-ports 100
□ If web — did I check vhosts?  (connect by IP and by domain name separately)
□ If web — did I rescan directories with a bigger wordlist?
□ If web — did I fuzz parameters (/page.php?id=FUZZ)?
□ Did I take service banners all the way to "search"? (version → searchsploit → read)
□ Did I try discovered credentials on "every" service? (SSH/FTP/DB/web login)
□ Did I read found files "to the end"? (comments, backup files .bak/.old, config files)
□ If privilege escalation — did I read the recon automation tool's output to the end?
□ Ask the me of 30 minutes ago: what haven't I looked at?

What matters is that this list is not a fixture but a growing thing — every time a blockage is resolved, "the check that saved me" gets added to the list.

2-4. The 90-Minute Rule — The Right Amount of Persistence

Persistence also needs design.

Blockage occurs
  → 0–90 min: re-run the checklist "from the top," in order
  → at 90 min: look at "one step" of a hint only (no full walkthroughs)
  → if the hint solves it: record that point in the blockage log — "why did I stop there"
  → if solved without a hint: record "which check saved me" in the log

The moment you read a whole walkthrough, that machine loses its training value — there are no walkthroughs in the exam. On the other hand, burning 4 hours staring at the same screen is not training but torture. 90 minutes of full re-enumeration + a one-step hint is the optimum for the practice phase.


3. Follow Along

3-1. Building Your Own Checklist, First Edition

Copy 2-3’s skeleton into your personal wiki as when-stuck-checklist.md. Add "the enumerations that saved me" from your Step 305 retrospectives right away — for example, if a retrospective says "I checked the SMB version late," the list gains □ If SMB — did I do anonymous enumeration (enum4linux)?.

Keep the checklist to what fits on one screen (15–25 items). A 100-item list never gets executed.

3-2. Taking Down 2 New Machines — With the Difficulty Raised This Time

Pick 2 machines from the Step 304 list, late-Easy to early-Medium. One rule today:

"When no answer is in sight, don't look for a new tool — go back to the checklist."

Whenever you get stuck mid-attack, stop and run the checklist from the top. Mark immediately which item broke through (screen example):

[Blockage 1] 47 min — nothing in the web root
  → Check: found vhost unchecked. Added domain to /etc/hosts and connected
  → A different site opened. Resolved by: vhost check (6 min)

3-3. The Blockage-Resolution Log — Raw Material for the Weakness Map

Leave one entry per blockage per machine — the goal is 4+ log entries across the 2 machines.

## Blockage log — [machine name]
- Time: __ minutes after attack start
- Symptom: (what didn't work)
- The check that saved me: (which checklist item)
- Why I missed it: (the hole in my habits — e.g., "if web, vhosts first" wasn't there)
- Checklist revision: (items added/changed)

"Why I missed it" is the core — you must record the hole in your habits, not the technique, or you’ll fall into the same hole on the next machine.

3-4. Revising the Checklist and Continuing the Reports

When both machines are done, revise the checklist — move the checks that saved you upward, push never-used items downward. And continue the report drafts in Step 305’s format (4 cumulative).

The finished checklist is exam day’s emergency procedure manual. It is a document that will be polished across 30 machines between now and the exam, so a rough first edition is fine — a list that gets executed beats a perfect list.


4. Missions & Exercises

Mission — Complete and Apply the Checklist

  1. Build the first edition of your own checklist from 2-3’s skeleton plus your Step 305 retrospectives
  2. Take down 2 late-Easy to early-Medium machines, running the checklist from the top whenever stuck
  3. Leave 2+ blockage-resolution log entries per machine (4+ total) — including "why I missed it"
  4. Revise the checklist after the takedowns (reorder items + add new ones)
  5. Continue report drafts to reach 4 cumulative

Exercises

Exercise 1. Explain the concrete losses that arise from misreading "Try Harder" as "try more brute-forcely."

Exercise 2. In 2-2’s measurement, how did the default scan and full scan differ, and what does that mean in the exam?

Exercise 3. Why must the blockage log record not only "the check that saved me" but also "why I missed it"?

Exercise 4. From the perspective of training value, explain why the 90-minute rule allows looking at only "one step" of a hint rather than the "full walkthrough."


5. Model Answers & Completion Criteria

Mission Model Answer

An example of a well-written blockage log (the machine takedown portion is a screen example):

## Blockage log — Medium machine A
- Time: 63 minutes after attack start
- Symptom: only web :80 open; directory scan with the default wordlist came up empty.
- The check that saved me: checklist item 4, "rescan with a bigger wordlist"
  → directory-list-2.3-medium.txt found /backup → config copy → DB credentials
- Why I missed it: the habit of finalizing the first scan's result as "nothing there."
  A scan only sees "as much as the wordlist," yet I absolutized the result.
- Checklist revision: added a caution to item 4 — "a negative from the default
  wordlist means 'not in this list,' not 'doesn't exist.'"

How to verify: ① does the checklist file exist, within 15–25 items? ② do all 4 log entries have "why I missed it" — without it, they’re technical memos, not training logs. ③ did the checklist change between before and after revision (traces of growth)? ④ does each log’s "check that saved me" point to an actual checklist item? ⑤ are the 4 cumulative report drafts organized in the same format?

Exercise Answers

Answer 1. Three losses arise. First, time allocation breaks — random exploit attempts spend 30 minutes each while skipping the 5-minute re-enumeration that would have worked. Second, logs get contaminated — sprayed attack traces can lock services (account lockouts, crashes) or make the original state unknowable. Third, no training happens — a "got lucky" experience can’t be reproduced, so it doesn’t transfer to the next machine. Since an exam machine’s difficulty lies in hiding, not technique, random attempts are a misreading of the problem itself.

Answer 2. In the measurement, the default scan (top 1000) reported not a single open port — "All 1000 scanned ports … are in ignored states" — while the full scan (-p-) found an open service on 43463/tcp. In the exam, this means the misjudgment "this machine has no attack surface" becomes the direct cause of zero points. In an environment where scanning all 65,535 takes under a second, settling for the top 1000 is not a choice but a mistake.

Answer 3. Because "the check that saved me" is the answer for that one machine, but "why I missed it" is the answer for every next machine. For example, "I didn’t find /backup" is a fact; "the habit of absolutizing a default-wordlist negative" is me, the thing to fix. Only logs with the latter lead to checklist revisions, and the accumulation of those revisions becomes exam-day speed.

Answer 4. Reading a whole walkthrough turns every remaining step into "copying after seeing the answer," destroying the machine’s training value — the foothold and escalation phases after the blockage no longer count as practice. A one-step hint, by contrast, tells you only "what you missed in enumeration"; everything after remains yours to solve, so the machine’s remaining training value stays alive. And forcing 90 minutes of full re-enumeration first gives your checklist one chance to break through before you reach for a hint.

Completion Criteria Checklist

  • [ ] I can explain "Try Harder = regression to enumeration" in my own words
  • [ ] I can explain the difference between nmap -p- and a default scan with a measured example
  • [ ] I made the first edition of my own checklist (15–25 items)
  • [ ] When stuck, I practiced returning to the checklist instead of reaching for new tools
  • [ ] I left 4+ blockage-resolution log entries including "why I missed it"
  • [ ] I actually revised the checklist after the takedowns
  • [ ] Mission: 2 machines solved + 4 cumulative report drafts complete

6. Common Pitfalls & Fixes

Wall 1. Skipping the full scan because it’s "slow"

Symptom: you run only the default scan and conclude "only 3 ports open."
Cause: you benchmarked against the speed of an old memory.
Fix: 2-2’s measurement is the answer — the full scan of localhost took 0.32 seconds. Even on practice machines across a network, tuning --min-rate finishes in a few minutes. Looking at 1000 of 65,535 with the excuse of "slow" is gambling on every machine in the exam.

Wall 2. Never looking at UDP, ever

Symptom: the habit of scanning only TCP has hardened.
Cause: UDP scans are slow and bothersome.
Fix: not all ports, just the top 100 — sudo nmap -sU --top-ports 100 target. Machines where a UDP service like SNMP (161) is the door to initial credentials really exist. Pin the UDP-100 scan as checklist item 2.

Wall 3. Retrying "the thing that doesn’t work" over and over

Symptom: you run the same exploit a tenth time with different options.
Cause: you chose repeated attempts instead of enumeration regression — this is the precise misuse of Try Harder.
Fix: set a rule — "the same attempt at most twice; from the third, back to the checklist." Ten minutes × ten retries costs more than one pass of the checklist (usually 30 minutes).

Wall 4. The checklist grew too big to execute

Symptom: items passed 50 and you can’t get through them when stuck.
Cause: you only added and never pruned.
Fix: hold a cleanup day every 3–4 machines — move recently unused items down to an "archive" section and keep the executable part within 25. The checklist is not an encyclopedia; it’s an emergency procedure manual.

Wall 5. Can’t hold out 90 minutes and open the walkthrough

Symptom: you search 20 minutes after getting stuck, and copy from then on.
Cause: anxiety — "everyone else is solving it."
Fix: keep the blockage log open in advance — with a place to record, a blockage stops being "failure" and becomes "data being collected." And when you do look at a hint, scroll only to the very next step. The exam day’s 24 hours are made of these 90 minutes.


7. Summary

Today’s Concepts

Concept One-line explanation
The reality of Try Harder Not "brute-force attempts" but "thorough enumeration" — a switch of assumptions
Enumeration regression Stuck = need new technique (✗), unexamined information exists (✓) → return to the checklist
Full-port scan The top 1000 is only a sample — all 65,535 with -p-
Blockage-resolution log Time, symptom, the check that saved me, why I missed it — raw material for the weakness map
90-minute rule 90 min full re-enumeration → one-step hint → record in log
The checklist grows A living document polished until exam day by adding and reordering the checks that saved you

Today’s Commands & Tools

Command Use
nmap -p- --min-rate 10000 target Full TCP port scan — the only proof of "nothing there"
sudo nmap -sU --top-ports 100 target UDP top 100 — hidden doors like SNMP
gobuster + a large wordlist Distinguishing "not in this list" from "doesn’t exist"
vhost check (register in /etc/hosts, then connect) Whether the IP and the name point to different sites
searchsploit service version Banner → connection to known vulnerabilities
when-stuck-checklist.md The emergency procedure manual you made today — a document that travels with you to the exam

The Core Instinct

The OSCP’s wall is not a wall of technique but a wall of vision. The answer is already printed somewhere on the screen; while you can’t solve it, you simply haven’t looked at that output yet. So this exam’s persistence is not a matter of willpower but of procedure — if there’s a list to go back to, a place to record, and a set time to stop, persistence becomes not a personality trait but a system. Today you built that system’s first edition.


Once every box is checked, Step 306 is complete.