[보안] Wireshark로 악성 트래픽 탐지: 네트워크 포렌식 기법

목차

• 1. 왜 Wireshark 악성코드 분석이 중요한가
• 2. 네트워크 포렌식의 핵심 개념 정리
• 정상 트래픽과 의심 트래픽 비교
• 3. 실전 준비: 캡처 환경과 분석 범위부터 정합니다
• 4. Wireshark로 악성 트래픽 좁혀 가는 순서
• HTTP와 TLS에서 제가 먼저 보는 것
• 5. 네트워크 포렌식 심화: 스트림 재조립과 객체 추출
• 6. ⚠️ 실무에서 겪는 함정과 패킷 분석 보안 해결법
• 문제 1. 암호화된 TLS 때문에 내용이 안 보입니다
• 문제 2. 캡처 파일이 너무 커서 Wireshark가 버벅입니다
• 문제 3. 정상 관리 도구를 악성으로 오인했습니다
• 7. 분석 결과 검증: IOC 정리와 재현 확인
• 8. Wireshark 악성코드 분석 FAQ와 침해 사고 대응 팁
• Q1. Wireshark만으로 악성코드 감염을 확정할 수 있나요?
• Q2. DNS만 봐도 도움이 되나요?
• Q3. 패킷 분석 보안 업무를 처음 시작한다면 뭘 먼저 익혀야 할까요?
• 9. 마무리: 결국 중요한 건 패턴을 읽는 눈입니다

[보안] Wireshark로 악성 트래픽 탐지: 네트워크 포렌식 기법

현장에서 사고 대응하다 보면 로그(Log)만으로는 답이 안 나오는 순간이 꼭 옵니다. 서버는 멀쩡해 보이는데 외부로 뭔가 계속 나가고, EDR(Endpoint Detection and Response, 엔드포인트 탐지 및 대응) 알림은 애매하고, 방화벽 로그도 조각난 상태인 경우 말이죠. 이럴 때 제가 끝까지 붙잡고 보는 도구가 바로 Wireshark입니다. 특히 Wireshark 악성코드 분석이 필요한 상황에서는 패킷(Packet, 네트워크를 오가는 데이터 조각) 자체가 거의 마지막 단서가 되더라고요. 저도 처음엔 화면에 줄줄이 뜨는 패킷을 보고 이게 뭔가 싶었는데, 몇 번 삽질하고 나니 침해 흔적을 찾는 순서가 보이기 시작했습니다.

이번 글은 단순히 필터 몇 개 소개하는 수준이 아니라, 네트워크 포렌식 관점에서 악성 트래픽을 어떻게 좁혀 가는지, 어떤 표시가 진짜 위험 신호인지, 그리고 침해 사고 대응 때 무엇부터 확인해야 하는지를 제 경험 기준으로 정리한 내용입니다. 홈랩에서도 재현 가능한 방식으로 풀어볼 테니, 보안 분석을 막 시작하신 분이나 운영 중 이상 트래픽 때문에 답답하셨던 분들께 도움이 될 겁니다.

패킷 캡처부터 악성 징후 식별, IOC 정리까지 이어지는 전체 분석 흐름을 보여주는 개요 이미지입니다.

1. 왜 Wireshark 악성코드 분석이 중요한가

쉽게 말해, 악성코드가 남기는 흔적은 파일(File)만이 아니라 통신(Communication)에도 남습니다. 프로세스 이름은 위장할 수 있어도, C2(Command and Control, 명령제어) 서버와의 통신 패턴, 비정상 DNS 질의, 평소와 다른 User-Agent, 짧은 주기의 반복 연결 같은 건 생각보다 숨기기 어렵거든요. 실제로 제가 예전에 겪었던 케이스도 그랬습니다. 서버 자원 사용량은 평범했는데, 외부 특정 IP로 주기적인 TLS 세션이 계속 열리더라고요. 처음엔 백업 에이전트인가 했는데, SNI(Server Name Indication)와 세션 간격을 보니 전형적인 비콘(Beacon) 패턴이었습니다. 그때 패킷 안 봤으면 놓쳤을 가능성이 높았습니다.

