킥오프 미팅에서 고객분들이 가장 많이 물어보시는 질문이 있습니다 — “저희 서비스, 안전한가요?” 정말 중요한 질문인데, 솔직한 답은 조금 조심스럽습니다. “어디까지, 어떤 방식으로 살펴보느냐에 따라 달라집니다.” 이 글은 견적서와 최종 보고서 사이의 약 2주 동안, 저희 점검팀이 어떤 마음으로 무엇을 하는지를 차분히 적어본 이야기입니다. 모의해킹을 처음 준비하시는 분들께 조금이나마 도움이 되면 좋겠습니다.
취약점 스캔과 모의해킹은 어떻게 다를까요?
가장 많이 받는 질문부터 풀어보겠습니다. 스캐너는 정말 유용한 도구입니다. 알려진 패턴을 빠르고 폭넓게 훑어주니까요. 다만 한 가지를 보완하기는 어렵습니다 — “작은 문제들을 이렇게 이어 붙이면 어떤 일이 벌어지는가”를 함께 판단하는 일입니다. 그 연결을 짚어보는 부분을 사람이 거든다고 이해해 주시면 좋을 것 같습니다.
예를 들어, 한 커머스 고객사에서 저희가 정리해 드린 침투 경로는 이런 모습이었습니다. 하나하나는 모두 “중간” 이하 등급이었습니다.
[낮음] 비밀번호 재설정 응답에 사용자 이메일이 노출됨
│
▼
[중간] 계정 열거가 가능 → 유효한 내부 운영자 계정 확인
│
▼
[중간] 관리자 페이지가 IP 화이트리스트로만 보호됨
│ └─ 앞서 찾은 SSRF로 내부에서 요청 → 화이트리스트 통과
▼
[심각] 운영자 권한으로 전 주문/결제 데이터 열람 + 쿠폰 무제한 발급스캐너 리포트에는 이 네 가지가 서로 무관한 항목으로 표시됩니다. 스캐너가 부족하다는 뜻은 아닙니다. 다만 “이게 이어진다”를 읽어내는 한 단계를 사람이 더한다고 보시면 좋겠습니다.
사실 범위 협의가 가장 중요합니다
앞에서 조심스럽게 답한 이유가 여기에 있습니다. 점검은 RoE(Rules of Engagement)를 함께 정하는 데서 시작합니다. 대상 자산, 테스트 시간대, 절대 하지 말아야 할 것(서비스 중단·실데이터 변경), 그리고 문제 발생 시 연락 체계까지요. 이 부분을 꼼꼼히 정할수록 주어진 2주를 가장 값지게 쓸 수 있습니다.
정보를 어디까지 공유하시느냐에 따라 접근 방식이 달라집니다. 무엇이 더 낫다기보다는, 예산과 목적에 맞춰 고르시면 됩니다.
유형 | 공유하는 정보 | 이런 분께 권해드려요 |
|---|---|---|
블랙박스 | 거의 없음 (외부인 시점) | 실제 외부 공격에 가장 가깝습니다. 정찰에 시간이 필요해, 일정에 여유가 있을 때 좋습니다. |
그레이박스 | 일반 계정 한두 개, 일부 문서 | 비용 대비 살펴보는 범위가 넓어 가장 많이 선택하시는 방식입니다. |
화이트박스 | 소스코드·설계도·관리자 권한 | 가장 깊이 들여다봅니다. 비즈니스 로직까지 보고 싶으실 때 적합합니다. |
처음 받으시는 거라면 그레이박스를 조심스럽게 추천드립니다. 정찰에 쓸 시간을 실제 점검에 더 쓸 수 있어, 첫 점검에서 체감이 큰 편입니다.
정찰: 누구에게나 잊혀진 자산은 생깁니다
공격 표면을 모르면 점검도 어렵습니다. 그래서 처음 며칠은 자산을 차근차근 정리하는 데 씁니다. 서비스를 오래 운영하다 보면 누구에게나 잊혀진 서버가 생기기 마련인데, 그런 자산이 의외로 중요한 출발점이 되곤 합니다.
# 서브도메인을 모으고 → 살아있는 호스트만 추리고 → 무엇을 쓰는지 봅니다
subfinder -d target.com -silent | httpx -silent -title -tech-detect
# 결과 예시
https://api.target.com [200] [메인 API · nginx]
https://event2022.target.com [200] [Apache/2.4.29 · PHP/5.6] ← 함께 살펴볼 자산마지막 줄처럼 오래된 자산을 발견하면, 저희는 이를 탓하기보다 “함께 정리하면 좋을 목록”으로 봅니다. 누구의 잘못도 아니고, 자산은 시간이 지나면 자연스럽게 쌓이니까요.
“될 것 같다”보다 “직접 확인했습니다”
의심되는 지점을 추리고 나면 실제로 확인해 봅니다. 저희가 지키려고 노력하는 원칙이 하나 있는데, “될 것 같다”를 보고서에 적지 않으려 한다는 점입니다. 통제된 방식으로 직접 재현해 확인하거나, 재현되지 않으면 왜 그런지를 적습니다. 추측은 고객분의 판단을 흐릴 수 있어서요. 물론 모든 검증은 RoE의 안전선 안에서, 사전에 합의된 범위로만 진행합니다.
거점을 확보한 뒤가 사실 더 중요한 부분입니다. 자격증명 재사용이나 권한 설정의 빈틈을 따라가며 “이 한 번의 침투가 실제 업무에 어떤 영향을 줄 수 있는가”를 시나리오로 보여드립니다. 의사결정에 도움이 되는 건 취약점 번호보다 이 이야기인 것 같습니다.
한 걸음 더 — 실제 공격자(APT)의 시선으로
여기서부터가 저희가 특히 공을 들이는 부분입니다. 실제 표적 공격(APT) 그룹은 애플리케이션의 로직만 노리지 않습니다. 오히려 더 조용히 노리는 곳은 그 서비스가 ‘기대고 있는’ 것들 — 오픈소스 라이브러리, 프레임워크, 내장 컴포넌트, 외부 의존성입니다. 잘 만든 코드도 결국 수십 개의 컴포넌트 위에 올라가 있고, 그 중 하나의 틈이 전체의 입구가 되곤 합니다. 그래서 저희도 같은 시선으로 그 부분을 들여다봅니다.
1-day: 이미 공개됐지만 아직 막히지 않은 틈
가장 현실적인 위협부터 말씀드리면, 어떤 컴포넌트의 보안 패치가 공개되는 순간 그 패치의 ‘이전과 이후 차이’는 곧 ‘무엇이 취약했는가’의 지도가 됩니다. 운영 환경이 아직 패치를 적용하지 못한 동안(이른바 ‘패치 갭’) 공격자는 공개된 패치를 거꾸로 읽어 익스플로잇을 재구성합니다. 저희도 같은 방법으로, 고객 환경의 컴포넌트와 버전을 식별하고 알려진 결함이 이 설정에서 실제로 악용되는지 통제된 범위에서 확인합니다.
# 응답 헤더·정적 리소스·에러 페이지로 컴포넌트와 버전을 식별
$ httpx -u https://target -title -tech-detect -server
target [200] [Spring Boot · Jackson] [nginx/1.18.0]
# 프런트 번들 해시로 라이브러리 버전을 추정하고
# 식별된 버전이 공개 권고문(advisory)의 영향 범위에 드는지 대조
# → 패치 디핑으로 PoC를 재구성해, 이 환경에서 실제로 되는지만 안전하게 확인여기서 핵심은 “버전이 낮습니다”라는 지적이 아니라, “이 버전이 이 설정에서 실제로 이렇게 악용됩니다”를 보여드리는 것입니다. 그래야 어떤 패치를 먼저 적용해야 하는지 우선순위가 분명해지니까요.
0-day: 아직 아무도 모르는 틈
외부에 노출된 핵심 컴포넌트나 직접 개발한 라이브러리처럼 위험도가 큰 부분에 대해서는, 한 걸음 더 들어가 아직 알려지지 않은 결함을 찾기도 합니다. 입력을 다루는 파서·디코더·프로토콜 처리부를 대상으로 한 타깃 퍼징과 소스 리뷰로, 미지의 메모리 손상이나 인가 우회를 탐색합니다. 이 과정은 범위와 안전선을 사전에 충분히 합의한 경우에 한해, 통제된 방식으로만 진행합니다.
저희가 그동안 다수의 CVE를 등록해 온 것도 이런 작업의 연장선에 있습니다. 발굴 과정을 더 자세히 보고 싶으시면 0-day는 어떻게 발굴되는가 글에 패치 디핑과 퍼징 하네스 작성까지 정리해 두었으니 함께 봐주시면 좋겠습니다.
현장 노트: “저희 코드는 깨끗합니다”가 끝이 아닐 때가 많습니다. 코드가 멀쩡해도 기대고 있는 라이브러리 하나가 실제 공격의 입구가 되곤 하거든요. 그 한 칸까지 같이 살펴봐 드리는 게 APT 관점 점검의 핵심인 것 같습니다.
저희가 가장 마음을 쓰는 건 보고서입니다
점검은 2주지만, 고객분께 남는 건 보고서입니다. 그래서 저희가 스스로에게 던지는 질문은 하나예요 — “담당 개발자분이 이 보고서를 읽고 바로 고치실 수 있을까?” 취약점을 많이 나열하기보다, 우선순위가 분명하고 재현 절차를 그대로 따라 할 수 있는 보고서가 실제로 더 도움이 된다고 믿습니다.
현장 노트: 점검을 마치며 재점검 일정을 함께 잡아두시는 고객분들이, 경험상 가장 빠르게 안정되시는 것 같습니다. 보안은 한 번의 이벤트라기보다 꾸준히 이어가는 과정에 가깝다고 느낍니다.
자주 묻는 질문
기간은 보통 얼마나 걸리나요?
범위와 깊이에 따라 다릅니다. 웹 서비스 한 개는 보통 1~2주, 복합 인프라나 레드팀은 조금 더 걸립니다. 정확한 일정은 협의 때 함께 정합니다.
운영 서비스에 영향이 가지는 않을까요?
저희가 가장 조심하는 부분입니다. 위험할 수 있는 작업은 시간대·승인·통제 아래에서만 진행하고, 염려되는 경우 스테이징에서 확인합니다. 문제가 생기면 즉시 멈출 수 있도록 비상 연락 체계도 미리 정해둡니다.
스캐너 결과만 받아도 되지 않나요?
스캐너 결과도 출발점으로 충분히 의미가 있습니다. 저희는 거기에 오탐을 걸러내고 연결 가능성을 확인하는 과정을 더해 드린다고 생각해 주시면 좋겠습니다.
마치며
모의해킹의 핵심은 화려한 도구보다 절차와 사람의 꾸준한 판단에 있는 것 같습니다. 범위를 함께 잘 정하고, 잊혀진 자산을 찾아 정리하고, 직접 확인하고, 고치기 쉽게 정리해 드리는 것 — 저희가 늘 더 잘하려고 노력하는 부분입니다. 우리 서비스가 어디까지 안전한지 궁금하시면 편하게 모의해킹 상담으로 물어봐 주세요. 작게 시작해서 함께 단단하게 만들어가면 좋겠습니다.