Step 272. Completing Your Own Pentest Playbook — Taking a Photo of Your Current Skill

Level 3 — Real-World CTF & Advanced Offensive Skills | Difficulty ★★★☆☆ | Estimated time: 3–4 hours

Prerequisites: Step 89’s personal wiki, Step 105’s technique classification table, Step 259–260’s privesc checklists, Step 270’s Medium guide.

What you need: your personal wiki (or a new repository), and every routine document and checklist you’ve made scattered about until now.
⚠️ All exercises in this chapter are for your own lab and legal platforms only. Applying them to unauthorized systems is a crime. The commands that go into the playbook must be ones you verified on legal learning platforms like HTB and TryHackMe, or in your own lab.
Character note: today is a project chapter — not a new technique, but a day for assembling your everything-so-far into one manual.

Until now you’ve made many documents. The technique classification table, privesc checklists, enumeration routines, the Medium guide, the AD path annotations. Each was excellent in its moment, but they’re too scattered to unfold mid-combat. From "what do I type first when handed a new machine" to "where do I fall back to when stuck" — you need to be able to unfold it all in one place.

What you make today is the penetration testing playbook — a personal manual you unfold in real engagements, and a living document that will be revised for the rest of your career. Don’t try to make it perfect. v1 is merely "a photo of your current skill."

1. Learning Objectives

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

Integrate scattered routine documents into a playbook with an 8-section structure
Place "copy-paste ready" command cards in each section
Build a "stuck-handling tree" that fixes the order of actions for stalled situations
Attach links to your own write-ups in each section, connecting to verified cases
Declare playbook v1.0 and set the revision rules

2. Background Knowledge — Today’s Tools and Concepts

Today’s Tools at a Glance

Category	Details
Language/environment	Markdown + personal wiki (Git-managed)
Today’s commands	No new attack commands — just verification `grep -rn`
Concepts needed	Command cards, the stuck-handling tree, living documents, version declaration
Today’s deliverable	A playbook repository (8 sections + README + stuck tree) v1.0

2-1. How the Playbook Differs from the Wiki

If the personal wiki (Step 89) is "a warehouse of what you know," the playbook is "a book of the order your hands move in." The difference shows in sentence form.

Wiki document: "LFI is a vulnerability that reads server-side files…" (explanation)
Playbook document: ?file=../../../etc/passwd → if root:x:0:0: shows, confirmed (action)

Every sentence in the playbook must start with a verb. "Check, try, scan." When a concept gets curious, you follow a link from the playbook to the wiki — which is why the two documents stay separate.

2-2. The 8-Section Structure — The Skeleton This Book Proposes

Section	What it holds	Past steps supplying the material
01 Recon	nmap templates, scan order	Step 81, 268
02 Per-service enumeration	Command cards per service: web/SMB/FTP/SSH…	Step 265–270
03 Intrusion patterns	Judgment criteria per entrance vector	Step 105, 270
04 Linux privesc	Privilege-escalation checklist	Step 125–126, 259
05 Windows privesc	Privilege-escalation checklist	Step 260
06 AD	Domain route (enumeration → Roasting → path)	Step 261–263, 271
07 Pivoting	Internal-network movement	Step 264
08 Stuck-handling tree	Order of actions when stalled	Step 269, 270

Adjust the weights to your own distribution of experience. If your pivoting experience is still shallow, 07 can start as a single page — an empty section only needs its place held.

2-3. Command Cards — Copy-Paste-ability Is the Quality Standard

The playbook’s basic unit is the command card. A card’s completion condition is: "mid-combat, can I copy this whole block and run it?"

## nmap — the first 5 minutes on a new machine
# pass 1: basics (fast)
nmap -sV -sC targetIP -oN nmap_default.txt
# pass 2: all ports (in the background)
nmap -p- --min-rate 2000 targetIP -oN nmap_all.txt
# pass 3: UDP top ports (slow)
sudo nmap -sU --top-ports 100 targetIP -oN nmap_udp.txt

One caution — do not include unverified commands. "Saw it on the internet, might use it someday" is not a playbook but a scrapbook. Only commands you’ve typed yourself and seen the output of become cards. That is the value that distinguishes this document from a HackTricks clone.

