InfoSec 3001 — 공격적 관점에서의 정보보안

Step 241. pcap 분석 심화: Wireshark 고급 필터, tshark — 패킷 백 개의 사건 재구성

Step 241. pcap 분석 심화: Wireshark 고급 필터, tshark — 패킷 백 개의 사건 재구성

Level 3 — Forensics 트랙 | 난이도 ★★★★☆ | 예상 소요 시간 5시간

전제: Step 83~84(Wireshark 기초, 프로토콜과 이상 탐지)를 마쳤다. 디스플레이 필터의 기본 문법과 TCP/DNS/HTTP의 정상 모양을 안다.

⚠️ 이 챕터의 실습은 내 랩·합법 플랫폼 전용입니다. 허가 없는 시스템에 적용하면 범죄입니다.

  • 준비물: WSL 우분투의 tshark(실측: 4.2.2), scapy venv(실측: scapy 2.7.0).
  • 주의: 오늘의 증거 파일은 scapy로 직접 조성한 시나리오 pcap입니다. tshark 출력은 전부 실측이고, Wireshark GUI 화면은 "화면 예시"입니다.

CTF와 실제 침해 사고에서 pcap 파일은 수만 개의 패킷으로 옵니다. 눈으로 한 줄씩 읽는 것은 불가능하고, 필요도 없습니다. 실전 분석가의 솜씨는 통계로 좁히고, 필터로 파고들고, 스트림으로 읽는 3단 체계입니다. 오늘은 "사무실 PC가 감염돼 자격증명이 샜다"는 시나리오의 pcap을 직접 만들고, 그 안에서 공격의 전체 흐름 — 로그인 도청, DNS 터널링, 페이로드 다운로드 — 을 tshark만으로 재구성합니다.

1. 학습 목표

이 챕터를 끝내면 다음을 할 수 있습니다:

  • -z io,phs(프로토콜 계층)와 -z conv,tcp(대화 목록)로 "어디부터 팔지"를 정한다
  • 고급 필터(http.request.method, dns.qry.name contains, tcp.stream eq)를 조합한다
  • -T fields로 원하는 필드만 뽑아 셸 파이프라인에 연결한다
  • follow,tcp로 한 대화의 내용을 통째로 읽는다
  • pcap 하나에서 공격 시나리오를 타임라인으로 재구성한다

2. 배경 지식 — 오늘의 도구와 개념

오늘의 도구 한눈에 보기

구분 내용
언어·환경 WSL 우분투 bash, tshark 4.2.2(실측), scapy 2.7.0 venv(실측)
오늘의 명령어 tshark -r f -q -z io,phs, -z conv,tcp, -Y 필터, -T fields -e …, -z follow,tcp,ascii,N
필요한 개념 디스플레이 필터 vs 통계, TCP 스트림 번호, DNS 터널링, 대화(conversation)
오늘의 산출물 시나리오 pcap + 공격 타임라인 + 재사용 가능한 tshark 필터 5종

2-1. 분석의 3단 체계 — 줌아웃에서 줌인으로

큰 pcap을 받으면 순서가 정해져 있습니다:

  1. 통계로 지도를 그린다 — 프로토콜 계층(뭐가 얼마나 있는가), 대화 목록(누가 누구와 얼마나)
  2. 필터로 의심 구역을 판다 — 비정상적으로 큰 대화, 상식 밖의 프로토콜, 평문 자격증명
  3. 스트림으로 현장을 읽는다 — 한 대화의 패킷을 재조립해 실제 내용을 통째로 복원

눈으로 목록을 스크롤하는 것은 이 세 단계가 다 끝난 뒤의 확인 작업입니다. 순서가 반대면 바다에서 바늘을 맨손으로 찾는 것과 같습니다.

2-2. 디스플레이 필터 vs 통계 필터

tshark -Y "필터"는 패킷을 고르는 필터(디스플레이 필터)입니다. 반면 -z io,phs 같은 -z 옵션은 파일 전체를 집계하는 통계 명령입니다. 둘을 섞어 쓰는 것이 오늘의 핵심입니다: -z conv,tcp로 큰 대화를 찾고, 그 대화의 스트림 번호를 -Y "tcp.stream eq 5"로 파고드는 식입니다.

2-3. TCP 스트림 — 대화의 인덱스

