Step 257. HTB Easy 2대 (누적 4) — 입구의 레퍼토리를 넓히다

Level 3 — CTF 실전과 공격 스킬 심화 | 난이도 ★★★★☆ | 예상 소요 시간 8시간+ (머신당 4시간 안팎)

전제: Step 256(Easy 2대 독립 해결)을 마쳤다. 루틴 문서, privesc 패턴 노트, 머신 로그 습관은 이미 갖춰져 있다.

준비물: Step 256의 HTB 환경·머신 로그 2부·"Easy 패턴" 정리, 플레이북(루틴 문서의 발전형).
⚠️ 이 챕터의 실습은 내 랩·합법 플랫폼 전용입니다. 허가 없는 시스템에 적용하면 범죄입니다. Hack The Box(hackthebox.com)는 운영자가 공격 연습용으로 공식 개방한 합법 학습 플랫폼입니다 — 이 플랫폼의 머신 외에는 오늘의 기술을 쓰지 않습니다.
플랫폼 안내: 이 챕터의 HTB 화면과 명령 출력은 전부 화면 예시입니다. 실제 공략은 여러분이 직접 합니다.

두 대를 혼자 뚫었으니, 이제 여러분에게는 "내가 잘하는 입구"가 생겼습니다. 그리고 그것이 오늘의 문제입니다. 사람은 성공한 경로를 반복하게 되어 있습니다 — 웹으로 뚫은 사람은 다음에도 웹만 봅니다. 머신마다 입구는 다른데(웹 취약점, FTP 익명, SMB 공유, 기본 자격증명, 커널 버그…), 내 레퍼토리가 한 종류면 입구가 안 맞는 머신 앞에서 무력해집니다.

오늘의 과제는 누적 4대라는 숫자가 아니라 유형의 다양화입니다. 의식적으로 "아직 안 해 본 입구"를 가진 머신을 고르고, 그 경험을 표로 누적하는 것. 네 대가 모이면 비로소 패턴이 통계처럼 보이기 시작합니다.

1. 학습 목표

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

초기 침투 벡터(입구)를 유형별로 분류하고 내 경험의 편중을 진단한다
지금까지와 다른 유형의 머신을 의도적으로 선정한다
user 쉘까지의 소요 시간을 이전 대비 비교해 성장을 계량한다
새로 만난 서비스와 기법을 플레이북에 즉시 추가하는 습관을 굳힌다
"입구 유형 × 발견 방법" 표를 만들어 누적 4대의 자산화를 완성한다

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

오늘의 도구 한눈에 보기

구분	내용
언어·환경	HTB Easy 머신 2대(신규 유형) + 공격 머신 + 누적 로그
오늘의 명령	지금까지의 전부 + 머신이 요구하는 것(새 서비스면 새 도구)
필요한 개념	초기 침투 벡터 분류, 레퍼토리 편중, 플레이북, 소요 시간 비교
오늘의 산출물	누적 4대 + 입구 유형 표 + 플레이북 v1

2-1. 입구 유형의 지도

HTB Easy 머신의 초기 침투 벡터는 대략 여섯 갈래로 분류됩니다.

① 웹 취약점      — 업로드 우회, 인젝션, 알려진 CMS/프레임워크 취약점
② 익명 서비스    — FTP anonymous, 익명 SMB, 인증 없는 DB
③ 기본·약한 자격증명 — 기본 계정, 재사용 암호, 무차별 대입
④ 정보 노출      — 소스 코드, 백업 파일, 주석, git 저장고 속 비밀
⑤ 공개 익스플로잇 — 알려진 CVE 그대로 (버전이 곧 답)
⑥ 설정 꼬임      — 쓰기 가능 공유, 잘못된 권한, 예측 가능한 경로

각 유형은 요구하는 기술이 다릅니다. ①은 웹 열거의 깊이, ②③은 서비스별 점검 루틴, ④는 꼼꼼함, ⑤는 버전 대조와 익스플로잇 수정 능력, ⑥은 시스템 이해를 요구합니다. 한 유형만 잘해서는 이 지도를 다 못 덮습니다.

