Netcap · Investigation workflow
PCAP Analysis: From DNS to HTTP and File Evidence
A useful network investigation connects an observation to the records and packets that support it. Start with a small capture whose contents you already know.
By Amsterdam Technologies · Updated 9 November 2026
Choose the implementation and preserve the input
This workflow uses Netcap’s public Go command-line implementation and the reproducible synthetic-transfer lab. Commercial desktop editions have a separate release and feature surface. Check net --version and the documentation’s release notes before copying commands.
Keep the original PCAP or PCAPNG unchanged. Write analysis output to a new directory and record the tool version and options. Capture truncation, missing packets and encryption affect what can be concluded even when the parser finishes successfully.
Start with an offline, known-answer capture
The synthetic transfer lab creates a DNS answer followed by an HTTP transfer between documentation addresses. Its Python fixture generator writes PCAP bytes locally; it sends no network traffic. Run it from the matching repository checkout as described in the lab.
python3 scripts/docs-fixtures.py
net capture -read doc-fixtures/investigation.pcap -out doc-fixtures/audit \
-rules docs/examples/http-observation.yml -conns -dpi=false -geoDB=false
net dump -read doc-fixtures/audit/HTTP.ncap.gz -jsonThe lab retains its documented v0.15.2 baseline. Use its complete prerequisites and checks rather than assuming every historical Netcap binary accepts current flags.
Follow DNS, HTTP and the extracted file
- Inspect the DNS records for the expected question and answer. A matching name and time can suggest a relationship; they do not establish why an application made a connection.
- Inspect the HTTP transaction. In this fixture, the request is for
/fixture.txtover TCP port 8080. - Inspect the File record and its completeness fields. Compare the stored body and SHA-256 hash with the fixture’s expected content.
- Follow related evidence to the Connection and Alert records. Keep the relationship’s scope and limitations alongside the result.
The expected “Documentation HTTP Transfer” alert identifies a known fixture. It is not evidence that the transfer is malicious. Similarly, a filename or MIME classification is not an integrity check on the extracted bytes.
Check that the rule stays quiet on benign input
The companion benign capture contains the DNS exchange without the HTTP transfer. Analyze it with the same rule. It must not produce the fixture’s HTTP-transfer alert. An absent alert file and a file containing no matching rows can both be valid outcomes, depending on empty-writer cleanup.
A positive example alone does not demonstrate useful detection. Keeping a benign control beside the positive capture makes changes to rules and decoder behavior easier to review.
Export selected packets without losing context
The lab’s packet-evidence command exports the selected TCP packets with a manifest binding the input and output hashes. Preserve the original capture too: selecting the TCP exchange intentionally leaves out its DNS context. Record the selection expression with the evidence.