Wazuh Architecture & Data Flow

What is Wazuh?

Wazuh is a free, open-source security platform used for threat detection, integrity monitoring, incident response, and compliance. It is widely deployed in Security Operations Centers (SOCs) as a SIEM (Security Information and Event Management) and XDR (Extended Detection and Response) solution.

Wazuh collects security-relevant data from endpoints across your entire environment — servers, workstations, cloud instances, and containers — analyzes it for threats, and presents findings to security analysts through a centralized dashboard.

In simple terms: Wazuh watches everything happening across your network, detects threats, and gives you a single place to see and respond to them.

The Three Core Components

Wazuh’s architecture is built around three core components, each with a distinct role:

Component Overview

What Makes Wazuh Different?

Unlike traditional antivirus tools that only look for known malware signatures, Wazuh takes a behavioral approach — it monitors what is actually happening on a system and alerts when behavior deviates from what is expected. This allows it to detect:

• Zero-day attacks (never-before-seen threats)
• Insider threats (legitimate users behaving maliciously)
• Configuration weaknesses and compliance violations
• File tampering and unauthorized changes

Question:-

Which component collects endpoint data?

Which component analyzes security events?

Which component stores and indexes data?

Wazuh Server & Data Flow

You’ve already learned what a SIEM does conceptually — collect, normalize, correlate, alert. Wazuh is one real, open-source implementation of exactly that model, split across three components that each own one piece of the job. This chapter traces a single event through all three, using Wazuh’s actual internal component names rather than a simplified stand-in for them.

The Wazuh Server

The Analytics Engine sits at the center of the server, and it does four distinct jobs, not two:

• Data decoding — translating whatever raw format just arrived into a common structure
• Rule matching — comparing that structured data against known-bad patterns
• Correlation — linking multiple separate events together into one bigger picture
• Enrichment — attaching extra context to an event before it’s ever shown to an analyst

That last pair is easy to undersell. Rule matching alone tells you that something happened. Correlation is what notices that five failed logins and one successful one, minutes apart, are actually the same story — not five unrelated facts. Enrichment is what turns a bare IP address into “an IP with a known-bad reputation,” or a bare technique name into its full MITRE ATT&CK context, before an analyst has to go look any of that up manually.

Nothing here happens in isolation — the Analytics Engine is wired directly into the sources that make correlation and enrichment possible in the first place:

• Threat intelligence (IP reputation, file hashes) — the data enrichment actually pulls from
• MITRE ATT&CK (tactic mapping, adversary techniques) — how a rule match gets labeled with a real attacker technique, not just an internal rule ID
• Vulnerability detection (CVE database, inventory connector) — cross-referencing what’s actually installed against what’s actually exploitable
• State of the endpoint (file integrity database, system inventory database) — what changed, and what the endpoint looked like beforehand
• Regulatory compliance (PCI-DSS, HIPAA, NIST, ISO 27001, GDPR) — mapping a finding to the specific standard it violates
• Integration daemon (third-party APIs, external threat intel feeds) — pulling in intelligence Wazuh doesn’t generate itself
• Agent enrollment and communication services — issuing each agent its key and normalizing whatever it sends in, regardless of source technology
• Administration & management and system health & operations — the API service and configuration management that everything else runs on top of, plus cluster health checks and distributed synchronization when the server is scaled across multiple nodes

Once the engine has decoded, matched, correlated, and enriched an event, exactly one component moves it onward: Filebeat, which forwards the finished alert to the Wazuh Indexer. Notice this is the same conclusion as before, now with the full picture behind it — an event can be perfectly decoded, correctly matched, properly correlated, and richly enriched, and still never become searchable if Filebeat isn’t the one carrying it across.

The Complete Data Flow

Here’s the same journey traced through Wazuh’s actual internal pieces, not a simplified stand-in for them:

On the monitored endpoint, the Wazuh Agent isn’t one process — it’s two working together. Logcollector watches whatever sources are configured (a monitored file, Windows logs, macOS ULS logs, Linux logs) and captures new entries as they appear. Agentd owns the actual connection back to the server — encrypted, authenticated, and resilient to network interruption. Logcollector doesn’t talk to the server directly; it hands events to Agentd, and Agentd is what actually sends them.

On the server side, two things can happen in parallel. Agent traffic arrives at Remoted, the component built specifically to receive encrypted agent connections. But notice Syslog in the diagram bypasses the agent path entirely, going straight into Remoted — this is how agentless sources (network devices, firewalls, anything that can’t run a Wazuh agent) get into the pipeline: no Agentd, no Logcollector on the source side, just a syslog stream aimed directly at the server. The server also runs its own Logcollector, for monitoring files that live on the server itself rather than on a remote endpoint.