2-2. 편중 진단 — 나는 지금 어디에 치우쳐 있는가

레퍼토리 확장의 첫 단계는 현황 파악입니다. Step 255의 Starting Point 노트와 Step 256의 로그 2부를 펼치고, 각 머신의 입구를 2-1의 분류로 태깅하세요.

예시 (화면 예시):
Starting Point 머신들 — ② 익명 서비스, ③ 기본 자격증명 위주
Easy #1 — ① 웹 (업로드 우회)
Easy #2 — ① 웹 (CMS 취약점)
→ 진단: ①에 편중. ④⑤⑥ 경험 없음

이 진단이 곧 오늘의 머신 선정 기준입니다 — "안 해 본 유형을 가진 Easy"를 고릅니다. 머신의 입구를 미리 아는 것은 스포일러이므로, 완벽한 선정은 불가능합니다. 대신 커뮤니티의 비공식 태그(웹 중심, AD, 기타)나 머신 설명 문구 수준의 정보로 추측하고, 뚫어 보니 겹치는 유형이었다면 그것도 기록합니다.

2-3. 플레이북 — 루틴 문서의 다음 단계

Step 251에서 시작한 루틴 문서가 여기서 플레이북(playbook)으로 격상됩니다. 차이는 "명령의 순서"에서 "상황별 대응표"로 가는 것입니다.

## 플레이북 조항 예시
- 포트 21(ftp) 발견 시 → anonymous 로그인 시도 → 되면 전체 목록 → get
- 포트 445(smb) 발견 시 → smbclient -L -N → $ 없는 공유 → recurse on; mget *
- 웹 80 발견 시 → 경로 스캔(작은 목록) → /robots.txt, /.git, 백업 확장자 확인 → 큰 목록 재스캔
- 버전 문자열 발견 시 → searchsploit → exploit-db 원문 대조 → 수정 사항 메모

새 기법을 만날 때마다 "어떤 신호 → 무슨 명령"의 한 조항으로 추가합니다. 머신 안에서 검색한 시간이 다음 머신에서 사라지는 것 — 이것이 플레이북의 효용입니다.

2-4. 성장의 계량 — user까지의 시간

"실력이 늘고 있는가"를 감각이 아니라 숫자로 봅니다. 기준 지표는 user 쉘까지의 시간입니다 — 머신마다 난이도가 다르므로 절대값보다 추이가 중요합니다.

예시 기록 (화면 예시):
Easy #1: user까지 3h 20m, root까지 +35m
Easy #2: user까지 2h 05m, root까지 +1h 10m
Easy #3: user까지 1h 40m, root까지 +40m

시간이 줄어드는가 — 줄고 있다면 어떤 단계에서 줄었는가(정찰이 빨라졌는가, 가설의 첫 선택이 맞았는가)까지 읽는 것이 진짜 분석입니다. 이 데이터는 Step 258의 시간 제한 훈련에서 기준선이 됩니다.

2-5. "열거로 돌아가기" — 모든 유형 공통의 회귀점

유형이 달라도 막힘의 처방은 하나로 수렴합니다: 열거 결과에 답이 이미 있는 경우가 대부분입니다. 새 유형의 머신에서 당황할 때 — "이 서비스는 처음 보는데" — 의 순서:

1. 이 서비스의 기본 열거 명령이 무엇인지 검색 (5분)
2. 플레이북에 조항이 있나 확인, 없으면 새로 쓴다
3. 그래도 안 되면 정찰로 회귀 — 놓친 포트, 더 깊은 경로 스캔
4. "새로운 서비스"는 사실 새로운 것이 아니다 — 열거하고 읽는 것은 같다

3. 따라 하기

오늘도 3번 섹션은 절차입니다. 화면은 전부 예시입니다.

3-1. 머신 선정 — 편중 진단 먼저

2-2의 진단을 로그 맨 위에 쓰고 시작합니다 (예시):

