Reference

Daemons

Normalization engine modules

The modules of the Wazuh normalization engine work together to transform raw events into structured and enriched security data. Each module is responsible for a specific stage of the event processing pipeline, including event reception, decoding, normalization, enrichment, and output generation. This modular architecture constitutes a unified event processing workflow.

Server

The Server module includes two HTTP servers. The events socket receives raw events from the Remoted daemon or the vulnerability scanner. The management API socket exposes operations that internal client dev tools and other Wazuh manager components use. These operations include managing routes, running tester sessions, applying content changes, querying GeoIP and IOC state, toggling raw event indexing, and reading metrics. Both sockets use HTTP with JSON bodies. Protocol buffers (protobuf) define the schema for every request and response.

Orchestrator

The Orchestrator is the runtime hub of the Wazuh normalization engine. It owns the routes table that maps each space to the active security policy and its evaluation priority. It also owns the session table that the tester uses. When an event arrives, the Orchestrator forwards an independent copy to each active policy, allowing a single incoming event to produce multiple output documents, one for each active policy. Routes can be added, replaced, or removed at runtime without restarting the normalization engine, which is what makes hot-swapping of synchronized content possible.

Builder

The Builder turns the declarative content stored in the Engine Content Manager into an executable graph that the Backend can run. It validates field types against the Schema, resolves variables and definitions, and links every helper function used in check, parse, and normalize stages. The Engine Content Manager calls the Builder whenever content changes, so the Orchestrator can register the resulting graph as a route.

Backend

The Backend is the runtime that executes the compiled graph for every event. It goes through the stages described in event policy processing: pre-filter, decoders (including KVDB lookups), enrichment (Geo and IOC), post-filter, and outputs.

Engine Content Manager

The Engine Content Manager is the local mirror of the content managed in the Wazuh indexer. It is organized by spaces. The Engine Content Manager has three responsibilities:

• Storage of decoders, filters, KVDBs, integrations, and policies on the normalization engine endpoint.

• Synchronization with the Wazuh indexer (CMSync), which periodically compares per-space content hashes and pulls the full content when they differ.

• CRUD which validates and applies any mutations issued through the management API.

After every applied change, the Engine Content Manager hands the affected policies to the Builder and asks the Orchestrator to swap the corresponding routes.

Schema

The Schema module loads the Wazuh Common Schema (WCS) document at startup. It exposes the schema to the Builder for build-time field validation and to the Backend for runtime validation of dynamic values. It guarantees that every document the engine emits is type-consistent with the mappings configured in the Wazuh indexer.

KVDB

KVDBs are per-space key-value databases that decoders and filters consult during event processing. For example, decoders use them to map identifiers to canonical names or to merge default values into events. Regular KVDBs are part of the per-space content. CMSync synchronizes them with the rest of the space assets, and the normalization engine rebuilds them when their source changes.

IOC

Indicators of compromise databases are used at the IOC enrichment stage to match fields in incoming events against threat intelligence. These databases are shared across spaces and are independent of the regular content sync. A dedicated IOC synchronizer keeps them up to date. It downloads updates into a temporary database and then swaps it in atomically, so readers never observe a partially updated database.

Geo

The Geo module performs GeoIP and ASN lookups using MaxMind MMDB databases. Like the IOC databases, the Geo databases are global rather than per-space. They are refreshed in the background and hot-reloaded without restarting the Wazuh normalization engine. Refer to the Geo enrichment section of the documentation for more information.

Indexer connector

The indexer connector carries the Wazuh indexer traffic of the normalization engine. It sends outbound processed events (driven by policy outputs) and receives inbound runtime configuration (consumed by the Configuration module). The shared content manager library downloads the ruleset and IOC content through the read calls of the same connection, so content downloads never delay events.

Stream Log

Stream Log provides asynchronous, rotating log channels with size-based and time-based rotation, gzip compression, and retention by file count and total size. It backs the file outputs that policies can configure, and it is also what the optional event dumper uses to persist raw events for forensic investigation. Hot-path writes never block on disk I/O.

Configuration

The local configuration is loaded from the Wazuh manager XML/ini at startup, allowing every module to read from it. A subset of runtime parameters is also pulled periodically from the Wazuh indexer as remote configuration, so operators can tune behavior without restarting the engine. Remote configuration changes are applied with rollback if a module rejects the new values.

Shared libraries

The table below lists the shared libraries provided by the Wazuh manager, their roles, and the components that use them.

CLI tools

The Wazuh manager provides a set of command-line interface (CLI) tools for managing, monitoring, and troubleshooting its components. The table below lists the available CLI tools and their purposes within the Wazuh manager.