Zeek: turn a connection into an investigation trail
Use connection identifiers to connect evidence while keeping the limits of passive visibility explicit.
Archive date is an editorial placement, not the original publication date. Published 9 September 2026; documentation reviewed 9 September 2026. Examples describe proposed checks, not customer incidents or measured product results.
A network alert becomes more useful when an analyst can establish what happened immediately before and after it. Zeek supplies protocol and connection context that can support that investigation, even when a signature alone gives little explanation.
Begin with a known capture
On a host with Zeek installed, process an approved synthetic PCAP from a clean output directory:
mkdir -p ./zeek-lab-output
cd ./zeek-lab-output
zeek -r ../approved-test.pcap LogAscii::use_json=T
This writes local logs. It does not send traffic or validate the location of a production sensor. Zeek documents the workflow in its quick start.
Choose a fixture whose endpoints and expected protocols are known. A large unexplained capture is a poor first test because it makes missing evidence difficult to recognize.
Follow one connection
Inspect a compact view of JSON connection records:
jq -c '{uid,origin:."id.orig_h",destination:."id.resp_h",
port:."id.resp_p",proto,service,duration}' conn.log
The connection-log reference explains the fields and the connection UID. Use the UID to locate related protocol records where that field is present. Preserve sensor identity and time context when combining records from multiple systems.
Ask a specific question: did this host query a name and then connect to an unexpected service? The DNS answer and the subsequent destination can support a hypothesis. They do not prove that the same process or user caused both actions without additional endpoint evidence.
Know what encryption removes
TLS can leave useful connection and handshake metadata while hiding application contents. Visibility varies with protocol and configuration. A missing HTTP log for an encrypted connection is not, by itself, a sensor failure.
Likewise, traffic that never traverses the observation point cannot appear in the logs. Capture loss, asymmetric routing, and mirror oversubscription can create partial records. Investigate those conditions before interpreting absence as proof that communication did not happen.
Build a repeatable analyst exercise
Prepare a small scenario containing a DNS lookup, an allowed web request, and a connection to a lab-only destination. Ask a second operator to reconstruct the sequence using the logs and the documented queries. Record which claims can be established and which require endpoint or identity records.
Then repeat on the live monitored path using approved harmless traffic. Verify that the logs reach the analyst’s system within the agreed window and remain queryable after rotation.
Avoid turning metadata into certainty
A large transfer is not automatically exfiltration. A new destination is not automatically malicious. Use inventory, business purpose, endpoint process information, and access records to test the hypothesis.
A useful deployment delivers dependable context and explicit blind spots. See encrypted traffic visibility for the complementary sensor-placement review.