Step 272. 나만의 침투 플레이북 완성 — 지금 실력의 사진을 찍는다

Level 3 — CTF 실전과 공격 스킬 심화 | 난이도 ★★★☆☆ | 예상 소요 시간 3~4시간

전제: Step 89의 개인 위키, Step 105의 기법 분류표, Step 259~260의 privesc 체크리스트, Step 270의 Medium 가이드가 있다.

준비물: 개인 위키(또는 새 저장소), 지금까지 흩어져 만든 모든 루틴 문서와 체크리스트.
⚠️ 이 챕터의 실습은 내 랩·합법 플랫폼 전용입니다. 허가 없는 시스템에 적용하면 범죄입니다. 플레이북에 담기는 명령들은 HTB·TryHackMe 같은 합법 학습 플랫폼과 내 랩에서 검증한 것들이어야 합니다.
성격 안내: 오늘은 프로젝트 챕터입니다 — 새 기술이 아니라, 여러분의 지금까지를 하나의 매뉴얼로 조립하는 날입니다.

지금까지 여러분은 여러 문서를 만들었습니다. 기법 분류표, privesc 체크리스트, 열거 루틴, Medium 가이드, AD 경로 주석. 그런데 이 문서들은 각각의 순간에는 훌륭했지만 전투 중에 펼치기엔 흩어져 있습니다. "새 머신을 받으면 처음에 뭘 치는가"부터 "막혔을 때 어디로 돌아가는가"까지를 한 곳에서 펼칠 수 있어야 합니다.

오늘 만드는 것이 침투 플레이북(penetration testing playbook) — 실전에서 펼치는 개인 매뉴얼이자, 앞으로 평생 개정될 살아있는 문서입니다. 완벽하게 만들려 하지 마세요. v1은 "지금 실력의 사진"일 뿐입니다.

1. 학습 목표

이 챕터를 끝내면 다음을 할 수 있습니다:

흩어진 루틴 문서들을 8개 절 구조의 플레이북으로 통합한다
각 절에 "복붙해서 바로 쓸 수 있는" 명령 카드를 배치한다
"막힘 대처 트리"를 만들어 정체 상황의 행동 순서를 고정한다
각 절에 내 write-up 링크를 붙여 검증된 사례로 연결한다
플레이북 v1.0을 선언하고 개정 규칙을 정한다

2. 배경 지식 — 오늘의 도구와 개념

오늘의 도구 한눈에 보기

구분	내용
언어·환경	마크다운 + 개인 위키(Git 관리)
오늘의 명령	새 공격 명령 없음 — 검증용 `grep -rn` 정도
필요한 개념	명령 카드, 막힘 대처 트리, 살아있는 문서, 버전 선언
오늘의 산출물	플레이북 저장소(8개 절 + README + 막힘 트리) v1.0

2-1. 플레이북이 위키와 다른 점

개인 위키(Step 89)가 "아는 것의 창고"라면, 플레이북은 "손이 가는 순서의 책"입니다. 차이는 문장 형태에서 드러납니다.

위키 문서: "LFI란 서버 측 파일을 읽는 취약점이다…" (설명)
플레이북 문서: ?file=../../../etc/passwd → root:x:0:0: 보이면 확정 (동작)

플레이북의 문장은 전부 동사로 시작해야 합니다. "확인한다, 대입한다, 스캔한다." 개념이 궁금해지면 플레이북에서 위키로 링크를 타면 되고, 그래서 두 문서는 분리합니다.

2-2. 8개 절 구조 — 이 책이 제안하는 골격

절	담는 것	재료가 되는 과거 스텝
01 정찰	nmap 템플릿, 스캔 순서	Step 81, 268
02 서비스별 열거	웹/SMB/FTP/SSH… 서비스별 명령 카드	Step 265~270
03 침투 패턴	입구 벡터별 판단 기준	Step 105, 270
04 리눅스 privesc	권한 상승 체크리스트	Step 125~126, 259
05 윈도우 privesc	권한 상승 체크리스트	Step 260
06 AD	도메인 루트(열거→Roasting→경로)	Step 261~263, 271
07 피벗팅	내부망 이동	Step 264
08 막힘 대처 트리	정체 시 행동 순서	Step 269, 270