Wireshark/tshark는 같은 5-튜플(출발지·목적지 IP·포트, 프로토콜)의 패킷을 묶어 스트림 번호를 매깁니다. 0번부터 순서대로입니다. 스트림 번호를 알면 -z follow,tcp,ascii,N으로 그 대화의 애플리케이션 데이터를 순서대로 재조립해 볼 수 있습니다 — HTTP라면 요청과 응답이 통째로 보입니다. GUI의 "Follow TCP Stream"과 같은 기능입니다.

2-4. DNS 터널링 — 전화번호부로 밀서를 보내기

DNS는 거의 모든 네트워크에서 허용되는 평문 프로토콜이라, 침해 사고에서 데이터 유출 통로로 자주 쓰입니다. 수법은 단순합니다 — 빼낼 데이터를 base64 등으로 부호화해 서브도메인 라벨에 붙여 질의합니다. c3VwM3JzZWNyZXQ=.exfil.evil-example.net 같은 질의가 그것입니다. 탐지의 힌트: 서브도메인이 비정상적으로 길고, 같은 도메인 아래 질의가 반복됩니다.

3. 따라 하기

3-1. 증거 파일 조성 — 시나리오 pcap 만들기

분석 연습에는 "정답을 아는" 증거가 필요합니다. scapy로 사건 현장을 조성합니다 (스크립트 전문은 tmp_test/step241_pcap.py; 이 챕터의 출력은 2026-09-09 실측입니다):

from scapy.all import IP, TCP, UDP, DNS, DNSQR, DNSRR, Raw, wrpcap
# 시나리오:
#  ① 정상 DNS 2건 (portal.example.com, cdn.example.com)
#  ② HTTP POST /login — 평문 자격증명 (username=admin&password=sup3rsecret)
#  ③ 의심 DNS 3건 — base64 조각을 서브도메인에 붙인 질의 (exfil.evil-example.net)
#  ④ C2 서버(203.0.113.99:4444)가 먼저 연결해 300KB를 밀어 넣음 (역접속 + 대량 전송)
...
wrpcap("scenario.pcap", pkts)

scenario.pcap 생성: 139개 패킷

3-2. 1단계: 통계로 지도 그리기

먼저 "무엇이 얼마나 있는가"를 봅니다:

tshark -r scenario.pcap -q -z io,phs

===================================================================
Protocol Hierarchy Statistics
Filter:

ip                                       frames:139 bytes:306319
  udp                                    frames:10 bytes:942
    dns                                  frames:10 bytes:942
  tcp                                    frames:129 bytes:305377
    http                                 frames:2 bytes:297
      urlencoded-form                    frames:1 bytes:194
    data                                 frames:120 bytes:304800

(2026-09-09 실측.)

출력 읽는 법: 세 가지가 눈에 들어와야 합니다. ① HTTP 안에 urlencoded-form — 폼 제출이 있다. 로그인일 가능성. ② data라는 이름 붙은 TCP가 120패킷 304KB — 해석되지 않은 대량 전송, 전체 바이트의 99%. ③ DNS가 10패킷 — 적지만 내용을 봐야 합니다. 다음 질문은 "그 대량 전송은 누구와의 대화인가"입니다:

tshark -r scenario.pcap -q -z conv,tcp

================================================================================
TCP Conversations
                                                           |       <-      | |       ->      | |     Total     |
203.0.113.99:4444          <-> 192.168.10.50:40001              1 40 bytes      122 304 kB        123 304 kB
192.168.10.50:40000        <-> 192.168.10.10:80                 2 143 bytes       4 314 bytes       6 457 bytes

(2026-09-09 실측.)

읽는 법: 대화는 두 개뿐입니다. 포털(192.168.10.10:80)과의 대화는 작고 정상적입니다. 문제는 위쪽 — 203.0.113.99:4444에서 우리 PC로 122패킷 304KB가 한 방향으로 쏟아졌습니다. <- 열이 1패킷뿐, -> 열이 122패킷. 질문 없는 폭포입니다. 이 대화부터 팝니다.

3-3. 2단계: 필터로 파고들기 — 폼, DNS, 스트림

먼저 그 폼 제출이 무엇인지 봅니다:

tshark -r scenario.pcap -Y 'http.request.method == "POST"'

    8   0.350000 192.168.10.50 → 192.168.10.10 HTTP 194 POST /login HTTP/1.1  (application/x-www-form-urlencoded)

로그인 요청입니다. 필드를 쪼개 봅니다:

