How to write an incident report from a packet capture

The analysis is only half the job. A manager needs to know what happened and what to do; an engineer needs to check your work; and in six months someone will need to understand why a decision was made. One well-structured report can serve all three.

1. Write for two readers

Most readers stop after the first page. Put everything a decision-maker needs there, in plain language, and the technical detail after it for those who need to verify:

• The first page answers: what happened, how bad is it, is it over, and what do we need to do?
• The rest answers: how do you know? Every claim on the first page should lead to evidence later in the report.

2. Record the basics

A capture without context can't be interpreted, and a report that loses the context can't be checked. Record:

• Where the capture was taken (which host, port or tap), and what it could and couldn't see.
• The time window, with the time zone. Use UTC throughout the report, and say so.
• Any capture filter, and the snap length if packets were truncated.
• Who captured it, how it was stored, and a hash of the original file.

capinfos -a -e -c incident.pcapng     # first and last packet, packet count
sha256sum incident.pcapng            # identifies the exact file you analysed

3. Use a fixed structure

1. Executive summary. A one-sentence verdict, then the few things that need attention and what to do about each. Say what was checked and found clean as well: "no connections to known-bad addresses" is a finding.
2. Scope and method. The capture details above, the tools used, and what was out of scope.
3. Timeline. Key events in UTC order: first contact, the suspicious activity, the response. Times from packets, not from memory.
4. Findings. One section each, most severe first, written as below.
5. Limitations. What the capture couldn't show: encrypted content, other network segments, the time before capture began.
6. Appendix. Evidence files and their hashes, indicators (addresses, domains, hashes) for blocking, and raw tables.

4. Write findings that can be checked

Each finding should separate three things, so a reader can agree with the evidence while questioning the interpretation:

• Observed: "Host 10.0.4.17 made 214 DNS lookups for random-looking names under t.example between 14:02 and 14:31 UTC (frames 18,220 to 40,915)."
• Interpreted, with confidence: "This is likely DNS tunnelling. The names are base32-encoded and numbered in sequence, and no known vendor uses the domain."
• Recommended: "Isolate 10.0.4.17, block t.example at the resolver, and examine the host for the process making the lookups."

Use confidence words consistently, and define them once: confirmed (the evidence leaves no other reasonable explanation), likely and possible. Write "the capture shows" rather than "the attacker did": the capture shows packets, and intent is an inference.

5. Attach the evidence

Don't make reviewers search a 5 GB file. Cut a small capture for each finding, by conversation or time window:

# One conversation
tshark -r incident.pcapng -Y "ip.addr == 10.0.4.17 && dns" -w finding-01-dns.pcapng

# A time window
editcap -A "2026-10-12 14:02:00" -B "2026-10-12 14:31:00" incident.pcapng finding-01-window.pcapng

Without a time zone, editcap takes those times as local time on the machine running it, so check the window with capinfos -a -e afterwards. Hash every evidence file, list the hashes in the appendix, and keep the original unchanged. If the report leaves your organisation, sanitize the slices first.

6. Review before sending

• Close out every flagged item. For each automated finding you looked at, record whether it was confirmed, a false positive (and why), or is still under investigation. A false positive with a reason is useful; a silent omission isn't.
• Check every claim against its evidence. Can each sentence in the summary be traced to a finding, and each finding to frames or a file?
• Remove secrets. Passwords, session tokens and personal data that appeared in the capture don't belong in the report. Name the account; don't print the password.
• Have someone else read the first page. If they can't say what happened and what to do, rewrite it.

Manual method vs PCAPNG Analyzer