Step 344. Penetration Playbook v2.0 — The Cycle Where Experience Becomes a Manual
Level 4 — Professional | Difficulty ★★★★☆ | Estimated time: 4–6 hours (asset collection + critical re-read + revision + version declaration)
Prerequisites: the playbook v1.0 of Step 272, the OSCP checklists of Steps 304–313, the bug-bounty recon procedure of Steps 314–319, and the scenario-training timeline of Step 343.
- What you need: the playbook v1.0 repository (Git), every routine document and training record created since v1.0, and one empty file for the changelog.
- ⚠️ All exercises in this chapter are for your own lab and legal platforms only. Applying them to unauthorized systems is a crime. Every procedure that goes into the playbook must be one verified on legal learning platforms and in your own lab.
- Chapter type: today is a project chapter — not a new technique, but a day of revision, transferring the experience of the last seventy Steps into the playbook.
In Step 272, you declared playbook v1.0 "a photograph of your current skill." That declaration carried one promise — that this document would be revised for life. Since then, you’ve prepared for and taken the OSCP practical, reconnoitered real services in bug bounty, and run a full-lab integrated scenario in Step 343. Seventy Steps have passed since the photograph was taken. v1.0 is now an old photo.
Today is the day you renew that photograph. But today’s core is not the revision itself — it’s the cycle of revision. Learn in the field, reflect it in the playbook, verify it in the next engagement, reflect it again — once this cycle starts turning, your skill grows at compound interest. v2.0 is the first proof that the cycle has completed one full turn.
1. Learning Objectives
By the end of this chapter, you will be able to:
- Exhaustively collect the assets accumulated since v1.0 (checklists, timelines, lessons) and build a revision-candidate list
- Read v1.0 critically to identify "procedures that diverge from reality"
- Attach "actual verification cases (date/machine)" links to each procedure and revise it into v2.0
- Update the tool list to the standard of "what you actually use now"
- Institutionalize the document’s lifecycle by setting a changelog and a revision cadence
2. Background Knowledge — Today’s Tools and Concepts
Today’s Tools at a Glance
| Category | Details |
|---|---|
| Language/environment | Markdown + Git (playbook repository), Git Bash |
| Today’s commands | git log, git diff, grep -rn — used for before/after comparison and verification |
| Concepts needed | Critical re-read, verification-case links, tool-list updates, changelog, revision cadence |
| Today’s deliverable | Playbook v2.0 (revised procedures + CHANGELOG.md + a revision-cadence declaration) |
2-1. The Difference Between v1 and v2 — From Photograph to Film
v1.0 was "a photograph of your current skill." We said a photograph’s value emerges when you compare later — today is that "later." v2.0’s work comes in three broad kinds.
- Revise: procedures written into v1.0 that you now perform differently in the field
- Add: steps v1.0 didn’t have — refined AD chains, bug-bounty recon, scenario operations
- Delete: cards never once opened, tools no longer used
The most valuable of these is deletion. On the day you built v1.0, you surely included things "you might use someday." A card never opened across seventy Steps will never be opened. Deleting is revision.
2-2. Critical Re-reading — Finding the "That’s Not How I Actually Did It"
The first act of revision is not writing but reading. Read v1.0 end to end, stamping each procedure with one of three marks.
The three stamps of a critical re-read:
[Keep ] — I followed this procedure in recent engagements too
[Revise ] — the direction is right, but in practice I did it shorter/differently
[Retire ] — I never once did it this way; it was a desktop procedure
The places stamped "Revise" and "Retire" are v2.0’s work zones. The important attitude here — respect v1.0, but do not trust it. v1.0’s author is you seventy Steps ago, and that person knows less than you do now. The judge is not the document but your memory and your records.
2-3. Promoting Verification-Case Links — From Link to Table
In Step 272, verification was marked by hanging one write-up link on each card. In v2.0, you promote this into a verification table. Only when each procedure shows "when, on which target, with what result" it was verified do you have grounds to trust that procedure mid-battle.
### The v2.0 format of a procedure card (example)
#### SMB enumeration — initial contact
crackmapexec smb <target-IP> -u '' -p '' --shares
| Verified | Date | Target | Result |
|------|------|------|------|
| ✅ | OSCP mock exam 2 | Machine B | anonymous share READ — flag clue |
| ✅ | Step 343 scenario | lab workstation | null session refused → next card |
The verification table also carries failed cases — because the record "it didn’t work in this environment" determines the branching of your next attempt. A playbook that records only successes is a document that doesn’t know its procedures’ limits.
2-4. Tool-List Updates — Cleaning the Toolbox
Your hands have changed since v1.0. You learned new tools, some tools yielded their place to faster alternatives, and some were automated away into aliases and scripts. There is exactly one rule for updating the tool list — keep only tools actually executed in the last three months.
Your shell history is the judge, because what you actually typed is the definition of "a tool you use." In 3-4 you’ll confirm this with a command.
2-5. Changelog and Revision Cadence — The Document’s Lifecycle
v1.0’s revision rule was "reflect at least one lesson per new machine/competition." The rule worked well but had a limit — small reflections piled up, but a re-examination of the whole structure was assigned to no one. So from v2.0, you run two layers of revision.
- Continuous revision: the existing rule as-is. Right after an engagement, reflect the lesson into the relevant section immediately
- Periodic revision: once per quarter, a full re-read like today’s. This is where the version number goes up
The changelog accumulates in a single CHANGELOG.md file, newest date first. Why a separate file instead of git log — a changelog needs the narrative of "what changed and why," and commit messages are too narrow to hold that narrative.
3. Follow Along
3-1. Collecting Revision Candidates — A Full Census of Assets
Gather everything created since v1.0 into one directory listing. In Git Bash, sweep each repository and write down the candidates.
Input (Git Bash):
ls ~/wiki ~/oscp-notes ~/bugbounty 2>/dev/null
ls playbook/
Output example:
ad-paths.md oscp-checklist.md report-template.md scenario-timeline.md
recon-procedure.md triage-log.md
01_recon/ 02_service_enum/ 03_exploit_patterns/ 04_linux_privesc/
05_windows_privesc/ 06_AD/ 07_pivoting/ stuck-tree.md
Then create the revision-candidate list — playbook/v2_todo.md. All you write next to each asset is "which section it goes to."
v2 work list (screen example):
- oscp-checklist.md → reinforce sections 01, 04, 05 (the enumeration order changed)
- scenario-timeline.md → propose a new section 08 "Scenario Operations"
- recon-procedure.md → add a "real-service recon" sub-card to section 01
- ad-paths.md → full revision of section 06 (paths grew from 3 to 9)
Why we do this: the #1 failure pattern of revision is "collecting until you’re too exhausted to write." So we limit the collection stage’s deliverable to one list, not a document. Once the list is complete, collection is done — each asset gets its close read when you revise its section.
3-2. Critical Re-reading — Stamping
Open each v1.0 file and apply 2-2’s stamps. The grounds for every judgment must be records — recent training timelines, OSCP notes, competition logs. If your memory is hazy, send that procedure back as "unverified."
Critical re-read results (screen example):
01_recon/nmap_template.md
1st card [Keep ] — this was the order in the OSCP practical too
2nd card [Revise ] — raised --min-rate 2000 → 3000 (mock exam 2 records)
3rd UDP [Revise ] — barely ran it in the field. Demote to "only when there's a suspicious clue"
stuck-tree.md
step 3 HackTricks [Revise ] — lately, searching my own write-up repo came first
step 5 24-hour sleep [Keep ] — this opened it in Step 343 too
How to read it: the memos on the "Revise" stamps are v2.0’s diff. Do not fix the document at this stage — stamp only. Mixing reading and writing stalls the re-read halfway.
3-3. Section-by-Section Revision — Executing Revise, Add, Delete
Once every stamp is placed, revise one section at a time. The work order per section is fixed — ① process the Revise stamps, ② add cards from new assets, ③ delete the Retire-stamped cards, ④ attach a verification table to every card.
Here are three representative changes new in v2.0.
① Reordering the stuck-handling tree — recent data overturned the old order.
# Stuck-Handling Tree v2
1. Re-examine enumeration — any ports/pages you haven't looked at
2. Search my own write-up repo — have I solved a similar machine before # moved ahead of v1's step 3 (HackTricks)
3. Multiply asset list × untried surfaces
4. Check the HackTricks page for the service
5. Wider scans — all ports, UDP, a large wordlist
6. Sleep on it 24 hours, then retry
> Grounds for revision: in 6 of the last 10 stalls, step 2 (searching my records) resolved it (Steps 330–343 logs)
② New section "08 Scenario Operations" — Step 343’s timeline-operation rules are promoted into cards.
# 08 Scenario Operations — Multiple Machines as One Operation
- Declare one goal sentence at the start ("obtain file X on the DC")
- Add findings to the asset map immediately — credentials table + network diagram
- Time-axis log: time / action / result / information gained
> Verification case: Step 343 integrated scenario (41-line timeline, 5-stage chain)
③ Deleting tool cards — cards with no execution record in three months get deleted. The deleted list goes into the CHANGELOG as "Deleted: reason" — the grounds for deletion helps any later decision to revive it.
3-4. Tool-List Update — History Is the Judge
Confirm with history what you actually use.
Input (Git Bash):
history | awk '{print $2}' | sort | uniq -c | sort -rn | head -20
Output example:
412 cd
287 ls
198 grep
141 python
118 nmap
97 git
84 crackmapexec
71 gobuster
...
How to read it: if a tool absent from this list is in the playbook, that card is a suspect. Conversely, if a tool sits near the top of this list but has no playbook card — say you type crackmapexec daily with no card for it — that is v2.0’s most urgent addition. If you worked in a WSL lab environment, check the lab-side history the same way with wsl -d <lab-name> -- bash -c "history | ...".
3-5. Writing the CHANGELOG and Declaring v2.0
Create playbook/CHANGELOG.md and record the first entry.
# Playbook Changelog
### v2.0 (2026-09-XX)
- Revised: section 01 nmap card — --min-rate raised, UDP card demoted (grounds: mock exam 2)
- Revised: stuck-tree order — my write-up search moved to step 2 (grounds: last 10 stall logs)
- Added: new section 08 Scenario Operations (grounds: Step 343)
- Added: real-service recon card (grounds: bug-bounty season)
- Deleted: N unused tool cards (grounds: 3-month history)
- Policy: quarterly periodic revision declared. Next re-read scheduled: ____.
### v1.0 (past date)
- First completion. 8-section skeleton + N command cards.
Then commit — playbook v2.0. Finally, fix the version section in the README and register the next periodic revision date in your calendar. A revision cadence absent from the calendar is not a declaration — it’s a wish.
4. Missions & Exercises
Mission — Complete Playbook v2.0
- Take a full census of post-v1.0 assets and complete
v2_todo.md - Critically re-read every v1.0 section and apply the three stamps (Keep/Revise/Retire)
- Execute the section-by-section revision — revise, add, delete + attach a verification table to every card
- Update the tool list by the history standard, and record the grounds for deleted cards in the CHANGELOG
- Record the v2.0 entry in
CHANGELOG.md, register the revision cadence and next re-read date in the calendar, and leave a v2.0 commit
Exercises
Exercise 1. Of the three acts of v2.0 revision (revise, add, delete), explain why "delete" is the most valuable.
Exercise 2. Explain why critical re-reading separates "stamping" from "fixing," through the difference in work characteristics between reading and writing.
Exercise 3. Explain why the verification table also carries failure cases, in contrast with the limits of "a playbook that records only successes."
Exercise 4. Explain why the two-layer structure of continuous and periodic revision is necessary, through the limit of v1.0’s revision rule ("reflect one lesson per engagement").
5. Model Answers & Completion Criteria
Mission Model Answer
The flow of 3-1 through 3-5 is the answer: a one-page work list → a stamped re-read → section-by-section revision (with verification tables) → a history-based tool update → CHANGELOG and calendar registration, and the v2.0 commit.
How to verify: ① Does git diff v1.0..v2.0 show all three kinds — revise, add, delete? ② Does every card carry a verification table (success + failure cases)? ③ Does each CHANGELOG entry carry its grounds (date/machine/log)? ④ Is the list of deleted cards and their reasons recorded? ⑤ Is the next periodic revision date actually in the calendar? ⑥ Is there a v2.0 commit in git log?
Exercise Answers
Answer 1. Because deletion is a record of verified knowledge — "I don’t use this." Revision and addition grow the document, but deletion raises the document’s trust density — it guarantees that every remaining card is one you actually open in the field. A "card never once opened" is also unlikely to be opened in the future, and while such cards sit mixed in, the judgment cost of "should I open this one or not" recurs every battle. Deleting is not losing — it is an act that raises the value of what remains.
Answer 2. Reading (judgment) and writing (revision) are different thinking modes. A re-read sweeps the whole to see the distribution; revision immerses itself in one section. Mix them and a bias appears — the first few sections get careful fixes while later sections get skipped in exhaustion. Finishing a stamps-only re-read completes "a map of the workload" first, so you can plan the revision’s priorities and distribution. And since the stamping stage judges against records, it also prevents the "I want to fix it this way" greed — which arrives once you start fixing — from contaminating the judgment.
Answer 3. A playbook that records only successes is a document that doesn’t know its procedures’ limits of application. With only the record "anonymous-share enumeration worked," the next time it fails you can’t judge whether the procedure is wrong or the environment is different. When a failure case sits beside it ("in null-session-refused environments, move to the next card"), the procedure’s preconditions surface, and mid-battle branching decisions get faster. The success column of a verification table tells you "you may trust this"; the failure column tells you "how far that trust extends."
Answer 4. Continuous revision is strong at procedure-unit improvements — an option change on one card, an added link — but powerless against structure-unit problems. A section split that has drifted from reality, a tree order that’s statistically wrong, half the cards falling into disuse — none of these surfaces under "reflect one lesson per engagement," because that rule never creates an occasion to re-read the whole. Periodic revision guarantees that occasion by policy. If continuous revision fixes sentences, periodic revision fixes the table of contents.
Completion Criteria Checklist
- [ ] I built the full census list of post-v1.0 assets (
v2_todo.md) - [ ] I finished a re-read stamping every v1.0 section with the three marks (Keep/Revise/Retire)
- [ ] I executed all three kinds of revision — revise, add, delete
- [ ] I attached verification tables with success and failure cases to every card
- [ ] I updated the tool list by the shell-history standard
- [ ] I recorded the deleted cards and their grounds in the CHANGELOG
- [ ] I recorded the v2.0 entry in the CHANGELOG and registered the next periodic revision date in the calendar
- [ ] Mission: I left a
playbook v2.0commit
6. Common Pitfalls & Fixes
Wall 1. I keep polishing to perfection and the revision never ends
Symptom: you’ve been repeating "I’ll commit after I polish section 08 a bit more" for three weeks.
Cause: you’ve mistaken v2.0 for a finished product — a relapse of the same trap as v1.0.
Fix: a playbook is not a reference book — it’s an operations manual. There is one standard: "is this a form I’ll actually open in the next engagement?" If it is, commit. The cycle of revision matters more than perfection. Once the cycle turns, v2.1 and v2.2 will polish it as much as needed. An uncommitted revision never enters the cycle.
Wall 2. Re-reading v1.0 embarrasses me — I want to rewrite everything from scratch
Symptom: instead of stamps, a full-rewrite urge rises.
Cause: your growth across seventy Steps is large enough that the old document looks childish — a natural emotion.
Fix: express that embarrassment not as a rewrite but as sentences in the CHANGELOG. "This v1.0 procedure belonged to the beginner era; now I do it this way" — that contrast is the document’s value. Don’t delete v1.0. Keep it with git tag. When you revise v3.0 a year from now, that tag becomes the material proving the width of your growth.
Wall 3. Deleting by the history standard scares me — "what if I need it later?"
Symptom: you stamped cards for deletion but can’t execute.
Cause: you’ve mistaken deletion for loss. In a Git repository, deletion is not loss.
Fix: remember two devices. ① Git history — a deleted card can be revived anytime via git log and the CHANGELOG’s "Deleted: reason" entries. ② Scrapbook separation — for cards you can’t let go of, move them not into the playbook but into a wiki "archive." Failing the playbook’s eligibility standard ("executed within the last 3 months") is different from throwing the knowledge itself away.
Wall 4. The history command shows nothing
Symptom: you ran history in Git Bash and got only a few lines, with no past-session records.
$ history | wc -l
12
Cause: shell history is saved at session end by default, and Git Bash’s default save size is small. And if the real work happened in a WSL lab, it was never in Git Bash’s history to begin with.
Fix: you must look at the history of the shell where the work happened — if lab work was in WSL, check the lab side with wsl -d <lab-name> -- bash -c "history | awk ...". If records are still thin, use memory and training logs (timelines, write-ups) as this revision’s judges, and raise history saving for the next revision (HISTSIZE, HISTFILESIZE).
Wall 5. I want to write "grounds" in the CHANGELOG but there are no records
Symptom: "why did I fix this card again?" — even digging through competition logs, that day’s judgment doesn’t surface.
Cause: the moment you reflected a lesson and the moment you recorded it drifted apart. You committed continuous revisions without writing the grounds.
Fix: this time, honestly write "grounds: memory (unverified)" and move on — an unverified mark beats a fabricated ground. Then fix the policy: fix the continuous-revision commit-message format to reflect: content (grounds: date/target). An empty format makes you defer the commit, and that deferral forces the recording.
7. Summary
Today’s Concepts
| Concept | One-line explanation |
|---|---|
| The three acts of revision | Revise (procedures diverging from reality) · add (new assets) · delete (unopened cards) — deletion is the highest value |
| Critical re-read | Separating the reading that only stamps (Keep/Revise/Retire) from the writing that fixes |
| Verification table | Per-procedure records of success + failure cases — evidence of trust and of limits |
| History-based update | Only "commands actually typed" count as "tools in use" — shell history is the judge |
| Two-layer revision | Continuous (one lesson per engagement) + periodic (quarterly full re-read) |
| CHANGELOG | The narrative of what changed and why — the grounds for deletions live here too |
Today’s Commands
| Command | What it does |
|---|---|
git diff v1.0..HEAD |
Before/after comparison of the revision |
git tag v1.0 |
Preserving the old version (don’t delete it) |
history | awk '{print $2}' | sort | uniq -c | sort -rn |
Ranking of actually used tools |
grep -rn "keyword" playbook |
Confirming searchability survives the revision |
git commit -m "playbook v2.0" |
Declaring the revision’s baseline |
The Core Instinct
The playbook’s version number is not the document’s version — it’s your version. The seventy Steps between the person who made v1.0 and the person who made v2.0 remain intact in the git diff — shorter procedures, colder deletions, denser verification tables. That diff is growth’s most honest evidence, and as long as this document lives, that evidence keeps accumulating.
And remember the cycle. Today’s v2.0 is not an end but the starting point of the second revolution. The moment this document gets "opened" even once in the next engagement, that page becomes a revision candidate again. The engine that compounds your skill is not a flashy new technique but this boring cycle — engagement, reflection, revision, engagement again.
Once every box is checked, Step 344 is complete.