2-4. The Stuck-Handling Tree — Turning Emotion into Procedure

When an attack stalls, the real enemy is not skill shortage but the randomness of panic — typing the same thing over and over, or suddenly trying something irrelevant. The stuck-handling tree is a procedure that fixes that moment’s actions in advance.

30-minute stall detected
 1. Re-review enumeration — is there a port/page in the scan results not yet examined
 2. Asset list × untried surfaces multiplication (Step 269)
 3. Check the per-service HackTricks pages
 4. Wider scans — all ports, UDP, large wordlists, vhosts
 5. Set aside for 24 hours, then retry

The key is doing it strictly from the top, in order. With the tree, the anxiety of "I don’t know what to do" changes into the positional sense of "I’m on step 2 right now."

2-5. A Living Document — v1.0 and the Revision Rules

The playbook is not a finished product but a version. v1.0 is a photo of your current skill, and every time you fight a new machine or competition, you fold in at least one thing you learned and go to v1.1, v1.2. Manage it with Git and the revision history becomes your growth history — a year from now, git log will draw your growth graph.

3. Follow Along

3-1. Building the Repository and Skeleton — Hands-On

Inside your wiki (or as a separate repository), make a playbook/ directory and erect the 8-section skeleton.

Input (Git Bash):

mkdir -p playbook/01_정찰 playbook/02_서비스별_열거 playbook/03_침투_패턴 \
  playbook/04_리눅스_privesc playbook/05_윈도우_privesc playbook/06_AD \
  playbook/07_피벗팅

Then fill in the minimal files — below is each file’s starting form.

playbook/README.md:

# My Pentest Playbook v1.0
When handed a new machine, unfold this document first.

## Contents
- [01 Recon](01_정찰/nmap_템플릿.md)
- [02 Per-service enumeration](02_서비스별_열거/웹.md)
- [04 Linux privesc](04_리눅스_privesc/체크리스트.md)
- [Stuck-handling tree](막힘_대처_트리.md)

## Revision rules
Fold in at least 1 thing learned per new machine/competition.

playbook/01_정찰/nmap_템플릿.md:

# nmap command card
## pass 1: quick check
nmap -sV -sC targetIP -oN nmap_default.txt
## pass 2: all ports
nmap -p- --min-rate 2000 targetIP -oN nmap_all.txt
## pass 3: UDP top ports
sudo nmap -sU --top-ports 100 targetIP -oN nmap_udp.txt

playbook/04_리눅스_privesc/체크리스트.md:

# Linux privilege-escalation checklist
- [ ] sudo -l
- [ ] SUID: find / -perm -4000 -type f 2>/dev/null
- [ ] cron: cat /etc/crontab; ls -la /etc/cron.*
- [ ] kernel/distro version: uname -a; cat /etc/os-release
- [ ] writable PATH folders: echo $PATH

Why do this: the reason for erecting the skeleton first is to make the "empty sections" visible. An empty section is not a failure but a map of what to fill next.

3-2. Verifying Searchability — Hands-On

Verify, the moment you make it, whether the playbook can still be found through mid-combat as it grows.

Input (measured 2026-09-09, Git Bash):

grep -rn "perm -4000" playbook
grep -rn "HackTricks" playbook

Output (measured 2026-09-09):

playbook/04_리눅스_privesc/체크리스트.md:3:- [ ] SUID: find / -perm -4000 -type f 2>/dev/null

playbook/막힘_대처_트리.md:4:2. Check the per-service HackTricks pages

How to read it: whether you remember only part of a command (perm -4000) or only the keyword of an action (HackTricks), the document must get caught. This is the playbook version of Step 89’s "searchability" principle — mid-combat, you search not with complete sentences but with fragment keywords.

Why do this: if search fails now when you have five files, it will fail forever when you have fifty. You verify the structure while it’s small.

3-3. Integrating the Scattered Documents — Import and Extraction

Now you extract command cards from your past documents. There’s an order.

