Evidence Acquisition and Packet Capture
This domain tests whether you can acquire network evidence defensibly and preserve its fidelity. Questions cover capture placement, hardware and software capture, packet loss, file formats, hashing, and documentation.
Core rules
Capture as close to the target as legal and practical. A network TAP preserves link integrity and sees full-duplex traffic; a SPAN/mirror port is convenient but can drop packets under oversubscription and may omit physical errors. Use a capture interface in promiscuous mode only where authorized. Set snaplen deliberately: full packets support payload analysis; headers-only captures reduce storage but may lose content evidence.
Record interface, filter, link speed, capture start/stop in UTC, tool version, and drop statistics. Prefer pcapng for interface and comment metadata, but verify tool compatibility. Hash the finished capture and store it write-protected; analyze a copy. Size storage from link rate, utilization, and duration, and use ring buffers to avoid full-disk loss.
Worked example
A 1 Gbps link at 20% average utilization produces about 200 Mbps, or roughly 25 MB/s, so a one-hour full-packet capture is about 90 GB before overhead. If only 10% of packets are relevant, a BPF filter for the suspect /24 cuts volume, but document the filter because it excludes other evidence. If the SPAN port reports drops, move to a TAP or reduce scope.
Traps
Capturing on the wrong VLAN; forgetting that SPAN may not see switched unicast without proper configuration; truncating packets and later needing payload; and hashing before capture stops. Also check time synchronization: packet timestamps and log timestamps must share a known time base.