Step 257. HTB Easy x2 (Cumulative 4) — Widening Your Repertoire of Entry Points

Level 3 — Real-World CTF & Advanced Offensive Skills | Difficulty ★★★★☆ | Estimated time: 8+ hours (about 4 hours per machine)

Prerequisites: Step 256 (solving 2 Easy machines independently) — you already have the routine document, the privesc pattern notes, and the machine-log habit.

• What you need: Your HTB environment from Step 256, your two machine logs, your "Easy patterns" summary, and a playbook (the evolved form of your routine document).
• ⚠️ All exercises in this chapter are for your own lab and legal platforms only. Applying them to unauthorized systems is a crime. Hack The Box (hackthebox.com) is a legal learning platform officially opened by its operators for attack practice — do not use today’s techniques on anything outside this platform’s machines.
• Platform note: Every HTB screen and command output in this chapter is a Screen example. You do the actual solving yourself.

You’ve cracked two machines on your own, so by now you have "an entry point I’m good at." And that is today’s problem. People repeat the paths that worked — someone who got in through the web looks at the web first next time too. But each machine’s entry point differs (web vulnerability, anonymous FTP, SMB shares, default credentials, kernel bugs…), and if your repertoire covers only one kind, you freeze in front of machines whose entry point doesn’t match.

Today’s assignment is not the number "cumulative 4" — it’s diversifying the types. Deliberately pick machines with entry points you haven’t tried yet, and accumulate that experience in a table. Once four machines come together, the pattern finally starts to look like statistics.

1. Learning Objectives

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

• Classify initial access vectors (entry points) by type and diagnose the skew in your own experience
• Intentionally select machines of types different from what you’ve done so far
• Compare your time-to-user shell against previous machines to quantify your growth
• Cement the habit of immediately adding newly encountered services and techniques to your playbook
• Build an "entry-point type × discovery method" table and finish turning 4 cumulative machines into an asset

2. Background Knowledge — Today’s Tools and Concepts

Today’s Tools at a Glance

2-1. A Map of Entry-Point Types

The initial access vectors of HTB Easy machines fall roughly into six branches.

① Web vulnerabilities   — upload bypass, injection, known CMS/framework flaws
② Anonymous services    — FTP anonymous, anonymous SMB, unauthenticated DBs
③ Default/weak credentials — default accounts, reused passwords, brute force
④ Information exposure  — source code, backup files, comments, secrets in git repos
⑤ Public exploits       — known CVEs used as-is (the version is the answer)
⑥ Misconfigurations     — writable shares, wrong permissions, predictable paths

Each type demands a different skill. ① needs depth in web enumeration, ②③ need per-service checking routines, ④ needs thoroughness, ⑤ needs version matching and exploit-fixing ability, ⑥ needs system understanding. Being good at one type alone won’t cover this map.

2-2. Skew Diagnosis — Where Am I Lopsided Right Now?

The first step of expanding your repertoire is assessing the current state. Open your Starting Point notes from Step 255 and your two logs from Step 256, and tag each machine’s entry point using the classification from 2-1.

Example (Screen example):
Starting Point machines — mostly ② anonymous services, ③ default credentials
Easy #1 — ① web (upload bypass)
Easy #2 — ① web (CMS vulnerability)
→ Diagnosis: skewed toward ①. No experience with ④⑤⑥

This diagnosis is today’s machine-selection criterion — pick "Easy machines likely to have untried types." Knowing a machine’s entry point in advance is a spoiler, so perfect selection is impossible. Instead, guess from the community’s unofficial tags (web-heavy, AD, misc) or the machine’s description, and if it turns out to overlap with a type you’ve done, record that too.

2-3. The Playbook — The Next Stage of the Routine Document

The routine document you started in Step 251 gets promoted here into a playbook. The difference is moving from "a sequence of commands" to "a situation-by-situation response table."

## Example playbook entries
- Port 21 (ftp) found → try anonymous login → if it works, list everything → get
- Port 445 (smb) found → smbclient -L -N → shares without $ → recurse on; mget *
- Web on 80 found → path scan (small list) → check /robots.txt, /.git, backup extensions → rescan with big list
- Version string found → searchsploit → cross-check the original on exploit-db → note any fixes needed

Every time you meet a new technique, add it as a single entry in the form "what signal → what command." The time you spent searching inside one machine disappears in the next — that is the playbook’s value.

2-4. Quantifying Growth — Time to User

Look at "am I getting better?" as a number, not a feeling. The reference metric is time to user shell — since difficulty varies per machine, the trend matters more than the absolute value.

Example records (Screen example):
Easy #1: user in 3h 20m, root +35m
Easy #2: user in 2h 05m, root +1h 10m
Easy #3: user in 1h 40m, root +40m