Step 105’s technique classification table → material for section 03 Intrusion patterns (each technique’s "signs" become judgment criteria)
Step 259–260’s checklists → move to sections 04, 05 (leave the originals in the wiki and link)
Step 268–269’s enumeration and asset-list rules → become the preamble guidance of sections 01, 02
Step 271’s AD path annotations → become a verified-case link in section 06
Step 270’s Medium guide → becomes the entrance-priority table in section 03

It’s extraction, not moving — leave the wiki’s explanation documents as they are, move only the action parts into the playbook, then attach a "details: [wiki document]" link.

3-4. Writing the Stuck-Handling Tree

Make playbook/막힘_대처_트리.md on 2-4’s skeleton, but verify the order against your own records. In the Medium synthesis table (Step 270), what were "the actions that actually worked when stuck"? Those actions must rise to the top of the tree.

If an order different from the book’s skeleton comes out, that is the right answer — this document must be not a textbook but a compression of my own past data.

3-5. Verified-Case Links — My Write-Ups Are the Evidence

Next to each section’s command card, link the attack record where that command actually worked.

## web directory scan
gobuster dir -u http://targetIP -w /usr/share/wordlists/dirb/common.txt
> verified case: [M-3 machine write-up](../../writeups/M-3.md) — used to find /backup

Why do this: "a command I actually succeeded with" and "a command I saw somewhere" have different trust levels mid-combat. Mark cards without links as "unverified," and once verified on the next machine, replace the mark with a link. This one rule keeps raising the playbook’s quality.

3-6. Declaring v1.0 and the Revision Rules

Finally, declare it in the README.

## Version
- v1.0 (2026-09-XX): first completion. 8-section skeleton + N command cards.
- Revision rules: fold in at least 1 thing learned per new machine/competition. Commit immediately upon folding in.

And commit — playbook v1.0. This commit is the reference point. The difference between this commit and you half a year later is exactly your growth.

4. Missions & Exercises

Mission — Complete Playbook v1.0

Build a playbook/ repository with the 8-section structure and place at least 1 command card per section
Check each card for "copy-paste-ability," and include only verified commands
Write 막힘_대처_트리.md with its order decided by my own attack-record data
Attach at least 1 verified-case link to your own write-up per section
Pass 2 grep -rn search tests and leave a v1.0 commit

Exercises

Exercise 1. Explain the difference between the playbook and the personal wiki from the perspective of sentence form.

Exercise 2. State what "copy-paste-ability," the command card’s completion condition, means, and why it becomes the quality standard.

Exercise 3. Explain why the stuck-handling tree’s essence is not "content" but "fixed order."

Exercise 4. Explain why unverified commands must not go into the playbook, in terms of the difference from public documents like HackTricks.

5. Model Answers & Completion Criteria

Mission Model Answer

The flow of 3-1–3-6 is itself the skeleton: 8 section directories, at least 1 card per section, a 5-step stuck tree, verified-case links, a v1.0 commit. Few cards is fine — v1 is a photo, not an encyclopedia.

How to verify: ① does find playbook -name "*.md" show the 8 sections’ files? ② Does a fragment-keyword search like grep -rn "perm -4000" playbook find the document? ③ Does each card carry a verified-case link or an "unverified" mark? ④ Does the stuck tree’s order have grounds in your records? ⑤ Is there a v1.0 commit in git log?

Exercise Answers

Answer 1. The wiki is "a warehouse of what you know," centered on explanatory sentences ("LFI is …"), while the playbook is "a book of the order your hands move in," centered on action sentences ("check, try"). When a concept is in question, you follow a link from the playbook to the wiki — so the two stay separate.

Answer 2. Copy-paste-ability means "mid-combat, does copying this whole block and running it work?" Mid-combat there’s no leisure to reconstruct a command from memory, and reconstruction breeds typos and missing options. Only a copy-paste-able card gets reused accurately under time pressure, so that becomes the card’s quality standard.

Answer 3. Because the real enemy in a stalled situation is the randomness of panic. The tree’s items are mostly actions you already know, but in a panic state you execute them in random order, or repeat only the same one. The fixing of "strictly from the top, in order" turns anxiety into positional sense ("I’m on step 2 right now") — that is the tree’s function.

