Step 276. Speed Training: Easy in Under 4 Hours — Push Your Routine to Autopilot

Level 3 — Real-World CTF & Advanced Offensive Skills | Difficulty ★★★☆☆ | Estimated time: 1 day (4-hour time attack + 1 hour of analysis)

Prerequisites: Step 130’s time-attack budget table and 30-minute rule, the live-machine routine from Step 251 onward, Python 3 (for the lap-time analyzer).

What you need: one never-before-seen HTB or THM Easy machine, a timer, a lap-time log file, and Python 3. The machine assault scenes in this chapter are screen examples; the Python lap-time analyzer runs are marked as measured (2026-09-09, Python 3.12).
⚠️ 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) and TryHackMe are legal learning platforms officially opened by their operators for attack practice — do not use today’s techniques on anything except these platforms’ machines.
This is a training methodology chapter. Today you measure and shave not new techniques but "the speed of your existing routine."

What separates the top ranks in a competition is not the person who solves Hard — it’s the person who clears Easy fast. A team that spends 8 hours on an Easy-tier problem has no time to even look at the hard ones. Today’s goal is to raise the recon → foothold → privesc routine you’ve built so far to a level where it comes out without thinking, and finish an Easy within 4 hours.

But the enemy in speed training is not slowness — it’s haste. Fast without skipping — the answer to that balance lies in parallelization. The person who fills waiting time with other investigation is fast without skipping anything.

1. Learning Objectives

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

Build and keep a stage-by-stage budget table for a 4-hour Easy time attack
Parallelize investigation while running wait-heavy work like scans and brute-forcing in the background
Build a template path that pulls reverse-shell and privilege-escalation commands from the playbook instantly
Record stage-by-stage timestamps and confirm bottlenecks in numbers with the lap-time analyzer
Set the baseline for "when to give up and read the write-up"

2. Background Knowledge — Today’s Tools and Concepts

Today’s Tools at a Glance

Category	Details
Language/environment	HTB/THM Easy machine, Kali or WSL, timer, Python 3 (lap-time analyzer)
Today’s commands	All review — `nmap` (fast scan + full scan in parallel), `gobuster`, reverse-shell/privesc templates
Concepts needed	Parallelization, stage-by-stage time budgets, bottlenecks, the bail-out baseline
Today’s deliverable	Lap-time log + bottleneck analysis results (budget-vs-actual deviation table)

2-1. The 4-Hour Budget Table — Easy’s Time Map

The base allocation for an Easy 4-hour run. It’s Step 130’s 6-hour budget table compressed for Easy.

Stage	Budget	Goal	Exit signal
① Recon/enumeration	0:00–0:30	Attack surface + candidate vulnerability list	Candidate list complete (full scan need NOT be done)
② Foothold	0:30–2:30	First shell	`whoami` output
③ Privesc	2 hours within 2:30–4:00	root/SYSTEM	uid=0 in `id`
④ Write-up	Last 30 min	A reproducible log	Lap-time log complete
Slack	30 min	Absorb overruns	—

The most common cause of blowing past 4 hours on Easy is ① exceeding an hour. Recon runs long not because scans are slow but because you do nothing while waiting for the scans.

2-2. Parallelization — Turn Waiting Time into Investigation Time

Speed training’s technique is really just one thing. Don’t wait.

Time 0:00
 ├─ Terminal 1: nmap -sV target          (1–2 min, read this first)
 ├─ Terminal 2: nmap -p- target -oN full.txt   (slow → background)
 └─ Terminal 3: if a web port shows, start gobuster immediately (slow → background)

From 0:03 on: read Terminal 1's results while manually exploring the web
 — Terminals 2 and 3 keep working while you're making judgments

A structure where machines enumerate while humans judge — this is the whole of "speed without skipping." Conversely, 10 minutes spent blankly waiting for gobuster to finish is not a skill issue but a scheduling failure.

2-3. The Template Path — Hands Before Brain

Easy’s reverse shells and privesc enumeration are things you already know. The reason known things come out slowly is time spent searching. Before speed training, organize the playbook’s "instant copy-paste section."

