We build Flowtriq and one of our core features is PCAP capture on every detected attack. This post explains why post-attack evidence matters, why most tools do not keep it, and what operators lose when their attack data vanishes.
The 5-minute forensics window
A DDoS attack hits your server at 3:17 AM. Your detection tool fires an alert. Automated mitigation kicks in and stops the attack within 10 seconds. At 3:18 AM, the incident is over. Everyone goes back to sleep.
At 9:00 AM, your customer calls. Their service was degraded for 47 seconds during the attack. They want to know what happened. Was it really a DDoS attack? How big was it? Where did it come from? What type of attack was it? Can you prove it was external and not a failure on your end?
You open your DDoS tool. The alert is there: "Attack detected on 203.0.113.45 at 03:17:22 UTC. Duration: 47 seconds. Type: UDP amplification." But there is no packet capture. No source IP list. No traffic graph with the resolution needed to show the attack ramp-up and mitigation. The tool shows you a summary line and maybe a total byte count. That is all that survived.
Your customer wants evidence. You have a one-line summary. This gap between what happened and what you can prove happened is the forensics problem in DDoS protection.
"The attack lasted 90 seconds. By the time I checked the next morning, all I had was a log line that said 'attack detected' and a log line that said 'attack ended.' No packet data, no source analysis, nothing I could show the customer or send to our insurance company."
Why most tools do not keep attack data
Storing detailed attack data is expensive. A 10 Gbps DDoS attack generates roughly 1.25 GB of packet data per second. Even a 30-second attack produces 37 GB of raw PCAP. Most tools make a practical decision: storing that much data for every attack on every server is too expensive, so they discard the packet-level evidence and keep only aggregate statistics.
The math gets worse for flow-based detection tools. These tools never see the actual packets in the first place. They analyze sampled flow data (sFlow, NetFlow, IPFIX) that captures metadata about traffic flows, not the traffic itself. A flow record tells you "there were 500,000 UDP packets from port 53 to port 12345 in the last 30 seconds." It does not tell you what was in those packets, what the source IPs were (beyond sampled examples), or what the payload contained.
The specific reasons attack data vanishes:
No PCAP capability. Many detection tools, especially those based on flow telemetry, have no mechanism to capture actual packets. They analyze flow metadata, not traffic. They literally cannot produce a packet capture because they never see the packets.
Short retention windows. Tools that do capture some attack data often retain it for hours or days, not weeks or months. When the customer calls the next day, the data might still be there. When the insurance company asks for evidence three weeks later, it is gone.
Aggregate-only storage. Some tools store attack events as aggregate records: start time, end time, peak volume, attack type, total bytes. These records survive long-term but lack the granularity needed for forensic analysis. You know an attack happened, but you cannot prove what it looked like at the packet level.
Storage cost constraints. Tools that could store detailed data choose not to because of storage costs. On-premise appliances have finite disk capacity. SaaS tools have storage limits tied to pricing tiers. In both cases, detailed attack data is the first thing sacrificed when storage fills up.
Why post-attack evidence matters
Customer communication
When a customer experiences an outage or degradation caused by a DDoS attack targeting their server, they want proof. A one-line alert summary does not satisfy a customer who lost revenue during the incident. They want to know: how big was the attack (bandwidth, packets per second)? What type of attack was it? How long did it take to detect? How long did mitigation take? Was any of their legitimate traffic affected?
With forensic data (packet captures, traffic graphs, classification details), you can produce a credible incident report that answers all of these questions. Without it, you are asking the customer to trust your word that the outage was caused by an external attack and not by a failure in your infrastructure. That trust erodes quickly if you cannot back it up with evidence.
Insurance claims
Cyber insurance policies increasingly cover DDoS-related losses, including business interruption, incident response costs, and customer SLA credits. But insurance claims require evidence. The underwriter wants to see documentation that a DDoS attack occurred, what its characteristics were, how long it lasted, and what the impact was.
A packet capture with timestamps, source IP analysis, and traffic classification provides the kind of evidence that insurance adjusters accept. A one-line log entry does not. Operators who cannot produce forensic evidence for their insurance claims risk having claims denied or delayed.
Compliance and regulatory reporting
Regulatory frameworks like NIS2 (for EU operators), SOC 2, and PCI DSS require incident documentation. NIS2 Article 23 specifically mandates that operators submit an initial notification within 24 hours and a detailed incident report within 72 hours of a significant incident. That detailed report needs to include the nature of the incident, its impact, and the measures taken to address it.
Producing a "detailed incident report" requires detailed incident data. If your detection tool only kept a summary line and a total byte count, your incident report will be thin enough to raise questions from the regulator. PCAP evidence, traffic graphs, classification confidence scores, and mitigation action logs provide the depth that compliance reporting requires.
Root cause analysis
After an attack, the question is not just "what happened?" but "why did it happen and how do we prevent it next time?" Root cause analysis requires examining the attack traffic in detail: which source IPs contributed the most volume? Were the source IPs spoofed or real? Did the attack target a specific service port or a random port? Was the attack amplified through a specific reflection vector?
This analysis informs defensive improvements. If the attack used DNS amplification, you might deploy DNS response rate limiting. If the attack came from a specific ASN, you might add that ASN to your monitoring watchlist. If the attack targeted a specific port, you might deploy port-specific FlowSpec rules. None of these improvements are possible without the data to analyze.
Law enforcement cooperation
When DDoS attacks cause significant damage, operators sometimes work with law enforcement to identify and prosecute the attackers. Law enforcement asks for evidence: packet captures, source IP lists, timing information, and payload samples. Without forensic data, there is nothing to hand over, and the investigation cannot proceed.
What good forensics looks like
Effective DDoS forensics captures and retains the following for every detected attack:
Packet capture (PCAP). A sample of actual packets from the attack window. Not every packet (that would be impractical for large attacks), but a representative sample that captures the attack structure, packet sizes, flags, protocols, and payload patterns. This is the gold standard of forensic evidence because it can be independently verified by any network analysis tool (Wireshark, tcpdump, tshark).
Traffic timeline with sub-second resolution. A time-series graph showing bandwidth and packet rate throughout the attack, with enough resolution to show the attack onset, the peak, the mitigation effect, and the tail. 1-second or sub-second resolution is necessary to accurately represent short attacks and fast mitigation.
Classification confidence. Not just "this was a UDP amplification attack," but the confidence level of that classification and the specific signals that led to it. If the classification was based on packet size distribution, show the distribution. If it was based on source port analysis, show the port breakdown. This transparency lets operators (and their customers) verify that the classification is credible.
Source analysis. Top contributing source IPs or ASNs, geographic distribution (if available), and whether sources appear spoofed (based on TTL analysis, TCP sequence validation, or similar heuristics). This data supports root cause analysis and, in some cases, upstream abuse reporting.
Mitigation action log. What mitigation actions were taken, when they were taken, and what their effect was. Did a FlowSpec rule deploy at 03:17:25? Did attack traffic drop by 95% within 2 seconds of deployment? This chain of actions and effects demonstrates that the operator's defenses worked as intended.
Every attack gets a PCAP. Every incident has evidence.
Flowtriq captures packet-level evidence on every detected attack. Traffic timelines, classification data, source analysis, and mitigation logs, all retained and accessible through the dashboard.
Start Free Trial →How Flowtriq handles forensic data
Flowtriq's agent captures a PCAP sample during every detected attack. The capture starts when detection fires and continues for a configurable window (default: the duration of the attack plus a post-attack tail). The PCAP is uploaded to the cloud backend and associated with the attack event in the dashboard.
What this means in practice:
- Every attack has a PCAP. Whether it is a 30-second port scan or a 4-hour volumetric flood, there is packet-level evidence available for review.
- PCAPs are downloadable. Operators can download the PCAP file and open it in Wireshark or any other analysis tool. The data is not locked in a proprietary format.
- Attack events include classification data, traffic timelines, and source analysis. The dashboard shows the full forensic picture, not just a summary line.
- Data retention is measured in months, not hours. Attack events and their associated forensic data are retained long enough to support compliance reporting, insurance claims, and customer communication.
We are transparent about limits: we capture a representative sample of attack packets, not the complete traffic stream. For a 100 Gbps attack, capturing every packet would generate terabytes of data. The sample is large enough to verify the attack classification and provide forensic evidence, but it is not a complete record of every packet received during the attack.
What operators should demand
Regardless of which DDoS tool you use, here is what to ask about forensic capabilities:
- Does the tool capture actual packets, or just flow metadata? Flow-based tools cannot produce PCAP evidence because they never see the packets. If your compliance or insurance requirements include packet-level evidence, you need a tool that operates at the packet level.
- How long is attack data retained? If the retention window is shorter than your compliance reporting timeline, you will not have the data when you need it.
- Can you export the data? Forensic data locked in a proprietary dashboard is less useful than data you can download, share with customers, send to insurers, or submit to regulators.
- What is the resolution of traffic data? 5-minute averages do not capture the dynamics of a 30-second attack. Sub-second resolution is necessary for accurate forensic analysis.
- Is the classification explained? A label that says "UDP amplification" is less useful than a classification that shows the packet size distribution, source port analysis, and confidence score that led to that label.
The attack is the easy part. Knowing what happened, proving what happened, and learning from what happened is where most DDoS tools fall short. Forensic data is not a nice-to-have feature. It is the difference between "we handled the attack" and "we can prove we handled the attack."