Zeek and Wazuh integration strengthens network threat detection

At a glance

What this is: This is a how-to article showing how to integrate Zeek with Wazuh so network telemetry can be parsed, normalised, correlated, and alerted on in real time.

Why it matters: It matters because security teams need network visibility that feeds detection and response workflows, especially where reconnaissance and suspicious DNS or TLS activity may precede broader compromise.

👉 Read Wazuh's blog post on integrating Zeek with Wazuh for network threat detection

Context

Network security monitoring often fails when telemetry exists but is not normalised into a form that SIEM and response tooling can act on. Zeek produces rich traffic logs, but those logs need parsing, mapping, and alert logic before they become useful for detection. In identity-adjacent terms, this is about controlling access paths and spotting suspicious activity around services, certificates, and query behaviour rather than treating raw network data as evidence by itself.

The article is fundamentally a control-integration guide, not a threat report. Its practical value is showing how network visibility can be turned into usable security signals for brute force, reconnaissance, DNS anomalies, and certificate validation issues. That is a typical operational challenge for teams that rely on SIEM and XDR pipelines to reduce detection latency and support triage.

Key questions

Q: How should security teams turn Zeek network logs into useful SIEM detections?

A: Start by normalising Zeek output into a consistent schema, then map high-value fields such as source, destination, protocol, DNS query, and TLS status into rules that reflect real attacker behaviour. Correlation matters more than volume. A good setup turns repeated network anomalies into a small number of triage-ready alerts.

Q: Why do DNS and TLS events matter for early threat detection?

A: DNS and TLS often expose suspicious infrastructure before an incident becomes obvious elsewhere. Repeated lookups, rejected connections, and invalid certificates can reveal scanning, command-and-control, or compromised services. Those events are valuable because they give defenders early warning, provided the detections are tuned to ignore routine benign noise.

Q: What do security teams get wrong about network monitoring pipelines?

A: They often treat logging as the outcome instead of the starting point. If Zeek events are not parsed, thresholded, and tied to response ownership, the team gets visibility without decisions. Effective monitoring turns packet data into action, not just storage.

Q: How do teams decide whether certificate validation alerts are worth investigating?

A: Treat them as context-sensitive signals rather than automatic compromise indicators. A self-signed or expired certificate may reflect misconfiguration, but it can also point to malicious infrastructure or trust abuse. Investigate ownership, exposure, and change history before dismissing the alert.

Technical breakdown

How Zeek turns packet data into structured security telemetry

Zeek is a network analysis framework, not a packet sniffer in the narrow sense. It observes traffic and writes structured logs such as conn.log, dns.log, and ssl.log, each with fields that describe a different view of the session. By default, those logs are tab-separated and schema-specific, which makes direct correlation harder. Converting them to JSON and mapping fields into a standard schema creates a more reliable feed for downstream analytics, alerting, and response workflows.

Practical implication: normalise Zeek output before ingestion so detection logic can key off consistent fields rather than ad hoc log formats.

Why Wazuh correlation matters for network detection

Wazuh adds the security context that raw Zeek telemetry lacks. Once Zeek logs are ingested, rules and decoders can correlate repeated connection failures, suspicious DNS lookups, and certificate validation problems into actionable alerts. This is the difference between observation and detection. The real architectural benefit is that network activity becomes searchable, thresholdable, and automatable inside a broader monitoring platform, which is what allows analysts to prioritize signals instead of chasing every event.

Practical implication: use correlation rules and thresholds to convert repeated network behaviours into higher-confidence alerts.

How TLS and DNS signals support early warning

DNS and TLS logs often expose suspicious infrastructure before an attack becomes noisy elsewhere. Repeated DNS queries can indicate command-and-control lookups, while self-signed or expired certificate usage can surface malicious or compromised services. In practice, these signals are useful because they are often low-level indicators that appear earlier than endpoint alerts or user-visible impact. The challenge is not collecting them, but tuning the detection logic so benign exceptions do not drown out meaningful anomalies.

Practical implication: tune DNS and certificate-based detections carefully so early-warning signals remain visible and actionable.

Threat narrative

Attacker objective: The attacker aims to discover services, identify weak points, and use network-side signals to support intrusion, reconnaissance, or command-and-control activity.

1. Entry occurs through routine network activity that Zeek can observe, such as DNS lookups, connection attempts, or TLS sessions that later prove suspicious.
2. Escalation emerges when repeated failed connections, port probes, or certificate anomalies reveal reconnaissance or abnormal trust conditions that correlate into a higher-confidence alert.
3. Impact is the security team's ability to detect and investigate brute force, scanning, or suspicious infrastructure before the activity develops into a broader compromise.

