Your server stopped responding at 3:47 AM. The access log shows a POST request to a page that doesn't exist. The firewall recorded an outbound connection to an IP in a country where you have no clients. Your first instinct is "wipe and rebuild." Wrong. Before you erase everything, you need to answer one question: what exactly happened? That's where network forensics comes in, and Wireshark is the tool we use every day to find the answers.
We, at Meteora Web, have been working on real incidents for years. When a client calls us after an attack, our first question is not "what antivirus do you have?" but "what traffic did you capture?". Network traffic does not lie. Logs can be altered, files deleted, but the packet that passed through the firewall at that exact moment is technical evidence.
This guide is an operational network forensics session with Wireshark: how to capture traffic at the right moment, how to isolate malicious flows, how to extract evidence that stands up in a technical report. No textbook theory. Only procedures that work.
Why Network Forensics Is Different from Traditional Security
Traditional security tries to prevent access. Network forensics assumes the access has already happened and works to reconstruct what occurred after. It is a fundamental mindset shift.
When we analyze malicious traffic, we are not looking for vulnerabilities. We are looking for evidence of lateral movement: who talked to whom, when, on which port, with which payload. A single DNS packet can reveal a C2 command. A well-formed TLS session can hide data exfiltration. An anomalous TCP handshake can indicate a network scan.
The common mistake is to open Wireshark and stare at the packet list without a method. We see everything, we understand nothing. Serious network forensics starts with an operational question: what question do I want to answer? Only then do you choose the filter.
The difference between packet capture and flow data
Before diving into packets, let's understand the raw material. Flow data (e.g. NetFlow, IPFIX) are statistical summaries: source IP, destination IP, ports, protocol, packet count. They help understand "who talked to whom" but say nothing about content. Full packet captures (PCAP) contain the original bytes. They are heavy, but they allow you to reconstruct a session, extract a file, re-read a command.
Sponsored Protocol
In our work, we use both. Flow data for initial analysis, PCAP for the definitive proof. If you only have firewall logs, you can do a preliminary analysis. If you have a PCAP, you can close the case.
Immediate checklist:
- Check if your firewall or router supports NetFlow/IPFIX and enable it, even if you don't think you need it today.
- Configure a SPAN port mirroring on your core switch to capture traffic from a critical segment.
- Set PCAP files rotation: keep at least 7 days, incidents need past data.
How to Capture Traffic the Right Way
Capturing badly is the first step toward a failed analysis. If your interface is in promiscuous mode in the wrong place, you record noise. If the buffer is too small, you lose packets at the worst moment. If you capture on a production server with slow disks, the system collapses under write load.
We use a simple rule: capture as little as possible but in the right spot. For a suspected C2, the right spot is the Default Gateway interface of the compromised segment. For exfiltration, the right spot is the data server interface. You don't need to capture the whole backbone.
BPF capture filters to use right away
Capture filters in Wireshark (BPF, Berkeley Packet Filter) are different from display filters. They apply at the source and let you discard useless packets already during acquisition. Here are the commands we use every day:
# Capture all traffic to and from a suspicious IP
tcpdump -i eth0 -w incident.pcap host 185.220.101.34
# Capture HTTP/HTTPS traffic to a specific network
tcpdump -i eth0 -w webserver.pcap net 10.0.0.0/24 and port 80 or port 443
# Capture DNS traffic (essential to spot C2)
tcpdump -i eth0 -w dns.pcap port 53
# Capture with file rotation, to avoid filling the disk
tcpdump -i eth0 -w capture.pcap -C 100 -W 10 port 80 or port 53The -C option limits each file to 100 MB and -W keeps at most 10 files. It sounds obvious, but we see it often: analysts capturing without limits and filling the disk, losing the evidence. A well-configured capture is a capture that doesn't stop before the incident.
Action to do now: open a shell on your test server and run a capture with tcpdump on port 53 for 30 seconds. Then open the file with Wireshark and see how many DNS queries pass in one minute. That is your baseline noise.
Wireshark for Malicious Traffic Analysis — The Filters That Matter
Wireshark is the standard tool for packet analysis. But using it well means knowing the display filters that separate signal from noise. There is no magic "find attack" button. There is a logical sequence of filters that leads to the evidence.
Sponsored Protocol
When we open a suspicious PCAP, our sequence is always the same: first we look at anomalous protocols, then anomalous connections, then the packet content.
Essential display filters
// Show only traffic between two specific hosts
ip.addr == 10.0.0.10 && ip.addr == 185.220.101.34
// Exclude broadcast and multicast traffic (noise)
!(ip.broadcast) && !(ip.multicast)
// Find DNS requests for suspicious domains (C2)
dns.qry.name contains "\.xyz" || dns.qry.name contains "\.top"
// Identify TCP sessions with few packets but large payloads
tcp.len > 1000
// Search HTTP payloads with typical exploit patterns (eval, base64, cmd)
http.request.uri contains "eval" || http.request.uri contains "base64"
// Show only traffic to non-standard ports
!tcp.port in {80,443,22,53} && tcp.flags.syn == 1The tcp.flags.syn == 1 filter shows only the beginning of TCP connections. It is perfect for spotting vertical network scans (many ports toward a single IP) or horizontal scans (the same port toward many IPs). In seconds you understand if your server is a target or has been turned into a scanner.
Common mistake: analyzing without context. A single packet with a strange payload is not evidence. You must reconstruct the flow: right-click the packet, then Follow, then TCP Stream. There you see the full conversation, and often the evil becomes obvious.
Statistics you never use but should
The Statistics menu in Wireshark is underrated. Three entries in particular save us in real cases:
Endpoints shows the IP addresses with the most traffic. If an IP you don't know has transferred 500 MB, it's a natural suspect. Conversations shows sessions between host pairs. Sort by bytes and see who is talking to whom in an anomalous way. Protocol Hierarchy shows protocol distribution. If you see ICMP bursts, someone is doing ping sweeps or tunneling.
These statistics don't require a powerful PC. They require discipline in observing before filtering. We always open these three views before any manual filter. It is our way to avoid the bias of looking only for what we already suspect.
Action to do now: on your recent test PCAPs, open Statistics → Conversations and sort by bytes. If there is a flow you can't explain, analyze it with Follow TCP Stream. Train yourself to recognize the normal traffic of your environment before a real incident arrives.
Sponsored Protocol
How to Recognize a C2 Flow and Data Exfiltration
The most delicate part of network forensics is distinguishing a false positive from a true indicator of compromise (IoC). We see it every day: a client shows us a foreign IP and asks "is this an attack?". Sometimes yes, often it's a legitimate external service. You need a method.
A C2 flow (Command and Control) has recurring characteristics: periodic connections at regular intervals, payloads of constant size, non-standard protocols on common ports, or DNS queries to recently registered domains. C2 traffic is never random. It follows a rhythm because the malware must receive commands and send state.
To spot C2 in Wireshark:
# Find connections that repeat at regular intervals
# Use the filter for the suspicious server and look at the Time column
ip.addr == 10.0.0.10 && tcp.port == 443Then observe the time delta between timestamps. If you see a packet every exact 60 seconds, it is very likely a beacon. Open the conversation and look at the payload size. If it is always the same, it is an encrypted command or an heartbeat.
Data exfiltration, on the other hand, is an outbound data flow anomalous by volume. The most effective way to see it is again the Conversations statistic, sorted by data transfer. If a host talks to an external IP and the volume is disproportionate to normal activity, you have a suspect. Then look at the payload: if it is encrypted and travels on port 53 to an unauthorized DNS server, you found a tunnel.
The DNS tunnel pattern
The DNS tunnel is the preferred technique to bypass firewalls: malware encodes stolen data in DNS queries to an attacker-controlled domain. In Wireshark it is recognizable because the domain name contains long, random subdomains.
// Filter to find suspicious DNS queries with very long labels
dns.qry.name.len > 50A normal domain example.com rarely has subdomains of 50+ characters. If you see one, it is not a coincidence.
Action to do now: download a public PCAP with C2 traffic from a source like Malware-Traffic-Analysis.net and apply the filters from this section. You don't need to analyze the whole file, just find a beacon. When you find it, describe it in words: source IP, destination IP, port, interval, payload size. That is the basis of your next report.
Sponsored Protocol
How to Extract Evidence and Write a Forensic Report
Network forensics does not end with analysis. It ends when you produce usable evidence. Whether you need to hand it to an external consultant, your management, or an authority, the PCAP file alone is not enough. You need a report that explains what you found, why it is malicious, and how you discovered it.
Good network forensic reports follow a simple structure: context, methodology, evidence, conclusions. Context: what happened, when, on which system. Methodology: which tools and filters you used. Evidence: screenshots of packets, payload extraction, file hashes. Conclusions: what the evidence indicates and the next actions.
A tool we often use to extract files from PCAPs is foremost. When an attacker transfers a payload over HTTP, the file can be recovered and analyzed in isolation.
# Extract files from PCAP
foremost -i incident.pcap -o extraction/
# Or use tcpdump to extract the payload of a single session
tcpdump -r incident.pcap -A -c 50 'host 185.220.101.34 and tcp port 80'Evidence must be preserved intact: a read-only copy of the file, the SHA-256 hash calculated and recorded, and the chain of custody documented. If the file is used in a legal proceeding, integrity is everything.
Action to do now: take a screenshot of the malicious conversation you found in the previous section, export the relevant packets with File → Export Specified Packets, and calculate the SHA-256 hash of the original PCAP file. These three actions produce a minimal but professional evidence set.
Network Forensics and Incident Response — What Is Their Role?
You might ask: where does network forensics fit into an incident response plan? The answer is: immediately after detection and before eradication. The worst mistakes we see in SMBs are two: restoring the system before analyzing the traffic, and discarding the PCAPs of an incident to free up space. Both erase the only available evidence.
In our approach, network forensics is the bridge between detection and response. It tells you who entered, how they entered, what they touched, and where other backdoors might exist. Skipping this step means patching one hole without knowing if there are other open doors. On our path of incident response and digital forensics, network forensics is one of the pillars for building a defense that holds.
Sponsored Protocol
The advice we give every client is simple: prepare the capture before the incident. Having a packet capture system always active on critical partitions gives you the visibility that no log can provide. The storage cost of 7 days of traffic is negligible compared to the cost of an unanalyzed incident.
Tools Complementary to Wireshark
Wireshark is powerful, but alone it is not enough. In complex cases we use complementary tools to automate analysis or handle huge volumes of traffic.
tshark is the command-line version of Wireshark. It lets you extract specific fields from large PCAPs and create a CSV summary for subsequent correlations. A command we often use to track suspicious flows:
# List of all TCP conversations with sizes
tshark -r incident.pcap -q -z conv,tcpZeek (formerly Bro) turns traffic into structured logs: connections, DNS, HTTP, TLS. It is a passive IDS and is excellent for large-scale analysis. Zeek logs correlate easily with Wireshark data.
NetworkMiner is another utility we love for its ability to reassemble flows and display transferred files with a simple interface. It is useful when the client is not technical and wants to see clearly.
Action to do now: install tshark and reproduce the conversation analysis you did with Wireshark, but from the terminal. Familiarity with tshark will make you faster on large volumes, where the GUI is not practical.
What to do now
Don't wait for an incident to prepare. Network forensics is trained on normal traffic before it is ever used on malicious traffic. These are the first three actions you would take if you were in our shoes:
- Configure continuous capture on the main gateway with daily rotation. If you don't have it yet, start with a 7-day history. It will pay for itself at the first attack.
- Practice on public PCAPs of malicious traffic. Learn to recognize the beacon pattern and the DNS tunnel signature. Analysis speed comes with repetition.
- Define your evidence delivery process. After each analysis, hash the PCAP file, save screenshots of suspicious flows, and write a one-page report. You'll see that when it really matters, you'll already have the method.
Network traffic does not lie. It is up to you to listen.
