Wireshark for Threat Detection: A Practical Guide for 2026

A user reports their machine is slow. CPU is fine. RAM is fine. Someone opens Wireshark — and finds the machine has been sending 2 GB per hour to an IP in Eastern Europe for three days. The network card was struggling under the load. Nobody had looked at the network.

This guide walks through exactly how that investigation unfolds, and then goes further: how to find the threats that are specifically designed to look like normal traffic in 2026.

TL;DR

Over 95% of traffic is TLS-encrypted — but the handshake metadata still exposes attackers

JA3 fingerprints, certificate anomalies, and SNI mismatches identify malware without decrypting a single byte

Ransomware, C2 beaconing, and DNS tunneling each leave distinct network signatures

SMB flood patterns reveal ransomware propagation before files are encrypted

tshark outputs JSON that feeds directly into Wazuh, Elastic, or Splunk for automated detection

The Problem With Hunting Threats in 2026

A few years ago, packet analysis meant reading traffic. You could see HTTP requests, FTP passwords, and SMTP headers in plaintext. Today, over 95% of internet traffic is TLS 1.3 encrypted, and that number keeps rising.

This has created a dangerous misconception: that packet analysis is no longer useful because “everything is encrypted.”

The reality is different. The TLS handshake — the negotiation that happens before any encrypted data flows — is visible in plaintext and contains enough information to fingerprint the software making the connection, identify self-signed certificates typical of malware infrastructure, and detect protocol abuse. Beyond that, timing patterns, traffic volume, and behavioral anomalies don’t require decryption at all.

The threat hunter’s job has shifted from reading content to reading context. This guide focuses on exactly that.

Walkthrough: Investigating the Slow Machine

Let’s work through the opening scenario step by step. A user reports sluggishness. CPU and RAM are normal. You open Wireshark on a network tap or the affected machine itself and start a capture.

Step 1: Find the Top Talkers

After 60 seconds, stop the capture and go to:

Statistics → Endpoints → IPv4

Sort by Bytes (descending). This shows every IP the machine communicated with, ranked by data volume. If one external IP shows gigabytes while everything else shows megabytes, that’s your lead.

You’re looking for an asymmetry that doesn’t fit the machine’s role. A developer’s workstation sending 1.8 GB to a single external IP is not normal browsing.

Step 2: Isolate and Examine the Connection

Apply a display filter to focus on just that IP:

ip.addr == 185.220.101.47

Now check:

Port — Port 443 is the most common choice for attackers because HTTPS traffic on 443 is expected and rarely inspected. Traffic on unusual ports (4444, 8443, 9001) is a stronger signal.
Protocol label — If Wireshark shows TCP instead of a named protocol, it couldn’t identify the application layer. This happens with custom protocols, non-standard port usage, or encrypted tunnels.
Direction — Is data mostly flowing outbound? Exfiltration is outbound by nature.

Step 3: Examine the TLS Handshake

Right-click a packet in the stream → Follow → TLS Stream

You won’t see decrypted content — but you’ll see the handshake. Expand Transport Layer Security in the packet details and look at the Certificate message. Ask:

Who issued this certificate? Legitimate services use certificates from trusted CAs. A self-signed certificate, or one issued by an unknown CA, is a red flag.
What is the Common Name (CN)? Generic values like localhost, mail.ru, or a random string are common in auto-generated malware C2 certificates.
When was it issued? A certificate created yesterday for an external IP you’ve never seen before is suspicious.

Step 4: Check the Timing Pattern

Go to Statistics → I/O Graph.

This charts traffic volume over time. The shape of the graph often reveals the nature of the threat before you’ve decoded anything:

Flat elevated line — continuous exfiltration
Regular spikes at fixed intervals — automated C2 beaconing (e.g., checking in every 60 seconds)
Irregular bursts — a human operator on the other end

Beaconing is one of the clearest network signatures of a compromised machine, and the I/O Graph makes it immediately visible.

Step 5: Find the DNS Resolution

Filter for DNS traffic immediately before the connection started:

dns && frame.time_relative < 5

Malware resolves a domain name before connecting. A DNS query to an unusual domain a few seconds before the suspicious connection started gives you the C2 domain — far more useful for threat intelligence and blocking than an IP address that can rotate within hours.

Reading Encrypted Traffic Without Decrypting It

JA3 Fingerprinting

Every TLS connection starts with a ClientHello — a message where the client announces which TLS versions, cipher suites, and extensions it supports. Different software sends different combinations. JA3 hashes these fields into a 32-character fingerprint.

