Step 130. ★ Checkpoint: Time-Attack Mock Penetration — Run the Entire Process in 6 Hours

Level 2 — Introduction to Security and Attack Skill Basics | Difficulty ★★★★☆ | Estimated time: 7 hours (6-hour time attack + 1-hour retrospective)

Prerequisites: Steps 111–129 — you have built the Kali lab, completed the entire MS2 process, and attacked one VulnHub machine you’d never seen before.

What you need: one VulnHub Easy-rated VM different from Step 129’s, a timer (your phone is fine), and a notepad or Markdown file for time logging. This chapter’s lab attack screens are screen examples; the time measurements of local commands are measured (2026-09-09, WSL Ubuntu 24.04).
⚠️ All exercises in this chapter are for your own lab and legal platforms only. Applying them to unauthorized systems is a crime.
This chapter is a test — you learn no new techniques. It is training in pulling out everything so far within a time limit.

The real world — competitions, exams, or the job — is a fight against time. With the same skill, a person with an allocation plan like "recon 30 minutes, intrusion 2 hours, privilege escalation 2 hours, documentation 1 hour" goes much further. Today’s checkpoint tests not your hacking skill but your sense of time. And it engraves one rule into your body — never hang on a single path for more than 30 minutes.

1. Learning Objectives

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

Make and keep a time-allocation table for a 6-hour penetration exercise
Record each phase’s end time and result to track delays against the plan
Abandon a stuck path and switch to another using the "30-minute rule"
Build a fast enumeration command sequence that sketches a target’s outline in tens of seconds
Write a retrospective document on "where did the time go" after finishing

2. Background Knowledge — Today’s Tools and Concepts

Today’s Tools at a Glance

Category	Details
Language/environment	Kali + a VulnHub Easy VM (different from Step 129’s), a timer, a record file
Today’s commands	All review — `nmap`, `searchsploit`, privilege-escalation enumeration + `time` for measurement
Concepts needed	Time boxing, the 30-minute rule, retrospective
Today’s artifact	Time-attack results + `time-attack-retrospective.md` (time usage and improvements)

2-1. Time Allocation — The Silent Clock Is the Scariest

In a timed penetration, the worst enemy is not a hard vulnerability but the absence of time sense. The moment you burn 90 minutes on one path thinking "just a little more and it’ll work," everything else collapses.

So you make a table before starting. A basic 6-hour allocation:

Phase	Time	Goal	End signal
① Recon/enumeration	0:00–0:30	Full scan + attack surface list	Vulnerability candidate list complete
② Intrusion	0:30–2:30	First shell	`whoami` output
③ Privilege escalation	2:30–4:30	Reach root	uid=0 in `id`
④ Documentation/wrap-up	4:30–6:00	Reproducible record complete	Attack record file finished
Reserve	Carry-over from each phase	Absorb delayed phases	—

The key is not the numbers but deciding the end signals in advance. "Until it works" is not a plan; "when this time comes, move on" is.

2-2. The 30-Minute Rule — Hanging On Is the #1 Cause of Timeouts

If there’s been no progress on one path (one service, one exploit) for 30 minutes, stop and ask:

"Is this path the only one? Are there lines in the scan results I haven’t knocked on yet?"

Most of the time the answer is "there are." Then just mark that path (memo: "Samba — 30 minutes spent, exploit mismatch") and move to the next candidate. Surprisingly often, re-reading the original scan results is the fastest breakthrough — the person who did recon diligently wins the time attack.

2-3. Retrospective — The Checkpoint’s Real Artifact

The time attack’s report card is not whether you got root but the retrospective document. When the 6 hours end, ask:

Which phases ran late against the plan?
What exactly was I doing during those phases?
What will I do differently next time?

"1 hour over in the intrusion phase" is a result; "I tried 3 exploits in no particular order" is a cause. A retrospective must dig down to causes for the next checkpoint’s allocation table to improve.

3. Follow Along

3-1. Before Starting — Picking a Target and Setting the Timer

