Wireshark for Blue Teams: Spot Suspicious Traffic

Wireshark is the microscope of network defence. Logs tell you that something happened. A packet capture shows you exactly what was said on the wire. This guide teaches a blue team workflow in Wireshark: the filters to use, the patterns that point to scanning, beaconing, DNS abuse and cleartext credentials, and the habits that keep an investigation tidy.

This is Part 9 of 30 in the Blue Team Learning Path. If you want the offensive side of the same tool, our Wireshark for penetration testing guide covers capture setup and attacks. Here we focus on spotting suspicious traffic.

Key takeaways

• Start with the big picture (Protocol Hierarchy, Conversations) before reading single packets.
• Capture filters limit what you record. Display filters limit what you see. Do not confuse them.
• Look for patterns over time: regular intervals, many ports, unusually long DNS names.
• Analyse captures in an isolated VM, because pcaps from incidents can contain malware payloads.

Capture filters versus display filters

This distinction trips up almost every beginner. A capture filter uses BPF syntax and decides which packets are saved while you capture. If you filter too much, the evidence is gone for good. A display filter uses Wireshark’s own syntax and only hides packets in the view. For investigations, capture broadly if disk space allows and filter in the display. The official display filter reference lists every field you can use.

Two examples to show the difference:

Capture filter (BPF):   host 192.0.2.10 and tcp port 443
Display filter:         ip.addr == 192.0.2.10 && tcp.port == 443

Step 1: get the big picture first

Before you read a single packet, open the summary views from the Statistics menu.

• Protocol Hierarchy: shows what share of traffic is which protocol. Unexpected protocols, such as large amounts of DNS or IRC on a file server, are leads.
• Conversations: lists every pair of endpoints with bytes and duration. Sort by bytes to spot unusual transfers, and by duration to find long-lived connections.
• Endpoints: shows which hosts talk the most. A workstation that talks to hundreds of internal hosts is behaving like a scanner.
• I/O Graph: plots traffic over time. A perfectly regular pattern is a hint of automation.

Step 2: the display filters every defender should know

• dns: all DNS traffic.
• http.request: HTTP requests (cleartext only).
• tls.handshake.type == 1: TLS Client Hello packets.
• tcp.flags.syn == 1 && tcp.flags.ack == 0: the first packet of every new TCP connection.
• ip.addr == 192.0.2.10: anything from or to one host.
• !(arp || icmp || dns): remove common background noise.
• frame.time_delta > 30: gaps of more than 30 seconds between packets.

Combine them with && and ||. Right-click any field in the packet details and choose “Apply as Filter” to build filters without memorising names. Save the ones you use often as filter buttons.

Pattern 1: port scanning

A scanner sends many SYN packets to many ports and gets mostly resets back. Apply tcp.flags.syn == 1 && tcp.flags.ack == 0, then open Statistics, Conversations, TCP and look for one source with a huge number of short conversations to one destination. A reset-heavy view with tcp.flags.reset == 1 confirms closed ports. Internal scanning like this maps to the Discovery tactic in ATT&CK, as explained in Part 6.

Pattern 2: beaconing

Malware checking in with its command server tends to connect at regular intervals, often with small random variation. To find it:

1. Filter to one suspicious host and its external destinations.
2. Open Statistics, Conversations and sort external addresses by number of packets or duration.
3. Pick one conversation and add the column frame.time_delta_displayed.
4. Look for repeated, similar gaps, for example every 60 seconds.

Legitimate software also polls on timers, such as update checks, so beaconing is a lead rather than proof. Check whether the destination is a known service and whether the traffic size looks like a heartbeat.

Pattern 3: suspicious DNS

DNS is allowed almost everywhere, so attackers abuse it. Filter with dns and look for:

• Very long or random-looking subdomains, which may carry encoded data.
• Many TXT queries to one domain.
• A large number of failed lookups (NXDOMAIN) for random names, which is typical of domain generation algorithms.
• Internal hosts bypassing your resolver and talking straight to an outside DNS server.

You can export fields to a list with the command-line version, tshark, that ships with Wireshark:

