The mindset that makes Wireshark useful

Open Wireshark on a busy interface and you get thousands of packets a second — a firehose that tells you nothing until you know what you are looking for. The people who find Wireshark indispensable and the people who find it overwhelming are looking at the same tool; the difference is entirely one of method. This guide is about the method: capture less, filter hard, and know what normal looks like before you go hunting for abnormal.

Almost everything below also assumes the traffic is yours to look at. Packet capture on a network you do not own or administer can break wiretapping law, and "I was just curious" is not a defence. On your own network, in a lab, or with written authorisation, it is one of the most powerful diagnostic and forensic tools there is.

Two kinds of filter, and the costly mistake of confusing them

Wireshark has two filter systems that look similar and do completely different jobs. Getting them straight is the first real skill.

A capture filter decides what gets recorded. It runs before packets are saved, uses the low-level BPF syntax, and what it drops is gone forever. Use it to keep a capture manageable on a busy link:

Only web traffic
tcp port 80 or tcp port 443
Only one subnet
net 192.168.1.0/24
Only DNS
udp port 53

A display filter decides what you see in a capture you already have. It uses Wireshark's own richer syntax, and it hides rather than deletes — clear it and every packet is back:

HTTP POSTs — a place data leaves the network
http.request.method == "POST"
DNS lookups to throwaway TLDs
dns.qry.name contains ".xyz" or dns.qry.name contains ".top"
TLS to a non-standard port
tls && tcp.port != 443

The mistake that costs you evidence: using a capture filter when you should have used a display filter. If you capture only port 443 and later realise the interesting activity was on port 8443, that traffic was never written and cannot be recovered. On anything you might need to investigate afterwards, capture broadly and filter the display narrowly. Capture filters are for taming volume on a link too busy to record whole; display filters are for the actual analysis.

Following the conversation, not the packet

A single packet rarely tells a story; the exchange does. Wireshark's most useful everyday feature is Follow TCP Stream (right-click a packet → Follow → TCP Stream), which reassembles both directions of a connection into the actual back-and-forth — the HTTP request and its response, the commands and replies of a plaintext protocol, laid out in order. This is where you stop reading hex and start reading what happened.

Two menus turn a capture into an overview:

• Statistics → Conversations lists every pair of hosts talking, with byte and packet counts. It is how you spot the one internal host sending far more data outbound than any other.
• Statistics → Protocol Hierarchy breaks the capture down by protocol, so an unexpected sliver of something — IRC on a corporate network, an odd amount of ICMP — jumps out against the normal mix.

Reading traffic for signs of trouble

Once you can filter and follow, the forensic questions become approachable. A few patterns worth knowing by sight:

Beaconing. Command-and-control malware tends to phone home on a regular cadence — a connection every 60 seconds, say, whether or not there is anything to do. In Conversations, that shows as a host pair with a steady, metronomic packet rhythm rather than the bursty pattern of human activity. Regularity is the tell.

DNS tunnelling. DNS is allowed out of almost every network, which makes it a favourite covert channel. The signatures are unusually long query names, a high volume of TXT lookups, and a flood of subdomains under one parent domain — data smuggled out one query at a time. A display filter on dns plus a glance at query lengths surfaces it.

Data exfiltration. Large outbound transfers at hours when nobody is working, encrypted connections to non-standard ports, or big HTTP POST bodies to a domain no one recognises. None is proof on its own; together, and against a baseline of what this network normally does, they are a lead.

The common thread is that every one of these is defined relative to normal. You cannot recognise abnormal beaconing without knowing this network's usual rhythm, or a suspicious destination without knowing the usual ones. Which is why the single most valuable thing you can do with Wireshark is study known-good traffic first.

tshark: Wireshark without the window

The GUI is for exploring; tshark, its command-line sibling, is for repeating and automating. Anything you do once by hand, tshark lets you script over many captures:

Every HTTP host and path requested in a capture
tshark -r capture.pcap -Y "http.request" \
  -T fields -e http.host -e http.request.uri
Talkers, busiest first — the CLI version of the Conversations view
tshark -r capture.pcap -T fields -e ip.src | sort | uniq -c | sort -rn | head -20
Carve one TCP stream out into its own file for closer study
tshark -r capture.pcap -Y "tcp.stream eq 5" -w stream5.pcap

-Y takes the same display-filter syntax as the GUI, and -T fields -e … prints named fields as columns you can pipe into sort, awk or a script. This is how you go from analysing one capture to processing a directory of them the same way every time — the foundation of any automated triage pipeline.

Working habits that save you later

• Capture broad, filter narrow. Record more than you think you need; a display filter can always narrow it, a capture filter cannot un-drop a packet.
• Use a ring buffer for long captures. -b filesize: / -b files: (or the GUI's multiple-file options) roll over old files so continuous monitoring does not fill the disk.
• Treat captures as sensitive. A pcap can contain credentials, tokens and personal data in the clear. Encrypt it at rest and delete it when the work is done — it is exactly the kind of file that turns a capture session into a breach.
• Timestamp everything. In incident response the sequence and timing of packets is often the whole finding; note the capture's time base.
• Baseline first. Capture a known-good period and learn its shape. Every anomaly you will ever find is defined against that.

Where a hosted scanner fits — and where it doesn't

Wireshark reads traffic that reaches the machine it runs on, which means capture is inherently local: to see a network's packets you need to be on that network, and no remote service can sniff air or wire it cannot touch. That part stays on your own machine. What a platform like CyberSec Pro complements is the active side of an assessment — the scanning, enumeration and exploitation tools that generate traffic and probe services, run server-side in a dedicated container with their output streamed back. A common workflow pairs the two: run an authorised scan from the platform, capture the resulting traffic locally in Wireshark, and use the packet view to confirm exactly what the target did in response. The scanner tells you what is exposed; the capture tells you what actually happened on the wire.