Playbook instant copy-paste section (example table of contents):
- 3 reverse shells: bash, python3, php — paired with the listener command
- Shell stabilization: python3 -c 'import pty;pty.spawn("/bin/bash")' + the stty bundle
- One block of privesc enumeration: the whoami&&id&&... sequence from Step 130
- Web basics: standard gobuster/dirsearch commands, wordlist paths

The standard is the 10-second rule — if you can’t paste the command you need into a terminal within 10 seconds, your template organization is incomplete.

2-4. The Bail-Out Baseline — Reading the Write-up Is Also Strategy

In speed training, the write-up is not forbidden — it’s a tool allowed only under conditions set in advance. Example baselines:

The foothold stage (2 hours) fully overrun with zero new hypotheses → hint-level reading allowed (direction only)
No progress within 30 minutes after the hint → read only the write-up paragraph for that stage
However, record the fact and time of any reading in the log — "4 hours solo" and "4 hours with the write-up" are different scores

Reading "whenever stuck" with no baseline collapses the training; never reading at all wastes time. Set the baseline before you start — a stuck brain cannot be a fair judge.

3. Follow Along

3-1. Before Starting — Machine Selection and Budget Setup

Pick an Easy machine you’ve never seen — you can’t measure speed on a machine you know. Create the lap-time log file.

Input (the laps.txt format — add one line each time a stage ends):

recon | 0:00

Why this format: two boxes — "stage | elapsed time" — are enough. Rather than breaking your flow filling an elaborate table mid-assault, a format where one line takes 5 seconds survives. Post-run analysis is the script’s job (3-4).

3-2. The Recon Stage — Three Terminals Running at Once

Screen example (the screen at 5 minutes into recon — verify it yourself on your own machine):

# Terminal 1 (started 0:00, finished 0:02)
$ nmap -sV 10.10.11.50
PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 8.9p1 Ubuntu
80/tcp open  http    nginx 1.18.0

# Terminal 2 (started 0:00, still running in background)
$ nmap -p- 10.10.11.50 --min-rate 2000 -oN full.txt

# Terminal 3 (started 0:02, still running in background)
$ gobuster dir -u http://10.10.11.50 -w /usr/share/wordlists/dirb/common.txt

How to read it: in 2 minutes the outline "web and SSH" is up, and from now on, while you comb the website by hand, the full scan and directory enumeration run behind you. If the candidate list stands at 0:30, this stage is a success.

3-3. Foothold & Privesc — The Template Path in the Field

Try candidates in version-match order (Step 130’s criterion), but every command must come from the instant copy-paste section. Spending time on judgment, not typing, is this training’s normal state.

Screen example (the lap-time log filling up):

recon | 0:00
recon | 0:35
foothold | 2:50      ← whoami: www-data secured
privesc | 3:40       ← id: uid=0(root)
notes | 4:25

How to read it: each line is "the elapsed time at which that stage ended." These five lines are today’s entire report card — more than whether you got root, these numbers are what the training targets.

3-4. After Finishing — Confirming Bottlenecks with the Lap-Time Analyzer

Feed the log to the analyzer and look at budget-vs-actual deviations.

Input (the core of tmp_test/lap_budget.py):

BUDGET = {"recon": 30, "foothold": 120, "privesc": 120, "notes": 30}  # minutes, Easy 4-hour basis

for name, end in laps[1:]:
    actual = end - prev
    budget = BUDGET.get(name, 0)
    diff = actual - budget
    verdict = "over budget — record the cause" if diff > 0 else "within budget"

Output (measured 2026-09-09, with 3-3’s example log as input, Python 3.12):

Stage      Budget   Actual    Diff   Verdict
--------------------------------------------
recon        30min    35min    +5min  over budget — record the cause
foothold    120min   135min   +15min  over budget — record the cause
privesc     120min    50min   -70min  within budget
notes        30min    45min   +15min  over budget — record the cause
--------------------------------------------
Total 265min (4h 25m) / target 240min