tshark -r scenario.pcap -Y 'http.request.method == "POST"' -T fields \
  -e frame.number -e ip.src -e http.host -e http.request.uri -e urlencoded-form.key -e urlencoded-form.value

8	192.168.10.50	portal.example.com	/login	username,password	admin,sup3rsecret

(2026-09-09 실측.)

읽는 법: urlencoded-form.key/value 필드가 폼을 이름,값 쌍으로 분해해 줍니다. 평문 HTTP 로그인의 자격증명이 패킷 하나에 통째로 실려 있었습니다 — 이것이 "평문 프로토콜은 길거리에서 엽서 쓰기"라는 표현의 실물입니다.

다음은 DNS입니다. 질의 패킷만 골라 이름을 봅니다:

tshark -r scenario.pcap -Y 'dns.flags.response == 0' -T fields -e dns.id -e dns.qry.name

0x1111	portal.example.com
0x2222	cdn.example.com
0x3300	c3VwM3JzZWNyZXQ=.exfil.evil-example.net
0x3301	YWRtaW4=.exfil.evil-example.net
0x3302	ZG9uZQ==.exfil.evil-example.net

(2026-09-09 실측.)

읽는 법: 첫 두 줄은 정상입니다. 아래 세 줄 — 서브도메인이 base64 모양의 긴 문자열이고 같은 exfil.evil-example.net 아래 연속 질의입니다. 2-4의 DNS 터널링 패턴입니다. 조각을 해독해 보면:

import base64
for f in ["c3VwM3JzZWNyZXQ=", "YWRtaW4=", "ZG9uZQ=="]:
    print(f, "->", base64.b64decode(f).decode())

c3VwM3JzZWNyZXQ= -> sup3rsecret
YWRtaW4= -> admin
ZG9uZQ== -> done

(2026-09-09 실측.) 3-3의 평문 로그인에서 샌 자격증명이, DNS 질의로 위장해 외부로 빠져나갔습니다. 두 증거가 서로를 증명하는 순간입니다.

3-4. 3단계: 스트림으로 현장 읽기

HTTP 대화의 전체 내용을 재조립합니다:

tshark -r scenario.pcap -q -z follow,tcp,ascii,0

===================================================================
Follow: tcp,ascii
Filter: tcp.stream eq 0
Node 0: 192.168.10.50:40000
Node 1: 192.168.10.10:80
POST /login HTTP/1.1
Host: portal.example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 35

username=admin&password=sup3rsecret
HTTP/1.1 302 Found
Location: /dashboard
Content-Length: 0

(2026-09-09 실측. 요청과 응답이 한 화면에 재조립됐습니다.)

대량 전송 대화(스트림 1)도 확인합니다:

tshark -r scenario.pcap -Y 'tcp.stream eq 1' | head -4
tshark -r scenario.pcap -Y 'tcp.stream eq 1' | wc -l

   17   0.800000 203.0.113.99 → 192.168.10.50 TCP 40 4444 → 40001 [SYN] Seq=0 Win=8192 Len=0
   18   0.850000 192.168.10.50 → 203.0.113.99 TCP 40 40001 → 4444 [SYN, ACK] Seq=0 Ack=1
   19   0.900000 203.0.113.99 → 192.168.10.50 TCP 40 4444 → 40001 [ACK] Seq=1 Ack=1
   20   0.950000 203.0.113.99 → 192.168.10.50 TCP 2540 4444 → 40001 [PSH, ACK] Len=2500
123

(2026-09-09 실측.)

읽는 법: 결정적 단서가 17번 패킷에 있습니다 — [SYN]이 외부 서버(203.0.113.99)에서 우리 PC로 왔습니다. 정상 다운로드는 우리가 먼저 연결합니다. 외부가 먼저 연결을 여는 이 대화는 "역접속(reverse connection)" — 침투한 악성코드가 아니라 공격자가 직접 문을 두드린 흔적이거나, 프록시 구성의 산물입니다. 어느 쪽이든 수사 대상입니다. 그리고 그 뒤 2500바이트씩 120개의 데이터가 밀려 들어왔습니다:

tshark -r scenario.pcap -Y 'tcp.len > 2000' | wc -l

120

3-5. 자동화 — 셸 파이프라인에 얹기

tshark의 출력을 sort | uniq -c에 연결하면 반복 분석이 스크립트가 됩니다:

tshark -r scenario.pcap -T fields -e ip.src | sort | uniq -c | sort -rn

    122 203.0.113.99
     10 192.168.10.50
      5 8.8.8.8
      2 192.168.10.10

