Wireshark for Beginners: How to Investigate Suspicious Network Traffic Like a Pro

Suspicious network traffic usually isn’t “mystical”—it’s just packets. The pro move is knowing where to look in Wireshark and how to turn raw traffic into a clear timeline of what happened.

In this Wireshark for beginners guide, I’ll show you exactly how to investigate suspicious network traffic like a pro: from setting up capture safely, to using smart display filters, to building a timeline with protocols and endpoints. I’m going to be direct with the practical steps I use in real investigations, including the mistakes that waste hours.

By the end, you’ll be able to answer questions like: “Is this scan?” “Is this malware beacons?” “Why is my laptop making strange outbound connections?” and you’ll know what evidence to collect for escalation.

Why Wireshark is the fastest way to investigate suspicious traffic

Wireshark is a packet analyzer, meaning it lets you inspect network traffic at the protocol level—TCP, UDP, DNS, TLS handshakes, HTTP requests, and more. That’s the difference between vague “something seems off” and a concrete answer.

When I first started using Wireshark in incident response-style troubleshooting, the biggest surprise was how often the story is already in the first 2–5 minutes of a capture: repeated DNS queries, a burst of SYN packets, odd TLS SNI values, or a device that’s trying to phone home every 30 seconds.

Definition check: Suspicious network traffic refers to traffic patterns that deviate from your expected behavior—unusual destinations, abnormal ports, repetitive connections, failed logins, or unexpected protocols like SMB or SSH from endpoints that shouldn’t use them.

What you need before you start (and what most beginners do wrong)

Your results in Wireshark depend as much on capture setup as on filters. The fastest way to avoid confusion is to capture the right thing at the right time.

1) Choose the right capture point

On a typical home network, you usually can’t passively see traffic from other devices without additional setup. On a managed switch, you can use SPAN/mirroring to copy traffic to your capture host. On a laptop, you can capture only what your machine sees.

In corporate environments (and in many security labs), you’ll often mirror a port to a dedicated analysis machine. This is what makes Wireshark useful for “enterprise-grade” investigations.

2) Start with a short capture window

Capture for 60–180 seconds when you reproduce the suspected behavior. Beginners often capture for hours, then get overwhelmed by noise and irrelevant background traffic.

One trick I rely on: start capture, trigger the suspicious action (open a suspicious website, plug in a device, run an app), wait 1–2 minutes, then stop the capture. Repeat if needed and compare.

3) Set a baseline expectation

Before you label traffic “malicious,” get a baseline. For example, you can record normal DNS activity for your device over a day, then compare the next capture to what you expect.

Even a simple baseline helps: common destination categories (CDN providers, OS update servers), your typical DNS latency, and your normal outbound ports.

4) Don’t trust “volume” alone

Low-volume traffic can be the most dangerous. A malware beacon might send tiny HTTPS requests every 30 seconds. Conversely, high-volume traffic might be benign streaming or backups.

Use patterns, not just quantity—frequency, destination novelty, protocol misuse, and errors matter.

Wireshark basics you must master (so filters actually work)

Wireshark’s learning curve is mostly about display filters, follow streams, and reading protocol fields. Once you can do those three things, you’re already operating above beginner level.

Understand display filters vs capture filters

A capture filter decides what gets recorded; a display filter decides what you see after the capture. Display filters are more flexible, so start there once your capture window is correct.

In practice: I use capture filters only when I’m fighting performance issues, like huge captures on busy links.

Essential Wireshark toolbar actions

• Stop the capture at a predictable moment so you can correlate packets to events.
• Use the search bar for quick endpoint hunting (IP or hostname).
• Right-click > Follow > TCP Stream to reconstruct conversations.
• Right-click > Follow > UDP Stream for DNS, QUIC/UDP-based protocols (when visible), or app traffic.
• Right-click > Follow > TLS Stream (where available) to review handshake and SNI-related data.