Is the time shrinking — and if so, in which phase did it shrink (did recon get faster, was your first hypothesis right)? Reading that far is the real analysis. This data becomes the baseline for the time-limit training in Step 258.

2-5. "Back to Enumeration" — The Universal Return Point for Every Type

Whatever the type, the cure for being stuck converges on one thing: the answer is usually already in your enumeration results. When you’re flustered on a new type of machine — "I’ve never seen this service" — the order is:

1. Search for the service's basic enumeration commands (5 minutes)
2. Check whether your playbook has an entry; if not, write one
3. Still nothing? Return to recon — missed ports, deeper path scans
4. A "new service" is not actually new — enumerating and reading works the same

3. Follow Along

Today, section 3 is again procedure. All screens are examples.

3-1. Selecting Machines — Skew Diagnosis First

Write the 2-2 diagnosis at the top of your log before you start (example):

# Step 257 kickoff — 2026-09-11
## Skew diagnosis
- Entry points so far: ① web x2, ② anonymous x1, ③ default credentials x1
- Untried: ④ information exposure, ⑤ public exploit (version→CVE), ⑥ misconfiguration
- Goal for these 2 machines: machines likely to be type ④ or ⑤
## OS diversification: #3 as a Windows Easy (testing the Step 254 routine)

Alternating Linux and Windows is another axis of type diversification. It’s a chance to check whether the Windows routine you built in Step 254 works on a real Easy machine.

3-2. The 15 Minutes When You Meet a New Service

When an unfamiliar service shows up on an open port, give it a 15-minute procedure before searching (Screen example):

nmap -sV -p- $TARGET -oN nmap-full.txt

PORT     STATE SERVICE VERSION
21/tcp   open  ftp     ProFTPD 1.3.5
22/tcp   open  ssh     OpenSSH 7.2p2 Ubuntu
80/tcp   open  http    Apache httpd 2.4.18

How to read it: Suppose you’ve never seen ProFTPD before. The 15-minute procedure: ① search the service name + version verbatim (5 min), ② if known vulnerabilities exist, check a trustworthy original source (exploit-db, NVD) (5 min), ③ draft a playbook entry (5 min). If there’s still no answer after these 15 minutes, demote this path and move to another port — the 30-minute rule applies to new services too.

3-3. First-Try Order by Type — An Example of a Non-Web Machine

Here’s the early flow of a machine whose entry point is on the SMB side (Screen example):

smbclient -L //$TARGET -N

	Sharename       Type      Comment
	---------       ----      -------
	backups         Disk
	IPC$            IPC       Remote IPC

smbclient //$TARGET/backups -N -c 'recurse on; ls'

  config.old.bak                 A     2048  ...
  notes.txt                      A      312  ...

How to read it: Backup files and notes inside an anonymously readable share — this is the classic overlap of ② (anonymous service) and ④ (information exposure). A file like config.old.bak means your next move is to download it and read it carefully. Unlike a web machine, the rhythm is not "scan → immediate vulnerability" but "enumerate → read documents → combine clues."

3-4. Two Lines to Add to Your Machine Log

Starting today, two lines are added to the log format from Step 256.

## Complete
- user: 1h 40m (entry-point type: ④ information exposure — bak file in smb share)
- root: +40m (pattern: kernel version → public exploit)
- Hints used: none
- Entry-point type tag: ④           ← addition 1: classification number
- Playbook addition: entry for reading smb share backup files first  ← addition 2: this round's asset

A round’s learning only closes when you’ve written down "which playbook entry this machine’s lesson settled into."

3-5. Cumulative 4 — Completing the Entry-Point Type Table

When you finish both machines, complete the table that is today’s centerpiece (example):

## Entry-point type × discovery method (cumulative 4 + Starting Point)
| Machine | OS | Entry-point type | Discovery method | Time to user |
|------|-----|-----------|-----------|----------|
| Easy #1 | Linux | ① web (upload) | gobuster path scan | 3h 20m |
| Easy #2 | Linux | ① web (CMS) | version search → exploit-db | 2h 05m |
| Easy #3 | Windows | ② anonymous SMB | smbclient -N | 1h 50m |
| Easy #4 | Linux | ④ info exposure | credentials in a backup file | 1h 40m |

## What the table shows
- Time to user shrank from 3h 20m → 1h 40m — the effect of a fixed recon routine
- The ① skew started resolving. ⑤⑥ still untried → the goal for the next 2 (Step 258)

How to read it: This table shows two things — what you know how to do (the types you’ve experienced), and a growth curve measured in time. The empty cells (⑤⑥) are not a shame; they are the list of your next assignments.

4. Missions & Exercises

Mission — Cumulative 4 and the Entry-Point Type Table

