Wireshark is a protocol analyzer that supports both live packet capture and offline examination of previously captured traffic. Like tcpdump, it can capture packets from a network interface through its capture engine, dumpcap, using a platform-appropriate packet capture library such as libpcap or Npcap. It can also read capture files in pcap, pcapng, and many other formats. In an investigative workflow, treat the original capture as evidence: record its cryptographic hash, document the acquisition details, and work from a verified copy.
Wireshark’s protocol dissectors decode packet bytes into hierarchical fields and values you can inspect at the frame, link, network, transport, and application layers. You can search and filter these fields. Display filters are applied during packet analysis and operate on dissected protocol fields, so a filter such as http.request.method == "GET" selects captured packets in which Wireshark identifies an HTTP request using the GET method. Capture filters, by contrast, use Berkeley Packet Filter (BPF) syntax, similar to tcpdump, and are applied during capture before packets are written. They cannot reference Wireshark’s dissected protocol fields. Traffic excluded by a capture filter is unavailable in that capture, so for forensic acquisition, it is generally preferable to capture broadly and apply display filters during analysis, subject to storage, privacy, and operational constraints.
Edit > Find Packet also supports searches for strings, hexadecimal byte sequences, and regular expressions in packet data. This is useful when investigating content that a dissector does not recognize. Wireshark can also search the protocol tree of a selected packet. Protocol dissection depends on correct protocol identification. Wireshark uses port-based associations, heuristics, and other identification mechanisms, so traffic on non-standard ports may be misdissected or left undissected until the analyst applies Decode As.
Stream analysis is among Wireshark’s most valuable features, but the mechanisms differ by protocol. For TCP, Follow TCP Stream reconstructs the captured byte stream in each direction using TCP sequence information, accounting for retransmissions and out-of-order segments where sufficient data is available. UDP has no equivalent transport-layer byte stream, built-in sequencing, or retransmission mechanism. Follow UDP Stream groups datagrams associated with the same endpoint pair and presents their payloads in capture order; it cannot independently restore missing datagrams or determine an application’s intended message order. Application-layer reassembly of messages carried over UDP, such as fragmented DNS messages, is a separate function performed by the relevant dissector. QUIC, which implements its own transport and stream mechanisms over UDP, requires separate consideration. Wireshark supports following streams for multiple protocols, including TCP, UDP, TLS, HTTP, HTTP/2, QUIC, and SIP, although the available views and decoded content depend on the selected protocol, capture completeness, and, where applicable, decryption.
Separately, the TCP preference “Allow subdissector to reassemble TCP streams” controls whether higher-layer dissectors can receive reassembled TCP data when application-layer protocol data units span multiple segments. This affects application-layer dissection and the fields available for analysis and filtering. Reassembly of out-of-order segments is controlled separately, and incomplete captures may prevent complete reconstruction.
Reconstructed output is only as complete as the underlying capture. Packet loss at the capture point, an oversubscribed SPAN port, asymmetric routing, or a monitoring point that sees only one direction can leave gaps. Wireshark may flag these conditions with TCP analysis messages such as “TCP Previous segment not captured.” Such a message indicates that expected sequence data was not observed in the available capture; it does not, by itself, establish where or why the data was missed. A truncated snapshot length can also leave the captured packet length smaller than the original frame length, meaning some payload bytes were never recorded. Checksum errors on packets captured at the sending host are frequently caused by NIC checksum offloading rather than tampering or corruption.
Encrypted payloads, including TLS, IPsec, and WPA2/WPA3 traffic, generally remain opaque unless the required secrets, keys, and other decryption conditions are available. For TLS, a key log file, such as one produced by an application configured to use SSLKEYLOGFILE, is a common decryption method. A server’s RSA private key can decrypt certain legacy TLS sessions that use compatible RSA key exchange, but it cannot generally decrypt modern sessions using ephemeral key exchange. Decryption also depends on having the relevant traffic and compatible protocol support. The pcapng format can embed decryption secrets in Decryption Secrets Blocks, so captures containing embedded keys must be handled as sensitive evidence.
Wireshark provides summary views useful for triage and scoping, including Statistics > Conversations and Endpoints, Protocol Hierarchy, and I/O Graphs. These help analysts examine source and destination addresses, ports, packet and byte counts, protocol distribution, and traffic patterns over time. Timestamps reflect the capture system’s clock and the timestamp characteristics of the capture source. The displayed time zone is configurable, so document the relevant clock, time zone, and timestamp settings when correlating network traffic with other evidence sources.
For artifact recovery, File > Export Objects can extract supported objects from protocols including HTTP, SMB, FTP-DATA, TFTP, IMF (Internet Message Format), and DICOM. Successful extraction depends on the availability of the relevant application data and sufficient protocol reassembly. Missing or truncated data can produce incomplete or unusable files, although not every capture gap necessarily affects every exported object. Hash each exported object, record its source and extraction details, and preserve the original capture. Wireshark can save captures in multiple formats, but converting from pcapng to legacy pcap can discard metadata, including packet comments, per-interface information, and embedded decryption secrets. Wireshark’s feature set is too broad to cover exhaustively in this post, so we’ll concentrate on the capabilities most relevant to incident analysis.
Wireshark and tcpdump
The comparison between Wireshark and tcpdump is not intended to establish superiority. The tools are not mutually exclusive; in practice, they are often complementary. Sometimes one tool fully satisfies the task. In other cases, combining them is more efficient or provides the most practical approach.
Consider a capture too large for Wireshark to analyze efficiently. Wireshark dissects packets and retains packet-list metadata and analysis state for tasks such as conversation tracking, sequence analysis, and reassembly. As a result, large captures can consume substantial memory and become slow to load or analyze. tcpdump, by contrast, can read a capture sequentially, evaluate each packet against a filter, and write selected packets without retaining Wireshark's full analysis state. This makes it useful for reducing large captures to manageable subsets, although processing time still depends on the file size, filter complexity, and storage performance.
Now consider a common scenario in which large captures reside on a remote, possibly cloud-hosted, system. Transferring the entire file may be slow, costly, and unnecessary if the packets of interest can be isolated on the remote system. Finally, suppose the traffic of interest has a distinctive trait that a Berkeley Packet Filter (BPF) expression can select: a value in a protocol header or, using byte offsets and masks, a value in the packet data. We will cover filters in detail later. For now, understand a conventional capture filter as a means of selecting packets according to header or payload characteristics, with each packet evaluated independently. That last property shapes the workflow. A filter that matches a distinctive payload value selects the packets containing that value, not automatically every packet in the session to which they belong. Without the necessary packets from both directions and the intervening segments, stream reconstruction and object export may fail or produce incomplete artifacts. A practical approach is to use the distinctive trait to identify a candidate conversation, then extract its traffic using the relevant addresses, transport protocol, and ports. Validate the resulting subset rather than assuming that a matching payload identifies the entire conversation.
Account for IP fragmentation as well. Non-initial IP fragments do not contain the transport-layer header, so port-based filters may not match them; the initial fragment generally contains the transport header, provided it has not itself been truncated. Where fragmentation is relevant, ensure that the extraction preserves the fragments needed for reassembly. Also account for VLAN encapsulation: VLAN tags affect packet-header offsets, and fixed-offset BPF expressions must account for the actual link-layer structure. BPF's VLAN primitives can adjust offsets when the filter is written appropriately.
Once the relevant subset has been written to a new capture file, it can be opened in Wireshark for detailed inspection, including stream analysis, object extraction, and examination of individual protocol fields. Two fidelity caveats apply. tcpdump typically writes classic pcap rather than pcapng, so pcapng-specific metadata, such as packet comments and per-interface information, may be lost. Timestamp precision also requires attention: when reading a savefile, tcpdump's default microsecond precision can truncate timestamps stored at nanosecond resolution. Where the input contains nanosecond-resolution timestamps and preserving that precision matters, use --time-stamp-precision=nano when reading the file. This option preserves the available precision during reading; it cannot restore precision that was lost earlier.
tcpdump -r input.pcap --time-stamp-precision=nano -w subset.pcap 'host 203.0.113.5 and tcp port 443'Treat this process as evidence handling. Hash the original capture before processing, work from a verified copy, and avoid writing derived output to the evidence volume. Record the exact command line, tool versions, filter expression, and output format. Hash the extracted file as a derivative artifact and retain the original capture as the authoritative source. When extraction occurs remotely, hash the source and extracted subset there, then verify their hashes again after transfer. Document any format conversion, filtering, or other transformation that could affect metadata or timestamps.
We will examine other tools in subsequent posts Some are narrowly focused, such as passive operating-system fingerprinting, which infers a likely operating system from TCP/IP stack characteristics such as initial TTL, TCP window size, option ordering, and maximum segment size (MSS). Treat its output as an investigative lead, not a conclusion, because NAT, proxies, traffic normalization, operating-system changes, and deliberate spoofing can alter or imitate these characteristics. Other tools, such as Wireshark, provide broad protocol-analysis capabilities. No single tool is likely to meet every investigative need, so use each for its strengths and combine tools where doing so produces a more efficient, reproducible, and defensible result.
The image above shows Wireshark’s main welcome screen. The screenshot shows Wireshark version 3.6.2, so the menu labels and layout may differ in newer versions. When you start Wireshark, this screen provides quick access to recently opened capture files and allows you to begin capturing live traffic from any available network interface. It also provides links to learning resources, including the Wireshark User’s Guide, wiki, and community support channels.
Although several commonly used options are available directly from the welcome screen, analysts will typically use the menus and toolbars to access Wireshark’s broader range of features. These include packet analysis, statistics, protocol-specific tools, and capture configuration options. The menus provide access to far more functionality than is visible on the welcome screen alone.
The image above shows Wireshark’s main packet-analysis window, used to examine traffic captured from a live network or loaded from a capture file. The main menu provides access to packet analysis, statistics, protocol-specific tools, and other functions. Directly below the toolbar is the display filter entry field, where you can enter display filters to select which packets appear in the packet list. Unlike capture filters, display filters do not remove packets from the underlying capture file.
Wireshark’s main analysis window is organized into three primary panes. The packet list pane displays the captured packets and provides summary information about each one, including its number, timestamp, source, destination, protocol, length, and a brief description. Selecting a packet in this pane updates the information shown in the other two panes.
The packet details pane presents the selected packet as a hierarchical breakdown of its protocol layers and fields. For example, the selected packet in this screenshot is a DHCP Discover message. Its details include the frame information, Ethernet II header, IPv4 header, UDP header, and DHCP protocol fields. Expand a protocol section by selecting the triangle beside it to inspect its individual fields.
The packet bytes pane displays the selected packet’s raw bytes in hexadecimal, alongside their ASCII representation where applicable. This view is useful when validating protocol fields, inspecting payloads, or examining bytes that are not fully interpreted by a dissector.
The status bar at the bottom displays information about the current capture file and packet counts. In this screenshot, Wireshark has loaded 2025-01-22-traffic-analysis-exercise.pcap, with 39,427 packets in total and all 39,427 currently displayed.
Now examine the hexadecimal output in the packet bytes pane. At the beginning of the selected packet, the first 14 bytes represent the standard Ethernet II header, assuming an untagged Ethernet frame. The IPv4 header begins immediately afterward, at zero-based offset 14 (hexadecimal 0x0E). Its first byte is 0x45, indicating IPv4 (version 4) and an Internet Header Length (IHL) of 5, equivalent to a 20-byte IPv4 header. Remember that the displayed byte offsets begin at zero. Therefore, the first byte is at offset 0x0000, and the IPv4 header begins at offset 0x000E. VLAN tags or other link-layer encapsulations can change this offset, so always verify the actual frame structure before assuming that the IP header starts at byte 14.
Wireshark provides a variety of traffic views and statistical tools that help analysts understand the composition and behavior of a network capture. In this exercise, we have limited information about the contents of the PCAP file, other than the guidance indicating that it contains DHCP traffic and HTTP sessions.
A useful starting point is to examine the capture’s overall statistics. These views help establish a baseline of observed network activity, identify protocols and communicating hosts, and highlight conversations that may warrant closer investigation. This initial profiling can guide subsequent analysis, although statistical patterns alone do not establish malicious activity. To begin, select the Statistics menu in Wireshark’s main menu bar. Explore the available options to identify useful summaries of the captured traffic.
Wireshark provides several statistical views that help analysts understand the contents of a packet capture. The two views shown here are Capture File Properties, on the left, and Protocol Hierarchy, on the right. Both are accessible from the Statistics menu.
The screenshots above show the results of selecting two options from Wireshark’s Statistics menu. The display on the left shows the Capture File Properties window, which summarizes the contents and characteristics of the loaded capture file. The display on the right shows the Protocol Hierarchy, which provides a breakdown of the protocols identified in the captured traffic.
The Capture File Properties window summarizes the capture, including the number of packets, the total captured packet bytes, the capture duration, and various packet-size and timing statistics. It also displays information about the capture file itself, including its file size. Notice that the file size shown in the File section is approximately 26 MB, while the Bytes Captured field in the Details section reports 26,128,819 bytes. These values measure different things. The file size includes the bytes occupied by the packet records and the capture-file structure, such as record headers and other format-specific metadata. The Bytes Captured value represents the total number of packet bytes recorded in the capture, rather than the size of the file on disk. Consequently, the two values do not necessarily match.
Another useful overview is available through Statistics → Protocol Hierarchy. This view organizes the traffic by protocol and its relationships to other protocols, showing statistics such as packet counts, bytes, and percentages of the captured traffic. Protocols are presented hierarchically, allowing analysts to see how traffic is distributed across different layers and protocol families. This overview provides a useful starting point for identifying the dominant protocols in a capture and deciding which areas warrant closer examination. For example, if the investigation concerns SMTP and HTTP activity, the Protocol Hierarchy can help establish whether these protocols are present and how much of the captured traffic they represent. However, the presence or relative volume of a protocol does not, by itself, establish suspicious activity. Protocol Hierarchy is a useful starting point for profiling an unfamiliar capture. It helps identify the protocols present and their relative prevalence, allowing you to focus subsequent analysis on traffic relevant to the investigation.
To examine these views in Wireshark:
Select Statistics → Capture File Properties to view the capture summary shown on the left.
Select Statistics → Protocol Hierarchy to examine the protocol distribution shown on the right.
Wireshark’s Statistics → Conversations view provides a useful summary of communication between network endpoints. Depending on the selected protocol tab, it displays conversations identified at different protocol layers, including Ethernet, IPv4, IPv6, TCP, and UDP. The statistics typically include packet and byte counts, with additional columns showing traffic in each direction. This view is particularly useful for profiling network activity, identifying heavily communicating hosts, and locating conversations that warrant closer examination.
Select a protocol tab at the top of the window to view the corresponding statistics. The available tabs depend on the protocols present in the capture and the Wireshark version. Older versions sometimes displayed tabs even when the capture contained no corresponding traffic, whereas newer versions generally show only tabs for which relevant data is available. Consequently, the tabs you see may differ between capture files and software versions.
In the screenshot, the TCP tab on the left lists individual TCP conversations, distinguished by endpoint addresses and port numbers. Each row represents a distinct endpoint pair, allowing you to examine the number of packets and bytes exchanged between the endpoints. You can sort the results by clicking a column heading; clicking it again reverses the sort order. Sorting by bytes or packets is a convenient way to identify high-volume conversations or unusually active connections that may deserve further investigation.
The IPv4 tab on the right presents a broader view. Instead of distinguishing conversations by TCP or UDP port numbers, it aggregates traffic by IP address pair. As the screenshot illustrates, multiple TCP connections between 10.1.17.215 and 10.1.17.2 appear as separate entries in the TCP view but contribute to a combined total in the IPv4 view. This allows you to assess the overall volume of traffic exchanged between two hosts, even when that traffic spans multiple transport-layer connections.
This distinction is useful when investigating potential data exfiltration. For example, consider a host that transfers a large volume of data to a single destination through one long-lived connection. Sorting TCP conversations by bytes may make that connection immediately apparent. However, an application could also distribute the transfer across many separate connections to the same destination, making the overall activity less obvious when examining individual TCP conversations.
Switching to the IPv4 view can help reveal this broader pattern because traffic between the same IP address pair is aggregated across connections. The resulting totals may highlight a host that exchanged an unusually large amount of data with a particular destination, even when no individual TCP connection appears exceptional.
This approach is not limited to exfiltration investigations. Aggregated conversation statistics can also help identify internal scanning, repeated communications with external infrastructure, unusually active hosts, and other patterns that merit closer analysis. However, high packet or byte counts are not proof of malicious activity. Legitimate backups, software updates, and ordinary application traffic can also generate substantial volumes. Validate suspicious patterns by examining the relevant TCP or UDP conversations, protocol details, timestamps, and other available evidence. The same general approach to network-flow analysis is also used by tools such as Zeek and SiLK, which provide additional ways to summarize and investigate network communications.
One of Wireshark’s most valuable capabilities is TCP stream reconstruction. Tools such as tcpdump primarily capture, filter, and display individual packets, which is often sufficient when the artifact of interest is contained in a single packet. However, investigating an entire exchange requires examining how the packets fit together. Wireshark’s Follow TCP Stream feature reconstructs the captured TCP byte stream using sequence numbers, accounts for retransmissions and out-of-order segments where possible, and presents the data from both directions in a color-coded view. This allows you to examine what the client sent and how the server responded, without manually piecing together individual packets.
Wireshark also provides Follow UDP Stream, but UDP has no transport-layer sequencing or retransmission mechanism equivalent to TCP. The feature groups datagrams associated with the same endpoint pair and displays their payloads in capture order. It cannot independently restore missing datagrams or determine their intended application-level order.
Command-line tools can support similar investigations. TShark can follow TCP streams and output their contents without a graphical interface, while tcpflow can reconstruct TCP streams into separate files. Zeek complements these tools through connection logging and application-protocol analysis, although its output is not simply equivalent to Wireshark’s Follow TCP Stream view.
Keep the limitations in mind. Follow TCP Stream focuses on the reconstructed application-data stream rather than displaying the individual packet headers, flags, and timing information. To examine those details, return to the packet list and inspect the relevant packets. The displayed content also depends on the protocol and the selected stream-view format. For example, HTTP chunked transfer encoding and compression may require additional protocol-aware interpretation; do not assume that the Follow Stream output automatically presents the fully decoded application content. Encrypted traffic, including TLS, remains unreadable at the application layer unless the necessary decryption material is available and Wireshark can successfully decrypt the session.
The reconstruction is also limited by the quality and completeness of the capture. Missing TCP segments, a capture that begins partway through a connection, or traffic observed in only one direction can leave the reconstructed stream incomplete. Check TCP analysis messages and expert information, then compare the stream with the underlying packets before treating it as a complete record of the exchange.
Let’s follow a TCP stream in our sample PCAP file. Select a TCP packet belonging to the session you want to investigate—in this example, the first packet in the packet list—and choose Analyze → Follow → TCP Stream. Wireshark opens a separate window displaying the reconstructed conversation. It also applies a display filter, typically of the form tcp.stream eq 0, to the main packet list so that only packets associated with the selected stream are displayed. The stream index may differ depending on which connection you select. Clear the display filter when you have finished examining the stream and want to return to the full packet list.
Record the stream index in your investigation notes so that you can return to the same conversation later. Also document the capture filename and any relevant packet numbers or timestamps, since the stream index identifies the conversation within that capture rather than serving as a universal identifier. The reconstructed output is shown in the next image.
Stream reconstruction is one of Wireshark’s most frequently used features. In the Follow TCP Stream window, client-to-server data is displayed in red and server-to-client data in blue by default. In this example, the stream carries LDAP traffic. The client issues a RootDSE search request, querying attributes such as namingContexts, defaultNamingContext, and supportedControl. The server, an Active Directory domain controller identified as CITADEL-DC01 in the C137.local domain, returns the requested information. The status line reports four client packets, three server packets, four turns, and 5,062 bytes.
LDAP uses a structured binary encoding, so non-printable bytes appear as dots in the ASCII representation. This is expected and does not indicate missing data. To examine the exact message structure, select the hexadecimal view or inspect the relevant packets using Wireshark’s LDAP protocol dissector. The drop-down beneath the reconstructed data defaults to Entire conversation. You can change this selection to display only client-to-server data or server-to-client data. The color coding helps distinguish the direction of communication, while the direction selector allows you to focus on one side of the exchange.
Following a stream also applies a display filter to the main Wireshark window. In this example, the filter is tcp.stream eq 0, which limits the packet list to packets associated with stream 0. The other packets are hidden from the current view, not deleted from the capture file. In the Follow Stream window, Back returns to the previous display-filter state, while Close closes the stream window and leaves the stream filter applied. To restore the full packet list, clear the display filter using the X control in the filter bar.
Wireshark assigns TCP stream indices during packet dissection; these indices are not stored as intrinsic identifiers in the capture file. Record the stream index alongside the source and destination IP addresses, port numbers, capture filename, and relevant packet numbers or timestamps so that you can identify the conversation reliably during later analysis.
Finally, distinguish between display filters and capture filters. Display filters control which packets are visible during analysis; clearing a display filter restores the packets that were previously hidden. Capture filters use Berkeley Packet Filter (BPF) syntax and are applied during acquisition. Packets rejected by a capture filter are not written to that capture file and therefore cannot be recovered from it. This distinction is important in forensic investigations because filtering during analysis preserves the original captured evidence, whereas filtering during acquisition can permanently exclude relevant traffic from the resulting capture.
Wireshark assigns each TCP stream an index during packet dissection. This index appears in the display filter applied by Follow TCP Stream, such as tcp.stream eq 0, and in the packet details pane as [Stream index]. Use it as a convenient working reference in your investigation notes and report, but do not treat it as a permanent identifier. Stream indices are derived during dissection rather than stored in the capture file, so they may change when the capture contents, packet ordering, or dissection conditions change. For reproducible forensic reporting, record the stream index alongside the following information:
Capture identification: the capture filename and its SHA-256 hash.
Conversation endpoints: the source and destination IP addresses and port numbers, including the transport protocol.
Time boundaries: the first and last relevant packet timestamps, with the display time zone documented.
Analysis filter: the exact display filter expression used to isolate the stream.
Packet references: the relevant frame numbers from the original capture.
Frame numbers identify packet positions within a particular capture file. They are useful references when tied to the verified, hashed original, but may change if packets are removed, reordered, or the capture is otherwise transformed. Recording these details allows another analyst to verify the evidence, locate the same packets, and reproduce the analysis without relying solely on a stream index that may not remain stable across different processing conditions.
Another useful Wireshark feature is Find Packet, which allows you to search a capture for packets matching a specific indicator or pattern. You can search for text strings, hexadecimal byte sequences, or other supported patterns, depending on the selected search mode. To open the Find Packet interface, select Edit → Find Packet from the menu bar or press Ctrl+F. The search controls allow you to specify what to search for and where to look, helping you locate packets of interest for further investigation.
In current versions of Wireshark, Find Packet (Edit → Find Packet, or Ctrl+F) appears as a search bar above the packet list rather than as a separate dialog box. Its controls let you specify where to search, how text should be interpreted, whether the search is case-sensitive, and which search method to use.
You can set the search scope to Packet list, Packet details, or Packet bytes. Packet list searches the text displayed in the packet list columns, such as the Info column, so results can depend on column configuration and name-resolution settings. Packet details searches dissected protocol field names and values. Packet bytes searches the raw bytes of the captured frame, including its headers and payload.
The search-type options include Display filter, Hexadecimal value, String, and Regular expression. The available encoding options include Narrow, Wide, and Narrow & Wide, which can help locate text represented as ordinary single-byte characters or as UTF-16 text commonly found in Windows artifacts. Hovering over a control displays a short description of its function.
When searching for a known string within captured packet data, select String as the search type and Packet bytes as the search scope. In this example, we search for MFEw. The Case sensitive option determines whether uppercase and lowercase differences matter. Because MFEw and MFEW contain different character sequences, choose this setting deliberately according to the indicator you are investigating.
Searches start with the selected packet and continue through the capture. Use Ctrl+N to move to the next match and Ctrl+B to move to the previous match. In this example, the search identifies an HTTP GET request to a CDN-hosted address whose URI begins with MFEwTzBNMEsw. This string is consistent with Base64-encoded data that may represent part of a certificate-status request, such as an OCSP request. However, the prefix alone is not sufficient to establish the nature of the request. Examine the complete URI, the associated HTTP headers and response, and the surrounding traffic before drawing a conclusion. Certificate-status checks are common in legitimate browsing and application activity, so a match should be treated as an investigative lead rather than evidence of malicious behavior.
Remember that a packet-byte search examines individual captured frames. It may not find a string that spans multiple TCP segments, and compressed or encrypted content may not appear in searchable form. In such cases, follow the relevant TCP stream, inspect the protocol dissection, and determine whether reassembly or decryption is necessary.
For reproducible forensic analysis, record the search type, scope, search string, case-sensitivity and encoding settings, relevant frame numbers, and the SHA-256 hash of the capture file. These details allow another analyst to repeat the search against the same evidence.
Find Packet moves the selection to a frame containing the string, providing a lead rather than the surrounding context. To examine the hit in its conversation, select the matching packet and choose Analyze > Follow > TCP Stream (Ctrl+Alt+Shift+T), or right-click the packet and choose Follow > TCP Stream. Only options supported by the selected packet are enabled. In this example, the packet carries HTTP over TCP, so TCP Stream and HTTP Stream are available, while options such as UDP, TLS, and QUIC are disabled.
Follow TCP Stream reassembles and displays the TCP conversation’s application data. A single connection may contain multiple HTTP requests and responses, so locate the exchange containing your search hit. Follow HTTP Stream presents the conversation at the HTTP layer, making the request line and headers easier to inspect; how much of the body is readable depends on its content and transfer encodings. Check the Host header and the response’s Content-Type. A response with Content-Type: application/ocsp-response supports the interpretation that this is an OCSP certificate-status lookup. Confirm it against the request and surrounding traffic rather than relying on the URI prefix alone. The response body is binary and may appear as dots or other unreadable characters in the ASCII view.
For reproducibility, record the selected frame number, TCP stream index, and source and destination address-port pairs. Because the search matched MFEw case-insensitively and the same URI prefix appears in multiple frames at different times, identify the specific occurrence you followed.
This stream contains a single HTTP exchange: one client request (red) and a two-packet server response (blue). The request is a GET whose URI begins MFEwTzBNMEsw..., matching the string we searched for. The string appears in the client’s request line, not in the server’s response headers. The Host header is ocsp.digicert.com, the User-Agent is Microsoft-CryptoAPI/10.0, and the response’s Content-Type is application/ocsp-response. Together, these details indicate an OCSP certificate-status lookup generated through the Windows cryptographic stack, rather than a conventional request to download a user-accessed file. This helps explain why a short Base64 prefix can produce multiple hits in a capture.
The response headers provide an additional timeline reference. The server’s Date is Sat, 19 Sep 2020 02:40:08 GMT, while the cache-related fields (Age, max-age, Expires, and X-Cache: HIT) indicate that the response was served from a CDN cache. Treat the HTTP Date as server-provided metadata that can help corroborate the capture timeline, not as a replacement for the packet timestamps. Also consider clock differences and caching behavior when interpreting the relationship between these times.
The 1,507-byte response body contains binary data. Apply the ocsp display filter and inspect the decoded fields, where available, including certificate status, responder information, validity times, and certificate serial number. OCSP requests can expose information about certificates being checked and may provide clues about a host’s TLS activity, even when the application sessions themselves are encrypted. However, an OCSP request does not by itself prove that the host directly visited the associated website; certificate validation may be triggered by background services or other applications. For reproducibility, record the relevant frame numbers, TCP stream index, source and destination address-port pairs, and the SHA-256 hash of the capture file.
Post a Comment