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

Packet capture analysis is the highest-fidelity evidence available during a network incident. This module builds a repeatable workflow using Wireshark and TShark — scoping captures, filtering effectively, and turning raw packet data into analyst conclusions.

A PCAP shows exactly what happened at the wire level. When an alert fires and you are not sure whether the signature matched real behavior or an edge case, a packet capture settles it. Session reconstruction, exfiltration estimation, protocol abuse detection — all of these require the ability to read and navigate capture files without getting lost.

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

Trace each step and identify which log or capture point gives you evidence at that stage. Most triage mistakes happen when someone skips a hop and draws conclusions from an incomplete picture.

$Decide the question and capture point -> run `tcpdump -ni any -w capture.pcap` -> open with `tshark -r capture.pcap -q -z io,phs` to see protocol mix -> apply a display filter to narrow traffic -> follow a TCP stream to see the full application exchange.
$Suspicious DNS query appears in logs -> load the PCAP in tshark, filter on `dns and ip.src == <host>` -> look for long query names, high query volume, or non-standard record types -> pull the associated conn log to see whether a TCP/UDP session followed the response.
$PCAP -> `tshark -Y 'tls.handshake.type==1' -T fields -e ip.dst -e tls.handshake.extensions_server_name` extracts SNI -> compare the SNI list against known-good domains -> anything unrecognized becomes a pivot point for investigation.

baseline-normal-before-debugging

$DNS precedes the TCP connection to the same destination — if you see a SYN with no prior DNS query, the IP was hardcoded or cached.
$A complete HTTP/1.1 response contains a status code, headers, and body in a single TCP stream; gaps in the stream indicate retransmission or capture loss.
$The `capinfos` output for a well-captured PCAP shows zero dropped packets and a duration that matches your capture window.

Expert tip: Record what normal looks like in your actual environment before you test any edge case. A baseline you measured beats a baseline you assumed every time.

concept-breakdown-and-mastery

1. Capture Strategy and Scoping

$ core idea: Before starting a capture, define the question. Are you troubleshooting a broken connection, validating an alert, or gathering evidence of potential exfiltration? The question determines where to capture, how long to run, and what filters to apply. Capturing without a question produces large, unwieldy files that slow analysis.

$ defender angle: Capture filters reduce volume at collection time; display filters narrow analysis after the fact. Use them intentionally. An overly narrow capture filter can permanently exclude evidence you need later — you cannot recover packets that were never written to disk.

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

2. Wireshark Analysis Workflow

$ core idea: Start broad, then narrow. Look at top talkers, protocol distribution, error conditions, and timing anomalies before drilling into individual streams. Follow TCP streams to reconstruct conversations, inspect DNS queries for unusual names or high-volume resolution, review TLS certificate metadata, and compare request-response patterns before drawing conclusions.

$ defender angle: Wireshark works best for interactive investigation. Coloring rules, packet comments, and stream following help build an investigation narrative you can save and share. Keep filtered views and annotated captures so findings are reproducible.

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

3. TShark for Repeatable and Scriptable Analysis

$ core idea: TShark runs without a GUI, which makes it the right tool for headless systems, bulk triage, and scripted workflows. Use it to extract specific fields, summarize protocols across large capture files, and generate quick evidence lists that feed into reports or pipelines.

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

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

deep-dive-notes-expanded

Read each section, then immediately test the concept in your lab. Theory that you have not verified with a real command or log line does not stick.

1. Capture Strategy and Scoping

Before starting a capture, define the question. Are you troubleshooting a broken connection, validating an alert, or gathering evidence of potential exfiltration? The question determines where to capture, how long to run, and what filters to apply. Capturing without a question produces large, unwieldy files that slow analysis.

Capture filters reduce volume at collection time; display filters narrow analysis after the fact. Use them intentionally. An overly narrow capture filter can permanently exclude evidence you need later — you cannot recover packets that were never written to disk.

Always document the capture point: the endpoint, SPAN port, firewall, sensor, or cloud mirror where traffic was collected. The same TCP session can look very different depending on where in the path you intercepted it.

Normal Behavior

DNS precedes the TCP connection to the same destination — if you see a SYN with no prior DNS query, the IP was hardcoded or cached.

Failure / Abuse Pattern

The capture was taken on the wrong interface — traffic that transits the firewall from outside is invisible on a capture taken on the internal segment only.

Evidence To Collect

Capture traffic safely and understand capture scope limitations.

2. Wireshark Analysis Workflow

Start broad, then narrow. Look at top talkers, protocol distribution, error conditions, and timing anomalies before drilling into individual streams. Follow TCP streams to reconstruct conversations, inspect DNS queries for unusual names or high-volume resolution, review TLS certificate metadata, and compare request-response patterns before drawing conclusions.

Wireshark works best for interactive investigation. Coloring rules, packet comments, and stream following help build an investigation narrative you can save and share. Keep filtered views and annotated captures so findings are reproducible.

Focus on a small set of high-value filters deeply: tcp.flags, dns.qry.name, http.request.method, tls.handshake, ip.addr, frame.time_delta. Knowing ten filters well beats having a list of a hundred you have to look up every time.

Normal Behavior