(2026-09-09 실측.)

읽는 법: 누가 가장 많이 말했는지가 한눈에 나옵니다. 203.0.113.99가 압도적 — 대화 통계(conv,tcp)의 결론을 한 줄로 재확인했습니다. 실전에서는 이 파이프라인에 http.host, dns.qry.name 등을 갈아 끼워 "접속한 호스트 순위", "질의한 도메인 순위"를 즉시 뽑습니다. 대량 pcap에서 이 한 줄짜리 통계가 조사의 첫 지도입니다.

3-6. GUI에서의 같은 작업 — 화면 예시

같은 분석을 Wireshark GUI에서 하는 경로입니다 (화면 예시 — 실제 실행하지 않았습니다):

# 화면 예시 — Wireshark GUI 절차
1. scenario.pcap 열기
2. Statistics → Protocol Hierarchy   ← tshark -z io,phs 와 동일
3. Statistics → Conversations → TCP  ← tshark -z conv,tcp 와 동일. Bytes 열 정렬
4. 디스플레이 필터창에: http.request.method == "POST"
5. 패킷 우클릭 → Follow → TCP Stream  ← -z follow,tcp,ascii 와 동일
6. File → Export Objects → HTTP      ← 전송된 파일 목록에서 덩치 큰 것 저장

같은 파일, 같은 결론, 다른 도구입니다. GUI는 탐색에 강하고, tshark는 기록과 반복에 강합니다 — 조사 보고서에 명령어를 그대로 붙일 수 있다는 것이 CLI의 힘입니다.

3-7. 타임라인 재구성 — 오늘의 결론

수집한 증거를 시간순으로 배열하면 사건이 됩니다:

[0.00s~]  정상 활동: portal.example.com DNS 질의, 페이지 접근
[0.35s]   HTTP POST /login — admin/sup3rsecret 평문 전송 (증거: 스트림 0)
[0.55s~]  exfil.evil-example.net으로 base64 조각 3건 DNS 질의 — 자격증명 유출
[0.80s]   203.0.113.99:4444가 PC에 먼저 연결(SYN) — 역접속
[0.95s~]  같은 연결로 2500바이트 × 120회 = 300KB 유입 — 페이로드 또는 정보묶음

"로그인 도청 → 자격증명 유출 → 외부 연결 → 대량 전송"의 사슬이 완성됐습니다. 이 한 문단이 침해 사고 보고서의 Executive Summary와 같은 뼈대입니다.

4. 미션과 연습문제

미션 — 필터 다섯 종 세트와 사건 보고서

  1. 아래 다섯 필터를 scenario.pcap에 적용하고 결과를 한 줄씩 기록한다:
    ① http.request ② dns.qry.name contains "evil" ③ tcp.flags.syn == 1 and tcp.flags.ack == 0 ④ tcp.len > 2000 ⑤ frame.len > 2000과 비교해 ip.len 기반 필터 하나 직접 만들기
  2. ①~④ 중 "유출의 직접 증거"를 찍어 주는 필터가 어느 것인지 밝힌다
  3. 3-7 형식으로 자신만의 타임라인을 작성한다 — 각 항목에 근거 필터 또는 스트림 번호를 괄호로 단다
  4. (도전) 대량 전송된 300KB를 follow,tcp,raw,1으로 덤프해 파일로 저장하고 크기를 확인한다

연습문제

문제 1. -z conv,tcp에서 203.0.113.99:4444 ↔ 우리 PC 대화의 <-가 1패킷, ->가 122패킷이었습니다. 이 비대칭이 의미하는 것은 무엇인가요?

문제 2. DNS 터널링 질의를 골라내는 필터로 dns.qry.name contains "exfil" 말고, 도메인을 몰라도 쓸 수 있는 조건을 생각해 보세요 (힌트: 이름의 길이).

문제 3. 평문 HTTP 로그인의 자격증명이 노출됐는데, 같은 사이트가 HTTPS였다면 우리가 볼 수 있는 것과 볼 수 없는 것은 무엇인가요?

문제 4. 스트림 1의 첫 패킷이 외부→내부 [SYN]이었습니다. 이 사실 하나로 "정상 다운로드" 가설을 기각할 수 있는 이유를 설명하세요.

5. 모범 답안과 완료 기준

미션 모범 답안

필터 적용 결과 (2026-09-09 실측 기반):