# Step 257 개시 — 2026-09-11
## 편중 진단
- 지금까지 입구: ①웹 2대, ②익명 1대, ③기본자격증명 1대
- 미경험: ④정보 노출, ⑤공개 익스플로잇(버전→CVE), ⑥설정 꼬임
- 이번 2대 목표: ④ 또는 ⑤ 유형이 기대되는 머신
## OS 다양화: #3는 윈도우 Easy로 (Step 254 루틴 시험)

리눅스와 윈도우를 번갈아 가는 것도 유형 다양화의 한 축입니다. Step 254에서 만든 윈도우 루틴이 실전 Easy에서 통하는지 확인할 기회입니다.

3-2. 새 서비스를 만났을 때의 15분

낯선 서비스가 열린 포트에서 보이면, 검색 전에 15분 절차를 둡니다 (화면 예시):

nmap -sV -p- $TARGET -oN nmap-full.txt

PORT     STATE SERVICE VERSION
21/tcp   open  ftp     ProFTPD 1.3.5
22/tcp   open  ssh     OpenSSH 7.2p2 Ubuntu
80/tcp   open  http    Apache httpd 2.4.18

읽는 법: ProFTPD를 처음 본다고 가정해 봅시다. 15분 절차: ① 서비스명+버전을 그대로 검색(5분), ② 알려진 취약점이 있으면 신뢰할 만한 원문(exploit-db, NVD) 확인(5분), ③ 플레이북에 조항 초안 작성(5분). 이 15분이 지나도 답이 없으면 이 경로는 일단 후순위로 내리고 다른 포트로 갑니다 — 30분 규칙은 새 서비스에서도 유효합니다.

3-3. 유형별 첫 시도 순서 — 서비스가 다른 머신의 예

입구가 SMB 쪽인 머신의 초반 흐름입니다 (화면 예시):

smbclient -L //$TARGET -N

	Sharename       Type      Comment
	---------       ----      -------
	backups         Disk
	IPC$            IPC       Remote IPC

smbclient //$TARGET/backups -N -c 'recurse on; ls'

  \config.old.bak                 A     2048  ...
  \notes.txt                      A      312  ...

읽는 법: 익명으로 읽히는 공유 안의 백업 파일과 메모 — 이것이 ②(익명 서비스)와 ④(정보 노출)가 겹치는 전형입니다. config.old.bak 같은 파일은 내려받아 정독하는 것이 다음 행동입니다. 웹 머신과 달리 "스캔 → 바로 취약점"이 아니라 "열거 → 문서 읽기 → 단서 조합"의 리듬입니다.

3-4. 머신 로그에 추가할 두 줄

Step 256의 로그 형식에 오늘부터 두 줄이 추가됩니다.

## 완료
- user: 1h 40m (입구 유형: ④ 정보 노출 — smb 공유 속 bak 파일)
- root: +40m (패턴: 커널 버전 → 공개 익스플로잇)
- 힌트 사용: 없음
- 입구 유형 태그: ④           ← 추가 1: 분류 번호
- 플레이북 추가: smb 공유 백업파일 우선 열람 조항  ← 추가 2: 이번 판의 자산

"이 머신에서 배운 것이 플레이북 어느 조항으로 정착했는가"까지 적어야 그 판의 학습이 닫힙니다.

3-5. 누적 4대 — 입구 유형 표 완성

두 대를 끝내면 오늘의 본산인 표를 완성합니다 (예시):

## 입구 유형 × 발견 방법 (누적 4대 + Starting Point)
| 머신 | OS | 입구 유형 | 발견 방법 | user까지 |
|------|-----|-----------|-----------|----------|
| Easy #1 | 리눅스 | ① 웹(업로드) | gobuster 경로 스캔 | 3h 20m |
| Easy #2 | 리눅스 | ① 웹(CMS) | 버전 검색 → exploit-db | 2h 05m |
| Easy #3 | 윈도우 | ② 익명 SMB | smbclient -N | 1h 50m |
| Easy #4 | 리눅스 | ④ 정보 노출 | 백업 파일 속 자격증명 | 1h 40m |