How to read it: the identity of the 25-minute overrun is visible in numbers — you saved 70 minutes on privesc but leaked on foothold and notes. The next training’s assignment is not "faster overall" but exactly two things: "foothold +15 min" and "notes +15 min." Once a bottleneck has a name, it can be prescribed for.

Why: "failed the sub-4-hour cut" is an emotion, but "+25 min, 2 causes" is a plan. For repetitions of speed training to accumulate as skill, every run must end with this table.

4. Missions & Exercises

Mission — Easy 4-Hour Time Attack and Bottleneck Analysis

Pick a never-before-seen Easy machine, set a 4-hour timer, and record the start in laps.txt.
Parallelize recon — note explicitly in the log that fast scan / full scan / directory enumeration ran concurrently.
Organize the playbook’s instant copy-paste section, and self-check whether you kept the 10-second rule during the assault.
Write the bail-out baseline (2-4) as sentences before starting; if you read the write-up, record the time and scope.
After finishing, produce stage-by-stage deviations with the lap-time analyzer, and attach a one-line cause to every overrun stage.

Exercises

Exercise 1. Why is parallelization called "speed without skipping"? How is it different from haste?

Exercise 2. In the 3-4 measurement, privesc came in 70 minutes under budget yet the total target was still exceeded. Explain why this result means something different from "speed training failure."

Exercise 3. Why is the completion criterion for the instant copy-paste section set as the "10-second rule"?

Exercise 4. Why must the write-up-reading baseline be set before starting, not after getting stuck?

5. Model Answers & Completion Criteria

Mission Model Answer

Root within 4 hours is the ideal, but grading is process-based.

Traces of parallelization: are 2+ concurrently running tasks noted in the log?
The 10-second rule: was the instant copy-paste section actually used? If you found commands by "searching" mid-assault, record it as template-incomplete.
Lap-time completeness: are all five lines (start + 4 stages) present? Speed without records can’t be measured, so it doesn’t become training.
Named bottlenecks: does every overrun stage carry a one-line cause — at the level of "foothold +15 min: tried 3 exploits in no order"?
Baseline compliance: if the write-up was read, are time and scope recorded, and was it within the baseline written before starting?

Exercise Answers

Answer 1. Because parallelization removes only waiting time without omitting any procedure. Not running the full scan is haste (throwing away information), but combing the web by hand while the full scan runs is parallelization (getting the same information faster). The product of both — the candidate list — is identical; only the time taken differs. What must be shaved in speed training is not procedure but waiting.

Answer 2. Because the total overrun (+25 min) was decomposed into two concrete causes. "Failure" is a stagnant state with unknown causes, but this table tells you the next training’s assignment is two items: "foothold +15 min, notes +15 min." The -70 on privesc was confirmed as a strength already attached to your body, so it needs no touching. Training success is judged not by hitting the target but by confirming the next assignment.

Answer 3. Because the moment you pass 10 seconds, the act of searching itself becomes a new immersion that breaks the assault’s flow. Searching for a command leads to reading docs, and reading docs evaporates the thread of the hypothesis you were judging. And 10 seconds is a measurable criterion — self-assessments like "I can find it quickly" are easily overestimated, so a numbered criterion is needed to grade whether template organization is complete.

Answer 4. Because a stuck brain is not a fair judge. Right after burning 2 hours, the judgment "just one little hint" seeps in as rationalization — without a baseline, the reading threshold drops every time with the intensity of the stall. A baseline set before starting is a rule handed down by calm you to stuck you. And the duty to record (time and scope) is what distinguishes "4 hours solved solo" from "4 hours accompanied" on the report card.

Completion Criteria Checklist

[ ] I built the Easy 4-hour budget table (stages, exit signals) before starting
[ ] I ran the recon stage three or more ways in parallel
[ ] I organized the playbook’s instant copy-paste section and checked the 10-second rule
[ ] I wrote the bail-out baseline as sentences before starting
[ ] I completed the five-line lap-time log
[ ] I produced stage-by-stage deviations with the lap-time analyzer
[ ] I recorded a one-line cause for every overrun stage