1. Write your skew diagnosis, then select 2 Easy machines likely to have untried types (change the OS for one of them too)
2. Solve the 2 machines under Step 256’s rules exactly (independent solving, logs, the 30-minute rule)
3. Tag each machine’s entry point with the 2-1 classification and record it in the log
4. Compare time to user shell against previous machines and write down the trend
5. Immediately add newly encountered services and techniques as playbook entries
6. Complete the "entry-point type × discovery method" table from 3-5, and write at least three lines about what the table shows

Exercises

Q1. Explain the rationale for the strategy "even among Easy machines, choose varied types" in terms of the danger of repertoire skew.

Q2. Write out the three steps of the 15-minute procedure for an unfamiliar service, and explain why it stops at 15 minutes by connecting it to the 30-minute rule.

Q3. Explain why, when using "time to user" as a growth metric, you should look at the trend rather than absolute values.

Q4. Explain the difference between the routine document (Step 251) and the playbook using the expressions "a sequence of commands" and "a situation-by-situation response table."

## Playbook additions (Step 257)
- [SMB] Found a share without $ → recurse on; ls → prioritize get on .bak/.old/notes files → read carefully
- [Windows Easy] If 445+3389 combination, try anonymous SMB first; if it fails, check web/other ports
- [Time recording] Always log the time user was reached in the completion section — baseline data for Step 258

6. Common Pitfalls & Fixes

Wall 1. The machine I picked turned out to be the same type after all

Symptom: You picked one thinking "this time it’ll be different," but it was a web vulnerability again.
Cause: You can’t know a machine’s entry point exactly without spoilers — selection is only ever a guess.
Fix: It’s not a failure; it’s data. Record it in the log as "intended: ④, actual: ①." Even with an overlapping type, if the detailed technique within it differs (upload bypass vs. injection), your repertoire widened. Perfect diversification is achieved by stacking rounds — do the final check on the cumulative-6 table including Step 258.

Wall 2. I picked a Windows machine but my Linux habits come out

Symptom: You got a shell and typed ls -la, cat /etc/passwd.
Cause: Dozens of machines’ worth of Linux muscle covers Windows. It’s normal, and today is correction training.
Fix: Paste the Windows routine from Step 254 onto the first page of your log — first command after the shell is whoami /priv, file finding is dir /s-family, processes are Get-Process. Struggle for a few days and your hands will change. And that struggle itself is worth recording — if you log "time spent switching to Windows," it shows up as a variable in Step 258’s time analysis.

Wall 3. Researching a new service ate two hours

Symptom: Chasing an unfamiliar service’s vulnerability, your recon never ended.
Cause: You mixed "research" and "verification" together without the 15-minute procedure.
Fix: Set a physical timer — a 15-minute phone alarm. When research time ends, write in one sentence "is this path alive?"; if alive, verification phase (with its own 30-minute rule), otherwise demote it. A path where search results are documents only and reproduction fails is unlikely to be an Easy machine’s answer — authors design problems inside standard techniques (Step 256).

Wall 4. The time comparison became pressure instead

Symptom: The thought "I’m slower than last time" makes you impatient and tempted to skip recon.
Cause: You misunderstood the metric’s purpose. The time trend is not grading — it’s a diagnostic tool.
Fix: Read the slow round’s log more closely — which phase slowed down? If recon was slow, it’s a tooling problem (wordlists, bandwidth); if hypothesis was slow, it’s a prioritization problem; if escalation was slow, it’s a pattern-notes problem. "Getting faster" is a result, not a goal — the goal is an accurate routine, and speed is its byproduct. Training that targets speed is done separately, in controlled form, in Step 258.

Wall 5. The playbook is becoming a copy-paste collection

Symptom: Entries keep growing, but you stop opening it inside machines.
Cause: The entries aren’t written "in the form I experienced" — if you transplant someone else’s text wholesale, it can’t be searched.
Fix: Enforce the entry format — one or two lines of [signal] → [command] → [next action]. Push long explanations out as a one-line link. And when a round ends, mark "the entries I actually opened this round" — an entry that never gets opened has the wrong form, so refine it before the next round. The playbook is not a document but a tool, and a tool has value only when used.

7. Summary

Today’s Concepts

Today’s Commands & Tools

The Instinct That Matters More Than Commands

Some things only become visible once four machines come together — "the entry point opens to whoever finished enumerating," "time is lost not in recon but in hesitation," "a new service is scary but the procedure is always the same." These sentences don’t come from reading; the four lines accumulated in your table say them. That is why today’s real deliverable is not flags but that table. If holes in the types (⑤⑥) remain, that’s good news — in the next chapter’s time-limit training, you’ll find out what those holes cost you, this time while watching the clock.

Once every box is checked, Step 257 is complete.