Know what “Expert Info” is telling you

Wireshark includes an “Expert Information” view that highlights anomalies: retransmissions, malformed packets, checksum issues, and protocol errors. It’s not perfect, but it’s a fast triage tool.

When I’m teaching teams, I tell them to scan Expert Info before deep-diving. It often points directly at the “weird packets” that should get your attention.

How to investigate suspicious network traffic step-by-step

Here’s the investigation workflow I use when something looks wrong. It’s designed to reduce randomness: you’ll confirm what happened, who did it, and what evidence supports your conclusion.

Step 1: Identify the endpoint and timeline

Start by looking at the conversation list and the “top talkers.” In the packet list, click a source IP and scan for repeated outbound behavior.

Then check timestamps closely. Suspicious traffic often clusters around an event: malware launch, device reconnect, user login, or a network change.

• Look for repeated connections to new or rare destinations.
• Watch for bursts of failed attempts followed by success or a redirect.
• Note unusual ports: 4444, 3389/RDP from a machine that shouldn’t use it, 22/SSH to random IPs, or high ephemeral ports paired with scanning behavior.

Step 2: Use DNS filters to catch recon and command-and-control

DNS is where attackers often announce themselves. Even when payloads are encrypted, DNS queries can show hostnames, domains, and timing patterns.

Try these display filters:

• dns – show all DNS traffic
• dns.qry.name contains "doubleclick" (swap with a suspicious keyword) – find domains of interest
• dns.flags.rcode != 0 – errors (NXDOMAIN, SERVFAIL)
• dns.qry.name matches ".*[0-9]{2,}.*" – crude heuristic for random-looking names (use carefully)

What I look for: a device generating many NXDOMAIN responses, periodic queries, or domains with random-looking labels. In a 2026 real-world scenario I handled, a laptop made short DNS queries every 25–35 seconds to an otherwise rarely-used subdomain; the actual HTTPS payloads were encrypted, but the DNS rhythm was the smoking gun.

Step 3: Spot scanning with TCP flags and connection patterns

Scanning traffic often shows SYN bursts, many “half-open” attempts, and repeated connections to many IPs on a small set of ports.

Use these filters:

• tcp.flags.syn == 1 and tcp.flags.ack == 0 – likely connection attempts without completion
• tcp.flags.reset == 1 – resets (often indicates probing or refused ports)
• tcp.analysis.retransmission – retransmissions (can be either bad networks or suspicious reliability tricks)
• tcp.port == 445 or tcp.port == 139 – SMB probing (environment-dependent)
• tcp.port == 3389 – RDP attempts (common for brute force)

My rule: if a single endpoint tries many destinations within a short window on sensitive ports, treat it as suspicious until proven otherwise.

Step 4: Inspect HTTP and headers when available

If your traffic includes HTTP (plain) or older enterprise endpoints that still use HTTP, you can see paths, user agents, and sometimes session tokens.

Use filters:

• http – all HTTP
• http.request.method == "POST" – data submissions
• http.host – host header field (use in search)

Most modern malware prefers HTTPS, so don’t be shocked if HTTP is minimal. That’s normal in 2026.

Step 5: Analyze TLS handshakes and SNI (where possible)

TLS is encryption, but the handshake still leaks useful metadata. Server Name Indication (SNI) is often visible unless privacy features are used in a way that hides it.

Use filters and fields:

• tls.handshake – TLS-related packets
• tls.record.content_type == 22 – TLS handshake records (context dependent)
• In the packet details, check Server Name / SNI

What you’re hunting: unknown domains, suspicious certificate patterns, frequent reconnects to the same host, and abnormal handshake failures.

Step 6: Build a mini “case report” from Wireshark evidence

Before you escalate to security or wipe/reimage anything, write down what you saw. You’re not writing a novel; you’re collecting proof.

