hack3rs.ca network-security

/learning/packet-capture-protocol-analysis-wireshark-tshark :: module-4

student@hack3rs:~/learning$ open packet-capture-protocol-analysis-wireshark-tshark

Packet Capture and Protocol Analysis with Wireshark / TShark

Develop a repeatable packet-analysis workflow using Wireshark and TShark. Focus on scoping captures, filtering effectively, and turning packet evidence into defensive conclusions.

Packet captures are often the highest-fidelity evidence available during network incidents. They help validate alerts, reconstruct sessions, and prove what actually happened rather than what a signature inferred.

learning-objectives

$Capture traffic safely and understand capture scope limitations.
$Use display filters and stream reconstruction to isolate relevant sessions.
$Extract protocol-level indicators and behavioral evidence from PCAPs.
$Translate packet findings into incident notes and detection improvements.

example-dataflow-and-observation-paths

Use these example dataflows to trace how activity moves through systems and where a defender can observe evidence. This is how learners move from memorizing terms to thinking like investigators.

$Capture request defined -> packet capture collected -> TShark summary narrows protocols/hosts -> Wireshark deep dive reconstructs streams -> analyst documents findings and timestamps.
$Suspicious DNS query -> identify related connections -> inspect TLS metadata -> compare to known-good traffic pattern -> escalate or tune detection.
$Evidence path: PCAP -> extracted fields -> narrowed timeline -> annotated stream -> incident note / detection improvement.

baseline-normal-before-debugging

$Protocol flows show expected sequencing (DNS before web request, handshakes before payload).
$Common applications produce repeatable request/response patterns under stable conditions.
$PCAP metadata matches the capture point and target scope documented at start.

Expert tip: Baseline normal behavior before writing detections or escalating anomalies. Most tuning and triage errors come from skipping this step.

concept-breakdown-and-mastery

1. Capture Strategy and Scoping

$ core idea: Before capturing, define the question: Are you troubleshooting an outage, validating an alert, or investigating suspected exfiltration? The question determines capture location, duration, and filter choices.

$ defender angle: Capture filters reduce volume at collection time; display filters narrow analysis after capture. Use them intentionally. Overly narrow capture filters can permanently exclude evidence you later need.

$ prove understanding: Capture traffic safely and understand capture scope limitations.

2. Wireshark Analysis Workflow

$ core idea: Start broad, then narrow: identify top talkers, protocols, errors, and suspicious timings. Follow TCP streams, inspect DNS, review TLS metadata, and compare request-response patterns before making conclusions.

$ defender angle: Wireshark is strong for interactive exploration. Use coloring rules, packet comments, and stream following to build an investigation narrative. Save filtered views and annotated captures for repeatability.

$ prove understanding: Use display filters and stream reconstruction to isolate relevant sessions.

3. TShark for Repeatable and Scriptable Analysis

$ core idea: TShark is ideal for headless systems, bulk triage, and automation. Use it to extract fields, summarize protocols, and generate quick evidence lists without opening a GUI.

$ defender angle: A practical workflow is to use TShark for first-pass summaries and field extraction, then open a smaller filtered PCAP in Wireshark for detailed examination.

$ prove understanding: Extract protocol-level indicators and behavioral evidence from PCAPs.

deep-dive-notes-expanded

Work through the sections in order. For each section, learn the theory, identify normal behavior, identify failure patterns, then validate with packet/log/CLI evidence.

1. Capture Strategy and Scoping

Before capturing, define the question: Are you troubleshooting an outage, validating an alert, or investigating suspected exfiltration? The question determines capture location, duration, and filter choices.

Capture filters reduce volume at collection time; display filters narrow analysis after capture. Use them intentionally. Overly narrow capture filters can permanently exclude evidence you later need.

Always document the capture point (endpoint, SPAN port, firewall, sensor, cloud mirror). The same flow can look very different depending on where in the path you observe it.

Normal Behavior

Protocol flows show expected sequencing (DNS before web request, handshakes before payload).

Failure / Abuse Pattern

Capture point misses critical traffic and analysts over-interpret partial evidence.

