Simulated Kill-Chain Walkthrough

가상 해커 데스크톱

단계별로 "해커라면 이렇게 움직일 것이다"를 서사로 보여드립니다. 먼저 방어 아이디어를 직접 적어보고, 그다음 실제로 쓰이는 방어 절차를 확인하세요.

attacker@vm — fictional session 00:00
STAGE 1 · 정찰 (Reconnaissance)window_recon.sh
# 목표: 공격 가능한 표면을 찾는다 (서사적 재구성, 실제 스캔 명령 아님) [recon] 대상 조직의 공개 채용공고에서 사용 중인 CMS/프레임워크 이름 확인 [recon] 공개 CVE 데이터베이스에서 해당 버전의 "패치 안 된" 취약점 유무 조회 [recon] 회사 헬프데스크 전화번호, 조직도, 직원 SNS 노출 정보 수집 [found] 오래된 버전 흔적 + 응대 매뉴얼이 느슨해 보이는 고객센터 발견

해커가 여기서 노리는 것

해커는 침투 전에 "가장 손쉬운 문"부터 찾는다. 기술적 취약점뿐 아니라 사람(고객센터, 신입 직원)도 정찰 대상이 된다. 이 단계는 겉으로 드러나는 흔적이 거의 없어 탐지가 가장 어렵다.

✓ 실제로 쓰이는 방어
  • 외부에 노출되는 정보(버전, 조직도, 매뉴얼)의 최소화 — 공격면 관리(attack surface management)
  • 알려진 CVE에 대한 패치 SLA 운영 및 정기 취약점 스캔
  • 직원 대상 OSINT 노출 점검(자신도 모르게 공개된 정보 파악)
STAGE 2 · 초기 접근 (Initial Access)window_access.log
# 목표: 문 안으로 발 하나를 들여놓는다 [approach-A] 가짜 오류 화면을 만들어 "해결하려면 이 안내를 따르세요" 유도 (클릭픽스형) [approach-B] 직원 목소리를 흉내내 헬프데스크에 "비밀번호를 잊었다" 전화 [approach-C] 신뢰받는 오픈소스 패키지의 배포 계정을 노려 정상 채널에 잠입 [result] 세 갈래 모두 "기술적 방화벽"이 아니라 "신뢰"를 공략한다

공통점

초기 접근은 대개 가장 단단한 벽(서버)이 아니라 가장 약한 고리(사람, 신뢰 관계, 공급망)를 노린다. 세 방식 모두 피해자가 "스스로" 문을 열어주게 만드는 구조다.

✓ 실제로 쓰이는 방어
  • 출처 불명 안내창의 명령어를 직접 실행하지 않도록 하는 사용자 교육
  • 전화 요청은 사전 등록된 번호로 콜백해 재확인, 민감 변경은 MFA 필수
  • 패키지 배포 계정 2FA 의무화 및 서명·해시 검증
STAGE 3 · 실행 & 지속성 (Execution / Persistence)window_exec.log
# 목표: 한 번 들어온 것을 "계속 살아있게" 만든다 [exec] 확보한 권한으로 표준 실행 경로(패키지 require, 확장 프로그램 실행 등)에 편승 [persist] 재부팅되어도, 비밀번호가 바뀌어도 접근이 끊기지 않을 방법을 심는다 [note] "설치 즉시 발동"이 아니라 "필요할 때만 조용히 발동"하도록 지연 설계

왜 '조용함'이 핵심인가

즉시 요란하게 움직이면 바로 탐지된다. 실제 사고들에서 반복되는 패턴은 평소엔 정상처럼 보이다가, 특정 조건(호출 시점, 지연 시간, 이벤트 발생)에서만 동작하는 설계다.

✓ 실제로 쓰이는 방어
  • 계정 초기화·비밀번호 변경 시 관련 토큰·세션도 함께 무효화되는 설계
  • 퇴직·직무변경 시 즉시 권한 회수 체크리스트 운영
  • 이상행위 기반 모니터링(EDR)으로 '정상처럼 보이지만 낯선 행위' 탐지
STAGE 4 · 권한 상승 & 확산 (Privilege Escalation / Lateral Movement)window_pivot.log
# 목표: 처음 확보한 낮은 권한을 더 넓은 권한으로 바꾼다 [pivot] 개발 환경 접근권한 → 실제 운영(prod) 시스템 접근권한으로 이동 시도 [pivot] 한 서비스의 인증정보를 다른 연결된 서비스에 재사용해보는 시도 [why] 조직 내부에 '경계'가 없으면 한 곳이 뚫리는 순간 전체가 뚫린다

구조적 약점

개발과 운영이 분리되지 않았거나, 한 계정에 너무 많은 서비스 권한이 몰려 있으면 이 단계가 매우 쉬워진다. 반대로 권한이 잘게 나뉘어 있으면 공격자는 매번 새로운 벽에 부딪힌다.

✓ 실제로 쓰이는 방어
  • 최소권한 원칙과 서비스별 권한 분리(같은 계정에 권한 몰아주지 않기)
  • 개발·운영 환경 분리 및 운영 시스템 접근에 별도 승인 절차
  • 네트워크 세그멘테이션으로 한 구역 침해가 전체로 번지지 않도록 차단
STAGE 5 · 수집 & 탈취 (Collection / Exfiltration)window_exfil.log
# 목표: 확보한 데이터를 들키지 않고 밖으로 빼낸다 [collect] 자격증명, 고객정보, API 키 등 가치 있는 데이터를 한곳에 모은다 [exfil] 흔히 감시가 느슨한 채널(정상처럼 보이는 트래픽)을 통해 소량씩 내보낸다 [why] 한 번에 대량 전송하면 이상 탐지에 걸리기 쉽다 — 그래서 '조용히, 나눠서'

탐지 포인트

탈취 단계는 "평소와 다른 트래픽 패턴"이 유일한 단서인 경우가 많다. 이상행위 기반 네트워크 모니터링이 이 단계에서 가장 강력한 방어선이다.

✓ 실제로 쓰이는 방어
  • DNS·아웃바운드 트래픽 이상탐지를 정상 모니터링 범위에 포함
  • 대량·비정상 시간대 데이터 조회에 대한 이상행위 알림 체계
  • 민감 데이터 저장 시 암호화 + 접근 로그 상시 감사
정리 — 다섯 단계 모두 관통하는 공격자의 논리는 하나입니다: "가장 약하고, 가장 눈에 덜 띄는 지점을 조용히 통과한다." 방어자의 논리도 결국 하나로 수렴합니다: 어느 단계에서든 이상함을 빨리 알아채고, 권한을 잘게 쪼개고, 신뢰를 함부로 주지 않는 것. 30문항 방어 퀴즈(이전에 만든 파일)로 각 단계별 절차를 더 깊이 연습해볼 수 있습니다.