Step 267. HTB Medium 1대 (누적 2) — 주연 서비스를 읽고, 막힘을 통계로
Level 3 — CTF 실전과 공격 스킬 심화 | 난이도 ★★★★☆ | 예상 소요 시간 2일(하루 2~3시간)
전제: Step 265(첫 Medium 독립 해결)와 Step 266(복기 + 재공략)을 마쳤다. 루틴 문서 v2의 개선점 5개를 펴 놓고 시작합니다.
- 준비물: HTB VPN 환경, 루틴 문서 v2, Step 265의 진척 로그(비교 기준), 단계별 시간 기록지.
- ⚠️ 이 챕터의 실습은 내 랩·합법 플랫폼 전용입니다. 허가 없는 시스템에 적용하면 범죄입니다. HackTheBox(HTB)는 합법 학습 플랫폼입니다 — 그 머신들 외에는 오늘의 기술을 쓰지 않습니다.
- 플랫폼 안내: 이 챕터의 HTB 화면과 출력은 전부 화면 예시입니다. 실제 풀이와 기록은 여러분이 직접 합니다.
두 번째 Medium은 다른 의미로 중요합니다. 첫 대에서 배운 패턴(열거 심화 + 가설 운영 + 리서치)이 우연이 아니라 재사용 가능한 실력인지 검증하는 판이기 때문입니다. 오늘의 주제는 둘입니다 — 첫 스캔에서 "이 머신의 주연은 무엇인가"를 빨리 읽는 감각, 그리고 막힘의 위치를 단계별로 기록해 통계로 만드는 습관. 두 대의 데이터로는 약점의 경향이, 이어지는 대수로는 약점의 지도가 그려집니다.
1. 학습 목표
이 챕터를 끝내면 다음을 할 수 있습니다:
- 첫 정찰 결과에서 머신의 유형(웹 중심/서비스 중심/AD 등)과 "주연 서비스"를 지목한다
- 주연 서비스 기준으로 HackTricks 리서치의 출발점을 정한다
- 첫 Medium과 다른 유형의 머신을 골라 루틴의 일반성을 검증한다
- 단계별 소요 시간과 막힘 위치를 기록해 첫 대와 비교한다
- 누적 2대의 막힘 통계로 "내가 어느 단계에서 막히는가"를 진단한다
2. 배경 지식 — 오늘의 도구와 개념
오늘의 도구 한눈에 보기
| 구분 | 내용 |
|---|---|
| 언어·환경 | HTB VPN + Kali — Step 265와 동일 환경 |
| 오늘의 명령 | 익숙한 정찰 명령 + whatweb, wappalyzer 계열의 식별 도구, 단계별 date 기록 |
| 필요한 개념 | 머신 유형 분류, 주연 서비스, 약점 단계의 통계적 진단 |
| 오늘의 산출물 | 누적 2대 root + 단계별 시간 비교표 + 막힘 통계 v1 |
2-1. 머신의 주연을 읽는다 — 첫 스캔이 정하는 것
모든 서비스가 같은 비중은 아닙니다. Medium 머신에는 보통 주연 서비스가 있습니다 — 입구와 체인의 대부분이 그 서비스를 중심으로 돌아가는, 그 머신의 주제입니다.
첫 정찰에서 주연을 읽는 단서는 이런 것들입니다.
- 비표준 포트에 뜬 서비스 (3000, 8000, 9000대의 웹/앱 서버)
- 버전이 정확히 찍힌 낯선 서비스 (이름을 모르는 서비스 = 그 머신의 주제일 확률 높음)
- 유난히 큰 웹 애플리케이션 (로그인, 검색, 업로드, API가 다 있는 사이트)
- 반대로, 흔한 22/80만 있고 웹이 단순하면 → 단서가 소스/경로 깊숙이 있는 유형
주연을 빨리 지목할수록 리서치가 빨라집니다. "이 머신은 무엇에 관한 머신인가"를 첫 30분 안에 문장으로 적어 보세요 — 틀려도 됩니다, 정찰이 깊어지며 고치면 됩니다. 지목 자체가 조사의 좌표를 줍니다.
2-2. 유형을 다르게 고르는 이유 — 루틴의 일반성 검증
첫 Medium이 웹 중심이었다면, 두 번째는 서비스 중심(SMB, DB, 메일 등)이나 다른 주제로 고르세요. 같은 유형을 연속으로 풀면 "웹 머신을 잘 푸는 사람"이 되지만, Medium 졸업에 필요한 것은 "유형이 바뀌어도 루틴이 서는 사람"입니다.
Step 252의 유형 분기 표를 기억하세요 — 정찰 결과가 분기를 정할 뿐, 루틴의 뼈대(정찰 → 식별 → 가설 → 검증 → 상승)는 유형이 달라도 같습니다. 두 번째 대에서 확인할 것은 이것입니다 — 뼈대가 유지되는가, 분기만 바뀌는가. 뼈대가 흔들리면 그 지점이 훈련 목록입니다.
2-3. HackTricks 리서치 — 주연 서비스의 공략 순서를 찾는다
주연이 정해지면 리서치의 출발점이 정해집니다. HackTricks(book.hacktricks.xyz)에는 서비스별 페이지가 있고, 각 페이지는 "이 서비스를 만나면 무엇부터 확인하는가"의 목록입니다 (화면 예시):
[리서치 루틴]
1. nmap 배너의 서비스명+버전을 그대로 HackTricks 검색창에
2. 해당 페이지의 'Enumeration' 절을 위에서부터 체크리스트처럼 실행
3. 페이지가 없으면 "서비스명 pentest", "서비스명 exploit" 검색
4. 찾은 공략 단계를 진척 로그에 '검증할 가설 목록'으로 옮김
핵심은 열거 정보가 곧 검색 키워드라는 것입니다. 배너 한 줄(Apache httpd 2.4.49)이 리서치의 전부를 열고, 그 리서치가 가설의 목록을 만듭니다. 정찰 → 식별 → 리서치 → 가설 목록 — 이 사슬이 Medium의 표준 공정입니다.
2-4. 막힘의 통계 — 두 대부터 시작되는 진단
Step 265에서 막힘마다 [열거/기법] 구분을 붙였습니다. 이제 그 기록을 단계별로 모읍니다.
[막힘 기록 서식]
막힘 #1 | 단계: 입구 발견 | 유형: 열거 부족 | 소요: 40분 | 돌파: vhost 스캔
막힘 #2 | 단계: 상승 | 유형: 기법 부족 | 소요: 55분 | 돌파: HackTricks cron 문서
머신 두 대의 막힘을 합치면 경향이 보이기 시작합니다.
[통계 예시 — 누적 2대]
| 단계 | 막힘 횟수 | 총 소모 시간 |
|------------|-----------|--------------|
| 정찰/입구 | 3회 | 2.5h |
| 침투 | 1회 | 1.0h |
| 권한 상승 | 4회 | 3.5h |
이 표가 말하는 것: "나는 상승에서 가장 많이, 가장 오래 막힌다." 이것이 느낌이 아니라 수치로 잡힌 약점입니다. 막힘은 무작위가 아닙니다 — 사람마다 막히는 단계에 경향이 있고, 그 경향을 아는 것이 다음 훈련의 순서를 정합니다. 대수가 쌓일수록 이 표는 정확해집니다.
3. 따라 하기
3-1. 머신 선정 — 첫 대와 다른 유형으로
선정 기준은 Step 265와 같되, 한 가지가 추가됩니다.
□ 커뮤니티 평가가 좋은가
□ 첫 Medium과 다른 유형인가 (웹 중심 ↔ 서비스 중심 ↔ 기타)
□ 주연이 될 서비스가 명확해 보이는가 (리뷰·태그로 유추)
로그 첫 줄에 씁니다: "선정: (이름) / 유형: ____ / 첫 대와 다른 점: ____".
읽는 법: "다른 유형"은 고통이 아니라 설계입니다. 첫 대에서 익힌 루틴이 낯선 지형에서도 서는지 확인하는 것이 오늘의 실험입니다.
3-2. 정찰과 주연 지목 — 첫 30분의 문장
정찰은 루틴 문서 v2대로 시작합니다 (화면 예시):
export TARGET=10.10.11.YYY
mkdir -p htb/second-medium && cd htb/second-medium
date '+시작: %F %H:%M' | tee timeline.txt
nmap -sV -p- $TARGET -oN 01_full_tcp.txt
nmap -sU --top-ports 100 $TARGET -oN 02_udp_top100.txt
스캔이 끝나면, 결과를 보고 30분 안에 이 문장을 로그에 씁니다.
"이 머신의 주연은 ____이다. 근거: ____."
(예: "주연은 8080의 낯선 웹앱. 근거: 유일하게 로그인 폼+API를 갖춘 표면,
나머지는 22와 정적 페이지뿐.")
읽는 법: 식별이 애매하면 whatweb http://$TARGET:8080 같은 식별 도구로 기술 스택을 확인하세요. 주연 지목은 확정이 아니라 작업 가설입니다 — 이후 정찰이 이 문장을 고치면 그것도 기록입니다.
3-3. 주연 중심 리서치 — 가설 목록 만들기
주연 서비스의 HackTricks 페이지를 열고, ‘Enumeration’ 절을 위에서부터 실행합니다. 확인한 항목마다 진척 로그에 결과를 남깁니다 (화면 예시):
[리서치 → 가설 목록]
서비스: (예) Gitea 1.16
□ 기본 자격증명 시도 → 실패
□ /api/v1 버전 정보 노출 → 확인됨, 익명 접근 불가
□ 공개 익스플로잇 존재 여부 → searchsploit: 해당 없음
→ 남은 가설: 회원가입 기능 오용, 저장소 열거
읽는 법: 이 목록이 오늘의 작업 큐입니다. 위에서부터 하나씩 검증하고, 폐기는 이유와 함께 지웁니다. 가설이 바닥나면 그때 다음 주연 후보(조연 서비스)로 넘어갑니다 — Step 265의 가설-검증 사이클이 그대로 재사용되는 것을 확인하세요.
3-4. 단계별 시간 기록 — 첫 대와 같은 저울로
Step 252의 시간 측정 서식을 그대로 씁니다. 단계가 바뀔 때마다 시각을 찍습니다 (화면 예시):
머신 2: 시작 10:00
정찰 완료: 10:25 (25분) ← 첫 대 1.0h
입구 발견: 11:40 (75분) ← 첫 대 2.5h
침투(쉘): 13:20 (100분) ← 첫 대 2.0h
권한 상승: 15:10 (110분) ← 첫 대 2.0h
읽는 법: 괄호의 비교가 오늘의 데이터입니다. 전부 빨라질 필요는 없습니다 — 유형이 달라 어느 단계는 느려지는 것이 정상입니다. 중요한 것은 "어느 단계가 느려졌고 그 이유가 무엇인가"를 문장으로 답할 수 있는가입니다.
3-5. 마무리 — 막힘 통계 v1과 간이 회고
root 후, 두 대의 막힘 기록을 2-4의 표로 합치고 간이 회고를 씁니다.
[간이 회고 서식]
- 잘된 점 1개: ____
- 막힌 점 1개(통계가 가리키는 단계와 일치하는가): ____
- 다음 머신(누적 3)에서 바꿀 것 1개: ____
읽는 법: Step 266의 대규모 복기는 누적 몇 대마다 한 번씩이면 됩니다. 매 판마다 하는 것은 이 간이 회고 — 3줄이지만, 통계 표와 붙어 있을 때 힘이 있습니다. "막힌 점"이 통계의 최다 단계와 일치하는지 보는 것이 포인트입니다 — 체감과 데이터가 어긋나면, 데이터를 믿으세요.
4. 미션과 연습문제
미션 — 다른 유형의 Medium 돌파와 막힘 통계 v1
- 첫 Medium과 다른 유형의 머신을 골라 선정 근거를 적으세요.
- 첫 30분 안에 "주연 서비스 지목 문장"을 로그에 쓰세요 — 나중에 고쳤다면 고친 기록도 남기세요.
- 주연 서비스의 HackTricks 페이지(또는 검색 결과)에서 가설 목록을 만들어 위에서부터 검증하세요.
- 단계별 시간을 첫 대와 같은 서식으로 기록하고, 완료 후 비교표를 만드세요.
- 두 대의 막힘을 단계별 통계 표로 합치고, "내 최다 막힘 단계"를 한 문장으로 선언하세요. 간이 회고 3줄로 닫습니다.
연습문제
문제 1. "주연 서비스"를 빨리 지목하는 것이 왜 리서치 속도를 올리는지, HackTricks 검색의 출발점 관점에서 설명해 보세요.
문제 2. 두 번째 Medium을 첫 대와 다른 유형으로 고르는 이유를, "루틴의 일반성" 개념과 함께 설명해 보세요.
문제 3. 막힘 통계에서 "체감상 약점"과 "데이터상 약점"이 어긋날 때 데이터를 우선해야 하는 이유를 설명해 보세요.
문제 4. 단계별 시간이 첫 대보다 특정 단계에서 느려졌을 때, 그것이 반드시 실력 퇴보를 뜻하지 않는 이유를 두 가지 들어 보세요.
5. 모범 답안과 완료 기준
미션 모범 답안
완성물의 형태 예시입니다 (내용은 여러분의 실제 기록으로):
머신 2: (이름) / 유형: 서비스 중심(첫 대는 웹 중심)
주연 지목(Day 1 10:25): "주연은 445/SMB + 5985/WinRM. 근거: 사용자 목록이
열리는 SMB와 관리 포트의 조합 — 자격증명이 주제인 머신."
시간 비교: 정찰 25분(첫 대 60) / 입구 75분(150) / 침투 100분(120) / 상승 110분(120)
막힘 통계(누적 2대): 정찰·입구 3회 2.5h / 침투 1회 1.0h / 상승 4회 3.5h
→ 선언: "내 최다 막힘 단계는 권한 상승이다. 처방: 상승 체크리스트 확장이 우선."
간이 회고: 잘된 점 — 주연 지목이 첫날 안에 끝남. 막힌 점 — WinRM 인증 시도 순서.
다음에 바꿀 것 — 자격증명 대입 순서표를 미리 만들고 시작.
검증하는 법: ① HTB 프로필에 누적 2대 완료 표시. ② 주연 지목 문장이 첫날 로그에 있는가. ③ 시간 비교표의 두 열(머신1/머신2)이 같은 단계 구분을 쓰는가. ④ 통계 표의 횟수 합이 두 로그의 막힘 기록 수와 일치하는가. ⑤ "최다 막힘 단계" 선언이 있고 처방이 붙어 있는가.
연습문제 해답
문제 1 해답. HackTricks는 서비스별로 조직된 문서입니다 — 검색의 키가 서비스 이름입니다. 주연을 지목하지 않으면 "무엇을 검색할지"부터 헤매게 되고, 열린 서비스 전부를 조금씩 조사하는 비효율이 생깁니다. 주연이 정해지면 검색어가 정해지고, 해당 페이지의 Enumeration 절이 곧 검증할 가설의 목록이 됩니다 — 리서치가 방황에서 체크리스트 처리로 바뀝니다.
문제 2 해답. 루틴이 진짜 실력인지 확인하려면 조건을 바꿔야 합니다. 같은 유형만 풀면 "웹 머신 패턴"을 익힌 것인지 "머신 공략 루틴"을 익힌 것인지 구분할 수 없습니다. 다른 유형에서 뼈대(정찰→식별→가설→검증→상승)가 유지되고 분기만 바뀐다면, 그 루틴은 유형을 넘어 재사용 가능한 것 — 이것이 일반성의 검증입니다. 흔들린 부분은 훈련 목록으로 정확히 올라갑니다.
문제 3 해답. 체감은 최근성과 감정의 영향을 받습니다 — 마지막으로 아팠던 막힘이 가장 큰 약점처럼 느껴지고, 길었지만 성공한 구간의 고생은 잊힙니다. 통계는 모든 막힘을 같은 저울로 답니다. 특히 "어느 단계에서 몇 번, 총 몇 시간을 썼는가"는 훈련 배분의 근거이므로, 기분 좋은 단계가 아니라 시간이 새는 단계에 훈련을 배정해야 합니다. 다만 데이터가 부족할 때(누적 2~3대)는 경향으로만 읽고, 대수를 쌓으며 보정합니다.
문제 4 해답. 첫째, 유형이 다르면 단계의 원래 난이도가 다릅니다 — 웹 중심에서 빨랐던 침투가 서비스 중심에서는 느린 것이 정상일 수 있습니다. 둘째, 첫 대는 우연히 아는 기법이 정답이었을 수 있습니다(운의 역할). 그래서 비교의 목적은 석차가 아니라 진단입니다 — "느려진 단계의 이유를 문장으로 말할 수 있는가"가 물음이지, 느린 것 자체가 실패는 아닙니다.
완료 기준 체크리스트
- [ ] 첫 대와 다른 유형의 Medium을 골라 근거를 적었다
- [ ] 첫 30분 안에 주연 서비스 지목 문장을 썼다
- [ ] 주연 서비스의 HackTricks(또는 검색) 기반 가설 목록을 만들어 검증했다
- [ ] 단계별 시간을 첫 대와 같은 서식으로 기록했다
- [ ] 누적 2대의 시간 비교표를 만들었다
- [ ] 막힘 통계 표(단계 × 횟수 × 시간)를 만들었다
- [ ] "내 최다 막힘 단계"와 처방을 선언했다
- [ ] 간이 회고 3줄을 썼다
6. 흔한 실수와 해결
벽 1. "주연이 뭔지 30분 안에 모르겠다"
증상: 열린 서비스가 여럿이라 어느 것이 주제인지 판단이 안 섭니다.
원인: 지목을 확정으로 여겨서입니다. 주연 지목은 정답 맞히기가 아니라 조사의 출발점 정하기입니다.
해결: 근거가 가장 두꺼운 것을 골라 "작업 가설"로 쓰고 시작하세요. 30분을 더 들여도 확신은 안 옵니다 — 검증 중에 자연히 고쳐집니다. 고친 기록("주연을 X로 봤으나 Y였음")도 실력의 증거입니다.
벽 2. "HackTricks에 이 서비스 페이지가 없다"
증상: 검색해도 해당 서비스의 정리 페이지가 나오지 않습니다.
원인: 서비스명이 일반 명사이거나, 너무 새롭거나, 배너를 잘못 읽었습니다.
해결: 순서대로 시도하세요 — ① 배너를 다시 읽어 정확한 이름+버전 확보(버전이 검색 품질을 좌우), ② "서비스명 + pentest", "서비스명 + exploit", "서비스명 + misconfiguration"으로 검색, ③ 서비스의 공식 문서에서 ‘기본 설정/기본 자격증명’ 확인. 열거가 모은 정보 전부가 검색 키워드 후보입니다.
벽 3. "첫 대보다 느려서 조급하다"
증상: 두 번째인데 시간이 더 걸리는 단계가 있고, 초조해집니다.
원인: 유형 차이와 운의 역할을 반영하지 않은 비교입니다 (연습문제 4 참조).
해결: 비교표에 "이유" 열을 추가하세요 — 느려진 단계마다 원인 문장을 적습니다. 원인이 "모르는 기법"이면 그것이 오늘의 수확이고, "열거 누락"이면 루틴 문서 v3의 개선점입니다. 초조함은 측정으로 바꾸는 것이 이 챕터의 요령입니다.
벽 4. "막힘 기록이 두 대에서 서식이 달라 합칠 수 없다"
증상: 머신 1의 로그와 머신 2의 로그가 단계 구분이 달라 통계 표가 안 만들어집니다.
원인: 서식을 미리 고정하지 않아서입니다. 통계는 같은 저울로 잰 기록만 합쳐집니다.
해결: 지금이라도 단계 구분을 통일하세요 — 정찰/입구/침투/상승 4구간을 권합니다. 과거 로그는 재분류해서 표를 만들고, 다음 머신부터는 2-4의 서식을 로그 템플릿에 고정하세요. 이 불편 자체가 "기록은 분석을 위해 쓴다"는 교훈입니다.
벽 5. "주연만 파다가 진짜 입구를 놓쳤다"
증상: 주연이라고 판 서비스의 가설이 전부 폐기됐고, 실제 입구는 조연이었습니다.
원인: 주연 지목이 집착으로 변했습니다. 지목은 우선순위지 배타적 선택이 아닙니다.
해결: 가설 목록이 바닥나는 것이 조연으로 넘어갈 정상 신호입니다 — "주연이 아니었다"는 것도 검증으로 확정된 사실입니다. 로그에 "주연 재지목: ____"을 적고 계속하세요. Medium 머신에서 주연을 두 번 고치는 것은 흔한 일입니다.
7. 정리
오늘의 개념
| 개념 | 한 줄 설명 |
|---|---|
| 주연 서비스 | 머신의 입구·체인이 중심으로 도는, 그 판의 주제 서비스 |
| 주연 지목 문장 | 첫 30분의 작업 가설 — 리서치의 출발 좌표 |
| 루틴의 일반성 | 유형이 바뀌어도 뼈대가 유지되는지로 검증하는 루틴의 품질 |
| 막힘 통계 | 단계 × 횟수 × 시간으로 모은 약점의 지도 |
| 간이 회고 | 잘된 점/막힌 점/다음 개선 1개 — 매 판의 3줄 마무리 |
오늘의 명령어·도구
| 명령 | 하는 일 |
|---|---|
whatweb http://$TARGET:8080 |
웹 기술 스택 식별 (주연 지목 보조) |
nmap -sV -p- $TARGET -oN 01_full_tcp.txt |
정찰의 첫 명령 — 기록은 계속 |
date '+%F %H:%M' | tee -a timeline.txt |
단계 전환 시각 기록 |
| HackTricks 서비스 페이지 | 주연 서비스의 공략 순서표 |
searchsploit "서비스 버전" |
공개 익스플로잇 존재 여부 확인 |
명령어보다 중요한 감각
두 번째 판이 확인해 준 것은 첫 판의 패턴이 재사용된다는 사실입니다 — 정찰, 주연 지목, 리서치, 가설 목록, 검증. 이 사슬이 두 번 돌았다면, 이제 그것은 "이 책의 방법"이 아니라 "여러분의 방법"입니다.
그리고 통계 표를 아끼세요. 두 대의 표는 아직 작지만, "상승에서 4회" 같은 한 줄은 느낌으로는 절대 잡히지 않는 약점의 좌표입니다. 다음 대(누적 3)에서 이 표에 열거의 기록이 어떻게 더해지는지 — 다음 챕터는 바로 그 기록의 체계, 열거의 깊이입니다.
전부 체크되면 Step 267 완료입니다. 사이드바의 체크박스를 눌러 진도를 저장하세요.