Quick answer: Wireshark is a free and open source tool for examining network traffic at packet level. In forensics it answers two questions: where did the data go, and when did the attacker do what. The most critical distinction while learning: a display filter (ip.addr == 10.0.0.5) and a capture filter (host 10.0.0.5) use different syntaxes, and confusing them is the biggest beginner obstacle. When you open a PCAP, work in this order: get the overall picture from Statistics, find who talked to whom in Conversations, read the suspicious flow with Follow TCP Stream, and pull transferred files with File then Export Objects. Most traffic is TLS encrypted, so the real skill is reading metadata rather than content.

In data leak investigations the disk tells you what was taken, the network tells you where it went. If an employee copied a customer list, traces remain on disk, but only network data shows whether that file actually left the building. This article is for those who want to learn Wireshark through a forensic lens.

When Wireshark comes into play

Network data differs from other evidence in one respect: if it was not recorded, it does not exist. You can examine a disk later, but you cannot recover traffic from two weeks ago that was never captured. Three sources matter in organizations:

  • PCAP files, full packet capture. The richest but most storage hungry source.
  • NetFlow and similar flow records, no content but who talked to whom and how much. Can be retained far longer.
  • Proxy, DNS and firewall logs, in practice the source most often available.

Wireshark examines the first category. In incident response you often will not have full PCAP, but when you do it gives the most definitive answer.

Capture filters versus display filters

This is where beginners get stuck most, and the two are different languages.

Capture filters run while recording and use BPF syntax. A packet not recorded is lost forever, so avoid narrow capture filters in forensic work.

host 10.0.0.5
port 443
net 192.168.1.0/24
not port 22

Display filters run after the capture is open and use Wireshark's own syntax. They delete nothing, they only show.

ip.addr == 10.0.0.5
tcp.port == 443
http.request.method == "POST"
dns.qry.name contains "example"
tls.handshake.extensions_server_name contains "dropbox"
frame.time >= "2026-07-14 09:00:00"

The rule: in forensics, capture broadly, display narrowly. Narrowing the capture loses evidence, narrowing the display is only focus.

The order for examining a PCAP

Reading packets one by one from the start is the least efficient approach. Follow this order:

  1. The overall picture. Statistics then Capture File Properties: when did recording start, how long, how many packets. Match the window to the incident.
  2. Protocol breakdown. Statistics then Protocol Hierarchy: what share is TLS, DNS, is there an unexpected protocol. Anomalies usually stand out here.
  3. Who talked to whom. Statistics then Conversations: sort address pairs by bytes. A single large outbound flow is the first sign of exfiltration.
  4. Name resolution. Statistics then DNS, or the dns filter: which domains were queried. Even in encrypted traffic, DNS tells you the destination.
  5. Read the stream. Right click a suspicious packet, Follow then TCP Stream. On unencrypted protocols you read the whole session.
  6. Extract files. File then Export Objects: pull files transferred over HTTP, SMB and FTP to disk.
  7. Tie it to a timeline. Place findings on the same timeline as disk and memory evidence. A packet alone tells no story.

Encrypted traffic: where the real skill lies

The overwhelming majority of traffic today is TLS encrypted. That does not end network analysis, it shifts focus from content to metadata. From an encrypted flow you can still read:

  • SNI (Server Name Indication). The destination domain usually travels in the clear during the TLS handshake. The tls.handshake.extensions_server_name filter shows which site was contacted.
  • Certificate details. Names in the server certificate are visible.
  • JA3 and JA4 fingerprints. The client's handshake style produces a signature, which is how known malicious clients are recognized.
  • Volume and timing patterns. A connection sending a small packet of identical size every 60 seconds is the classic sign of a command channel. You recognize the pattern without reading content.
  • Duration and direction. Long lived one way outbound uploads indicate exfiltration.

Note: as encrypted SNI (ECH) spreads this visibility decreases, which makes DNS and flow records even more important.

Patterns to look for in a leak investigation

Pattern Example filter What it means
Large outbound upload Conversations, sort by bytes Data exfiltration
Regular small packets tcp.len < 200 plus timing analysis Command channel (beacon)
TLS on an unusual port tls && !(tcp.port == 443) A channel trying to hide
DNS tunnelling dns.qry.name.len > 50 Smuggling data over DNS
Cleartext credentials http.authbasic or ftp Weak configuration, also evidence
Connection to unknown destination tls.handshake.extensions_server_name Unauthorized service use
File copy over SMB smb2.cmd == 5 Lateral data movement internally

Learning path and practice data

Network analysis is learned only on real captures. Lawful and free sources:

  • The Wireshark sample capture archive, ideal for learning protocols.
  • Malware Traffic Analysis, scenario exercises containing real malware traffic, one of the most productive resources for developing a forensic eye.
  • The NETRESEC public PCAP list, which aggregates many sources.
  • DFRWS challenge files for advanced practice.
  • Your own lab: transfer a known file between two virtual machines while capturing, then try to extract it with Export Objects.

Month one: learn what a TCP handshake, a DNS query and an HTTP request look like at packet level. You cannot find the abnormal without knowing the normal. Month two: work through display filters and the Statistics menu. Make Follow Stream and Export Objects habitual. Month three: move to reading metadata in encrypted traffic, study beacon patterns and SNI analysis.

The legal boundary: capturing is not automatically permitted

Technical ease does not mean legal freedom. Capturing traffic on a corporate network can amount to monitoring employee communications, which requires a previously communicated policy, a legitimate purpose and proportionality. Where personal data is processed, data protection obligations apply. Capturing a third party's network without authorization is plainly unlawful.

Common mistakes

  • Keeping the capture filter narrow. A packet not recorded never returns.
  • Capturing without promiscuous mode or port mirroring. On a switch you see only your own traffic, and this often goes unnoticed.
  • Not recording the time zone. Clock offsets ruin correlation with other logs.
  • Not hashing the PCAP. A network capture is evidence too and its integrity must be recorded.
  • Giving up because it is encrypted. Metadata answers most questions.
  • Drawing conclusions from a single packet. Without context a packet is not proof.

Frequently asked questions

Can Wireshark decrypt encrypted traffic? Not without keys. With the server private key or the browser's session key log (SSLKEYLOGFILE) you can, which is generally only possible in your own test environment.

What is the difference between tcpdump and Wireshark? tcpdump captures on the command line and is practical on servers. Wireshark analyzes through a graphical interface. The common arrangement: capture with tcpdump, analyze with Wireshark.

How much PCAP should I retain? Full packet capture consumes enormous storage. Most organizations keep short term full capture on critical segments and long term flow records elsewhere.

Is PCAP sufficient on its own in a forensic examination? No. It gains meaning combined with disk and memory evidence.

Can I record my employee's traffic? On corporate resources it is possible subject to a legitimate purpose, a previously communicated policy and proportionality. Do not begin without a legal assessment.

Do I need networking knowledge to learn Wireshark? Basic TCP/IP knowledge is required. You must understand how protocols work before reading packets.

Sources

In a suspected data leak, network records are often the only definitive proof. For examination support or hands on network forensics training for your team, contact DSET. We provide incident response and digital forensics from our Ankara Hacettepe Teknokent laboratory.