NHI Mgmt Group analysis

Network visibility becomes governance only when telemetry is normalised and actionable. Raw Zeek logs are useful, but they do not become control evidence until they are parsed, mapped, and correlated into a monitoring system. That is the gap this article addresses, and it is the same gap that appears in many logging programmes where data collection outpaces operational use. For practitioners, the lesson is to treat telemetry normalisation as part of the control plane, not a back-end convenience.

Early detection depends on recognising weak signals before they become incident narratives. DNS anomalies, connection rejects, and TLS certificate failures are not the breach themselves, but they often reveal the shape of suspicious behaviour. This is where SIEM and XDR programmes either add value or become noise factories. Teams that cannot threshold and triage these events quickly will miss the low-level indicators that matter most.

Structured network telemetry should be linked to identity and access review where service trust is involved. Certificate validation failures, unusual connection patterns, and repeated probes often intersect with exposed services, shared credentials, or unmanaged endpoints. That intersection matters for IAM and NHI governance because network events frequently expose the operational reality of identities used by workloads and services. Practitioners should treat network monitoring as an input to broader access and trust governance.

Zeek-to-SIEM integration is a detection design pattern, not an end state. The article shows how to make packet-level visibility operational, but the deeper requirement is consistent rule tuning, case validation, and response ownership. Without those controls, teams accumulate logs instead of reducing risk. The practical conclusion is that monitoring architecture must be built around decision points, not just collection points.

What this signals

Structured telemetry only reduces risk when it feeds a decision cycle. Network monitoring programmes that stop at collection tend to accumulate technical debt, while teams that normalise and correlate logs can shorten investigation time and improve escalation quality. In practice, the next maturity step is not more data, but better linkage between detections, asset context, and response ownership.

For identity-adjacent operations, network signals should be reviewed alongside service endpoints, certificates, and trust relationships. That is where hidden exposure surfaces: unmanaged services, weak segmentation, and credentials that are visible only through their network behaviour. Teams that connect those layers can spot problems earlier and avoid treating every anomaly as an isolated event.

For practitioners

• Normalise Zeek logs before ingestion Convert Zeek TSV output into JSON and map fields into a consistent schema before sending events into Wazuh or any other SIEM pipeline. This keeps correlation rules stable and reduces parser drift when log formats differ by sensor or deployment.
• Tune rules around repeated network behaviours Create thresholds for repeated rejected connections, DNS query patterns, and TLS validation failures so noisy activity escalates into a small set of actionable detections. Validate each rule against known-benign traffic before production rollout.
• Use TLS validation failures as investigation triggers Investigate self-signed or expired certificate events in context, because they may indicate malicious infrastructure, compromised services, or misconfigured trust boundaries. Route these events into triage workflows with asset ownership attached.
• Connect network alerts to service trust review When alerts point to unusual services or endpoints, check whether the affected system relies on shared credentials, unmanaged certificates, or weak network segmentation. That turns a network event into a governance review instead of a standalone alert.

Key takeaways

• Zeek and Wazuh solve a visibility problem only when network logs are normalised into actionable security signals.
• Repeated rejects, DNS anomalies, and certificate validation failures are early indicators that deserve correlation, not isolated review.
• The strongest operational outcome is a detection pipeline that links network telemetry to triage, ownership, and response decisions.

Key terms

• Zeek: Zeek is a network security monitoring framework that observes traffic and produces structured logs about sessions, protocols, and application behaviour. It is commonly used to turn raw packet activity into searchable telemetry that supports detection, investigation, and forensic analysis.
• SIEM/XDR Correlation: SIEM/XDR correlation is the process of combining related events into a single security signal that can be investigated or automated. In practice, it helps teams move from isolated logs to context-rich detections that reflect attacker patterns rather than raw noise.
• TLS Certificate: A TLS certificate is a machine credential used to prove a server or service is authentic during encrypted communication. In practice, it is a non-human identity artifact with a fixed expiration date, ownership requirement, and renewal workflow that must be governed like any other sensitive credential.

What's in the full article

Wazuh's full blog post covers the operational detail this post intentionally leaves for the source:

• Exact Zeek installation and configuration commands for Ubuntu 24.04 and Wazuh OVA environments
• Full decoder and rule XML examples for DNS, connection, and SSL/TLS event handling
• Step-by-step dashboard validation flows for each test case, including filter setup and alert review
• Lab simulation commands for scanning, DNS lookup generation, and certificate validation testing

👉 Wazuh's full guide includes the Zeek configuration steps, custom rules, and alert validation workflow.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps identity and security practitioners build control models that connect trust, lifecycle, and access decisions.