A complete HTTP/1.1 response contains a status code, headers, and body in a single TCP stream; gaps in the stream indicate retransmission or capture loss.

Failure / Abuse Pattern

A BPF filter of `port 443` drops all the DNS queries needed to reconstruct the domain -> IP -> connection sequence — use a broader filter during collection and filter in Wireshark.

Evidence To Collect

Use display filters and stream reconstruction to isolate relevant sessions.

3. TShark for Repeatable and Scriptable Analysis

TShark runs without a GUI, which makes it the right tool for headless systems, bulk triage, and scripted workflows. Use it to extract specific fields, summarize protocols across large capture files, and generate quick evidence lists that feed into reports or pipelines.

A practical workflow: use TShark for first-pass field extraction and protocol summaries, then open a smaller filtered PCAP in Wireshark for detailed examination. Each tool plays to its strength.

Keep a short library of TShark one-liners for DNS summaries, TLS certificate extraction, conversation analysis, and protocol counts. Document them with expected output so teammates can reuse them without starting from scratch.

Normal Behavior

The `capinfos` output for a well-captured PCAP shows zero dropped packets and a duration that matches your capture window.

Failure / Abuse Pattern

Retransmissions are treated as duplicate events rather than evidence of loss — in a sequence gap analysis, retransmits change the byte count and timing even if the payload is the same.

Evidence To Collect

Extract protocol-level indicators and behavioral evidence from PCAPs.

terminal-walkthroughs-with-example-output

Each walkthrough shows a command and what useful output looks like. Your lab output will differ — focus on which fields to read, not on matching the exact values shown here.

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: Run this against your lab environment and read the output field by field before moving on to the next command in this block. If you cannot explain what you see, re-read the section on capture traffic safely.

TShark Summary Queries

Intermediate

Command

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

Example Output

Protocol Hierarchy Statistics
eth
 ip
  tcp
   tls
  udp
   dns

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

cli-labs-and-workflow

Run these in a lab VM or network segment you own or are authorized to test against. After each command, write down one thing the output told you that you did not already know.

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 out loud as if briefing a colleague — no notes.
$Pick one CLI command and walk through exactly what the output means field by field.
$Name a specific failure mode and the log line or packet flag that reveals it.
$Write down what normal looks like for your lab before you introduce any anomaly.

Progress marker: Move on when you can brief the topic to someone else, run the commands from memory, and explain what a bad result looks like.

knowledge-check-and-answer-key

Answer each question out loud or in writing before you look at the hints. If you cannot answer it, go back to the section that covers it — do not just read the hint and move on.

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.
#DNS precedes the TCP connection to the same destination — if you see a SYN with no prior DNS query, the IP was hardcoded or cached.
#sudo tcpdump -ni any -w capture.pcap -c 500
#The capture was taken on the wrong interface — traffic that transits the firewall from outside is invisible on a capture taken on the internal segment only.

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.
#A complete HTTP/1.1 response contains a status code, headers, and body in a single TCP stream; gaps in the stream indicate retransmission or capture loss.
#tshark -r capture.pcap -q -z io,phs
#A BPF filter of `port 443` drops all the DNS queries needed to reconstruct the domain -> IP -> connection sequence — use a broader filter during collection and filter in Wireshark.

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.
#The `capinfos` output for a well-captured PCAP shows zero dropped packets and a duration that matches your capture window.
#editcap -A '2026-01-01 00:00:00' -B '2026-01-01 00:05:00' capture.pcap slice.pcap
#Retransmissions are treated as duplicate events rather than evidence of loss — in a sequence gap analysis, retransmits change the byte count and timing even if the payload is the same.

lab-answer-key-expected-findings

These are reference answers for a generic environment. Replace them with observations from your own lab — what you measured yourself is more useful than what is written here.

Expected Normal Findings

+DNS precedes the TCP connection to the same destination — if you see a SYN with no prior DNS query, the IP was hardcoded or cached.
+A complete HTTP/1.1 response contains a status code, headers, and body in a single TCP stream; gaps in the stream indicate retransmission or capture loss.
+The `capinfos` output for a well-captured PCAP shows zero dropped packets and a duration that matches your capture window.

Expected Failure / Anomaly Clues

!The capture was taken on the wrong interface — traffic that transits the firewall from outside is invisible on a capture taken on the internal segment only.
!A BPF filter of `port 443` drops all the DNS queries needed to reconstruct the domain -> IP -> connection sequence — use a broader filter during collection and filter in Wireshark.
!Retransmissions are treated as duplicate events rather than evidence of loss — in a sequence gap analysis, retransmits change the byte count and timing even if the payload is the same.

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

related-tool-guides

Each of these tools is directly relevant to the evidence collection or validation steps in this topic. Use them to close the gap between reading a concept and running it.

open /learning/tools/wireshark-tshark Wireshark / TShark open /learning/tools/tcpdump tcpdump

related-threat-pages

See where these fundamentals appear in real attack scenarios and what evidence defenders look for during triage.

open /threats/dns-abuse-tunneling-and-command-control DNS abuse, tunneling, and command-and-control open /threats/phishing-and-credential-theft Phishing and credential theft

<- 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