• Time window: e.g., 14:02:10–14:05:40 local time
• Suspected source IP: your endpoint’s IP
• Observed indicators: DNS NXDOMAIN bursts, TLS to rare domain, repeated SYN attempts
• Top destination IPs/domains
• Protocol summary: DNS + HTTPS beaconing every ~30 seconds, etc.

This approach saves you when you report findings to an IT admin or security team. They can trace the same timeline in logs, EDR alerts, proxy logs, and SIEM dashboards.

People Also Ask: Wireshark questions beginners ask (answered clearly)

What is the best Wireshark filter for suspicious network traffic?

The best starting filter is usually not one filter but a sequence. If you want a “fast triage” option, start with dns to reveal domain behavior, then pivot to tcp.flags.syn == 1 and tcp.flags.ack == 0 to look for scanning.

From there, use tls.handshake to map which domains are being contacted and how often. This triage path matches how attackers behave: recon (DNS), intrusion attempts (TCP flags), and command-and-control (TLS/HTTPS).

Can Wireshark detect malware by itself?

Wireshark can’t “diagnose” malware reliably by itself. It’s a visibility tool, not an antivirus. What it does well is show the network behaviors that malware and attackers produce.

When I evaluate suspicious traffic, I treat Wireshark as evidence for correlation with EDR detections, endpoint logs, Windows Event Viewer, and browser/proxy history. The network packets often explain why an alert fired, even if the malware payload is encrypted.

Why can’t I see the contents of HTTPS traffic in Wireshark?

HTTPS encrypts application data, so you usually won’t see payload content unless decryption keys are available or you capture in a way that allows it. You may still see handshake metadata like SNI, certificate details, and timing.

If you control the environment, you can configure TLS key logging (commonly used in testing) to decrypt traffic for legitimate analysis. For production investigations, follow your organization’s security and privacy policies.

Is it safe to run Wireshark on a production network?

It can be safe, but you have to do it responsibly. Promiscuous mode, heavy capture, and oversize captures can increase load. Use short capture windows and consider SPAN/mirroring best practices rather than forcing captures on critical servers.

As of 2026, many organizations require approvals and defined capture scopes for compliance reasons. If you’re in a regulated environment, get sign-off before capturing sensitive traffic.

Real-world scenarios: what suspicious traffic looks like in Wireshark

It’s easier to recognize malicious patterns when you’ve seen them before. Here are three scenarios that map to common real incidents.

Scenario A: “My laptop connects to random domains every 30 seconds”

In cases like this, the traffic pattern usually looks periodic: DNS queries followed by TLS connections. Malware beaconing often uses a tight cadence to poll for commands.

What to do in Wireshark:

1. Filter dns and check whether queries repeat with the same domain labels.
2. Filter tls.handshake and compare destination hosts over time.
3. Use “Follow TLS stream” (when available) to see handshake behavior and certificate info.

Original insight: the periodicity is often more important than the domain reputation. Attackers frequently rotate infrastructure, so the “badness” may move, but the calling rhythm stays consistent.

Scenario B: “The router shows lots of scans”

Scanning tends to generate many SYN attempts to many addresses, often targeting common ports. Even if the source is NATed, you can often isolate which internal endpoint is producing the scan.

What to do in Wireshark:

• Filter tcp.flags.syn == 1 and tcp.flags.ack == 0
• Sort by source IP, then narrow to the busiest source
• Look for port concentration: 23 (Telnet), 22 (SSH), 445 (SMB), 3389 (RDP)

When I investigate in a mixed environment, I also check whether the scan occurs after a device reconnects to Wi-Fi. That timing correlation helps pinpoint misconfigured software or compromised IoT devices.

Scenario C: “A user clicked something and now traffic is weird”

Post-click malicious behavior usually starts right away: DNS lookups for newly contacted domains, TLS handshakes to unknown servers, and possibly HTTP redirects.

What to do in Wireshark:

