침투 테스트 입문: 모의 해킹의 절차와 방법론

지난 글에서 기계가 지치지 않고 입력을 던져 결함을 찾는 퍼징을 다뤘다. 그러나 자동화가 닿지 못하는 영역이 있다. “이 할인 쿠폰을 음수로 적용하면 잔액이 늘어나지 않을까”, “관리자 화면의 ID만 바꾸면 남의 주문이 보이지 않을까” 같은, 맥락과 의도를 이해해야 보이는 취약점이다. 이런 결함을 사람이 공격자의 사고방식으로 직접 찾아내는 활동이 침투 테스트(Penetration Testing)다.

침투 테스트란, 그리고 무엇이 아닌가

침투 테스트는 명시적 승인 하에 실제 공격 기법을 사용해 시스템의 취약점을 찾고, 그것이 실제로 악용 가능한지를 통제된 방식으로 실증하는 보안 평가다. 핵심은 두 단어다. “승인”과 “실증”.

먼저 자주 혼동되는 취약점 스캐닝과 구분해야 한다.

취약점 스캐닝은 도구(Nessus, OpenVAS, ZAP 등)가 알려진 취약점 시그니처와 대조해 “취약점일 가능성이 있는 항목 목록”을 자동 생성하는 것이다. 빠르고 넓지만, 오탐이 많고 실제 악용 가능 여부와 영향도는 알려주지 못한다.
침투 테스트는 그 목록 중 무엇이 진짜인지, 진짜라면 그것을 발판으로 어디까지 갈 수 있는지를 사람이 검증한다. “취약점이 있다”가 아니라 “이 취약점으로 실제 고객 데이터에 접근했다, 절차는 이렇다”를 보여 준다.

스캐닝이 건강검진의 혈액 수치라면, 침투 테스트는 그 수치를 보고 실제 병을 진단하고 예후를 평가하는 의사의 판단에 가깝다. 둘은 대체재가 아니라 보완재다.

레드팀(Red Team) 활동과도 구분된다. 침투 테스트가 “정해진 범위에서 가능한 한 많은 취약점을 찾는” 폭넓은 평가라면, 레드팀은 “탐지·대응 역량을 시험하기 위해 특정 목표(예: 고객 DB 탈취)를 은밀히 달성하는” 목표 지향적·은밀성 중심 활동이다.

진행 단계

침투 테스트는 즉흥적인 해킹이 아니라 체계적인 절차를 따른다. PTES(Penetration Testing Execution Standard)나 OWASP WSTG(Web Security Testing Guide) 같은 방법론이 이 절차를 표준화하고 있다.

침투 테스트 진행 단계

1) 범위 정의와 계약. 가장 먼저, 그리고 가장 중요한 단계다. 어떤 시스템·IP·도메인이 대상인지, 테스트 기간은 언제인지, 절대 해서는 안 되는 행위(운영 DB 삭제, DoS, 실제 고객 데이터 유출 등)는 무엇인지를 서면으로 합의한다. 이것이 RoE(Rules of Engagement)이고, 서면 승인 없는 침투 테스트는 침투 테스트가 아니라 범죄다. 이 경계는 뒤에서 다시 강조한다.

2) 정찰(Reconnaissance). 공개 정보(OSINT)로 대상의 공격 표면을 파악한다. 서브도메인 열거, 기술 스택 식별, 노출된 문서·코드·자격증명 검색, 직원 정보 수집 등. 앞서 다룬 “공격 표면”과 “위협 모델링”이 공격자 시점에서 실행되는 단계다.

3) 스캐닝과 취약점 분석. nmap으로 포트·서비스를 식별하고, 디렉터리 브루트포싱으로 숨은 엔드포인트를 찾고, 자동 스캐너로 취약점 후보를 모은다. 여기까지는 자동화가 많이 돕는다.

4) 익스플로잇(Exploitation). 후보 취약점이 실제로 악용 가능한지 검증한다. SQL 인젝션으로 정말 데이터를 꺼낼 수 있는지, IDOR로 남의 데이터에 접근되는지를 통제된 방식으로 실증한다. 범위와 RoE를 벗어나지 않는 선에서만 수행한다.

