🦈 Wireshark Mastery — WCA-101 + SOC / IR / Network Forensics Field Guide

A single, deep, practical reference to take you from "I can open a pcap" to passing the Wireshark Certified Analyst (WCA-101) exam and working real cases in a SOC, Incident Response, or Network Forensics role.

Everything here is applied knowledge: filters you can paste, header fields you must know cold, attacker traffic patterns, and troubleshooting workflows.

How to use this guide

This document is deliberately structured to serve two goals at once:

Goal	How this guide serves it
Pass WCA-101	Every major section is tagged with the official exam domain and weight (e.g. `🎯 Domain 5.10 — TCP (17%)`). If it's on the exam, it's flagged.
Do real SOC / IR / forensics work	Look for the 🔍 Analyst Lens callouts — these turn each protocol into detection logic, IOCs, and hunt queries.

Recommended path:

Read top-to-bottom once for the mental model.
Do every filter in this guide against a real capture (start your own with File → Capture, or download sample pcaps — see Practice Resources).
Come back and use the Cheat Sheets as working reference.

Legend used throughout: 🎯 = maps to a WCA-101 exam objective • 🔍 = SOC/IR/Forensics application • ⚠️ = common mistake / exam trap • 💡 = pro tip

📋 Table of Contents

Part I — Foundations

The WCA-101 Exam, Decoded
How Packets Flow Through a Network
Installing & First Capture
The Wireshark Interface (every pane explained)

Part II — Capturing Like a Pro 🎯 Domain 2 (10%) 5. Capture Methods: TAP, SPAN, Endpoint, Multi-point 6. Capture Options, Ring Buffers & Limits 7. Promiscuous vs Monitor Mode 8. Command-Line Capture: dumpcap, tshark, tcpdump

Part III — Filtering 🎯 Domain 3 (12%) 9. Capture Filters (BPF) 10. Display Filters — Complete Reference 11. Operators, Membership, and the ! Trap 12. Filter Buttons, Macros & the "incomplete results" trap

Part IV — Interface Mastery 🎯 Domain 4 (5%) 13. Columns, Coloring Rules & the Minimap 14. Profiles — your most underrated tool 15. Protocol Preferences & "Decode As"

Part V — Key Features 🎯 Domain 1 (10%) 16. Find Packet, Marks, Comments & Time References 17. Name Resolution & Capture File Properties 18. Statistics: Protocol Hierarchy, Conversations, Endpoints, I/O Graph 19. Following Streams & Exporting Objects

Part VI — Protocol Deep Dives 🎯 Domain 5 (43%) 20. Ethernet 5.1 21. ARP 5.2 22. IPv4 5.3 23. ICMPv4 5.4 24. IPv6 & ICMPv6 5.5–5.6 25. UDP 5.7 26. DHCPv4 (DORA) 5.8 27. DNS 5.9 28. TCP — the big one 5.10 (17%)

Part VII — Application Layer & Troubleshooting 🎯 Domain 6 (20%) 29. HTTP / HTTPS / TLS 30. Troubleshooting Methodology & Scenarios 31. The Expert Information System

Part VIII — Security Operations 🔍 SOC / IR / Forensics 32. Threat Hunting in pcap 33. Malware, C2 & Beaconing Detection 34. Data Exfiltration & DNS Tunneling 35. Network Forensics & Evidence Handling 36. A Repeatable IR Triage Workflow

Part IX — Reference 37. Master Cheat Sheet 38. 30-Day Study Plan 39. Practice Resources

Part I — Foundations

1. The WCA-101 Exam, Decoded