1. Capture around the click time (within a 1–2 minute window).
2. Filter dns.flags.rcode != 0 to see whether the browser tried resolving lots of suspicious domains.
3. Follow TCP/TLS conversations to confirm the destination and sequence.
4. Cross-check with browser history and your proxy logs.

If you can’t correlate the exact time window, your conclusions get fuzzy fast. Short captures beat long captures every time.

Wireshark vs other tools: when you should combine approaches

Wireshark is great for analysis, but it doesn’t replace endpoint security tools. I like combining it with complementary tools so you don’t get stuck at packet-level ambiguity.

Pros of using Wireshark: you get “truth-level” protocol evidence. Cons: it’s manual, and it can’t identify the application process unless you also have endpoint telemetry.

If you want the operational angle, check your own blog cluster for related articles on detecting malware using network telemetry and setting up a basic IDS on a home or small business network.

Wireshark power moves that make you look like a pro

These techniques are what separate “I looked at packets” from “I investigated like a pro.”

Use a “suspect IP list” workflow

When you find one odd destination (like a domain-to-IP mapping), immediately search for it across the capture. That turns your investigation from reactive to systematic.

Example workflow:

• Find a suspicious IP in one packet
• Search for it using the filter: ip.addr == 203.0.113.50
• Check whether multiple protocols are involved (DNS + TLS + possibly SMB)

Compare “before and after” captures

Take two short captures: one right before the suspected action, and one right after. Differences are often obvious: new destinations, new ports, or new periodicity.

This is an underrated pro technique because it reduces your cognitive load. You don’t have to interpret everything—just the delta.

Export only the evidence you need

Instead of sharing a massive PCAP, export a filtered PCAP or save a “conversation” so others can validate your findings. I often export a small capture containing DNS + TLS for the suspicious period.

In real incident handling, that’s the difference between a quick review and weeks of “what is in this file?”

Know when Wireshark limitations apply

If the network uses encrypted DNS (DoH) or you’re analyzing only encrypted metadata with limited capture access, you’ll see less. That doesn’t mean the investigation is impossible; it means you adjust expectations and rely more on handshake metadata, traffic timing, and endpoint logs.

Another limitation: if you can’t map the traffic to a local process, you’ll need endpoint telemetry (Sysmon, EDR, or OS logs) to connect dots confidently.

Actionable checklist: investigate suspicious network traffic today

Use this checklist like a field guide. If you do these steps in order, you’ll produce a high-quality investigation in under an hour in most cases.

1. Capture correctly: short window (60–180 seconds) and start capture before triggering the suspicious behavior.
2. Pick the endpoint: identify the source IP that initiates unusual connections or recon.
3. Inspect DNS: run dns and look for NXDOMAIN bursts, repeated queries, and random-looking subdomains.
4. Check scanning: run tcp.flags.syn == 1 and tcp.flags.ack == 0 and review sensitive ports.
5. Review TLS handshakes: run tls.handshake and list SNI/certificate details for unknown domains.
6. Follow conversations: right-click and follow the TCP/TLS stream for the top suspicious destination.
7. Write down evidence: time window, source endpoint, top destinations, and protocol summary.

If you need operational context about how this fits into broader security practices, you can also align your approach with our incident response network investigation workflow guide.

Conclusion: Turn packet data into a clear security answer

Wireshark for beginners isn’t about memorizing every protocol field. It’s about building a repeatable investigation path: capture smart, filter with intent, analyze DNS/TCP/TLS patterns, and collect evidence you can correlate with endpoint logs.

My actionable takeaway for you: run two short captures (before/after), start with DNS, then pivot to TCP SYN patterns and TLS handshakes. That sequence consistently reveals the “what” and “when,” which is what you need to act—whether that means blocking a destination, investigating an endpoint, or escalating with proof.

Do that next time something feels off on your network, and you’ll stop guessing. You’ll be investigating like a pro.

Featured image alt text suggestion: “Wireshark for beginners analyzing suspicious network traffic with DNS and TLS filters”