tshark -r capture.pcapng -Y "dns.flags.response == 0" \
  -T fields -e ip.src -e dns.qry.name | sort | uniq -c | sort -rn | head

This counts the most frequent queries per source. A single name repeated hundreds of times, or a host asking for thousands of unique names, deserves a closer look.

Pattern 4: cleartext credentials and file transfers

Old protocols such as FTP, Telnet and HTTP basic authentication send secrets unencrypted. Filter with ftp.request.command == "PASS" or http.authorization to find them. In an incident, this tells you which credentials must be rotated. Use File, Export Objects, HTTP to list files that crossed the wire in cleartext, then hash them for analysis in a lab. Never open them on your normal machine.

A worked investigation: one suspicious workstation

Imagine the SOC receives an alert that workstation 192.0.2.50 contacted an address on a threat feed. You pull the capture from the network tap covering that hour. Here is a sensible order of work.

1. Orient. Open Statistics, Conversations and sort by bytes. The workstation sent 40 MB to one external host. That is unusual for an office machine.
2. Filter to that conversation with ip.addr == 192.0.2.50 && ip.addr == 198.51.100.7 and check whether it is TLS. The Client Hello shows a server name that does not match any business service.
3. Look for periodicity. Add the time delta column. Small packets leave every 60 seconds, then one large upload begins. That fits check-ins followed by data transfer.
4. Check DNS before the connection. Filter dns && ip.src == 192.0.2.50 and find the lookup for that server name, and note how recently it was first seen.
5. Pivot to the host. Take the first timestamp and search the workstation’s process creation and logon events around it, which tells you which program made the connection.

The result is a short, factual timeline: first lookup, first connection, regular check-ins, large upload. That is what an incident ticket needs, and every statement in it can be reproduced from the capture.

What about encrypted traffic?

Most traffic today is TLS, so you will not see the content. You can still learn a lot. The TLS Client Hello usually shows the server name the client asked for, the certificate details are visible in older TLS versions, and the sizes and timing of packets show behaviour. Use tls.handshake.type == 1 and add the server name field as a column to see which sites a host contacted. To read the content itself, you need session keys, which a lab setup can export, or an inspection proxy on your own network.

Follow a stream to tell the story

When a packet looks interesting, right-click it and choose Follow, then TCP Stream (or UDP, TLS or HTTP stream). Wireshark reassembles the conversation so you can read it like a transcript. Colour shows direction. Note the timestamp, the hosts and anything that looks like a command, a file name or a user agent. These details become indicators in your report. Our guide to Windows event logs shows how to match a network timestamp with a host event, which is how you prove which process made the connection.

Good habits for packet analysis

• Hash and store the original pcap and work on a copy.
• Use a profile with your columns and colouring rules so every investigation starts the same way.
• Note the time zone. Wireshark shows local time by default, and logs are often in UTC.
• Write down filters and findings as you go. A screenshot of a filter and its result is evidence.
• Check the capture point. A capture on one host misses traffic that never touched it. Part 22 covers Zeek for network-wide visibility.

Keep one more idea in mind as you practise: a capture is a witness, not a judge. It tells you what crossed one point on the network, at one time. It cannot tell you why, and it cannot see what happened inside an encrypted channel or on a different segment. Combine it with endpoint logs, DNS logs and proxy logs, and you will reach conclusions that stand up when someone asks how you know.

Common pitfalls

• Capturing with a filter that excludes the evidence. Capture broadly and filter later.
• Opening a malicious file you exported. Treat every extracted object as hostile.
• Reading single packets instead of patterns. Start with statistics.
• Declaring beaconing from one interval. Confirm with several samples and the destination reputation.
• Ignoring the time zone. A wrong offset can send you to the wrong hour of logs.

Practice ideas

Generate your own traffic in the home lab from Part 10: run a port scan between two VMs, visit a few sites, and run a deliberately noisy script that polls a server every minute. Then find each in the capture. The official Wireshark documentation has the user guide for any feature mentioned here. Once you can find your own traffic quickly, real incidents feel much more approachable.

Frequently asked questions