## 읽히는 것
- user까지 시간이 3h 20m → 1h 40m으로 단축 — 정찰 루틴의 고정 효과
- ① 편중 해소 시작. ⑤⑥은 아직 미경험 → 다음 2대(Step 258)의 목표

읽는 법: 이 표는 두 가지를 보여 줍니다 — 내가 무엇을 할 줄 아는가(경험한 유형), 그리고 시간이라는 성장 곡선. 빈 칸(⑤⑥)은 부끄러움이 아니라 다음 과제의 목록입니다.

4. 미션과 연습문제

미션 — 누적 4대와 입구 유형 표

편중 진단을 쓰고, 미경험 유형이 기대되는 Easy 2대를 선정합니다 (OS도 한 대는 바꿔 보세요)
Step 256의 규칙(독립 해결, 로그, 30분 규칙)을 그대로 적용해 2대를 해결합니다
각 머신의 입구를 2-1의 분류로 태깅하고 로그에 기록합니다
user 쉘까지의 시간을 이전 머신들과 비교해 추이를 적습니다
새로 만난 서비스·기법은 플레이북 조항으로 즉시 추가합니다
3-5의 "입구 유형 × 발견 방법" 표를 완성하고, 표에서 읽히는 것을 세 줄 이상 씁니다

연습문제

문제 1. "같은 Easy라도 유형을 골라 다양하게 먹어야 한다"는 전략의 근거를, 레퍼토리 편중의 위험으로 설명해 보세요.

문제 2. 낯선 서비스를 만났을 때의 15분 절차 세 단계를 쓰고, 왜 15분에서 멈추는지 30분 규칙과 연결해 설명해 보세요.

문제 3. "user까지의 시간"을 성장 지표로 쓸 때 절대값보다 추이를 봐야 하는 이유를 설명해 보세요.

문제 4. 루틴 문서(Step 251)와 플레이북의 차이를 "명령의 순서"와 "상황별 대응표"라는 표현을 써서 설명해 보세요.

5. 모범 답안과 완료 기준

미션 모범 답안

플레이북에 새로 정착한 조항의 형태 예시입니다:

## 플레이북 추가분 (Step 257)
- [SMB] $ 없는 공유 발견 → recurse on; ls → .bak/.old/notes 계열 파일 우선 get → 정독
- [윈도우 Easy] 445+3389 조합이면 익명 SMB 먼저, 안 되면 웹/기타 포트 확인
- [시간 기록] user 도달 시각은 로그 완료 절에 반드시 — Step 258 기준선 데이터

검증하는 법: ① 누적 4대의 user/root 제출 기록이 HTB 프로필에 있는가. ② 2대의 입구 유형이 이전 2대와 모두 같은 태그가 아닌가(다양화가 실제로 일어났는가). ③ 입구 유형 표에 "발견 방법"이 명령 수준으로 적혀 있는가. ④ 플레이북에 이번 2대에서 온 조항이 최소 1개 이상 추가됐는가. ⑤ 시간 추이에 대한 해석이 표 아래에 있는가.

연습문제 해답

문제 1 해답. 성공 경험은 편향을 만듭니다 — 웹으로만 뚫어 온 사람은 새 머신에서도 웹만 보고, 입구가 SMB인 머신에서는 "답이 없는 머신"처럼 느끼며 시간을 태웁니다. 실전(그리고 시험)에서는 입구를 골라 받을 수 없으므로, 레퍼토리의 구멍이 곧 불합격 포인트가 됩니다. 유형을 의도적으로 다양화하는 것은 "여섯 갈래 중 어느 것이 와도 첫 15분의 행동이 있다"는 상태를 만드는 훈련입니다.

문제 2 해답. ① 서비스명+버전을 그대로 검색, ② 알려진 취약점이 있으면 원문(exploit-db, NVD) 확인, ③ 플레이북 조항 초안 작성. 15분에서 멈추는 이유는 이 작업이 "조사"이지 "검증"이 아니기 때문입니다 — 낯선 서비스의 취약점 공략은 문서만으로 끝나지 않고 환경 수정이 따라붙어 시간이 무한정 늘 수 있습니다. 15분은 "이 경로가 살아 있는가"를 심판하는 시간이고, 살아 있으면(명확한 취약점이 확인되면) 본격 검증 단계로 넘겨 30분 규칙의 적용을 받게 합니다.