The key insight: the same malware always sends the same JA3 hash, regardless of what domain it’s connecting to or what IP it uses. Cobalt Strike, Metasploit, njRAT, and many other tools have well-documented JA3 fingerprints published in threat intelligence feeds.

In Wireshark, open any TLS ClientHello packet and look under:

Transport Layer Security → TLS 1.3 Record Layer → Handshake Protocol: Client Hello

The cipher suites and extensions listed here are what gets hashed. To cross-reference against known-malicious fingerprints, export the values and check against sslbl.abuse.ch.

To filter all TLS ClientHello packets — the starting point for any TLS investigation:

tls.handshake.type == 1

type == 1 means ClientHello. Every TLS session starts with one. Reviewing these across a capture gives you a complete picture of every encrypted outbound connection a machine initiated.

SNI: The Hostname Hidden in Plain Sight

Even in fully encrypted HTTPS traffic, the Server Name Indication (SNI) field in the ClientHello is transmitted in plaintext. SNI is the hostname the client wants to reach — it exists so that servers can serve multiple domains from the same IP.

This means you can see exactly which domain every machine is connecting to, even over HTTPS, without decryption:

tls.handshake.extensions_server_name

Add this as a column in Wireshark (right-click the field → Apply as Column) and you get a readable list of every HTTPS destination in your capture. Cross-reference against your DNS logs — if a machine is connecting to an HTTPS host it never resolved via DNS first, that’s a strong anomaly.

Certificate Anomalies

The server’s certificate is transmitted during the TLS handshake and visible without decryption. Filtering for Certificate messages:

tls.handshake.type == 11

Expand the certificate details and look for:

Field	What’s suspicious
Issuer	Self-signed (issuer == subject), or unknown CA
Validity period	Very short (days) or suspiciously round (exactly 1 year)
Subject CN/SAN	Generic values, random strings, IP addresses
Certificate age	Issued within the last 24–48 hours
Key size	512-bit or 1024-bit RSA (outdated, common in automated cert generation)

Legitimate enterprise services don’t use self-signed certificates for external endpoints. Finding one is an immediate investigation trigger.

Domain Fronting: When the SNI Lies

Domain fronting is a technique where malware connects to a legitimate CDN — Cloudflare, Azure CDN, AWS CloudFront — and the actual C2 communication is routed to an attacker-controlled backend. The SNI shows a trusted domain; the real destination is hidden.

The detection: the SNI hostname in the ClientHello doesn’t match the Common Name in the server’s certificate.

tls.handshake.type == 1 || tls.handshake.type == 11

Filter for ClientHello and Certificate messages, then compare the SNI extension value with the certificate CN. A mismatch — especially when the certificate CN is obscure and the SNI is a well-known CDN domain — is a domain fronting indicator.

Protocol-Level Threat Hunting

DNS: Every Attack Leaves Footprints Here

DNS is the first step in nearly every network-based attack. Before any connection is made, the attacker’s domain gets resolved. This makes DNS the richest single data source for threat hunters.

What normal looks like: A workstation makes a few hundred DNS queries per hour — Microsoft, Google, your SaaS tools, update servers.

What to hunt for:

High-entropy domain names are a sign of domain generation algorithms (DGA) — malware that generates new C2 domains algorithmically to avoid blocklists:

dns.qry.name matches "[a-z0-9]{12,}\.(com|net|org)"

This matches domain names with 12+ random-looking characters — typical DGA output.

DNS TXT record queries are rare in normal traffic. They’re the primary carrier in DNS tunneling (tools like dnscat2 and iodine encode data in TXT responses):

dns.qry.type == 16

Subdomains that are unusually long are another tunneling indicator — the data is encoded in the subdomain itself:

dns.qry.name matches "^.{40,}\."

Any subdomain longer than 40 characters deserves a look.

NXDOMAIN floods indicate a machine trying to reach dead C2 infrastructure — it’s cycling through DGA domains until one resolves:

dns.flags.rcode == 3

rcode == 3 is NXDOMAIN. A machine generating dozens of NXDOMAIN responses in a short period is likely running malware with a DGA.

SMB: Ransomware Before the Damage Is Done

SMB (port 445) is where you can catch ransomware while it’s spreading — before files are encrypted. The network signature is distinctive: one compromised host begins touching every other host on the subnet via SMB.

A flood of SMB Negotiate requests to many different internal IPs is lateral scanning — the malware probing for accessible shares:

smb2.cmd == 0 && ip.dst != 192.168.1.10

Adjust the exclusion to your known file server IP. Any machine initiating SMB Negotiate to hosts that aren’t file servers is scanning.

