[실전 레드팀 개발 및 운영(Red Team Development & Operations) 가이드] 11강 — 11. 공격 흐름도 작성 및 위험 평가 (Engagement Reporting)
안녕하세요! Hackerstory 공부방의 IT/보안 튜터 정다은입니다. 👋
지난 10강에서는 공격 작전이 끝난 후 실행했던 흔적 제거(Cleanup)와 디컨플릭션 검증 과정을 배웠습니다. 실전 공격을 성공적으로 수행하고 깔끔하게 마무리까지 마쳤다면, 이제 레드팀 오퍼레이션의 하이라이트이자 결실인 ‘보고서 작성(Engagement Reporting)’ 단계로 넘어갈 차례입니다.
많은 초보자분들이 "공격에 성공했으니 캡처 화면 몇 장 넣고 취약점 목록만 나열하면 되는 것 아닌가요?"라고 생각하곤 합니다. 하지만 레드팀의 보고서는 일반 모의침투 테스트(Pentest) 보고서와 완전히 다릅니다.
단순히 "어떤 취약점이 있다"를 넘어서, 공격자가 조직의 방어망을 어떻게 우회하여 최종 목표에 도달했는지 전체 스토리를 전달해야 하기 때문이죠.
오늘 11강에서는 최고 수준의 레드팀 보고서를 작성하기 위한 3가지 핵심 요소인 ① 공격 흐름도(Attack Flow Diagram), ② 관찰 사항(Observations)과 발견 사항(Findings)의 구별, 그리고 ③ 맥락 중심의 위험 매트릭스(Risk Matrix) 작성법을 차근차근 알아보겠습니다!
1. 개념 설명: 레드팀 보고서의 3대 핵심 요소
(1) 공격 흐름도 (Attack Flow Diagram)
일반적인 취약점 진단 보고서가 **'단편적인 취약점들의 목록(Checklist)'**이라면, 레드팀 보고서는 **'공격의 연쇄 과정을 그린 하나의 지도(Map)'**입니다.
- 왜 필요한가요? 경영진이나 방어팀(블루팀)은 "단순히 A 서버에 취약점이 있다"는 사실보다, **"공격자가 A 서버의 취약점을 이용해 B 계정을 탈취하고, 결국 C DB의 핵심 고객 정보를 유출했다"**는 전체 서사(Narrative)를 볼 때 위험성을 훨씬 직관적으로 이해합니다.
- 무엇을 표현하나요? 초기 침투(Get In)부터 정착(Stay In), 그리고 목표 달성(Act)까지 오퍼레이터가 수행한 모든 TTP(위협 주체의 기술/기법/절차)의 순서와 관계를 시각적으로 표현합니다.
(2) 관찰 사항(Observations) vs 발견 사항(Findings)
레드팀 보고서에서 가장 많이 혼동하는 개념입니다. 이 둘을 명확히 구분해야 조직의 사람(People), 프로세스(Process), 기술(Technology) 전반을 평가할 수 있습니다.
| 구분 | 관찰 사항 (Observations) | 발견 사항 (Findings) |
|---|---|---|
| 정의 | 훈련 과정에서 관찰된 방어팀의 행동, 절차적 공백, 탐지 미흡 등의 현상 | 시스템, 네트워크, 애플리케이션의 구체적인 기술적 결함 및 보안 취약점 |
| 중점 요소 | 사람(People) & 프로세스(Process) | 기술(Technology) & 설정(Configuration) |
| 예시 | "C2 통신이 3일간 유지되었으나 SOC에서 이상 징후를 탐지하지 못함" | "개발 서버의 LSASS 메모리 보호 미비로 인해 Plaintext Credential 유출 가능" |
| 개선 방향 | 모니터링 룰 강화, SOC 대응 프로세스 개선 | 패치 적용, 하드닝(Hardening), 설정 변경 |
💡 튜터 다은의 팁:
발견 사항(Findings)은 기술적 "구멍"이고, 관찰 사항(Observations)은 그 구멍을 모니터링하거나 막아야 할 "사람과 시스템의 반응"이라고 생각하면 이해하기 쉽습니다!
(3) 맥락 중심의 위험 매트릭스 (Risk Matrix)
CVSS(공통 취약점 평가 시스템) 점수가 높다고 해서 반드시 그 조직에 가장 위험한 것은 아닙니다. 레드팀은 **'실제 위협 맥락(Threat Context)'**을 반영한 위험성을 평가합니다.
- 기존 방식: "이 취약점은 CVSS 9.8점이므로 무조건 긴급 처리해야 합니다."
- 레드팀 방식: "이 취약점은 CVSS 6.5점이지만, 내부 망으로 침투하여 도메인 관리자 권한을 획득하는 결정적 다리가 되었으므로 우리 조직에게는 **'위험도: High'**입니다."
위험도는 기본적으로 **위협 발생 가능성(Likelihood) × 비즈니스 영향도(Impact)**로 계산되며, 여기에 **'방어팀의 탐지/차단 실패 여부'**가 가중치로 작용합니다.
2. 실전 예시로 배우는 보고서 작성법
이해를 돕기 위해, 실제 시나리오를 바탕으로 공격 흐름도와 보고서 구성 요소를 어떻게 작성하는지 보여드릴게요.
🎭 시나리오 요약
레드팀은 스피어 피싱을 통해 재무팀 직원 PC를 감금하고, 메모리에서 계정 정보를 탈취한 뒤, 내부 망을 거쳐 최종적으로 **'핵심 고객 DB'**에 접근하는 데 성공했습니다.
예시 1: 공격 흐름도 (Attack Flow Diagram)
보고서 상단에는 아래와 같은 흐름을 한눈에 볼 수 있는 다이어그램이 들어가야 합니다. (텍스트/아스키 및 순서도로 표현)
[1. 초기 침투] [2. 정착 및 권한 상승] [3. 내부 이동 및 목표 달성]
+-------------------+ +---------------------+ +------------------------+
| 악성 문서 첨부 | ---> | LSASS 메모리 덤프 | ---> | 내부망 스캐닝 및 |
| 스피어 피싱 이메일 | | (재무팀 PC) | | DB 서버 접근 (Pass-the-Hash)|
+-------------------+ +---------------------+ +------------------------+
| | |
v v v
[SOC 탐지 실패: Ob-01] [기술적 취약점: Fd-01] [목표 달성: DB 데이터 조회]
[SOC 모니터링 부재: Ob-02]
예시 2: 관찰 사항(Observations)과 발견 사항(Findings) 작성
실제 보고서 항목에는 이렇게 표기됩니다.
🔴 발견 사항 (Finding - 기술적 결함)
- 항목 ID: Fd-01
- 제목: Credential Guard 미적용으로 인한 LSASS 메모리 내 자격 증명 노출
- 설명: Windows 10/11의 Credential Guard 기능이 비활성화되어 있어, 공격자가 Mimikatz 기법을 이용해 메모리 내에 상주하는 NTLM 해시를 추출할 수 있었습니다.
- 위험도: High (내부 이동의 결정적 원인 제공)
- 조치 권고: GPO를 통해 전사 PC 대상 Credential Guard 강제 적용.
🔵 관찰 사항 (Observation - 프로세스/탐지 공백)
- 항목 ID: Ob-01
- 제목: 미인가 PowerShell 프로세스의 정기적 외부 C2 통신 미탐지
- 설명: 72시간 동안 30분 간격으로 비정상적인 HTTP/HTTPS 비콘(Beacon) 통신이 발생했으나, EDR 알람 우선순위 설정 오류로 인해 SOC 분석가에게 전달되지 않았습니다.
- 위험도: Medium (방어팀의 가시성 공백)
- 조치 권고: C2 프레임워크 특유의 비콘 주기 패턴을 탐지하는 SIEM 상관분석 룰 신규 등록.
예시 3: 레드팀 위험 매트릭스 (Risk Matrix)
레드팀은 작성된 Findings와 Observations를 바탕으로 아래와 같은 위험 매트릭스를 구성하여 경영진에게 자산 우선순위를 제안합니다.
impact (영향도)
▲
│ [Medium] [High] [Critical]
│ (Fd-01: LSASS) (최종 DB 유출)
│
│ [Low] [Medium] [High]
│ (Ob-01: C2)
│
└──────────────────────────────────────────► Likelihood (가능성)
- Critical: 사업 연속성에 치명적인 영향을 주는 최종 목표 달성 경로.
- High: 최종 목표 달성을 가능하게 만든 핵심 기술적 취약점 (
Fd-01). - Medium: 탐지 시간을 지연시킨 탐지 프로세스의 공백 (
Ob-01).
3. 핵심 내용 요약
오늘 다룬 내용을 핵심만 깔끔하게 정리해 볼까요?
- 공격 흐름도(Attack Flow Diagram):
- 단편적인 취약점 나열이 아닌, 공격의 시작부터 끝까지 연쇄적인 TTP 흐름을 시각화하여 전달합니다.
- 관찰 사항(Observations) vs 발견 사항(Findings):
- Findings: 수정해야 할 기술적인 취약점 및 설정 오류.
- Observations: 보완해야 할 방어팀의 탐지 공백, 프로세스 및 교육 미흡 사항.
- 위험 매트릭스(Risk Matrix):
- 단순히 CVSS 점수만 따지는 것이 아니라, 실제 비즈니스에 미치는 영향(Impact)과 위협의 실현 가능성(Likelihood)을 결합하여 위험의 우선순위를 정합니다.
다음 챕터 예고 🚀
축하합니다! 이제 여러분은 단순한 침투 테스트 보고서를 넘어, 조직 전체의 보안 태세를 한눈에 파악할 수 있는 고품질의 레드팀 오퍼레이션 보고서를 작성할 수 있게 되었습니다.
다음 시간은 본 코스의 마지막 커리큘럼인 12강: 레드팀 오퍼레이션의 완성과 지속적 개선 (Blue Team Interaction & Purple Teaming) 입니다!
공격이 끝나고 보고서를 제출했다고 해서 레드팀의 역할이 완전히 끝난 것은 아닙니다. 작전이 끝난 후 방어팀(Blue Team)과 결과를 공유하고 함께 디브리핑(Debriefing)을 진행하는 '퍼플 티밍(Purple Teaming)' 기법과, 이를 통해 조직의 보안성을 지속적으로 향상시키는 선순환 구조를 구축하는 방법을 알아보겠습니다.
수고 많으셨습니다. 다음 마지막 강의에서 만나요! 😊
댓글 0
로그인하면 댓글을 작성할 수 있습니다.