The Wireshark Certified Analyst (WCA-101) is the official Wireshark Foundation certification, launched June 2025, authored by Chris Greer and Ross Bagurdes with input from Gerald Combs (Wireshark's creator).

Exam facts

Attribute	Detail
Questions	50–60
Question types	Multiple choice/selection, matching, fill-in-the-blank
Time	120 minutes
Delivery	Kryterion / Webassessor — testing center or online, human-proctored (webcam + mic)
Allowed	Pen/pencil + blank paper only. No notes, devices, or software.
Retake	One attempt per 15 days
Validity	3 years (renew by retaking)
Practice exam	~US $29 via Webassessor (worth it — gives per-question feedback)

Exam domains & weightings (memorize this table)

#	Domain	Weight
1.0	Utilize key features of Wireshark	10%
2.0	Methods of capturing traffic	10%
3.0	Capture and display filters	12%
4.0	Configure/adapt the Wireshark interface	5%
5.0	Common network protocols	43%
—	↳ of which TCP alone	(17%)
—	↳ non-TCP protocols	(27%)
6.0	Troubleshoot common protocol issues	20%

⚠️ Where the exam is won or lost: Domains 5 (protocols, 43%) and 6 (troubleshooting, 20%) are 63% of your score, and TCP alone is 17% and scored separately. If your TCP and troubleshooting are weak, you fail regardless of everything else. Spend your study time proportionally.

🔍 Good news for security folks: the exam's protocol depth is your forensics/IR foundation. You cannot detect a malicious TCP session, a beacon, or DNS tunneling if you don't first understand what normal looks like at the byte level. This guide teaches "normal" and "malicious" side by side.

2. How Packets Flow Through a Network

🎯 Domain 5/6 explicitly test "describe packet flow through a data network" and "determine network topology only using information in a packet capture." This mental model is the backbone of everything.

Encapsulation — the nesting doll

Every packet Wireshark shows you is a set of nested headers. Data is wrapped as it goes down the sending stack and unwrapped going up the receiving stack.

┌──────────────────────────────────────────────────────────────┐
│ Ethernet Header │ IP Header │ TCP Header │  Application Data   │  Ethernet FCS
│  (Layer 2)      │ (Layer 3) │ (Layer 4)  │  (Layer 7)          │  (dropped by NIC)
└──────────────────────────────────────────────────────────────┘
   Dest/Src MAC     Dest/Src IP  Dest/Src Port   HTTP / DNS / TLS...
   EtherType        TTL, Proto   Seq/Ack, Flags

Wireshark's Packet Details pane shows exactly this stack, one expandable tree per layer, top (Frame) to bottom (application).

What changes at each hop (critical for topology & TTL analysis)

As a packet crosses a router (Layer 3 hop):

Field	Changes at each router?	Why it matters
Source/Dest MAC	✅ Yes — rewritten every hop	MAC is only locally significant. The MAC you see is the last device that forwarded the frame to your capture point.
Source/Dest IP	❌ No (unless NAT)	End-to-end identity. NAT is the exception (see §22).
TTL	✅ Decremented by 1 each router	Lets you estimate hop distance from the capture point.
IP Total Length / payload	❌ No (unless fragmentation)	—

💡 The single most useful topology trick: Look at the TTL of arriving packets and compare to the sender's typical OS default (Windows = 128, Linux/macOS = 64, many network devices = 255). If a Linux host's packets arrive with TTL 61, they crossed 64 − 61 = 3 routers to reach your capture point. 🎯 Domain 5.3: "Predict most likely distance, in hops, from the capturing device."

Layer 2 vs Layer 3 delivery — the switch/router divide

Same subnet (Layer 2): Host ARPs for the destination's MAC, frames go switch→switch, IP unchanged, MAC = actual destination.
Different subnet (Layer 3): Host ARPs for its default gateway's MAC, sends the frame to the router's MAC (but the destination IP is the far-away host). The router then forwards on. This is why dest MAC ≠ dest IP owner when talking off-subnet — a classic exam matching question.

🔍 Forensics application: In a capture, if you see a host sending to many external IPs but always to the same destination MAC, that MAC is the gateway/router. Mapping MAC↔IP relationships reconstructs the local topology from a single pcap — exactly what you do when you're handed an unknown capture in an IR case.

3. Installing & First Capture

Install

Windows / macOS: download from wireshark.org/download. On Windows, install Npcap (bundled) — it's the packet capture driver. Check "Install Npcap in WinPcap API-compatible mode" if older tools need it.
Linux: sudo apt install wireshark (Debian/Ubuntu) or sudo dnf install wireshark. During install, allow non-root capture so you don't have to run Wireshark as root (it adds you to the wireshark group; log out/in after).
Never run Wireshark as root/admin for routine work — the dissectors parse hostile input; a capture-only helper (dumpcap) runs with elevated rights instead. This is a security best practice and a forensics integrity practice.

Your first capture in 30 seconds

Launch Wireshark → the Welcome screen lists interfaces, each with a live sparkline showing traffic. Pick the busy one (usually Wi-Fi or Ethernet/eth0).
Double-click it → capture starts, packets stream in.
Type http in the display filter bar, press Enter → only HTTP shows.
Click the red ⏹ Stop button.
File → Save As → choose pcapng (the modern default) or pcap (max compatibility).

⚠️ Exam trap — pcap vs pcapng 🎯 Domain 1: pcapng (next-gen) supports multiple interfaces in one file, per-packet comments, capture metadata, and nanosecond timestamps. pcap (legacy libpcap) is simpler and more portable to old tools but lacks comments/metadata. Wireshark defaults to pcapng. If a tool "loses your comments," you saved as pcap.

4. The Wireshark Interface

🎯 Domain 4.0: "Identify key components of the GUI." Know every pane by name.

┌───────────────────────────────────────────────────────────────────────┐
│  Menu bar   |   Main toolbar (start/stop/restart, navigation)          │
├───────────────────────────────────────────────────────────────────────┤
│  [ Display filter bar ]  ← type filters here; green=valid, red=invalid │
├───────────────────────────────────────────────────────────────────────┤
│ ┃ PACKET LIST PANE (top)                                             ┃ │  ← minimap
│ ┃  No. | Time | Source | Destination | Protocol | Length | Info      ┃ │     (colored
│ ┃  1     0.000  10.0.0.5   10.0.0.1     TCP        74   [SYN] ...      ┃ │     sidebar)
├───────────────────────────────────────────────────────────────────────┤
│  PACKET DETAILS PANE (middle) — expandable protocol tree               │
│   ▸ Frame 1: 74 bytes on wire                                          │
│   ▸ Ethernet II, Src: ..., Dst: ...                                    │
│   ▸ Internet Protocol Version 4, Src: ..., Dst: ...                    │
│   ▸ Transmission Control Protocol, Src Port: ..., Dst Port: ...        │
├───────────────────────────────────────────────────────────────────────┤
│  PACKET BYTES PANE (bottom) — raw hex + ASCII                          │
│   0000  00 1a 2b 3c 4d 5e ...   ..+<M^....                             │
├───────────────────────────────────────────────────────────────────────┤
│  Status bar: expert severity dot | profile | packet counts            │
└───────────────────────────────────────────────────────────────────────┘

The three panes you live in

Pane	What it is	Analyst use
Packet List (top)	One row per packet. Columns are customizable.	90% of triage happens here — scan Info + colors.
Packet Details (middle)	The decoded protocol tree for the selected packet.	Click any field → its bytes highlight below and its filter name shows in the status bar.
Packet Bytes (bottom)	Raw hex + ASCII.	Confirm ground truth; spot cleartext creds, hidden strings, exfil.

💡 The link between panes is a superpower. Click a field in the Details pane → the exact bytes highlight in the Bytes pane, and the bottom-left status bar shows the display filter field name (e.g. tcp.flags.syn). This is how you learn filter syntax without memorizing it — click the field you care about, read its name, right-click → Apply as Filter.

⚠️ Exam trap — brackets [ ] 🎯 Domain 1: "Distinguish actual bytes captured from fields generated by dissectors." Anything Wireshark shows in square brackets — like [SYN, ACK], [Stream index: 0], [iRTT], [Bytes in flight], [Calculated window size] — is generated by Wireshark, not real bytes on the wire. You will get a question about this. Fields not in brackets came from the packet itself.

Part II — Capturing Like a Pro `🎯 Domain 2 (10%)`

5. Capture Methods

🎯 "Compare and contrast the benefits of different methods for traffic capture." This is a guaranteed exam question. Learn the trade-offs.

Method	How	Sees	Pros	Cons / Gotchas
Direct on endpoint	Run Wireshark on the host itself	Only that host's own traffic	Zero extra hardware; easy	Only one host; capture process can alter/observe its own traffic; misses dropped-before-stack frames
Port Mirror (SPAN)	Switch copies traffic from port(s)/VLAN to a monitor port	Everything on mirrored ports/VLAN	No inline device; flexible	Switch drops mirrored frames under load (oversubscription); may drop errored frames, strip VLAN tags, and doesn't guarantee timing accuracy
Network TAP	Passive hardware inserted inline on a link	100% of link traffic, both directions	Most reliable & complete; passive (fails safely); preserves errors & timing	Costs money; must be placed inline (brief link cut to install); full-duplex TAP presents 2 streams to merge
Infrastructure device	Capture on router/firewall itself (e.g. `debug`, embedded capture)	Traffic transiting that device	No extra gear; good vantage point	Can burden the device; limited buffer; often post-routing (MACs rewritten)
Multi-point capture	Capture at several locations simultaneously	Same flow from multiple vantage points	Locate where loss/latency is introduced; compare in vs out	Must time-sync captures (NTP/PTP); more data to correlate

💡 TAP vs SPAN — the exam's favorite comparison: A TAP is passive hardware that copies every bit including errors and never drops under load; a SPAN/mirror is a switch software feature that is convenient but can drop packets, drop errors, and reorder when the switch is busy. For forensics/evidence, prefer a TAP — completeness and integrity matter.

🔍 Analyst placement strategy: Where you capture determines what you can prove.

Suspected exfiltration? Capture at the internet egress (outside the firewall / on the TAP feeding your NDR).

Lateral movement? Capture east-west at distribution/core or on the segment of interest — north-south egress won't show it.

Endpoint compromise, host-only case? Direct capture on the host (but assume malware may hide from a host-based capture; a network vantage is harder to evade).

6. Capture Options, Ring Buffers & Limits

Open with Capture → Options (or the ⚙ gear). Key controls:

Interface & mode

Pick interface(s) — you can select multiple in one capture (pcapng only).
Promiscuous mode checkbox (see §7).
Snap length (snaplen): bytes captured per packet. Default = full packet. Set it small (e.g. 96) to capture headers only on high-volume links to save disk — but you'll lose payload (bad for forensics/object extraction).
Buffer size: kernel capture buffer; raise it on busy links to avoid drops.

Output / autostop / ring buffer

🎯 "Limit capture by file size, packets, or duration" and "Implement a Ring Buffer."

Long, unattended captures (a common SOC/forensics need — "capture until the intermittent problem recurs") use ring buffers so you never fill the disk:

Capture → Options → Output tab:
  ┌ Output format: pcapng
  ├ File: /captures/case42.pcapng
  ├ [✓] Create a new file automatically after:
  │       [ 100 ] megabytes        ← or after N seconds / packets
  └ [✓] Use a ring buffer with [ 20 ] files

Ring buffer with N files: Wireshark writes case42_00001_<timestamp>.pcapng, rolls to _00002, ... and when it reaches file N it overwrites the oldest. You always keep the most recent N files worth of traffic. Perfect for "let it run for days, grab the window around the incident."
Autostop conditions (Options → Stop capture automatically after): stop after X files / packets / seconds / MB. Combine: "stop after 1 hour OR 1 GB."

Control	Where	Use case
Files (ring)	Output tab	Continuous monitoring without filling disk
Autostop: packets	Options	Grab exactly N packets then stop
Autostop: duration	Options	Time-boxed capture (e.g. 60s baseline)
Autostop: filesize	Options	Cap a single file's size

💡 Start / Stop / Restart 🎯: the toolbar has all three. Restart (⟳) stops and immediately starts a fresh capture — handy to clear a noisy buffer right before triggering the behavior you want to record.

🔍 Forensics tip: For an evidence capture, prefer dumpcap (see §8) over the GUI — it's leaner, less likely to drop, and doesn't run the (attackable) dissectors while capturing. Capture broad (no filter), preserve the original file untouched, and analyze a copy.

7. Promiscuous vs Monitor Mode

🎯 "Describe the purpose of using promiscuous or monitor mode during a capture." Know the difference precisely — it's a classic fill-in-the-blank.

Mode	Layer	What it does	Without it
Promiscuous mode	Wired (and Wi-Fi, associated)	NIC keeps all frames it hears, not just those addressed to its own MAC or broadcast/multicast	NIC drops frames not destined to it — you'd only see your own host's traffic
Monitor mode (rfmon)	Wireless only	Radio captures 802.11 frames from all nearby networks without associating to any AP; sees management/control frames, beacons, other SSIDs	You only see traffic of the network you're joined to, already decrypted to look like Ethernet

Key nuances:

Promiscuous mode on a switched network shows little extra — a switch only forwards unicast to the correct port. You still only see broadcast/multicast + your own traffic unless you're on a SPAN port, TAP, or hub. This surprises people: "I enabled promiscuous mode but still only see my traffic" → because the switch is filtering, not your NIC.
Monitor mode is for Wi-Fi analysis (rogue AP hunting, deauth attacks, capturing WPA handshakes). Support is OS/driver dependent — best on Linux/macOS; often unavailable on Windows without special adapters.

🔍 SOC/IR use of monitor mode: detecting deauthentication floods (wlan.fc.type_subtype == 0x0c), rogue/evil-twin APs (unexpected BSSIDs beaconing your SSID), and capturing the 4-way handshake for authorized WPA2 audits.

8. Command-Line Capture

🎯 "Capture traffic using command line tools." You must know what each tool is for.

Tool	Role	Notes
dumpcap	The actual capture engine	Wireshark & tshark call it under the hood. Leanest, least likely to drop. Use it for evidence-grade captures.
tshark	Terminal Wireshark	Full dissection, display filters, statistics — no GUI. For scripting, remote boxes, huge files.
tcpdump	Classic *nix sniffer	Ubiquitous on servers; uses BPF (capture-filter) syntax; output is pcap you open in Wireshark.
editcap / mergecap / capinfos	pcap surgery	split/slice, merge, and summarize capture files.

Recipes you should know

# Capture 60s on eth0 to a ring buffer of 10x100MB files (unattended, disk-safe)
dumpcap -i eth0 -b filesize:100000 -b files:10 -w /captures/case.pcapng

# tcpdump on a remote server: only host 10.0.0.9, don't resolve names, full packets
tcpdump -i any host 10.0.0.9 -nn -s0 -w /tmp/host9.pcap

# tshark: read a file, apply a DISPLAY filter, print custom columns
tshark -r case.pcapng -Y "http.request" -T fields -e ip.src -e http.host -e http.request.uri

# tshark: live capture with a CAPTURE filter (BPF), stop after 1000 packets
tshark -i eth0 -f "tcp port 443" -c 1000 -w tls.pcapng

# capinfos: quick stats about a capture (great first step on unknown evidence)
capinfos case.pcapng

# editcap: slice out a time window from a huge evidence file (UTC)
editcap -A "2026-07-13 14:00:00" -B "2026-07-13 14:05:00" big.pcapng window.pcapng

# mergecap: combine multi-point captures into one time-ordered file
mergecap -w combined.pcapng site-a.pcapng site-b.pcapng

⚠️ -f vs -Y in tshark — -f is a capture filter (BPF, applied before capture, like tcpdump). -Y is a display filter (Wireshark syntax, applied after dissection). Mixing them up is a classic mistake.

🔍 Forensics workflow with the CLI: capinfos first (hashes, packet count, time range, interfaces) → editcap to carve the relevant window → analyze the copy in Wireshark → keep the original + its SHA256 untouched for chain of custody (§35).

Part III — Filtering `🎯 Domain 3 (12%)`

Filtering is the skill that separates people who use Wireshark from people who drown in it. There are two completely different filter languages — mixing them up is the #1 beginner error.

Capture filters vs Display filters — the fundamental split

🎯 "Compare and contrast Display Filters and Capture Filters." Guaranteed question.

	Capture Filter	Display Filter
When applied	Before capture — decides what's written to disk	After capture — decides what's shown
Syntax	BPF (Berkeley Packet Filter), same as tcpdump	Wireshark's own richer language
Reversible?	❌ No — filtered-out packets are gone forever	✅ Yes — just clear the filter, all packets return
Example	`host 10.0.0.5 and tcp port 443`	`ip.addr == 10.0.0.5 && tcp.port == 443`
Where	Capture → Options (or bar on Welcome screen)	The main filter bar (green when valid)
Use it to	Reduce volume on busy links; protect disk/privacy	Zoom in on already-captured data

⚠️ The golden rule: For forensics/IR, capture broadly, filter on display. A capture filter that's too tight throws away evidence you can never recover. Only use capture filters when volume genuinely forces it (e.g. multi-gig links, long unattended runs).

9. Capture Filters (BPF)

BPF is primitive-based: [protocol] [direction] [type] value, combined with and / or / not.

host 192.168.1.10            # traffic to OR from that IP
src host 192.168.1.10        # only from
dst host 192.168.1.10        # only to
net 10.0.0.0/8               # a whole subnet
port 53                      # TCP or UDP port 53
tcp port 443                 # TCP 443 only
udp port 53                  # DNS over UDP
portrange 1000-2000          # a range
ether host 00:1a:2b:3c:4d:5e # a MAC address
vlan 100                     # VLAN-tagged traffic, VLAN 100
tcp[13] & 2 != 0             # SYN bit set (byte 13 = flags, 0x02 = SYN)
not arp and not stp          # exclude noise
host 10.0.0.5 and tcp port 443   # combine with 'and'

💡 BPF has no ==. It's host X, port Y, not ip.addr == X. If you type ip.addr == into the capture filter box, it's invalid. That word-based feel is how you remember you're in BPF land.

🔍 Useful evidence capture filters:

Everything to/from a suspect host: host 10.10.10.66

Exclude your own management noise: not host <your-jumpbox> and not port 22

Only a subnet under investigation: net 172.16.5.0/24

10. Display Filters — Complete Reference

This is Wireshark's rich language. Format: protocol.field operator value.

The essential fields (know these cold for the exam)

# ---- Addressing ----
ip.addr == 10.0.0.5              # src OR dst is this IP  (see !  trap below)
ip.src == 10.0.0.5               # source only
ip.dst == 8.8.8.8                # destination only
eth.addr == 00:11:22:33:44:55    # MAC src or dst
ipv6.addr == 2001:db8::1

# ---- Ports & transport ----
tcp.port == 443                  # src or dst TCP 443
udp.port == 53
tcp.srcport == 49152
tcp.dstport == 80

# ---- Protocol name = "this layer is present" ----
tcp        udp        icmp       arp
dns        http       tls        dhcp       ftp        smb2

# ---- TCP analysis (the money filters — see §28) ----
tcp.flags.syn == 1 && tcp.flags.ack == 0     # SYN only (connection attempts)
tcp.analysis.retransmission                  # retransmits
tcp.analysis.duplicate_ack                   # dup ACKs
tcp.analysis.zero_window                     # receiver stalled
tcp.analysis.flags                           # ALL expert TCP issues at once

# ---- Application ----
http.request.method == "POST"
http.response.code == 200
dns.qry.name contains "evil"
tls.handshake.type == 1          # ClientHello

Operators — two syntaxes, same meaning

Meaning	C-style	English	Example
equal	`==`	`eq`	`ip.src == 10.0.0.1`
not equal	`!=`	`ne`	`tcp.port != 80`
greater	`>`	`gt`	`frame.len > 1000`
less	`<`	`lt`	`tcp.window_size < 1000`
≥ / ≤	`>=` `<=`	`ge` `le`	`ip.ttl <= 64`
AND	`&&`	`and`	`ip.src==X && tcp.port==443`
OR	`\|\|`	`or`	`dns \|\| http`
NOT	`!`	`not`	`!arp`

The power operators (these win exam questions and hunts)

contains   # byte-sequence / substring match (case-sensitive)
   http.user_agent contains "curl"
   frame contains "password"          # raw bytes anywhere in frame

matches    # regex (PCRE), case-insensitive with (?i)
   http.host matches "(?i)\\.(ru|cn|top)$"
   dns.qry.name matches "^[a-f0-9]{32}\\."   # hex-label DNS tunneling

in         # membership set  🎯 explicitly on the exam
   tcp.port in {80 443 8080}
   ip.addr in {10.0.0.1 10.0.0.2 10.0.0.3}
   http.response.code in {400..599}    # ranges work too

[n:m]      # slice bytes: offset n, length m
   eth.dst[0:3] == 00:1a:2b            # match an OUI (vendor)
   frame[100:4] == aa:bb:cc:dd

🎯 Membership filters (tcp.port in {80,443}) are called out by name in Domain 3. They're cleaner than tcp.port==80 || tcp.port==443 and you will see one.

Building filters without typing — the three GUI methods `🎯`

🎯 "Use multiple methods to create a display filter (manual entry, right click, drag/drop)."

Manual entry — type in the bar (autocomplete helps).
Right-click a field in Packet Details → Apply as Filter → Selected (or Prepare as Filter to edit before applying). Sub-options: ...and Selected, ...or Selected, ...and not Selected build compound filters click-by-click.
Drag & drop — drag a field from the Details pane straight into the filter bar to append it.

💡 Apply as Filter builds the filter and runs it; Prepare as Filter puts it in the bar so you can tweak it first. Also: right-click → Apply as Column turns any field into a permanent Packet List column (huge for triage — see §13).

11. Operators, Membership, and the `!` Trap

🎯 Domain 3 explicitly: "Identify the behavior of using ! (not) in different parts of filter logic by explaining the implicit 'any' and 'all' qualifiers." This is one of the most misunderstood topics in all of Wireshark and a favorite exam question. Read this twice.

The problem: `ip.addr` matches either field

ip.addr is true if src OR dst matches. Fields like this have an implicit "any" qualifier: "match if any address field equals X."

Now negate it. People write this to mean "exclude host 10.0.0.5":

ip.addr != 10.0.0.5      # ⚠️ DOES NOT do what you think

Because ip.addr != 10.0.0.5 expands to "is there any address field that is not 10.0.0.5?" In a packet 10.0.0.5 → 8.8.8.8, the dst (8.8.8.8) is "not 10.0.0.5", so the any test is true — the packet is shown. You fail to exclude the host you wanted gone.

The fix: negate the whole expression

!(ip.addr == 10.0.0.5)     # ✅ correct: "not (any field is 10.0.0.5)"

This reads as "show packets where it is not the case that any address is 10.0.0.5" → truly excludes every packet touching 10.0.0.5.

The rule to memorize

You want	❌ Wrong (implicit any)	✅ Right
Exclude all traffic with host X	`ip.addr != X`	`!(ip.addr == X)`
Exclude a port entirely	`tcp.port != 80`	`!(tcp.port == 80)`

💡 Mental model: field != value means "at least one instance of this field ≠ value" (any). !(field == value) means "no instance of this field == value" (all/none). When negating multi-instance fields (addresses, ports, which appear twice per packet), always wrap the equality in !( ).

🔍 Why analysts get burned by this: you're triaging an incident, you try to filter out a known-good host with ip.addr != 10.0.0.5, the noise doesn't go away, and you waste ten minutes. Now you know: !(ip.addr == 10.0.0.5).

Combining excludes cleanly (common IR pattern)

# Hide known-good chatter to reveal the anomalies
!(ip.addr == 10.0.0.1) && !(arp || dns || stp || nbns)

12. Filter Buttons, Macros & Traps

Filter buttons `🎯 "Create a button for easy access to a display filter"`

Type a filter, then click the + at the right end of the filter bar → name it → it becomes a one-click button under the filter bar. Buttons are per-profile, so your "SOC" profile can carry a whole toolbar of hunt filters.

Great buttons to pre-build for SOC/IR:

Retransmits   →  tcp.analysis.retransmission
Resets        →  tcp.flags.reset == 1
SYN-no-SYNACK →  tcp.flags.syn==1 && tcp.flags.ack==0
BigDNS        →  dns && frame.len > 300
HTTP-POST     →  http.request.method == "POST"
Cleartext-pw  →  frame contains "password" || frame contains "passwd"

💡 You can group buttons with // in the name (e.g. TCP//Retransmits) to make dropdown menus once you have many.

The "incomplete or excess results" trap `🎯`

🎯 "Identify situations where a display filter will show incomplete or excess results (e.g. filter for HTTP but don't see the TCP handshake)."

Display filters match per-packet on the layers present in that packet. Consequences:

Filter http → you lose the TCP handshake. The SYN/SYN-ACK/ACK and the pure-ACKs carry no HTTP layer, so they're hidden. You see requests/responses but not the connection setup or the ACKs. To see the whole conversation, right-click a packet → Follow → TCP Stream (auto-builds tcp.stream == N) or filter by the stream/port instead of the app protocol.
Reassembled data appears "in the wrong packet." With TCP reassembly on, a big HTTP response is shown against the last TCP segment that completed it; filtering http shows that one packet, not all the segments that carried the bytes.
Excess results from ip.addr/tcp.port — the "any" behavior means a filter can catch more than you intended (see §11).

💡 The fix nearly every time: when a display filter shows a confusing subset, switch to the conversation view: tcp.stream == N (from Follow Stream) shows every packet of that flow — handshake, data, ACKs, teardown — regardless of which app layer is present.

Part IV — Interface Mastery `🎯 Domain 4 (5%)`

13. Columns, Coloring Rules & Minimap

Columns — "the importance of columns in troubleshooting" `🎯`

The default columns waste screen space. Custom columns put the exact evidence you need one glance away.

Two ways to add a column 🎯 "use multiple methods to add a column":

Right-click a field in Packet Details → Apply as Column.
Preferences → Appearance → Columns → +, set Type = Custom, and enter a field expression.

High-value columns to add (per-profile):

Column field	Shows	Why
`tcp.stream`	Stream index	Instantly group packets by conversation
`tcp.analysis.ack_rtt`	ACK round-trip time	Spot latency at a glance
`ip.ttl`	TTL	Topology/hop distance; spoofing hints
`tcp.window_size`	Calculated window	Spot zero-window / flow-control stalls
`dns.qry.name`	Queried domain	DNS triage without opening packets
`http.host` + `http.request.uri`	Web target	See where hosts are browsing/beaconing
`frame.time_delta_displayed`	Δ from previous displayed packet	Measure gaps between filtered packets (beacon intervals!)

💡 Right-align numeric columns and drag to reorder. Column layouts are saved per profile — build a "TCP-Troubleshooting" profile with latency/window columns and a "SOC-Hunt" profile with DNS/HTTP/host columns.

Coloring rules — "highlight packets" `🎯`

View → Coloring Rules. Rules are display-filter expressions evaluated top-to-bottom; first match wins, and it colors the row in the Packet List. Wireshark ships with sensible defaults (black on red = TCP problems/resets, etc.).

Build custom rules for hunting:

# Name                Filter                                   Color
C2-suspect-ports   →  tcp.port in {4444 1337 8443 9001}        red bg
Long-DNS           →  dns && frame.len > 300                   orange bg
Cleartext-creds    →  frame contains "password"                magenta bg
Outbound-to-rare   →  ip.dst != 10.0.0.0/8 && tcp.flags.syn==1 yellow bg

⚠️ Exam note: coloring rule = a display filter that colors rather than hides. Order matters (first match wins). You can temporarily disable/reorder rules. Colorize Conversation (right-click → Colorize Conversation) is a separate, quick, temporary way to tint all packets of one flow without writing a rule. 🎯 Domain 4 lists both.

Minimap (colored sidebar) `🎯`

The thin vertical strip to the right of the Packet List is the minimap (a.k.a. intelligent scrollbar). It renders the coloring of the whole capture in miniature, so a band of red = a cluster of TCP problems you can click straight to. Combined with good coloring rules, it lets you see where trouble is in a 500k-packet file without scrolling. 🎯 "Use the minimap to quickly locate packets of interest."

14. Profiles

🎯 "Describe the value of profiles. Create/modify/copy a profile." Underrated, absolutely on the exam.

A profile is a saved bundle of your entire working environment: columns, coloring rules, filter buttons, layout, capture filters, preferences, and "recent" display filters. Switch profiles to instantly reconfigure Wireshark for a task.

Switch/create: bottom-right of the status bar shows the current profile (e.g. Default). Right-click it → New / Copy / Manage Profiles. Copying an existing profile is the fast way to start.
Why it matters: you keep separate mental toolkits — e.g. Default, TCP-Perf, SOC-Hunt, VoIP, DFIR-Casework — each with its own columns, colors, and buttons, and you don't clutter one setup with another's noise.

🔍 A ready-made "DFIR" profile = stream-index & host columns + C2/cleartext coloring rules + a filter-button toolbar of hunt queries + name resolution off (§17). Set it up once, reuse on every case. Profiles live in the Wireshark config folder (Help → About → Folders → Personal configuration) and can be copied to a USB stick / git repo and dropped onto any analyst's machine.

15. Protocol Preferences & "Decode As"

Protocol preferences `🎯 "understand the importance of protocol preferences"`

Edit → Preferences → Protocols (or right-click a protocol in Details → Protocol Preferences). These change how Wireshark dissects, which changes what you see. The ones that bite analysts:

Preference	Effect	When to change
TCP → Relative sequence numbers	Show seq/ack starting at 0 (readable) vs raw	Keep on for reading; turn off to match absolute values in another tool
TCP → Allow subdissector to reassemble TCP streams	Reassemble app data across segments	Turn off to see raw per-segment data; on for clean HTTP/TLS
TCP → Calculate conversation timestamps	Enables `tcp.time_delta` / `tcp.time_relative`	Turn on for beacon-interval & per-flow timing analysis
IPv4 → Validate checksum	Flags bad IP checksums	Off by default because checksum offload makes locally-captured outbound packets show bad checksums that aren't real (see below)

⚠️ Checksum-offload trap: On the sending host, the NIC computes TCP/IP checksums after Wireshark captures the packet (hardware offload). So your outbound packets show "checksum incorrect" even though the wire is fine. Don't chase this ghost — it's why checksum validation is off by default. A real bad checksum on inbound traffic is a different story.

"Decode As" `🎯`

Right-click a packet → Decode As... tells Wireshark to dissect traffic on a nonstandard port with a chosen dissector. Example: an app runs HTTP on TCP 8081; Wireshark shows it as generic "TCP." Decode As → HTTP → now port 8081 is fully dissected as HTTP for this session.

🔍 Huge for malware analysis: C2 loves oddball ports (HTTP on 8443, TLS on 4444). Decode As forces the right dissector so you can actually read the beacon. You can also use it to decode custom protocols or push a dissector onto a port the malware picked to evade naive tooling.

Part V — Key Features `🎯 Domain 1 (10%)`

16. Find, Marks, Comments & Time

Find Packet `🎯`

Ctrl+F opens the Find bar. Search by Display filter, Hex value, String, or Regex, and choose the pane to search (Packet list / details / bytes). String search across bytes is how you locate a filename, username, or IOC string anywhere in a capture.

Find → String → "confidential" → search Packet bytes  → jumps to any packet containing it
Find → Display filter → tcp.flags.reset==1            → next RST

Mark / Unmark & Ignore `🎯`

Mark (Ctrl+M): flags packets of interest (they turn black). Marks let you export only marked packets to a new evidence file (see below) and jump between them (Ctrl+Shift+N / ↑).
Ignore (Ctrl+D): hides a packet from analysis without deleting it.

Packet & file comments `🎯`

Packet comment: right-click a packet → Packet Comment (or Edit menu). Adds an analyst note stored in the pcapng. Invaluable for casework: annotate "← first beacon" or "← exfil starts here."
Capture file comment: Statistics → Capture File Properties has a comments box for case-level notes (analyst, case #, source).
⚠️ Comments require pcapng — save as pcap and they vanish.

Time reference & time formats `🎯 "Set/Unset time reference; apply different time formats"`

Set Time Reference (Ctrl+T): marks a packet as t=0; all following packets' times are shown relative to it (that packet shows *REF*). Perfect for measuring "how long after the SYN did X happen."
Time display formats — View → Time Display Format:
- Seconds Since Beginning of Capture (default relative)
- Seconds Since Previous Displayed Packet — the delta view; gaps jump out (great for spotting beacon intervals and stalls)
- UTC Date and Time of Day — use this for forensics/reporting so timestamps are unambiguous across time zones
- Seconds Since Epoch — for correlating with logs

💡 Δ time is a hunt tool. Filter to a suspected C2 conversation, set time format to Seconds Since Previous Displayed Packet (or add column frame.time_delta_displayed), and if you see a metronome — e.g. a packet every ~60.00s ± jitter — that regularity screams automated beaconing, not human browsing (§33).

17. Name Resolution & File Properties

Name resolution `🎯 "describe how Wireshark applies name resolution; configure it"`

View → Name Resolution (and Preferences → Name Resolution) toggles three layers:

Layer	Turns...	Source	Caution
MAC (`Resolve physical addresses`)	`00:1a:2b:...` → `Cisco_3c:4d:5e`	Built-in OUI/manuf database	Only shows vendor, not device
Transport (`Resolve transport names`)	`443` → `https`	`services` file	Port name is a guess by number
Network (`Resolve network addresses`)	`8.8.8.8` → `dns.google`	DNS lookups	⚠️ Generates traffic!

⚠️ Forensics/OPSEC warning: enabling network name resolution makes Wireshark send DNS queries for every IP in the capture — from your analysis box. On a live incident this can tip off an attacker (reverse lookups of their infrastructure) and pollute your own capture if you're analyzing live. For DFIR, keep network resolution OFF; rely on the capture's own DNS packets to map names to IPs. Wireshark can also read a hosts file for offline resolution.

Capture File Properties `🎯`

Statistics → Capture File Properties (or click the leftmost status-bar icon) — your first stop on any unknown capture. It shows:

File name, length, format (pcap/pcapng), hashes (SHA256/SHA1/MD5) ← evidence integrity!
First/last packet time & capture duration
Number of interfaces, their names, link type, snaplen, capture filter used
Packet count, avg pps, avg packet size, data byte totals
The capture/file comments

🔍 The SHA256 here is your chain-of-custody anchor. Record it before analysis; anyone can re-verify the evidence file is unaltered.

18. Statistics Tools

The Statistics menu is where triage gets fast. Master these five.

Protocol Hierarchy `🎯`

Statistics → Protocol Hierarchy — a tree of every protocol in the capture with % of packets and bytes. Your 10-second "what is even in this file?" view.

🔍 Hunt use: unexpected protocols jump out — why is there IRC, TFTP, or a big slice of unknown TCP on a corporate LAN? A large "Data" or non-standard-port TCP percentage often = tunneled/covert traffic. Right-click any row → Apply as Filter to drill in.

Conversations `🎯`

Statistics → Conversations — every pair that talked, tabbed by layer (Ethernet / IPv4 / IPv6 / TCP / UDP), with packets, bytes, duration, and bytes A→B vs B→A. Sort by bytes to find the top talkers instantly.

🔍 The exfiltration finder: sort the TCP/IPv4 tab by Bytes B→A (or the direction leaving your network). A workstation that sent hundreds of MB outbound to one external IP is your exfil candidate. Right-click the row → Apply as Filter → Selected → A↔B to isolate it. Columns also show Duration — a long-lived, low-volume conversation can be a C2 channel.

Endpoints `🎯`

Statistics → Endpoints — per-host totals (not pairs). The IPv4 tab can add GeoIP country/city/ASN columns if you've loaded MaxMind databases (Preferences → Name Resolution → GeoIP). Sort by packets/bytes to rank hosts; map view shows geographic spread.

🔍 GeoIP turns Endpoints into a quick "are we talking to countries we have no business talking to?" check — a fast IR signal.

I/O Graph `🎯 "create and interpret an I/O graph (packets/s or bits/s) for a display filter"`

Statistics → I/O Graph — throughput over time. Add multiple lines, each driven by a display filter, and choose the Y-axis unit (packets/s, bytes/s, bits/s, or an aggregate like MAX/AVG of a field).

Line 1: all traffic            (bits/s)   → overall load
Line 2: tcp.analysis.retransmission (pkts/s) → do retransmits spike with load?
Line 3: tcp.flags.syn==1       (pkts/s)   → SYN flood / scan bursts
Line 4: dns                    (pkts/s)   → DNS volume anomalies

🔍 Reading it: overlaying "throughput" with "retransmissions" shows if loss rises under load (congestion). A flat, evenly-spaced sawtooth of small outbound packets = beaconing. A wall of SYNs = scan or SYN flood. You can click a point on the graph to jump to that packet.

Others worth knowing

Statistics → DNS, HTTP, Statistics → Flow Graph (sequence diagram of a conversation — beautiful for explaining a handshake/teardown), Statistics → TCP Stream Graphs (see §28), Statistics → Service Response Time (per-protocol latency).

19. Following Streams & Exporting Objects

Follow Stream `🎯 "Use Follow TCP/UDP stream"`

Right-click a packet → Follow → TCP Stream (also HTTP, TLS, UDP, HTTP/2, QUIC). Wireshark:

Reassembles the whole conversation's payload into a readable window (client text in one color, server in another).
Auto-applies the filter tcp.stream == N so the Packet List now shows only that flow.

Use it to read an entire HTTP exchange, an FTP session, an SMTP email, or a cleartext protocol end-to-end. The dropdown lets you show ASCII, Hex Dump, C arrays, Raw, or one direction only.

🔍 DFIR gold: Follow TCP Stream on a suspicious flow reveals cleartext credentials (FTP/Telnet/HTTP Basic), HTTP beacon bodies, exfiltrated data, and C2 commands in one pane. "Show data as Raw" + Save lets you carve the exact bytes out for a malware sandbox.

Export Objects `🎯 "Export objects from packet captures"`

File → Export Objects → HTTP / SMB / TFTP / FTP-DATA / IMF (email)... lists every file/object Wireshark reconstructed from the capture (URL, hostname, content type, size). Select one → Save, or Save All to dump every transferred file.

🔍 This is core network forensics. From a pcap you can recover the actual downloaded malware binary, exfiltrated documents, or served web pages, then hash them and detonate them in a sandbox. Export Objects → HTTP on a drive-by capture literally hands you the payload. (For HTTPS you first need the TLS keys — see §29.)

Export specified packets `🎯`

File → Export Specified Packets (or Export PDU) lets you save a subset — Displayed (current filter), Marked, Range, or Selected — to a new file. This is how you carve a clean, minimal evidence file for a report or to hand to another analyst without shipping the whole multi-GB capture.

Part VI — Protocol Deep Dives `🎯 Domain 5 (43%)`

This is the single largest domain. Learn the header fields, the normal behavior, and — for each — the filters and what abuse looks like. Fields you must be able to name on sight are in bold.

20. Ethernet `🎯 5.1`

The Layer-2 frame that carries everything on a LAN.

┌───────────────┬───────────────┬───────────┬──────────────────┬─────────┐
│ Dest MAC (6B) │ Src MAC (6B)   │ EtherType │  Payload (46–1500)│  FCS 4B │
└───────────────┴───────────────┴───────────┴──────────────────┴─────────┘

Fields to know cold

Field	Size	Notes
Destination MAC	6 bytes	Who the frame is for on this LAN segment
Source MAC	6 bytes	Who sent it (last hop)
EtherType	2 bytes	What's inside: 0x0800 = IPv4, 0x86DD = IPv6, 0x0806 = ARP, 0x8100 = 802.1Q VLAN
FCS (CRC)	4 bytes	Frame check sequence — usually NOT shown in Wireshark (see below)

Exam-favorite facts

Minimum frame = 64 bytes (so runts/collisions are detectable); if payload < 46 bytes it's padded. Maximum standard frame = 1518 bytes (1500 MTU payload + 14 header + 4 FCS). Jumbo frames exceed this. 🎯 "Describe minimum and maximum frame sizes."
Why the CRC/FCS is missing 🎯: the NIC validates and strips the FCS before handing the frame to the OS/Wireshark. So Wireshark normally never sees it. Frames with a bad FCS are usually dropped by the NIC entirely (unless the adapter is set to pass errors). This is a guaranteed question.
MAC address types 🎯 "distinguish Unicast, Broadcast, Multicast":
- Broadcast = ff:ff:ff:ff:ff:ff (all ones) → everyone on the segment.
- Multicast = the least-significant bit of the first octet = 1 (e.g. 01:00:5e:... for IPv4 multicast, 33:33:... for IPv6). Filter: eth.dst[0] & 1.
- Unicast = that bit = 0 → one specific NIC.
- The 2nd-least-significant bit of the first octet = the U/L bit; if 1 the MAC is locally administered (e.g. randomized/spoofed) rather than a real burned-in vendor address.
VLAN tags (802.1Q) 🎯 "how the frame header is modified for VLAN tags": a 4-byte tag is inserted after Src MAC, EtherType becomes 0x8100, the tag carries the VLAN ID (12 bits, 0–4095) and priority (PCP), and the original EtherType follows. Filter: vlan / vlan.id == 100.

Filters

eth.addr == 00:1a:2b:3c:4d:5e     # this MAC as src or dst
eth.dst == ff:ff:ff:ff:ff:ff      # broadcasts
eth.dst[0] & 1                    # multicast/broadcast (group bit set)
eth.type == 0x0806                # ARP frames
vlan.id == 20                     # VLAN 20
eth.src[0:3] == 00:1a:2b          # match a vendor OUI

21. ARP `🎯 5.2`

Address Resolution Protocol maps a known IPv4 address → unknown MAC on the local segment. Pure Layer 2/3 glue; no ARP crosses a router.

How it works

Host needs to send to 10.0.0.9 on its subnet but doesn't know its MAC.
ARP Request — a broadcast (dst = ff:ff:ff:ff:ff:ff): "Who has 10.0.0.9? Tell 10.0.0.5."
ARP Reply — a unicast back to the asker: "10.0.0.9 is at aa:bb:cc:dd:ee:ff." 🎯 "difference between broadcast ARP and unicast ARP" → request is broadcast, reply is unicast.

Types you must recognize `🎯`

Type	Filter	Purpose
Request (op=1)	`arp.opcode == 1`	Ask for a MAC
Reply (op=2)	`arp.opcode == 2`	Answer with a MAC
Gratuitous ARP	`arp.isgratuitous == 1` (or `arp.src.proto_ipv4 == arp.dst.proto_ipv4`)	Host announces/updates its own mapping (IP failover, duplicate-IP detection, boot)
ARP probe	`arp.dst.proto_ipv4 == 0.0.0.0`-style sender	Check if an IP is already in use before claiming it

Filters

arp                               # all ARP
arp.opcode == 1                   # requests
arp.opcode == 2                   # replies
arp.src.hw_mac == 00:11:22:33:44:55
arp.dst.proto_ipv4 == 10.0.0.9    # who's asking for this IP
arp.duplicate-address-detected    # Wireshark expert: possible ARP spoofing!

🔍 ARP is a top LAN-attack signal. arp.duplicate-address-detected and a flood of gratuitous ARPs claiming the gateway's IP with a new MAC = ARP spoofing / MITM (someone poisoning caches to intercept traffic). A burst of ARP requests sweeping every host in a subnet = reconnaissance/scanning. 🎯 Domain 6: "identify communication issues using ARP" — also, if a host ARPs for an IP and gets no reply, that host is down or off-subnet — a fast way to spot dead gateways.

22. IPv4 `🎯 5.3`

The Layer-3 packet that gets data across networks.

 0        4        8            16                             31
┌────┬────┬────────┬────────────┬──────────────────────────────┐
│Ver │IHL │  DSCP  │Total Length│  Identification  │Flags│FragOff│
├────┴────┴────────┴────────────┼──────────────────────────────┤
│  TTL   │  Protocol │ Header Checksum │     Source IP Address   │
├──────────────────────────────┼──────────────────────────────┤
│      Destination IP Address   │        Options (if IHL>5)     │
└──────────────────────────────┴──────────────────────────────┘

Header fields you must know `🎯`

Field	Filter	Meaning / exam point
Version	`ip.version`	4
Total Length	`ip.len`	Whole packet (header+data) in bytes
Identification (IP ID)	`ip.id`	Unique-ish per packet; ties fragments together; strategies vary by OS (incrementing, random) — useful to fingerprint a sender or spot a spoofer/NAT `🎯 "IP identification strategies"`
Flags	`ip.flags`	DF (Don't Fragment), MF (More Fragments)
Fragment Offset	`ip.frag_offset`	Where this fragment sits in the original `🎯`
TTL	`ip.ttl`	Decremented each router; hits 0 → router drops & sends ICMP Time Exceeded
Protocol	`ip.proto`	1 = ICMP, 6 = TCP, 17 = UDP (memorize)
Header Checksum	`ip.checksum`	Covers header only
Src / Dst IP	`ip.src` / `ip.dst`	End-to-end identity

Address ranges to memorize `🎯 "public, private, multicast, APIPA ranges"`

Range	Type	Notes
`10.0.0.0/8`, `172.16.0.0/12`, `192.168.0.0/16`	Private (RFC1918)	Not routable on the internet → NAT'd
`169.254.0.0/16`	APIPA / link-local	Auto-assigned when DHCP fails — a red flag!
`224.0.0.0/4` (224–239)	Multicast	One-to-many
`127.0.0.0/8`	Loopback	localhost
everything else	Public	Internet-routable

💡 APIPA (169.254.x.x) in a capture = the host couldn't reach a DHCP server. That's a direct troubleshooting clue (§26, Domain 6).

TTL → hop distance `🎯 "predict distance in hops"`

Common initial TTLs: Windows = 128, Linux/macOS = 64, routers/Cisco = 255. Observed TTL subtracted from the nearest higher default = hops traversed. Arriving TTL 117 from a Windows host → 128 − 117 = 11 hops away.

NAT `🎯 "how NAT works and why it matters for capture/analysis"`

NAT rewrites private source IP:port → the router's public IP:port on the way out (and reverses inbound). Implications for you:

Capture location changes what you see: inside the NAT you see real private IPs; outside, every internal host looks like one public IP — you lose per-host visibility. Capture inside to attribute traffic to a specific workstation.
Many hosts behind one IP complicates attribution in IR — correlate with NAT/firewall logs.

Fragmentation `🎯`

If a packet exceeds the path MTU and DF isn't set, routers split it: same IP ID, MF=1 on all but the last, increasing Fragment Offset. Wireshark reassembles and shows [Reassembled in frame N]. Filter fragments: ip.flags.mf == 1 || ip.frag_offset > 0.

🔍 Unusual heavy fragmentation, tiny fragments, or overlapping offsets can be IDS/firewall evasion or a crafted-packet attack.

Filters

ip.addr == 8.8.8.8
ip.src == 10.0.0.0/8 && ip.dst != 10.0.0.0/8    # internal → external (egress)
ip.ttl < 64                                     # already traversed routers
ip.flags.df == 1                                # Don't Fragment set
ip.addr == 169.254.0.0/16                       # APIPA — DHCP failure
ip.proto == 6                                   # TCP

23. ICMPv4 `🎯 5.4`

ICMP is IP's diagnostic/error courier (ip.proto == 1). No ports.

Message types to know `🎯 "identify ICMP message types and their purpose"`

Type/Code	Name	Meaning
8 / 0	Echo Request / Reply	`ping` — reachability & RTT
3	Destination Unreachable	code 0 net, 1 host, 3 port unreachable, 4 frag needed+DF (PMTU black hole!), 13 admin filtered (firewall)
5	Redirect	Router says "use a better gateway"
11	Time Exceeded	TTL hit 0 (this powers traceroute)
4	Source Quench	(deprecated) congestion

The killer exam skill `🎯 "identify the IP packet which triggered an ICMP error"`

An ICMP error message (types 3, 5, 11) embeds the IP header + first 8 bytes of the original offending packet in its payload. Expand the ICMP packet in Wireshark and you'll see the original IP/TCP/UDP header nested inside — that tells you which flow caused the error (e.g. which UDP packet got "port unreachable"). This is frequently tested.

Filters

icmp                                   # all ICMP
icmp.type == 8                         # echo requests (pings out)
icmp.type == 0                         # echo replies
icmp.type == 3 && icmp.code == 3       # port unreachable (service down/closed UDP)
icmp.type == 3 && icmp.code == 4       # fragmentation needed (PMTU issues)
icmp.type == 11                        # TTL exceeded (traceroute / routing loop)

🔍 SOC/IR angle: big ICMP Echo packets or a steady ping stream with data payloads can be an ICMP tunnel/covert channel or exfil (normal pings are tiny & uniform — check data.len). A flood of Type 3 Code 3 from one host = a UDP port scan hitting closed ports. Type 11 everywhere = a routing loop. Type 3 Code 4 black-holing = broken Path MTU Discovery (a real "some sites hang" bug).

24. IPv6 & ICMPv6 `🎯 5.5–5.6`

IPv6 address types `🎯 "identify Link Local, Global Unicast, Multicast"`

Type	Prefix	Notes
Link-Local	`fe80::/10`	Auto-configured, never routed off-link; used for neighbor discovery
Global Unicast	`2000::/3` (e.g. `2001:...`)	Internet-routable, like a public IPv4
Unique Local	`fc00::/7` (usually `fd00::/8`)	Private, like RFC1918
Multicast	`ff00::/8`	e.g. `ff02::1` all-nodes, `ff02::2` all-routers
Loopback	`::1`	localhost

IPv6 has no broadcast — it uses multicast instead. No IP-header checksum, no fragmentation by routers (host-only via extension headers).

ICMPv6 & Neighbor Discovery `🎯 5.6`

ICMPv6 does far more than ICMPv4 — it replaces ARP and handles autoconfiguration via NDP (Neighbor Discovery Protocol):

Message	Type	Replaces / does
Neighbor Solicitation (NS)	135	"Who has this IPv6?" (= ARP request)
Neighbor Advertisement (NA)	136	"I have it, here's my MAC" (= ARP reply)
Router Solicitation (RS)	133	"Are there routers?"
Router Advertisement (RA)	134	Router announces prefix/gateway (SLAAC autoconfig)

icmpv6.type == 135     # Neighbor Solicitation
icmpv6.type == 136     # Neighbor Advertisement
icmpv6.type == 134     # Router Advertisement

🔍 Rogue RA attack: a malicious host sending Router Advertisements (type 134) can hijack IPv6 default routing (MITM) — a real threat even on "IPv4-only" networks that left IPv6 enabled. Hunt for RAs from unexpected MACs.

25. UDP `🎯 5.7`

Connectionless, no handshake, no reliability, tiny 8-byte header.

┌────────────┬────────────┬────────────┬────────────┐
│ Src Port   │ Dst Port   │  Length    │ Checksum   │
└────────────┴────────────┴────────────┴────────────┘

Field	Filter
Source Port	`udp.srcport`
Dest Port	`udp.dstport`
Length	`udp.length`
Checksum	`udp.checksum`

Exam points `🎯`

Higher-layer protocols on UDP: DNS(53), DHCP(67/68), TFTP(69), SNMP(161), NTP(123), Syslog(514), RTP/VoIP, QUIC(443). 🎯 "identify higher layer protocols which use UDP"
Why UDP for multicast/broadcast 🎯: TCP is strictly point-to-point (a handshake needs one specific peer). Broadcast/multicast is one-to-many, so it must be connectionless → UDP. That's why streaming, discovery (mDNS, SSDP), and routing multicasts use UDP.
UDP "stream id" & conversation timestamps 🎯: Wireshark assigns udp.stream indexes and, with conversation timestamps enabled, udp.time_delta — you can Follow UDP Stream and measure per-flow timing just like TCP (useful for DNS/VoIP analysis).

udp.port == 53                    # DNS
udp.stream == 3                   # a specific UDP conversation
udp.length > 512                  # oversized UDP (EDNS, tunneling, amplification)

🔍 UDP is the backbone of amplification DDoS (DNS, NTP, memcached, SSDP): tiny spoofed request → huge reply to the victim. Spot it as many large UDP responses to one dst from many servers on ports 53/123/1900.

26. DHCPv4 (DORA) `🎯 5.8`

How hosts get an IP. Runs on UDP: client 68 → server 67. Filter: dhcp (older Wireshark: bootp).

The 4 phases — DORA `🎯 "identify and describe the 4 phases"`

Step	Message	Direction	Meaning
D	Discover	client → broadcast	"Any DHCP servers out there?"
O	Offer	server → client	"You can have 10.0.0.55"
R	Request	client → broadcast	"I'll take that one" (broadcast so other servers know)
A	ACK	server → client	"Confirmed, here's your lease + options"

dhcp.option.dhcp == 1     # Discover
dhcp.option.dhcp == 2     # Offer
dhcp.option.dhcp == 3     # Request
dhcp.option.dhcp == 5     # ACK
dhcp.option.dhcp == 6     # NAK

The two purposes of a DHCP Request `🎯`

In DORA — accepting an offered address (broadcast).
Lease renewal — an already-configured host unicasts a Request directly to its server to extend the lease (no Discover/Offer needed). Same message type, different context — a classic exam distinction.

DHCP options to know `🎯 "identify DHCP options"`

Option	Name	Filter
1	Subnet Mask	`dhcp.option.subnet_mask`
3	Router (gateway)	`dhcp.option.router`
6	DNS Server(s)	`dhcp.option.domain_name_server`
51	Lease Time	`dhcp.option.ip_address_lease_time`
53	Message Type	`dhcp.option.dhcp`
50	Requested IP	`dhcp.option.requested_ip_address`
12	Hostname	`dhcp.option.hostname`

APIPA ↔ DHCP `🎯`

If Discover gets no Offer (server down, VLAN/relay misconfig, exhausted pool), the client falls back to APIPA 169.254.x.x and has no gateway/DNS → "connected but no internet." Seeing DHCP Discovers with no Offers plus APIPA addresses is the textbook diagnosis. 🎯 Domain 6

🔍 DFIR value of DHCP: Option 12 (hostname) and the client MAC in DHCP packets let you map IP → hostname → MAC → vendor at a point in time — essential for attributing an IP to a physical device during an incident. A rogue DHCP server (unexpected host sending Offers) is an attack that can redirect DNS/gateway for MITM — hunt dhcp.option.dhcp == 2 from any non-authorized server.

27. DNS `🎯 5.9`

Name ↔ IP resolution. Mostly UDP 53 (TCP 53 for zone transfers & large/>512B responses). Filter: dns.

Request vs reply `🎯`

dns.flags.response == 0 = query; == 1 = response.
Match a query to its reply by Transaction ID (dns.id) — Wireshark links them and shows [Time: ...] (the DNS response time — a latency signal).

Record types to recognize `🎯 "distinguish DNS record types"`

Type	#	Meaning
A	1	name → IPv4
AAAA	28	name → IPv6
CNAME	5	alias → canonical name
MX	15	mail server
NS	2	authoritative name server
PTR	12	IP → name (reverse)
TXT	16	arbitrary text (SPF/DKIM… and tunneling/exfil)
SOA	6	zone authority
SRV	33	service location (AD uses heavily)

dns.flags.response == 0                  # queries only
dns.qry.name == "example.com"
dns.qry.type == 1                        # A queries
dns.qry.type == 16                       # TXT (watch for abuse)
dns.flags.rcode == 3                     # NXDOMAIN (name doesn't exist)
dns.qry.name contains "dropbox"          # find traffic to a service
dns.time > 0.5                           # slow DNS responses (>500ms)

🔍 DNS is a hunter's goldmine (covered deeply in §34):

NXDOMAIN storms (dns.flags.rcode == 3) — malware DGA cycling through random domains looking for its live C2.

Long/hex/base32 labels in dns.qry.name + heavy TXT — DNS tunneling / exfiltration.

DNS with no matching process / to a non-corporate resolver — possible C2 or policy evasion.

DNS is often your only record of what domain an IP belonged to at incident time — capture it, keep it.

28. TCP — the big one `🎯 5.10 (17%, scored separately)`

TCP alone is 17% of the exam and graded on its own. Plus most of Domain 6 (troubleshooting, 20%) is TCP analysis. Realistically ~a third of your score lives here. Master it.

The TCP header

 0                   16                  31
┌──────────────────┬──────────────────┐
│  Source Port     │  Destination Port │
├──────────────────┴──────────────────┤
│         Sequence Number              │
├──────────────────────────────────────┤
│      Acknowledgment Number           │
├────┬─────┬───────┬───────────────────┤
│Off │ Rsv │ Flags │   Window Size     │
├────┴─────┴───────┼───────────────────┤
│    Checksum      │  Urgent Pointer   │
├──────────────────┴───────────────────┤
│      Options (MSS, SACK, WS, ...)     │
└───────────────────────────────────────┘

TCP flags `🎯 "how TCP flags establish and tear down a session"`

Flag	Filter	Purpose
SYN	`tcp.flags.syn == 1`	Synchronize — open a connection, exchange initial seq numbers
ACK	`tcp.flags.ack == 1`	Acknowledge received data
FIN	`tcp.flags.fin == 1`	Graceful close — "I'm done sending"
RST	`tcp.flags.reset == 1`	Abrupt reset — kill the connection now
PSH	`tcp.flags.push == 1`	Push buffered data to the app immediately
URG	`tcp.flags.urg == 1`	Urgent pointer valid (rare)

The 3-way handshake `🎯 "describe the components of a 3-way handshake"`

Client                                   Server
  │───── SYN  (seq=0)  ───────────────────▶│   "let's talk; my ISN=X"
  │◀──── SYN, ACK (seq=0, ack=1) ──────────│   "ok; my ISN=Y, I got your SYN"
  │───── ACK  (seq=1, ack=1)  ─────────────▶│   "great, connected"
        ── connection ESTABLISHED ──

Each side picks a random Initial Sequence Number (ISN). The SYN and FIN flags each consume one sequence number (that's why the ACK is ISN+1 even though no data was sent).
Filter for all connection attempts: tcp.flags.syn == 1 && tcp.flags.ack == 0.

iRTT — initial Round-Trip Time `🎯 "explain how iRTT is measured"`

Wireshark measures iRTT as the time between the SYN and the ACK that completes the handshake (SYN → SYN/ACK → final ACK). It appears as [iRTT] in the SYN packet's TCP tree (in brackets = Wireshark-generated). Because it's captured before any application delay, iRTT is your clean baseline for network latency on that path. Column/filter: tcp.analysis.initial_rtt.

💡 High iRTT (say 150 ms) tells you the network path itself is slow before the app even responds — it separates network latency from server slowness (huge for Domain 6).

MSS — Maximum Segment Size `🎯 "describe and calculate MSS"`

MSS = the largest TCP payload (data only) per segment, advertised in a SYN option by each side.
Classic math: standard Ethernet MTU 1500 − 20 (IP header) − 20 (TCP header) = MSS 1460 bytes. Memorize this. (With TCP options/tunnels the effective MSS is smaller — e.g. VPNs.)
Each side can advertise a different MSS; the sender must respect the receiver's advertised MSS. Filter: tcp.options.mss_val == 1460.

Sequence & Acknowledgment numbers `🎯 "how seq/ack maintain reliability"`

Sequence number = byte offset of the first data byte in this segment within the stream.
Acknowledgment number = the next byte the receiver expects (i.e., "I have everything up to ack−1"). ACKs are cumulative.
Reliability loop: sender numbers every byte; receiver ACKs the next expected byte; missing bytes → the ACK number stops advancing → sender retransmits.
Relative sequence numbers (Wireshark default) restart each stream at 0 so they're readable; toggle off in TCP preferences to see the real ISN-based values. 🎯

Teardown methods `🎯 "different methods TCP sessions are torn down"`

Graceful (4-way / FIN): each side sends FIN, the other ACKs it → FIN,ACK ×2. Sometimes seen as 3 packets when a side piggybacks FIN+ACK.
Abrupt (RST): one side sends RST — connection dies immediately, no cleanup. Common when a port is closed, an app crashes, a firewall kills a flow, or a load balancer trims idle connections.

tcp.flags.fin == 1                # graceful closes
tcp.flags.reset == 1              # resets (investigate these!)

TCP Options `🎯 "explain TCP options and their purpose (EOL, NOP, MSS, SACK, DSACK, Window Scaling)"`

Option	Purpose
MSS	Advertise max segment size (SYN only)
Window Scaling (WS)	Multiplier that lets the 16-bit window exceed 65,535 bytes — essential for high-bandwidth/high-latency (BDP) links. Negotiated in SYN; if one side doesn't support it, no scaling for the whole connection
SACK (Selective ACK)	Lets a receiver say "I got bytes 1–1000 and 2001–3000 but not 1001–2000" so the sender resends only the gap, not everything after it
DSACK (Duplicate SACK)	Reports that a duplicate segment arrived (helps distinguish real loss from spurious retransmits)
NOP	No-op padding to align options on 4-byte boundaries
EOL	End of options list
Timestamps (TSval/TSecr)	Better RTT measurement & PAWS

Window size & flow control `🎯` (and Domain 6)

The Window Size field = how many more bytes the receiver can buffer right now. It's the receiver throttling the sender (flow control).
Wireshark shows [Calculated window size] = raw field × the negotiated window scale factor (brackets = generated).
Zero Window (tcp.analysis.zero_window): receiver says "stop, my buffer is full" → transfer stalls until it sends a Window Update. A frequent cause of "the network is slow" that's actually a slow/overloaded receiving application not draining its socket.
Low window + high RTT = throughput killer 🎯 Domain 6: max throughput ≈ Window / RTT (Bandwidth-Delay Product). A small window over a long-latency path caps speed no matter how fast the link — you'll see the sender constantly waiting for ACKs.

The TCP analysis (expert) filters — memorize these `🎯`

These are Wireshark-generated flags (brackets in the tree), your bread and butter for Domain 6:

tcp.analysis.flags                 # EVERYTHING flagged below, at once
tcp.analysis.retransmission        # sender resent (loss suspected)
tcp.analysis.fast_retransmission   # resent after 3 dup ACKs (didn't wait for timeout)
tcp.analysis.duplicate_ack         # receiver re-ACKing → it's missing a segment
tcp.analysis.dup_ack_num           # the Nth dup ACK
tcp.analysis.lost_segment          # Wireshark saw a gap (a segment never captured)
tcp.analysis.out_of_order          # segments arrived out of sequence
tcp.analysis.zero_window           # receiver buffer full → stall
tcp.analysis.window_full           # sender has filled the receiver's window
tcp.analysis.window_update         # receiver re-opened its window
tcp.analysis.keep_alive            # idle-connection keepalive
tcp.analysis.ack_rtt              # time from segment to its ACK (latency!)

DUP ACKs, SACK & finding the missing bytes `🎯`

🎯 "Describe the purpose of a DUP ACK" and "Identify the byte range of missing segments based on a DUP ACK with SACK or DSACK." This is one of the hardest exam skills — here's how.

A duplicate ACK is the receiver repeating "I still only have up to byte N" — it keeps re-ACKing the same number because a segment is missing and everything after it is arriving out of order. 3 dup ACKs trigger the sender's fast retransmit.
With SACK enabled, each dup ACK also carries SACK blocks — the ranges the receiver did receive beyond the gap. The hole between the ACK number and the first SACK-left-edge is the missing byte range.

Worked example:

ACK number (cumulative) = 5001      → receiver has bytes up to 5000
SACK block Left Edge     = 6001
SACK block Right Edge    = 7001      → receiver also has 6001–7000
∴ MISSING segment = bytes 5001 – 6000   (the gap between 5001 and 6001)

The sender only needs to resend 5001–6000, not everything from 5001 onward — that's SACK's whole point. Filters: tcp.options.sack_le / tcp.options.sack_re.

Retransmissions — network loss vs. something else

Retransmission after RTO timeout, or Fast Retransmission after 3 dup ACKs → both mean the sender believes data was lost.
Where you capture matters: retransmits seen near the sender but the originals reaching the receiver fine = the ACKs are being lost on the return path, or you're upstream of the loss. Multi-point capture (§5) pins down where loss happens.

TCP Stream Graphs `🎯 "describe what each line represents in a TCP stream graph"`

Statistics → TCP Stream Graphs:

Graph	X / Y	Read it for
Time / Sequence (Stevens)	time / seq number	A smooth climbing line = healthy throughput; flat spots = stalls; step-backs = retransmits
Time / Sequence (tcptrace)	adds ACK line & window	Gap between data and the window line closing in = flow-control limited
Throughput	time / bytes-per-interval	Where speed dips
Round Trip Time	seq / RTT	Latency spikes per segment
Window Scaling	time / window size	Watch the receive window shrink toward zero (zero-window stalls)

💡 On a Stevens graph, a staircase that flattens then jumps is classic loss+recovery; a line that can't climb because the window ceiling (tcptrace) sits right on top of it is a window-limited transfer, not a loss problem — different fix entirely.

Reassembly, stream id & timestamps `🎯`

TCP reassembly (Allow subdissector to reassemble preference): Wireshark stitches segments so the app layer (HTTP/TLS) is shown decoded against the final segment. Turn it off to inspect raw per-segment bytes. 🎯 "describe the purpose of TCP reassembly."
tcp.stream = Wireshark's per-connection index (generated). tcp.stream == 4 isolates one whole conversation — the single most useful TCP filter for triage. 🎯 "describe the TCP stream id."
Conversation timestamps (tcp.time_relative, tcp.time_delta) = time since the stream's first packet / since the previous packet in this stream. Enable in TCP preferences; add as columns to measure per-flow timing and beacon intervals. 🎯

🔍 TCP for security:

Port scans: many SYNs to many ports, replies are SYN/ACK (open) or RST/ACK (closed). tcp.flags.syn==1 && tcp.flags.ack==0 + Conversations reveals a scanner instantly.

RST storms: bursts of tcp.flags.reset==1 = blocked/killed connections (firewall, IPS, or a service refusing) — or a RST-injection attack.

C2 over TCP: long-lived, low-and-slow conversations on odd ports; use Conversations (duration) + Δtime for beaconing.

Failed handshakes: SYNs with no SYN/ACK = host down, port filtered, or connectivity broken (Domain 6).

Part VII — Application Layer & Troubleshooting `🎯 Domain 6 (20%)`

29. HTTP / HTTPS / TLS

HTTP (cleartext) `🎯`

Runs on TCP 80 (and any port — use Decode As). Filter: http.

http.request                      # all requests
http.request.method == "GET"
http.request.method == "POST"     # uploads / form data / API calls / exfil
http.response.code == 200         # OK
http.response.code >= 400         # client/server errors
http.host == "example.com"
http.user_agent contains "python-requests"   # non-browser client
http.request.uri contains "/admin"

Key headers to read: Host (which site), User-Agent (which client — mismatches reveal bots/malware), Referer, Set-Cookie, Content-Type, Server. Follow → HTTP Stream reads the whole exchange; Export Objects → HTTP pulls the transferred files.

Server slowness vs. network slowness `🎯 Domain 6 — "distinguish server performance from slow transfer times"`

This is a flagship exam/real-world skill. In an HTTP GET:

Client ── GET /page ──▶ Server
                         (⏱ time server takes to respond = SERVER think time)
Client ◀── 200 OK ─────  Server

http.time = time from the request to the full response — includes both server processing and transfer.
Compare against iRTT (§28) and tcp.analysis.ack_rtt:
- Big gap before the server's first response byte, but ACKs are fast → server is slow (app/DB think time), network is fine.
- First byte comes quickly but the transfer drags with retransmissions / zero-windows → network or client problem, server is fine.
High RTT hurts request/response protocols most 🎯: HTTP, SMB, SQL do many small round trips; each one pays the RTT. On a 200 ms-RTT link, 50 sequential round-trips = 10 s of pure waiting regardless of bandwidth. This is why "the app is slow over the WAN but fine on LAN." Low window + high RTT compounds it (BDP throughput cap, §28).

HTTPS / TLS `🎯`

Filter: tls. You can see the handshake even though content is encrypted:

tls.handshake.type == 1           # ClientHello — contains SNI (server name!)
tls.handshake.type == 2           # ServerHello
tls.handshake.type == 11          # Certificate
tls.handshake.extensions_server_name == "example.com"   # SNI = which site
tls.record.version

SNI (tls.handshake.extensions_server_name) in the ClientHello reveals which domain the client is contacting even though the payload is encrypted — a critical hunting field.
The certificate (handshake type 11) shows the server's cert subject/issuer — self-signed or weird certs on odd ports are a C2 signal.
Decrypting TLS: if you control an endpoint, set the env var SSLKEYLOGFILE before launching the browser/app; point Wireshark to that keylog file (Preferences → Protocols → TLS → (Pre)-Master-Secret log filename). Wireshark then decrypts the session and Export Objects / Follow HTTP Stream work on the plaintext. (Server RSA private keys also work for non-PFS ciphers, but modern ECDHE requires the keylog.)

🔍 JA3/JA3S fingerprints (derived from ClientHello/ServerHello fields) identify specific TLS clients — many malware families have known JA3 hashes even though the traffic is encrypted. Wireshark exposes the raw fields; NDR tools compute the hash.

30. Troubleshooting Methodology & Scenarios `🎯 Domain 6 (20%)`

A repeatable method

Scope it — Statistics → Conversations/Endpoints: who's involved, how much, how long.
Isolate the flow — Follow Stream / tcp.stream == N.
Check the handshake — present? iRTT high? SYNs with no SYN/ACK?
Run the expert — tcp.analysis.flags; look for retransmits, dup ACKs, zero windows, resets.
Separate the layers — network latency (iRTT, ack_rtt) vs app latency (http.time, gaps before response) vs flow control (window).
Confirm root cause & prove it — annotate packets, export the minimal evidence.

Scenario playbook

Symptom in capture	Likely cause	Confirm with
SYN, SYN, SYN (no SYN/ACK)	Host down / port filtered / firewall drop	`tcp.flags.syn==1 && tcp.flags.ack==0`; check for ICMP type 3
SYN → RST/ACK	Port closed / service not listening	`tcp.flags.reset==1`
Many retransmissions + dup ACKs	Packet loss on the path	`tcp.analysis.retransmission`, I/O graph vs load
Zero-window / window-full	Receiver app not reading its socket	`tcp.analysis.zero_window`; TCP window graph
Fast first byte, slow big transfer	Loss/congestion or small window×RTT	Stevens stream graph flat spots
Slow first byte, fast transfer	Server/app think time	Gap before response; iRTT is low
Everything slow only over WAN	High RTT × chatty protocol / small window	iRTT, throughput = window/RTT
APIPA 169.254 addresses	DHCP failure	`ip.addr==169.254.0.0/16`, DHCP Discovers w/ no Offer
Duplicate-IP / gratuitous ARP flood	IP conflict or ARP spoofing	`arp.duplicate-address-detected`
ICMP type 3 code 4 black hole	Broken Path MTU Discovery	`icmp.type==3 && icmp.code==4`

🎯 Domain 6 also lists: "determine network topology only using information in a packet capture" — combine MAC↔IP mappings (§2), TTL hop counts (§22), gateway MAC identification, DHCP option-3 gateways, and ARP tables to sketch the LAN. And "identify potential issues using ARP, DHCP, and ICMP" — the three "infrastructure health" protocols above.

31. The Expert Information System `🎯`

Analyze → Expert Information (or the colored dot, bottom-left of the status bar) aggregates every issue Wireshark noticed, grouped by severity:

Severity	Color	Examples
Error	red	Malformed packets, checksum errors, dissector failures
Warning	yellow	Retransmissions, zero window, out-of-order, connection resets
Note	cyan	Dup ACKs, keep-alives, fast retransmits, window updates
Chat	blue/grey	Connection setup (SYN), FIN, window changes

Click any group → expand → click a specific item → jumps to that packet. It's a prioritized worklist for a capture: start at Errors/Warnings.

💡 The status-bar dot shows the highest severity present — a red dot means at least one error is lurking. Double-click it to open the Expert window. For troubleshooting, this + tcp.analysis.flags is the fastest path from "here's a capture" to "here's the problem."

Part VIII — Security Operations `🔍 SOC / IR / Forensics`

Everything so far taught you normal. This part turns that into detection. The same skills that pass WCA-101 are exactly what you use to hunt an intrusion in a pcap — you're just looking for deviations from the baselines above. Nothing here is offensive tooling; it's all defensive analysis of traffic you're authorized to inspect.

32. Threat Hunting in pcap

The hunter's first five moves on an unknown capture

Statistics → Capture File Properties — record SHA256, time range, size (evidence integrity + scope).
Statistics → Protocol Hierarchy — what protocols exist? Anything weird (IRC, TFTP, unknown TCP, lots of "Data")?
Statistics → Conversations (sort by bytes, and by duration) — top talkers + long-lived low-volume flows.
Statistics → Endpoints (+ GeoIP) — talking to unexpected countries/ASNs?
DNS overview — dns.flags.response==0 — what names are being resolved? Any DGA/tunneling smell?

High-signal hunting filters (build these as filter buttons / a "SOC-Hunt" profile)

# --- Reconnaissance / scanning ---
tcp.flags.syn==1 && tcp.flags.ack==0            # connection attempts (port scan source)
tcp.flags.reset==1                              # closed-port/blocked responses (scan target)
icmp.type==8                                    # ping sweep
arp.opcode==1                                   # ARP scan of a subnet

# --- Suspicious egress ---
ip.src==10.0.0.0/8 && ip.dst!=10.0.0.0/8 && tcp.flags.syn==1   # internal→external new conns
tcp.port in {4444 1337 3333 8443 9001 6666 6667}               # common C2/backdoor/IRC ports
!( tcp.port in {80 443 53 25 123 22} ) && ip.dst!=10.0.0.0/8   # unusual outbound ports

# --- Cleartext exposure ---
http.authorization                              # HTTP Basic creds
ftp.request.command in {"USER","PASS"}          # FTP creds
telnet                                          # telnet is all cleartext
frame contains "password"                       # brute string search

# --- Odd clients ---
http.user_agent contains "curl" || http.user_agent contains "python" || http.user_agent contains "powershell"
tls.handshake.extensions_server_name matches "(?i)\\.(top|xyz|tk|ru|cn)$"

Common MITRE-style behaviors ↔ what you see in Wireshark

Attacker behavior	pcap signature
Recon / scanning	SYN sprays, ICMP echo sweeps, ARP sweeps, RST/ACK replies
Initial access (drive-by/download)	HTTP GET of an `.exe/.dll/.js`, odd User-Agent; `Export Objects → HTTP` recovers it
C2 / beaconing	Regular-interval small flows, long-lived low-volume conversations, self-signed TLS on odd ports (§33)
Lateral movement	East-west SMB (`smb2`), RDP (3389), WMI/DCOM (135 + high ports), PsExec named pipes, Kerberos anomalies
Credential access	Cleartext creds, LLMNR/NBT-NS poisoning traffic (`llmnr`, `nbns`), Kerberoasting (many TGS requests)
Exfiltration	Large outbound to one external IP, DNS/ICMP tunneling, HTTP POST of big bodies (§34)

33. Malware, C2 & Beaconing Detection

Beaconing = malware "phoning home" on a schedule to fetch commands. It's periodic and usually low-volume — the opposite of bursty human browsing.

How to spot a beacon in Wireshark

Statistics → Conversations → sort by Duration and look for flows that live for the whole capture but move little data.
Isolate the suspect flow (ip.dst == <suspect> or tcp.stream == N).
Add a frame.time_delta_displayed column (or set time format to Seconds Since Previous Displayed Packet).
Look for regular intervals — e.g. a connection every 60.0 s ± small jitter. Human traffic is irregular; a metronome is automation.
I/O Graph the flow (packets/s) — beacons show an evenly spaced comb of spikes.

Corroborating signals

Tiny, uniform request sizes with occasional larger responses (command pull vs. task delivery).
TLS with a self-signed or mismatched certificate, or no SNI, on a non-standard port (tls && tcp.port != 443).
HTTP beacons: repetitive GET/POST to the same URI, unusual User-Agent, checkin-looking paths.
Destination reputation: endpoint IP in an unexpected ASN/country (Endpoints + GeoIP), freshly-registered domain in DNS.

# Isolate + time a suspected beacon
ip.addr == 203.0.113.66 && tcp
# then add column frame.time_delta_displayed and watch the interval

💡 Wireshark shows you the evidence; tools like RITA, Zeek, or your NDR quantify beacon regularity across huge datasets. Use Wireshark to confirm and characterize a beacon your SIEM/NDR flagged, then pull the exact bytes for the malware team.

34. Data Exfiltration & DNS Tunneling

Bulk exfiltration

Conversations → sort by bytes leaving your network. One workstation pushing hundreds of MB to a single external IP (especially over HTTPS/FTP/an odd port) is the classic pattern.
HTTP POST with large bodies to an unusual host: http.request.method=="POST" && ip.dst!=10.0.0.0/8 — inspect Content-Length and Follow Stream.
Off-hours transfers (correlate timestamps), or steady low-and-slow uploads designed to stay under DLP thresholds.

DNS tunneling / exfil — the hunter's favorite `🔍`

DNS is often allowed straight out, so malware hides data inside DNS. Signatures:

Very long query names with encoded (hex/base32/base64) subdomains: dns.qry.name looks like a3f9c2...e1.tunnel.evil.com, often near the 253-char limit.
High volume of unique subdomains under one parent domain (each query smuggles a chunk of data).
Heavy use of TXT / NULL / CNAME record types for data return.
Requests to one domain vastly outnumbering any web/other traffic to it.

dns.qry.name.len > 50                            # abnormally long names
dns.qry.type == 16                               # TXT (data channel)
dns && frame.len > 300                           # oversized DNS
dns.qry.name matches "(?i)[a-f0-9]{16,}"         # long hex label (encoded payload)
dns.flags.rcode == 3                             # NXDOMAIN storms (DGA hunting)
dns.count.answers == 0 && dns.flags.response==1  # empty answers (tunnel control)

ICMP tunneling

Normal pings are small and uniform. Large or variable ICMP Echo payloads carrying data = covert channel: icmp && data.len > 48. Follow the pattern across the conversation and Follow Stream to read the payload.

🔍 The mindset: exfil hides in allowed protocols (DNS, HTTPS, ICMP). You detect it by volume, regularity, entropy, and record-type anomalies against the baseline — exactly the "normal" you learned in Part VI.

35. Network Forensics & Evidence Handling

When a capture is evidence, process matters as much as analysis.

Chain of custody & integrity

Hash first, analyze the copy. Record SHA256 (Statistics → Capture File Properties, or capinfos -H file.pcapng) before touching the file. Work on a copy; keep the original read-only.
Document: who captured it, where (capture point/TAP/SPAN), when (UTC), with what tool/version, and why. Wireshark's capture file comment (Statistics → Capture File Properties) and per-packet comments live inside the pcapng and travel with the evidence.
Timestamps: set View → Time Display → UTC Date and Time of Day for reports so times are unambiguous and correlate with logs/SIEM.
Preserve completeness: capture with dumpcap (no dissection, fewer drops), full snaplen (no truncation), no capture filter if you can afford it — you can't analyze evidence you filtered away.

Reconstructing the story

Export Objects (HTTP/SMB/FTP/TFTP/IMF) → recover the actual malware, exfiltrated files, emails, or served pages. Hash recovered files; submit to sandbox/AV; match to threat intel.
Follow Stream (Raw) → carve exact byte ranges (payloads, C2 commands, credentials) into standalone files.
DNS + TLS SNI + HTTP Host → rebuild which domains/IPs were contacted and when — the network narrative.
DHCP (hostname/MAC) + ARP → attribute an IP to a specific device at incident time.
File → Export Specified Packets (Displayed/Marked/Range) → produce a minimal, court-ready subset instead of shipping the whole capture.

Tie it together

A defensible forensic report says: "At 14:03:11 UTC host WKSTN-07 (MAC .., per DHCP option 12) resolved evil.example (DNS txn 0x4a1b → 203.0.113.66), opened TCP stream 42 to it, and over 6 minutes POSTed 240 MB (Conversations bytes A→B). The transferred archive was recovered via Export Objects (SHA256 ..). Evidence file case42.pcapng SHA256 .., captured on the egress TAP with dumpcap 4.x." Every claim above is a filter/feature you now know.

36. IR Triage Workflow

A repeatable 10-minute first pass when someone drops a pcap on your desk mid-incident:

1.  capinfos / Capture File Properties   → hash, duration, size, capture point
2.  Protocol Hierarchy                   → what's in here? anything abnormal?
3.  Endpoints (+GeoIP)                    → unexpected external destinations/countries
4.  Conversations, sort by bytes         → top talkers = exfil candidates
    Conversations, sort by duration      → long low-volume = C2 candidates
5.  DNS queries (dns.flags.response==0)   → DGA / tunneling / bad domains
6.  Expert Information                    → errors/resets/retransmits worth noting
7.  Isolate suspects (tcp.stream==N)      → Follow Stream, read the exchange
8.  Export Objects                        → recover payloads, hash them
9.  Mark + comment key packets            → annotate the timeline
10. Export Specified Packets (Marked)     → hand a clean evidence subset up the chain

💡 Bake steps into a profile: pre-made columns (tcp.stream, dns.qry.name, http.host, frame.time_delta_displayed), coloring rules for C2 ports/cleartext, and a filter-button toolbar of the hunt queries in §32. Then triage is click, click, click.

Part IX — Reference

📑 Master Cheat Sheet

Display filter quick reference

# ADDRESSING
ip.addr == x            ip.src == x           ip.dst == x
eth.addr == x           ipv6.addr == x        !(ip.addr == x)   # true exclude

# PORTS / PROTO
tcp.port == 443         udp.port == 53        tcp.port in {80 443 8080}
tcp  udp  icmp  arp  dns  http  tls  dhcp  smb2  ftp

# TCP HEALTH (Domain 6 gold)
tcp.analysis.flags               # all issues
tcp.analysis.retransmission      tcp.analysis.duplicate_ack
tcp.analysis.zero_window         tcp.analysis.lost_segment
tcp.analysis.out_of_order        tcp.flags.reset == 1
tcp.flags.syn==1 && tcp.flags.ack==0     # SYN only
tcp.stream == N                  # isolate one conversation

# OPERATORS
==  !=  >  <  >=  <=      &&  ||  !      contains   matches   in   [n:m]

# STRINGS / RECON
frame contains "password"        http.request.method == "POST"
dns.qry.name contains "evil"     tls.handshake.extensions_server_name == "x"

BPF capture filter quick reference

host x          src host x      dst host x      net 10.0.0.0/8
port 53         tcp port 443    udp port 53     portrange 1000-2000
ether host x    vlan 100        not arp         host x and tcp port 443

Numbers to memorize

Thing	Value
IP Protocol IDs	ICMP=1, TCP=6, UDP=17
EtherTypes	IPv4=0x0800, IPv6=0x86DD, ARP=0x0806, VLAN=0x8100
Default TTLs	Windows=128, Linux/macOS=64, routers=255
MSS (Ethernet)	1500 − 20 − 20 = 1460
Ethernet frame	min 64, max 1518 bytes (1500 MTU)
DHCP ports	client 68 ↔ server 67
DNS	UDP 53 (TCP 53 for zone transfer / large)
Private ranges	10/8, 172.16/12, 192.168/16
APIPA	169.254.0.0/16 (DHCP failed)
IPv6 link-local / multicast	fe80::/10 / ff00::/8
ICMP echo	request=8, reply=0; TTL exceeded=11; unreachable=3
DORA msg types	Discover=1, Offer=2, Request=3, ACK=5, NAK=6
TCP throughput	≈ Window / RTT (BDP)

Keyboard shortcuts

Key	Action
Ctrl+F	Find packet
Ctrl+M	Mark packet
Ctrl+T	Set/unset time reference
Ctrl+D	Ignore packet
Ctrl+→ / ←	Expand / collapse detail tree
Ctrl+. / ,	Next / previous packet in conversation
Ctrl+G	Go to packet number
Ctrl+Shift+N	Next marked packet

The bracket rule (exam!)

Anything in [ ] — [SYN, ACK], [iRTT], [Stream index], [Bytes in flight], [Calculated window size], [Reassembled in ...] — is Wireshark-generated, not bytes on the wire.

📅 30-Day Study Plan

Week	Focus	Do this
1 — Foundations	Packet flow, interface, capture (Domains 1,2,4)	Install; capture your own traffic; add custom columns; build a profile; learn every pane. Read §1–19.
2 — Filters + L2/L3	Filters, Ethernet, ARP, IP, ICMP (Domains 3, 5.1–5.4)	Drill display + BPF filters on sample pcaps; master the `!` trap; do TTL hop-counting; recognize ARP/ICMP types. Read §9–24.
3 — TCP (the 17%)	TCP end-to-end + UDP/DHCP/DNS (5.7–5.10)	Handshake, teardown, seq/ack, options, window, retransmits, dup-ACK+SACK gap math, stream graphs. Do this until it's automatic. Read §25–28.
4 — Troubleshoot + Security + Review	Domain 6 + your SOC/IR use	Work the scenario playbook (§30); run the IR triage flow on malware-traffic pcaps; take the official $29 practice exam; re-drill weak areas. Read §29–36.

Daily habit: open a real capture and answer one question ("what's the slowest flow?", "any retransmits?", "what domains were resolved?"). Hands-on beats re-reading.

Two weeks out: you should be able to, from memory, (1) draw the TCP handshake with seq/ack, (2) list ICMP/DHCP/DNS types, (3) compute MSS and hop distance, (4) explain the ! any/all trap, and (5) name what each stream-graph line means.

🧪 Practice Resources

Practice on real packets — reading about Wireshark ≠ using it.

Wireshark sample captures: wiki.wireshark.org/SampleCaptures — protocols of every kind.
Malware-Traffic-Analysis.net — free, dated exercises with real malware pcaps + questions + answers. The place to build SOC/IR pcap skills.
PacketLife.net captures and CloudShark samples — bite-sized protocol examples.
Capture your own — the best lab is your own machine: browse, ping, nslookup, download a file, and watch it happen live.
Official WCA practice exam (~US $29 via Webassessor) — closest thing to the real questions, with per-item feedback.
Official objectives PDF — wireshark.org/certifications → download the WCA-101 objectives and check off each bullet.
Endorsed training: Packet Pioneer (Chris Greer), Network Nerd, SCOS, SYN-bit.

⚠️ Avoid "exam dump" sites promising real questions — they violate exam policy, are often wrong, and won't teach you the hands-on analysis the WCA actually tests. Learn the packets; the questions take care of themselves.

✅ Final pre-exam checklist

📜 License

Released under CC BY 4.0 — free to share and adapt with attribution.

Wireshark® is a registered trademark of the Wireshark Foundation. This is an independent study guide, not an official Wireshark Foundation product. Exam facts were current as of mid-2026 — always confirm details at wireshark.org/certifications before you register.

Now stop reading and go open a capture. 🦈

Name		Name	Last commit message	Last commit date
Latest commit History 1 Commit
.gitignore		.gitignore
LICENSE		LICENSE
README.md		README.md

Folders and files

Latest commit

History

Repository files navigation

🦈 Wireshark Mastery — WCA-101 + SOC / IR / Network Forensics Field Guide

How to use this guide

📋 Table of Contents

Part I — Foundations

1. The WCA-101 Exam, Decoded

Exam facts

Exam domains & weightings (memorize this table)

2. How Packets Flow Through a Network

Encapsulation — the nesting doll

What changes at each hop (critical for topology & TTL analysis)

Layer 2 vs Layer 3 delivery — the switch/router divide

3. Installing & First Capture

Install

Your first capture in 30 seconds

4. The Wireshark Interface

The three panes you live in

Part II — Capturing Like a Pro 🎯 Domain 2 (10%)

5. Capture Methods

6. Capture Options, Ring Buffers & Limits

Interface & mode

Output / autostop / ring buffer

7. Promiscuous vs Monitor Mode

8. Command-Line Capture

Recipes you should know

Part III — Filtering 🎯 Domain 3 (12%)

Capture filters vs Display filters — the fundamental split

9. Capture Filters (BPF)

10. Display Filters — Complete Reference

The essential fields (know these cold for the exam)

Operators — two syntaxes, same meaning

The power operators (these win exam questions and hunts)

Building filters without typing — the three GUI methods 🎯

11. Operators, Membership, and the ! Trap

The problem: ip.addr matches either field

The fix: negate the whole expression

The rule to memorize

Combining excludes cleanly (common IR pattern)

12. Filter Buttons, Macros & Traps

Filter buttons 🎯 "Create a button for easy access to a display filter"

The "incomplete or excess results" trap 🎯

Part IV — Interface Mastery 🎯 Domain 4 (5%)

13. Columns, Coloring Rules & Minimap

Columns — "the importance of columns in troubleshooting" 🎯

Coloring rules — "highlight packets" 🎯

Minimap (colored sidebar) 🎯

14. Profiles

15. Protocol Preferences & "Decode As"

Protocol preferences 🎯 "understand the importance of protocol preferences"

"Decode As" 🎯

Part V — Key Features 🎯 Domain 1 (10%)

16. Find, Marks, Comments & Time

Find Packet 🎯

Mark / Unmark & Ignore 🎯

Packet & file comments 🎯

Time reference & time formats 🎯 "Set/Unset time reference; apply different time formats"

17. Name Resolution & File Properties

Name resolution 🎯 "describe how Wireshark applies name resolution; configure it"

Capture File Properties 🎯

18. Statistics Tools

Protocol Hierarchy 🎯

Conversations 🎯

Endpoints 🎯

I/O Graph 🎯 "create and interpret an I/O graph (packets/s or bits/s) for a display filter"

Others worth knowing

19. Following Streams & Exporting Objects

Follow Stream 🎯 "Use Follow TCP/UDP stream"

Export Objects 🎯 "Export objects from packet captures"

Export specified packets 🎯

Part VI — Protocol Deep Dives 🎯 Domain 5 (43%)

20. Ethernet 🎯 5.1

Fields to know cold

Exam-favorite facts

Filters

21. ARP 🎯 5.2

How it works

Types you must recognize 🎯

Part II — Capturing Like a Pro `🎯 Domain 2 (10%)`

Part III — Filtering `🎯 Domain 3 (12%)`

Building filters without typing — the three GUI methods `🎯`

11. Operators, Membership, and the `!` Trap

The problem: `ip.addr` matches either field

Filter buttons `🎯 "Create a button for easy access to a display filter"`

The "incomplete or excess results" trap `🎯`

Part IV — Interface Mastery `🎯 Domain 4 (5%)`

Columns — "the importance of columns in troubleshooting" `🎯`

Coloring rules — "highlight packets" `🎯`

Minimap (colored sidebar) `🎯`

Protocol preferences `🎯 "understand the importance of protocol preferences"`

"Decode As" `🎯`

Part V — Key Features `🎯 Domain 1 (10%)`

Find Packet `🎯`

Mark / Unmark & Ignore `🎯`

Packet & file comments `🎯`

Time reference & time formats `🎯 "Set/Unset time reference; apply different time formats"`

Name resolution `🎯 "describe how Wireshark applies name resolution; configure it"`

Capture File Properties `🎯`

Protocol Hierarchy `🎯`

Conversations `🎯`

Endpoints `🎯`

I/O Graph `🎯 "create and interpret an I/O graph (packets/s or bits/s) for a display filter"`

Follow Stream `🎯 "Use Follow TCP/UDP stream"`

Export Objects `🎯 "Export objects from packet captures"`

Export specified packets `🎯`

Part VI — Protocol Deep Dives `🎯 Domain 5 (43%)`

20. Ethernet `🎯 5.1`

21. ARP `🎯 5.2`

Types you must recognize `🎯`

22. IPv4 `🎯 5.3`

Header fields you must know `🎯`

Address ranges to memorize `🎯 "public, private, multicast, APIPA ranges"`

TTL → hop distance `🎯 "predict distance in hops"`

NAT `🎯 "how NAT works and why it matters for capture/analysis"`

Fragmentation `🎯`

23. ICMPv4 `🎯 5.4`

Message types to know `🎯 "identify ICMP message types and their purpose"`

The killer exam skill `🎯 "identify the IP packet which triggered an ICMP error"`

24. IPv6 & ICMPv6 `🎯 5.5–5.6`

IPv6 address types `🎯 "identify Link Local, Global Unicast, Multicast"`

ICMPv6 & Neighbor Discovery `🎯 5.6`

25. UDP `🎯 5.7`

Exam points `🎯`

26. DHCPv4 (DORA) `🎯 5.8`

The 4 phases — DORA `🎯 "identify and describe the 4 phases"`

The two purposes of a DHCP Request `🎯`

DHCP options to know `🎯 "identify DHCP options"`

APIPA ↔ DHCP `🎯`

27. DNS `🎯 5.9`

Request vs reply `🎯`

Record types to recognize `🎯 "distinguish DNS record types"`

28. TCP — the big one `🎯 5.10 (17%, scored separately)`

TCP flags `🎯 "how TCP flags establish and tear down a session"`

The 3-way handshake `🎯 "describe the components of a 3-way handshake"`

iRTT — initial Round-Trip Time `🎯 "explain how iRTT is measured"`

MSS — Maximum Segment Size `🎯 "describe and calculate MSS"`

Sequence & Acknowledgment numbers `🎯 "how seq/ack maintain reliability"`

Teardown methods `🎯 "different methods TCP sessions are torn down"`

TCP Options `🎯 "explain TCP options and their purpose (EOL, NOP, MSS, SACK, DSACK, Window Scaling)"`

Window size & flow control `🎯` (and Domain 6)

The TCP analysis (expert) filters — memorize these `🎯`

DUP ACKs, SACK & finding the missing bytes `🎯`

TCP Stream Graphs `🎯 "describe what each line represents in a TCP stream graph"`

Reassembly, stream id & timestamps `🎯`

Part VII — Application Layer & Troubleshooting `🎯 Domain 6 (20%)`

HTTP (cleartext) `🎯`

Server slowness vs. network slowness `🎯 Domain 6 — "distinguish server performance from slow transfer times"`

HTTPS / TLS `🎯`

30. Troubleshooting Methodology & Scenarios `🎯 Domain 6 (20%)`

31. The Expert Information System `🎯`

Part VIII — Security Operations `🔍 SOC / IR / Forensics`

DNS tunneling / exfil — the hunter's favorite `🔍`