Zeek and Wazuh integration strengthens network threat detection

At a glance

What this is: This article shows how Zeek log ingestion into Wazuh can convert network telemetry into detections for brute force, reconnaissance, DNS abuse, and SSL/TLS certificate threats.

Why it matters: It matters because many teams have network data but lack the parsing, correlation, and alerting layer needed to turn it into actionable detection and response.

Context

Network security monitoring fails when telemetry stays fragmented or unreadable. Zeek produces structured network activity logs, but those logs still need parsing, enrichment, and correlation before they become useful for threat detection and response.

This integration sits at the boundary between network security and identity-adjacent monitoring, because the detections include brute force patterns, suspicious DNS lookups, and certificate validation anomalies that often accompany access abuse or compromise. The baseline problem is common: visibility exists in theory, but not in a form that is operationally actionable.

Key questions

Q: How should security teams operationalise Zeek telemetry in a SIEM or XDR pipeline?

A: Security teams should normalise Zeek output into consistent fields, then apply correlation rules that combine repeated events, thresholds, and known indicators. The goal is to turn network telemetry into actionable signals that can be triaged alongside endpoint and cloud data, not to preserve raw logs as an archive only.

Q: Why do repeated connection failures and scan patterns matter more than single network events?

A: Single network events are often ambiguous, but repeated failures in a short window show intent. When connection rejections, port probes, or unusual DNS behaviour cluster together, they usually indicate reconnaissance, service discovery, or attempted access abuse that deserves prioritised investigation.

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.

Q: How should teams decide whether network monitoring is producing useful detections?

A: Network monitoring is working when raw traffic patterns become repeatable detections that lead to investigation and response. If analysts still have to manually interpret every log line, the programme has collection but not operational visibility.

Technical breakdown

Why Zeek telemetry needs normalisation before SIEM correlation

Zeek is a network analysis framework that emits rich TSV logs such as conn.log, dns.log, and ssl.log. Those logs are valuable, but their field structures are log-type specific, which makes them hard to query consistently in a monitoring platform. Normalising the data into JSON and mapping fields into a common schema turns packet-level observation into structured security telemetry that can be searched, enriched, and correlated with other events. That step matters more than simple collection, because detection logic depends on consistent field names, values, and timestamps.

Practical implication: standardise Zeek output before relying on detection rules or cross-source correlation.

How correlation rules turn network events into detections

Wazuh can apply decoders, custom rules, thresholds, and indicator lists to Zeek logs so that repeated patterns become alerts rather than raw records. In practice, that means connection rejections, suspicious DNS activity, and certificate validation anomalies can be chained into higher-confidence signals. The mechanism is not magic analysis, but rule-based context building: a single event may be weak, while repeated events within a window indicate scanning or abuse. This is especially useful where network telemetry must be triaged quickly alongside endpoint or cloud data.

Practical implication: define rule logic around repeated patterns and known indicators, not isolated packets.

What SSL/TLS validation warnings reveal about network trust

Certificate warnings are often treated as transport hygiene, but in a monitoring pipeline they also indicate possible man-in-the-middle activity, misconfigured services, or compromised infrastructure. Zeek can surface the server-side certificate properties, and Wazuh can alert when certificates are self-signed or expired. That does not prove malicious activity on its own, but it gives analysts a high-value signal that network trust assumptions may be broken. For defenders, the important point is that trust failures in transport often overlap with broader compromise conditions.

Practical implication: treat certificate validation alerts as investigation triggers, not cosmetic warnings.

Threat narrative

Attacker objective: The likely objective is to find exposed services, test access paths, or exploit weak trust conditions while remaining within normal network traffic patterns.

1. Entry occurs through observable network activity such as DNS queries, rejected connections, or access to hosts presenting abnormal TLS certificates.
2. Credential or access abuse is inferred when repeated failed connections, scanning, or suspicious name resolution patterns suggest reconnaissance or attempted service discovery.
3. Impact is the generation of actionable alerts that expose likely brute force, port scan, DNS abuse, or certificate-related trust failures before they escalate into broader compromise.

Breaches seen in the wild

