Zeek Conn.log

What Conn.log Records and Why It Matters

Conn.log is Zeek’s core connection record, capturing who talked to whom, over what protocol, for how long, and in what state. That makes it the default starting point for answering basic network questions before moving into deeper packet or protocol analysis.

Because it is tabular and high-volume, Conn.log is useful for quick filtering, pivoting, and correlation across many hosts and time windows. It is often the first place analysts look when they need a compact view of traffic patterns, unusual endpoints, or suspicious connection behaviour.

How Conn.log Fits Network Security Monitoring

Conn.log is not a full payload view, but it provides the skeleton of network activity. In practice, it helps security teams establish baselines, identify which internal or external systems are communicating, and decide when packet capture, DNS, or application-layer logs are needed for follow-up.

Its value increases when it is used alongside other Zeek logs and flow sources. A connection record alone may not prove malicious intent, but it can surface the timing, directionality, and persistence patterns that justify a hunt or incident review.

Common Fields and Analytical Uses

The most useful Conn.log fields are the ones that describe topology and behaviour at scale: origin and responder addresses, ports, transport protocol, duration, and connection state. Those fields support questions such as whether a connection succeeded, whether it was long-lived, whether it involved uncommon ports, or whether it repeated across many hosts.

Analysts also use Conn.log to enrich other detections with context. For example, connection duration and state can help distinguish normal client-server traffic from beacon-like patterns, scanning, reset-heavy failures, or short-lived probes that would otherwise blend into routine activity.

Using Conn.log for Investigation and Hunting

Conn.log is especially valuable when the investigation needs a scalable first pass over traffic evidence. It helps narrow down which sessions deserve deeper inspection, whether the concern is lateral movement, unusual outbound communication, or repeated access to a sensitive service.

For readers building a detection workflow, Zeek’s connection log works best as a pivot source, not an endpoint. The strongest investigations combine it with DNS, HTTP, TLS, file, and notice data, then move to packet evidence only when the metadata suggests a real anomaly.

Good operational context for Zeek’s broader logging model is covered in Zeek Network Monitoring Guide, which shows how Conn.log fits into logging, scripting, deployment, and hunt workflows. For a broader evidence model that includes Zeek metadata, see Network Forensics Guide.

Risk and Threat Considerations

Conn.log is powerful because it exposes traffic relationships at scale, but that same visibility can be incomplete if an organisation treats metadata as proof of safety. Attackers often hide in ordinary-looking connections, use long-lived sessions, or blend command-and-control and exfiltration into common protocols, so Conn.log must be interpreted with other telemetry.

Failure mechanism: Analysts over-trust connection metadata, miss encrypted or protocol-abused traffic, or fail to correlate Conn.log with DNS, proxy, TLS, or packet evidence. That creates blind spots for beaconing, covert exfiltration, and lateral movement.

Impact: Suspicious activity can persist with low visibility, allowing adversaries to retain access, expand laterally, or move data out of the environment before defenders recognise the pattern.

Practitioner Guidance

Why practitioners should care: Conn.log is most valuable when it is treated as a triage and correlation source, not as a standalone verdict. Its fields are concise enough for fast hunting, but only if teams define what “normal” looks like for their environment and then compare anomalies against that baseline.

What to watch for: Long-lived or repeated connections, unusual ports, unexpected external destinations, connection-state patterns that suggest scanning or resets, and sessions that line up with DNS or TLS anomalies. Those patterns usually warrant a deeper look rather than immediate dismissal.

Practitioner takeaway: Use Conn.log to prioritise investigation, then confirm meaning with complementary logs or packet evidence before drawing conclusions.

Related resources from NHI Mgmt Group

• Conn Log
• Zeek x509.log
• Zeek ssl.log
• Zeek HTTP Log