📚 네트워크 · 패킷 분석 › 03. Wireshark 패킷 분석 — 150편
이전 글: 149. Packet에서 IOC 추출 · 다음 글: 151. 네트워크 장비의 종류
1. 개념
Alert는 "의심스럽다"는 신호일 뿐이고, 실제로 일어난 일은 패킷이 가장 직접적으로 보여 줍니다. Wireshark 기반 Incident 분석은 이벤트 하나를 출발점으로 캡처를 좁혀 들어가 "무엇이, 언제, 누구 사이에서, 어디까지 일어났는가" 를 증거와 함께 답하는 과정입니다.
이 글은 03 영역 정리편으로, 앞선 글의 기능을 분석 단계 순서로 엮습니다.
| 분석 단계 | 쓰는 기능 | 관련 글 |
|---|---|---|
| 증거 확보 | 해시 기록, 사본 작업 | 148. pcap 증거 보존과 해시 검증 |
| 개요 파악 | Capture File Properties, Protocol Hierarchy | 109. Statistics로 전체 흐름 파악 — Conversations·Endpoints·Protocol Hierarchy |
| 범위 축소 | Display Filter, Conversations, Endpoints | 108. Display Filter, 110. Conversations, 111. Endpoints |
| 흐름 재구성 | Follow TCP Stream, 프로토콜별 필드 | 134. Follow TCP Stream, 135. DNS Packet 분석·137. HTTP Packet 분석 |
| 이상 판정 | Flag·시퀀스·외부 통신 분석 | 128. TCP Flag 분석, 146. 비정상 TCP Traffic 분석, 147. 외부 비정상 통신 분석 |
| 결과 정리 | IOC 추출, 타임라인 | 149. Packet에서 IOC 추출 |
2. 동작 원리
분석은 넓게 보고 → 좁히고 → 재구성하고 → 판정하는 순서로 진행합니다.
[Alert 수신] 시각·출발지·목적지·룰 이름 확인
↓
[캡처 확보] 해당 시간대 pcap 확보 → 해시 기록 → 사본 생성
↓
[개요 파악] 캡처 기간·패킷 수 / 프로토콜 비율 / 통신량 상위 대화
↓
[범위 축소] 시간 구간 + 관련 IP로 필터 → 관련 스트림 목록
↓
[흐름 재구성] DNS 질의 → 연결 → 요청·응답 내용 → 전송 파일
↓
[판정] 정탐 / 오탐 / 판단 보류(추가 자료 필요)
↓
[정리] IOC 목록, 타임라인, 영향 범위, 권고 조치 → 보고판정 결과는 세 가지로 나눕니다. 판단 보류도 정당한 결론이며, 무엇이 부족한지를 명확히 적는 것이 중요합니다.
| 판정 | 근거 예 | 이후 조치 |
|---|---|---|
| 정탐(True Positive) | Alert 조건과 일치하는 악성 행위가 패킷에서 확인됨 | 대응 요청(격리·차단), 영향 범위 조사 |
| 오탐(False Positive) | 룰이 걸린 내용이 정상 업무 트래픽으로 확인됨 | 근거 기록, 룰 튜닝 요청 |
| 판단 보류 | 암호화·캡처 누락으로 내용 확인 불가 | 호스트 로그·EDR 등 추가 자료 요청 |
3. 주요 특징
분석 중 스스로에게 던질 질문과, 그 답을 주는 패킷 증거입니다.
| 질문 | 패킷 증거 | Wireshark에서 보는 곳 |
|---|---|---|
| 누가 시작했는가 | 첫 SYN의 출발지, DNS 질의 호스트 | tcp.flags.syn == 1 && tcp.flags.ack == 0 |
| 어디로 갔는가 | 목적지 IP, SNI, Host | Conversations, tls.handshake.extensions_server_name |
| 무엇을 주고받았는가 | 요청 URI, 응답 코드, 파일 | Follow Stream, Export Objects |
| 성공했는가 | 연결 성립, 응답 코드, 전송 바이트 | tcp.completeness, http.response.code |
| 언제 시작·끝났는가 | 첫·마지막 관련 프레임 시각 | Time 열(UTC 표시 권장) |
| 더 퍼졌는가 | 같은 목적지로 가는 다른 내부 호스트 | ip.dst == <IOC IP> 전체 검색 |
패킷 분석만으로 답할 수 없는 질문도 분명히 구분합니다.
| 패킷으로 알기 어려운 것 | 보완 자료 |
|---|---|
| 어떤 프로세스가 연결했는가 | EDR, 호스트 네트워크 이벤트 |
| 내려받은 파일이 실행되었는가 | EDR, Windows 이벤트 로그, Sysmon |
| 암호화된 내용 | 프록시 로그, 엔드포인트 로그 |
4. 예시
아래는 절차 설명을 위한 가상 시나리오이며, 명령 출력과 값은 모두 예시(값은 환경마다 다름)입니다.
Alert: 01:12 UTC, 내부 192.168.10.31 → 외부 203.0.113.77:80, "실행 파일 다운로드 의심" 룰
① 증거 확보와 개요 파악
sha256sum sensor_0930.pcapng > sensor_0930.pcapng.sha256
# Alert 전후 시간만 잘라 사본 생성
editcap -A "2026-09-30 01:05:00" -B "2026-09-30 01:30:00" sensor_0930.pcapng case.pcapng
capinfos case.pcapng # 기간·패킷 수
tshark -r case.pcapng -q -z io,phs # 프로토콜 비율
tshark -r case.pcapng -q -z conv,tcp # TCP 대화 목록② 범위 축소와 흐름 재구성 — 다음 필터를 차례로 적용합니다(# 뒤는 설명).
ip.addr == 192.168.10.31 && dns # 직전에 어떤 도메인을 물었는가
ip.addr == 192.168.10.31 && ip.addr == 203.0.113.77 # 해당 대화 전체
http.request && ip.src == 192.168.10.31 # 요청 URI·User-Agent
ip.dst == 203.0.113.77 && !(ip.src == 192.168.10.31) # 다른 내부 호스트도 접속했는가관련 스트림에서 Follow → TCP Stream으로 요청과 응답 헤더를 확인하고, File → Export Objects → HTTP로 파일을 내보내 해시를 계산합니다(파일은 실행하지 않음).
③ 타임라인 정리 — 형식 예시입니다.
시각(UTC) 프레임 내용 근거
01:12:04 412 192.168.10.31 DNS 질의 update-check.example.net dns.qry.name
01:12:05 415 192.168.10.31 → 203.0.113.77:80 TCP 연결 성립 SYN/SYN-ACK/ACK
01:12:05 418 GET /dl/a.bin, User-Agent 비브라우저 형태 http.request
01:12:06 421 200 OK, Content-Type application/octet-stream http.response.code
01:12:06~ 422-460 약 480KB 전송 후 FIN 종료 tcp.stream 17
01:13:10~ - 같은 목적지로 60초 간격 짧은 연결 반복 Conversations📷 [실습 화면 삽입 위치] View → Time Display Format을 UTC Date and Time of Day로 바꾼 뒤, 관련 대화만 필터링한 Packet List 화면
이 시나리오라면 "다운로드와 이후 주기적 통신 확인 → 정탐 가능성 높음, 실행 여부는 EDR 확인 필요"로 정리하고 호스트 격리 검토를 요청합니다.
5. 보안 관점
- 증거 무결성이 분석 결과의 신뢰를 결정합니다. 원본 해시를 먼저 기록하고, 잘라 내기·필터 저장은 모두 사본에서 합니다.
- 캡처에는 한계가 있습니다. 캡처 지점을 지나지 않은 통신, 센서가 놓친 패킷, 암호화된 내용은 보이지 않습니다. "보이지 않았다"를 "없었다"로 쓰지 않습니다.
- 시간 기준을 통일합니다. Wireshark 표시 시간과 SIEM·방화벽 로그의 시간대가 다르면 타임라인이 어긋나므로, 보고서는 UTC 등 한 시간대로 통일합니다.
6. SOC 관점
| 보고서 항목 | 담을 내용 |
|---|---|
| 요약 | 한두 문장의 결론과 판정(정탐/오탐/보류) |
| 탐지 정보 | Alert 시각·룰·출발지·목적지 |
| 분석 근거 | 필터·프레임 번호·스트림 번호, 캡처 파일 해시 |
| 타임라인 | UTC 기준 주요 이벤트 순서 |
| IOC | 유형·값·신뢰도(공유용 defang 표기) |
| 영향 범위·권고 | 관련 호스트, 추가 확인 필요 자료, 조치 제안 |
관제자가 확인할 질문
- Alert가 가리킨 행위가 패킷에서 실제로 성공했는가, 시도에 그쳤는가?
- 같은 IOC로 다른 호스트·다른 시간대를 검색했는가?
- 결론마다 다른 사람이 재현할 수 있는 근거(파일 해시, 필터, 프레임 번호)를 남겼는가?
오탐 주의: 룰 이름만 보고 판정하지 않습니다. 예를 들어 "실행 파일 다운로드" 룰은 정상 소프트웨어 업데이트에도 걸립니다. 도메인·서명·배포 경로가 업무용 소프트웨어와 일치하는지 확인한 뒤 판정합니다. 방화벽·IDS Alert와의 연계 분석은 06 영역 297. IDS Alert와 Packet 연계에서 다룹니다.
7. 핵심 정리
- Wireshark 기반 Incident 분석은 증거 확보 → 개요 → 범위 축소 → 흐름 재구성 → 판정 → 정리 순서로 진행합니다.
editcap으로 시간 구간 사본을 만들고, Protocol Hierarchy·Conversations로 전체 모양부터 봅니다.- 판정은 정탐·오탐·판단 보류로 나누며, 보류일 때는 필요한 추가 자료를 명확히 적습니다.
- 패킷으로 알기 어려운 프로세스·실행 여부는 EDR·호스트 로그로 보완합니다.
- 보고서에는 필터·프레임 번호·파일 해시처럼 재현 가능한 근거와 UTC 타임라인을 남깁니다.
