Wireshark
Open-source network protocol analyzer for capturing and inspecting packet-level traffic across hundreds of protocols.
Continue your mission
Open-source network protocol analyzer for capturing and inspecting packet-level traffic across hundreds of protocols.
# Wireshark
Wireshark is the world's most widely deployed open-source network protocol analyzer. It exists because network problems, whether caused by misconfiguration, software bugs, or deliberate attacks, leave evidence at the packet level that no higher-level tool can fully expose. Operating system logs record events; endpoint agents report behaviors; but only a packet capture shows exactly what bytes traveled between two hosts, in what order, and when. Wireshark solves the visibility problem by giving any analyst with network access the ability to capture, decode, and interrogate raw traffic without specialized hardware or licensing fees. That combination of depth, breadth, and accessibility has made it the de facto standard for protocol analysis across network engineering, software development, and security operations.
---
Wireshark is a graphical network protocol analyzer that captures packets from live network interfaces or reads previously saved capture files (typically in PCAP or PCAPng format) and decodes them across hundreds of recognized protocols. It was originally released in 1998 under the name Ethereal by Gerald Combs and was renamed Wireshark in 2006 following a change in Combs's employer. It is maintained by a global community of contributors and licensed under the GNU General Public License version 2.
Wireshark is not a network scanner. It does not actively probe hosts or enumerate services the way Nmap does. It is not an intrusion detection system; it does not generate alerts based on signatures or behavioral rules the way Suricata or Snort does. It is not a proxy or a man-in-the-middle tool; it reads traffic that passes through or originates from the host on which it runs, or traffic mirrored to that host via a SPAN port or network tap.
Wireshark is also not a full packet-capture platform in the enterprise sense. Tools like Zeek, NetworkMiner, or commercial solutions such as ExtraHop or Gigamon are designed for continuous, high-throughput capture and long-term storage across a distributed environment. Wireshark excels at interactive, analyst-driven inspection of specific sessions or time windows.
Variants and related forms include tshark, the command-line version of Wireshark that supports the same dissectors and filter syntax but is suited for scripted analysis and remote capture over SSH; editcap, which trims and converts capture files; and mergecap, which combines multiple captures into a single file. On Windows, Wireshark depends on Npcap for packet capture; on Linux and macOS it depends on libpcap. The PCAPng format, which Wireshark helped popularize, adds metadata, multiple interface support, and comment annotations to the older PCAP standard.
---
Wireshark operates through four sequential stages: capture, dissection, filtering, and display. Understanding each stage is necessary for using the tool correctly and for understanding its limitations.
Capture: When a user starts a capture, Wireshark instructs the operating system's packet capture library (libpcap on Linux and macOS, Npcap on Windows) to place a specified network interface into promiscuous mode. In promiscuous mode, the interface accepts all frames that arrive on the wire or wireless medium, not only those addressed to its own MAC address. For wireless captures, monitor mode (distinct from promiscuous mode) is required to see frames from other stations; this requires a compatible wireless adapter and drivers. Wireshark can also read from a SPAN port or a hardware tap placed inline on a network segment, which is the standard method for capturing traffic that does not pass through the analyst's host.
Capture filters, written in Berkeley Packet Filter (BPF) syntax, are applied at the kernel level before any packet reaches Wireshark's process. A capture filter such as host 10.1.1.50 and port 443 instructs the kernel to discard all other traffic, reducing both storage consumption and processing overhead. This matters on high-throughput links where capturing everything would quickly exhaust disk space or overwhelm memory.
Dissection: Once packets are captured, Wireshark's dissector engine decodes them layer by layer. A dissector is a module that understands the binary structure of a specific protocol. Wireshark ships with dissectors for more than 3,000 protocols including Ethernet, IP, TCP, UDP, ICMP, DNS, HTTP, TLS, SMB, Kerberos, RTP, and many industrial control system protocols such as Modbus and DNP3. Dissectors are chained: the Ethernet dissector identifies the EtherType, hands off to the IP dissector, which reads the protocol field and hands off to TCP or UDP, which in turn hands off to the application-layer dissector based on the port number or heuristic detection. Each dissector populates a tree of named fields that analysts can reference in filters and in the packet detail pane.
For TLS-encrypted traffic, Wireshark can decrypt sessions if the analyst provides a pre-master secret log file (generated by configuring a browser or application to export key material via the SSLKEYLOGFILE environment variable) or, in older RSA key exchange configurations, the server's private key. This is critical for analyzing HTTPS, encrypted SMB, or other TLS-wrapped protocols during incident response on internal systems where the analyst controls the endpoint.
Filtering: Display filters, applied after capture, use Wireshark's own filter syntax and reference dissector field names directly. A filter such as http.request.method == "POST" and ip.dst == 192.168.1.10 isolates all HTTP POST requests to a specific host. Display filters do not discard packets; they hide non-matching packets from view while leaving the full capture intact. This distinction matters during investigations: an analyst can flip between views without recapturing.
Display and Analysis: The main interface presents three panes. The packet list pane shows one row per packet with timestamp, source, destination, protocol, length, and a summary. The packet detail pane shows the full dissector tree for the selected packet, expandable to the byte level. The packet bytes pane shows the raw hexadecimal and ASCII representation of the packet, with fields highlighted as the analyst navigates the detail tree.
Practical example: during an incident response engagement, an analyst suspects DNS tunneling by a compromised workstation. The analyst applies the display filter dns and ip.src == 10.5.2.88 and immediately observes query names averaging 60 to 80 characters in length, far exceeding normal DNS query lengths, at a rate of several queries per second to a single external domain. The analyst uses "Statistics > DNS" to confirm the anomaly quantitatively, then exports the packet list to CSV for enrichment against threat intelligence. This workflow, from raw capture to actionable finding, takes under ten minutes with a pre-existing capture file.
---
Network traffic is the ground truth of what a system actually did, as opposed to what logs claim it did. Logs can be tampered with, misconfigured, or simply absent for certain traffic types. Packet captures are harder to falsify from the endpoint's perspective because they are recorded by a separate system or interface. This evidentiary quality makes Wireshark central to incident response, forensic investigation, and security validation.
Without packet-level visibility, defenders are forced to work backward from symptoms: an IDS alert, a firewall log entry, or a user complaint. These artifacts indicate that something happened but rarely show the complete content and context of the communication. Wireshark fills that gap. An analyst who can read the raw bytes of a suspicious SMB connection can determine whether it represents legitimate file access or an attempt to exploit a known vulnerability such as EternalBlue (MS17-010), because the exploit has a specific packet signature visible in the dissected fields.
A concrete consequence of absent packet-level analysis was evident during the early stages of many organizations' responses to the 2020 SolarWinds supply chain compromise. Defenders who lacked full packet capture infrastructure had difficulty distinguishing legitimate Orion product traffic from the SUNBURST backdoor's command-and-control communications, which were designed to mimic normal Orion API traffic. Organizations with packet capture capabilities were able to apply retrospective analysis to historical PCAP data, identify anomalous patterns in the timing and structure of DNS requests, and confirm or rule out compromise much faster than those relying solely on endpoint telemetry.
A common misconception is that TLS encryption makes Wireshark useless for application-layer analysis. This is false in two important contexts: first, on internal networks where analysts control endpoints and can obtain key material; second, for any analysis that does not require plaintext content, such as timing analysis, certificate inspection, handshake anomaly detection, and traffic volume profiling. Wireshark's TLS dissector shows the certificate chain, cipher suite negotiation, and handshake record types even without decryption keys, which is sufficient to identify self-signed certificates, weak cipher suites, or TLS version downgrade attempts.
---
CDA approaches Wireshark through the Planetary Defense Model (PDM) under the Visibility and Surface Detection (VSD) domain, applying the Continuous Surface Reduction (CSR) methodology: every surface you expose is a surface we eliminate.
In operational terms, CDA treats packet capture infrastructure not as a reactive forensic tool but as a continuous visibility layer that feeds surface reduction decisions. The presence or absence of anomalous protocol traffic, unexpected port usage, or unauthorized service communication is data that drives active configuration changes, not passive observation. Wireshark is the analyst's instrument for validating that CSR actions are producing the expected reduction in observable network surface.
Specifically, CDA uses Wireshark in three operational modes. First, during baseline establishment, analysts capture and profile normal traffic patterns for each network segment, identifying which protocols, ports, and host pairs constitute legitimate communication. This baseline becomes the reference against which deviation is measured. Second, during post-change validation, Wireshark captures are taken after firewall rule changes, service decommissions, or segmentation updates to confirm that the intended traffic is blocked and no unexpected traffic has appeared. This closes the loop between a control implementation and its verified effect. Third, during incident response, Wireshark is used for rapid triage of suspicious activity identified by detection tooling, drilling from a high-level alert down to the specific packets that confirm or refute the hypothesis.
CDA's differentiation is the operational discipline around capture scope and retention. Many organizations deploy Wireshark or tshark ad hoc, capturing only when a problem is already evident. CDA maintains persistent SPAN-port-based capture nodes at key choke points (perimeter, inter-segment boundaries, and high-value asset segments) with defined retention windows, so that retrospective analysis is possible when a threat is discovered days after initial compromise. This approach transforms Wireshark from a reactive utility into a proactive component of the detection architecture.
---
host [suspect IP] or port 53 is sufficient for most targeted investigations.---
---
CDA Theater missions that address topics covered in this article.
Guide to AWS Security Hub for centralized finding aggregation, continuous compliance monitoring, and automated remediation across AWS organizations.
Vendor assessment guide for HashiCorp Vault.
Wireshark is the leading network protocol analyzer for traffic capture and security investigation.
Written by CDA Editorial
Found an issue? Help improve this article.