여기서 중요한 포인트는 하나입니다. 패킷 분석 보안 업무는 패킷을 많이 보는 게 아니라, 수상한 통신을 빠르게 걸러내는 기준을 갖는 것입니다. 무작정 다 보면 시간만 날아갑니다 ㅎㅎ

2. 네트워크 포렌식의 핵심 개념 정리

제가 후배들한테 설명할 때는 복잡하게 안 갑니다. 아래 네 가지만 먼저 잡으라고 말합니다.

• Baseline(베이스라인, 평소 정상 통신 기준): 평소 어떤 프로토콜과 목적지로 통신하는지 알아야 이상이 보입니다.
• Indicator(인디케이터, 징후): 악성 여부를 직접 증명하지는 않지만 의심할 만한 패턴입니다.
• IOC(Indicator of Compromise, 침해 지표): 의심을 넘어서 차단·탐지 룰에 활용할 수 있는 구체 정보입니다. 예를 들면 도메인, IP, URI, 해시 같은 것들이죠.
• Stream Reassembly(스트림 재조립): 쪼개진 TCP 세션을 이어 붙여 실제 대화 내용을 보는 기능입니다.

악성 트래픽에서 자주 보는 징후는 대체로 비슷합니다. DNS가 유난히 길거나, HTTP 요청 헤더가 빈약하거나, TLS 핸드셰이크는 있는데 인증서 정보가 이상하거나, 특정 주기로 아주 작은 패킷이 반복되는 식입니다. 물론 이것만으로 바로 악성이라고 단정하면 안 됩니다. CDN(Content Delivery Network)이나 모니터링 에이전트도 비슷하게 보일 때가 있어서, 패킷 분석 보안에서는 결국 여러 신호를 겹쳐서 판단해야 합니다.

정상 트래픽과 의심 트래픽 비교

항목	정상 가능성	의심 신호
DNS 질의	사내/공개 리졸버로 일반 도메인 조회	랜덤한 하위 도메인 반복, TXT 질의 과다
HTTP 요청	브라우저/에이전트 형태의 자연스러운 헤더	비어 있거나 비정상적인 User-Agent, 짧은 URI 반복
TLS 통신	검증 가능한 인증서 체인, 일반적인 SNI	SNI 없음, 매우 잦은 재연결, 목적지 편중
세션 주기	사용자 행동 또는 배치 주기에 따라 변동	정확한 간격으로 반복되는 비콘 패턴

3. 실전 준비: 캡처 환경과 분석 범위부터 정합니다

여기서 많이들 실수하는 게, 일단 캡처부터 길게 떠놓는 겁니다. 근데 사고 대응에서는 범위를 먼저 정해야 합니다. 제가 보통 잡는 기준은 이렇습니다.

1. 이상 징후가 발생한 시간대 확인
2. 영향 받은 호스트 IP 또는 서버 NIC(Network Interface Card, 네트워크 인터페이스) 확인
3. 인바운드(Inbound, 유입)인지 아웃바운드(Outbound, 유출)인지 우선 분류
4. 필요하면 미러링 포트(Port Mirroring) 또는 span 구간에서 추가 캡처

Wireshark GUI만 써도 되지만, 저는 침해 사고 대응 현장에서는 tcpdump나 tshark로 먼저 캡처하고 나중에 Wireshark로 파는 편입니다. 서버에서 GUI 띄우는 건 부담이 있고, 장시간 수집에는 CLI(Command Line Interface, 명령행 인터페이스)가 훨씬 안정적이거든요.

sudo tcpdump -i eth0 -nn -s 0 -w suspicious.pcap host 192.0.2.10

위 명령은 특정 호스트 중심으로 패킷을 통째로 저장합니다. <code>-s 0 옵션으로 패킷 전체를 저장하는 게 포인트입니다. 잘라 먹으면 나중에 HTTP body나 인증서 정보 복원할 때 후회합니다.

