Dropped Packets on a 10 Gbps Incident Capture
You are called to a suspected ransomware intrusion at a 10 Gbps core link. The only available tap is a SPAN port on a switch that aggregates four 1 Gbps access links. You run tcpdump -i eth1 -s 0 -w incident.pcap for 90 seconds and collect 7.2 GB. tcpdump reports packets dropped by kernel: 1,842,003, and the interface counter shows 18% of packets not captured. The capture host clock is 2.3 seconds behind the NTP server; the switch SPAN port is configured without a timestamp. The incident responder wants to use the pcap to prove a workstation downloaded a 4.8 MB executable from an external IP. The file hash is known from EDR. The traffic to the external IP is HTTPS on port 443. The capture host was not dedicated; it also runs the SIEM forwarder and a vulnerability scanner.
1. Assess whether this capture is defensible evidence and what limitations you must document.
Read the worked answer
The capture is usable as supporting evidence but is not a complete or fully reliable record. An 18% packet drop rate means the pcap is missing packets, so it cannot prove that a particular session was the only one or that no other transfer occurred. The 2.3-second clock offset affects timeline correlation and must be documented, not silently corrected. The SPAN port may also drop traffic under oversubscription, and the capture host is not dedicated, so resource contention is a plausible cause. I would hash the pcap, record the exact command, interface, capture host, start and stop times, drop counters, clock offset, and storage path. I would also record that the SPAN configuration lacked hardware timestamps. In reporting, I would say the capture is corroborating, not standalone proof, and I would rely on EDR, proxy, and firewall logs for completeness. The limitations should appear in the report rather than be left for opposing counsel to find.
2. What capture architecture and settings would you use to reacquire the traffic with less loss?
Read the worked answer
I would stop using an oversubscribed SPAN port as the primary capture point. I would use a dedicated capture appliance with a network TAP on the link of interest, or capture at the access switch port for the suspect workstation rather than the aggregated core. If full core visibility is required, I would use multiple capture interfaces and a capture engine designed for high throughput, such as PF_RING or AF_PACKET with tuned ring buffers, writing to a dedicated fast disk. I would apply a precise BPF filter for the suspect host and port 443, enable hardware or kernel timestamping, and synchronize to the same NTP or PTP source as the other logs. I would monitor drop counters continuously and set an alert if they increase. For legal defensibility, I would document the architecture, filter, clock source, and drop statistics. If the goal is only flow-level evidence, I would consider NetFlow or IPFIX instead of full packets.
3. How would you correlate the pcap with the EDR hash to support the claim that the 4.8 MB file was downloaded?
Read the worked answer
I would first establish what the pcap can actually show. Because the transfer is HTTPS, the pcap will show IP addresses, TCP ports, packet sizes, timing, and TLS metadata, but not the file content or its hash. I could estimate the transfer size from packet and byte counts and compare it with 4.8 MB, but that is an inference, not proof. To link the download to the file, I would correlate the pcap's five-tuple and timestamps with proxy logs, TLS inspection logs if available, and EDR network and file events. The EDR hash proves that a file with that hash existed on the endpoint; it does not by itself prove the file came from that external IP. If a TLS-inspection proxy recorded the object, I would extract it, hash it, and compare. Otherwise, I would present the pcap as consistent with the EDR finding and state the encryption limitation explicitly.