Pick an Easy-rated VM different from the one you broke in Step 129 — you can’t measure your time sense with an answer you already know. Add it to the lab (the procedure of Step 129, sections 3-1–3-2) and write the allocation table on your notepad.

Input (the first screen of the memo file time-attack-log.md):

# Time-Attack Log — [machine name]
Start time: __:__  | Limit: 6 hours
| Phase | Plan | Actual end | Result notes |
|------|------|-----------|-----------|
| Recon | ~0:30 | | |
| Intrusion | ~2:30 | | |
| Escalation | ~4:30 | | |
| Documentation | ~6:00 | | |

Why: this table is today’s protagonist. Not a command log but a time log — filling in the "actual end" column each time a phase ends achieves half the training by itself.

3-2. ① Recon (30 minutes) — Fast and Wide

The recon phase has one technique — run in the background whatever can run in the background while you look at other things. A full scan (-p-) is slow, so first run a quick scan of the top ports to secure services you can look at right away, and let the full scan proceed at the same time.

Screen example (typical for the recon phase):

# Terminal 1 (immediate): nmap -sV 192.168.56.104
PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 7.2p2
80/tcp open  http    Apache httpd 2.4.18

# Terminal 2 (background): nmap -p- 192.168.56.104 -oN full.txt

How to read it: start enumerating from the quick scan results while the slow full scan runs in the back. The phase succeeds only if a "vulnerability candidate list" (service + version + searchsploit results) is in your notes before the 30 minutes are up.

3-3. Make a Prediction — How Long Do the Enumeration Commands Themselves Take?

In a time attack it’s easy to feel that "enumeration eats all the time," but executing the commands takes an instant. Let’s measure, with timings, a basic enumeration sequence for right after catching a shell on a Linux machine.

Input (measured on local WSL Ubuntu):

time (whoami && id && uname -sr && ss -tln && 
      cut -d: -f1 /etc/passwd | wc -l && 
      find /usr/bin -perm -4000 2>/dev/null | head -5)

Output (measured 2026-09-09, WSL Ubuntu 24.04 — values will differ in your environment):

root
uid=0(root) gid=0(root) groups=0(root)
Linux 6.18.33.2-microsoft-standard-WSL2
State  Recv-Q Send-Q  Local Address:Port  Peer Address:Port
LISTEN 0      4096    127.0.0.53%lo:53         0.0.0.0:*
LISTEN 0      4096       127.0.0.54:53         0.0.0.0:*
LISTEN 0      4096       127.0.0.1:46295      0.0.0.0:*
LISTEN 0      1000   10.255.255.254:53         0.0.0.0:*
29
/usr/bin/umount
/usr/bin/su
/usr/bin/sudo
/usr/bin/newgrp
/usr/bin/chsh

real    0m0.018s
user    0m0.007s
sys     0m0.006s

How to read it: gathering six kinds of information (identity, kernel, listening ports, account count, SUID list) took 0.018 seconds. real is the wall-clock time.

Why it matters: in a time attack, what eats time is not command execution but reading, judging, and wandering. So ① memorize your frequently used enumeration sequences as single chunks, ② save output to files so you read it twice, and ③ when you can’t decide, mark that line and move on. The tools are fast — your decisions are what spend the clock.

3-4. ②③ Intrusion and Escalation — The 30-Minute Rule in Action

In the intrusion phase, try candidates in priority order. The judgment criteria are the same as Step 129 — start with "known exploit code exists, and the version matches exactly."

Screen example (a memo where the 30-minute rule is working):

0:35 Candidate 1 Apache 2.4.18 — no match in searchsploit. Folded.
0:50 Candidate 2 SSH — brute force? Eats time. On hold.
1:10 Candidate 3 website on port 80 — found a backup file while hunting hidden directories
1:40 DB password in the backup file's config → reused it over SSH — success
1:41 whoami → www-data ... first shell secured (50 minutes ahead of plan)