Everything — agent traffic, syslog, and the server’s own local files — converges on Analysisd, which runs the three-step process worth knowing precisely:

PRE-DECODING     Splits the raw log into its outermost structure —
                 timestamp, hostname, and the program that logged it —
                 before attempting to understand the message itself

DECODING         Extracts the actual meaningful fields from the message
                 body: user, source IP, action, status
RULE MATCHING    Compares the fully decoded event against Wazuh's
                 rule set to determine whether it's worth an alert

Pre-decoding and decoding being separate steps matters more than it looks: pre-decoding figures out what kind of log this is and where it came from, and only then does decoding know which fields to actually extract from the message itself. You can’t decode a message correctly until you know what format you’re looking at.

Get Muhammad Faizan’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

Every event that reaches Analysisd — matched or not — gets written to archives.json. Only events that actually matched a rule get written to alerts.json. This distinction is worth sitting with: archives.json is your complete, unfiltered audit trail; alerts.json is the curated subset Wazuh has already decided is worth a human's attention. If you're ever investigating something and the alert you expected isn't in alerts.json, checking archives.json tells you whether the event arrived at all, or whether it just never matched a rule.

In the Wazuh Server processing pipeline, after receiving raw data from agents the server ___________ the log to extract structured fields such as username, IP address, and timestamp.

An event was successfully decoded, matched a rule, correlated with related events, and even enriched with threat intelligence — yet it never shows up anywhere in the Indexer or Dashboard. Every step up through alert generation clearly worked. What single component, if it had stopped running, would explain this exact symptom?

A brand-new log format arrives that Analysisd has never seen the exact field layout for, but pre-decoding still succeeds in identifying which source technology it came from. Can decoding go on to extract specific fields like the source IP without first knowing which log format it’s actually looking at? yes/ney

Wazuh Indexer and Dashboard

An alert is only as useful as your ability to find it again later. This chapter covers the two components responsible for exactly that — the Indexer, which stores and protects every event Filebeat forwards to it, and the Dashboard, where all of that data actually becomes something a SOC analyst can act on.

The Wazuh Indexer

The Indexer is built on OpenSearch, and every index is split into primary shards, each of which gets two replica copies — not one — spread across the other nodes in the cluster:

Read the layout carefully: Node 1 holds primary shard P0, plus replicas R1 and R2 — copies of Node 2’s and Node 3’s primary data, not its own. Node 2 holds primary P1, plus replicas R0 and R2. Node 3 holds primary P2, plus replicas R0 and R1. Every single node ends up holding a complete copy of the entire dataset once you combine its own primary with the replicas it’s storing for the other two — which means losing any one node still leaves all three primaries’ data fully recoverable from what’s left.

Reading a Real Alert Document

Once Filebeat delivers an alert and the Indexer stores it, this is genuinely what one looks like:

{
  "timestamp": "2022-04-24T17:24:56.110+0000",
  "agent": { "ip": "10.0.1.52", "name": "Amazon", "id": "001" },
  "data": { "srcip": "68.183.216.91", "srcport": "53820" },
  "rule": {
    "description": "sshd: insecure connection attempt (scan)",
    "id": "5706",
    "level": 6,
    "pci_dss": ["11.4"]
  },
  "mitre": { "technique": ["SSH"] },
  "id": ["T1021.004"],
  "tactic": ["Lateral Movement"]
}

Walk through what each block is actually telling you:

FieldValue in This AlertWhat It Tells Youagentip: 10.0.1.52, name: AmazonWhich enrolled endpoint reported this eventdatasrcip: 68.183.216.91, srcport: 53820The fields Analysisd's decoder pulled from the raw message — who actually connectedruledescription, id: 5706, level: 6, pci_dss: 11.4The match itself — human-readable description, Wazuh's internal rule ID, severity, and an automatic compliance mapping from enrichmentmitre.techniqueSSHWhich MITRE technique this event maps to, in plain termsidT1021.004The formal MITRE ID — Remote Services: SSHtacticLateral MovementWhere this technique sits in a real attacker's playbook

An analyst reading this document doesn’t just learn “someone tried SSH” — they learn exactly which compliance control it touches (PCI-DSS 11.4) and exactly where it sits in a real attacker’s playbook (Lateral Movement via T1021.004), all attached automatically, before anyone opened a case. e.

The Wazuh Dashboard

