Wireshark / TShark

Wireshark is the interactive GUI for packet inspection, stream following, and protocol dissection. TShark runs the same dissector engine from the command line, which makes it practical for SSH sessions, servers, automation, and quick field extractions during incident triage.

These tools answer questions that logs and alerts routinely cannot: Did the TCP handshake complete? Did DNS resolve? Did the TLS negotiation succeed or fail, and at which step? Did the client retry three times before giving up? Packet evidence cuts through conflicting tool outputs.

When a firewall says accepted, an application says timeout, and the IDS says nothing — a packet capture breaks the tie. Whether the problem is retransmission, a protocol mismatch, or an unexpected reset, the wire does not lie.

Start by writing down the question you are trying to answer. Troubleshooting a service outage means focusing on resets, retransmissions, and application response codes. Investigating suspicious activity means looking at destination patterns, protocol choices, session timing, and repeated behavior.

Run two passes. First, scope: identify top talkers, protocol mix, time windows, and obvious errors. Second, dig: reconstruct individual streams, inspect DNS query behavior, check TLS metadata, and annotate the packet evidence that supports your conclusions.

Write down the capture context every time — interface, capture point, filter used, time window, and what was not visible from that vantage. Without this, the analysis is hard to reproduce and easy to misread by the next analyst who picks it up.

Wireshark is one of the best places to learn how DNS actually behaves in your environment. You can watch query names, response codes, resolver selection, retry timing, and latency in real time. Most "suspicious domain" questions turn out to be stale records, misconfigured resolvers, or normal CDN behavior — and you can only tell the difference by looking.

TLS analysis is valuable even though payloads are encrypted. The handshake is visible: protocol version, cipher suites offered and chosen, certificate details, SNI, and failure step if the negotiation breaks. These details explain service problems and support network-based detections without decrypting anything.

The right mental model for encrypted traffic is not "I cannot see it." It is "I can see the protocol behavior, timing, and metadata." That shift makes you a better troubleshooter and a better threat hunter.

TShark pulls specific fields out of large captures quickly — DNS query names, TLS SNI values, IP conversations, HTTP methods, protocol counts. When your first goal is narrowing a 2 GB pcap file to the relevant ten minutes and three hosts, TShark is faster than clicking through the GUI.

During incident response, TShark lets you build small evidence tables for the report: which suspicious destinations did this host contact, how many TLS handshakes failed, how many NXDOMAIN responses came back in the first hour. These summaries help responders who are not packet analysts understand what the traffic shows.

Keep a small set of tested TShark commands for recurring tasks. Security teams who invest fifteen minutes building these snippets recover that time on the first real incident they use them. The commands also make your workflow reproducible across cases.

Where you capture matters more than which tool you use. An endpoint capture, a SPAN port, a VPN concentrator tap, and a cloud traffic mirror each have different blind spots. Know what traffic your capture point can and cannot see before drawing conclusions from what you did not observe.

Capture filters cut volume at collection time but permanently discard traffic. Display filters are safer when you are unsure what you need — they preserve everything and let you filter later. In high-volume environments, short targeted captures with documented rationale beat large unfocused ones every time.

A pcap file often contains regulated or sensitive data. Build habits around secure storage, limited retention, and access control from day one. For training purposes, use lab captures or strip sensitive content before sharing.

Packet tools extend what SIEMs, IDS/IPS, and endpoint telemetry can tell you. An alert shows that something happened. Packet evidence shows exactly what the handshake looked like, whether the payload matched the signature, and whether the traffic was actually interesting or a false positive.

Teams that treat packet analysis as a normal skill — not a rare escalation — close incidents faster and produce better root-cause write-ups. The three recurring tasks are: troubleshoot a service, validate an alert, reconstruct a timeline. You do not need full packet capture everywhere to get value from those.

Targeted captures during an incident window, lab captures for baselining normal protocol behavior, and short captures after a change all build the muscle memory you need before a real crisis lands in your queue.

Learn normal traffic before you try to recognize abnormal traffic. Capture a web browsing session, a DNS lookup, an SSH connection, a software update, and a failed TLS handshake. Build a mental model of what each looks like in Wireshark before you hunt for malicious behavior.

Develop a personal filter set and refine it over time. You do not need to memorize every protocol field — you need a reliable workflow for filtering by host, protocol, stream, time, and error condition. That gets you to the relevant packets in two minutes instead of twenty.

Write short summaries after each lab capture. Translating packet details into clear evidence statements — "the client sent three SYN packets with no response from the server side" — is the same skill you will need when writing an incident timeline at 2 a.m.