Wireshark for SOC beginners: the filters you will actually use

Opening a packet capture for the first time is overwhelming: thousands of lines, dozens of protocols, and no obvious place to start. The good news is that a SOC analyst needs only a small part of Wireshark to answer most questions. This guide covers the filters and views that do the heavy lifting, and a routine you can follow on any capture.

Capture filters and display filters are different

Wireshark has two kinds of filters, with different syntax:

• Capture filters decide what gets recorded in the first place. They use the older BPF syntax, such as host 10.0.0.25 and not port 3389, and anything they exclude is gone for good.
• Display filters only hide packets from view in a capture you already have. They use Wireshark's own syntax, such as ip.addr == 10.0.0.25, and can be changed as often as you like.

During an investigation you will almost always work with display filters on an existing file. Capture filters matter when you are recording on a busy link and need to keep the file size manageable. The display filter reference lists every field Wireshark knows.

The filters worth memorizing

Hosts, directions and ports

ip.addr == 10.0.0.25
ip.src == 10.0.0.25 && !(ip.dst == 10.0.0.0/8)
tcp.port == 3389 || tcp.port == 445

The first line shows everything to or from one host. The second keeps only traffic the host sends outside the 10.0.0.0/8 internal range, which is a quick way to see what a suspicious machine talks to on the internet. The third shows Remote Desktop and SMB, two protocols that matter for lateral movement.

DNS

dns && dns.flags.response == 0
dns.qry.name contains "update"

DNS is often the most useful protocol in a capture, because almost every connection starts with a name lookup, and the names are readable even when the traffic that follows is encrypted. The first filter lists only queries; the second finds lookups containing a word, which helps when you are chasing a suspicious domain.

Web traffic and TLS

http.request
http.request.method == "POST"
http.user_agent contains "PowerShell"
tls.handshake.type == 1
tls.handshake.extensions_server_name contains "example"

Plain HTTP requests show the full URL, the method and the user agent; a script downloading files often announces itself in the user agent. For HTTPS, the content is encrypted, but the Client Hello (tls.handshake.type == 1) usually still carries the server name the client asked for, known as SNI. Filtering on it gives you a list of the sites a machine visited even when you cannot read the traffic.

Scans and noise

tcp.flags.syn == 1 && tcp.flags.ack == 0
!(arp || icmp || mdns || ssdp)

The first filter shows connection attempts. One host sending connection attempts to many addresses or ports in a short time is a classic sign of scanning. The second hides background chatter from local discovery protocols so the interesting traffic stands out.

Three views that save time

• Statistics → Conversations lists every pair of hosts with the number of packets and bytes exchanged. Sorting by bytes is the fastest way to spot a large transfer, such as possible data exfiltration.
• Follow → TCP Stream (right-click a packet) rebuilds one connection as a readable conversation, which is ideal for unencrypted protocols such as HTTP, FTP and SMTP.
• File → Export Objects → HTTP extracts files transferred over plain HTTP, so you can calculate their hashes and check them against threat intelligence without opening them.

A short routine for any capture

1. Get the big picture

   Open Statistics → Protocol Hierarchy and Conversations. Note the busiest hosts and anything unexpected, such as a workstation exchanging gigabytes with a single external address.

2. Read the DNS

   Filter on DNS queries and scan the names. Random-looking domains, recently registered domains and very regular repeated lookups deserve a closer look.

3. Look for rhythm

   Select a suspicious destination and look at the timestamps. Connections at a steady interval, day and night, are typical of malware checking in with its command-and-control server.

4. Confirm and pivot

   Follow the interesting streams, export any transferred files, and take the domains, IP addresses and hashes you found back to your SIEM and EDR to see which other machines are involved.

Where Wireshark fits

Wireshark answers detailed questions about a specific moment on the network. It does not replace continuous monitoring: IDS sensors, firewall logs and flow records tell you where to look, and the capture tells you what exactly happened. Practicing on public sample captures, such as those shared by malware analysis communities, is the fastest way to get comfortable before you need it in a real incident.