4.4PCAP analysis (stream reassembly and elements of an intrusion)

Even when an alert or flow says "suspicious," what was actually exchanged is not settled until you look inside the packets. TCP crossing the network arrives as small segments and makes no sense as-is. The heart of pcap analysis is reassembling the scattered segments in order to restore the application-layer conversation (an HTTP GET response, a transferred file), then pinning down who sent what to whom. This section covers the procedure for stream reassembly and file extraction, and reading the elements of an intrusion (the 5-tuple plus payload) from packets to name the victim host and attacker infrastructure.

4.4.1Stream reassembly and file extraction

• TCP splits data into segments that are reordered by sequence numbers (seq/ack). Wireshark's Follow TCP Stream concatenates the segments of one connection (the same 5-tuple) in seq order, restoring the application-layer raw data (HTTP request/response bodies, etc.) with send/receive color-coded. The starting point is to narrow "which stream" with a filter (e.g., tcp.stream eq 3).
• To extract a transferred file, save the reassembled stream's payload, or use Wireshark's File > Export Objects > HTTP (or SMB, etc.) to write out the response body directly as a file. For the carved sample, compute a hash (e.g., sha256), check reputation, and register it as an IOC. This is the standard procedure for confirming "the malware that actually landed" from a pcap.

4.4.2Elements of an intrusion (5-tuple + payload)

• The basic elements describing an intrusion from packets are source address, destination address, source port, destination port, and protocol (the 5-tuple) plus the payload. The 5-tuple sets the skeleton of "which host talked to which service," and the payload settles "what it did / what it sent." Combined with direction (inside-to-outside or outside-to-inside), you can name the victim host, attacker, and C2/exfiltration destination.
• Ports and direction hint at roles: if an internal host's high ephemeral port (e.g., 49xxx) is the source and an external server port is the destination, that internal host is going outbound as a client. If a PE file flows inward in the response to GET /payload.exe, read it as a download (the victim side); if small periodic traffic from inside to a fixed external destination persists, read it as a C2 beacon; if large data leaves outward, read it as exfiltration.

An IDS alerts on one "suspicious EXE download," and you are handed the pcap for that time. To narrow down within a huge packet set, you filter by the alert's 5-tuple (e.g., ip.addr 10.1.1.5 && tcp.port 80). Right-clicking a matching packet and running Follow TCP Stream concatenates the scattered segments in seq order, and you see the request GET /update/setup.exe HTTP/1.1 (internal 10.1.1.5:49770 -> external 203.0.113.9:80) and, following 200 OK, a PE file in the response body (a binary starting with MZ). From the 5-tuple and direction, it is settled that internal host 10.1.1.5, as a client, fetched an executable from an external server—the victim host—and that 203.0.113.9 is the distribution infrastructure. Next, via File > Export Objects > HTTP you write out setup.exe directly, compute its sha256, check it against threat intel, find it malicious, and register the hash, URL, and destination IP as IOCs. The caution: a flow or an alert alone does not settle "did a file actually land and could it have run"—NetFlow would tell you only that "10.1.1.5 exchanged tens of KB with 203.0.113.9:80," giving neither proof the content is an EXE nor the sample itself. That is exactly why the procedure of reaching into packets—locate via 5-tuple, restore the conversation via stream reassembly, carve the sample via Export Objects—is indispensable for confirming impact and producing IOCs. And if this traffic were HTTPS, the response body would be encrypted and unextractable, so you would pivot to endpoint evidence (AV or process records)—a judgment that follows naturally from this same flow.

4.4.3Section summary

• TCP arrives as segments, so restore the application-layer conversation with Follow TCP Stream (reassembling one 5-tuple in seq order) before reading the content
• Extract transferred files with Export Objects, then hash them to make IOCs; use the 5-tuple + payload + direction to name the victim host and C2/exfiltration destination
• A flow or alert alone cannot settle the content; HTTPS encrypts the body and it is not extractable, so pivot to endpoint evidence in that case