It was 14:23 on a Tuesday when the alert fired.
ET MALWARE Zeus Bot POST Request. Severity HIGH. Source 192.168.1.100 reaching out to a bare IP in Eastern Europe on port 80. Classic command-and-control beacon pattern. The kind of alert your IDS has been tuned to catch.
The question that followed was the same one that follows every alert like this one: do we have the packet data that preceded this event?
In most security operations environments, the honest answer is no. Or: we have 72 hours. Or: we have flow records but not full packets. Or: we have the capture but nobody can navigate 2.1 TB of raw PCAP fast enough to matter.
Twenty-four minutes after that alert fired, my team had identified two infected hosts, created a chain-of-custody evidence bundle, and closed the investigation window. No packets left the server. No files were copied. The answer existed before we asked the question.
This is what forensic readiness actually looks like when the architecture supports it.
The Problem Nobody Wants to Say Out Loud
Network security teams have been accepting a structural lie for decades. The lie is this: a 72-hour rolling buffer is a reasonable retention policy.
It is not. It is the retention window that fits the storage budget. Those are different things, and only one of them is worth solving.
The retention window most organizations operate under is not the retention window they want. It is the retention window they can afford.
Mandiant's M-Trends 2025 report puts the global median dwell time at 11 days for 2024. A 72-hour buffer covers less than 28% of that window. When the alert fires on day 11, the packet evidence from day 1 is long gone.
What investigators are left with: logs that record what was logged, flow records that record connection metadata, IDS signatures that record what the rules matched. All derived from the same packets that have since been overwritten. The primary source is gone.
The IBM Cost of a Data Breach Report 2024 puts the mean time to identify a breach at 194 days. Mean time to contain: 64 days. These numbers are not mysteries. They are the direct consequence of investigating from secondary sources after the primary evidence window has closed.
Three Ways Forensic Readiness Fails
Every post-breach investigation I have been part of ends up in one of three places. The pattern is consistent enough that I can usually identify which failure mode applies within the first hour.
The data was never captured
Span ports are selective. Capture agents cover the known high-value segments. Everything else is assumed to be covered by logs. When the attacker moves laterally through an uncaptured segment, the trail ends at the boundary.
This one is simple but uncomfortable: starting a capture after an alert fires captures nothing retroactively. The window closed before you knew to open it.
The data was not retained
The capture was running. The rolling buffer was configured for 72 hours. The attacker established a foothold and waited two weeks before taking any action. The evidence of initial access was overwritten on day three.
An attacker who knows your retention window has an effective evasion strategy that requires no technical sophistication at all. Just patience.
The data exists but cannot be used
This is the most insidious failure mode because the infrastructure appears to be working. The capture is running. The files are on disk. But a 2.1 TB PCAP file is not an investigation surface.
Loading a file that size into Wireshark on an analyst's laptop takes minutes to open and hours to navigate. By the time the analyst has found the relevant 30-minute window, the incident response window has moved on.
What Actually Changed: Intelligence Before Rollover
The root cause across all three failure modes is the same: the capture infrastructure was designed for monitoring, not investigation. Monitoring requires alerting on current conditions. Investigation requires retroactive access to arbitrary historical windows at speed.
The architectural requirement that follows from this is precise: the index must be built as packets arrive, not after the fact. Post-processing a 2.1 TB capture to build a searchable index takes longer than the investigation window allows. The index must already be there when the alert fires.
Vantage's capture engine builds what we call the Query Analytics Tree continuously during capture. As each packet arrives, its 5-tuple, protocol fields, IDS correlation keys, and behavioral signals are committed to a hierarchical index structure stored alongside the PCAP file. By the time the alert fires, the index covering the preceding 14 days is complete and queryable.
This is not a database. There are no table scans. There is no SQL engine. The Query Analytics Tree is a purpose-built data structure that navigates by pruning branches that cannot contain the answer. A targeted query against 2.1 TB of capture reads 412 KB of data. That is 0.000019% of the total. The rest is skipped entirely.
Query performance scales with the specificity of the question, not the size of the capture.
24 Minutes: A Real Incident Response Workflow
Back to 14:23 on that Tuesday. Here is what the next 24 minutes looked like.
Check what we have
sentinel status State Running Uptime 14d 3h 22m Interfaces eth0, eth1 Total 1,457,241,847 packets 2.1 TB (14 days) Current 1,204 pps ~14.4 Mbps
Fourteen days of continuous capture. The evidence from day 1 is on disk and indexed. Sentinel has been running as an unattended systemd service the entire time.
Read the alert in context
Lynx connects to the capture server remotely. The IDS alert appears inline in the packet list, anchored to the exact packet that triggered it, with flow boundaries injected automatically. The raw packet data stays on the server. Nothing downloads to the analyst's laptop.
ALERT: Zeus Bot Checkin sid:2014818 192.168.1.100 -> 185.234.72.19:80 ET MALWARE Zeus Bot POST Request -- Flow start TCP 192.168.1.100:49152 -> 185.234.72.19:80 -- POST /gate.php 200 OK -- Flow end Duration: 0.107s Packets: 2 Bytes: 699 --
Two packets. 699 bytes. 0.107 seconds. Classic beacon structure. The analyst adds a bookmark: Initial C2 beacon, Zeus Bot.
Create the evidence window
Quarry creates a virtual projection of the relevant 30-minute window filtered to the two involved IPs. The projected file exists at a real path readable by Wireshark or any PCAP-aware tool. Zero storage overhead. The original 2.1 TB capture continues recording uninterrupted.
vqc project \ --volume capture_20241211_143022.pcapng \ --from 14:00:00 --to 14:30:00 \ --filter "ip.addr == 192.168.1.100 or ip.addr == 185.234.72.19" \ --encrypt level 10 \ --output /silos/incident-INC-2024-1217/evidence.pcapng Source 2.1 TB Window 14:00:00 - 14:30:00 Output evidence.pcapng Size 0 bytes (virtual — no data copied) Packets 4,218 (estimated from index)
Second analyst joins live
A senior analyst connects to the same session remotely. Two analysts, independent cursors, same capture. Within two minutes she finds a second infected host matching the same C2 pattern. In a traditional workflow this would have required a separate file transfer and a new analysis session.
Evidence packaged
lynx export \ --session INC-2024-1217 \ --include bookmarks comments audit-log \ --output /exports/INC-2024-1217-bundle.zip Bundle created: 14:47:03 UTC
Alert at 14:23. Evidence packaged at 14:47. Two infected hosts identified. Zero packets moved off server. One server. 24 minutes.
What This Requires (And What It Does Not)
The workflow above runs on a single server. Not a cluster. Not a distributed deployment. A single node with Sentinel capturing, Quarry providing the virtual filesystem, and Lynx connecting remotely.
What it requires: continuous capture before the alert fires, an index built at capture time not after, and a virtual filesystem layer that lets analysts work against the original data without moving it.
What it does not require: replacing your existing infrastructure. Sentinel captures alongside whatever you already have. Quarry's virtual filesystem is readable by Wireshark, tcpdump, and any PCAP-aware tool your team already uses. Suricata and Zeek alerts appear inline in Lynx because their output is merged directly into the Query Analytics Tree at capture time. The investment in your existing tooling is preserved.
This is not a rip-and-replace proposition. It is an additive layer that changes what your existing infrastructure can answer.
Forensic Readiness Is an Infrastructure Decision
I have been building packet capture infrastructure since 2005. The conversations I had then about retention windows, storage costs, and investigation capability are nearly identical to the conversations I have today. The constraints have shifted — storage is cheaper, links are faster, the threat landscape is more sophisticated — but the structural gap between monitoring capability and investigation capability has not closed.
The gap is not a tooling problem. Security teams have excellent tools. It is an architecture problem: the capture infrastructure was designed with different goals than the investigation workflow requires.
Forensic readiness means having the data before you need it, indexed before you query it, and presentable before the incident window closes. Those are infrastructure decisions made long before any alert fires.
The packet that triggered the alert needs to have been captured and indexed before the alert fired. Not after.
The 24-minute workflow above is not a best-case scenario. It is what happens when the architecture supports the workflow. The capture was already running. The index was already built. The analyst's job was to navigate it, not to construct it.
That is the shift worth making.
See the Workflow Live
We'll walk through the full incident response workflow with your traffic, on your infrastructure. Lynx, Sentinel, and Quarry on a single server — or scaled to your environment.
Request a Demo