문제 3 해답. 머신마다 난이도와 입구의 깊이가 다르므로 절대 시간은 비교 대상이 아닙니다 — 1시간짜리 머신과 5시간짜리 머신이 같은 Easy 라벨을 달고 있습니다. 추이를 보는 이유는 내 변수를 통제한 측정이 되기 때문입니다 — 같은 사람, 같은 루틴으로 연속된 머신을 풀 때 시간이 줄고 있다면, 그것은 루틴의 고정과 플레이북의 축적이 만든 성장입니다. 다만 추이도 머신 난이도 편차의 영향을 받으므로, "늘었다"는 확인보다 "어느 단계에서 줄었는가"를 읽는 것이 더 유용한 분석입니다.

문제 4 해답. 루틴 문서는 "모든 머신에서 항상 같은 순서로 치는 명령"의 목록입니다 — 정찰의 풀스캔, 쉘 획득 후의 sudo -l처럼 순서가 고정된 절차입니다. 플레이북은 거기에 조건이 붙습니다 — "포트 21이 보이면", "버전 문자열이 나오면"처럼 상황(신호)이 트리거이고 명령이 대응입니다. 루틴이 판의 뼈대라면, 플레이북은 뼈대 위에서 갈라지는 모든 분기점의 대응표입니다. 전자가 없으면 판이 흔들리고, 후자가 없으면 분기점마다 검색부터 다시 합니다.

완료 기준 체크리스트

[ ] 편중 진단을 문서로 작성했다
[ ] 미경험 유형의 Easy 2대를 선정·해결했다 (user+root)
[ ] 입구 유형 태그가 로그에 기록됐다
[ ] user까지 시간의 추이와 해석을 적었다
[ ] 플레이북에 새 조항이 추가됐다
[ ] 입구 유형 × 발견 방법 표를 완성했다
[ ] 표에서 읽힌 것(다음 목표 포함)을 세 줄 이상 썼다

6. 흔한 실수와 해결

벽 1. 뽑은 머신이 결국 같은 유형이었다

증상: "이번엔 다를 거야" 하고 골랐는데 뚫어 보니 또 웹 취약점입니다.
원인: 머신의 입구는 스포일러 없이는 정확히 알 수 없습니다 — 선정은 어디까지나 추측입니다.
해결: 실패가 아니라 데이터입니다. 로그에 "의도: ④, 실제: ①"로 기록하세요. 겹친 유형이라도 그 안의 세부 기법(업로드 우회 vs 인젝션)이 다르면 레퍼토리는 넓어진 것입니다. 완벽한 다양화는 수를 쌓아야 달성됩니다 — Step 258까지 포함한 누적 6대의 표에서 최종 점검하세요.

벽 2. 윈도우 머신을 골랐는데 리눅스 손버릇이 나온다

증상: 쉘을 얻고 ls -la, cat /etc/passwd를 치고 있습니다.
원인: 수십 대의 리눅스 근육이 윈도우를 덮습니다. 정상이며, 오늘이 교정 훈련입니다.
해결: Step 254의 윈도우 루틴을 로그 첫 페이지에 붙여 두세요 — 쉘 획득 후 첫 명령은 whoami /priv, 파일 찾기는 dir /s 계열, 프로세스는 Get-Process. 며칠 고생하면 손이 바뀝니다. 그리고 그 고생 자체가 기록 가치가 있습니다 — "윈도우 전환에 걸린 시간"도 로그에 적어 두면 Step 258의 시간 분석에서 변수로 보입니다.

벽 3. 새 서비스 조사가 두 시간을 삼켰다

