---
# System prepended metadata

title: Analyze PCAP with Wireshark
tags: [Learning BlueTeam2026]

---

# PCAP & Network Traffic Analysis

## 1. What is PCAP? Why do SOC/IR teams need PCAP?

**PCAP (Packet Capture)** is data that records all network packets in chronological order, accurately reflecting what actually happened on the network.

**Primary purposes:**

- Supporting **incident response** and **network forensics**
- Avoiding subjective analysis or conclusions based solely on alerts/logs

PCAP is especially critical when it is necessary to **prove an activity or refute an alert**.

## 2. What PCAP can and cannot show

### What PCAP allows you to analyze:

- All packets along a timeline (client ↔ server)
- TCP behavior: handshakes and flags (SYN / ACK / RST / FIN)
- Network anomalies: retries, retransmissions, timeouts
- **Unencrypted** payloads (HTTP, DNS)
- Behavioral indicators: beaconing, scanning, incomplete downloads

### What PCAP cannot reveal:

- HTTPS/TLS content (without decryption keys)
- User context and intent (business intent)
- Which process/binary on the host generated the traffic

PCAP focuses on **network visibility**, but it must be correlated with **endpoint logs** to fully understand an incident.

## 3. When should a SOC analyst open PCAP?

Not every alert requires PCAP. PCAP is typically used when:

- You need to **validate an alert** (True Positive / False Positive)
- There is suspicion of real impact (data exfiltration, malware download)
- Investigating abnormal patterns (beaconing, repeated RSTs)
- Verifying whether a downloaded file is **complete or truncated**
- Extracting detailed IOCs: IP, domain, URI, certificate fingerprint

## 4. Basic understanding of TCP & TLS/SSL

### TCP:

- 3-way handshake: `SYN → SYN-ACK → ACK`
- Reset (RST): intentional blocking vs connection error
- Retransmissions: network issues vs server overload
- Flow duration and packet size

### TLS:

- ClientHello: SNI, cipher suites
- ServerHello + Certificate
- TLS handshake timing (latency)
- Payload is not visible without decryption

![image](https://hackmd.io/_uploads/rJaYQ9LSbx.png)

## 5. Wireshark: Essential filters

```text
ip.addr == 192.168.1.1
ip.src == 192.168.1.2 && ip.dst == 8.8.8.8
tcp.port == 443
dns
http
tls || ssl
tcp.stream eq 7
tcp.flags.reset == 1
http.request.method == "POST"
frame.time >= "Oct 10, 2025 08:00:00"
````

**Notes:**

* Narrower filters → more accurate analysis
* Use `tcp.stream` to follow a complete conversation

## 6. Key data fields SOC analysts should correlate

When reviewing alerts together with PCAP, always ask:

* **Alert / Rule**: what detection rule triggered it?
* **Source / Destination**: who is communicating with whom?
* **Timestamp**: does it correlate with other events?
* **Action**: Blocked / Allowed / Success / Fail?
* **Severity**: response priority?
* **Artifact / IOC**: IP, domain, URL, hash, certificate
* **Context**: critical asset? VIP user? legitimate traffic?

⇒ Lack of context often leads to false positives.

## 7. Decrypting TLS traffic

![image](https://hackmd.io/_uploads/SJGkm9ISZg.png)

### Method 1: Using SSLKEYLOGFILE

**Principle:**
Browsers such as Chrome and Firefox (and some applications) can automatically log TLS session keys when the `SSLKEYLOGFILE` environment variable is enabled. This file contains master secrets that Wireshark can use to decrypt TLS traffic.

### Method 2: Browser Memory Dump

**Principle:**
While a browser maintains active HTTPS connections, session keys reside in the process memory. By dumping the browser’s memory and extracting strings matching the pattern `CLIENT_RANDOM`, the required master secrets can be obtained for TLS decryption.