Evidence To Collect

Capture traffic safely and understand capture scope limitations.

2. Wireshark Analysis Workflow

Start broad, then narrow: identify top talkers, protocols, errors, and suspicious timings. Follow TCP streams, inspect DNS, review TLS metadata, and compare request-response patterns before making conclusions.

Wireshark is strong for interactive exploration. Use coloring rules, packet comments, and stream following to build an investigation narrative. Save filtered views and annotated captures for repeatability.

Learn a small set of high-value filters deeply (for example tcp.flags, dns.qry.name, http.request.method, tls.handshake, ip.addr, frame.time_delta). Mastery beats memorizing a giant list.

Normal Behavior

Common applications produce repeatable request/response patterns under stable conditions.

Failure / Abuse Pattern

Overly narrow capture filters drop the packets needed for root cause analysis.

Evidence To Collect

Use display filters and stream reconstruction to isolate relevant sessions.

3. TShark for Repeatable and Scriptable Analysis

TShark is ideal for headless systems, bulk triage, and automation. Use it to extract fields, summarize protocols, and generate quick evidence lists without opening a GUI.

A practical workflow is to use TShark for first-pass summaries and field extraction, then open a smaller filtered PCAP in Wireshark for detailed examination.

Keep a small library of TShark commands for DNS summaries, TLS handshake metadata, conversations, and protocol counts. Reuse and document them for your team.

Normal Behavior

PCAP metadata matches the capture point and target scope documented at start.

Failure / Abuse Pattern

Packet details are read without checking timing, retransmission, or protocol order.

Evidence To Collect

Extract protocol-level indicators and behavioral evidence from PCAPs.

terminal-walkthroughs-with-example-output

These walkthroughs show representative commands plus example output so learners know what success and useful evidence look like. Treat the output as a pattern guide, not a fixed transcript.

Capture Traffic Safely

Beginner

Command

sudo tcpdump -ni any -w capture.pcap -c 500

Example Output

IP 10.10.20.15.53422 > 93.184.216.34.443: Flags [S]
IP 93.184.216.34.443 > 10.10.20.15.53422: Flags [S.]

$ why this matters: Use this step to validate capture traffic safely before moving on to more advanced commands in the same block. Focus on interpreting the output, not just running the command.

TShark Summary Queries

Intermediate

Command

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

Example Output

Protocol Hierarchy Statistics
eth
 ip
  tcp
   tls
  udp
   dns

$ why this matters: Use this step to validate tshark summary queries before moving on to more advanced commands in the same block. Focus on interpreting the output, not just running the command.

Workflow Helpers

Advanced

Command

editcap -A '2026-01-01 00:00:00' -B '2026-01-01 00:05:00' capture.pcap slice.pcap

Example Output

# command executed in lab
# review output for expected fields, errors, and anomalies

$ why this matters: Use this step to validate workflow helpers before moving on to more advanced commands in the same block. Focus on interpreting the output, not just running the command.

cli-labs-and-workflow

Run these commands only in environments you own or are explicitly authorized to test. Use a lab VM, sandbox network, or approved internal test segment for practice.

Capture Traffic Safely

Beginner

sudo tcpdump -ni any -w capture.pcap -c 500
sudo tshark -i any -a duration:30 -w capture.pcap
capinfos capture.pcap

Run in a lab or authorized environment. Record what fields change when you alter the test conditions.

TShark Summary Queries

Intermediate

tshark -r capture.pcap -q -z io,phs
tshark -r capture.pcap -Y dns -T fields -e frame.time -e ip.src -e dns.qry.name
tshark -r capture.pcap -Y tls.handshake.type==1 -T fields -e ip.dst -e tls.handshake.extensions_server_name

Run in a lab or authorized environment. Record what fields change when you alter the test conditions.

Workflow Helpers

Advanced

editcap -A '2026-01-01 00:00:00' -B '2026-01-01 00:05:00' capture.pcap slice.pcap
wireshark capture.pcap

Run in a lab or authorized environment. Record what fields change when you alter the test conditions.

expert-mode-study-loop