How to read it: each attempt carries a timestamp. Only with timestamps like "found at 1:10, shell at 1:41" can you reconstruct "where the time went" in the retrospective.

3-5. ④ Documentation (1 hour) — How to Use the Remaining Time

If reserve time remains, spend it on the record. Scale down Step 128’s report structure and fill in four cells per intrusion path: "cause → method → privileges gained → defense." Screenshots must always include whoami — this habit should already be attached to your body.

3-6. After Finishing — Writing the Retrospective

When 6 hours pass (or you get root), stop the clock and write the retrospective. The skeleton:

# Time-Attack Retrospective — [machine name] (date)
- Final reach: (root / user shell / only got as far as recon / ...)
- Phase-by-phase vs. plan: recon +10 min, intrusion -50 min, escalation +40 min ...
- TOP 3 spots where I spent the most time, and what I was doing there
- 3 things I'll do differently in the next time attack

Why: if you can’t come up with at least three "things to do differently," the retrospective is shallow. From 6 hours of trial and error, there are always at least three things to learn.

4. Missions & Exercises

Mission — Complete a 6-Hour Time Attack and Retrospective

Add an Easy VM different from Step 129’s to the lab, and write the allocation table in time-attack-log.md.
Set a timer and run the 6-hour time attack — record the time and result at each phase’s end.
Consciously apply the 30-minute rule at least once (note the path abandonment and switch explicitly in the log).
Polish the fast enumeration sequence from 3-3 for your own shell enumeration and keep it in your notes.
After finishing, write time-attack-retrospective.md — including the time-usage TOP 3 and 3 improvements.
The result doesn’t have to be root — "maximum progress + an accurate time history" is the mission’s complete form.

Exercises

Exercise 1. Why do you decide "end signals" in advance in a time-allocation table? Explain by comparing with "do it until it works."

Exercise 2. In the 3-3 measurement, gathering six kinds of information took 0.018 seconds. Yet in a time attack, tens of minutes get consumed on enumeration. Why?

Exercise 3. When you abandon a path under the 30-minute rule, why must you "leave a mark (memo)" before moving on?

Exercise 4. In a retrospective, why distinguish the result "1 hour over in the intrusion phase" from the cause "tried exploits in no particular order"?

5. Model Answers & Completion Criteria

Mission Model Answer

A time attack has no single correct answer either. Check against these verification criteria.

Allocation table exists: is there a table written before starting, with an "actual end" time filled in for each phase?
Traces of the 30-minute rule: is "path abandoned → switched" recorded at least once in the log?
Saved evidence: is the whoami/id output of the highest privilege you reached preserved as a file?
Retrospective depth: are the "things to do differently" at the action level — not "be faster" (bad) but "sort exploit candidates by version-match order" (good)?

Even without root, if 1–4 are thorough, this checkpoint is a pass. The time attack’s purpose is not victory but making your own time usage visible.

Exercise Answers

Answer 1. "Until it works" places the end condition externally (on success), so you burn unlimited time on failing paths. Deciding end signals as times in advance keeps the decision power with the plan, letting you cut failed paths and redistribute time to remaining ones. The essence of timed training is not going fast but cutting.

Answer 2. Because what spends time is not command execution but output interpretation and judgment — which port looks suspicious, which version breaks, what to switch to when stuck. So optimizing enumeration in a time attack happens not through "typing speed" but through "saving output to read twice" and "deciding judgment criteria (version match first) in advance."

Answer 3. Because the abandoned path may actually have been the right answer — 30 minutes later, other information (e.g., a newly found version string) can make that path promising again. If you discard it without a memo, that 30 minutes of trial and error vanishes entirely; if you mark it, the cost of revisiting is almost zero. In a time attack, memos are coordinates to return to.

Answer 4. Because results can’t be changed — only causes can. "1 hour over" is a symptom; "trying in no particular order" is a prescribable action. If the retrospective stops at results, the next allocation table just grows numbers like "intrusion 3 hours"; only by going down to causes do you get methods that improve within the same time, like "set a candidate-sorting criterion."