Once ransomware finds an accessible share and authenticates, it begins opening and writing files at high speed. This creates a burst of SMB2 Create requests:

smb2.cmd == 5 && smb2.filename contains "."

During active encryption, you’ll see hundreds of these per second from the infected host, targeting files across the share. The pattern is unmistakable.

Authentication failures followed by success reveal credential abuse:

ntlmssp.auth.username && smb2

This shows every account authenticating over SMB in the capture. If a service account you recognize is suddenly authenticating to 15 different hosts in 30 seconds, it’s being used for lateral movement.

ICMP: Small Protocol, Covert Use

Normal ICMP ping packets have payloads of 32–64 bytes. ICMP tunneling tools stuff data into the payload, creating abnormally large packets:

icmp && data.len > 100

More specific: standard Windows ping uses exactly 32 bytes. Linux uses 48 bytes. Anything larger is non-standard and warrants inspection.

Detecting C2 Beaconing

Automated C2 beaconing — where malware checks in with its server on a regular schedule — is one of the most reliable network indicators of compromise. The challenge is distinguishing it from legitimate periodic traffic (browser telemetry, update checkers, NTP).

The distinguishing features of malicious beaconing:

Precise intervals — legitimate software has timing jitter. Malware beacon intervals are often exact to within milliseconds.
Small, consistent payload sizes — a C2 check-in transfers a small, predictable amount of data each time.
External destination — beaconing to an internal IP is unlikely to be malware.
No DNS resolution before connection — the IP was either hardcoded or cached from an earlier resolution.

To investigate: use Statistics → Conversations, sort by Packets, and look at connections with many packets but small byte counts to external IPs. Then select one and open Follow → TCP Stream to see the actual payload size pattern.

For a quick visual: Statistics → I/O Graph with a 1-second interval shows the regularity of connections as a heartbeat-like pattern.

tshark: Automation and SIEM Integration

For continuous monitoring and pipeline integration, tshark — Wireshark’s command-line engine — brings the same analysis to headless servers and automated workflows.

The key capability for modern SOC environments is structured JSON output:

# Ship TLS handshake metadata to SIEM in real time
tshark -i eth0 \
  -Y 'tls.handshake.type == 1 || dns' \
  -T json \
  -e frame.time_epoch \
  -e ip.src -e ip.dst \
  -e dns.qry.name \
  -e tls.handshake.extensions_server_name \
  -e tls.handshake.ciphersuite \
  -l | filebeat -e -c /etc/filebeat/filebeat.yml

Breaking this down:

-Y 'tls.handshake.type == 1 || dns' — capture only TLS ClientHellos and DNS queries, ignoring bulk data traffic
-T json — structured output, one JSON object per packet
-e frame.time_epoch — Unix timestamp, easier to parse than human-readable format
-e tls.handshake.extensions_server_name — the SNI hostname from every HTTPS connection
-l — flush after each packet so the pipe to Filebeat is continuous rather than buffered

Once this data lands in your SIEM, you can correlate SNI hostnames against threat intel feeds, alert on known-bad JA3 cipher suite combinations, and build dashboards for encrypted traffic anomalies — all without deploying a dedicated NDR solution.

What You Can Do Today

Capture 10 minutes of normal traffic on a workstation and review Endpoints → IPv4. Build a mental model of what your environment looks like when nothing is wrong. Anomaly detection starts with knowing normal.
Add SNI as a Wireshark column. Filter for tls.handshake.type == 1, right-click tls.handshake.extensions_server_name → Apply as Column. Now every HTTPS connection shows its destination hostname. Do this once and leave it configured.
Check your network for self-signed certificates. Filter tls.handshake.type == 11 in a capture, expand the certificate details, and look at the Issuer field. Any self-signed certificate on an external connection is an immediate investigation priority.
Run the DNS TXT filter on a production capture. dns.qry.type == 16 should return almost nothing. If it returns anything at all, investigate those domains.
Set up tshark on a network tap or span port. Even a Raspberry Pi with tshark running and logging to a file gives you forensic evidence for the next incident. Capturing DNS and TLS ClientHellos costs almost nothing in storage and provides enormous investigative value.

DFIR: Incident Response Complete Guide 2026 — Packet captures are a primary evidence source in IR — this guide covers the full investigation process
Cobalt Strike Detection and Hunting — Cobalt Strike has distinctive JA3 fingerprints and beacon patterns visible in Wireshark
Threat Hunting with Wazuh — How to feed tshark JSON into Wazuh for automated network-level detection
NTLM Relay Attack: Detect and Defend 2026 — SMB traffic analysis in action for detecting NTLM relay attacks