Wireshark

What It Is

Wireshark is the standard tool for packet capture and protocol analysis. It places a network interface into promiscuous mode — reading every packet reaching that interface, not just packets addressed to it — and dissects the raw bytes into human-readable protocol layers.

MITRE maps packet capture tools to T1040 (Network Sniffing): adversaries use tcpdump and Wireshark to steal credentials sent over cleartext protocols, map internal network topology, and capture authentication material for lateral movement.

Essential Wireshark Concepts

Display Filters vs. Capture Filters

Rule of thumb: Capture everything and filter during analysis (display filters) unless you are on a system with very limited disk or processing power.

Color Rules

Wireshark color-codes packets by protocol. Default rules you’ll see constantly:

• Light purple: TCP traffic
• Light blue: UDP traffic
• Light green: HTTP traffic
• Light yellow: DNS traffic
• Dark pink: ICMP traffic
• Red: TCP RST (connection reset) or abnormal packets

You can create custom color rules. A useful one: color all packets with tcp.flags.syn==1 and tcp.flags.ack==0 (SYN packets) as one color, and all http.request packets as another.

Display Filter Quick Reference — The 30 You Use Every Day

Basic Protocol Filters

IP and Host Filters

Port and Service Filters

TCP Flag Filters

HTTP Analysis Filters

DNS Analysis Filters

Length and Time Filters

Compound Filters

Capture Filter Quick Reference

Use these when collecting traffic live (before saving to disk).

Investigation Workflows

Workflow 1: C2 Beaconing Investigation

Scenario: A SIEM alert flagged a host making regular HTTPS connections to an unknown external IP.

Steps:

1. Isolate the traffic:

   ip.addr == IP_OF_SUSPICIOUS_HOST and tcp.port == 443

2. Look at timing patterns:

   • Switch to the “Statistics → Flow Graph” view to see connection timing
   • Add the tcp.time_delta column (Time since previous packet in this TCP stream)
   • Check the “Conversations” view (Statistics → Conversations) for connection counts and data volumes

3. Check TLS handshake metadata:

   tls.handshake.type == 1 and ip.addr == IP_OF_SUSPICIOUS_HOST

   • Extract the Server Name Indication (SNI) — the hostname the client requested
   • Check the JA3 fingerprint (Wireshark 3.2+): Statistics → JA3/JA3S → Client
   • C2 frameworks have distinctive JA3 fingerprints. Cross-reference with known-threat feeds.

4. Check the process behind the connection:

   • This requires Sysmon Event ID 3 on the endpoint. Cross-reference the connection timestamp with the Sysmon log.
   • If the source process is rundll32.exe, svchost.exe (non-service), or a suspicious path in AppData/Temp, it’s confirmed C2.

5. Follow the TCP stream:

   • Right-click a packet → Follow → TCP Stream
   • If HTTPS (encrypted), you won’t see the payload. Focus on timing, sizes, and TLS metadata.
   • Unusual patterns: consistent payload sizes (e.g., exactly 512 bytes of payload each time), small requests, small responses — beaconing.

Key indicators of C2 beaconing:

• Regular intervals: connections every 60 seconds ± 5 seconds
• Small, consistent payload sizes
• Short-lived connections (connect, send, receive, close)
• No human browsing pattern (no images, CSS, favicon requests)
• Suspicious JA3 fingerprint

Workflow 2: Data Exfiltration Investigation

Scenario: An alert indicates large outbound data transfers from an internal host.

Steps:

1. Isolate outbound traffic from the host:

   ip.src == INTERNAL_HOST and !(ip.dst == 10.0.0.0/8)

2. Analyze by protocol:

   # DNS tunneling check
   dns.qry.name and ip.src == INTERNAL_HOST
   
   # HTTP exfiltration check
   http.request.method == "POST" and ip.src == INTERNAL_HOST
   
   # All TCP traffic sorted by destination
   tcp and ip.src == INTERNAL_HOST and !(ip.dst == 10.0.0.0/8)