여러분의 경험 분포에 맞게 가중치를 조절하세요. 아직 피벗팅 경험이 얕으면 07은 한 장으로 시작하면 됩니다 — 빈 절도 자리만 있으면 됩니다.

2-3. 명령 카드 — 복붙 가능성이 품질 기준

플레이북의 기본 단위는 명령 카드입니다. 한 장의 완성 조건은 "전투 중에 이 칸을 통째로 복사해 치면 되는가"입니다.

## nmap — 새 머신의 첫 5분
# 1차: 기본 (빠름)
nmap -sV -sC 대상IP -oN nmap_default.txt
# 2차: 전체 포트 (백그라운드로)
nmap -p- --min-rate 2000 대상IP -oN nmap_all.txt
# 3차: UDP 상위 (시간 걸림)
sudo nmap -sU --top-ports 100 대상IP -oN nmap_udp.txt

주의할 점 — 검증되지 않은 명령은 싣지 마세요. "인터넷에서 본 건데 나중에 쓸지도"는 플레이북이 아니라 스크랩북입니다. 직접 쳐서 결과를 본 명령만 카드가 됩니다. 그것이 이 문서를 HackTricks 사본과 구분하는 가치입니다.

2-4. 막힘 대처 트리 — 감정을 절차로 바꾸기

공략이 정체됐을 때의 진짜 적은 기술 부족이 아니라 패닉의 무작위성입니다. 같은 것을 반복해서 치거나, 갑자기 엉뚱한 것을 시도하거나. 막힘 대처 트리는 그 순간의 행동을 미리 정해 둔 절차입니다.

30분 정체 감지
 1. 열거 재검토 — 스캔 결과에 아직 안 본 포트/페이지가 있나
 2. 자산 목록 × 미시도 표면 곱하기 (Step 269)
 3. 서비스별 HackTricks 페이지 확인
 4. 더 넓은 스캔 — 전체 포트, UDP, 대형 워드리스트, vhost
 5. 24시간 방치 후 재시도

핵심은 위에서부터 순서대로만 한다는 것입니다. 트리가 있으면 "뭘 할지 모르겠다"는 불안이 "지금 2번을 하고 있다"는 위치 감각으로 바뀝니다.

2-5. 살아있는 문서 — v1.0과 개정 규칙

플레이북은 완성품이 아니라 버전입니다. v1.0은 지금 실력의 사진이고, 새 머신이나 대회를 치를 때마다 배운 것 하나 이상을 반영해 v1.1, v1.2로 갑니다. Git으로 관리하면 개정 이력이 곧 성장 이력입니다 — 1년 뒤 git log가 여러분의 성장 그래프를 그려 줄 것입니다.

3. 따라 하기

3-1. 저장소와 뼈대 만들기 — 실측

위키 안에(또는 별도 저장소로) playbook/ 디렉터리를 만들고 8개 절의 뼈대를 세웁니다.

입력 (Git Bash):

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

그리고 최소 파일들을 채웁니다 — 아래는 각 파일의 시작 형태입니다.

playbook/README.md:

# 나만의 침투 플레이북 v1.0
새 머신을 받으면 이 문서부터 펼친다.

## 목차
- [01 정찰](01_정찰/nmap_템플릿.md)
- [02 서비스별 열거](02_서비스별_열거/웹.md)
- [04 리눅스 privesc](04_리눅스_privesc/체크리스트.md)
- [막힘 대처 트리](막힘_대처_트리.md)

## 개정 규칙
새 머신/대회마다 배운 것 1개 이상 반영한다.

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

# nmap 명령 카드
## 1차: 빠른 확인
nmap -sV -sC 대상IP -oN nmap_default.txt
## 2차: 전체 포트
nmap -p- --min-rate 2000 대상IP -oN nmap_all.txt
## 3차: UDP 상위
sudo nmap -sU --top-ports 100 대상IP -oN nmap_udp.txt

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

# 리눅스 권한 상승 체크리스트
- [ ] sudo -l
- [ ] SUID: find / -perm -4000 -type f 2>/dev/null
- [ ] cron: cat /etc/crontab; ls -la /etc/cron.*
- [ ] 커널/배포판 버전: uname -a; cat /etc/os-release
- [ ] 쓰기 가능한 PATH 폴더: echo $PATH