6. Common Pitfalls & Fixes

Wall 1. The full scan never finishes and the recon stage ends

Symptom: the -p- scan runs past 30 minutes.

Cause: more than scan speed itself, it’s a design error of setting the exit condition as "full scan complete."

Fix: the recon stage’s exit signal is "candidate vulnerability list complete" (the 2-1 table). Start enumerating from the fast scan’s results and let the full scan run behind you. Opening full.txt midway through the foothold stage to check just once for missed ports is enough — that check is insurance against late-stage wandering. Also fix speed options like --min-rate into your playbook.

Wall 2. I parallelized everything and now I can’t tell which terminal is what

Symptom: five terminals are open and you don’t know what’s finished.

Cause: the parallelization had no name tags. You increased the count without the management.

Fix: title every terminal (tmux window names, tab names), or write all output to files — like -oN full.txt. And 3 parallel tasks is the cap. Beyond that, management cost eats the savings. If you can’t answer instantly "what am I waiting for right now?", it’s not parallelization; it’s scatter.

Wall 3. The lap-time analyzer spits out wrong numbers

Symptom (measured 2026-09-09):

ValueError: invalid literal for int() with base 10: '4h'

Cause: the time box in the log contains text like 4h 25m instead of 4:25. The analyzer reads only the h:mm format.

Fix: log formats are machine-read first — write h:mm only. Make a habit of moving mid-run memos ("lunch here") to a separate line or the end of the log rather than the same line, and the log won’t break in any analysis script.

Wall 4. Rushing makes me keep losing shells

Symptom: the reverse shell connects and drops; the web shell dies without responding. The more you hurry, the more silly mistakes pile up.

Cause: you’re getting speed from your fingers. Hurried typing produces listener-port typos and IP typos — and the recovery cost of one typo exceeds ten template pastes.

Fix: get speed from procedure — parallelization, templates, the bail-out baseline. Type your fingers slower than usual instead; typing it right the first time is shorter in total time. Make "the fast person is the accurate person" your motto for this training period.

Wall 5. I didn’t break in within 4 hours and don’t know whether to keep going

Symptom: the 4-hour alarm rings but "I feel like I’m almost there."

Cause: a normal moment where the time attack’s exit condition collides with the appetite for learning.

Fix: stop the clock, fix the score, then continuing afterward is allowed — but separate the logs. "Maximum progress at 4:00: user shell" is this run’s score, and everything after is study time under a separate log. Mix score and study and the comparison baseline for the next time attack disappears.

7. Summary

Today’s Concepts

Concept	One-line explanation
Parallelization	Filling waiting time with other investigation — speed that isn’t skipping
Time budget table	The Easy 4-hour map that fixes stage times and exit signals in advance
The 10-second rule	The completion criterion: any needed command pastes within 10 seconds
Bail-out baseline	The preconditions that allow write-up reading — set before starting
Bottleneck analysis	The post-run procedure that fixes overrun stages and causes in numbers from the lap-time log

Today’s Commands & Tools

Command/tool	What it does
`nmap -sV <IP>` / `nmap -p- <IP> --min-rate 2000 -oN full.txt`	Splitting the fast scan (front) from the full scan (background)
`gobuster dir -u <URL> -w <wordlist>`	Web directory enumeration — in the background
Playbook instant copy-paste section	The 10-second path for reverse shells, shell stabilization, privesc enumeration
`laps.txt` + `lap_budget.py` (example script)	Stage end-time recording and budget-vs-actual deviation computation

An Instinct More Important Than Commands

When speed training ends, you’ll realize — what decides the sub-4-hour cut is not new techniques but the removal of waiting and the accuracy of your hands. Machines work while humans judge, and humans type known commands without error in one shot. When these two mesh, Easy changes from "a problem that gets solved" into "a task that gets processed."

And this instinct is the admission ticket to the next stage — the Medium 8-hour long game. The person who saves time on Easy is the one who can allocate time on Medium.

Once every box is checked, Step 276 is complete.