tshark -r suspicious.pcap -q -z conv,ip

이건 대화 상대(IP conversation)를 먼저 훑어보는 용도입니다. 실제로 써보니까 처음부터 패킷 한 줄씩 보는 것보다, 누가 누구랑 얼마나 많이 이야기했는지 보는 게 훨씬 빠르더라고요.

4. Wireshark로 악성 트래픽 좁혀 가는 순서

제가 자주 쓰는 흐름은 거의 고정입니다. 처음엔 이것저것 눌러보다 시간이 많이 날아갔는데, 지금은 아래 순서대로 보면 놓치는 게 확실히 줄었습니다.

1. Statistics > Conversations로 상위 통신 쌍 확인
2. Statistics > Protocol Hierarchy로 평소와 다른 프로토콜 비중 확인
3. DNS, HTTP, TLS부터 1차 필터링
4. 의심 세션에 대해 Follow TCP Stream으로 내용 확인
5. 파일 다운로드 흔적이나 인코딩 데이터가 있으면 Export 또는 carve 검토
6. 최종적으로 IOC 정리

자주 쓰는 디스플레이 필터(Display Filter)는 아래 정도만 익혀도 체감이 큽니다.

dns
http
http.request
http.response
tls
ip.addr == 192.0.2.10
tcp.stream eq 5
dns.qry.name contains "update"
http.user_agent

특히 tcp.stream eq 번호는 정말 많이 씁니다. 같은 세션만 깔끔하게 분리해서 볼 수 있어서, 공격 흐름 따라가기에 좋거든요. 그리고 DNS를 볼 때는 단순 성공 응답만 보지 말고 질의 이름의 길이, 반복성, NXDOMAIN 여부도 함께 보세요. DGA(Domain Generation Algorithm, 도메인 생성 알고리즘) 계열은 여기서 냄새가 날 때가 많습니다.

디스플레이 필터, Conversations, Protocol Hierarchy를 함께 보는 실제 분석 흐름 예시 이미지입니다.

HTTP와 TLS에서 제가 먼저 보는 것

• Host 헤더: 정상 업무 도메인인지 확인
• User-Agent: 지나치게 단순하거나 비어 있지 않은지 확인
• URI 패턴: 짧은 경로를 반복 호출하는지 확인
• TLS SNI: 어떤 서버 이름으로 붙는지 확인
• Certificate 정보: 발급자와 주체가 비정상적으로 보이지 않는지 확인

여기서 팁 하나 드리면, TLS 자체가 암호화되어 있어도 메타데이터(metadata, 부가 정보)는 꽤 많이 남습니다. 그래서 내용이 안 보여도 통신 상대, 세션 주기, 핸드셰이크 빈도만으로도 상당히 많은 판단이 됩니다.

5. 네트워크 포렌식 심화: 스트림 재조립과 객체 추출

침해 사고 대응에서 의심 세션을 찾았으면 이제 안쪽을 봐야 합니다. Wireshark의 Follow TCP Stream 또는 Follow HTTP Stream 기능이 여기서 빛을 발합니다. 처음엔 이 기능이 그냥 보기 편한 뷰 정도로 느껴졌는데, 실제로는 가장 빠른 단서 수집 창구였습니다.

1. 의심 패킷 선택
2. 우클릭 후 Follow TCP Stream
3. 요청과 응답의 반복 패턴 확인
4. Base64 같은 인코딩 흔적이 있으면 별도 복호화 검토
5. HTTP 객체가 보이면 Export Objects 사용

tshark -r suspicious.pcap -Y "http.request" -T fields -e ip.src -e ip.dst -e http.host -e http.request.uri

이런 식으로 뽑아두면 IOC 정리가 빨라집니다. GUI에서 눈으로만 보면 놓치기 쉬운 반복 URI도 금방 보이거든요.

tshark -r suspicious.pcap -Y "dns" -T fields -e frame.time -e ip.src -e dns.qry.name