3. Check packet sizes:

   • Sort by frame.len (descending) — are there abnormally large packets?
   • For DNS: dns.resp.len > 512 is suspicious. dns.resp.len > 1400 is almost certainly tunneling.

4. Look for unusual protocols on standard ports:

   • SSH traffic on port 22 from a server that doesn’t do SSH
   • DNS traffic on non-standard ports
   • ICMP traffic with large payloads

5. Extract and examine:

   • File → Export Objects → HTTP (if HTTP traffic) — extract downloaded/uploaded files, then decode payloads with CyberChef
   • Statistics → Endpoints — see all IPs the host contacted
   • Statistics → Conversations — see total data transferred per conversation

Key indicators of data exfiltration:

• Large outbound transfers to a single external IP (multiple MB)
• DNS TXT queries with long subdomains (> 30 chars) and large responses (> 512 bytes)
• SSH/SFTP from servers to external IPs
• HTTP POST requests with large Content-Length headers
• Off-hours data transfers

Workflow 3: Port Scan Investigation

Scenario: A firewall alert indicates inbound port scanning.

Steps:

1. Isolate traffic from the scanning IP:

   ip.src == SCANNING_IP and tcp.flags.syn == 1

2. Check if it’s a half-open scan:

   tcp.flags.syn == 1 and tcp.flags.ack == 0 and ip.src == SCANNING_IP

   Count unique destination ports. If there are many, it’s a scan.

3. Check for abnormal flag combinations:

   ip.src == SCANNING_IP and (tcp.flags == 0x029 or tcp.flags == 0x000)

   (Xmas scan = 0x029, NULL scan = 0x000)

4. Check scan duration:

   • Statistics → Conversations — look at the timing range
   • A full subnet scan completes in seconds to minutes
   • A slow scan (over hours or days) with small numbers of packets is more sophisticated

Key indicators:

• TCP connections to closed ports (RST received for non-listening services)
• Random or sequential destination port patterns
• Abnormal TCP flag combinations (SYN-only, FIN, Xmas, NULL)
• Sequential IP scanning (10.0.0.1, 10.0.0.2, 10.0.0.3, etc.)

Workflow 4: Protocol Anomaly Investigation

Scenario: A detection rule flagged unusual protocol behavior.

Steps:

1. Check the TCP analysis flags (View → Coloring Rules → TCP Analysis):

   • TCP Retransmission: Packet loss — could be network issue or intentional evasiveness
   • TCP Duplicate ACK: Sign of packet loss or network congestion
   • TCP Fast Retransmission: Host detected packet loss and retransmitted — common in C2 under poor network conditions
   • TCP Out-of-Order: Packets arrived out of sequence — sometimes used by attackers to evade IDS
   • TCP Window Update: Receiver changed window size — could indicate buffer manipulation
   • ZeroWindow / WindowFull: Receiver buffer is full — DoS or misconfiguration

2. Check for protocol header anomalies:

   • Mismatched protocol/port (e.g., HTTP on port 53)
   • Invalid flag combinations
   • Unusual TTL values (TTL != 64 for Linux, != 128 for Windows — possible IP spoofing)

Useful Wireshark Preferences for Analysts

Enable these for faster analysis:

• Resolve MAC addresses → ON (identifies hardware vendors)
• Resolve transport names → ON (shows port names like “http” not just “80”)
• Use custom HTTP headers → ON (captures User-Agent, Referer, etc.)
• Enable TCP analysis → ON (shows retransmissions, dup ACKs, window issues)
• Show TCP sequence numbers in bytes → ON (easier to track data transfer amounts)
• Edit → Preferences → Appearance → Layout: Put packet list on top, packet details middle, packet bytes bottom

Related

• Snort and Suricata — detection and response for T1040 techniques
• Zeek (formerly Bro) — detection and response for T1040 techniques
• Wireshark 4.6.6 Release — how wireshark 4.6.6 released helps detect and analyze threats
• Network Security Basics — detection and response for T1040, T1046 techniques

Sources

• Wireshark User’s Guide
• Wireshark Display Filters Reference
• MITRE ATT&CK T1040
• Wireshark TCP Analysis
• PacketTotal — PCAP Analysis