An agency analyst needs the unencrypted file a host downloaded. A week of NetFlow is stored, and no packets were saved. What gap prevents recovery of that file?

NetFlow and similar flow records summarize a conversation: addresses, ports, protocol, timing, and counters. They do not store payload. Carving a downloaded file requires the bytes, which this disk does not have. A tap can copy frames that contain payload, and the 5-tuple is only the address and protocol fields. "NetFlow keeps only the conversation summary and has no payload, so the file cannot be carved". With no payload in the flow summary, there are no file bytes to reassemble from the week of NetFlow. "NetFlow already stores the downloaded file, so the bytes can be carved directly from those records". Flow records do not store the downloaded file. There is nothing in them to carve into the original content. "A traffic tap would also lack payload, so a tap capture could not hold the downloaded file either". A tap copies frames, and those frames can include payload. Saying a tap would also lack payload reverses the gap. The disk in this case holds NetFlow, not a packet copy. "The 5-tuple inside each NetFlow record is the downloaded file and can be opened as its content". The 5-tuple is source address, destination address, source port, destination port, and protocol. Those five fields are not the file body and cannot be opened as the download. Exam caveat: a saved packet copy from a tap could be carved by reassembling the TCP stream. This disk has flow records only. Operational check: open a NetFlow record for the download and confirm it shows the conversation fields and counters, with no file bytes present.