$Explain the concept in plain language without reading notes.
$Show how to validate the concept with logs, packets, or commands.
$Name at least one common failure mode and how to detect it.
$Document what 'normal' looks like before testing edge cases.

Progress marker: You are ready to move on when you can explain the topic, run the commands, and interpret the output without guessing.

knowledge-check-and-answer-key

Try answering these from memory before looking at the hints. These questions are designed to test understanding of concepts, dataflow, and evidence collection.

1. Capture Strategy and Scoping

Questions

?How would you explain "Capture Strategy and Scoping" to a new defender in plain language?
?What does normal behavior look like for capture strategy and scoping in your lab or environment?
?Which logs, packets, or commands would you use to validate capture strategy and scoping?
?What failure mode or attacker abuse pattern matters most for capture strategy and scoping?

Show answer key / hints

Answer Key / Hints

#Capture traffic safely and understand capture scope limitations.
#Protocol flows show expected sequencing (DNS before web request, handshakes before payload).
#sudo tcpdump -ni any -w capture.pcap -c 500
#Capture point misses critical traffic and analysts over-interpret partial evidence.

2. Wireshark Analysis Workflow

Questions

?How would you explain "Wireshark Analysis Workflow" to a new defender in plain language?
?What does normal behavior look like for wireshark analysis workflow in your lab or environment?
?Which logs, packets, or commands would you use to validate wireshark analysis workflow?
?What failure mode or attacker abuse pattern matters most for wireshark analysis workflow?

Show answer key / hints

Answer Key / Hints

#Use display filters and stream reconstruction to isolate relevant sessions.
#Common applications produce repeatable request/response patterns under stable conditions.
#tshark -r capture.pcap -q -z io,phs
#Overly narrow capture filters drop the packets needed for root cause analysis.

3. TShark for Repeatable and Scriptable Analysis

Questions

?How would you explain "TShark for Repeatable and Scriptable Analysis" to a new defender in plain language?
?What does normal behavior look like for tshark for repeatable and scriptable analysis in your lab or environment?
?Which logs, packets, or commands would you use to validate tshark for repeatable and scriptable analysis?
?What failure mode or attacker abuse pattern matters most for tshark for repeatable and scriptable analysis?

Show answer key / hints

Answer Key / Hints

#Extract protocol-level indicators and behavioral evidence from PCAPs.
#PCAP metadata matches the capture point and target scope documented at start.
#editcap -A '2026-01-01 00:00:00' -B '2026-01-01 00:05:00' capture.pcap slice.pcap
#Packet details are read without checking timing, retransmission, or protocol order.

lab-answer-key-expected-findings

Use this as a baseline answer key for labs and walkthroughs. Replace these with environment-specific observations as you practice in real or simulated networks.

Expected Normal Findings

+Protocol flows show expected sequencing (DNS before web request, handshakes before payload).
+Common applications produce repeatable request/response patterns under stable conditions.
+PCAP metadata matches the capture point and target scope documented at start.

Expected Failure / Anomaly Clues

!Capture point misses critical traffic and analysts over-interpret partial evidence.
!Overly narrow capture filters drop the packets needed for root cause analysis.
!Packet details are read without checking timing, retransmission, or protocol order.

hands-on-labs

$Capture a login to a lab web app and reconstruct the transaction timeline (DNS, TCP/TLS, HTTP).
$Use TShark to extract DNS query names and TLS SNI/certificate metadata from a PCAP.
$Compare benign software update traffic versus suspicious scripted traffic and write a short analyst note.

common-pitfalls

$Using only display filters and assuming dropped packets never happened.
$Ignoring clock/time deltas and focusing only on packet contents.
$Treating one packet or one stream as representative of all traffic.

tools-and-references

completion-outputs

# A reusable packet analysis checklist
# A TShark command cheat sheet for defender workflows
# A sample incident packet timeline with evidence notes

<- previous page Linux and Windows Logging Basics for Defenders -> next page Network Security Monitoring with Zeek and Suricata

learning-path-position

Detection & Monitoring / Weeks 3-6 · Module 4 of 12