5) 포스트 익스플로잇(Post-Exploitation). 한 발을 들였다면, 거기서 얼마나 더 갈 수 있는지를 평가한다. 권한 상승, 횡적 이동(lateral movement), 추가 데이터 접근 가능성. 이 단계가 “취약점 하나”의 진짜 영향도를 결정한다. 낮아 보이던 취약점이 다른 것과 연결되며 치명적 경로가 되는 경우가 흔하다.

6) 보고와 재테스트. 침투 테스트의 진짜 산출물은 익스플로잇 코드가 아니라 보고서 다. 발견 항목마다 재현 절차, 위험도(보통 CVSS 기반), 비즈니스 영향, 구체적 개선 권고를 담는다. 그리고 조직이 수정한 뒤 그 수정이 실제로 유효한지 재검증(retest)하는 것까지가 한 사이클이다.

정보 수준에 따른 세 가지 방식

테스터에게 사전 정보를 얼마나 주느냐에 따라 접근이 달라진다.

블랙박스·그레이박스·화이트박스

블랙박스: 정보를 거의 주지 않는다. 외부 공격자의 현실을 가장 충실히 재현하지만, 정찰에 시간을 다 쓰면 정작 깊은 점검을 못 할 수 있다.
그레이박스: 일반 사용자 계정과 일부 문서를 제공한다. 인증 이후 영역(대부분의 비즈니스 로직과 권한 결함이 여기 있다)에 집중할 수 있어, 웹 서비스 정기 점검의 사실상 표준이다.
화이트박스: 소스 코드와 아키텍처까지 공개한다. 같은 기간에 가장 깊은 분석이 가능하지만 외부자 시점 재현은 아니다. 고위험 핵심 컴포넌트에 적합하다.

“최대한 현실적으로”가 목적이면 블랙박스에, “주어진 예산에서 최대한 많이 찾기”가 목적이면 화이트박스에 가깝게 설계한다. 실무에서는 외부 노출면은 블랙박스로, 인증 영역은 그레이박스로 나누는 혼합 방식이 흔하다.

도구는 거들 뿐

침투 테스터의 작업대에는 표준 도구들이 있다 — 트래픽을 가로채고 조작하는 인터셉트 프록시(Burp Suite, OWASP ZAP), 네트워크 스캐너(nmap), 익스플로잇 프레임워크 등. 하지만 도구는 손발일 뿐 머리는 사람이다. 다음 같은 사고는 자동화하기 어렵다.

- 가격 100원짜리 상품의 수량을 -10으로 보내면?      → 비즈니스 로직
- 주문 조회 URL의 order_id를 1씩 올려 보면?           → IDOR / 접근 제어
- 비밀번호 재설정 토큰을 다른 계정에 사용하면?          → 인증 결함 연쇄
- 결제 요청 직후 취소 요청을 동시에 보내면?            → 레이스 컨디션

그동안 다뤄온 취약점 유형 하나하나가 침투 테스터의 점검 체크리스트가 된다. OWASP WSTG는 이 점검 항목을 카테고리별로 정리해 둔, 사실상 웹 침투 테스트의 표준 안내서다.

법적·윤리적 경계 (반드시)

이 글은 인가된 보안 평가를 전제로 한다. 강조해도 지나치지 않은 원칙이 있다.

서면 승인 없는 테스트는 불법이다. 대상 시스템의 소유자가 명시적으로 서면 동의한 범위에서만 수행한다. 한국은 정보통신망법, 미국은 CFAA 등으로 무단 접근을 처벌한다.
범위를 절대 벗어나지 않는다. 옆 시스템이 더 흥미로워 보여도, RoE에 없으면 손대지 않는다.
클라우드 환경은 별도 정책을 확인한다. AWS·GCP 등은 자체 인프라에 대한 테스트 정책이 있으며, 일부 행위는 사전 통지가 필요하다.
발견한 취약점은 책임 있게 다룬다. 보고서는 안전하게 전달하고, 테스트 중 접근한 데이터는 파기한다.

이렇게 침투 테스터가 시스템을 외부에서 검증한다면, 외부 보안 연구자 커뮤니티의 힘을 상시로 빌리는 방법도 있다. 다음 글에서는 버그 바운티와 책임 있는 취약점 공개(Responsible Disclosure)를 다룬다.

지난 글: 퍼징(Fuzzing): 예상 밖의 입력으로 숨은 취약점 찾기

다음 글: 버그 바운티와 취약점 공개: 외부 연구자와 협력하는 법

읽어주셔서 감사합니다. 😊