증상: 낯선 서비스의 취약점을 찾다 보니 정찰이 끝나지 않았습니다.
원인: 15분 절차 없이 "조사"와 "검증"을 한 데 섞은 경우입니다.
해결: 타이머를 물리적으로 거세요 — 폰 알람 15분. 조사 시간이 끝나면 "이 경로는 살아 있는가"를 한 문장으로 적고, 살아 있으면 검증 단계(별도 30분 규칙), 아니면 후순위로. 검색 결과가 문서뿐이고 재현이 안 되는 경로는 Easy 머신의 답이 아닐 확률이 높습니다 — 출제자는 표준 기법 안에서 문제를 냅니다(Step 256).

벽 4. 시간 비교가 오히려 압박이 된다

증상: "지난번보다 느리다"는 생각에 조급해져 정찰을 건너뛰고 싶어집니다.
원인: 지표의 용도를 오해한 것입니다. 시간 추이는 채점이 아니라 진단 도구입니다.
해결: 느린 판의 로그를 더 자세히 읽으세요 — 느려진 단계가 어디인가. 정찰이 느렸다면 도구 문제(워드리스트, 대역), 가설이 느렸다면 우선순위 판단 문제, 상승이 느렸다면 패턴 노트 부족 문제입니다. "빨라지는 것"은 결과이지 목표가 아닙니다 — 목표는 정확한 루틴이고, 속도는 그 부산물입니다. 속도를 목표로 삼는 훈련은 Step 258에서 따로, 통제된 형태로 합니다.

벽 5. 플레이북이 "복붙 모음"이 되어 간다

증상: 조항은 늘어나는데 정작 머신 안에서 안 열게 됩니다.
원인: 조항이 "내가 겪은 형태"로 안 쓰여 있습니다 — 남의 글을 통째로 옮기면 검색이 안 됩니다.
해결: 조항의 형식을 강제하세요 — [신호] → [명령] → [다음 행동] 한두 줄. 긴 설명은 링크 한 줄로 밀어 내세요. 그리고 판이 끝날 때 "이번 판에서 실제로 연 조항"에 표시를 하세요 — 안 열리는 조항은 형태가 잘못된 것이니 다음 판 전에 다듬습니다. 플레이북은 문서가 아니라 도구이고, 도구는 쓰이는 것만 가치가 있습니다.

7. 정리

오늘의 개념

개념	한 줄 설명
초기 침투 벡터(입구)	머신에 처음 발을 디디는 경로 — 웹/익명 서비스/자격증명/정보 노출/CVE/설정 꼬임
레퍼토리 편중	성공 유형만 반복해 경험이 한쪽에 쏠리는 현상
플레이북	"신호 → 명령 → 다음 행동" 조항의 모음 — 루틴 문서의 발전형
user까지 시간	성장의 계량 지표 — 절대값이 아니라 추이와 단계별 분포로 읽는다
15분 절차	낯선 서비스의 조사 상한 — 검색 5, 원문 5, 조항 5

오늘의 명령어·도구

명령	하는 일
`smbclient //IP/공유 -N -c 'recurse on; ls'`	공유 전체 목록 재귀 열람
`searchsploit 서비스명 버전`	공개 익스플로잇 대조
`nmap -sV -p- $TARGET -oN 파일`	(변함없는) 정찰의 첫 명령
(문서) 편중 진단표	머신 선정 전에 쓰는 현황 파악
(문서) 입구 유형 × 발견 방법 표	누적 경험의 자산화

명령어보다 중요한 감각

네 대가 모이면 비로소 보이는 것들이 있습니다 — "입구는 결국 열거를 다 한 사람에게 열린다", "시간은 정찰이 아니라 망설임에서 간다", "새로운 서비스는 두렵지만 절차는 늘 같다". 이 문장들은 읽어서 생기지 않고, 표에 누적된 네 줄이 말해 줍니다. 그래서 오늘의 진짜 산출물은 플래그가 아니라 그 표입니다. 유형의 구멍(⑤⑥)이 남아 있다면 좋은 일입니다 — 다음 챕터의 시간 제한 훈련에서 그 구멍이 어떤 대가를 치르게 하는지, 이제는 시계를 보며 확인하게 됩니다.

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