DNS 질의만 따로 떼서 시간순으로 보면, 일정 간격으로 긴 도메인이 반복되는지 바로 드러납니다. 제가 홈랩에서 테스트 악성 샘플 통신을 재현해봤을 때도 결국 핵심은 화려한 기능보다 이런 단순 추출이었습니다. 드디어 됐다! 싶은 순간이 꼭 옵니다.

6. ⚠️ 실무에서 겪는 함정과 패킷 분석 보안 해결법

이 섹션은 진짜 경험담입니다. 저도 처음엔 Wireshark만 켜면 다 보일 줄 알았는데, 현실은 그렇지 않더라고요.

문제 1. 암호화된 TLS 때문에 내용이 안 보입니다

정상입니다. 요즘은 대부분 암호화되어 있으니까요. 이럴 땐 평문 복호화에 집착하기보다 아래를 봅니다.

• 목적지 IP와 도메인 관계
• SNI 유무
• 세션 생성 주기
• 전송 바이트 크기 편차
• 같은 서버로의 반복 연결

즉, 콘텐츠가 아니라 행위 패턴을 보는 겁니다. 이게 침해 사고 대응에서 꽤 중요합니다.

문제 2. 캡처 파일이 너무 커서 Wireshark가 버벅입니다

이건 정말 자주 겪습니다. 하루치 pcap을 통째로 열면 고생 시작입니다. 저는 보통 CLI로 먼저 자릅니다.

tshark -r suspicious.pcap -Y "ip.addr == 192.0.2.10" -w focused.pcap

대상 호스트 기준으로 줄여놓고 다시 열면 훨씬 낫습니다. 시간대가 명확하면 그 구간만 캡처하거나 분할 저장하는 것도 좋습니다.

문제 3. 정상 관리 도구를 악성으로 오인했습니다

백업 에이전트, 모니터링 에이전트, 원격 관리 툴이 의외로 수상하게 보일 때가 많습니다. 그래서 Baseline이 중요합니다. 평소에 자산 목록, 허용 통신, 에이전트 목록을 정리해두면 이런 오탐(False Positive, 정상인데 경보가 뜨는 경우)을 많이 줄일 수 있습니다. 저도 처음엔 이거 때문에 삽질 좀 했습니다 ㅎㅎ

의심 세션을 Follow TCP Stream으로 열어 요청/응답 패턴을 확인하는 장면을 표현한 이미지입니다.

7. 분석 결과 검증: IOC 정리와 재현 확인

분석은 발견으로 끝나면 안 됩니다. 운영에 반영할 수 있어야 의미가 있습니다. 저는 보통 아래 형태로 결과를 정리합니다.

1. 의심 출발지/목적지 IP
2. 관련 도메인 또는 SNI
3. 반복된 URI 또는 DNS 질의 패턴
4. 최초 발견 시각과 반복 주기
5. 연관 프로세스 또는 호스트 역할
6. 차단 또는 모니터링 권고 사항

그리고 가능하면 재현 검증도 합니다. 예를 들어 같은 호스트에서 같은 시간대에 동일한 통신이 다시 발생하는지, 방화벽 차단 후 재시도 흔적이 사라지는지 확인하는 식입니다. 이 단계까지 가야 분석 결과가 실제 보안 운영에 연결됩니다.

검증 항목	확인 방법	기대 결과
목적지 재접속 여부	차단 후 동일 세션 재발 확인	반복 연결 감소 또는 중단
DNS 재질의 여부	동일 도메인 질의 추적	비정상 질의 패턴 소멸
호스트 범위 확산 여부	다른 내부 IP 동일 통신 확인	추가 감염 호스트 식별 또는 없음
탐지 룰 적용성	IOC 기반 룰 반영 후 경보 확인	재탐지 가능 상태 확보

의심 IP, 도메인, 세션 주기와 차단 전후 변화를 한눈에 보여주는 결과 요약 이미지입니다.