왜 하는가: 뼈대를 먼저 세우는 이유는 "빈 절"을 보이게 하기 위해서입니다. 빈 절은 실패가 아니라 앞으로 채울 지도입니다.

3-2. 검색 가능성 검증 — 실측

플레이북이 커져도 전투 중에 찾을 수 있는지, 만들자마자 검증합니다.

입력 (2026-09-09 실측, Git Bash):

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

출력 (2026-09-09 실측):

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

playbook/막힘_대처_트리.md:4:2. 서비스별 HackTricks 페이지 확인

읽는 법: 명령의 일부만 기억나도(perm -4000), 행동의 키워드만 기억나도(HackTricks) 문서가 걸려야 합니다. 이것이 Step 89의 "검색 가능성" 원칙의 플레이북 버전입니다 — 전투 중에는 완성된 문장이 아니라 단편 키워드로 검색하니까요.

왜 하는가: 지금 파일이 다섯 개일 때 검색이 안 되면, 쉰 개가 됐을 때는 영원히 안 됩니다. 구조의 검증은 작을 때 합니다.

3-3. 흩어진 문서 통합 — 가져오기와 추출

이제 과거 문서들에서 명령 카드를 추출합니다. 순서가 있습니다.

Step 105의 기법 분류표 → 03 침투 패턴 절의 재료 (기법별 "징후"가 판단 기준이 됩니다)
Step 259~260의 체크리스트 → 04, 05 절로 이동 (원본은 위키에 두고 링크)
Step 268~269의 열거·자산 목록 규칙 → 01, 02 절의 서두 지침으로
Step 271의 AD 경로 주석 → 06 절의 검증 사례 링크로
Step 270의 Medium 가이드 → 03 절의 입구 우선순위 표로

이동이 아니라 추출입니다 — 위키의 설명 문서는 그대로 두고, 플레이북에는 동작 부분만 옮긴 뒤 "상세: [위키 문서]" 링크를 겁니다.

3-4. 막힘 대처 트리 작성

playbook/막힘_대처_트리.md를 2-4의 골격으로 만들되, 여러분의 기록으로 순서를 검증하세요. Medium 종합 표(Step 270)에서 "막혔을 때 실제로 먹혔던 행동"이 무엇이었나요? 그 행동이 트리의 위로 올라와야 합니다.

책의 골격과 다른 순서가 나오면 그것이 정답입니다 — 이 문서는 교과서가 아니라 내 과거 데이터의 압축이어야 하니까요.

3-5. 검증 사례 링크 — 내 write-up이 증거

각 절의 명령 카드 옆에, 그 명령이 실제로 먹혔던 내 공략 기록을 링크합니다.

## 웹 디렉터리 스캔
gobuster dir -u http://대상IP -w /usr/share/wordlists/dirb/common.txt
> 검증 사례: [M-3 머신 write-up](../../writeups/M-3.md) — /backup 발견에 사용

왜 하는가: "내가 실제로 성공시킨 명령"과 "어디선가 본 명령"은 전투 중 신뢰도가 다릅니다. 링크가 없는 카드는 "미검증" 표시를 붙여 두고, 다음 머신에서 검증되면 링크로 교체하세요. 이 규칙 하나가 플레이북의 품질을 계속 올립니다.

3-6. v1.0 선언과 개정 규칙

마지막으로 README에 선언합니다.

## 버전
- v1.0 (2026-09-XX): 첫 완성. 8개 절 뼈대 + 명령 카드 N장.
- 개정 규칙: 새 머신/대회마다 배운 것 1개 이상 반영. 반영 즉시 커밋.

그리고 커밋합니다 — 플레이북 v1.0. 이 커밋이 기준점입니다. 반년 뒤 이 커밋과 그때의 차이가 곧 여러분의 성장 폭입니다.

4. 미션과 연습문제

미션 — 플레이북 v1.0 완성

8개 절 구조의 playbook/ 저장소를 만들고 각 절에 명령 카드를 1장 이상 배치한다
각 카드가 "복붙 가능"한지 점검하고, 검증된 명령만 싣는다
막힘_대처_트리.md를 내 공략 기록 데이터로 순서를 정해 작성한다
각 절에 내 write-up 검증 사례 링크를 1개 이상 건다
grep -rn 검색 테스트 2개를 통과하고, v1.0 커밋을 남긴다