It’s tempting to think of the dashboard as just “the UI for looking at alerts,” but it actually does two genuinely different jobs that are easy to conflate:

Looking at your security data — real-time alerts, historical search, threat hunting, malware detection results, file integrity monitoring, and the compliance dashboards (PCI DSS, GDPR, HIPAA, NIST 800–53) that the enrichment step above feeds directly.

Managing Wazuh itself — configuring which modules run on which agents, monitoring cluster health, writing custom rules and decoders, and a built-in test tool that shows exactly how a specific log line would be pre-decoded, decoded, and matched before a rule goes live. Direct consoles exist for the Server API and Indexer API too, for working below the dashboard’s own abstractions.

The dashboard talks to the Server API just as directly as it talks to the Indexer — it’s the single interface tying the entire pipeline together, not a passive viewer sitting on top of whatever the Indexer happens to store.

Question Stream:-

The Wazuh Indexer is based on ___________, an open-source search and analytics engine that stores and makes all security events instantly searchable.

Node 2 in a 3-node indexer cluster suffers a complete, unrecoverable hardware failure. Given that every node holds replica copies of the other two nodes’ primary shards, is Node 2’s primary shard data permanently lost? yes/ney

Wazuh Agent

Everything covered so far — decoding, rule matching, correlation, enrichment, shards, the dashboard — only ever sees data that actually reaches the server. The agent is where that data originates, and unlike the server, it runs on the machine you’re actually trying to protect: a laptop, a cloud instance, a container, a server sitting in a rack. Wazuh runs it across Linux, Windows, macOS, Solaris, AIX, and more, which is exactly why it can normalize such wildly different sources into the same pipeline you already understand.

The Agent Daemon — Not a Collector, a Coordinator

The agent isn’t one process quietly tailing a log file. It’s a small, modular system in its own right, with a core daemon coordinating everything underneath it:

The daemon’s four core jobs explain a lot about why the agent behaves the way it does:

• Modules management — deciding which of the modules below are actually enabled on this specific endpoint, since not every module makes sense everywhere (a database server has no reason to run container security monitoring)
• Data flow control — queueing events and applying anti-flooding protection, so a sudden burst of activity on the endpoint doesn’t overwhelm the connection back to the server or the network it travels over
• Data encryption — every byte sent to the server travels over an authenticated, encrypted channel, established the moment the agent first enrolls
• Remote configuration — once connected, the agent can be reconfigured, upgraded, and monitored entirely from the server side, without anyone touching the endpoint directly

That last point matters at scale in a way it doesn’t for a single machine: managing one agent by hand is trivial; managing ten thousand agents by hand isn’t a real option, and remote configuration is what makes the difference.

The Nine Modules — What Actually Runs Underneath

Every module is independently configurable, which means an endpoint only runs what it actually needs rather than everything Wazuh is capable of.

A few of these connect directly to things you’ve already learned elsewhere in this track. FIM is the same concept you saw in the Windows System Log module — a changed file, now caught at the agent level instead of relying on the OS’s own logging. Malware detection’s non-signature approach to hidden processes is the same idea behind the EDR module’s fileless-attack detection: you can’t scan for a hidden rootkit by its file hash if it’s specifically designed to have no visible file to hash. And Active Response is this same agent-level capability you’d recognize from the Incident Response module — the difference here is where the action actually executes: not a human clicking a button in a console, but a script the agent runs locally, the instant a rule matches.

Enrollment — Why the Agent and Server Diagrams Both Show a Key

You already met the server’s half of this relationship in the Wazuh Server chapter: the Agent Enrollment Service issues a unique key, and the Agent Connection Service validates it on every subsequent message. The agent side is the other half of that same handshake — before an agent ever ships its first log line, it has to enroll, receiving the key that becomes its permanent proof of identity. Every message after that point travels encrypted and authenticated, over TCP or UDP, with the daemon’s flow-control mechanisms protecting both the agent’s own stability and the network it shares with everything else.

This is worth internalizing as one continuous idea rather than two separate ones: the agent’s Data encryption function and the server’s Agent Connection Service aren’t two different security measures — they’re the same connection, secured from both ends at once.

Question Stream

The Wazuh Agent communicates with the Wazuh Server over an encrypted channel using port ___________ by default.

The Wazuh Agent feature that monitors critical files and directories for unauthorized changes — such as modifications to `/etc/passwd` — is called File ___________ Monitoring.

The Wazuh Agent checks installed software versions against known vulnerability databases to identify outdated software — this capability is called ___________ Detection.