이 과정까지 마치면 단순한 Wireshark 악성코드 분석을 넘어, 조직 내부의 대응 체계까지 손볼 포인트가 보입니다. 어떤 자산이 외부와 자유롭게 통신하는지, DNS 모니터링이 부족한지, 로그 보존이 충분한지 같은 부분 말이죠.

8. Wireshark 악성코드 분석 FAQ와 침해 사고 대응 팁

Q1. Wireshark만으로 악성코드 감염을 확정할 수 있나요?

보통은 어렵습니다. 패킷은 강력한 증거지만, 프로세스 정보나 파일 흔적 없이 단독으로 확정하기엔 한계가 있습니다. 그래서 EDR, Sysmon, 방화벽 로그, 프록시 로그와 같이 보셔야 합니다.

Q2. DNS만 봐도 도움이 되나요?

네, 생각보다 큽니다. 특히 외부 유출(Exfiltration, 정보 빼내기)이나 DGA 계열은 DNS에서 이상 징후가 먼저 보이는 경우가 많습니다. DNS 분석은 패킷 분석 보안의 가장 빠른 입구입니다.

Q3. 패킷 분석 보안 업무를 처음 시작한다면 뭘 먼저 익혀야 할까요?

제가 현장에서 직접 침해 사고 대응을 해보니 아래 순서가 가장 효율적이었습니다.

1. TCP 3-way handshake와 세션 개념 이해
2. DNS, HTTP, TLS 기본 구조 이해
3. Wireshark 디스플레이 필터 익히기
4. Follow TCP Stream과 Conversations 기능 익히기
5. IOC 정리 습관 만들기

이전 글에서 다뤘던 로그 기반 분석과 같이 보시면 더 잘 연결됩니다. 다음 글에서는 Zeek나 Suricata와 연계해서 pcap 없이도 이상 행위를 추적하는 흐름을 다뤄볼 예정입니다.

9. 마무리: 결국 중요한 건 패턴을 읽는 눈입니다

Wireshark는 기능이 많아서 처음엔 압도적입니다. 저도 처음엔 메뉴가 너무 많아서 괜히 겁먹었었는데, 실제로 써보니까 핵심은 몇 가지로 압축되더라고요. 누가 누구와 통신하는지, 그 주기가 이상한지, DNS/HTTP/TLS에서 어색한 흔적이 있는지, 그리고 세션을 따라가면 무엇이 보이는지. 이 네 가지만 잡아도 분석 품질이 꽤 올라갑니다.

Wireshark 악성코드 분석은 화려한 트릭보다 기본기가 더 중요합니다. 캡처 범위를 정확히 잡고, 정상 패턴과 비교하고, 의심 세션을 깊게 파고드는 순서 말이죠. 혹시 지금 운영 환경에서 애매한 외부 통신 때문에 답답하셨다면, 오늘 소개한 네트워크 포렌식 흐름대로 한 번만 따라가 보세요. 생각보다 빨리 실마리가 잡힐 겁니다.

필터링, 스트림 분석, IOC 정리, 대응 반영까지의 핵심 포인트를 한 장으로 요약한 이미지입니다.

정리하자면 이렇습니다.

• 네트워크 포렌식은 패킷을 전부 보는 작업이 아니라 의심 신호를 구조적으로 좁혀 가는 작업입니다.
• 패킷 분석 보안의 핵심은 정상 베이스라인과 비교하는 습관입니다.
• 침해 사고 대응에서는 발견 후 IOC 정리와 차단 검증까지 이어져야 합니다.

현장에서 정말 많이 느끼는 건, 잘 만든 분석 루틴 하나가 삽질 시간을 엄청 줄여준다는 점입니다. 이거 진짜 편하더라고요. 독자분들도 꼭 한 번 자기만의 분석 체크리스트를 만들어 보셨으면 합니다.

📚 함께 읽으면 좋은 글

• Nmap 오류 해결: 스캔 실패 원인부터 디버깅 팁까지