연습문제

문제 1. 플레이북과 개인 위키의 차이를 문장 형태의 관점에서 설명해 보세요.

문제 2. 명령 카드의 완성 조건인 "복붙 가능성"이 의미하는 것과, 그것이 품질 기준이 되는 이유를 말해 보세요.

문제 3. 막힘 대처 트리의 핵심이 "내용"이 아니라 "순서 고정"인 이유를 설명해 보세요.

문제 4. 검증되지 않은 명령을 플레이북에 싣지 말아야 하는 이유를, HackTricks 같은 공개 문서와의 차이로 설명해 보세요.

5. 모범 답안과 완료 기준

미션 모범 답안

3-1~3-6의 흐름이 곧 뼈대입니다. 8개 절 디렉터리, 절당 카드 1장 이상, 막힘 트리 5단계, 검증 사례 링크, v1.0 커밋. 카드가 적어도 괜찮습니다 — v1은 사진이지 백과사전이 아닙니다.

검증하는 법: ① find playbook -name "*.md"로 8개 절의 파일이 보이는가. ② grep -rn "perm -4000" playbook 같은 단편 키워드 검색이 문서를 찾는가. ③ 각 카드에 검증 사례 링크 또는 "미검증" 표시가 있는가. ④ 막힘 트리의 순서에 내 기록 근거가 있는가. ⑤ git log에 v1.0 커밋이 있는가.

연습문제 해답

문제 1 해답. 위키는 "아는 것의 창고"로 설명 문장("LFI란 ~이다")이 중심이고, 플레이북은 "손이 가는 순서의 책"으로 동작 문장("확인한다, 대입한다")이 중심입니다. 플레이북에서 개념이 궁금하면 위키로 링크를 타는 구조이므로 둘은 분리합니다.

문제 2 해답. 복붙 가능성은 "전투 중에 이 칸을 통째로 복사해 치면 동작하는가"라는 뜻입니다. 전투 중에는 명령을 기억에서 재구성할 여유가 없고, 재구성 과정에서 오타와 옵션 누락이 생깁니다. 복붙 가능한 카드만이 시간 압박 속에서도 정확하게 재사용되므로, 그것이 카드의 품질 기준이 됩니다.

문제 3 해답. 정체 상황의 진짜 적은 패닉의 무작위성이기 때문입니다. 트리의 각 항목은 대부분 이미 아는 행동이지만, 패닉 상태에서는 그 행동들을 무작위 순서로, 혹은 같은 것만 반복해서 실행합니다. "위에서부터 순서대로만"이라는 고정이 불안을 위치 감각("지금 2번을 하고 있다")으로 바꾸는 것이 트리의 기능입니다.

문제 4 해답. HackTricks는 모든 가능성의 목록이고, 플레이북은 내가 검증한 것의 목록입니다. 미검증 명령이 섞이면 전투 중 "이게 됐던 건가"를 매번 판별해야 해서 플레이북의 신뢰가 무너집니다. 공개 문서는 참고서, 플레이북은 내 손에 맞춘 도구 상자 — 도구 상자에는 써 본 도구만 넣습니다.

완료 기준 체크리스트

[ ] 8개 절 구조로 플레이북 뼈대를 만들었다
[ ] 각 절에 복붙 가능한 명령 카드를 1장 이상 배치했다
[ ] 검증된 명령만 실었고, 미검증은 표시했다
[ ] 막힘 대처 트리를 내 기록 데이터로 순서를 정했다
[ ] 각 절에 내 write-up 검증 사례 링크를 걸었다
[ ] grep -rn 검색 테스트 2개를 통과했다
[ ] 미션: v1.0 선언 커밋과 개정 규칙을 README에 남겼다

6. 흔한 실수와 해결

벽 1. 완벽하게 만들려다 영원히 v1.0이 안 나온다

증상: "카드가 아직 열 장밖에 없는데…"라며 선언을 미룹니다.
원인: v1.0을 완성품으로 오해했습니다. 플레이북은 버전이지 성취가 아닙니다.
해결: 빈 절이 있어도 선언하세요. "v1.0 = 지금 실력의 사진"이라는 정의를 README에 그대로 적으면 마음이 편해집니다. 평생 개정하는 문서의 첫 사진은 초라해도 됩니다 — 사진의 가치는 나중에 비교할 때 생깁니다.