• BeyondTrust breach 2024: A stolen BeyondTrust Remote Support API key let a China state-sponsored actor reset accounts and reach US Treasury workstations in 2024.
• Schneider Electric Jira breach 2024: Credentials linked to a Lumma infostealer infection gave Hellcat access to Schneider Electric's Jira; 40GB and 400,000 user rows claimed.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Network telemetry only becomes governance-relevant when it is normalised into a usable security control. Zeek by itself produces visibility, but visibility is not yet detection, triage, or response. The governance gap is the translation layer between raw packet observation and policy-enforced action, which is where SIEM/XDR integration adds value. Practitioners should treat parsing and field normalisation as a control requirement, not a convenience.

Certificate validation alerts are an underused signal for trust boundary failure. Expired or self-signed certificates often get dismissed as operational noise, yet they can also indicate infrastructure abuse, interception risk, or unmanaged services. In a network monitoring programme, these warnings should feed both incident investigation and hygiene remediation because they reveal where trust is no longer behaving as intended. The practitioner conclusion is simple: transport trust needs monitoring, not assumptions.

Reconnaissance detection depends on recognising sequence, not just content. A single rejected connection or DNS lookup may be innocuous, but repeated patterns over a short window indicate discovery activity that deserves response. This is where network monitoring becomes a governance issue for identity and access as well, because scans and abnormal lookups are often the prelude to privilege testing or access abuse. Teams should tune for behaviour patterns that show intent, not just individual events.

Blast-radius visibility matters more than log volume. Organisations do not need every packet in context-free form; they need enough structure to understand where suspicious activity is headed, which asset is exposed, and which response path is appropriate. That is the practical case for integrating Zeek with a monitoring platform: it reduces ambiguity at the point where investigation speed matters. The practitioner takeaway is to optimise for decision quality, not telemetry volume.

From our research library:

• Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
• Read next: Identity Visibility and Intelligence Platforms (IVIP) Guide

What this signals

Network visibility becomes actionable only when telemetry is normalised, correlated, and tied to response. The largest failure mode in many monitoring programmes is not lack of data but lack of structure, which leaves analysts with context but no decision path. Zeek-to-SIEM integration is therefore best understood as a governance step that turns observation into enforced detection.

Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs, and the same visibility gap shows up in network telemetry when logs remain siloed or unparsed. The practical lesson is that control quality depends on whether monitoring data can actually support investigation, not whether it exists somewhere in the stack.

For practitioners

• Standardise Zeek logs into JSON before rule creation Convert conn.log, dns.log, and ssl.log into a consistent structure so that alert logic can rely on stable field names, timestamps, and values.
• Tune alerts for repeated reconnaissance patterns Use thresholds and frequency windows for rejected connections, scans, and suspicious DNS activity rather than treating each event as a standalone incident.
• Escalate certificate validation failures into investigations Flag self-signed and expired certificate events as potential trust boundary failures and route them into analyst review with surrounding network context.
• Correlate Zeek events with endpoint and cloud telemetry Join network signals with endpoint and cloud data so that suspicious traffic patterns can be validated against host activity and access context.

Key takeaways

• Zeek and Wazuh together address a common operational gap: network telemetry often exists, but it is not structured well enough to drive reliable detections.
• The article uses brute force, port scans, DNS abuse, and certificate validation failures to show how raw network logs can be turned into security signals.
• The main practitioner lesson is to normalise Zeek output, tune for repeated behaviour, and treat trust failures in TLS as investigation triggers.

Key terms

• Network Visibility: Network visibility is the ability to see and understand activity across connections, workloads, applications, and databases in context. It goes beyond collecting logs or packets by showing how traffic and access patterns relate to each other, so teams can distinguish normal behavior from suspicious movement and respond with precision.
• Log Normalization: Log normalization is the process of converting different event formats into a common schema. It lets detection rules work across many sources, reduces source-specific rule drift, and keeps investigations consistent when infrastructure or vendors change.
• Reconnaissance Detection: Reconnaissance detection is the identification of traffic patterns that suggest probing, discovery, or target mapping before a full attack. It usually depends on repeated events, unusual destination patterns, and short-interval behaviour rather than one-off packets.
• Certificate validation: Certificate validation is the process of checking that a TLS certificate chains to a trusted authority and matches the intended hostname. In practice, it is a core trust decision, because accepting invalid or mismatched certificates lets an attacker impersonate a legitimate endpoint and intercept secure traffic.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, identity lifecycle, and secrets management. It helps security and identity practitioners connect access controls to the broader monitoring and response model their programmes depend on.