① http.request                          → 1패킷 (POST /login)
② dns.qry.name contains "evil"          → 6패킷 (질의 3 + 응답 3)
③ tcp.flags.syn==1 and tcp.flags.ack==0 → 2패킷 (두 대화의 개시 — 하나는 외부발!)
④ tcp.len > 2000                        → 120패킷 (전부 203.0.113.99→PC)
⑤ ip.len > 2000                         → 120패킷 (IP 헤더 포함 길이 — ④와 동일 집합)

유출의 직접 증거는 ② — DNS 질의 안에 base64화된 자격증명이 들어 있습니다. ③은 "외부발 연결"이라는 별도 이상을 찍어 줍니다.

타임라인은 3-7의 형식을 따르되 각 항목에 근거를 답니다 — 예: [0.80s] 역접속 개시 (근거: 필터 ③의 두 번째 패킷, ip.src=203.0.113.99). 4번 도전: -z follow,tcp,raw,1의 출력에서 헤더 줄을 걷고 저장하면 300,000바이트(120 × 2500)가 나와야 합니다.

검증하는 법: ① 다섯 필터의 패킷 수가 기록됐는가. ② "직접 증거" 선택에 이유가 붙었는가. ③ 타임라인 각 항목에 근거(필터/스트림)가 달렸는가.

연습문제 해답

문제 1 해답. 한 방향으로만 대량 전송이 흘렀다는 뜻입니다 — 우리 측 요청·응답 트래픽이 거의 없는데 상대가 304KB를 밀어 넣었습니다. 정상적인 요청-응답 대화(파일 요청 후 다운로드 등)에서는 요청 패킷들이 <- 측에 존재합니다. 이 비대칭은 "우리가 시킨 적 없는 전송"이라는 이상의 직접 증거입니다.

문제 2 해답. 이름 길이 조건 — 예: dns.qry.name.len > 40. DNS 터널링은 데이터를 라벨에 싣기 때문에 질의 이름이 비정상적으로 깁니다. 정상 도메인은 사람이 치는 이름이라 짧습니다. 길이 외에도 "같은 상위 도메인 아래 질의 빈도"(-T fields -e dns.qry.name | sort | uniq -c로 확인)가 두 번째 조건이 됩니다.

문제 3 해답. 볼 수 있는 것: 상대방 IP·포트, 통신의 크기와 시각, (SNI가 평문이라면) 접속한 도메인. 볼 수 없는 것: URL 경로(/login), 폼 필드, 자격증명, 응답 본문 — 전부 TLS 안쪽입니다. 그래서 HTTPS 시대의 분석은 "내용" 대신 "행위(누구와, 얼마나, 어떤 리듬으로)" 중심으로 이동했습니다 — 3-5의 통계 기법이 그대로 그 시대의 도구입니다.

문제 4 해답. 정상 다운로드에서 연결 개시자(SYN 발신자)는 항상 우리 PC입니다 — 우리가 문을 두드려야 서버가 열어 줍니다. [SYN]이 외부에서 왔다는 것은 이 대화가 우리의 요청으로 시작되지 않았다는 증거이므로 "사용자가 파일을 받았다" 가설은 성립 불가입니다. 남는 가설은 역접속(방화벽 우회 기법)이나 미리 뚫린 경유지 — 어느 쪽이든 비정상입니다.

완료 기준 체크리스트

  • [ ] io,phs와 conv,tcp 통계로 분석 시작점을 정할 수 있다
  • [ ] -T fields -e 조합으로 원하는 필드를 표로 뽑을 수 있다
  • [ ] follow,tcp,ascii,N으로 대화 내용을 재조립했다
  • [ ] DNS 터널링의 두 가지 얼굴(긴 서브도메인, 반복 질의)을 안다
  • [ ] 외부발 SYN을 이상 징후로 읽을 수 있다
  • [ ] tshark 출력을 sort | uniq -c 파이프라인에 연결할 수 있다
  • [ ] 미션: 필터 5종 적용 + 근거 달린 타임라인을 완성했다

6. 흔한 실수와 해결

벽 1. 필터는 걸었는데 아무것도 안 나온다

증상: tshark -r f -Y "http"가 빈 결과입니다.
원인: 그 pcap에 정말 HTTP가 없거나, HTTP가 비표준 포트(80이 아닌 포트)에서 오가서 프로토콜 자동 해석이 안 된 경우입니다.
해결: -z io,phs로 프로토콜 지도부터 확인하세요. 비표준 포트라면 -d tcp.port==8080,http로 해석을 강제할 수 있습니다.