벽 2. 인터넷 문서를 통째로 베끼고 있다

증상: 어느새 HackTricks의 요약본을 만들고 있습니다.
원인: "빈 절을 빨리 채우고 싶다"는 조급함.
해결: 미검증 명령은 싣지 않는 규칙으로 되돌아가세요. 베낀 명령은 전투 중 신뢰가 없어 결국 공식 문서를 다시 열게 됩니다 — 그럴 바엔 플레이북에 링크 한 줄만 적는 것이 낫습니다.

벽 3. 문서가 위키와 플레이북에 이중으로 존재해 어긋난다

증상: 위키를 고쳤는데 플레이북은 옛 내용입니다.
원인: 이동이 아니라 복사를 했습니다.
해결: 원칙으로 정리하세요 — 설명은 위키에만, 동작 카드는 플레이북에만. 플레이북 카드에 개념 설명이 필요하면 "상세: [위키 문서]" 링크로 연결합니다. 한 내용은 한 곳에만 존재해야 합니다.

벽 4. 막힘 대처 트리를 만들었는데 정작 막힐 때 안 펼친다

증상: 트리를 잊고 또 같은 명령을 반복하고 있었습니다.
원인: 트리가 행동 습관에 연결되지 않았습니다. 문서는 만들어도 발동 조건이 없습니다.
해결: 발동 조건을 기계적으로 정하세요 — "타이머 30분" 또는 "같은 유형의 명령 3회 연속 무산". 조건이 감지되면 무조건 트리 문서를 여는 것부터. 조건 없는 절차는 장식입니다.

벽 5. grep 검색이 아무것도 못 찾는다

증상: 분명 적어 둔 명령인데 grep -rn에 안 걸립니다.
원인 둘 — 검색 키워드와 문서의 표현이 다르거나(“권한상승” vs “privesc”), 파일이 플레이북 밖에 있거나.
해결: 명령 카드에는 명령 원문 자체를 반드시 포함하세요 — 명령 원문은 검색 키워드로 가장 강력합니다. 그리고 검색은 playbook/ 안에서 실행하는 것을 습관으로. 검색이 안 먹히는 카드는 표현을 고쳐야 하는 신호입니다.

7. 정리

오늘의 개념

개념	한 줄 설명
침투 플레이북	실전에서 펼치는 개인 매뉴얼. 위키(창고)와 분리된 손의 책
명령 카드	플레이북의 기본 단위. 완성 조건은 "복붙해서 바로 쓸 수 있는가"
8개 절 구조	정찰·서비스별·침투 패턴·리눅스·윈도우·AD·피벗팅·막힘 트리
막힘 대처 트리	정체 시 행동 순서를 고정한 절차. 핵심은 내용이 아니라 순서 고정
검증 사례 링크	카드 옆의 "내가 성공시킨 기록" 링크. 신뢰의 증거
v1.0 선언	지금 실력의 사진. 평생 개정되는 문서의 첫 기준점

오늘의 명령

명령	용도
`mkdir -p playbook/01_정찰 ...`	8개 절 뼈대 생성
`grep -rn "키워드" playbook`	플레이북 검색 가능성 검증
`find playbook -name "*.md"`	절별 파일 존재 확인
`git commit -m "플레이북 v1.0"`	버전 기준점 선언

명령어보다 중요한 감각

플레이북의 완성도는 페이지 수가 아니라 신뢰도로 잽니다. "여기 적힌 것은 전부 내 손으로 검증됐다"는 확신이 있는 문서는 전투 중 패닉을 줄여 줍니다. 그리고 이 문서의 진짜 보상은 1년 뒤에 옵니다 — v1.0 커밋과 그때의 차이를 git log로 보는 순간, 여러분은 자기 성장을 추상이 아니라 diff로 확인하게 됩니다. 오늘의 초라한 첫 사진이 그 비교를 가능하게 합니다.

전부 체크되면 Step 272 완료입니다. 사이드바의 체크박스를 눌러 진도를 저장하세요.