Answer 4. HackTricks is a list of every possibility; the playbook is a list of what I’ve verified. Mix in unverified commands and mid-combat you must judge "did this work before?" every time, collapsing the playbook’s trust. A public document is a reference book; the playbook is a toolbox fitted to my hands — only tools I’ve used go into the toolbox.

Completion Criteria Checklist

[ ] I built the playbook skeleton with the 8-section structure
[ ] I placed at least 1 copy-paste-able command card per section
[ ] I included only verified commands and marked unverified ones
[ ] I decided the stuck-handling tree’s order from my own record data
[ ] I attached verified-case links to my write-ups in each section
[ ] I passed 2 grep -rn search tests
[ ] Mission: I left the v1.0 declaration commit and revision rules in the README

6. Common Pitfalls & Fixes

Wall 1. Trying to make it perfect, v1.0 never comes out

Symptom: you keep postponing the declaration, saying "I only have ten cards so far…"
Cause: you misunderstood v1.0 as a finished product. The playbook is a version, not an achievement.
Fix: declare it even with empty sections. Writing the definition "v1.0 = a photo of my current skill" straight into the README puts your mind at ease. The first photo of a document revised for a lifetime may be shabby — a photo’s value appears when you compare later.

Wall 2. You’re wholesale-copying internet documents

Symptom: before you knew it, you were making an abridged HackTricks.
Cause: the impatience of "I want to fill the empty sections fast."
Fix: return to the rule of not including unverified commands. A copied command has no trust mid-combat, so you end up reopening the official document anyway — in that case, writing just one link line in the playbook is better.

Wall 3. Content exists doubly in wiki and playbook, and they drift apart

Symptom: you fixed the wiki, but the playbook has the old content.
Cause: you copied instead of moving.
Fix: settle it with the principle — explanations live only in the wiki; action cards live only in the playbook. When a playbook card needs a concept explanation, connect it with a "details: [wiki document]" link. One piece of content must exist in one place only.

Wall 4. You made the stuck-handling tree but don’t unfold it when actually stuck

Symptom: you forgot the tree and were repeating the same command again.
Cause: the tree isn’t connected to an action habit. You made the document but there’s no trigger condition.
Fix: set the trigger condition mechanically — "a 30-minute timer" or "3 consecutive failed commands of the same type." When the condition fires, opening the tree document comes first, no exceptions. A procedure without a trigger is decoration.

Wall 5. grep searches find nothing

Symptom: it’s a command you definitely wrote down, but grep -rn doesn’t catch it.
Cause: one of two — the search keyword and the document’s expression differ ("privilege escalation" vs "privesc"), or the file is outside the playbook.
Fix: command cards must always include the command’s literal text itself — the literal command is the strongest search keyword. And make it a habit to run searches inside playbook/. A card that search can’t catch is a signal its phrasing needs fixing.

7. Summary

Today’s Concepts

Concept	One-line explanation
Pentest playbook	A personal manual unfolded in real engagements; a book of hands, separate from the wiki (warehouse)
Command card	The playbook’s basic unit; completion condition is "can it be copy-pasted straight into use"
8-section structure	Recon, per-service, intrusion patterns, Linux, Windows, AD, pivoting, stuck tree
Stuck-handling tree	A procedure fixing the order of actions when stalled; the essence is fixed order, not content
Verified-case link	A "record where I succeeded" link beside a card; evidence of trust
v1.0 declaration	A photo of current skill; the first reference point of a document revised for a lifetime

Today’s Commands

Command	What it does
`mkdir -p playbook/01_정찰 ...`	Create the 8-section skeleton
`grep -rn "keyword" playbook`	Verify playbook searchability
`find playbook -name "*.md"`	Confirm per-section files exist
`git commit -m "playbook v1.0"`	Declare the version reference point

An Instinct More Important Than Commands

A playbook’s completeness is measured not by page count but by trustworthiness. A document with the certainty that "everything written here was verified by my own hands" reduces panic mid-combat. And this document’s real reward comes a year later — the moment you view the difference between the v1.0 commit and your then-self through git log, you confirm your growth not as abstraction but as diff. Today’s shabby first photo makes that comparison possible.

Once every box is checked, Step 272 is complete. Click the checkbox in the sidebar to save your progress.