벽 2. -z follow가 에러를 낸다

증상: tshark -z follow,tcp,ascii,0에서 스트림을 못 찾습니다.
원인: 스트림 번호는 파일마다 0부터 다시 매겨집니다. 다른 파일의 번호를 가져왔거나, 필터와 함께 쓸 때 번호가 어긋난 경우입니다.
해결: -z conv,tcp로 이 파일의 대화 목록을 먼저 보고 번호를 확인하세요. 스트림 번호는 "이 파일 안에서의 인덱스"입니다.

벽 3. 필드 이름을 몰라서 -e가 먹지 않는다

증상: -T fields -e http.passwd 같은 추측한 이름이 빈 칸을 냅니다.
원인: Wireshark의 필드 이름은 정해진 계층형 명칭입니다 (http.request.uri, dns.qry.name …).
해결: GUI의 패킷 상세 창에서 필드를 클릭하면 왼쪽 아래 상태 표시줄에 정확한 필드 이름이 뜹니다 (화면 예시). GUI에서 이름을 확인하고 tshark로 옮기는 것이 실전 워크플로입니다.

벽 4. Running as user "root" ... This could be dangerous 경고가 신경 쓰인다

증상 (2026-09-09 실측): tshark 실행 때마다 이 경고가 stderr로 나옵니다.
원인: WSL에서 root로 실행 중이기 때문입니다. 출력 자체는 정상입니다.
해결: 무시해도 분석에는 지장이 없지만, 파이프라인에 얹을 때 섞이지 않게 2>/dev/null로 stderr를 버리는 습관이 편합니다.

벽 5. pcap이 커서 tshark가 느리다

증상: 수만 패킷 파일에 필터를 걸 때마다 수 초씩 걸립니다.
원인: tshark는 매번 파일 전체를 순회합니다.
해결: 조사가 진행되면서 좁혀지면, 좁힌 결과를 -w 부분.pcap으로 저장해 그 파일을 이어서 분석하세요. 바다 → 웅덩이 → 컵 순으로 옮기는 것이 대용량 분석의 정석입니다.

7. 정리

오늘의 개념

개념 한 줄 설명
3단 체계 통계(지도) → 필터(굴착) → 스트림(정독) — 눈 스크롤은 마지막
TCP 스트림 같은 대화의 인덱스 — follow의 단위
평문의 위험 HTTP POST는 엽서 — 자격증명이 그대로 보인다
DNS 터널링 긴 서브도메인 + 반복 질의 = 밀서의 얼굴
역접속 외부가 먼저 보낸 SYN — "우리가 시킨 적 없는 대화"
비대칭 대화 한 방향으로만 큰 대화는 요청 없는 전송

오늘의 명령어·필터

명령·필터 하는 일
tshark -r f -q -z io,phs 프로토콜 지도 (뭐가 얼마나)
tshark -r f -q -z conv,tcp 대화 목록 (누가 누구와 얼마나)
http.request.method == "POST" 폼 제출만 골라내기
dns.qry.name contains "…" 이름에 특정 문자열 포함 질의
tcp.stream eq N N번 대화만 보기
-T fields -e 필드 필드만 표로 추출
-q -z follow,tcp,ascii,N 대화 내용 통째 재조립
| sort | uniq -c | sort -rn 빈도 순위 — 조사의 첫 지도

명령어보다 중요한 감각

패킷 분석의 실력은 필터 암기가 아니라 질문의 순서입니다. "뭐가 있나(통계) → 어디가 이상한가(비대칭·폭주·상식 밖) → 그 대화의 내용은(스트림) → 다른 증거와 연결되는가(타임라인)". 오늘 시나리오에서 평문 로그인과 DNS 조각이 서로를 증명했듯이, 포렌식의 결론은 언제나 증거들의 교차 확인에서 나옵니다.

그리고 이 모든 분석이 "내가 만든 증거 파일"에서 이뤄졌다는 점을 다시 새겨 둡니다. 같은 기술을 남의 네트워크에서 캡처한 파일에 적용하는 것은 전혀 다른 일 — 법과 허가의 영역입니다.

전부 체크되면 Step 241 완료입니다. 사이드바의 체크박스를 눌러 진도를 저장하세요.

← 이전 스텝
다음 스텝 →