Completion Criteria Checklist

[ ] I can make a 6-hour allocation table (with phases and end signals) before starting
[ ] I can proceed while recording each phase’s actual end time and result
[ ] I have a record of abandoning and switching paths under the 30-minute rule
[ ] I can run a fast enumeration sequence as a single chunk of commands
[ ] I saved evidence output of the highest privilege reached
[ ] I completed a retrospective containing the time-usage TOP 3 and 3 improvements

6. Common Pitfalls & Fixes

Wall 1. The 30-minute recon phase flies by

Symptom: you wait for the full scan (-p-) to finish and the phase ends.

Cause: you built a schedule that waits for a slow scan. -p- takes minutes, more with more ports.

Fix: look at a quick scan (default top ports) first as in 3-2, and run the full scan in the background. The recon phase’s end condition is not "full scan complete" but "vulnerability candidate list complete."

Wall 2. I got absorbed in one path and 2 hours had passed

Symptom: "just a little more" repeats until the entire intrusion phase is gone.

Cause: the 30-minute rule had no notification device. While immersed, you can’t see the clock — that’s normal.

Fix: physically set a 30-minute timer (a phone alarm). When it rings, take your hands off unconditionally and ask "is this path the only one?" — rules are kept by devices, not willpower.

Wall 3. The VM is slow and commands lag

Symptom (screen example): nmap or shell responses lag by seconds.

Cause: the VM has insufficient memory/CPU allocated, or other VMs are running on the host at the same time.

Fix: shut down VMs you’re not using and check the allocations for the target and Kali. In a time attack, environmental delay is not skill but an equipment variable — a 10-minute environment check before starting (one ping sweep, one shell-response check) reduces mid-run confusion.

Wall 4. I don’t know which number to look at in the time command’s result

Symptom (measured form, 2026-09-09):

real    0m0.018s
user    0m0.007s
sys     0m0.006s

Cause: confusion from not knowing why three lines appear.

Fix: you only need to look at real — the wall-clock time from the command’s start to its end. user is the time the CPU ran your code; sys is operating-system (kernel) work time. In a time attack, what matters is the time you waited, and that’s real.

Wall 5. When I try to write the retrospective, I can’t remember what I did

Symptom: after 6 hours, the contents of each phase are blurred.

Cause: you didn’t record times along the way. Memory keeps only the climax scenes of the intrusion and erases the rest.

Fix: from the next time attack on, spend 30 seconds each time a phase ends filling in the log table. Those 30 seconds × 4 are the entire raw material of the 1-hour retrospective. Recording is work in progress, not work after finishing.

7. Summary

Today’s Concepts

Concept	One-line explanation
Time boxing	A plan that fixes each phase’s time and end signal in advance
The 30-minute rule	A device that cuts a progress-free path at 30 minutes and switches
End signal	An objective phase-end condition replacing "until it works"
Retrospective	Post-analysis that digs down to causes, not results
Maximum progress	The time attack’s grading standard that doesn’t require root

Today’s Commands

Command	What it does
`time (command chunk)`	Measure a command chunk’s actual elapsed time (check `real`)
`nmap -sV <IP>`	Quick service/version scan (the recon phase’s leadoff batter)
`nmap -p- <IP> -oN full.txt`	Full scan — in the background
`whoami && id && uname -sr && ss -tln`	Basic post-shell enumeration in one chunk
`find /usr/bin -perm -4000 2>/dev/null`	Find SUID files (privilege-escalation lead)

An Instinct More Important Than Commands

What the time attack teaches is not speed but restraint — anyone can push a working path, but not everyone can abandon a failing path on time. The moment you turn on the clock, you step up from "a person who breaks in" to "a person who allocates time."

And when this checkpoint ends, Level 2’s intrusion part comes to a close. You can now face a machine you’ve never seen, within a fixed time, with your own routine — and above all, you’ve learned where you spend your time.

Once every box is checked, Step 130 is complete.